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

[Chandler Carruth via llvm-commits]

I spent some time looking at this.

Hal, I think we need to revert all of this. =[

The operand bundle thing solves a very real issue in InstCombine and
ValueTracking but it makes the inline cost computation superlinear. I'm
actually amazed we didn't see this sooner.

A fundamental requirement of the current inliner is that inline cast has a
fixed constant bound on the cost of computing it. With this change, the
cost can be linear because we will walk every single instruction in the
callee to determine that it isn't an assume. The test cases here have *no*
assume instructions in them. So this seems really bad in terms of
regressions: we made code *without* assumes slower to make code *with*
assumes faster. =/ But it is also superlinear. If you imagine a module with
two functions, one of which calls the other N times and the other calls the
first N times, I'm pretty sure we'll examine all N instructions of one
function for each of the N call sites in the other.

The test cases here aren't terribly pathological and they still seem to
trigger this behavior. =/

I don't see any particularly easy ways around this either. This is in fact
what a caching approach to function analyses in the new PM is designed to
solve -- it allows us to not do linear work here by caching results.
Eventually, the 'collectEphemeralValues' call will actually just lookup an
ephemeral values analysis and use its cached results.

Until then, I actually think the (somewhat hacky) caching scheme the
AssumptionCache was using is the right approach. I would use the
AssumptionCache for CodeMetrics and building the ephemeral value set, and
then use the operands for everything else. Then, in the new PM, we can
replace the AssumptionCache with a more elegant cached set of ephemeral
values.

I've told Daniel to go ahead and revert this to get non-assume-heavy things
back to linear compile time. If my suggestion doesn't make sense, poke me,
happy to chat about alternatives here.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161219/03191e8c/attachment.html>