llvm dev - Jun 2019 - live-in lists during register allocation

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

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
>

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
>>