<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 10, 2015 at 3:38 PM, Hal Finkel via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
> >You're right that we don't really want infinite register classes,<br>
> >but rather, we<br>
> >want "expandable" ones. Making extra-large register classes that are<br>
> >restricted by having most of the registers in the reserved set,<br>
> >however,<br>
> >seems just as much a hack (and a worse one in many ways).<br>
><br>
> Whether it’s a hack or not depends on the sizes in question. Existing<br>
> X86 already has this property for 64 bit, there are registers which<br>
> simply don't exist<br>
> unless the target arch is 64 bit.  If WebASM folks are thinking of<br>
> allocating down to something like 32 or 64 registers, with maybe a<br>
> maximum of 128 or 256, then<br>
> making some portion of this reserved when a tighter allocation (only<br>
> coloring to 16 or 32) seems completely doable (and natural) using<br>
> all existing infrastructure, with nothing<br>
> special needed.<br>
<br>
</div></div>No argument from me on this point, however, whether or not a relatively-small fixed number is acceptable I don't know. What does seem to be the case, however, is that they need some kind of register use cost function which makes the use of each new register increasingly expensive and/or the ability to dynamically change the number of registers that are reserved at any given time. The former is probably better.<br></blockquote><div><br></div><div>A relatively-small fixed number is indeed not acceptable. We have a virtual ISA which is general-purpose and is not inherently afraid of having thousands of registers and perhaps more, if that's what the program actually needs. We do use coloring to reduce the number as we can, but coloring can't always fix everything without spilling.<br><br></div><div>And whether we ever have LLVM spill, as opposed to just using more registers, is a decision we'd like to make based on the needs of the platform, not based on any limitations of LLVM. Right now, the working assumption is that LLVM should not spill.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><br>
> If getting into significantly larger numbers, then I<br>
> can see where this might be considered a hack.  But unless you are<br>
> talking about multi-thousands,<br>
> it does beg the question about what the extra generality is worth<br>
> compared to the engineering effort to design, implement and support<br>
> it.<br>
<br>
</span>This is exactly why I was in favor of reusing the existing infrastructure for virtual registers.<br></blockquote><br></div><div class="gmail_quote">The virtual register infrastructure in LLVM turns out to be a very close fit for our needs. The main alternative is effectively to take LLVM's physical register concept and evolve it in the direction of being more like its virtual register concept in several significant ways. It's not clear that LLVM should really want two different concepts with so much similarity, but also numerous subtle differences.<br><div><br></div><div>Dan<br><br></div></div></div></div>