<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 27, 2019 at 12:37 AM Kristof Beyls via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><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 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" target="_blank">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></div></blockquote><div><br></div><div>LTO style optimization uses the monolithic model which Propeller moves away from. The design principle is as much as possible preparation work will be done at module level, while the global step is lean and mean.</div><div><br></div><div>For layout/splitting/alignment/packing, linker is the right platform to use. It sees/creates many things compiler does not, such as PLTs/stubs/trampolines. etc. Besides, using linker allows inter-procedural reordering of blocks in native object files as long as those files are compiled with the right annotations. For instance, we can do per application optimal layout for memcpy/memset functions from libc.a depending on the profile data for that app.</div><div><br></div><div>David</div><div><br></div><div> </div><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_quote"><div><br></div><div>Thanks,</div><div><br></div><div>Kristof </div></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>