[cfe-commits] r122643 - in /cfe/trunk: lib/CodeGen/CGDecl.cpp lib/CodeGen/CGStmt.cpp test/CodeGen/asm-variable.c

Benjamin Kramer benny.kra at googlemail.com
Fri Dec 31 11:34:46 PST 2010


On 31.12.2010, at 05:34, Jakob Stoklund Olesen wrote:
> On Dec 30, 2010, at 4:08 PM, Benjamin Kramer wrote:
>> 
>> I'm not very happy with this fix. Using such a pinned variable with inline asm looks like an edge case.
> 
> It is all that is required for local variables, see http://gcc.gnu.org/onlinedocs/gcc/Local-Reg-Vars.html
> 
>> Most code (e.g. ruby 1.9) uses this as a (premature) optimization so it shouldn't hurt there but on the other hand
>> the linux kernel uses this extension to access the stack pointer like a variable.
>> 
>> register unsigned long current_stack_pointer asm("esp");
>> foo = current_stack_pointer;
> 
> Presumably this is a global variable, otherwise it could legally be compiled to:
> 
>  foo = undef
> 
> I think we can support global variables like this one by replacing all reads and writes with empty inline assembly statements.
> 
> That will work for reserved registers like %esp. As for using allocatable registers for global variables, I really hope we can avoid that.

Okay, the kernel indeed uses a global variable and that still gives an error with clang.
Sorry for the noise. *phew*

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.



More information about the cfe-commits mailing list