[PATCH] D100573: [ValueTracking] don't recursively compute known bits using multiple llvm.assumes

[Sanjay Patel via Phabricator via llvm-commits]

spatel created this revision.
spatel added reviewers: nikic, lebedev.ri, xbolva00.
Herald added subscribers: hiraditya, mcrosier.
spatel requested review of this revision.
Herald added a project: LLVM.

This is an alternative to D99759 <https://reviews.llvm.org/D99759> to avoid the compile-time explosion seen in:
https://llvm.org/PR49785

The suggestion was to make the exclusion logic stronger to avoid blowing up, but I'm not seeing how to do that. Note that we reduced the complexity of the exclusion mechanism in D16204 <https://reviews.llvm.org/D16204> because it was too costly.

So I'm questioning the need for recursion/exclusion entirely - what is the optimization value vs. cost of recursively computing known bits based on assumptions? This was built into the implementation from the start with 60db058, and we have kept adding code/cost to deal with that capability.

By clearing the query's AssumptionCache inside computeKnownBitsFromAssume(), this patch retains all existing assume functionality except refining known bits based on even more assumptions.

We have 1 regression test that shows a difference in optimization power. Is that example representative of real-world llvm.assume usage?


https://reviews.llvm.org/D100573

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D100573.337773.patch
Type: text/x-patch
Size: 13881 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210415/8d0f375f/attachment.bin>