[Bug target/100000] New: arm: Missed optimisation storing V4DF vector

[Bug target/100000] New: arm: Missed optimisation storing V4DF vector

[acoplan at gcc dot gnu.org]

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

            Bug ID: 100000
           Summary: arm: Missed optimisation storing V4DF vector
           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: ---

typedef float __attribute((vector_size(16))) v4sf;

v4sf f(v4sf *p)
{
    return *p;
}

gives:

f:
        vldrw.32        q0, [r0]
        sub     sp, sp, #32
        add     sp, sp, #32
        bx      lr

with -march=armv8.1-m.main+mve -mfloat-abi=hard -O2 but the sub/add is
redundant.

[Bug target/100000] non-leaf epologue/prologue used if MVE v4sf is used for load/return

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
            Summary|arm: Missed optimisation    |non-leaf epologue/prologue
                   |storing MVE V4SF vector     |used if MVE v4sf is used
                   |                            |for load/return

[Bug target/100000] non-leaf epologue/prologue used if MVE v4sf is used for load/return

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
      Known to fail|                            |10.2.1
   Last reconfirmed|                            |2021-12-09

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.

[Bug target/100000] non-leaf epologue/prologue used if MVE v4sf is used for load/return

[rearnsha at gcc dot gnu.org]

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

--- Comment #2 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
If the testcase is built with -march=armv8.1-m.main+mve.fp then the useless
stack adjustments go away.  I think that's because V4SFmode is not a supported
vector mode for integer MVE - see arm_vector_mode_supported_p() in arm.cc. 
When it isn't a builtin type we end up with a BLKmode object that the compiler
creates a stack-slot for, even though no RTL is ever generated to use the slot
in this case.

[Bug target/100000] non-leaf epologue/prologue used if MVE v4sf is used for load/return

[rearnsha at gcc dot gnu.org]

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

--- Comment #3 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
Given that the hard-float ABI essentially requires V4SF as a type, it might be
better to consider this mode supported unconditionally in this case, and
although that might make the compiler try some pointless vectorizations it
would generate better code for cases like this.

[Bug target/100000] non-leaf epologue/prologue used if MVE v4sf is used for load/return

[stammark at gcc dot gnu.org]

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

Stam Markianos-Wright <stammark at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |stammark at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #4 from Stam Markianos-Wright <stammark at gcc dot gnu.org> ---
I tried out Richard's suggestion in arm_vector_mode_supported_p (allowing V8HF,
V4SF and V2DF unconditionally) and it seems to have worked! After a testsuite
run I found a few ICEs due to a number of patterns that needed enabling:

@mve_vpselq_<supf><mode> which was only enabled for mve.fp

And then all the patterns that were conditional on:
-  "((TARGET_HAVE_MVE && VALID_MVE_SI_MODE (<MODE>mode))
-    || (TARGET_HAVE_MVE_FLOAT && VALID_MVE_SF_MODE (<MODE>mode)))

mve_vec_extract<mode><V_elem_l>
*mve_vec_extract_sext_internal<mode>
*mve_vec_extract_zext_internal<mode>
mve_vec_set<mode>_internal
*movmisalign<mode>_mve_store
*movmisalign<mode>_mve_load

These weren't causing any ICEs but also made sense to enable:
mve_vst2q<mode>
mve_vld2q<mode>
mve_vld4q<mode>

No regressions after that, but I think I will hold off until GCC14 Stage 1 to
post this patch, just to be safe.