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

[Elvis Wang via llvm-commits]

ElvisWang123 wrote:

For these new test cases ([ab9178e](https://github.com/llvm/llvm-project/commit/ab9178e3e73dc715463e1019ed2cd449dc18bb18), [7665d3f](https://github.com/llvm/llvm-project/commit/7665d3f0df78b8b58c1adb18d53f36351426da72)), I would like to raise  discussion of the difference between the legacy model and the VPlan-based cost model for in-loop reduction cost.

1. Should we limit all `ext` and `mul` instructions has only one user in both extended-reduction and MulAcc patterns ?
    -  If Yes, limit all `ext` and `mul` has only one user and the user is reduction.  Bad for VPlan-based cost model but this is how legacy cost model be implemented.
       - VPlan: We cannot fold the `VPWidenCastRecipe` and `VPWidenRecipe` into `VPExtendedReductionRecipe` and `VPMulAccRecipe` when there are two reductions share same `ext` or `mul`. This will generate larger cost than the legacy model and also far from the  assembly.
       - Legacy: Currently the legacy cost model limit these instruction has only one user. This make legacy cost model calculate the cost for `ext` and `mul` even these instruction can be  folded into following reductions.
    -  If No. Good for Vplan based but miscalculate the cost for legacy model.
       - VPlan: Let `VPWidenCastRecipe` and `VPWidenRecipe` can transform into `VPExtendedReductionRecipe` and `VPMulAccRecipe`. If the `WidenCast` and `Widen` recipes has other user than reductions, it will still calculate the cost of `WidenCast` and `Widen` recipes. This seems much closer to the generated assembly.
       -  Legacy: If `ext` and `mul` instructions has users other than reductions, we will not calculate the cost of these instructions.
     - Current status: 
     Currently I removed some `OneUser` limitations in the VPlan-bsed implementation to support two reductions in one loop and the legacy cost model always limit `ext` and `mul` instructions has one user. But in the new test case (`test_std_q31`), the legacy cost model cannot mark the `ext` instruction to free because it is shared by two reductions. This mis-calculation from the legacy model trigger the assertion and I think it is difficult to fix it in the legacy model.
2. Do we want this patch to land before assertion is removed?
 


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