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

[Daniel Berlin via llvm-commits]

1. Sure, if we think there is room for improvement, yeah, great, let's do
that before giving up on it :)
2. If we fail, you could use an SCC based algorithm if you want special
loop handling, etc.

FWIW: what i'm proposing is to share the same internals. Staring at LVI, i
don't see why you would get different results if you do it in the forward
order.


On Fri, Mar 11, 2016 at 5:01 PM, Philip Reames <listmail at philipreames.com>
wrote:

> 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>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/041e61f4/attachment.html>