[PATCH] D77074: [FPEnv][AArch64] Platform-specific builtin constrained FP enablement

[Diogo N. Sampaio via Phabricator via cfe-commits]

dnsampaio added inline comments.


================
Comment at: clang/lib/CodeGen/CGBuiltin.cpp:8486-8492
+      return Builder.CreateConstrainedFPCall(
+          F,
+          {EmitScalarExpr(E->getArg(1)), EmitScalarExpr(E->getArg(2)), Ops[0]});
+    } else {
+      Function *F = CGM.getIntrinsic(Intrinsic::fma, HalfTy);
+      // NEON intrinsic puts accumulator first, unlike the LLVM fma.
+      return Builder.CreateCall(F, {EmitScalarExpr(E->getArg(1)),
----------------
It seems that `Builder.CreateCall` and `Builder.CreateConstrainedFPCall` usually have the same arguments, except for the function F being or not part of "experimental_constrained_".
Would it make sense to teach the `Builder` to select between creating a constrained or not call, depending if the function passed is constrained?

I was thinking in something like this:
```
Function *F = CGM.getIntrinsic( Builder.getIsFPConstrained()?
                                                        Intrinsic::experimental_constrained_fma :
                                                        Intrinsic::fma, HalfTy);
return Builder.CreateCallConstrainedFPIfRequired(F, ....
```



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77074