Re: RFC: Representing vector lane load/store operations

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

Richard Guenther <richard.guenther@gmail.com> writes:
>>> For your case in question the vectorizer would create local vars with
>>> that mode, knowing it is supported, so I don't see big problems for
>>> that particular case.
>>
>> The problem is that I'd like to use this for intrinsics as well as for
>> automatic vectorisation.  E.g. I'd like:
>>
>> typedef struct int8x16x4_t
>> {
>>  int8x16_t val[4];
>> } int8x16x4_t;
>>
>> to have non-BLKmode as well.  arm_neon.h uses this type of structure
>> to represent compounds vectors.  But once the type is defined (with Neon
>> support enabled), there's nothing to stop someone using the type
>> (not the intrinsics) in a function that has Neon disabled.  We mustn't
>> use the special mode in such cases, because there aren't enough GPRs to
>> store it.  It should be treated as BLKmode instead.  Which I suppose
>> is the same situation as...
>
> I'd use non-BLKmode for the above unconditionally.

But without Neon, there aren't enough registers to store the structure.
Any use of the Neon mode would just lead to a reload failure.  Even if
we think it's not sensible to use the type without Neon, we need a better
diagnostic than that.

So I think this mode has to be conditional in exactly the way that
vector modes are, or be subject to the same diagnostics that you
were suggesting for 128-bit types.

I was actually thinking along the lines of having a target hook such as:

   array_mode_supported_p (tree elemtype, unsigned HOST_WIDE_INT size)

which would return true if ELEMTYPE[SIZE] should use non-BLKmode where
possible.  When it returns true, we'd pass 0 rather than 1 to this
mode_for_size_tree call (from the ARRAY_TYPE case in layout_type):

	    /* One-element arrays get the component type's mode.  */
	    if (simple_cst_equal (TYPE_SIZE (type),
				  TYPE_SIZE (TREE_TYPE (type))))
	      SET_TYPE_MODE (type, TYPE_MODE (TREE_TYPE (type)));
	    else
	      SET_TYPE_MODE (type, mode_for_size_tree (TYPE_SIZE (type),
						       MODE_INT, 1));

This would have the "advantage" (as I see it) of working with the
generic vector extensions too.  E.g. if a user defines their own
3-element-array-of-vector type, they would benefit from the same
handling as the Neon-specific intrinsics and the vectoriser-generated
arrays.

We still make generic vectors available when there's no underlying
hardware support, so I'd have expected these 3-element-array-of-vector
types to be available too.  That's why I prefer the idea of making the
mode conditional, as for vector types, rather than rejecting uses of
the type outright.

But from this:

> I'd say if somebody writes
>
> v4sf float_vec;
>
> void __attribute__((target("no-sse")))
> foo (void)
> {
>   float_vec += float_vec;
> }
>
> he deserves to get a diagnostic.  Thus, even for global decls I think we
> can reject such uses.  Complication arises whenever we do not see
> a decl, like for
>
> void foo(v4sf *x)
> {
> }
>
> which we could of course reject (at function definition time) if an
> unsupported type is used in this way.  But the function might
> not even dereference that pointer ...

it sounds like you think there's no point supporting generic vectors
when no underlying hardware support is available.

> And I still think that only changing DECL_MODEs based on
> target attributes and not TYPE_MODEs is appealing ;)

Understood.  I just think that, if we do that, we really should
get rid of TYPE_MODE (as a global property) as well, otherwise there'd
be even more chaos than there is now.  And that sounds like it could
be several months' work in itself.

Richard