On Wed, Mar 23, 2011 at 3:13 PM, Richard Sandiford
<richard.sandif...@linaro.org> wrote:
> Richard Guenther <richard.guent...@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.
So the 3-element-array-of-vector type has the vector mode of a single
element? I'm confused. I also don't see how a user could want to
have a non-BLK mode on such array types (consider them being
part of a struct - how would that affect argument passing and other
ABI details?).
> 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.
Well, I meant if the user compiles with -msse, declares such a
global var (which means it gets V4SFmode and not BLKmode)
and then uses it in a function where he explicitly disables SSE
then something is wrong. If he declares a BLKmode global
then generic vector support will happily trigger and make it work.
I realize this is all a bit tricky and probably nobody properly designed
the target attribute stuff with all these details in mind. But now
we have to live with it ... :(
>> 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.
True. But I like the idea of TYPE_MODE becoming even more "dynamic"
even less.
If it's just three element array-of-vector types you need why not expose
it via attribute((mode(xyz))) only? You could alias that mode to BLKmode
if neon is not enabled ...
Richard.
