================
Comment at: utils/TableGen/NeonEmitter.cpp:1553-1554
@@ -1517,3 +1552,4 @@
case OpMlaLane:
+ case OpFMALane:
s += "__a + (__b * " + SplatLane(nElts, "__c", "__d") + ");";
break;
----------------
Tim Northover wrote:
> Sorry, I should have spotted this earlier, but I think that an fma is
> semantically distinct from the C expression "a+b*c".
>
> The latter we *can* transform into an fma in -ffast-math mode, but not
> generally. So we probably need an intrinsic to make sure that if the user
> asks for a fused multiply, that's the operation they get.
>
> Actually, there'a already a generic llvm intrinsic to handle this:
> "@llvm.fma.*"; we should probably use that rather than an
> ARM/AArch64-specific one.
Tim,
I see your point, so do you mean we must generate fmla instruction for
intrinsic function vfma_lane_f32(), no matter if it is in -ffast-math mode or
not? Then I think we have to generate fmls for intrinsic function
vfms_lane_f32() as well. I don't see LLVM IR has @llvm.fms.* defined, so we
have to define an aarch64 specific LLVM intrinsic, or we can use an expression
containing llvm.fma.* to represent it? Since it's a fused calculation, I doubt
we should do the latter. I want to confirm with you before modifying the code.
Thanks,
-Jiangning
http://llvm-reviews.chandlerc.com/D1752
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
