This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: casting "extended vectors"


On 6 Jul, 2014, at 3:45 PM, Marc Glisse <marc.glisse@inria.fr> wrote:

> On Sat, 5 Jul 2014, Vincenzo Innocente wrote:
> 
>> at the end of
>> https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html
>> I read
>> "It is possible to cast from one vector type to another, provided they are of the same size"
>> 
>> when I try, it looks to me that it is actually more a type-punning rather than a C-style cast.
> 
> Indeed, I am not happy about that, but it seems hard to change that now.
Understand.
> If you could send a patch to gcc-patches improving the documentation, it would be welcome.
I will try to think of something (maybe use "reinterpret" insted of cast, as in c++ reinterpret_cast.) 
The point is that there is no (more?) any equivalent for  C/C++ type
Of course adding __builtin_convertvector and its doc will ease to clarify the issue
> 
> 
>> Is it possible to cast “vectors”  as in C one casts intrinsic types?
> 
> Not directly, no. You can cast element by element and hope gcc will vectorize it, but I don't even think that is likely.
     VF convert(itype i) { VF f; for (int j=0;j<N;++j) f[j]=i[j]; return f;}
    itype convert(VF f) { itype i; for (int j=0;j<N;++j) i[j]=f[j]; return i;}
vectorize for N=8  and N=16, does not vectorize for N=4 (independently of the target architecture)

> 
> From a language point of view, clang recently introduced __builtin_convertvector. It takes a type as second parameter, that may be an issue if we try to implement the same in gcc.
strange syntax indeed. of course in c++ would be trivial…  "__builtin_convertvector<T>”
It that would be a very welcome addition whatever syntax you choose/manage-to-implement

If you can also try to add something for “movemask” would be also great!

Vincenzo
> 
> From an implementation point of view, we seem to have most (all?) pieces (float_expr, vec_unpack_hi_expr, etc) to represent those in the middle-end.
> 
> -- 
> Marc Glisse

-

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]