[PATCH] D98212: [wip][basicaa] look through phis and selects when searching for underlying object

[Philip Reames via Phabricator via llvm-commits]

reames created this revision.
reames added a reviewer: nikic.
Herald added subscribers: dantrushin, hiraditya, mcrosier.
Herald added a reviewer: bollu.
reames requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Warning: Code is a mess, not for real review.  This is mostly for @nikic to take a look and tell me if I missed something fundamental.

Background:

- DecomposeGEP needed to be in sync with getUnderlyingObject in a very fragile manner.  However, I can't find any good reason for this.  Simple recursing through the base of the decomposed gep gives us the same number of recursive calls, and it doesn't seem to matter if the underlying object search is ahead of the recursion.  All it does is add a small constant amount of additional work per step, at worst.
- We can often find a single underlying object, even after searching through a phi graph.  The existing recursive phi handling is one instance of this (but done in the recursive step).
- If we allow the underlying logic search to traverse phi graphs, even with small limits (e.g. 6) we find interesting cases.

@nikic - I'm mostly looking for a sanity check here.  This feels "too easy".  Have I managed to miss something fundamental here?


https://reviews.llvm.org/D98212

Files:
  llvm/include/llvm/Analysis/BasicAliasAnalysis.h
  llvm/include/llvm/Analysis/ValueTracking.h
  llvm/lib/Analysis/BasicAliasAnalysis.cpp
  llvm/lib/Analysis/ValueTracking.cpp
  llvm/test/Analysis/BasicAA/recphi.ll
  llvm/test/CodeGen/Hexagon/swp-epilog-phi13.ll
  llvm/test/Transforms/LoopVectorize/ARM/pointer_iv.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D98212.329093.patch
Type: text/x-patch
Size: 24377 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210308/9687c1df/attachment.bin>