[PATCH] D127158: [AArch64] Add intrinsic support for gpr<->fpr flavors of fixed-point converts

[Rob McClure via Phabricator via llvm-commits]

rmcclure added a comment.

In D127158#3566948 <https://reviews.llvm.org/D127158#3566948>, @dmgreen wrote:

> Hello - Can you give more details about why we want these to be added? Are we missing ACLE intrinsics that clang doesn't have, or are some intrinsics broken? I don't see definitions for vcvtd_n_f64_s32 in the ACLE for example.

The main goal is just to expose these instructions to anyone who might want them, since they expose functionality that isn't available with the existing intrinsic support.

I agree that `vcvtd_n_f64_s32` doesn't exist, but `vcvth_n_s64_f16` does, for example, which is where things get a bit more interesting.

In mainline, LLVM currently produces something like the following:

  fcvtzs  h0, h0, #10
  fmov    x0, d0

This technically matches what the ACLE lists as the generated instruction (`FCVTSZ Hd,Hn,#n`), but that seems wrong to me - it drops the sign information from the result (e.g. converting -1.0f produces a positive result).
For comparison, after this change, LLVM generates:

  fcvtzs  x0, h0, #10

which preserves the sign information. It also supports results that exceed the range of a 16-bit integer, which also seems sensible.

As two other points of reference:
For the example above, GCC also generates `fcvtzs  x0, h0, #10`
For `vcvth_s64_f16` (the fp->integer flavor), mainline LLVM (and GCC) generates `fcvtzs x0, h0`, which technically violates the ACLE spec in the same way I described above (it expects `FCVTZ Hd,Hn`), so making the fixed-point<->fp converts behave similarly seems reasonable.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127158/new/

https://reviews.llvm.org/D127158