<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 28, 2014 at 3:39 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"><div class="">On 28 March 2014 10:17, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:<br>

> This has been the long standing historical objection to the feature. It is a<br>
> *really* invasive change to the register allocator to plumb this kind of<br>
> register reservation through it.<br>
<br>
</div>Do you mean only the reserved part or the general named register idea?<br></blockquote><div><br></div><div>Just the reserved part.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
About reserving registers, we already have the ability to reserve<br>
certain registers (R9 on ARM, for instance), so it should not be too<br>
hard to reserve arbitrary registers.<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As far as I could find looking backwards, there were many more<br>
impediments back then. The inability to represent this in IR<br>
correctly, the idea that it should be part of the language (not an<br>
intrinsic) thus breaking optimisation rules, the lack of inline asm<br>
knowledge in the back-end (fixed by MC and IAS), and the lack of<br>
register reservation mechanisms (which we have today).<br></blockquote><div><br></div><div>I don't understand this paragraph. It seems wrong.</div><div>- 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.</div>
<div>- I don't recall anyone caring about "language" versus intrinsics.</div><div>- We have always had knowledge of the important part of inline asm: the constraints and clobbers. Neither MC nor IAS is relevant here.</div>
<div>- We don't have a generic register reservation mechanism today.</div><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">> Worse, the semantics for it being<br>
> inherently translation-unit based become deeply confusing in LLVM due to the<br>
> potential for (partial) LTO.<br>
<br>
</div>I don't know LTO well enough to answer that, maybe Rafael can chime in.<br>
<br>
But ultimately, this particular feature is draconian in itself, and<br>
the GCC docs describe lots of cases where it's not safe to use it.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This, and the clear_cache builtins, are particularly dangerous but<br>
necessary extensions to implementing low level bare-metal code while<br>
keeping the code in a manageable level (C-land).<br></blockquote><div><br></div><div>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.</div>
</div></div></div>