This updates NewGVN test cases that were running
"opt -basic-aa -newgvn ..."
to run
"opt -passes=newgvn ..."
instead.
The pipeline will be more similar to what we used to have with
legacy PM by doing it this way. The compatility mode that we've
been using for awhile during transition from legacy PM to new PM,
i.e. using the legacy syntax together with new PM, has resulted in
a pipeline such as
-passes='function(require<basic-aa>),function(newgvn)'
but running the analysis in a separate function pass manager seem
overly complicated for these tests.
Another difference is that we will get the default aa-pipeline instead
of only running basic-aa. That might be a bit questioned (given that
the tests originally specified basic-aa). The output is however
identival for all the test cases modified here regardless of using
basic-aa or the default aa-pipeline.
This is also another small step towards removal of the support for
using the legacy PM syntax in opt.
Differential Revision: https://reviews.llvm.org/D118340
As it's causing some bot failures (and per request from kbarton).
This reverts commit r358543/ab70da07286e618016e78247e4a24fcb84077fda.
llvm-svn: 358546
Summary:
This rewrites store expression/leader handling. We no longer use the
value operand as the leader, instead, we store it separately. We also
now store the stored value as part of the expression, and compare it
when comparing stores for equality. This enables us to get rid of a
bunch of our previous hacks and machinations, as the existing
machinery takes care of everything *except* updating the stored value
on classes. The only time we have to update it is if the storecount
goes to 0, and when we do, we destroy it.
Since we no longer use the value operand as the leader, during elimination, we have to use the value operand. Doing this also fixes a bunch of store forwarding cases we were missing.
Any value operand we use is guaranteed to either be updated by previous eliminations, or minimized by future ones.
(IE the fact that we don't use the most dominating value operand when it's not a constant does not affect anything).
Sadly, this change also exposes that we didn't pay attention to the
output of the pr31594.ll test, as it also very clearly exposes the
same store leader bug we are fixing here.
(I added pr31682.ll anyway, but maybe we think that's too large to be useful)
On the plus side, propagate-ir-flags.ll now passes due to the
corrected store forwarding.
This change was 3 stage'd on darwin and linux, with the full test-suite.
Reviewers:
davide
Subscribers:
llvm-commits
llvm-svn: 292648
