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

Jonas Paulsson via llvm-dev
2019-09-24T13:15:46Z

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