The lowering of PHI nodes used to detect if all inputs originated
from IMPLICIT_DEF's. If so the PHI node was replaced by an
IMPLICIT_DEF. Now we also consider undef uses when checking the
inputs. So if all inputs are implicitly defined or undef we
lower the PHI to an IMPLICIT_DEF. This makes
PHIElimination::LowerPHINode more consistent as it checks
both implicit and undef properties at later stages.
Details
Diff Detail
- Repository
- rL LLVM
- Build Status
Buildable 23243 Build 23242: arc lint + arc unit
Event Timeline
This is slightly related to https://bugs.llvm.org/show_bug.cgi?id=39085, but this patch is supposed to focus on getting IMPLICIT_DEF when all PHI inputs are undefined.
The PR is about the problem with updating "killed" that is mentioned in the "bar" part of the test case.
The patch on its own makes sense to me, so LGTM (comment below).
I didn't know PHIElimination looks for IMPLICIT_DEFs, do you have an idea why that is given that we run ProcessImplicitDefs immediately before PHIElimination and it has a rule to eliminate phi-nodes with all implicit-def inputs too...
lib/CodeGen/PHIElimination.cpp | ||
---|---|---|
224–225 | If we touch this function anyway, should we take the opportunity to switch to a more modern style: static bool isSourceUndefined(const MachineInstr &MPhi, const MachineRegisterInfo &MRI) { for (unsigned I = 1, E = MPhi->getNumOperands(); I != E; I += 2) { const MachineOperand &MO = MPhi->getOperand(I); if (!isImplicitlyDefined(MO.getReg(), MRI) && !MO.isUndef()) return false; } return true; } |
lib/CodeGen/PHIElimination.cpp | ||
---|---|---|
224 | how about naming this allPhiOperandsUndefined? |
Probably because ProcessImplicitDefs only is used for optimized regalloc (we do not add that pass in TargetPassConfig::addFastRegAlloc). So for "fast" we still have lots of IMPLICIT_DEF:s lingering around.
For "optimized" we run ProcessImplicitDefs (remove lots of IMPLICIT_DEF:s and propagate undef to uses) before PHIElimination, so this is when we can find undef instead of IMPLICIT_DEF on the PHI inputs.
ProcessImplicitDefs could be taught to also consider a PHI with only undef inputs as an IMPLICIT_DEF (and the same for COPY/INSERT_SUBREG/REG_SEQUENCE). That way we could clean up even more things already before PHIElimination in the optimized pipeline. Now the IMPLICIT_DEF inserted by PHIElimination isn't eliminated in the same way as if we had executed ProcessImplicitDefs after PHIEliminiation (which currently isn't possible since ProcessImplicitDefs requires SSA).
On the other hand, I don't know how important it is to eliminate IMPLICIT_DEF:s. The Coalescer and RegAlloc need to know about IMPLICIT_DEF:s, so isn't copies of undefined values removed anyway? So why do we run ProcessImplicitDefs at all?
BTW: This is still good to go, no need for further review. (I often approve patches with small issues remaining in cases where I trust the author to address the small issues correctly).
Great, I kind of imagined that it was good to go, but wanted to publish my pre-commit updates anyway (I do not have time to monitor build bots today so I'll commit this later).
Thanks for the review!
how about naming this allPhiOperandsUndefined?