[Bug target/102252] New: svbool_t with SVE can generate invalid assembly

[Bug target/102252] New: svbool_t with SVE can generate invalid assembly

[gilles.gouaillardet at gmail dot com]

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

            Bug ID: 102252
           Summary: svbool_t with SVE can generate invalid assembly
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gilles.gouaillardet at gmail dot com
  Target Milestone: ---

Created attachment 51429
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51429&action=edit
a simple reproducer

Let's consider the attached test_svbool.cpp and compile it with SVE fixed 512
bits:

$ g++ -march=armv8.2-a+sve -msve-vector-bits=512 -c test_svbool.cpp 
/tmp/cc38qRcE.s: Assembler messages:
/tmp/cc38qRcE.s:44: Error: invalid addressing mode at operand 2 -- `ldr
p0,[x0,x1,lsl 3]'

The generated assembly is invalid and cannot be assembled.

All branches that support SVE (10, 11 and 12) are affected.

FWIW, the code compiles just fine with LLVM 12, 13 and main branches.
This code is a trimmed version of an improvement for GROMACS.

[Bug target/102252] svbool_t with SVE can generate invalid assembly

[gilles.gouaillardet at gmail dot com]

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

--- Comment #1 from Gilles Gouaillardet <gilles.gouaillardet at gmail dot com> ---
Created attachment 51430
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51430&action=edit
a test that works

FWIW, the attached test_svfloat.cpp passes.
It is very similar to test_svbool.cpp but it "abstracts" a svfloat32_t instead
of a svbool_t.

[Bug target/102252] svbool_t with SVE can generate invalid assembly

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-09-09
             Status|UNCONFIRMED                 |NEW
                 CC|                            |ktkachov at gcc dot gnu.org
             Target|                            |aarch64
     Ever confirmed|0                           |1

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Confirmed.

[Bug target/102252] svbool_t with SVE can generate invalid assembly

[ktkachov at gcc dot gnu.org]

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
The RTL for the offending insn:

(insn 9 8 10 (set (reg:VNx16BI 68 p0)
        (mem:VNx16BI (plus:DI (mult:DI (reg:DI 1 x1 [93])
                    (const_int 8 [0x8]))
                (reg/f:DI 0 x0 [92])) [2 work_3(D)->array[offset_4(D)]+0 S8
A16])) "asm.c":29:29 4465 {*aarch64_sve_movvnx16bi}
     (nil))

That addressing mode isn't valid for predicate loads.
In aarch64.c:aarch64_classify_address if we set allow_reg_index_p to false when
vec_flags & VEC_SVE_PRED that fixes it, but will need more testing

[Bug target/102252] svbool_t with SVE can generate invalid assembly

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |ktkachov at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Testing a patch

[Bug target/102252] svbool_t with SVE can generate invalid assembly

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Kyrylo Tkachov <ktkachov@gcc.gnu.org>:

https://gcc.gnu.org/g:512b383534785f9fc021e700a1fdda86cf0f3fe7

commit r12-3490-g512b383534785f9fc021e700a1fdda86cf0f3fe7
Author: Kyrylo Tkachov <kyrylo.tkachov@arm.com>
Date:   Mon Sep 13 15:40:28 2021 +0100

    aarch64: PR target/102252 Invalid addressing mode for SVE load predicate

    In the testcase we generate invalid assembly for an SVE load predicate
instruction.
    The RTL for the insn is:
    (insn 9 8 10 (set (reg:VNx16BI 68 p0)
            (mem:VNx16BI (plus:DI (mult:DI (reg:DI 1 x1 [93])
                        (const_int 8 [0x8]))
                    (reg/f:DI 0 x0 [92])) [2 work_3(D)->array[offset_4(D)]+0 S8
A16]))

    That addressing mode is not valid for the instruction [1] as it only
accepts the addressing mode:
    [<Xn|SP>{, #<imm>, MUL VL}]

    This patch rejects the register index form for SVE predicate modes.

    Bootstrapped and tested on aarch64-none-linux-gnu.

    [1]
https://developer.arm.com/documentation/ddi0602/2021-06/SVE-Instructions/LDR--predicate---Load-predicate-register-

    gcc/ChangeLog:

            PR target/102252
            * config/aarch64/aarch64.c (aarch64_classify_address): Don't allow
            register index for SVE predicate modes.

    gcc/testsuite/ChangeLog:

            PR target/102252
            * g++.target/aarch64/sve/pr102252.C: New test.

[Bug target/102252] svbool_t with SVE can generate invalid assembly

[gilles.gouaillardet at gmail dot com]

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

--- Comment #6 from Gilles Gouaillardet <gilles.gouaillardet at gmail dot com> ---
I am happy to confirm this issue is fixed in the latest 12-20210919 snapshot
:-)

FWIW, I was not yet able to build GROMACS because of an other issue that was
introduced last week. I reported it at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102421

[Bug target/102252] svbool_t with SVE can generate invalid assembly

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.0
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Fixed.