<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 03/24/2017 06:00 PM, Daniel Berlin
wrote:<br>
</div>
<blockquote
cite="mid:CAF4BwTWH8m4ywmhdGgzS3J7nyw6wXh1VzbXt655ujK2XTgVDqw@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Mar 24, 2017 at 3:44 PM,
Daniel Berlin <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">In which i repeat my claim that trying to
keep caches up to date is significantly harder to get
right and verify than incremental recomputation :)</div>
</blockquote>
<div><br>
</div>
<div>and to be super clear here, the practical difference
between the two is that incremental computation is really
"build an analysis that can be run at any point, but is a
full analysis that computes all answers and not on demand.
The speed at which the analysis runs depends on how much
data has changed since last time.".</div>
</div>
</div>
</div>
</blockquote>
<br>
How exactly do you propose this works in this case (given that the
recomputation cost is proportional to the amount the IR has
changed)? It sounds like caching with the default behavior on RAUW
flipped. Instead of assuming by default that the replacement
instructions has the same known bits as the original, we assume that
it does not (and then recursively clear out all users).<br>
<br>
-Hal<br>
<br>
<blockquote
cite="mid:CAF4BwTWH8m4ywmhdGgzS3J7nyw6wXh1VzbXt655ujK2XTgVDqw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>The compile time hit depends on how often you want
answers. Usually people try to say "i want them always up
to date" (often without any quantification of cost or
other trade-offs), which leads to trying to do it
on-demand</div>
<div><br>
</div>
<div>Caching is really "build something that is always
computed on demand. Try to make it faster by storing the
answers it gives somewhere, and hoping that the rest of
the algorithm retains the ability to give correct answers
on demand when you remove some of the stored answers".</div>
<div><br>
</div>
<div>One can obviously argue that incremental recomputation
is a form of caching, so i'm trying to be concrete about
my definitions.</div>
<div><br>
</div>
<div>usually, caching additionally requires clients be able
to correctly predict and remove the set of answers
necessary for correctness (IE know enough about how the
algorithm works) but this isn't strictly the case if
designed well.</div>
<div><br>
</div>
<div>Caching also often ends up with degraded answers over
time, while most full analysis can be made to not do so.
See, for example, memdep, which has unresolvable cache
invalidation issues. This means, for example, opt -gvn
-gvn gives different answers than opt -gvn | opt -gvn.</div>
<div><br>
</div>
<div>Both approaches obviously require information about
what has changed in the IR.</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div> I additionally claim that we should actually
quantify the performance benefits of doing either over
"recomputing once or twice during pipeline" before
going down this route.
<div><br>
</div>
<div>We are *already* trading off compile time
performance vs generated code performance. </div>
<div><br>
</div>
<div>All other things being equal, we should trade it
off in a way that makes maintenance of code and
verification of correctness as easy as possible.</div>
<div><br>
</div>
<div>Asserting that a good tradeoff to reduce compile
time is "cache" instead of "stop doing it on demand"
(or incrementally recompute), without any data other
than compile time performance seems ... not
particularly scientific.</div>
<div><br>
</div>
<div>It's certainly true that caching is often posited
as "easier", but i think a trip through bugzilla
would put this idea to rest.</div>
<div><br>
</div>
<div><br>
</div>
</div>
</div>
<div class="HOEnZb">
<div class="h5">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Mar 24, 2017 at
3:33 PM, Craig Topper via Phabricator <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:reviews@reviews.llvm.org"
target="_blank">reviews@reviews.llvm.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0
0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">craig.topper added a
comment.<br>
<br>
I'm seeing more problems than just nsw/nuw flags
here.<br>
<br>
sext.ll test is failing because
SimplifyDemandedInstructions bits determined
that this<br>
<br>
%and = and i32 %x, 16<br>
<br>
shl i32 %and, 27<br>
<br>
Simplified to just the shl because we were only
demanding the MSB of the shift. This occurred
after we had cached the known bits for the shl
as having 31 lsbs as 0. But without the "and" in
there we can no longer guarantee the lower bits
of the shift result are 0.<br>
<br>
I also got a failure on shift.ll not reported
here. This was caused by getShiftedValue
rewriting operands and changing constants of
other shifts. This effectively shifts the Known
bits and thus the cache needs to be invalidate.<br>
<br>
<br>
<a moz-do-not-send="true"
href="https://reviews.llvm.org/D31239"
rel="noreferrer" target="_blank">https://reviews.llvm.org/D3123<wbr>9</a><br>
<br>
<br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>