Following D20789 getPtrStride has a new argument ShouldCheckWrap;
This patch makes collectConstStridedAccesses (part of interleaved-mem-accesses analysis)
call getPtrStride with [Assume=true and ShouldCheckWrap=false],
(instead of the default [Assume=false, ShouldCheckWrap=true]),
matching the way getPtrStride is called from isConsecutivePtr.
It is actually not entirely clear to me when we want to permit Assume and/or require ShouldCheckWrap... Looks like there may be some inconsistency now with how getPtrStride is called; For example, hasConsecutiveLikePtrOperand under the convers calls getPtrStride once with [Assume/CheckWrap=true,false] to identify consecutive accesses, and once with [Assume/CheckWrap=false,true] to identify strided accesses. Is this intentional?
In the attached testcase we have missed vectorization when interleaved-accesses are not identified because vectorization with gathers is too costly. If getPtrStride is called with Assume=false and ShouldCheckWrap=true (current behavior) it cannot resolve the stride because the SCEV could wrap and Stride!=1. If getPtrStride is called with Assume=true or ShouldCheckWrap=false it is able to return a stride of 2, and in turn the interleaved-mem-accesses analysis is able to form an interleaving group.