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.
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.
> 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.
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.
(One nasty was that addi. does not exist, so we used addic. where it was
wanted before, so that had to change.)
Segher
