[PATCH] D144434: [VPlan] Handle invariant GEPs in isUniformAfterVectorization.
Florian Hahn via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri May 19 13:08:46 PDT 2023
fhahn added a comment.
In D144434#4141906 <https://reviews.llvm.org/D144434#4141906>, @reames wrote:
> I think there's a deeper logic issue here. I'm pretty sure this is a bug I introduced, so, sorry!
>
> LoopAccessInfo::isUniform uses SCEV's notion of loop invariant. This is both things which are currently loop invariant, but also things whose computation is loop invariant (e.g. uniform).
>
> As you noticed, VPReplicateRecipe::execute uses only whether the recipe was defined. This is essentially a proxy for whether an instructions *placement* was loop invariant. This explicitly *does not* reason about computation. (I think... this part of things I'm less confident in.)
At the moment, `isUniformAfterVectorization` reasons about more than just placement by using information about uniform operands, but relies on uniforms being represented as uniform VPReplicateRecipes. I think the underlying issue is that we don't classify the GEP as uniform correctly. I put up D150991 <https://reviews.llvm.org/D150991> to use `Legal::isUniform` to bring the reasoning during classification in line with `isUniformMemOp` which is used in other places.
In D144434#4149935 <https://reviews.llvm.org/D144434#4149935>, @kartcq wrote:
> This patch does not solve the issue completely.
> But I don't have expertise enough to comment on what needs to be fixed.
>
> A simplified test case which still breaks the Loop vectorizer even after applying this candidate patch is as follows
Thanks, I added the new test in 07e5f57df4bf <https://reviews.llvm.org/rG07e5f57df4bf0410fdb772770696a1ed85762e86>
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D144434/new/
https://reviews.llvm.org/D144434
More information about the llvm-commits
mailing list