Re: RFC: Representing vector lane load/store operations

[Richard Sandiford <richard.sandiford@linaro.org>]

Richard Guenther <richard.guenther@gmail.com> writes:
> 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.

Hmm, but if we do that, when is it correct to look at TYPE_MODE?

E.g. when expanding the new __builtin_load_lanes function described
earlier, it wouldn't be valid to base the target register's mode on
TYPE_MODE, so I suppose we'd have to call the hook instead.  And if we
did revert the TYPE_MODE change for vector types, the vector optabs
would need to do the same thing.  Wouldn't we just end up replacing
most/all uses of TYPE_MODE with calls to the hook?  What would any
remaining uses of TYPE_MODE actually be testing?

E.g. I suppose we really ought to do the same thing for 128-bit types,
since this:

    /* TODO: This isn't correct, but as logic depends at the moment on
       host's instead of target's wide-integer.
       If there is a target not supporting TImode, but has an 128-bit
       integer-scalar register, this target check needs to be adjusted. */
    if (targetm.scalar_mode_supported_p (TImode))
      {
        int128_integer_type_node = make_signed_type (128);
        int128_unsigned_type_node = make_unsigned_type (128);
      }

seems to apply one value of scalar_mode_supported_p to the whole compilation.
(TImode support seems to depend on TARGET_ZARCH for s390.)

Richard