[llvm-dev] live-in lists during register allocation

[Jonas Paulsson via llvm-dev]

Hi,

I have proposed a patch to address the issue discussed previously about 
the live-in lists and their trustworthiness. In short, some 
optimizations depend on checking if a physical register is live out of 
MBB and this should preferably be the case only if that register is in 
one of MBBs successors live-in list. The SystemZ backend does this check 
in SystemZElimCompare.cpp:isCCLiveOut(), but it would have been much 
preferred to have this done by a method in common-code. Note that this 
is now intended for use for a non-allocatable, non-reserved register and 
does not depend on or help register allocation.

My patch adds a check for the live-through case of live-in lists in the 
MachineVerifier and moves the method that checks the live-in lists of 
the successors to MachineBasicBlock:

   /// Return true if the specified physical register is in the live in 
set of
   /// any of the successor blocks. If false is returned, Reg is 
guaranteed to
   /// not be live out, although sub/super-registers are not checked. 
This can
   /// be called both before and after regalloc.
   bool isLiveOut(MCRegister PhysReg) const;

I would like to know if anyone would be in favor of having this here 
with a stated guarantee as in the comment, or if there are any 
objections to it?

https://reviews.llvm.org/D68267

/Jonas



On 2019-09-24 15:15, Jonas Paulsson via llvm-dev wrote:
> Hi Matthias,
>
> I have come back to this issue again of trusting live-in lists during 
> a call to foldMemoryOperandImpl(). You answered in June "... They were 
> intended only for post-ra passes and are only setup during the final 
> rewriting pass".
>
> I would like to clarify further by asking if this answer generally 
> relates to the allocated phys-regs being added to live-in lists by 
> VirtRegRewriter? What then about a non-allocatable register?
>
> I see that the MachineVerifier reports an error if there is a user of 
> the CC phys-reg without a previous def in the MBB, or an entry for CC 
> in the live-in list of the MBB. This makes it reasonable to assume 
> that physregs are expected to be present in the live-in list if there 
> is indeed a user of a live-in value. Since CC is non-allocatable it 
> also seems that this shouldn't really be different before or after 
> regalloc, or?
>
> Is there any explicit guarantee for this anywhere so that this can be 
> relied on? Given the MachineVerifier check, this ought to be the case, 
> or? If not, could we add this somewhere in the documentation?
>
> /Jonas
>
> On 2019-06-19 15:21, Matthias Braun wrote:
>> The per-block live-in lists? No. (assuming things have changed since 
>> last year).
>>
>> They were intended only for post-ra passes and are only setup during 
>> the final rewriting pass.
>>
>> - Matthias
>>
>>> On Jun 18, 2019, at 10:12 PM, Jonas Paulsson 
>>> <paulsson at linux.vnet.ibm.com> wrote:
>>>
>>> Hi,
>>>
>>> I wonder if live-in lists can be trusted to be accurate during 
>>> register allocation / foldMemoryOperandImp().
>>>
>>> On SystemZ, a compare register-register which has one of the 
>>> registers spilled can fold that reload into a compare 
>>> register-memory instruction. In order to do this also with the first 
>>> (LHS) register, the operands must be swapped. This can only 
>>> reasonably be done when all the CC users are in the same basic block 
>>> and so can be found in order to reverse their condition operands, 
>>> which must be done. The first check for this is to know if the CC 
>>> register is live into any successor block.
>>>
>>> I know there has been corrupt live-in lists in the past found, but I 
>>> think that was some passes after register allocation.
>>>
>>> Would it be safe to rely on live-in lists in foldMemoryOperandImpl()?
>>>
>>> Thanks,
>>>
>>> Jonas
>>>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev