Aarch64 / simd builtin question

Aarch64 / simd builtin question

[Steve Ellcey]

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.

Steve Ellcey
sellcey@cavium.com

Re: Aarch64 / simd builtin question

[James Greenhalgh]

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

Re: Aarch64 / simd builtin question

[Steve Ellcey]

On Fri, 2018-06-08 at 22:34 +0100, James Greenhalgh wrote:
> 
> 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

Thanks, that is helpful though I think you meant vget_low_f32 in
the first line instead of vget_low_f64.  With that change I get the
code I want/expect.  I hadn't seen the __GETLOW macro in the neon
header file.

Steve Ellcey