This is the mail archive of the
mailing list for the GCC project.
Re: [ARM/hard_vfp_4_4_branch] Fix VFP ABI for generic vectors without NEON
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 12 May 2009 17:19:07 +0100
- Subject: Re: [ARM/hard_vfp_4_4_branch] Fix VFP ABI for generic vectors without NEON
- References: <Pine.LNX.email@example.com>
On Tue, 2009-05-12 at 13:43 +0000, Joseph S. Myers wrote:
> This patch, against ARM/hard_vfp_4_4_branch, fixes problems with the
> handling of generic vectors with the VFP ABI but without NEON.
> If -mfloat-abi=hard is used with -mfpu=neon, generic GCC vectors
> created with the vector_size attribute get vector modes (if NEON has
> suitable modes) and are handled like NEON vectors, being passed and
> returned in VFP/NEON registers in accordance with the VFP ABI.
> If -mfloat-abi=hard is used without -mfpu=neon, without this patch,
> generic GCC vectors may or may not get vector modes. The only vector
> modes they may get are V2SImode, V4HImode and V8QImode, which the ARM
> back end declares it supports in that case (probably for historical
> reasons because they are the iWMMXt vector modes). Other vectors will
> get DImode, TImode or BLKmode. Vectors getting vector modes will be
> handled by the VFP ABI code as vectors; it will attempts to pass them
> in VFP registers, resulting in ICEs because the relevant move patterns
> are only enabled for NEON; TImode moves can also result in ICEs, again
> because the move patterns are only enabled for NEON. Vectors not
> getting vector modes will not be handled as vectors, leading to
> undesirable ABI incompatibilities between code built with and without
> -mfpu=neon; we concluded in previous off-list discussion that it was
> best for generic vectors to be handled (for ABI purposes) like NEON
> vectors of the same size whether or not NEON is enabled.
> This patch fixes these problems. The VFP ABI code now handles all
> 64-bit and 128-bit vectors without regard to whether they got vector
> modes. The back end no longer claims to support the iWMMXt modes if
> neither iWMMXt nor NEON is enabled, and the argument passing / return
> code splits up TImode vectors as needed into DImode pieces that the
> VFP move patterns know how to handle.
> (The compiler already has a sorry ("iWMMXt and hardware floating
> point"), so we don't need to worry about the VFP and iWMMXt
> combination, though I don't think anything in this patch should break
> that combination further.)
> Tested with no regressions with cross to arm-none-eabi; this also
> fixes ICEs on g++.dg-struct-layout-1/t026,
> gcc.c-torture/execute/simd-6.c, gcc.dg/compat/vector-1. OK to commit
> to the branch?
> 2009-05-12 Joseph Myers <firstname.lastname@example.org>
> * config/arm/arm.c (aapcs_vfp_sub_candidate): Use V2SImode and
> V4SImode as representatives of all 64-bit and 128-bit vector
> types. Allow vector types without vector modes.
> (aapcs_vfp_is_call_or_return_candidate): Handle vector types
> without vector modes like BLKmode.
> (aapcs_vfp_allocate): Handle TImode for non-TARGET_NEON like
> BLKmode. Avoid unsupported vector modes or TImode moves for
> (aapcs_vfp_allocate_return_reg): Likewise.
> (arm_vector_mode_supported_p): Only support V2SImode, V4HImode and
> V8QImode if TARGET_NEON || TARGET_IWMMXT.