[PATCH] D23583: [AArch64] Add feature has-fast-fma

Matthias Braun via llvm-commits llvm-commits at lists.llvm.org
Wed Aug 17 15:10:30 PDT 2016


MatzeB added a comment.



In https://reviews.llvm.org/D23583#518669, @rengolin wrote:

> In https://reviews.llvm.org/D23583#518632, @evandro wrote:
>
> > I doubt it, since the folding is done in the middle end.
>
>
> Right, ignore me.
>
> > I disagree.  `isFMAFasterThanFMulAndFAdd()` is static and there's no good reason why `enableAggressiveFMAFusion()` cannot be static either.   In this sense, this feature is no different than the many of the existing features in AArch64.
>
>
> I assumed the FMA fusion optimisation could just query the cost model in some way. Overriding the cost model for specific instructions in specific sub-architectures is the most logical solution to me.


>From a design point of view I agree. TargetInstrInfo callbacks appear to mis ISA specifics with cost model/tuning options nowadays and it would be cleaner to have them part of the scheduling Model (or create a new interface called TargetTuning or TargetCostModel).
But we have to discuss this outside of this patch I believe.

> 

> 

> > Furthermore, I'm afraid that generalizing it to query the scheduling model would expand the scope of this feature beyond the hardware that I have available to test it on.

> 

> 

> I understand the constraints, but I think we should design the back-end for all cores and not keep adding special cases to every different decision on every different core.

> 

> After all, moving from isCoreX() to hasCoreXFeatureY() seems pointless.


>From the looks of it this specific tuning should be applicable to many more cores. Having it available as a feature at least makes it easy for others to test and enable/disable on the cores they feel responsible for. However judging whether the feature would be suitable for a particular core is hard when the description reads "FastFMA/Use FMA aggressively".


Repository:
  rL LLVM

https://reviews.llvm.org/D23583





More information about the llvm-commits mailing list