tree 55d28adeaa1ba9d6226ee8a067acfcc2cb4c0201
parent b31a094a9cd8c2d9c30ae8239dd6c2cfdab3e1ce
author Sanjay Patel <spatel@rotateright.com> 1618576762 -0400
committer Copybara-Service <copybara-worker@google.com> 1618603792 -0700

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

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

Another potential solution would make the exclusion logic stronger to avoid
blowing up, but note that we reduced the complexity of the exclusion mechanism
in 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.

Differential Revision: https://reviews.llvm.org/D100573

GitOrigin-RevId: bb907b26e2bf2a0d5ea3fcb13ba0ccef3420a38c