<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 10, 2015 at 2:46 PM Matthias Braun via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">To say this first: This whole discussion about using virtregs until emit or having growable physregs is hard to argue without actually having experience trying to go either way.<br></blockquote><div><br></div><div>Indeed, we are accumulating exactly this experience now, having started with VRegs, as that seems like a more natural fit conceptually. The problem is that we are essentially blocked on this (obviously lack of PEI/frameindex elimination blocks a lot of things) so in order to make further progress and get further experience we will need either a simple change something like the one proposed or to do what NVPTX did and just make our own copy of PEI.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Problems when using virtregs throughout the backend until emit time:<br>
- The MC layer is using MCPhysReg (which is an uint16_t) and would need retrofitting to support virtregs<br>
- VirtRegs are assumed to have a definition, physregs can appear "out of thin air" in some situations like function parameters, or exception objects appearing in a register when going to a landingpad.<br></blockquote><div><br></div><div>This is what Dan is trying to address with <a href="http://reviews.llvm.org/D14750" class="cremed">http://reviews.llvm.org/D14750</a>. The discussion on that change is essentially the same as the one going on here.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- VirtRegs are assumed to be interchangeable, replaceing vreg5 with vreg42 shouldn't affect the program semanic (given they both have the same register class and we have no other defs/uses of vreg42), if you use virtregs for parameter passing this won't be true anymore<br></blockquote><div><br></div><div>I believe this would be addressed for wasm with a mechanism like that in D14750 (or the current special ARGUMENT pseudos we have now) in combination with the fact that we remap the virtual registers into a different number space in a way that takes the arguments into account, just before emission.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- regmask clobbers only affect physregs<br>
(- You cannot reuse the existing regalloc infrastructure, but IMO that's not a good idea anyway for virtual ISAs)<br></blockquote><div><br></div><div>Agreed.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Problems when allowing the dynamic creation of physregs:<br>
- The current assumption of all register being known at tbalegen time will mean that we probably need bigger changes to support dynamically growing physreg lists and it may take a while until we have flushed out all places that relied on a fixed-register number assumption.<br></blockquote><div><br></div><div>This seems like a really big deal to me; plus a lot of the discussion above e.g. with regard to what the behavior of the pysical register classes, is about properties which are really only relevant for register allocation (and again I think we agree that we probably don't want to be using the normal register allocator anyway).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- You probably do not want to compute/modify some information like register class subsets/supersets. However as far as I can see we do not need subregister support for the virtual ISA usecase and may be fine just not allowing the combination of subregs with dynamic physreg creation.<br>
<br></blockquote><div>I think you are right.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Non-Issues:<br>
- Liveness calculation should work as well with virtregs as with physregs<br>
<br>
All in all it seems to me like using virtregs until emission time may take less engineering effort to a point where it is 95% working, but will be a pain to maintain in the long term because we suddenly have physreg like semantics on virtregs for some targets (but not for "normal" ones).<br><br></blockquote><div><br></div><div> Perhaps it would be worthwhile to flesh out a bit more precisely what semantics are required.</div></div></div>