diff options
author | Richard Sandiford <richard.sandiford@arm.com> | 2021-07-20 15:42:02 +0100 |
---|---|---|
committer | Richard Sandiford <richard.sandiford@arm.com> | 2021-07-20 15:42:02 +0100 |
commit | 1ef9b135793a528c05c4a3e22649744955aa2dfb (patch) | |
tree | 7c103fb256b38fa1dd23e8d479866e9f5d4a5628 /libstdc++-v3/src/filesystem/ops.cc | |
parent | 0c4ae4ff46b1d7633f1e06f57d348b5817b8f640 (diff) | |
download | gcc-1ef9b135793a528c05c4a3e22649744955aa2dfb.zip gcc-1ef9b135793a528c05c4a3e22649744955aa2dfb.tar.gz gcc-1ef9b135793a528c05c4a3e22649744955aa2dfb.tar.bz2 |
aarch64: Tweak old vect-* tests to avoid new FAILs
I'm not sure what these test were originally designed to test.
vaddv and vmaxv seem to be testing for vectorisation, with associated
scan-assembler tests. But they use arm_neon.h functions to test
the results, which would presumably also trip many of the scans.
That was probably what the split into vect-fmax-fmin.c and
vect-fmaxv-fminv-compile.c was supposed to avoid.
Anyway, the tests started failing after the recent change to allow
staged reductions for epilogue loops. And epilogues came into play
because the reduction loops iterate LANES-1 rather than LANES times.
(vmaxv was trying to iterate LANES times, but the gimple optimisers
outsmarted it. The other two explicitly had a count of LANES-1.)
Just suppressing epilogues causes other issues for vaddv and vmaxv.
The easiest fix therefore seemed to be to use an asm to hide the
initial value of the vmaxv loop (so that it really does iterate
LANES times) and then make the others match that style.
gcc/testsuite/
PR testsuite/101506
* gcc.target/aarch64/vect-vmaxv.c: Use an asm to hide the
true initial value of the reduction from the vectorizer.
* gcc.target/aarch64/vect-vaddv.c: Likewise. Make the vector
loop operate on exactly LANES (rather than LANES-1) iterations.
* gcc.target/aarch64/vect-fmaxv-fminv.x: Likewise.
Diffstat (limited to 'libstdc++-v3/src/filesystem/ops.cc')
0 files changed, 0 insertions, 0 deletions