
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">On Jul 16, 2013, at 3:32 PM, Nick Lewycky <<a href="mailto:nlewycky@google.com">nlewycky@google.com</a>> wrote:<br><div><br class="Apple-interchange-newline"><blockquote type="cite"><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">* Parallelize ModulePasses by splitting them into an analysis phase and an optimization phase. Make each per-TU build emit the .bc as usual plus an analysis-file (for instance, call graph, or "which functions reads/modify which globals"). Merge all the analysis-files and farm them back out to be used as input to the programs optimizing each .bc individually -- but now they have total knowledge of the whole-program call graph and other AA information, etc.</span></blockquote></div><br><div>Shuxin presented the same idea to me. It offers the best opportunity to scale while sidestepping concurrency issues. It avoids problem of loading all functions during the IPO phase then cloning them into separate LLVMContexts later. I don’t see this as part of the first milestone though.</div><div><br></div><div>-Andy</div></body></html>