https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117207
Segher Boessenkool <segher at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |segher at gcc dot gnu.org
--- Comment #5 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #3)
> So, what about just adding -fno-tree-vectorize to dg-options of the tests?
Why would that be a good idea? We want to test if somehow the options for one
function "infected" the options for another, not just if the lack of tree-level
unrolling resulted in worse results!
> Here is what I've tried (r12-5394 is the last ppc64le build I have around
> before the r12-5920 fix, r12-6021 first ppc64le build after that fix and
> r15-7688 latest trunk build I have around):
> for i in ./cc1.r12-5394 ./cc1.r12-6021 ../../objp5/gcc/cc1.r15-7688; do for
> j in "" "-fno-tree-vectorize"; do rm -f pr103515.c.*; $i -quiet -nostdinc
> -O2 $j -fdump-rtl-loop2_unroll-optimized pr103515.c ; echo $i $j; grep
> 'optimized: loop unrolled' pr103515.c.*; done; done
> ./cc1.r12-5394
> pr103515.c:16:17: optimized: loop unrolled 3 times
> pr103515.c:26:11: optimized: loop unrolled 7 times
> ./cc1.r12-5394 -fno-tree-vectorize
> pr103515.c:16:17: optimized: loop unrolled 3 times
> pr103515.c:25:17: optimized: loop unrolled 3 times
> ./cc1.r12-6021
> pr103515.c:26:11: optimized: loop unrolled 7 times
> ./cc1.r12-6021 -fno-tree-vectorize
> pr103515.c:25:17: optimized: loop unrolled 3 times
> ../../objp5/gcc/cc1.r15-7688
> pr103515.c:17:11: optimized: loop unrolled 1 times
> pr103515.c:26:11: optimized: loop unrolled 7 times
> ../../objp5/gcc/cc1.r15-7688 -fno-tree-vectorize
> pr103515.c:25:17: optimized: loop unrolled 3 times
Perhaps it is possible to make a sane test based on such things. But the
test as-is, doe not test what it is meant to test, anymore.
> So, IMHO the test still checks what it is supposed to test even with
> -fno-tree-vectorize, it would have FAILed before r12-6021 even with
> -fno-tree-vectorize, it doesn't FAIL after that and doesn't still FAIL on
> the trunk that way (unlike the case without -fno-tree-vectorize).
It does not matter at all whether the test would have failed before the
original change. Testcase writing is supposed to be an exact science, not
some experimental tinkering thing!
Most unrolling is tree-level these days, so if you disable that *of course*
the test compiles to the same thing at -O2 as it does at -O3.
