On Dec 31, 2010, at 11:34 AM, Benjamin Kramer wrote: > To sum this up, should we consider using local register vars outside of asm > statements > unsafe and just ignore them (as we do now)? While GCC supports them to some > extent I don't > think it's worth to support it just to enable some premature optimizations. > We don't even > need a warning in that case.
There are three cases:
1. Pinned local variables are treated no differently than normal local
variables except when they are used as operands for inline asm. This is what
Rafael's patch implements. I suppose you could warn if such a variable is never
used for inline asm.
2. Global variables pinned to a reserved register. This is just an odd way of
accessing a register, and it is fairly easy to support in the front end by
emitting empty inline asm instead of reads and writes to the global.
3. Global variables pinned to an allocatable register. For this to work, the
backend must treat the pinned register as reserved, effectively changing the
calling convention of all functions in the compilation unit. Other compilation
units would have to be built with -ffixed-reg. I really don't want to support
this if it can at all be avoided.
It is very hard for the frontend to distinguish between 2. and 3., it would
have to know if a register is reserved. Even the backend has a hard time
telling when %ebp (the frame pointer) is reserved.
I think we should consider not supporting pinned global variables, and instead
provide a way of reading and writing specific registers with inline asm
constraints.
Instead of:
register unsigned long current_stack_pointer asm("esp");
foo = current_stack_pointer;
We could permit:
asm ("" : "={esp}"(foo));
The curly brace syntax for inline asm constraints also obsoletes pinned local
variables.
/jakob
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
