Richard Guenther <richard.guent...@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...
> 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...
> > 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.
Richard
