[llvm-dev] Allowing virtual registers after register allocation

[Quentin Colombet via llvm-dev]

> On Jan 22, 2016, at 1:52 PM, Matthias Braun <mbraun at apple.com> wrote:
> 
>> 
>> On Jan 22, 2016, at 1:44 PM, Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote:
>> 
>>> 
>>> On Jan 22, 2016, at 1:23 PM, Matthias Braun <mbraun at apple.com <mailto:mbraun at apple.com>> wrote:
>>> 
>>>> 
>>>> On Jan 22, 2016, at 12:29 PM, Derek Schuff <dschuff at google.com <mailto:dschuff at google.com>> wrote:
>>>> 
>>>> Here are 2 patches, which are independent of each other.
>>>> 
>>>> The first splits PrologEpilogInserter into 2 parts : http://reviews.llvm.org/D16481 <http://reviews.llvm.org/D16481>
>>>> After looking at the code I thought it made more sense for the major split to include whether callee-saved register spills are supported. So for non-virtual targets, virtual registers are not supported and scavenging is optionally supported, and vice versa for virtual targets. The base case includes just frame finalization, prolog/epilog code insertion and FrameIndex elimination. The CSR-supporting case includes CSR spilling and optionally scavenging.
>>>> It's a little bit ugly because e.g. most of the target hooks (even those used in the core pieces like FI elimination) take a pointer to a RegScavenger object which could be null, and there's still a little bit of code in the FI elimination code that takes CSR spilling into account. But I do think it is an improvement, and I'd be interested in feedback. This patch could be ready to land if people are happy with the design.
>>>> 
>>>> The other (http://reviews.llvm.org/D16483 <http://reviews.llvm.org/D16483> )is the aforementioned prototype for requiring MachineFunctionPasses to opt-in to supporting virtual registers. It's only done for WebAssembly and X86 so far as a proof of concept. The interesting bit to look at is the way it's implemented (right now it's just a virtual method that's called inside an assert which can be compiled away) and the passes that will opt-in. It's mostly a concrete version of the info I put in my previous post. Before it lands I'll have to update the rest of the targets, and will probably manually expand the SUPPORTS_VIRTUAL_REGISTERS macro which I used for my experimental convenience (unless you think it's actually better that way).
>>> Thanks for working on this.
>>> 
>>> In my opinion the important thing with the (not) supporting vregs in a pass was that I would have liked to make it explicit if a target wants to use vregs after regalloc.
>> 
>>> This way we can actually differentiate the cases where vregs appear after register allocation because of a bug and the case where they are intentional. The important thing would be to add something like MachineRegisterInfo::setVirtRegsAfterRegalloc() and MachineRegisterInfo::getVirtRegsAfterRegalloc(). Because I would assume that we will find more examples like the following (from MachineBasicBlock):
>>> 
>>>   void addLiveIn(MCPhysReg PhysReg, LaneBitmask LaneMask = ~0u) {
>>>     LiveIns.push_back(RegisterMaskPair(PhysReg, LaneMask));
>>>   }
>>> 
>>> this needs to be changed to support VRegs. But if we do that change, I'd like to change it to something like this:
>>> 
>>>   void addLiveIn(unsigned Reg, LaneBitmask LaneMask = ~0u) {
>>>     assert(TargetRegisterInfo::isPhysReg(Reg) || getParent()->getRegInfo().getVirtRegsAfterRegalloc());
>>>     LiveIns.push_back(RegisterMaskPair(Reg, LaneMask));
>>>   }
>> 
>> I haven’t looked at the patch, just commenting on that example. My understanding was that supporting both virtual and physical registers should not have any impact on anything else, but the pass itself. I.e., if the pass updates the liveIns, in that example, it does that only for physical registers. I.e., we do not push for changes like this.
> Without changing addLiveIn you will not be able to use something like the RegisterScavenger or LivePhysRegs (or rather an equivalent to those two that supports virtual registers).

That is the thing, if we need it, that probably means this pass does not support virtual registers.

> This is probably not needed today but I'm pretty sure we will find more minor things in common infrastructure that need to be updated to support virtregs along physregs (a different example would be http://reviews.llvm.org/D14750 <http://reviews.llvm.org/D14750>). I don't expect any huge changes in the common infrastructure but enough that I would like to be able to write an assert like in my example above.

Fair enough, but I’d rather decide when we see an actual use for that.

Q.
> 
> - Matthias

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160122/6b4498f8/attachment.html>