https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34723
Jeffrey A. Law <law at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P2 |P4
--- Comment #10 from Jeffrey A. Law <law at redhat dot com> ---
So I looked at this again for a while today. To recap, we need to peel an
iteration off the loop to get the code we want for this testcase.
We allow jump threading to peel iterations off loops after the loop optimizers
have finished. In this specific case, ivopts changes the iteration test in
ways that make it hard for the final DOM pass to discover the jump threading
opportunity.
I briefly toyed with conditionally allowing the first DOM pass to peel the
loop, but the conditions feel like an unmaintainable hack. Essentially we're
trying to outguess whether or not some later pass would likely make a better
decision. We end up with if (a || b || c || d || e || f || g, etc) which tries
to capture all the later loop passes that might not want the loop peeled by
DOM.
While looking over the result of such a patch, my conclusion was that in
general, allowing peeling by the first DOM pass wasn't worth the hack from a
performance and code size standpoint.
I'll note that -funroll-loops or -fpeel-loops ultimately do something better,
they fully unroll the loop into straight line code. They (unfortunately) leave
the address un-cse'd, but the result is still better than anything jump
threading would do here.
I'm going to downgrade to P4 -- there's some chance that one day we'll keep
enough information from ivopts to allow the final DOM pass to discover the jump
threading opportunity, so I don't think we want to close this BZ.
