[Bug tree-optimization/114551] [14 Regression] wrong code at -O3 on x86_64-linux-gnu since r14-2944
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114551 Richard Biener changed: What|Removed |Added Summary|[13 Regression] wrong code |[14 Regression] wrong code |at -O3 on x86_64-linux-gnu |at -O3 on x86_64-linux-gnu |since r14-2944 |since r14-2944 Resolution|--- |FIXED Target Milestone|13.3|14.0 Status|ASSIGNED|RESOLVED --- Comment #9 from Richard Biener --- Too awkward to backport, depend on rewrite_to_defined_overflow API re-org. Fixed in GCC 14.
[Bug tree-optimization/114551] [14 Regression] wrong code at -O3 on x86_64-linux-gnu since r14-2944
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114551 --- Comment #7 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:e152177b362143465e2b9d721ea632cae3f13445 commit r14-9781-ge152177b362143465e2b9d721ea632cae3f13445 Author: Richard Biener Date: Wed Apr 3 14:53:30 2024 +0200 tree-optimization/114551 - loop splitting and undefined overflow When loop splitting hoists a guard computation it needs to make sure that can be safely evaluated at this place when it was previously only conditionally evaluated. The following fixes this for the case of undefined overflow. PR tree-optimization/114551 * tree-ssa-loop-split.cc (split_loop): If the guard is only conditionally evaluated rewrite computations with possibly undefined overflow to unsigned arithmetic. * gcc.dg/torture/pr114551.c: New testcase.
[Bug tree-optimization/114551] [14 Regression] wrong code at -O3 on x86_64-linux-gnu since r14-2944
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114551 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #6 from Richard Biener --- It can be reproduced with -O2 -funswitch-loops -fsplit-loops. Loop splitting emits [local count: 14598063]: a.0_1 = a; _2 = a.0_1 + -1; a = _2; _24 = _2 <= 0; _10 = 2147483647 - _2; if (_10 <= 2) and the 2147483647 - _2 expression then overflows, so that's definitely wrong. This is built here: /* Build a condition that will skip the first loop when the guard condition won't ever be true (or false). */ gimple_seq stmts2; border = force_gimple_operand (border, &stmts2, true, NULL_TREE); if (stmts2) or rather in split_at_bb_p and put into '*border'
[Bug tree-optimization/114551] [14 Regression] wrong code at -O3 on x86_64-linux-gnu since r14-2944
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114551
--- Comment #5 from Andrew Pinski ---
Found potential split point: if (f.12_35 <= _25)
{ 3 + I*-1 } le_expr 2147483647 - _2
Applying pattern match.pd:6064, generic-match-4.cc:1699
[Bug tree-optimization/114551] [14 Regression] wrong code at -O3 on x86_64-linux-gnu since r14-2944
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114551 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment #4 from Andrew Pinski --- Note you can remove continue/[[unlikely]]` and reproduce it with `-O3 -fdisable-tree-lim2`. Also note disabling VRP2, `-fdisable-tree-vrp2` allows the code to pass which gets me the feeling like maybe lsplit is not rewriting the check to be overflow safe.
[Bug tree-optimization/114551] [14 Regression] wrong code at -O3 on x86_64-linux-gnu since r14-2944
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114551
--- Comment #3 from Andrew Pinski ---
The first major difference with/without continue is the moving of `f >
(2147483647 - a)` checkout of the loop via lim2 in the case of not having the
continue.
You can replace the inner most loop with:
```
for (; c < 4; c++) {
[[unlikely]];
d = f && a > 0 && f > (2147483647 - a) ? 0 : b[f];
}
```
Also so yes it is the continue predictor that is coming into play.
