This is an archive of the discontinued LLVM Phabricator instance.

[PHIElimination] Lower a PHI node with only undef uses as IMPLICIT_DEF
ClosedPublic

Authored by bjope on Sep 26 2018, 9:20 AM.

Details

Summary

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.

Diff Detail

Repository
rL LLVM

Event Timeline

bjope created this revision.Sep 26 2018, 9:20 AM

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.

MatzeB accepted this revision.Sep 27 2018, 9:26 AM

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
225–226 ↗(On Diff #167152)

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;
}
This revision is now accepted and ready to land.Sep 27 2018, 9:26 AM
MatzeB added inline comments.Sep 27 2018, 9:28 AM
lib/CodeGen/PHIElimination.cpp
225 ↗(On Diff #167152)

how about naming this allPhiOperandsUndefined?

bjope added a comment.Sep 28 2018, 8:35 AM

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

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?

bjope updated this revision to Diff 167486.Sep 28 2018, 8:39 AM

Minor refactoring/renaming as suggested by Matze.

bjope marked 2 inline comments as done.Sep 28 2018, 8:41 AM

Minor refactoring/renaming as suggested by Matze.

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

jsji removed a subscriber: jsji.Sep 28 2018, 9:22 AM
bjope added a comment.Sep 28 2018, 9:36 AM

Minor refactoring/renaming as suggested by Matze.

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!

This revision was automatically updated to reflect the committed changes.