[PATCH] D26602: [DAGCombiner] do not fold (fmul (fadd X, 1), Y) -> (fmad X, Y, Y) by default

Nicolai Hähnle via llvm-commits llvm-commits at lists.llvm.org
Wed Nov 16 08:38:01 PST 2016


nhaehnle added a comment.

In https://reviews.llvm.org/D26602#594518, @spatel wrote:

> So let's use the codegen definitions since there's no hope of sorting out the connection to the higher-level definitions in this patch. :)
>
> 1. FPOpFusion::Fast - Enable fusion of FP ops wherever it's profitable.
> 2. UnsafeFPMath - This flag is enabled when the -enable-unsafe-fp-math flag is specified on the command line. When this flag is off (the default), the code generator is not allowed to produce results that are "less precise" than IEEE allows...UnsafeFPMath implies LessPreciseFPMAD.
> 3. LessPreciseFPMADOption - This flag is enabled when the -enable-fp-mad is specified on the command line.  When this flag is off (the default), the code generator is not allowed to generate mad (multiply add) if the result is "less precise" than doing those operations individually.
> 4. NoInfsFPMath - This flag is enabled when the -enable-no-infs-fp-math flag is specified on the command line. When this flag is off (the default), the code generator is not allowed to assume the FP arithmetic arguments and results are never +-Infs.
>
>   Does NoInfsFPMath override FPOpFusionFast? Or do we need another enum value/flag to answer that question? Are there other transforms that need to be aware of this interaction?


No, I think they're somewhat orthogonal and supplement each other in this particular case.

As I understand it, FPOpFusion::Fast says: enable fusion wherever it's profitable *even if rounding is slightly changed* (in practice, the intermediate rounding step is skipped) -- this should be documented.

Generally, whenever something comes with the tradeoff of less or slightly changed precision, you don't expect massive changes in behaviour with inf/nans.

And there are plenty of practical optimizations that FPOpFusion::Fast enables (mul + add --> fma), just this particular case here should require the user to say both "I'm fine with slightly different precision" **and** "I'm fine with massively different behavior in the face of +/-Inf".


https://reviews.llvm.org/D26602





More information about the llvm-commits mailing list