<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 22, 2017 at 2:34 PM, Michael Zolotukhin via Phabricator <span dir="ltr"><<a 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">mzolotukhin added a comment.<br>
<br>
Thanks for posting this, Hal!<br>
<br>
I'll run some experiments with it, but in general I support this approach.<br>
<br>
@rnk:<br>
<span class=""><br>
> Long term, I agree with Danny that computing known bits on demand doesn't seem to scale. We might want to just do the analysis up front and see if that works better.<br>
<br>
</span>The problem with computing everything upfront is that at some point we might want to partially invalidate the results. Recomputing everything from scratch after it  sounds inefficient,</blockquote><div><br></div><div>(assume it is inefficient for a second)</div><div>What makes you think you have to do that?<br></div><div>Why are the only two options "compute on demand" and "build from scratch" and not "incrementally recompute"?<br></div><div> <br></div><div>Most of these are lattice propagation problems.</div><div>Most are incrementally recomputable by resetting the lattice state of the members of the def use chain being touched here, and starting propagation from the first one.</div><div>(the ones that aren't are where they use things like reachable block state, but even that is fixable).<br></div><div><br></div><div>FWIW: It also may not be inefficient. Again, we are not building a super-optimizer here, so it may good enough to do it, say, twice, and live with the fact that we are never going to minimize every possible expression to the smallest possible state. What matters is whether the performance of generated code suffers or not.</div><div><br></div><div>The example i usually trot out here is that gcc computes aliasing *twice*, in the entire compiler. It beats us on pretty much every alias precision metric and ability to do memory optimization metric you can find.  So the "completely stateless" work we do in basicaa, to have everything be the best it can be, at all times, has still not won there</div><div>There are plenty of other examples.</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> and if we add caching, we'll end up with something like what's proposed here. </blockquote><div><br></div><div>I think you meant to write something else, because if we add caching, we definitely end up with something like what is proposed, since caching is what is proposed ;)</div><div>If you mean it would look similar to incremental recomputation:<br>it is definitely *much* easier to verify the state of the analysis is sane if you do incremental updating instead of caching.</div><div> </div><div>IE trivially, at pretty much any point, you can say "recompute what this *should* look like against the function*, and compare to what you got from incremental recomputation.</div><div><br></div><div>Local caching like this is very hard to verify.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">To me this looks very similar to what we have in SCEV (a map from expression to the corresponding analysis result, that we can invalidate and recompute whenever it's requested again), and I think SCEV has been working pretty well so far in this aspect.<br>
<br>
Michael<br>
<br>
<br>
<a href="https://reviews.llvm.org/D31239" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D31239</a><br>
<br>
<br>
<br>
</blockquote></div><br></div></div>