<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 30 June 2017 at 16:21, Manuel Klimek <span dir="ltr"><<a href="mailto:klimek@google.com" target="_blank">klimek@google.com</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"><div class="gmail_quote"><span class=""><div dir="ltr">On Fri, Jun 30, 2017 at 4:03 PM Noah L <<a href="mailto:duneroadrunner@gmail.com" target="_blank">duneroadrunner@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 29, 2017 at 10:31 PM, Manuel Klimek <span dir="ltr"><<a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a>></span> wrote:<br>...</div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_7830457756545770133m_-7034282781998978131gmail-"></span><span class="m_7830457756545770133m_-7034282781998978131gmail-"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br>I'm not saying it's not feasible. I'm not even saying it's not reasonable. But you can see why it'd be nicer for me if libTooling could just present me with a combined AST. :)<br></div></div></div></div></blockquote></div><div><br></div></span><div>Unfortunately that only scales to small projects in the generalized case. The static analyzer gets away with it because it only loads things close to the function it analyzes, instead of needing a global view.</div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"></div>Scales in what way? Memory usage?</div></div></blockquote><div><br></div></span><div>Both memory and compute.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"> I just watched Gabor's talk where, if I understood correctly, he mentions that the combined ASTs for llvm took up 40Gb when exported to disk. I'm assuming that's not compressed or anything. There are plenty of workstations with 40Gb+ of RAM.</div></div></blockquote><div><br></div></span><div>There are also plenty of workstations that don't have that much RAM. I personally like tools that I can run on a machine without killing all other jobs, too :)</div></div></div></blockquote><div><br></div><div>Also note that 40Gb on disk might not correspond to 40Gb+ RAM. One of the reason the dumps are so big because the headers are duplicated in the AST files of separate TUs. In case we utilize lazy loading from AST files (i.e. loading only the definitions we need), and merging the definitions into the original AST, we might save a lot of memory compared to the disk dumps. Or in case of modules, the duplication would be much less on the disks too. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"> The static analyzer may need significant additional memory for its processing, but my tool does not.<br><br>And tools like mine aren't part of the interactive development process. They may only ever need to be applied to a project once. So it might even be acceptable for it to take a week or whatever to execute. (I don't see why this wouldn't apply, to a lesser degree, to the static analyzer as well.)<br></div></div></blockquote><div> </div></span><div>Generally, in my experience, for development speed, sanity and error resilience, faster turnaround times help.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">Are you sure you're not being overly conservative about the scaling issue? Or am I somehow just being naive here? For me, I feel that it's a very inconvenient feature omission, and I'm not sure I really understand the reluctance.<br></div></div></blockquote><div><br></div></span><div>We might disagree on the overhead of the 2-phase solution. We have built libtooling around this, and have quite a bit of infrastructure (that's also getting expanded over time) to make this as easy as possible.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">Anyway, if I understood correctly, Gabor was implying that I could somehow use/abuse the new feature to achieve a combined AST? By importing all the functions in the other translation units manually? And if memory use really is an issue, is there a way to import a function into the AST, check it out, then lose it when your done with it?<br><br></div></div><div dir="ltr"><div class="gmail_extra">Noah<br><br></div></div></blockquote></span></div></div>
</blockquote></div><br></div></div>