https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64172
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P2
--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to jos...@codesourcery.com from comment #9)
> On Thu, 4 Dec 2014, ktkachov at gcc dot gnu.org wrote:
>
> > Hmm, is passing vectors around when vector instructions are not present
> > expected to work?
>
> All you need to conform to the VFP AAPCS variant is loads/stores. Even
> single-precision-only VFP has the required loads/stores to support that
> AAPCS variant.
>
> When fixing up various problems in an early version of the VFP ABI support
> patch some years ago, one of the things I implemented was making sure
> generic vector types would be passed the same (which would be the same as
> the corresponding NEON vector types) whether or not NEON instructions were
> available. In the current version of the code, I think what's relevant is
> in aapcs_vfp_sub_candidate:
>
> case VECTOR_TYPE:
> /* Use V2SImode and V4SImode as representatives of all 64-bit
> and 128-bit vector types, whether or not those modes are
> supported with the present options. */
>
> The test in the present bug doesn't even seem to have vectors as function
> arguments / returns so the ABI shouldn't even be involved - I'd have
> expected the generic vector code to be lowered completely to non-vector
> code before the back end gets involved.
That indeed happens if the target doesn't provide optabs with vector modes.
See tree-vect-generic.c.
