<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
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.
<a class="moz-txt-link-freetext" href="https://llvm.org/bugs/show_bug.cgi?id=26921">https://llvm.org/bugs/show_bug.cgi?id=26921</a>). 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. <br>
<br>
Philip<br>
<br>
<div class="moz-cite-prefix">On 03/11/2016 04:57 PM, Daniel Berlin
wrote:<br>
</div>
<blockquote
cite="mid:CAF4BwTUbtYAUPY++uVq3_wkGDJ9p0BBNQ7yH+xOBzDOc1KSjNA@mail.gmail.com"
type="cite">
<div dir="ltr">I'm with phillip on this one.
<div>If LVI is being asked about every variable, either</div>
<div>A. We should make something that produces the same info but
does it not lazily (the evaluation order that LVI uses is
non-optimal)</div>
<div>B. We should stop asking about every variable.</div>
<div><br>
</div>
<div>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 :)</div>
<div><br>
</div>
<div>There are better orderings and better solving strategies
that will produce identical info, far faster.</div>
<div>However, most of these can't be stopped "in the middle"
like LVI can.</div>
<div>If we are asking for every variable, we should do that.</div>
<div><br>
</div>
<div>Given that meet/join/etc is already abstracted out pretty
well, writing such a solver using SparseSolver or something
should be preetty trivial.</div>
<div>My guess is a couple hundred lines of code at most.</div>
<div>I would do that instead, and use it in passes that are
asking about every variable.</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Mar 11, 2016 at 4:34 PM, Philip
Reames via llvm-commits <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:llvm-commits@lists.llvm.org" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a></a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">reames
added a comment.<br>
<br>
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.<br>
<span class=""><br>
<br>
Repository:<br>
rL LLVM<br>
<br>
<a moz-do-not-send="true"
href="http://reviews.llvm.org/D18069" rel="noreferrer"
target="_blank">http://reviews.llvm.org/D18069</a><br>
<br>
<br>
<br>
</span>_______________________________________________<br>
llvm-commits mailing list<br>
<a moz-do-not-send="true"
href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a><br>
<a moz-do-not-send="true"
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits"
rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>