* [Bug target/97252] [10/11 Regression] arm: ICE compiling pure-code/pr94538-2.c with MVE since r10-7293-g3eff57aa
2020-09-30 8:42 [Bug target/97252] New: [10/11 Regression] arm: ICE compiling pure-code/pr94538-2.c with MVE since r10-7293-g3eff57aa acoplan at gcc dot gnu.org
@ 2020-09-30 14:48 ` acoplan at gcc dot gnu.org
2021-01-14 9:22 ` rguenth at gcc dot gnu.org
` (8 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: acoplan at gcc dot gnu.org @ 2020-09-30 14:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97252
Alex Coplan <acoplan at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |10.3
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug target/97252] [10/11 Regression] arm: ICE compiling pure-code/pr94538-2.c with MVE since r10-7293-g3eff57aa
2020-09-30 8:42 [Bug target/97252] New: [10/11 Regression] arm: ICE compiling pure-code/pr94538-2.c with MVE since r10-7293-g3eff57aa acoplan at gcc dot gnu.org
2020-09-30 14:48 ` [Bug target/97252] " acoplan at gcc dot gnu.org
@ 2021-01-14 9:22 ` rguenth at gcc dot gnu.org
2021-03-15 11:50 ` acoplan at gcc dot gnu.org
` (7 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-01-14 9:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97252
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P2
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug target/97252] [10/11 Regression] arm: ICE compiling pure-code/pr94538-2.c with MVE since r10-7293-g3eff57aa
2020-09-30 8:42 [Bug target/97252] New: [10/11 Regression] arm: ICE compiling pure-code/pr94538-2.c with MVE since r10-7293-g3eff57aa acoplan at gcc dot gnu.org
2020-09-30 14:48 ` [Bug target/97252] " acoplan at gcc dot gnu.org
2021-01-14 9:22 ` rguenth at gcc dot gnu.org
@ 2021-03-15 11:50 ` acoplan at gcc dot gnu.org
2021-03-16 9:36 ` acoplan at gcc dot gnu.org
` (6 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: acoplan at gcc dot gnu.org @ 2021-03-15 11:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97252
Alex Coplan <acoplan at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2021-03-15
Known to fail| |11.0
Ever confirmed|0 |1
CC| |ktkachov at gcc dot gnu.org,
| |sripar01 at gcc dot gnu.org
Keywords| |ice-on-valid-code
Target|arm |arm-eabi
Status|UNCONFIRMED |NEW
--- Comment #1 from Alex Coplan <acoplan at gcc dot gnu.org> ---
The problematic insn is:
(insn 8 7 9 2 (set (reg:V4SI 119)
(const_vector:V4SI [
(const_int 4095 [0xfff])
(const_int 0 [0]) repeated x3
])) "ice.c":3:21 2998 {*mve_movv4si}
(nil))
We ICE in the output code for *mve_mov<mode> with which_alternative == 4. It
looks like the constraint is wrong for this alternative:
(define_insn "*mve_mov<mode>"
[(set (match_operand:MVE_types 0 "nonimmediate_operand"
"=w,w,r,w,w,r,w,Ux,w")
(match_operand:MVE_types 1 "general_operand"
"w,r,w,Dn,Uxi,r,Dm,w,Ul"))]
Unless I'm missing something, I don't think "Uxi" is a valid constraint.
Perhaps the "Ux" constraint was intended instead?
If the constraint really is invalid, it would be nice to catch this earlier
(ideally when the MD files are processed at build time).
Changing the constraint to Ux leads to cycling in LRA. Perhaps something went
wrong at expand time? Need to do some more debugging.
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug target/97252] [10/11 Regression] arm: ICE compiling pure-code/pr94538-2.c with MVE since r10-7293-g3eff57aa
2020-09-30 8:42 [Bug target/97252] New: [10/11 Regression] arm: ICE compiling pure-code/pr94538-2.c with MVE since r10-7293-g3eff57aa acoplan at gcc dot gnu.org
` (2 preceding siblings ...)
2021-03-15 11:50 ` acoplan at gcc dot gnu.org
@ 2021-03-16 9:36 ` acoplan at gcc dot gnu.org
2021-03-16 10:45 ` acoplan at gcc dot gnu.org
` (5 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: acoplan at gcc dot gnu.org @ 2021-03-16 9:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97252
--- Comment #2 from Alex Coplan <acoplan at gcc dot gnu.org> ---
> Unless I'm missing something, I don't think "Uxi" is a valid constraint.
> Perhaps the "Ux" constraint was intended instead?
D'oh, this is of course the union of the Ux (MVE-specific) constraint and the
"i" (general) constraint.
It seems that the problem is that we need the const_vector to get
force_const_mem'd into the constant pool, but the usual approach on AArch32
(without -mpure-code) seems to be to keep these constants around until the
arm_reorg pass runs where they then get brought into a local literal pool. Of
course, with -mpure-code, the literal pool is disabled, so we don't make this
transformation.
Looking at the same testcase on AArch64, we seem to force the const_vector out
to the constant pool in LRA instead.
Not sure what the right approach is for AArch32 here.
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug target/97252] [10/11 Regression] arm: ICE compiling pure-code/pr94538-2.c with MVE since r10-7293-g3eff57aa
2020-09-30 8:42 [Bug target/97252] New: [10/11 Regression] arm: ICE compiling pure-code/pr94538-2.c with MVE since r10-7293-g3eff57aa acoplan at gcc dot gnu.org
` (3 preceding siblings ...)
2021-03-16 9:36 ` acoplan at gcc dot gnu.org
@ 2021-03-16 10:45 ` acoplan at gcc dot gnu.org
2021-03-17 12:31 ` acoplan at gcc dot gnu.org
` (4 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: acoplan at gcc dot gnu.org @ 2021-03-16 10:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97252
--- Comment #3 from Alex Coplan <acoplan at gcc dot gnu.org> ---
FWIW, for the related testcase (which we also ICE on):
typedef int __attribute((vector_size(16))) V;
V v;
void f() { v = (V){4095}; }
clang pushes the constant out to the constant pool:
$ clang -target arm ice.c -c -S -o - -O2 -march=armv8.1-m.main+mve -mpure-code
-mfloat-abi=hard
[...]
f:
.fnstart
@ %bb.0:
movw r0, :lower16:.LCP0_0
movw r1, :lower16:v
movt r0, :upper16:.LCP0_0
movt r1, :upper16:v
vldrw.u32 q0, [r0]
vstrw.32 q0, [r1]
bx lr
.Lfunc_end0:
.size f, .Lfunc_end0-f
.cantunwind
.fnend
@ -- End function
.type v,%object @ @v
.comm v,16,8
.type .LCP0_0,%object @ @.LCP0_0
.section .rodata,"a",%progbits
.p2align 4
.LCP0_0:
.long 4095 @ 0xfff
.long 0 @ 0x0
.long 0 @ 0x0
.long 0 @ 0x0
.size .LCP0_0, 16
I think we should do the same.
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug target/97252] [10/11 Regression] arm: ICE compiling pure-code/pr94538-2.c with MVE since r10-7293-g3eff57aa
2020-09-30 8:42 [Bug target/97252] New: [10/11 Regression] arm: ICE compiling pure-code/pr94538-2.c with MVE since r10-7293-g3eff57aa acoplan at gcc dot gnu.org
` (4 preceding siblings ...)
2021-03-16 10:45 ` acoplan at gcc dot gnu.org
@ 2021-03-17 12:31 ` acoplan at gcc dot gnu.org
2021-03-22 14:44 ` cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: acoplan at gcc dot gnu.org @ 2021-03-17 12:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97252
Alex Coplan <acoplan at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |acoplan at gcc dot gnu.org
--- Comment #4 from Alex Coplan <acoplan at gcc dot gnu.org> ---
Mine
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug target/97252] [10/11 Regression] arm: ICE compiling pure-code/pr94538-2.c with MVE since r10-7293-g3eff57aa
2020-09-30 8:42 [Bug target/97252] New: [10/11 Regression] arm: ICE compiling pure-code/pr94538-2.c with MVE since r10-7293-g3eff57aa acoplan at gcc dot gnu.org
` (5 preceding siblings ...)
2021-03-17 12:31 ` acoplan at gcc dot gnu.org
@ 2021-03-22 14:44 ` cvs-commit at gcc dot gnu.org
2021-03-22 14:47 ` [Bug target/97252] [10 " acoplan at gcc dot gnu.org
` (2 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-03-22 14:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97252
--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Alex Coplan <acoplan@gcc.gnu.org>:
https://gcc.gnu.org/g:150a829accd76ddd73c20628774cb0781f6e8bfe
commit r11-7764-g150a829accd76ddd73c20628774cb0781f6e8bfe
Author: Alex Coplan <alex.coplan@arm.com>
Date: Mon Mar 22 14:43:15 2021 +0000
arm: Fix MVE ICEs with vector moves and -mpure-code [PR97252]
This fixes around 500 ICEs in the testsuite which can be seen when
testing with -march=armv8.1-m.main+mve -mfloat-abi=hard -mpure-code
(leaving the testsuite free of ICEs in this configuration). All of the
ICEs are in arm_print_operand (which is expecting a mem and gets another
rtx, e.g. a const_vector) when running the output code for
*mve_mov<mode> in alternative 4.
The issue is that MVE vector moves were relying on the arm_reorg pass to
move constant vectors that we can't easily synthesize to the literal
pool. This doesn't work for -mpure-code where the literal pool is
disabled. LLVM puts these in .rodata: I've chosen to do the same here.
With this change, for -mpure-code, we no longer want to allow a constant
on the RHS of a vector load in RA. To achieve this, I added a new
constraint which matches constants only if the literal pool is
available.
gcc/ChangeLog:
PR target/97252
* config/arm/arm-protos.h (neon_make_constant): Add generate
argument to guard emitting insns, default to true.
* config/arm/arm.c (arm_legitimate_constant_p_1): Reject
CONST_VECTORs which neon_make_constant can't handle.
(neon_vdup_constant): Add generate argument, avoid emitting
insns if it's not set.
(neon_make_constant): Plumb new generate argument through.
* config/arm/constraints.md (Ui): New. Use it...
* config/arm/mve.md (*mve_mov<mode>): ... here.
* config/arm/vec-common.md (movv8hf): Use neon_make_constant to
synthesize constants.
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug target/97252] [10 Regression] arm: ICE compiling pure-code/pr94538-2.c with MVE since r10-7293-g3eff57aa
2020-09-30 8:42 [Bug target/97252] New: [10/11 Regression] arm: ICE compiling pure-code/pr94538-2.c with MVE since r10-7293-g3eff57aa acoplan at gcc dot gnu.org
` (6 preceding siblings ...)
2021-03-22 14:44 ` cvs-commit at gcc dot gnu.org
@ 2021-03-22 14:47 ` acoplan at gcc dot gnu.org
2021-03-29 17:17 ` cvs-commit at gcc dot gnu.org
2021-03-29 17:19 ` [Bug target/97252] " acoplan at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: acoplan at gcc dot gnu.org @ 2021-03-22 14:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97252
Alex Coplan <acoplan at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[10/11 Regression] arm: ICE |[10 Regression] arm: ICE
|compiling |compiling
|pure-code/pr94538-2.c with |pure-code/pr94538-2.c with
|MVE since |MVE since
|r10-7293-g3eff57aa |r10-7293-g3eff57aa
Known to fail|11.0 |10.2.1
--- Comment #6 from Alex Coplan <acoplan at gcc dot gnu.org> ---
Fixed on trunk. Needs backporting to GCC 10.
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug target/97252] [10 Regression] arm: ICE compiling pure-code/pr94538-2.c with MVE since r10-7293-g3eff57aa
2020-09-30 8:42 [Bug target/97252] New: [10/11 Regression] arm: ICE compiling pure-code/pr94538-2.c with MVE since r10-7293-g3eff57aa acoplan at gcc dot gnu.org
` (7 preceding siblings ...)
2021-03-22 14:47 ` [Bug target/97252] [10 " acoplan at gcc dot gnu.org
@ 2021-03-29 17:17 ` cvs-commit at gcc dot gnu.org
2021-03-29 17:19 ` [Bug target/97252] " acoplan at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-03-29 17:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97252
--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Alex Coplan
<acoplan@gcc.gnu.org>:
https://gcc.gnu.org/g:f14adc64c1be6e6a07689ef87c65fc87cc24902f
commit r10-9555-gf14adc64c1be6e6a07689ef87c65fc87cc24902f
Author: Alex Coplan <alex.coplan@arm.com>
Date: Mon Mar 22 14:43:15 2021 +0000
arm: Fix MVE ICEs with vector moves and -mpure-code [PR97252]
This fixes around 500 ICEs in the testsuite which can be seen when
testing with -march=armv8.1-m.main+mve -mfloat-abi=hard -mpure-code
(leaving the testsuite free of ICEs in this configuration). All of the
ICEs are in arm_print_operand (which is expecting a mem and gets another
rtx, e.g. a const_vector) when running the output code for
*mve_mov<mode> in alternative 4.
The issue is that MVE vector moves were relying on the arm_reorg pass to
move constant vectors that we can't easily synthesize to the literal
pool. This doesn't work for -mpure-code where the literal pool is
disabled. LLVM puts these in .rodata: I've chosen to do the same here.
With this change, for -mpure-code, we no longer want to allow a constant
on the RHS of a vector load in RA. To achieve this, I added a new
constraint which matches constants only if the literal pool is
available.
gcc/ChangeLog:
PR target/97252
* config/arm/arm-protos.h (neon_make_constant): Add generate
argument to guard emitting insns, default to true.
* config/arm/arm.c (arm_legitimate_constant_p_1): Reject
CONST_VECTORs which neon_make_constant can't handle.
(neon_vdup_constant): Add generate argument, avoid emitting
insns if it's not set.
(neon_make_constant): Plumb new generate argument through.
* config/arm/constraints.md (Ui): New. Use it...
* config/arm/mve.md (*mve_mov<mode>): ... here.
* config/arm/vec-common.md (movv8hf): Use neon_make_constant to
synthesize constants.
(cherry picked from commit 150a829accd76ddd73c20628774cb0781f6e8bfe)
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug target/97252] arm: ICE compiling pure-code/pr94538-2.c with MVE since r10-7293-g3eff57aa
2020-09-30 8:42 [Bug target/97252] New: [10/11 Regression] arm: ICE compiling pure-code/pr94538-2.c with MVE since r10-7293-g3eff57aa acoplan at gcc dot gnu.org
` (8 preceding siblings ...)
2021-03-29 17:17 ` cvs-commit at gcc dot gnu.org
@ 2021-03-29 17:19 ` acoplan at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: acoplan at gcc dot gnu.org @ 2021-03-29 17:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97252
Alex Coplan <acoplan at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Summary|[10 Regression] arm: ICE |arm: ICE compiling
|compiling |pure-code/pr94538-2.c with
|pure-code/pr94538-2.c with |MVE since
|MVE since |r10-7293-g3eff57aa
|r10-7293-g3eff57aa |
Status|NEW |RESOLVED
--- Comment #8 from Alex Coplan <acoplan at gcc dot gnu.org> ---
Fixed.
^ permalink raw reply [flat|nested] 11+ messages in thread