[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