Allow vscale GEPs to be analysed in BasicAA if comparison is performed between 2 GEPs that are equal in scalability (i.e. vscale vs vscale) This improves Codegen that is dependent on alias analysis framework (e.g. SVE on AArch64)
Details
Diff Detail
Event Timeline
I see cases where when we do Loop unrolling for SVE, that we move Load/Stores across iterations although they definitely not aliasing. This patch is trying to improve on that. In theory we should allow alias analysis when done between 2 GEPs that have the same scalable type, and memory location size.
This patch is the first series of patch to improve SVE loop unrolling, to get the full benefit, getSizeOrUnknown() must be updated as well (used in machinememoperand I believe).
Rudimentary prototyping suggests that doing this properly can give us a lot of uplift for SVE, especially in the LITTLE core
I'd suggest to split this into two parts: First add support for scalable LocationSize, and make sure code can handle it correctly, and then add support for scalable offsets to GEP decomposition later. I don't think the way you're currently doing it is what we want.
llvm/include/llvm/Analysis/MemoryLocation.h | ||
---|---|---|
107 | precise() takes a TypeSize. You should be able to handle the isScalable() case in here only, rather than adjusting all callers to call a separate preciseScalable() method instead. |
Hi Nikita,
Yeap sure I can do the adjustment on the precise(method)
Meanwhile, could you please elaborate on what way would you prefer how we handle the scalable offsets on GEP decomposition?
Harvin
I think vscale should be part of VariableGEPIndex, as we're modelling an expression of the form vscale * x.
precise() takes a TypeSize. You should be able to handle the isScalable() case in here only, rather than adjusting all callers to call a separate preciseScalable() method instead.