On 2/1/2016 12:40 PM, Richard Henderson wrote:
On 02/02/2016 01:58 AM, Ulrich Weigand wrote:
I think on many targets a clobber "cc" works because the backend
actually defines a register named "cc" to correspond to the flags.
Therefore the normal handling of clobbering named hard registers
catches this case as well.
Yes. C.f. Sparc ADDITIONAL_REGISTER_NAMES.
This doesn't work on i386 because there the flags register is called
"flags" in the back end.
Once upon a time i386 used cc0. A survey of existing asm showed that
almost no one clobbered "cc", and that in the process of changing i386
from cc0 to an explicit flags register we would break almost
everything that used asm.
The only solution that scaled was to force a clobber of the flags
register.
That was 1999. I think you'll buy nothing but pain in trying to
change this now.
I expect you are right. After experimenting, the cases where this might
buy you any benefit are just too uncommon, and the 'benefit' is just too
small.
The one place where any of this would (sort of) be useful is checking
for the "cc" clobber conflicting with the output parameters. This
didn't used to be a thing, but now that i386 can 'output' flags, it is.
The compiler currently accepts both of these and they both produce the
same code:
asm("": "=@ccc"(x) : : );
asm("": "=@ccc"(x) : : "cc");
I assert (pr69095) that the second one should give an error (docs:
"Clobber descriptions may not in any way overlap with an input or output
operand"). Creating a check for this was more challenging than I
expected. I kept assuming that there 'had' to be existing code to
handle cc and I could tie into it if I could only figure out where it was.
But now that I have this written, I'm still vacillating about whether it
is useful. It seems like I could achieve the same result by adding
"Using @cc overrides the "cc" clobber" to the docs. But hey, it also
checks for duplicate "memory" and "cc" clobbers, so there's that...
dw
