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

[stammark at gcc dot gnu.org via Gcc-bugs]

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

Stam Markianos-Wright  changed:

   What|Removed |Added

 CC||stammark at gcc dot gnu.org
 Status|NEW |ASSIGNED

--- Comment #4 from Stam Markianos-Wright  ---
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_ which was only enabled for mve.fp

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

mve_vec_extract
*mve_vec_extract_sext_internal
*mve_vec_extract_zext_internal
mve_vec_set_internal
*movmisalign_mve_store
*movmisalign_mve_load

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

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

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

[rearnsha at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Richard Earnshaw  ---
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

[rearnsha at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Richard Earnshaw  ---
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

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  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  ---
Confirmed.

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

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  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