On Fri, Jun 08, 2018 at 04:01:14PM -0500, Steve Ellcey wrote:
> I have a question about the Aarch64 simd instructions and builtins.
>
> I want to unpack a __Float32x4 (V4SF) variable into two __Float64x2
> variables. I can get the upper part with:
>
> __Float64x2_t a = __builtin_aarch64_vec_unpacks_hi_v4sf (x);
>
> But I can't seem to find a builtin that would get me the lower half.
> I assume this is due to the issue in aarch64-simd.md around the
> vec_unpacks_lo_<mode> instruction:
>
> ;; ??? Note that the vectorizer usage of the vec_unpacks_[lo/hi] patterns
> ;; is inconsistent with vector ordering elsewhere in the compiler, in that
> ;; the meaning of HI and LO changes depending on the target endianness.
> ;; While elsewhere we map the higher numbered elements of a vector to
> ;; the lower architectural lanes of the vector, for these patterns we want
> ;; to always treat "hi" as referring to the higher architectural lanes.
> ;; Consequently, while the patterns below look inconsistent with our
> ;; other big-endian patterns their behavior is as required.
>
> Does this mean we can't have a __builtin_aarch64_vec_unpacks_lo_v4sf
> builtin that will work in big endian and little endian modes?
> It seems like it should be possible but I don't really understand
> the details of the implementation enough to follow the comment and
> all its implications.
>
> Right now, as a workaround, I use:
>
> static inline __Float64x2_t __vec_unpacks_lo_v4sf (__Float32x4_t x)
> {
> __Float64x2_t result;
> __asm__ ("fcvtl %0.2d,%1.2s" : "=w"(result) : "w"(x) : /* No clobbers */);
> return result;
> }
>
> But a builtin would be cleaner.
Hi Steve,
Are you in an environment where you can use arm_neon.h ? If so, that would
be the best approach:
float32x4_t in;
float64x2_t low = vcvt_f64_f32 (vget_low_f64 (in));
float64x2_t high = vcvt_high_f64_f32 (in);
If you can't use arm_neon.h for some reason, you can look there for
inspiration of how to write your own versions of these intrinsics.
Thanks,
James
