[PosibleSpam] Re: z constraint in powerpc inline assembly ?

Gabriel Paubert paubert at iram.es
Fri Jan 17 04:42:40 AEDT 2020


On Thu, Jan 16, 2020 at 07:57:29AM -0600, Segher Boessenkool wrote:
> On Thu, Jan 16, 2020 at 09:06:08AM +0100, Gabriel Paubert wrote:
> > On Thu, Jan 16, 2020 at 07:11:36AM +0100, Christophe Leroy wrote:
> > > Hi Segher,
> > > 
> > > I'm trying to see if we could enhance TCP checksum calculations by splitting
> > > inline assembly blocks to give GCC the opportunity to mix it with other
> > > stuff, but I'm getting difficulties with the carry.
> > > 
> > > As far as I can read in the documentation, the z constraint represents
> > > '‘XER[CA]’ carry bit (part of the XER register)'
> > 
> > Well, the documentation is very optimisitic. From the GCC source code
> > (thanks for switching to git last week-end ;-)), it is clear that the
> > carry is not, for the time being, properly modeled. 
> 
> What?  It certainly *is*, I spent ages on that back in 2014 and before.
> See gcc.gnu.org/PR64180 etc.
> 
> You can not put the carry as input or output to an asm, of course: no C
> variable can be assigned to it.
> 
> We don't do the "flag outputs" thing, either, as it is largely useless
> for Power (and using it would often make *worse* code).
> 
> If you want to access a carry, write C code that does that operation.
> The compiler knows how to optimise it well.
> 
> > Right now, in the machine description, all setters and users of the carry
> > are in the same block of generated instructions.
> 
> No, they are not.  For over five years now.  (Since GCC 5).
> 
> > For a start, all single instructions patterns that set the carry (and
> > do not use it) as a side effect should mention the they clobber the 
> > carry, otherwise inserting one between a setter and a user of the carry 
> > would break.
> 
> And they do.
>

Apologies, I don't know how I could misread the .md files this badly.
Indeed I see everything now that you mention it.

I'm still a bit surprised that I have found zero "z" constraints in the
whole gcc/config/rs6000 directory. Everything seems to be CA_REGNO.

> All asms that change the carry should mention that, too, but this is
> automatically done for all inline asms, because there was a lot of code
> in the wild that does not clobber it.

I was not aware of this, anyway I would always put as correct as
possible clobbers for my inline assembly code.

> 
> > This includes all arithmetic right shift (sra[wd]{,i}, 
> > subfic, addic{,\.} and I may have forgotten some.
> 
> {add,subf}{ic,c,e,ze,me} and sra[wd][i] and their dots.  Sure.  And
> mcrxr and mcrxrx and mfxer and mtxer.  That's about it.

Yes, but are last ones (the moves) are ever generated by the compiler?

Looking at the source (again) it seems that even lswi has disappeared.

> 
> We don't model the second carry at all yet btw, in GCC.  Not too many
> people know it exists even, so no big loss there.
> 

Anyway, I couldn't use it. I tried to buy a Talos II at work but
management made it too complex to negotiate. The problem was not the
money, but the paperwork :-(. Now my most powerful PPC machine is a 17" 
Powerbook G4.

> (One nasty was that addi. does not exist, so we used addic. where it was
> wanted before, so that had to change.)
> 
> 
> Segher


	Regards,
	Gabriel


More information about the Linuxppc-dev mailing list