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

dalej dalej at apple.com
Mon Jan 3 14:48:25 PST 2011


I was on vacation during this this thread, sorry.  I'm the one who has been (sporadically) fixing this in llvm-gcc.  As of 119392 I believe local asm variables are correct there.

On Jan 1, 2011, at 12:15 PM, Jakob Stoklund Olesen wrote:
> On Dec 31, 2010, at 7:05 PM, Chris Lattner wrote:
>> On Dec 31, 2010, at 12:43 PM, Jakob Stoklund Olesen wrote:
>>> 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.
>> […]

Also, the register is not pinned to the variable.  It is available for normal allocation except around asm statements.

>>> 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.
>> 
>> Right, llvm-gcc does this.  This is vaguely bogus but it is (obviously) used and useful to support.
>> 
>>> 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.
>> 
>> […]

Currently, the IR doesn't support a way of representing this.  It doesn't work in llvm-gcc, and I agree it would be good to avoid doing it.

I haven't looked at the patches, but clang should generate the same thing llvm-gcc generates for the same constructs.  If you do that it will work; if you do anything else you'll probably hit subtle bugs.

>> Interestingly enough, GCC emits a warning:
>> 
>> $ cat t.c
>> register int foo asm("rax");
>> void f() {
>>   foo = 42;
>> }
>> 
>> t.c:1: warning: call-clobbered register used for global register variable
> 
> Yes, the documentation says that you should only use callee-saved registers, otherwise any library function you call will clobber your global.
> 
>> My opinion is that the warning is a (really low priority) QoI issue and that we should implement #2 and forget about people who get burned with #3.
> 
> I'm fine with that, but it does mean that we silently miscompile #3 because the register can be allocated normally.
> 
>> We should not implement -ffixed-reg if possible IMO, though it has been discussed on llvmdev as useful for people who have GC'd languages etc, and I vaguely recall the Haskell folks doing some work in this area.  To do this right we'd have to do something like this:
>> http://nondot.org/sabre/LLVMNotes/GlobalRegisterVariables.txt
> 
> I would prefer that approach too. It lets the register allocator decide if the register global is really more important than all the locals it interferes with.
> 
>>> We could permit:
>>> 	asm ("" : "={esp}"(foo));
>>> The curly brace syntax for inline asm constraints also obsoletes pinned local variables.
>> 
>> Lets not extend GCC assembly syntax anymore! :)
> 
> Yeah, fair enough.
> 
> /jakob
> 
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20110103/fa95df17/attachment.html>


More information about the cfe-commits mailing list