Re: RFC: Representing vector lane load/store operations

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

On Wed, Mar 23, 2011 at 2:01 PM, Richard Sandiford
<richard.sandiford@linaro.org> wrote:
> Richard Guenther <richard.guenther@gmail.com> writes:
>>> Hmm, but if we do that, when is it correct to look at TYPE_MODE?
>>
>> Most of the tree passes shouldn't care about TYPE_MODE (nor
>> DECL_MODE) and on RTL we shouldn't need to care about trees.
>
> It sounds like you think it would be better to get rid of TYPE_MODE.
> I can see why that's appealing, but it also sounds very ambitious :-)
> As well as all the uses in the middle-end, targets have (wrongly) tended
> to use type modes to define the ABI.  It might be quite difficult to
> untangle the whole mess now.
>
> Of course, that's also an argument in favour of what you say about
> TYPE_MODE not changing unless we can help it...

Indeed.

>> 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.

>> > 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.)
>>
>> Well, it depends on where int128_integer_type_node is used.  I think
>> if the target with some settings supports TImode then we probably
>> want to have that type node.  At the point the user declares some vars
>> with it you can error out dependent on local support. At expansion
>> time you'd need to check whether accesses in a given mode are
>> really "possible" and dispatch to BLKmode handling if they are not.
>
> ...this.  Do you mean that we'd error for local declarations, but fall
> back to BLKmode for operations on already-defined (global) declarations?
> I'm just worried that might be a bit inconsistent.

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 ...

That said, I think for your case in question we should set possible
target attribute issues aside (because we have those issues already).
In that case you wouldn't need to touch TYPE_MODE at all as
it would have non-BLKmode as soon as you create a vector-lane
type or decl?

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

Richard.