<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Op vr 27 sep. 2019 om 02:32 schreef Sriraman Tallam via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">><br>
> If you have the MIR at the time you're making all the propeller optimization decisions, why is the linker rewriting raw x86 assembly, as opposed to performing the relevant transforms on MIR?<br>
<br>
MIR is still one module at a time.  We cannot do inter-procedural<br>
basic block layout here.  We can do much more advanced stuff at the<br>
whole-program level in the linker.  The relaxation code is the down<br>
side.<br>
<br>
For more details, We strongly considered this.  We could run something<br>
like a thin link in thin lto figure out the global layout and hand out<br>
the relevant  subsets of the global decision  to each module.  This<br>
looked more complicated and the individual pieces from each module<br>
should still be globally laid out again by the linker.  This<br>
constraints us on what we can do for layout and also does not work<br>
well with future optimizations like global alignment like David<br>
pointed out.<br></blockquote><div><br></div><div>Apologies for the naive question.</div><div>Why is MIR restricted to being only module at a time?</div><div>If the restriction of only being able to do per-module processing at the MIR level would go away, then all these optimizations could be done in a compile step, and no support would need to be added to a linker?</div><div>If the restriction to do cross-module optimization at the MIR level could be removed, would it become a better tradeoff to do this in an LTO compiler step rather than a linker step?</div><div><br></div><div>Thanks,</div><div><br></div><div>Kristof </div></div></div>