public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug tree-optimization/97513] New: [11 regression] aarch64 SVE regressions since r11-3822
@ 2020-10-21 9:38 clyon at gcc dot gnu.org
2020-10-21 10:32 ` [Bug target/97513] " rguenth at gcc dot gnu.org
` (11 more replies)
0 siblings, 12 replies; 13+ messages in thread
From: clyon at gcc dot gnu.org @ 2020-10-21 9:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97513
Bug ID: 97513
Summary: [11 regression] aarch64 SVE regressions since r11-3822
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Since r11-3822 (g:7e7352b2ad089ea68d689f3b79d93e3ee26326f7), I have noticed
several aarch64/SVE regressions:
gcc.target/aarch64/sve/mask_load_slp_1.c -march=armv8.2-a+sve
scan-assembler-times \\tld1w\\t 48
gcc.target/aarch64/sve/mask_load_slp_1.c -march=armv8.2-a+sve
scan-assembler-times \\tst1w\\t 40
gcc.target/aarch64/sve/slp_10.c -march=armv8.2-a+sve scan-assembler-times
\\tld1d\\t 15
gcc.target/aarch64/sve/slp_10.c -march=armv8.2-a+sve scan-assembler-times
\\tst1d\\t 15
gcc.target/aarch64/sve/slp_10.c -march=armv8.2-a+sve scan-assembler-times
\\tuqdecd\\t 6
gcc.target/aarch64/sve/slp_10.c -march=armv8.2-a+sve scan-assembler-times
\\tuqdecw\\t 9
gcc.target/aarch64/sve/slp_10.c -march=armv8.2-a+sve scan-assembler-times
\\twhilelo\\tp[0-7]\\.d 30
gcc.target/aarch64/sve/slp_12.c -march=armv8.2-a+sve scan-assembler-times
\\tld1d\\t 15
gcc.target/aarch64/sve/slp_12.c -march=armv8.2-a+sve scan-assembler-times
\\tst1d\\t 15
gcc.target/aarch64/sve/slp_12.c -march=armv8.2-a+sve scan-assembler-times
\\tuqdecd\\t 6
gcc.target/aarch64/sve/slp_12.c -march=armv8.2-a+sve scan-assembler-times
\\tuqdecw\\t 9
gcc.target/aarch64/sve/slp_12.c -march=armv8.2-a+sve scan-assembler-times
\\twhilelo\\tp[0-7]\\.d 30
gcc.target/aarch64/sve/slp_3.c -march=armv8.2-a+sve scan-assembler-times
\\tld1d\\t 6
gcc.target/aarch64/sve/slp_3.c -march=armv8.2-a+sve scan-assembler-times
\\tmov\\tz[0-9]+\\.d, #25\\n 2
gcc.target/aarch64/sve/slp_3.c -march=armv8.2-a+sve scan-assembler-times
\\tmov\\tz[0-9]+\\.d, #31\\n 2
gcc.target/aarch64/sve/slp_3.c -march=armv8.2-a+sve scan-assembler-times
\\tmov\\tz[0-9]+\\.d, #41\\n 2
gcc.target/aarch64/sve/slp_3.c -march=armv8.2-a+sve scan-assembler-times
\\tmov\\tz[0-9]+\\.d, #62\\n 2
gcc.target/aarch64/sve/slp_3.c -march=armv8.2-a+sve scan-assembler-times
\\tmov\\tz[0-9]+\\.d, x[0-9]+\\n 3
gcc.target/aarch64/sve/slp_3.c -march=armv8.2-a+sve scan-assembler-times
\\tst1d\\t 6
gcc.target/aarch64/sve/slp_3.c -march=armv8.2-a+sve scan-assembler-times
\\tuqdecd\\t 3
gcc.target/aarch64/sve/slp_3.c -march=armv8.2-a+sve scan-assembler-times
\\twhilelo\\tp[0-7]\\.d 12
gcc.target/aarch64/sve/slp_3.c -march=armv8.2-a+sve scan-assembler-times
\\tzip1\\tz[0-9]+\\.d, z[0-9]+\\.d, z[0-9]+\\.d\\n 9
gcc.target/aarch64/sve/slp_3.c -march=armv8.2-a+sve scan-assembler-times
\\tzip2\\tz[0-9]+\\.d, z[0-9]+\\.d, z[0-9]+\\.d\\n 3
gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-not
\\tldr
gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-times
\\tld1d\\t 12
gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-times
\\tld1rd\\tz[0-9]+\\.d, 18
gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-times
\\tld1w\\t 6
gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-times
\\tmov\\tz[0-9]+\\.d, #11\\n 2
gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-times
\\tmov\\tz[0-9]+\\.d, #17\\n 2
gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-times
\\tmov\\tz[0-9]+\\.d, #24\\n 2
gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-times
\\tmov\\tz[0-9]+\\.d, #37\\n 2
gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-times
\\tmov\\tz[0-9]+\\.d, #63\\n 2
gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-times
\\tmov\\tz[0-9]+\\.d, #80\\n 2
gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-times
\\tmov\\tz[0-9]+\\.d, #81\\n 2
gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-times
\\tmov\\tz[0-9]+\\.d, #99\\n 2
gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-times
\\tmov\\tz[0-9]+\\.d, x[0-9]+\\n 4
gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-times
\\tst1d\\t 12
gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-times
\\tst1w\\t 6
gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-times
\\tuqdecd\\t 6
gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-times
\\tuqdecw\\t 6
gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-times
\\twhilelo\\tp[0-7]\\.d 24
gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-times
\\twhilelo\\tp[0-7]\\.s 12
gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-times
\\tzip1\\tz[0-9]+\\.d, z[0-9]+\\.d, z[0-9]+\\.d\\n 33
gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-times
\\tzip2\\tz[0-9]+\\.d, z[0-9]+\\.d, z[0-9]+\\.d\\n 15
gcc.target/aarch64/sve/slp_8.c -march=armv8.2-a+sve scan-assembler-times
\\tld1d\\t 9
gcc.target/aarch64/sve/slp_8.c -march=armv8.2-a+sve scan-assembler-times
\\tst1d\\t 9
gcc.target/aarch64/sve/slp_8.c -march=armv8.2-a+sve scan-assembler-times
\\tzip1\\tp[0-7]\\.d 3
gcc.target/aarch64/sve/slp_8.c -march=armv8.2-a+sve scan-assembler-times
\\tzip2\\tp[0-7]\\.d 3
gcc.target/aarch64/sve/slp_perm_1.c -march=armv8.2-a+sve
scan-assembler-times \\trevb\\tz[0-9]+\\.d, p[0-7]/m, z[0-9]+\\.d\\n 1
gcc.target/aarch64/sve/slp_perm_2.c -march=armv8.2-a+sve
scan-assembler-times \\trevb\\tz[0-9]+\\.s, p[0-7]/m, z[0-9]+\\.s\\n 1
gcc.target/aarch64/sve/slp_perm_3.c -march=armv8.2-a+sve
scan-assembler-times \\trevb\\tz[0-9]+\\.h, p[0-7]/m, z[0-9]+\\.h\\n 1
gcc.target/aarch64/sve/slp_perm_6.c -march=armv8.2-a+sve
scan-assembler-times \\ttbl\\tz[0-9]+\\.b, z[0-9]+\\.b, z[0-9]+\\.b\\n 1
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/97513] [11 regression] aarch64 SVE regressions since r11-3822
2020-10-21 9:38 [Bug tree-optimization/97513] New: [11 regression] aarch64 SVE regressions since r11-3822 clyon at gcc dot gnu.org
@ 2020-10-21 10:32 ` rguenth at gcc dot gnu.org
2020-10-21 13:14 ` acoplan at gcc dot gnu.org
` (10 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-10-21 10:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97513
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|tree-optimization |target
Target Milestone|--- |11.0
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/97513] [11 regression] aarch64 SVE regressions since r11-3822
2020-10-21 9:38 [Bug tree-optimization/97513] New: [11 regression] aarch64 SVE regressions since r11-3822 clyon at gcc dot gnu.org
2020-10-21 10:32 ` [Bug target/97513] " rguenth at gcc dot gnu.org
@ 2020-10-21 13:14 ` acoplan at gcc dot gnu.org
2020-10-21 13:17 ` clyon at gcc dot gnu.org
` (9 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: acoplan at gcc dot gnu.org @ 2020-10-21 13:14 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97513
Alex Coplan <acoplan at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |acoplan at gcc dot gnu.org
--- Comment #1 from Alex Coplan <acoplan at gcc dot gnu.org> ---
> Since r11-3822 (g:7e7352b2ad089ea68d689f3b79d93e3ee26326f7), I have noticed several aarch64/SVE regressions
Presumably that is just a revision that you've seen this at rather than the
result of a bisection?
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/97513] [11 regression] aarch64 SVE regressions since r11-3822
2020-10-21 9:38 [Bug tree-optimization/97513] New: [11 regression] aarch64 SVE regressions since r11-3822 clyon at gcc dot gnu.org
2020-10-21 10:32 ` [Bug target/97513] " rguenth at gcc dot gnu.org
2020-10-21 13:14 ` acoplan at gcc dot gnu.org
@ 2020-10-21 13:17 ` clyon at gcc dot gnu.org
2020-11-19 18:02 ` rsandifo at gcc dot gnu.org
` (8 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: clyon at gcc dot gnu.org @ 2020-10-21 13:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97513
--- Comment #2 from Christophe Lyon <clyon at gcc dot gnu.org> ---
Right, but the builds were broken before that (did not work with gcc-4.8.5 on
the host), so I didn't notice this problem ealier.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/97513] [11 regression] aarch64 SVE regressions since r11-3822
2020-10-21 9:38 [Bug tree-optimization/97513] New: [11 regression] aarch64 SVE regressions since r11-3822 clyon at gcc dot gnu.org
` (2 preceding siblings ...)
2020-10-21 13:17 ` clyon at gcc dot gnu.org
@ 2020-11-19 18:02 ` rsandifo at gcc dot gnu.org
2020-11-19 19:56 ` clyon at gcc dot gnu.org
` (7 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: rsandifo at gcc dot gnu.org @ 2020-11-19 18:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97513
rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rsandifo at gcc dot gnu.org
--- Comment #3 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
With current trunk I'm seeing:
FAIL: gcc.target/aarch64/sve/loop_add_4.c -march=armv8.2-a+sve
scan-assembler-times \\tadd\\tz[0-9]+\\.d, z[0-9]+\\.d, z[0-9]+\\.d\\n 10
FAIL: gcc.target/aarch64/sve/loop_add_4.c -march=armv8.2-a+sve
scan-assembler-times \\tadd\\tz[0-9]+\\.h, z[0-9]+\\.h, z[0-9]+\\.h\\n 10
FAIL: gcc.target/aarch64/sve/loop_add_4.c -march=armv8.2-a+sve
scan-assembler-times \\tadd\\tz[0-9]+\\.s, z[0-9]+\\.s, z[0-9]+\\.s\\n 10
FAIL: gcc.target/aarch64/sve/loop_add_4.c -march=armv8.2-a+sve
scan-assembler-times \\tdecd\\tz[0-9]+\\.d, all, mul #15\\n 1
FAIL: gcc.target/aarch64/sve/loop_add_4.c -march=armv8.2-a+sve
scan-assembler-times \\tdecd\\tz[0-9]+\\.d, all, mul #16\\n 1
FAIL: gcc.target/aarch64/sve/loop_add_4.c -march=armv8.2-a+sve
scan-assembler-times \\tdecd\\tz[0-9]+\\.d\\n 1
FAIL: gcc.target/aarch64/sve/loop_add_4.c -march=armv8.2-a+sve
scan-assembler-times \\tdech\\tz[0-9]+\\.h, all, mul #15\\n 1
FAIL: gcc.target/aarch64/sve/loop_add_4.c -march=armv8.2-a+sve
scan-assembler-times \\tdech\\tz[0-9]+\\.h, all, mul #16\\n 1
FAIL: gcc.target/aarch64/sve/loop_add_4.c -march=armv8.2-a+sve
scan-assembler-times \\tdech\\tz[0-9]+\\.h\\n 1
FAIL: gcc.target/aarch64/sve/loop_add_4.c -march=armv8.2-a+sve
scan-assembler-times \\tdecw\\tz[0-9]+\\.s, all, mul #15\\n 1
FAIL: gcc.target/aarch64/sve/loop_add_4.c -march=armv8.2-a+sve
scan-assembler-times \\tdecw\\tz[0-9]+\\.s, all, mul #16\\n 1
FAIL: gcc.target/aarch64/sve/loop_add_4.c -march=armv8.2-a+sve
scan-assembler-times \\tdecw\\tz[0-9]+\\.s\\n 1
FAIL: gcc.target/aarch64/sve/slp_perm_1.c -march=armv8.2-a+sve
scan-assembler-times \\trevb\\tz[0-9]+\\.d, p[0-7]/m, z[0-9]+\\.d\\n 1
FAIL: gcc.target/aarch64/sve/slp_perm_2.c -march=armv8.2-a+sve
scan-assembler-times \\trevb\\tz[0-9]+\\.s, p[0-7]/m, z[0-9]+\\.s\\n 1
FAIL: gcc.target/aarch64/sve/slp_perm_3.c -march=armv8.2-a+sve
scan-assembler-times \\trevb\\tz[0-9]+\\.h, p[0-7]/m, z[0-9]+\\.h\\n 1
FAIL: gcc.target/aarch64/sve/slp_perm_6.c -march=armv8.2-a+sve
scan-assembler-times \\ttbl\\tz[0-9]+\\.b, z[0-9]+\\.b, z[0-9]+\\.b\\n 1
FAIL: gcc.target/aarch64/sve/vcond_3.c -march=armv8.2-a+sve
scan-assembler-times \\tmov\\tz[0-9]+\\.[hsd], p[0-7]/z, #-32768\\n 3
FAIL: gcc.target/aarch64/sve/vcond_3.c -march=armv8.2-a+sve
scan-assembler-times \\tmov\\tz[0-9]+\\.[hsd], p[0-7]/z, #256\\n 3
FAIL: gcc.target/aarch64/sve/vcond_3.c -march=armv8.2-a+sve
scan-assembler-times \\tmov\\tz[0-9]+\\.[hsd], p[0-7]/z, #2\\n 3
FAIL: gcc.target/aarch64/sve/vcond_3.c -march=armv8.2-a+sve
scan-assembler-times \\tmov\\tz[0-9]+\\.b, p[0-7]/z, #-128\\n 1
FAIL: gcc.target/aarch64/sve/vcond_3.c -march=armv8.2-a+sve
scan-assembler-times \\tmov\\tz[0-9]+\\.b, p[0-7]/z, #2\\n 1
Christophe, does that match your results?
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/97513] [11 regression] aarch64 SVE regressions since r11-3822
2020-10-21 9:38 [Bug tree-optimization/97513] New: [11 regression] aarch64 SVE regressions since r11-3822 clyon at gcc dot gnu.org
` (3 preceding siblings ...)
2020-11-19 18:02 ` rsandifo at gcc dot gnu.org
@ 2020-11-19 19:56 ` clyon at gcc dot gnu.org
2021-01-14 9:30 ` rguenth at gcc dot gnu.org
` (6 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: clyon at gcc dot gnu.org @ 2020-11-19 19:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97513
--- Comment #4 from Christophe Lyon <clyon at gcc dot gnu.org> ---
Not quite: as of r11-5140, I see:
FAIL: gcc.target/aarch64/sve/slp_perm_1.c -march=armv8.2-a+sve
scan-assembler-times \\trevb\\tz[0-9]+\\.d, p[0-7]/m, z[0-9]+\\.d\\n 1
FAIL: gcc.target/aarch64/sve/slp_perm_2.c -march=armv8.2-a+sve
scan-assembler-times \\trevb\\tz[0-9]+\\.s, p[0-7]/m, z[0-9]+\\.s\\n 1
FAIL: gcc.target/aarch64/sve/slp_perm_3.c -march=armv8.2-a+sve
scan-assembler-times \\trevb\\tz[0-9]+\\.h, p[0-7]/m, z[0-9]+\\.h\\n 1
FAIL: gcc.target/aarch64/sve/slp_perm_6.c -march=armv8.2-a+sve
scan-assembler-times \\ttbl\\tz[0-9]+\\.b, z[0-9]+\\.b, z[0-9]+\\.b\\n 1
FAIL: gcc.target/aarch64/sve/vcond_3.c -march=armv8.2-a+sve
scan-assembler-times \\tmov\\tz[0-9]+\\.[hsd], p[0-7]/z, #-32768\\n 3
FAIL: gcc.target/aarch64/sve/vcond_3.c -march=armv8.2-a+sve
scan-assembler-times \\tmov\\tz[0-9]+\\.[hsd], p[0-7]/z, #256\\n 3
FAIL: gcc.target/aarch64/sve/vcond_3.c -march=armv8.2-a+sve
scan-assembler-times \\tmov\\tz[0-9]+\\.[hsd], p[0-7]/z, #2\\n 3
FAIL: gcc.target/aarch64/sve/vcond_3.c -march=armv8.2-a+sve
scan-assembler-times \\tmov\\tz[0-9]+\\.b, p[0-7]/z, #-128\\n 1
FAIL: gcc.target/aarch64/sve/vcond_3.c -march=armv8.2-a+sve
scan-assembler-times \\tmov\\tz[0-9]+\\.b, p[0-7]/z, #2\\n 1
gcc.target/aarch64/sve/loop_add_4.c started passing between r4882 and r4894.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/97513] [11 regression] aarch64 SVE regressions since r11-3822
2020-10-21 9:38 [Bug tree-optimization/97513] New: [11 regression] aarch64 SVE regressions since r11-3822 clyon at gcc dot gnu.org
` (4 preceding siblings ...)
2020-11-19 19:56 ` clyon at gcc dot gnu.org
@ 2021-01-14 9:30 ` rguenth at gcc dot gnu.org
2021-03-09 14:26 ` rguenth at gcc dot gnu.org
` (5 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-01-14 9:30 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97513
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P1
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/97513] [11 regression] aarch64 SVE regressions since r11-3822
2020-10-21 9:38 [Bug tree-optimization/97513] New: [11 regression] aarch64 SVE regressions since r11-3822 clyon at gcc dot gnu.org
` (5 preceding siblings ...)
2021-01-14 9:30 ` rguenth at gcc dot gnu.org
@ 2021-03-09 14:26 ` rguenth at gcc dot gnu.org
2021-03-17 13:13 ` jakub at gcc dot gnu.org
` (4 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-03-09 14:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97513
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Last reconfirmed| |2021-03-09
Status|UNCONFIRMED |WAITING
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
What's the current state of affairs?
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/97513] [11 regression] aarch64 SVE regressions since r11-3822
2020-10-21 9:38 [Bug tree-optimization/97513] New: [11 regression] aarch64 SVE regressions since r11-3822 clyon at gcc dot gnu.org
` (6 preceding siblings ...)
2021-03-09 14:26 ` rguenth at gcc dot gnu.org
@ 2021-03-17 13:13 ` jakub at gcc dot gnu.org
2021-04-01 16:11 ` rsandifo at gcc dot gnu.org
` (3 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-03-17 13:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97513
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I chose to bisect randomly one test, gcc.target/aarch64/sve/slp_perm_1.c
started FAILing with r11-3823 and FAILs even with current trunk, the difference
seems to be that previously it was using the SVE variable length vectors and
now it uses fixed V16QImode vectors.
As this PR mentions a lot of different FAILs, some started earlier, others
later, some got fixed afterwards, others not, it is hard to find out what
can/should be done.
I can't reproduce the gcc.target/aarch64/sve/mask_load_slp_1.c FAILs, I get 48
/ 40 instructions as expected even with r11-3822.
I get 40 / 32 in r11-3823 up to r11-4480, and starting from r11-4481 again 48 /
40 until now.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/97513] [11 regression] aarch64 SVE regressions since r11-3822
2020-10-21 9:38 [Bug tree-optimization/97513] New: [11 regression] aarch64 SVE regressions since r11-3822 clyon at gcc dot gnu.org
` (7 preceding siblings ...)
2021-03-17 13:13 ` jakub at gcc dot gnu.org
@ 2021-04-01 16:11 ` rsandifo at gcc dot gnu.org
2021-04-07 14:22 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: rsandifo at gcc dot gnu.org @ 2021-04-01 16:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97513
rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |ASSIGNED
--- Comment #7 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
Testing a patch for the slp_perm_*.c regressions, which as Jakub
says are real. The remaining SVE testsuite failures looks like
testisms, so I'll deal with those separately.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/97513] [11 regression] aarch64 SVE regressions since r11-3822
2020-10-21 9:38 [Bug tree-optimization/97513] New: [11 regression] aarch64 SVE regressions since r11-3822 clyon at gcc dot gnu.org
` (8 preceding siblings ...)
2021-04-01 16:11 ` rsandifo at gcc dot gnu.org
@ 2021-04-07 14:22 ` cvs-commit at gcc dot gnu.org
2021-04-08 10:21 ` jakub at gcc dot gnu.org
2021-04-09 11:45 ` rsandifo at gcc dot gnu.org
11 siblings, 0 replies; 13+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-04-07 14:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97513
--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Sandiford <rsandifo@gcc.gnu.org>:
https://gcc.gnu.org/g:2f3d9104610cb2058cf091707a20c1c6eff8d470
commit r11-8030-g2f3d9104610cb2058cf091707a20c1c6eff8d470
Author: Richard Sandiford <richard.sandiford@arm.com>
Date: Wed Apr 7 15:21:56 2021 +0100
vect: Restore variable-length SLP permutes [PR97513]
Many of the gcc.target/sve/slp-perm*.c tests started failing
after the introduction of separate SLP permute nodes.
This patch adds variable-length support using a similar
technique to vect_transform_slp_perm_load.
As there, the idea is to detect when every permute mask vector
is the same and can be generated using a regular stepped sequence.
We can easily handle those cases for variable-length, but still
need to restrict the general case to constant-length.
Again copying vect_transform_slp_perm_load, the idea is to distinguish
the two cases regardless of whether the length is variable or not,
partly to increase testing coverage and partly because it avoids
generating redundant trees.
Doing this means that we can also use SLP for the two-vector
permute in pr88834.c, which we couldn't before VEC_PERM_EXPR
nodes were introduced. The patch therefore makes pr88834.c
check that we don't regress back to not using SLP and adds
pr88834_ld3.c to check for the original problem in the PR.
gcc/
PR tree-optimization/97513
* tree-vect-slp.c (vect_add_slp_permutation): New function,
split out from...
(vectorizable_slp_permutation): ...here. Detect cases in which
all VEC_PERM_EXPRs are guaranteed to have the same stepped
permute vector and only generate one permute vector for that case.
Extend that case to handle variable-length vectors.
gcc/testsuite/
* gcc.target/aarch64/sve/pr88834.c: Expect the vectorizer to use
SLP.
* gcc.target/aarch64/sve/pr88834_ld3.c: New test.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/97513] [11 regression] aarch64 SVE regressions since r11-3822
2020-10-21 9:38 [Bug tree-optimization/97513] New: [11 regression] aarch64 SVE regressions since r11-3822 clyon at gcc dot gnu.org
` (9 preceding siblings ...)
2021-04-07 14:22 ` cvs-commit at gcc dot gnu.org
@ 2021-04-08 10:21 ` jakub at gcc dot gnu.org
2021-04-09 11:45 ` rsandifo at gcc dot gnu.org
11 siblings, 0 replies; 13+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-04-08 10:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97513
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So fixed?
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/97513] [11 regression] aarch64 SVE regressions since r11-3822
2020-10-21 9:38 [Bug tree-optimization/97513] New: [11 regression] aarch64 SVE regressions since r11-3822 clyon at gcc dot gnu.org
` (10 preceding siblings ...)
2021-04-08 10:21 ` jakub at gcc dot gnu.org
@ 2021-04-09 11:45 ` rsandifo at gcc dot gnu.org
11 siblings, 0 replies; 13+ messages in thread
From: rsandifo at gcc dot gnu.org @ 2021-04-09 11:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97513
rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|ASSIGNED |RESOLVED
--- Comment #10 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
Fixed. I was going to count r11-8059 against this too,
but forgot.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2021-04-09 11:45 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-21 9:38 [Bug tree-optimization/97513] New: [11 regression] aarch64 SVE regressions since r11-3822 clyon at gcc dot gnu.org
2020-10-21 10:32 ` [Bug target/97513] " rguenth at gcc dot gnu.org
2020-10-21 13:14 ` acoplan at gcc dot gnu.org
2020-10-21 13:17 ` clyon at gcc dot gnu.org
2020-11-19 18:02 ` rsandifo at gcc dot gnu.org
2020-11-19 19:56 ` clyon at gcc dot gnu.org
2021-01-14 9:30 ` rguenth at gcc dot gnu.org
2021-03-09 14:26 ` rguenth at gcc dot gnu.org
2021-03-17 13:13 ` jakub at gcc dot gnu.org
2021-04-01 16:11 ` rsandifo at gcc dot gnu.org
2021-04-07 14:22 ` cvs-commit at gcc dot gnu.org
2021-04-08 10:21 ` jakub at gcc dot gnu.org
2021-04-09 11:45 ` rsandifo at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).