[PATCH] D18069: Throttling LICM to reduce compile time of Value Propagation and Reg Splitting

[Daniel Berlin via llvm-commits]

I'm with phillip on this one.
If LVI is being asked about every variable, either
A. We should make something that produces the same info but does it not
lazily (the evaluation order that LVI uses is non-optimal)
B. We should stop asking about every variable.

LazyValueInfo is supposed to be for lazy queries.  It is a backwards
solver.  This is going to be the worst possible order to ask about things
in :)

There are better orderings and better solving strategies that will produce
identical info, far faster.
However, most of these can't be stopped "in the middle" like LVI can.
If we are asking for every variable, we should do that.

Given that meet/join/etc is already abstracted out pretty well, writing
such a solver using SparseSolver or something should be preetty trivial.
My guess is a couple hundred lines of code at most.
I would do that instead, and use it in passes that are asking about every
variable.



On Fri, Mar 11, 2016 at 4:34 PM, Philip Reames via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> reames added a comment.
>
> I understand your thought process, but this approach is just not going to
> work.  As a matter of policy, we canonicalize at the IR level and LICM is
> pretty much the classic definition of canonicalization.  Restricting the
> aggressiveness of LICM to resolve a compile time problem elsewhere in the
> optimizer is fundamentally unacceptable.
>
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D18069
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160311/9bf0bef2/attachment.html>