This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Design for flag bit outputs from asms

On Mon, May 04, 2015 at 12:33:38PM -0700, Richard Henderson wrote:
> (3) Note that ppc is both easier and more complicated.
>   There we have 8 4-bit registers, although most of the integer
>   non-comparisons only write to CR0.  And the vector non-comparisons
>   only write to CR1, though of course that's of less interest in the
>   context of kernel code.

Actually vector (Altivec) write to CR6. Standard FPU optionally write to
CR1, but the written value does not exactly depend on the result of the last
instruction; it is an instead an accrued exception status.

>   For the purposes of cr0, the same scheme could certainly work, although
>   the hook would not insert a hard register use, but rather a pseudo to
>   be allocated to cr0 (constaint "x").

Yes, but we might also want to leave the choice of a cr register to the compiler.

>   That said, it's my understanding that "dot insns", setting cr0 are
>   expensive in current processor generations.  

Not that much if I understand properly and 
no (P7) or one (P8) additional clock for common instructions 
(add/sub and logical), but nothing else, so they are likely a win. 

Shift/rotate/sign extensions seem to have more decoding restrictions: 
the recording ("dot") forms are "cracked" and use 2 integer units.

>   There's also a lot less
>   of the x86-style "operate and set a flag based on something useful".

But there is at least an important one, which I occasionally wished I had: 
the conditional stores. 

The overflow bit might also be useful, not really 
for the kernel, but for applications (and mfxer is slow).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]