[PATCH] D136470: Allow scalable vectors in computeKnownBits

[Philip Reames via Phabricator via llvm-commits]

reames created this revision.
reames added reviewers: craig.topper, asb, frasercrmck, RKSimon, efriedma, paulwalker-arm, david-arm.
Herald added subscribers: foad, StephenFan, bollu, hiraditya, mcrosier.
Herald added a project: All.
reames requested review of this revision.
Herald added a subscriber: alextsao1999.
Herald added a project: LLVM.

This extends the computeKnownBits analysis to support scalable vectors.  The critical detail is in deciding how to represent the demanded elements of a vector whose length is unknown at compile time.

For this patch, I adopt the convention that we track one bit which corresponds to all lanes.  That is, that bit is implicitly broadcast to all lanes of the scalable vector resulting in all lanes being demanded.  This is the same convention we use in getSplatValue in SelectionDAG.

Note that this convention doesn't actually impact much.  Most of the code is agnostic to the interpretation of the demanded elements, and the few cases which actually care need case by case handling anyways.  In this patch, I just bail out of those cases.

A prior patch (D128159 <https://reviews.llvm.org/D128159>) proposed using a different convention in SDAG.  I don't see any strong reason to prefer one scheme over the other, so I propose we go with this one as it's conceptually the simplest.  Getting known and demanded bit optimizations unblocked at all is a significant win.

I've locally implemented this scheme in reasonable large parts of ValueTracking.cpp and SelectionDAG equivalents, and have not hit any blockers.  If this is approved, I plan to post a series of patches plumbing this through all the relevant parts.

In the discussion on that patch, a preference was expressed for introducing some form of abstraction around the demanded elements.  I'll note that I've played with several variations on that idea locally, and have yet to find anything which results in more readable code.  If anyone has concrete ideas in this area, I'm happy to explore in follow up patches.  I'd strongly prefer to be making API changes in NFC manner with tests in place.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D136470

Files:
  llvm/lib/Analysis/ValueTracking.cpp
  llvm/test/Transforms/InstCombine/add.ll
  llvm/test/Transforms/InstCombine/intrinsics.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D136470.469680.patch
Type: text/x-patch
Size: 6832 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20221021/26d10d6b/attachment.bin>