<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 6, 2015 at 12:16 AM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This can be used in real pass pipelines to force the usually lazy<br>
analysis running to eagerly compute something at a specific point, </blockquote></span><div><br>Any particular reason this would be useful/necessary?</div></blockquote></div><br>Two ways I can think of off hand:</div><div class="gmail_extra"><br></div><div class="gmail_extra">Force something to be computed across a domain before we start to mutate that domain. For example, pre-compute something over an SCC before running function passes that may mutate that SCC. Sub-domains can only query cached analysis results from outer domains because we can't interrupt the peers to run the pass lazily.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The second issue is with passes that just use 'getCachedResult' to acquire a cached result (but not lazily run a pass) for some other reason such as "efficiency". Unclear how often this will come up in the new pass manager, but it happens a lot in the old one so I wanted to make sure we could do it. I'm hopeful that the lazy running + aggressive caching will decrease or remove this use case, but its unlikely to remove the first one. =/</div></div>