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

[Chandler Carruth]

On Fri, Mar 28, 2014 at 3:39 AM, Renato Golin <renato.golin at linaro.org>wrote:

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

Just the reserved part.


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

I don't understand how taking registers out of the allocation set within
the innards of the target definition itself is really comparable to making
some functions register allocate with one set of registers and other
functions register allocate with a different set of registers. I don't
think this example really means anything.


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

I don't understand this paragraph. It seems wrong.
- We have never (and still don't have) a representation for this in the IR.
But that's OK, the whole point has always been that such a representation
would be invented.
- I don't recall anyone caring about "language" versus intrinsics.
- We have always had knowledge of the important part of inline asm: the
constraints and clobbers. Neither MC nor IAS is relevant here.
- We don't have a generic register reservation mechanism today.

If you don't believe the last part, look at how many bugs and how much time
it has taken for developers to try to support the frame pointer register
usage on x86. That is actually the closest I know of to register
reservation, and it has been an endless source of complexity and bugs
despite not even needing to interact with the actual input code outside of
inline assembly constraints and clobbers.

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

And these seem like excellent reasons to not implement the dangerous
feature and instead to provide a significantly safer feature and direct
users either to not do the dangerous things, or if they are trying to do
the safe thing, use the feature which was designed for it.

Also, to reiterate, this email is about reserving allocatable registers,
not necessarily about every other way you might design global named
registers, such as restricting them to unallocatable registers. I still
think that is a silly way of representing things, but I don't have some
deep concern over its complexity. I *do* have deep concerns over the
complexity of making the register set essentially parameterized by user
code. I think that is madness.


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

Global named register variables which reserve allocatable registers are not
necessary for anything. Case in point, multiple operating systems today can
be built entirely using a compiler which doesn't support them, down to and
including their kernels. But I think your going overboard trying to sell
the importance of the general area when the objections are regarding
specific aspects of the implementation. No one is arguing that we shouldn't
support the concrete known use cases.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140328/f236a262/attachment.html>