[llvm-dev] live-in lists during register allocation
Jonas Paulsson via llvm-dev
llvm-dev at lists.llvm.org
Tue Oct 15 07:11:43 PDT 2019
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
/// any of the successor blocks. If false is returned, Reg is
/// not be live out, although sub/super-registers are not checked.
/// 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?
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?
> 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()?
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
More information about the llvm-dev