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

[Chandler Carruth]

On Thu, Dec 30, 2010 at 4:08 PM, Benjamin Kramer
<benny.kra at googlemail.com>wrote:

> Using such a pinned variable with inline asm looks like an edge case.
>

Actually, I've seen this frequently in real C++ code is leading into a an
inline assembly block and trying to setup registers ahead of time. It's
required to work around a number of issues. Older GCCs used to only allow a
small number of inline asm inputs / outputs, and so this would be used to
grow that slightly in some code that was written to that legacy compiler.
Rafael encountered code where this is used to pin registers for which no
clear register constraint exists on the x86-64 platform. Perhaps this is
just a difference of what C++ code we're looking at...


> Most code (e.g. ruby 1.9) uses this as a (premature) optimization so it
> shouldn't hurt there
>

Agreed, this is the most common, and to my eyes the most important concern:
I actually really *really* like the fact that we accept and utterly ignore
the suggestion. ;] I would love to see a warning for this behavior however.
Thoughts Rafael? I'm imagining something similar to the unused variable
warning, and warn when the variable goes out of scope if it was never in
fact used as an input to inline assembly.


> 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;
>
> We used to error out on this, now we treat it like normal stack variable
> and miscompile the code.
>

I've never seen this construct, but then I've never worked on the kernel. =/
This is really frustrating, because the ways I can think of to make this use
case work correctly basically boil down to turning every access to the
variable into the equivalent inline assembly to access the register. I have
a feeling this would play havoc with LLVM's optimizers, and it would
certainly pessimize all the code you mentioned above that use this merely as
an "optimization".

What if we made it an error to access a register variable which is
explicitly declared as referring to the stack pointer or other "special"
registers that could reasonably be assumed to have meaningful values when
accessed in this manner?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20101230/566f3c59/attachment.html>