https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70288
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
At -O1 cunroll produces an unreasonably amount of tests/BBs which later
produces compile-time hogs.
Estimated size after unrolling: 1
test_case_2.c:25:13: note: loop with 11 iterations completely unrolled
Estimated size after unrolling: 1
test_case_2.c:15:11: note: loop with 6 iterations completely unrolled
Estimated size after unrolling: 1
test_case_2.c:27:9: note: loop with 10 iterations completely unrolled
Estimated size after unrolling: 1
test_case_2.c:10:7: note: loop with 5 iterations completely unrolled
Estimated size after unrolling: 1
test_case_2.c:29:5: note: loop with 11 iterations completely unrolled
Estimated size after unrolling: 1
test_case_2.c:30:3: note: loop with 12 iterations completely unrolled
because we think that all the
size: 2 if (&s2_108 > &s1_115)
Constant conditional.
conds are optimized. But they are not (they'll be jump-threaded eventually).
This is from the innermost loop which has
double s1_115[4], s2_108[4];
...
if (s2_108 > s1_115) {
int var23 = -890798748;
do {
long long e_119[4];
} while (var23 <= -890798746);
}
and thus compares addresses of unrelated variables which invokes undefined
behavior (but which we usually won't fold to a constant or trap/unreachable).
I'll fix the cunroll size heuristic.
