[llvm] [AArch64] Codegen for new SCVTF/UCVTF variants (FEAT_FPRCVT) (PR #123767)

Virginia Cangelosi via llvm-commits llvm-commits at lists.llvm.org
Wed Jan 22 07:35:47 PST 2025


================
@@ -0,0 +1,159 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py UTC_ARGS: --version 5
+; RUN: llc -mattr=+neon,+fprcvt -verify-machineinstrs %s -o - | FileCheck %s
+; RUN: llc -mattr=+neon -verify-machineinstrs %s -o - | FileCheck %s --check-prefix=CHECK-NO-FPRCVT
+
+target triple = "aarch64-unknown-linux-gnu"
+
+
+; To demonstrate what we have implemented, we'll want a scalar integer value in a SIMD/FP register.
+; A common case for this setup is when using the result of an integer reduction intrinsic.
+
+; SCVTF
+
+define half @scvtf_f16i32(<4 x i32> %x) {
+; CHECK-LABEL: scvtf_f16i32:
+; CHECK:       // %bb.0:
+; CHECK-NEXT:    addv s0, v0.4s
+; CHECK-NEXT:    scvtf h0, s0
+; CHECK-NEXT:    ret
+;
+; CHECK-NO-FPRCVT-LABEL: scvtf_f16i32:
+; CHECK-NO-FPRCVT:       // %bb.0:
+; CHECK-NO-FPRCVT-NEXT:    addv s0, v0.4s
+; CHECK-NO-FPRCVT-NEXT:    scvtf s0, s0
+; CHECK-NO-FPRCVT-NEXT:    fcvt h0, s0
----------------
virginia-cangelosi wrote:

Ok I will replace the .neon.saddv lines in the tests, I agree that it will make them clearer.

When I add these patterns it still uses the old versions of scvtf as it prioritises them (i think the priority is just the order they appear in the file for now)
  def : Pat<(f16 (op (i32 FPR32:$Rn))),
          (!cast<Instruction>(NAME # HSr) $Rn)>;
note: op resolves to any_{u,s}int_to_fp

https://github.com/llvm/llvm-project/pull/123767


More information about the llvm-commits mailing list