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)),
----------------
kpn wrote:
> dnsampaio wrote:
> > 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, ....
> > ```
> >
> In CGBuiltins.cpp we already have emitUnaryMaybeConstrainedFPBuiltin() plus
> Binary and Ternary. They work well for the pattern seen on other hosts. But
> they won't easily work for this ticket.
>
> How about a new function just below those three that will work well here? A
> emitCallMaybeConstrainedFPBuiltin() that takes two intrinsic IDs and chooses
> which one based on constrained FP would make for an even more compact use.
> The block of example code you put above would just turn into a single
> function call. Does that work for you?
Sounds good to me.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D77074/new/
https://reviews.llvm.org/D77074
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
