[llvm-dev] live-in lists during register allocation
Jonas Paulsson via llvm-dev
llvm-dev at lists.llvm.org
Tue Sep 24 06:15:46 PDT 2019
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
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?
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:
>> 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()?
More information about the llvm-dev