[llvm] [VPlan] Impl VPlan-based pattern match for ExtendedRed and MulAccRed (NFCI) (PR #113903)

[David Green via llvm-commits]

davemgreen wrote:

> Thanks, I will only model these three patterns for reduction.

I believe that `reduce.add(ext(mul(ext(...), ext(...))))` is mathematically equivalent to `reduce.add(mul(ext(...), ext(...)))`, so that sounds good so long as we can match both. I don't remember about the `reduce.add(ext(mul(..., ...)))` form, it doesn't sound like it would be equivalent. If it turns out we do need it, it should hopefully be fine to look into adding it later.

> I think we already model the instruction cost for ext(load) in VPWidenCastRecipe::computeCost(). We compute the CastContextHint which depends on the load/store for the ext instructions. But I am not quite sure will ARMTTI handle this pattern correctly or not.
>
> In summary, I think we only need two new recipes for reduction - reduce(ext) and reduce.add(mul(<optional>(ext), <optional>(ext))) ?

IIRC CCH was added for getting the extension costs (more) correct under Arm/MVE, so it hopefully does OK in the current scheme. We might need to be a little careful about which one of `red-ext + load` vs `red + ext-load` we prefer for each vplan.

https://github.com/llvm/llvm-project/pull/113903