Re: patch: Re: rfc: auto-casted vector types

[Kumar Gala <kumar dot gala at motorola dot com>]

> I thought about this some more, and I believe I see where the 
> underlying problem lies.  Nick (or Jim), please correct me if I'm 
> wrong, since you wrote the code in question.
>
> The reason we have the following line:
>
> 	+   return t1 == V2SI_type_node || t2 == V2SI_type_node;
>
> is because most of the builtins return V2SI:
>
> 	#define __ev_addw(a,b) __builtin_spe_evaddw((__v2si) (a), (__v2si) 
> (b))
>
> and we want to be able to assign their value to any other simd type 
> without a cast.  The API actually has a definition of __ev_addw() like 
> thus:
>
> 	__ev64_opaque__ __ev_addw(__ev64_opaque, __ev64_opaque__);
>
> __ev_addw is supposed to return an opaque type so we can copy it to 
> and fro without a cast.  Since __builtin_spe_evaddw returns a V2SI, we 
> have the aforementioned line to ensure it behaves like an opaque 
> (return t1 == V2SI, etc).
>
> So... instead of hacking all over the place in perhaps the .md and .c 
> file, why don't we instead cast the return types of all the builtins 
> to __ev64_opaque__, and then remove the offending line Geoff pointed 
> out.  Like this:
>
> 	#define __ev_addw(a,b) (__v2si)__builtin_spe_evaddw(etc, etc)
>
> BTW, __v2si is just a macro define for __ev64_opaque__.
>
> This way we only change the user include file, remove one line from 
> rs6000_spe_vector_types_compatible(), and leave everything as is :-).

Sounds reasonable, but what I thought your last set of changes removes 
the need to do any casts between the various V... modes.  Is this not 
true?  If so, why are the casts required at all?

- kumar