[cfe-dev] [LLVMdev] Named register variables GNU-style

[Hal Finkel]

----- Original Message -----
> From: "Renato Golin" <renato.golin at linaro.org>
> To: "LLVM Dev" <llvmdev at cs.uiuc.edu>, "Clang Dev" <cfe-dev at cs.uiuc.edu>
> Sent: Thursday, March 27, 2014 8:55:47 AM
> Subject: [LLVMdev] Named register variables GNU-style
> 
> Folks,
> 
> I just had a discussion about __builtin_stack_pointer in the GCC
> list,
> and there were a number of arguments against it,

Can you summarize?

> 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.

I think this also would be a nice feature to have, and fairly straightforward to implement.

That having been said, are there not cases where only the backend knows in what register the stack pointer is held? A sophisticated backend might even spill the stack pointer during some portions of the function to create a range in which it was allocatable, and I certainly would not want to preclude such an implementation.

 -Hal

> 
> 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
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory