We don't actually check whether a MemoryAccess is affine in very many places, but one important one is in checks for aliasing.
Details
Diff Detail
Event Timeline
While I agree with the commit message, I am not aware of any real benefit this will provide us given that we only leverage the constant range ScalarEvolution range analysis. If we would use a better one, e.g., along the lines of https://reviews.llvm.org/D20230, I think this patch does make sense.
This opinion was basically written down in the code:
// Check if we have non-affine accesses left, if so bail out as we cannot // generate a good access range yet.
We ran into a case similar to the included testcase, where we need to generate a runtime alias check with a memset in order to vectorize a loop. (memset isn't really non-affine, but we currently model it that way.)
Why don't we then treat a memset/memcpy/memmove with affine length as affine access instead?
E.g. replace the "false" in ScopBuilder.cpp line 279 and 300 with "LengthIsAffine"?
I assumed there was some reason we were treating the memset as non-affine... if there isn't, I'm happy to change it.
You also have to adjust the call location to
buildMemIntrinsicAccessRelation
but I think this is the best way to go.