Re: RFC: Representing vector lane load/store operations

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

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?

Richard