================
@@ -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
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
