[cfe-dev] A question on register allocation

[James Y Knight via cfe-dev]

To be clear: I don't think this feature actually makes sense for any normal
userland code. The list of caveats is so large that probably the only place
it might make sense at all is in a kernel. And since apparently the linux
kernel decided not to use it, it's probably not worth implementing, anyways.

That said, I still don't actually think there's any real complication here,
even after briefly scanning a couple recent threads. A user-reserved
register isn't fundamentally any different than any other target-reserved
register. Said list is already computed separately per-MachineFunction.
This has basically nothing to do with the multiple varied register
allocators, and requires no additional functionality in them. Obviously,
reserving registers will make the generated code worse due to fewer
registers being available, and if you reserve too many registers, you'll
have a Bad Time. Don't do that.

I really think it'd be very nearly trivial to implement something which is
at the same level of usefulness as GCC's version of this. It's just that
that level of usefulness is pretty low.

On Mon, Oct 5, 2015 at 5:07 AM, Renato Golin <renato.golin at linaro.org>
wrote:

> On 5 October 2015 at 01:48, James Y Knight via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
> > I don't think it'd actually be terribly difficult: every target already
> has
> > a list of target-specific reserved registers that are setup by
> > TargetRegisterInfo::getReservedRegs(const MachineFunction &). Merging
> that
> > builtin set with an set of "extra" reserved registers attached to a
> > MachineFunction seems like it'd be easy enough.
>
> It's not about the implementation, but the side effects. There has
> been enough discussions on this topic already as a quick search on the
> mailing list will show. One may be able to persuade people to accept
> it, but this argument above is the first that everyone uses when the
> threads start (I have used that, too, myself), and it never works.
>
> So, unless someone comes with a rock solid investigation on all the
> side effects on the multiple register allocators and the side effects
> on code generation and low-level optimizations for all affected
> targets, people will look away. :)
>
>
> > Of note for the use-case given here: there are no callee-saved xmm
> registers
> > in the sysV ABI. So, unless you re-compile *everything* linked into your
> > binary with the reserved register (including libc, dynamic linker,
> compiler
> > runtime support library, etc.) and validate that no asm code in any of
> those
> > clobbers it either, you can't be guaranteed that the value will always be
> > preserved -- even if clang has this feature.
>
> Precisely. :)
>
>
> > On Oct 4, 2015, at 2:06 PM, mats petersson via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
> > Your problem here is that you also need to "remove" your chosen register
> > from the list of registers the compiler may use for other purposes. As
> far
> > as I understand, there's no infrastructure to "remove this register
> ALWAYS",
> > so you'll most likely need to do a fair bit of changes - I'm not familiar
> > with this particular bit of code, but it's obviously an ugly/difficult
> > enough solution that for the "make Linux compile with Clang" was solved
> by
> > "remove use of global registers", except for "stack pointer" (Stack
> pointer
> > is OK, since compiler will not use that register for anything other than
> "as
> > stack pointer").
>
> Precisely++. :)
>
> cheers,
> --renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151005/c330f60d/attachment.html>