[PATCH] D52558: [PHIElimination] Lower a PHI node with only undef uses as IMPLICIT_DEF

[Bjorn Pettersson via Phabricator via llvm-commits]

bjope added a comment.

In https://reviews.llvm.org/D52558#1248133, @MatzeB wrote:

> The patch on its own makes sense to me, so LGTM (comment below).
>
> I didn't know `PHIElimination` looks for `IMPLICIT_DEF`s, 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?


Repository:
  rL LLVM

https://reviews.llvm.org/D52558