<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;"><br><div><div>On Jul 17, 2013, at 7:09 PM, Shuxin Yang <<a href="mailto:shuxin.llvm@gmail.com">shuxin.llvm@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000" 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;"><div class="moz-cite-prefix">Andy and I briefly discussed this  the other day, we have not yet got chance to list a detailed pass order<span class="Apple-converted-space"> </span><br>for the pre- and post- IPO scalar optimizations.<span class="Apple-converted-space"> </span><br><br>This is wish-list in our mind:<br><br>pre-IPO:  based on the ordering he propose, get rid of the inlining (or just inline tiny func), get rid of<span class="Apple-converted-space"> </span><br>               all loop xforms...<br><br>post-IPO: get rid of inlining, or maybe we still need it, only perform the inling to to callee which now become tiny.<br>               enable the loop xforms.<br><br>                The SCC pass manager seems to be important inling,  no matter how the inling looks like in the future,<span class="Apple-converted-space"> </span><br>                I think the passmanager is still useful for scalar opt.  It enable us to achieve cheap inter-procedural<span class="Apple-converted-space"> </span><br>                opt hands down in the sense that we can optimize callee, analyze it, and feedback the detailed whatever<br>                info  back to caller (say info like "the callee already return constant 5", the "callee return value in 5-10",<span class="Apple-converted-space"> </span><br>                and such info is difficult to obtain and IPO stage, as it can not afford to take such closer look.<span class="Apple-converted-space"> </span><br><br>I think it is too early to discuss the pre-IPO and post-IPO thing, let us focus on what Andy is proposing.<span class="Apple-converted-space"> </span><br></div></div></blockquote></div><br><div>Right. We don’t need to debate the specifics of the LTO pipeline yet, particularly in this thread. The important thing is that the function passes will run in the same order for LTO, so we should probably factor PassManagerBuilder to make that easy. The difference with LTO is that some of the canonical IR passes will end up running at least twice, in both pre and post IPO. The lowering IR passes will only run in post IPO.</div><div><br></div><div>-Andy</div></body></html>