[LLVMdev] Named register variables GNU-style

Renato Golin renato.golin at linaro.org
Thu Mar 27 06:55:47 PDT 2014


Folks,

I just had a discussion about __builtin_stack_pointer in the GCC list,
and there were a number of arguments against it, and it got me
thinking I didn't have strong arguments against GNU's named register
extension. Does anyone remember the arguments for not implementing
that extension?

My view is that making it an intrinsic (say @llvm.register(name))
would have the exact same semantics as __builtin_<register_name> has,
in that it'll be carried down all the way to SelectionDAG and be just
a CopyFromReg from that reg's name.

The fact that they remain as intrinsics will guarantee that they will
last until SelectionDag and not commoned up or heavily modified. I'm
not sure how to make Clang do that, but it shouldn't be too hard to
short-circuit the asm handler if we're dealing with a
declaration/instantiation and "register" is a specifier of the type.

The arguments supporting the builtins is that, in case of stack
pointer, it's not target specific, thus avoiding ifdefs. The
counter-argument is that most usage of the named register extension is
already target specific (together with everything around it), so that
extra value is very limited. Also, since kernel and library code
(heavy users of named registers) will have to support old compilers,
this will *have* to be ifdefd anyway.

The arguments against builtins are that named register is more
generic, is already in use for more than the stack pointer and is
reasonably straightforward to both understand and implement.

Both builtins and named registers don't give you the guarantees that
you would like from such a high-level construct, and users are already
aware that this is the case, so we don't have to worry that much about
it.

Also, reading back some comments, it seems that the biggest concern
was that inline asm wasn't really a first-class citizen in the LLVM
back-end, but I think that has changes with M, right?

My questions are:

1. Were the initial concerns dealt with by the introduction of MC?

2. Is there any remaining argument against named registers that
stronger than the ones supporting it?

3. Is my draft for implementing named registers acceptable?

cheers,
--renato



More information about the llvm-dev mailing list