llvm dev - Mar 2014 - [LLVMdev] Named register variables GNU-style

On 28 March 2014 02:06, Rafael Espíndola <rafael.espindola at gmail.com>
wrote:
> Correct. The proposed solution would work for all non allocatable
> registers. We should probably still err if someone tries to use an
> allocatable one.
AFAIK, GCC reserves the allocatable registers. If we're going to do
this we'd have to be as close as possible to the current behaviour to
avoid surprises.

--renato

On Fri, Mar 28, 2014 at 2:31 AM, Renato Golin <renato.golin at
linaro.org>wrote:
> On 28 March 2014 02:06, Rafael Espíndola <rafael.espindola at
gmail.com>
> wrote:
> > Correct. The proposed solution would work for all non allocatable
> > registers. We should probably still err if someone tries to use an
> > allocatable one.
>
> AFAIK, GCC reserves the allocatable registers. If we're going to do
> this we'd have to be as close as possible to the current behaviour to
> avoid surprises.

This has been the long standing historical objection to the feature. It is
a *really* invasive change to the register allocator to plumb this kind of
register reservation through it. Worse, the semantics for it being
inherently translation-unit based become deeply confusing in LLVM due to
the potential for (partial) LTO.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140328/66ba9378/attachment.html>

On 28 March 2014 10:17, Chandler Carruth <chandlerc at google.com>
wrote:
> This has been the long standing historical objection to the feature. It is
a
> *really* invasive change to the register allocator to plumb this kind of
> register reservation through it.
Do you mean only the reserved part or the general named register idea?

About reserving registers, we already have the ability to reserve
certain registers (R9 on ARM, for instance), so it should not be too
hard to reserve arbitrary registers.

As far as I could find looking backwards, there were many more
impediments back then. The inability to represent this in IR
correctly, the idea that it should be part of the language (not an
intrinsic) thus breaking optimisation rules, the lack of inline asm
knowledge in the back-end (fixed by MC and IAS), and the lack of
register reservation mechanisms (which we have today).

So, while I appreciate there is vast historical reasons to not support
it, otherwise Mark and Behan would not have gone that far convincing
us of the __builtin_stack_pointer in the first place, I believe that,
not only the harder technical problems have being fixed by now, but
the arguments towards builtins are less technically valid than the
ones supporting named registers.


> Worse, the semantics for it being
> inherently translation-unit based become deeply confusing in LLVM due to
the
> potential for (partial) LTO.
I don't know LTO well enough to answer that, maybe Rafael can chime in.

But ultimately, this particular feature is draconian in itself, and
the GCC docs describe lots of cases where it's not safe to use it.
This, and the clear_cache builtins, are particularly dangerous but
necessary extensions to implementing low level bare-metal code while
keeping the code in a manageable level (C-land).

We can only guarantee behaviour that is described in the standards we
implement. Anything else may have value but still be unsafe in certain
conditions, and in that category we have undefined behaviour,
implementation defined behaviour and extensions. It's not because a
few things might break that we don't use it, and undefined behaviour
is a particularly dangerous field that we all thread happily on a day
to day basis. Extensions shouldn't be different.

cheers,
--renato