[gvn] Handle simply phi equivalence cases
authorPhilip Reames <listmail@philipreames.com>
Sat, 6 Mar 2021 17:27:19 +0000 (09:27 -0800)
committerPhilip Reames <listmail@philipreames.com>
Sat, 6 Mar 2021 17:31:12 +0000 (09:31 -0800)
commit5db2735af91be3bfb2fcb06bf8e1ac5f7d1e4812
tree5d74a2fa31c49ac321fd57ead8a15d5d4c60b335
parent15fdd536f9217d4ccc1bb2f5531268cfab5ea846
[gvn] Handle simply phi equivalence cases

GVN basically doesn't handle phi nodes at all. This is for a reason - we can't value number their inputs since the predecessor blocks have probably not been visited yet.

However, it also creates a significant pass ordering problem. As it stands, instcombine and simplifycfg ends up implementing CSE of phi nodes. This means that for any series of CSE opportunities intermixed with phi nodes, we end up having to alternate instcombine/simplifycfg and gvn to make progress.

This patch handles the simplest case by simply preprocessing the phi instructions in a block, and CSEing them if they are syntactically identical. This turns out to be powerful enough to handle many cases in a single invocation of GVN since blocks which use the cse'd phi results are visited after the block containing the phi. If there's a CSE opportunity in one the phi predecessors required to recognize the phi CSE opportunity, that will require a second iteration on the function. (Still within a single run of gvn though.)

Compile time wise, this could go either way. On one hand, we're potentially causing GVN to iterate over the function more. On the other, we're cutting down on iterations between two passes and potentially shrinking the IR aggressively. So, a bit unclear what to expect.

Note that this does still rely on instcombine to canonicalize block order of the phis, but that's a one time transformation independent of the values incoming to the phi.

Differential Revision: https://reviews.llvm.org/D98080
llvm/lib/Transforms/Scalar/GVN.cpp
llvm/test/Transforms/GVN/phi.ll