[Bug tree-optimization/71466] [7 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71466 --- Comment #10 from Jan Hubicka --- Iterations bounds are computed at early optimization time and maintained thorough. So the info is computed at thread2 time. Looking into testcase I noticed that jump threading seems to be doing useless work on degenerate PHI: # f_28 = PHI <1(8), 1(2)> ... if (f_28 == 0) When the code was part of vrp/dom, perhaps it never seen this oppurtunity because the constant got propagated first?
[Bug tree-optimization/71466] [7 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71466 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #9 from Jeffrey A. Law --- Jan's speculation in c#6 may not be 100% correct, but he's on the right track. We're getting the wrong # of iterations for some reason and that causes all kinds of hell in the unroller. bz71403 is a duplicate and I'm making it the canonical bug for this issue. *** This bug has been marked as a duplicate of bug 71403 ***
[Bug tree-optimization/71466] [7 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71466 --- Comment #8 from Jeffrey A. Law --- Jan, It's a nice theory, but if that were the case I'd expect we'd be having these problems before pulling the backwards threading bits into their own pass. I'm pretty sure the iterations data isn't even initialized when the first couple instances of the backwards threader are run. What is interesting about these tests is we're threading the backedge into a deeper point in the loop. That deeper point happens to also be the header of a nested loop. So there's some chance we've mucked up other aspects of the loop structures in an unexpected way. The three BZs are almost certainly the same issue though from looking at the CFGs and what jumps are being threaded.
[Bug tree-optimization/71466] [7 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71466 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #7 from Jan Hubicka --- Isn't the problem caused by fact that you end up rolling the loop and thus increasing number of iterations? Number of iterations is number of execution of the edge latch->header and is stored perisstently in the loop structure. If you change shape of the loop and some earlier edge becomes latch, you may need to adjust the estimate. If you are busy, I may try to look into this at weekend. I quite like the new threading code becuase it is simple while it catch many cases in practice. If it had mode that does not increase code size (which I sent patch for) it may be a good candidate for an early pass getting profile estimation to work noticeably better. Honza
[Bug tree-optimization/71466] [7 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71466 --- Comment #6 from Jeffrey A. Law --- FWIW, I've got two other BZs that exhibit at the surface seem to be the same problem -- namely the new threading code causing the unroller to generate incorrect code. The after threading code looks right in the test I've been looking at, but I find it hard to believe we've got 3 distinct instances where the new threading code is exposing the same latent bug in the unroller. So, anyway, at first glance this appears to be the same issue I'm already tracking.
[Bug tree-optimization/71466] [7 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71466 Richard Biener changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |7.0 Summary|wrong code at -O3 on|[7 Regression] wrong code |x86_64-linux-gnu|at -O3 on x86_64-linux-gnu
