[llvm] [LV] Convert gather loads with invariant stride into strided loads (PR #147297)

[Mel Chen via llvm-commits]

================
@@ -3307,6 +3332,52 @@ struct VPWidenLoadEVLRecipe final : public VPWidenMemoryRecipe, public VPValue {
   }
 };
 
+/// A recipe for strided load operations, using the base address, stride, and an
+/// optional mask. This recipe will generate an vp.strided.load intrinsic call
+/// to represent memory accesses with a fixed stride.
+struct VPWidenStridedLoadRecipe final : public VPWidenMemoryRecipe,
+                                        public VPValue {
+  VPWidenStridedLoadRecipe(LoadInst &Load, VPValue *Addr, VPValue *Stride,
----------------
Mel-Chen wrote:

> Hm yes, this is a general modeling issue, but could be improved separately (and does not only apply to this intrinsic I think). Is setting the alignment critical for the initial implementation?
> 

As Craig mentioned above, I think we should still preserve the alignment information for now. Moreover, since  https://github.com/llvm/llvm-project/pull/164205 converts strided accesses into gather/scatter, if we don’t preserve it now, wouldn’t that cause the masked.gather/scatter to lose their alignment information?

> I am not sure I understand this completely; We should be able to check the profitability up-front regardless of what recipe we create later on, I think?
> 

Yes, that works. I’m currently using `TTI.getIntrinsicInstrCost` to achieve this. But I think the best approach would be to directly reuse 
```
static InstructionCost getCostForIntrinsics(Intrinsic::ID ID,
                                            ArrayRef<const VPValue *> Operands,
                                            const VPRecipeWithIRFlags &R,
                                            ElementCount VF,
                                            VPCostContext &Ctx)
```
that is called by `VPWidenIntrinsicRecipe::computeCost`.

This would prevent potential discrepancies between the pre-conversion cost estimation and the actual recipe cost. I believe refactoring `getCostForIntrinsics` would be needed to make that work.

> I think this could be mostly taken care of by providing a `m_StridedLoad()` pattern?

Yes, that’s the least important issue. Using m_Intrinsic<> directly is also fine.

Anyway, the main concern is still the alignment. @fhahn Could you tell me what your major concern is about adding VPWidenStridedLoadRecipe in details? That would help me think of a way to address it.


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