Re: [ARM/hard_vfp_4_4_branch] Fix VFP ABI for generic vectors without NEON

[Richard Earnshaw <rearnsha at arm dot 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  <joseph@codesourcery.com>
> 
> 	* 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
> 	non-TARGET_NEON.
> 	(aapcs_vfp_allocate_return_reg): Likewise.
> 	(arm_vector_mode_supported_p): Only support V2SImode, V4HImode and
> 	V8QImode if TARGET_NEON || TARGET_IWMMXT.
> 

OK.

R.