[Bug target/97252] New: [10/11 Regression] arm: ICE compiling pure-code/pr94538-2.c with MVE since r10-7293-g3eff57aa

[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]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97252

            Bug ID: 97252
           Summary: [10/11 Regression] arm: ICE compiling
                    pure-code/pr94538-2.c with MVE since
                    r10-7293-g3eff57aa
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

Since r10-7293-g3eff57aacfef6e05f55e9dd6ecae3ef8568aaac4, AArch32 GCC ICEs
compiling gcc/testsuite/gcc.target/arm/pure-code/pr94538-2.c.

To reproduce:

$ arm-eabi-gcc -c pr94538-2.c -march=armv8.1-m.main+mve -mpure-code
during RTL pass: final
pr94538-2.c: In function 'foo':
pr94538-2.c:12:1: internal compiler error: in arm_print_operand, at
config/arm/arm.c:24158
   12 | }
      | ^
0x111a814 arm_print_operand
        /home/alecop01/toolchain/src/gcc/gcc/config/arm/arm.c:24158
0x92a8ca output_operand(rtx_def*, int)
        /home/alecop01/toolchain/src/gcc/gcc/final.c:4051
0x92b3ac output_asm_insn(char const*, rtx_def**)
        /home/alecop01/toolchain/src/gcc/gcc/final.c:3944
0x15b7ed4 output_2993
        /home/alecop01/toolchain/src/gcc/gcc/config/arm/mve.md:728
0x92a2ad get_insn_template(int, rtx_insn*)
        /home/alecop01/toolchain/src/gcc/gcc/final.c:2070
0x92ddbb final_scan_insn_1
        /home/alecop01/toolchain/src/gcc/gcc/final.c:3039
0x92e0a6 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
        /home/alecop01/toolchain/src/gcc/gcc/final.c:3152
0x92ecac final_1
        /home/alecop01/toolchain/src/gcc/gcc/final.c:2020
0x92f00a rest_of_handle_final
        /home/alecop01/toolchain/src/gcc/gcc/final.c:4658
0x92f00a execute
        /home/alecop01/toolchain/src/gcc/gcc/final.c:4736
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug target/97252] [10/11 Regression] arm: ICE compiling pure-code/pr94538-2.c with MVE since r10-7293-g3eff57aa

[acoplan at gcc dot gnu.org]

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

[Bug target/97252] [10/11 Regression] arm: ICE compiling pure-code/pr94538-2.c with MVE since r10-7293-g3eff57aa

[rguenth at gcc dot gnu.org]

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

[Bug target/97252] [10/11 Regression] arm: ICE compiling pure-code/pr94538-2.c with MVE since r10-7293-g3eff57aa

[acoplan at gcc dot gnu.org]

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.

[Bug target/97252] [10/11 Regression] arm: ICE compiling pure-code/pr94538-2.c with MVE since r10-7293-g3eff57aa

[acoplan at gcc dot gnu.org]

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.

[Bug target/97252] [10/11 Regression] arm: ICE compiling pure-code/pr94538-2.c with MVE since r10-7293-g3eff57aa

[acoplan at gcc dot gnu.org]

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.

[Bug target/97252] [10/11 Regression] arm: ICE compiling pure-code/pr94538-2.c with MVE since r10-7293-g3eff57aa

[acoplan at gcc dot gnu.org]

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

[Bug target/97252] [10/11 Regression] arm: ICE compiling pure-code/pr94538-2.c with MVE since r10-7293-g3eff57aa

[cvs-commit at gcc dot gnu.org]

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.

[Bug target/97252] [10 Regression] arm: ICE compiling pure-code/pr94538-2.c with MVE since r10-7293-g3eff57aa

[acoplan at gcc dot gnu.org]

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.

[Bug target/97252] [10 Regression] arm: ICE compiling pure-code/pr94538-2.c with MVE since r10-7293-g3eff57aa

[cvs-commit at gcc dot gnu.org]

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)

[Bug target/97252] arm: ICE compiling pure-code/pr94538-2.c with MVE since r10-7293-g3eff57aa

[acoplan at gcc dot gnu.org]

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.