[clang] [CIR][AArch64] Lower vfma and scalar FMA lane builtins (PR #204819)

[Yair Ben Avraham via cfe-commits]

================
@@ -83,7 +167,7 @@ float32x4_t test_vfmaq_lane_f32(float32x4_t a, float32x4_t b, float32x2_t v) {
 // LLVM-NEXT: [[V_BYTES:%.*]] = bitcast <2 x i32> [[V_I]] to <8 x i8>
 // LLVM:      [[V_CAST:%.*]] = bitcast <8 x i8> [[V_BYTES]] to <2 x float>
 // LLVM-NEXT: [[LANE:%.*]] = shufflevector <2 x float> [[V_CAST]], <2 x float> {{.*}}, <4 x i32> <i32 1, i32 1, i32 1, i32 1>
-// LLVM:      [[FMA:%.*]] = call <4 x float> @llvm.fma.v4f32(<4 x float> [[B_CAST:%.*]], <4 x float> [[LANE]], <4 x float> [[A_CAST:%.*]])
+// LLVM:      [[FMA:%.*]] = call <4 x float> @llvm.fma.v4f32(<4 x float> {{.*}}, <4 x float> [[LANE]], <4 x float> {{.*}})
----------------
yairbenavraham wrote:

IIUC, the previous inline captures, e.g. `[[B_CAST:%.*]]` / `[[A_CAST:%.*]]` inside the `llvm.fma` call (where lane-source cast/shuffle is involved), made the check look stronger but did not actually prove that those operands came from `b` and `a`. Replacing them with `{{.*}}` is weaker, but avoids suggesting as if I am checking operand provenance when it is only naming the call operands.

A stronger form would be (again, to my current understanding) to define `[[B_CAST]]` and `[[A_CAST]]` on the actual bitcast lines from `[[B_BYTES]]` and `[[A_BYTES]]`, then use those names in the `llvm.fma` call. The complication is that direct LLVM IR and CIR-to-LLVM emit these casts in a different relative order for the lane forms, while this file currently uses a shared `LLVM` prefix for both RUN lines.

Would using `LLVM-DAG` for the order-insensitive bitcast setup be acceptable here? That would keep the current RUN lines unchanged while still allowing the `llvm.fma` call to check the exact `b, lane, a` operands.

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