[llvm-dev] Condition code in DAGCombiner::visitFADDForFMACombine?

Ryan Taylor via llvm-dev llvm-dev at lists.llvm.org
Tue Aug 21 07:08:42 PDT 2018


So I have a test case where:

%20 = fmul nnan arcp float %15, %19
%21 = fadd reassoc nnan arcp contract float %20, -1.000000e+00

is being contracted in DAG to fmad. Is this correct since the fmul has no
reassoc or contract fast math flag?

Thanks.

On Mon, Aug 20, 2018 at 12:56 PM Ryan Taylor <ryta1203 at gmail.com> wrote:

> I'm curious why the condition to fuse is this:
>
> // Floating-point multiply-add with intermediate rounding.
>   bool HasFMAD = (LegalOperations && TLI.isOperationLegal(ISD::FMAD, VT));
>
> static bool isContractable(SDNode *N) {
>   SDNodeFlags F = N->getFlags();
>   return F.hasAllowContract() || F.hasAllowReassociation();
> }
>
> bool CanFuse = Options.UnsafeFPMath || isContractable(N);
> bool AllowFusionGlobally = (Options.AllowFPOpFusion == FPOpFusion::Fast ||
> CanFuse || HasFMAD);
> // If the addition is not contractable, do not combine.
> if (!AllowFusionGlobally && !isContractable(N))
>     return SDValue();
>
> Specifically the AllowFusionGlobally, I would have expected something more
> like:
>
> bool AllowFusionGlobally = (Options.AllowFPOpFusion == FPOpFusion::Fast &&
> CanFuse && HasFMAD);
>
> or at the very least:
>
> bool AllowFusionGlobally = ((Options.AllowFPOpFusion == FPOpFusion::Fast
> || CanFuse) && HasFMAD);
>
> It seems that as long as the target can do fmad it does do fmad since
> HasFMAD is true.
>
> Thanks.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180821/2b30f2c4/attachment.html>


More information about the llvm-dev mailing list