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