This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: casting "extended vectors"
- From: Vincenzo Innocente <vincenzo dot innocente at cern dot ch>
- To: <gcc-help at gcc dot gnu dot org>
- Date: Sun, 6 Jul 2014 16:32:10 +0200
- Subject: Re: casting "extended vectors"
- Authentication-results: sourceware.org; auth=none
- References: <B4ED95BB-BB4D-4771-9423-B84DE9C9BE4C at cern dot ch> <alpine dot DEB dot 2 dot 11 dot 1407061523020 dot 1893 at laptop-mg dot saclay dot inria dot fr>
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
-