[PATCH] D152082: [ValueTracking] getUnderlyingObject() look through phi.

[Joshua Cao via Phabricator via llvm-commits]

caojoshua created this revision.
Herald added subscribers: dmgreen, hiraditya.
Herald added a project: All.
caojoshua added reviewers: nikic, goldstein.w.n, arsenm, fhahn.
Herald added a subscriber: StephenFan.
caojoshua updated this revision to Diff 528164.
caojoshua edited the summary of this revision.
caojoshua added a comment.
caojoshua updated this revision to Diff 528166.
caojoshua published this revision for review.
Herald added subscribers: llvm-commits, pcwang-thead, wdng.
Herald added a project: LLVM.

small updates


caojoshua added a comment.

small update


caojoshua added a comment.

I think this analysis of objects is correct. Would appreciate if reviewers let me know whether my understanding is correct or not. This change is on top of a local NFC to make getUnderlyingObject() <https://github.com/caojoshua/llvm-project/commit/a4096c6421025f2a9cbc675ce3ef953bc4e66ad6> recursive.

Some caveats:

- With unbounded lookups, this could increase compile times since this is a frequently used API. However, there is a default max lookup of 6. I only see one caller that uses a different value of 0, for infinite max lookups. I think overall compile time should see minimal impact.
- This change unintentionally made a bunch of changes to codegen tests. The tests with small changes look fine to me, but I'm unsure about `@wrongUseOfPostDominate`. I have not work with LLVM CodeGen before, so I don't want to dive too deep into this test in case the idea in this patch is completely wrong. I'd like to get a first round of feedback before I look into it.



================
Comment at: llvm/test/Transforms/LoopVectorize/ARM/pointer_iv.ll:884
 ; CHECK-NEXT:  entry:
-; CHECK-NEXT:    [[UGLYGEP:%.*]] = getelementptr i8, ptr [[Z:%.*]], i32 3000
-; CHECK-NEXT:    [[UGLYGEP1:%.*]] = getelementptr i8, ptr [[X:%.*]], i32 3000
----------------
Is this transformation legal? I believe it is. I tried putting this in [alive2, but compilation is failing without any output.](https://alive2.llvm.org/ce/z/V9sZAM). I tried an example in [godbolt](https://godbolt.org/z/ohEhPrT1d) which is functionally the same, except we GEP directly from the array base. The generated code in that case eliminates the bounds check, so I think it should be fine here as well.

Although the test goes through multiple passes, the removal of the bounds check is occurring during loop-vectorize, and I'm not familiar with the pass. It's not clear to me how this patch is affecting anything in loop-vectorize.




For a pointer phi, we can strenghten the underlying object if each of
its incoming pointers are the same, or the PHI itself.

Some benefits are:

- Determining partial aliasing of induction phis
- Folding phis that point to a zero initialized constant array


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D152082

Files:
  llvm/lib/Analysis/ValueTracking.cpp
  llvm/test/Analysis/BasicAA/recphi.ll
  llvm/test/CodeGen/AArch64/aarch64-matrix-umull-smull.ll
  llvm/test/CodeGen/ARM/arm-shrink-wrapping-linux.ll
  llvm/test/CodeGen/Thumb2/mve-memtp-loop.ll
  llvm/test/Transforms/InstCombine/ptr-replace-alloca.ll
  llvm/test/Transforms/LoopVectorize/ARM/pointer_iv.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D152082.528166.patch
Type: text/x-patch
Size: 21567 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20230603/2ba973db/attachment.bin>