[PATCH] D146033: [AArch64][TTI] Cost model FADD/FSUB

Fri Mar 17 12:22:13 PDT 2023

SjoerdMeijer added a comment.

In D146033#4202014 <https://reviews.llvm.org/D146033#4202014>, @dmgreen wrote:

> I think this makes a lot of sense. Especially if we are treating many shuffles with a cost of 1, floating point operations should not be twice the cost. We could consider doing the same for fmul from looking at software optimization guides, but the changes for fadd/fsub already have a high likelihood of causing some large changes.  Adding fneg is worth it though as that should be a simple operation.
>
> This might lead to a fair number of changes. From looking at the main regression I found for example, it was a case of identical code being produced by the loop vectorizer, but scalar and vector costs being closer lead it to have a higher minimum trip count for entering the vector body (from D109368 <https://reviews.llvm.org/D109368>). The real problem there is aliasing causing LD4 loads to not be recognized though, so it's tough to see how this change is really to blame. There are a number of improvements too, to make up for that regression.
>
> @fhahn do you have any thoughts on the change from your side, or any benchmark results that could be helpful?

Thanks a lot for looking at this Dave. I completely agree about giving other FP operations like fmul the same treatment. I forgot to mention why I only chose to change the cost for FADD/FSUB, but it's exactly for the reason you mentioned: I was a bit cautious about causing too many changes at the same time and am hoping to restrict the fallout by changing FADD/FSUB first before doing others. So I am more than happy to add FNEG too if we think that won't increase the risk of regressions.

I will also add the extra checks for the more exotic FP types like you suggested.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D146033/new/

https://reviews.llvm.org/D146033