Re: RFC: Representing vector lane load/store operations

[Richard Guenther <richard.guenther@gmail.com>]

On Wed, Mar 23, 2011 at 11:38 AM, Richard Sandiford
<richard.sandiford@linaro.org> wrote:
> Richard Guenther <richard.guenther@gmail.com> writes:
>> But as you have partial defs of the vector lane array the simplest
>> approach is probably to not make them a register.  Be prepared
>> for some surprises during RTL expansion though ;)
>
> OK.  It's there I'd like to start, specifically with:
>
>  These arrays of vectors would still need to have a non-BLK mode,
>  so that they can be stored in _rtl_ registers.  But we need that anyway
>  for ARM's arm_neon.h; the code that today's GCC produces for the intrinsic
>  functions is very poor.
>
> because I'd like to fix the bad code we generate for intrinsics.
>
> Thing is, this is going to be another case where the mode of a type
> depends on the current target.  E.g. on ARM, we don't want to use
> a 24-byte mode for an array of 3 2xSI vectors unless V2SI is also
> available.  Both the mode of the vector type and the mode of the
> array type will therefore depend on whether Neon is enabled.
>
> I know you don't like the way we handle TYPE_MODE for vectors:
>
>  #define TYPE_MODE(NODE) \
>    (TREE_CODE (TYPE_CHECK (NODE)) == VECTOR_TYPE \
>     ? vector_type_mode (NODE) : (NODE)->type.mode)
>
> so I'm guessing you wouldn't be too happy to see ARRAY_TYPE popping
> up there as well. :-)  What's the best way of handling this?

I'd say use either DECL_MODE at the point where we decide on
expanding vars (setting it from a target hook), or simply ask such
a hook at expansion time.  That should have worked for the target
atttribute stuff as well instead of dispatching in TYPE_MODE (types
are global and TYPE_MODE with the target attribute depends on
the context, but decls are local to the declaration context, so the
mode persists and is not dependent on the attribute). Might
need some surgery in places where we assume TYPE_MODE == DECL_MODE,
but I suspect it's mostly around RTL expansion.

Richard.

> Richard
>