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

[Philip Reames via llvm-commits]

On the topic of LVI vs Eager Value Info, I'm much less convinced than 
Danny that jumping straight to that is a good idea.  There's lots of 
room to improve the implementation of LVI (e.g. 
https://llvm.org/bugs/show_bug.cgi?id=26921).  I'm not opposed to the 
idea of an eager algorithm, but getting the eager code to handle all of 
the cases LVI does is not as obvious as it first might seem. In 
particular, LVI's handling of loops is surprisingly sophisticated and 
non obvious.  It's able to do fairly sophisticated inductive proofs of 
constant ranges.

Philip

On 03/11/2016 04:57 PM, Daniel Berlin wrote:
> 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 <mailto: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 <mailto: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/406d102d/attachment.html>