[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