[llvm] r289755 - Make processing @llvm.assume more efficient by using operand bundles

[Daniel Berlin via llvm-commits]

On Tue, Jan 3, 2017 at 5:43 AM, Hal Finkel via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> Hi Philip,
>
> First, I'm planning on rewriting this change to be more targeted,
> specifically to take the alternative approach we discussed briefly on the
> review thread and keep the list of affected variables in the assumption
> cache.


> Second, regarding motivation, the problem is not the basic-block scan
> (with the assumption cache, we actually do very little of that anyway). The
> core problem is that, in ValueTracking, which is used heavily by
> InstCombine and other passes, checks all assumptions in each function for
> every variable being processed to determine known bits, etc. These checks
> are pattern matches, and while they normally fail quickly, as the number of
> assumptions increases, this is a large problem: it makes known-bits
> determination O(#assumptions in the function), for every variable, in the
> common case, and, because the assumption processing is part of the
> recursive known-bits procedure, the constant factor can be large too given
> certain kinds of inputs. What we need for ValueTracking (and also for LVI
> and maybe others) is a way to cache which variables are (usefully) affected
> by which assumptions.
>
>
When you say affected, do you mean "what uses"?
Because your operand bundles change, does not really do that.
For a given use I still have to find the assume (which is in the middle of
a block), then go to the bundle, then look at the uses of the things in
that bundle
Or am i missing something?

Regarding your suggestions below, I can definitely see how we might run
> into a problem with the dominance checking if we had a large number of
> assumptions which affected a variable -- it is only when we have an
> assumption that potentially affects a variable that we do any of the
> dominance checking -- but I've not run into any such cases yet.
>

Note: I have precisely the same problem with newgvn's predicate handling:

I need to be able to tell, for a given instruction, what predicates
dominate it (including assumes)

It's pretty fast for most predicates, because they occur at the end of
blocks, but could still be sped up.
For assumes, not so much, because they can occur wherever.

I have a prototype where i've implemented e-ssa to solve both problems. It
requires the introduction of one intrinsic, and some use renaming.

IE
if (foo == 50) {
} else { }

becomes

if (foo == 50) {
foo1 = predicateinfo(foo, the icmp of foo )
(use foo1)
} else {
foo2 = predicateinfo(foo, the icmp of foo)
(use foo2)
}

Once that's done, finding the set of predicates that usefully affect a
given use is trivial, as you can just walk the def-use chains.

I haven't implemented it for assume, but it should work just as well for
that.

I'm somewhat against caching solutions and hacky here,I generally prefer to
solve infrastructury problems with better infrastructure.  Caching tends to
just kick the can down the road, and often makes it harder to build better
infrastructure.  It makes sense when the change is significantly harder to
get right, and not worth the cost. Here, honestly, we can do better.
We have plenty of cases where CVP, etc, will be significantly sped up by
the above (i can hand them to you) but not by your change.

Note also that it improves a large set of passes.
For example, the variable split enables SCCP to do correlated value
propagation (trivially for equality comparison, other things with a bit of
work)

Before, it could only do something if "foo" turned out the same everywhere.
After, you can propagate  "foo == 50" to the foo1 branch.

Early measurements come out to a few percent more constants found total.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170103/1450b6e7/attachment.html>