This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/62217] [4.9/5 Regression] DOM confuses complete unrolling which in turn causes VRP to warn


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62217

--- Comment #9 from Jeffrey A. Law <law at redhat dot com> ---
Yes, any particular choice has the potential to regress in one way or another. 
These are heuristics after all.  We're just looking for a reasonable refinement
if we can find one.

Dominance doesn't seem to be the right thing to be looking at to me since the
crux of this issue is propagating the "copy" implied by the equality comparison
just changes what SSA_NAME we reference and as a result ultimately hides stuff
from later passes.  It doesn't (in this case) enable further simplifications or
for either SSA_NAME to become unused.  A dominance test between the args of the
equality comparison just doesn't seem helpful here.

In fact, because both names are used in the equality test, these propagations
can never cause an SSA_NAME to become unused.  At best the propagation will
expose some further simplification on one of the paths or it will result in one
SSA_NAME having a single use (the comparison).  We have no good way of guessing
if the former will happen, but we can encourage the latter.

But as I mentioned earlier, I really wonder if we should allow these context
sensitive equivalences to be expressed in the gimple if they didn't prove
useful.  And that was the whole purpose behind uncprop -- to find context
sensitive propagations that ultimately didn't prove useful and which result in
poor coalescing or unwanted constant initializations and un propagate them.

It wouldn't directly help this problem because the use is in a normal
statement, but it's definitely closely related and it wouldn't be hard to
repurpose that code.  In fact, it might be a good thing to do in general.

Essentially what it's doing is building a map of values back to SSA_NAMEs which
hold those values by way of an equality comparison.  At each use of the value,
we can look at the list of SSA_NAMEs that hold that value and select the one
that appears to be least cost based on whatever metrics we see fit.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]