live-in lists during register allocation


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()?



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

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?



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?