<div dir="auto">Hi all,<div dir="auto"><br></div><div dir="auto">This thread appears to be going poorly.</div><div dir="auto"><br></div><div dir="auto">Fangrui: unless you have a specific concern I think the vast majority of people are in favor of this patch going in as is. I understand that it may not be what we might end up with, but it absolutely is incremental progress towards that goal without making anything harder in the long run and Sriraman and team have said that they'll take responsibility for anything that does arise.</div><div dir="auto"><br></div><div dir="auto">I, Rui, and David all think that this is fine to go in and ultimately Rui is the current code owner. Let's have this go in now and future development can either be worked on separately, brainstormed in the future, or we'll look at what changes need to be made as we get there. </div><div dir="auto"><br></div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 23, 2020, 11:22 PM Fangrui Song via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">MaskRay added a comment.<br>
<br>
In D68065#1937331 <<a href="https://reviews.llvm.org/D68065#1937331" rel="noreferrer noreferrer" target="_blank">https://reviews.llvm.org/D68065#1937331</a>>, @tmsriram wrote:<br>
<br>
> In D68065#1934866 <<a href="https://reviews.llvm.org/D68065#1934866" rel="noreferrer noreferrer" target="_blank">https://reviews.llvm.org/D68065#1934866</a>>, @MaskRay wrote:<br>
><br>
> > I am very glad to see that we have made progress by landing D68063 <<a href="https://reviews.llvm.org/D68063" rel="noreferrer noreferrer" target="_blank">https://reviews.llvm.org/D68063</a>> (llvm/CodeGen/CommandFlags.inc) and D73674 <<a href="https://reviews.llvm.org/D73674" rel="noreferrer noreferrer" target="_blank">https://reviews.llvm.org/D73674</a>> (llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp). Basic block sections is agreed to be useful even outside Properller.<br>
> ><br>
> > There are several optimizations goals:<br>
> ><br>
> > - Alignment inserting<br>
> > - Automatic cache prefetching<br>
> > - Large code model addressing can lower performance quite a bit. A post-link scheme can relax large code model addressting to small code model addressing.<br>
> > - ...<br>
> ><br>
> >   There is a CPU erratum that we want to mitigate.<br>
> > - Intel's Jump Condition Code Erratum<br>
> ><br>
> >   By making this change, we will go the object file level route: annotate object files with metadata so that certain transformations can be performed.<br>
> ><br>
> >   Whether this scheme can satisfy the goals and avoid the erratum, and the uncertainty about how many stuff we will have to reinvent is my biggest concerns.<br>
> ><br>
> >   On <a href="https://lists.llvm.org/pipermail/llvm-dev/2020-February/139543.html" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/pipermail/llvm-dev/2020-February/139543.html</a> (my brainstorming), I mentioned we may achieve our goals and make it suitable for future optimizations by using a file format with more semantics (rather than an object file). I hope we can think more on this, rather than rush to conclusions "this is redoing full LTO. it can't scale"<br>
> ><br>
> >   Considering the above points, I re-iterate my "Request Changes". We need a plan to prove that we can achieve our optimization goals while avoiding caveats (erratum).<br>
><br>
><br>
> @echristo @ruiu<br>
><br>
> If the JCC erratum is the only concern then we are able to show now with experiments that Propeller can produce JCC erratum free binaries with almost no performance impact and only by using the existing assembler mitigations : <a href="http://lists.llvm.org/pipermail/llvm-dev/2020-March/140134.html" rel="noreferrer noreferrer" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2020-March/140134.html</a><br>
><br>
> Let's use that thread to continue to investigate how the linker could potentially do a better job of handling this or other erratums in general.  Could we please unblock this?<br>
<br>
<br>
Intel JCC erratum is not the only concern. My bigger concern is whether we can achieve our post-link optimization goals other than layout shuffling with the current scheme:<br>
<br>
- Alignment inserting<br>
- Automatic cache prefetching<br>
- Large code model addressing can lower performance quite a bit. A post-link scheme can relax large code model addressting to small code model addressing. ...<br>
- ...<br>
<br>
These points were already listed in my previous comments. I believe internally you probably have more brainstorming thoughts. As I said on <a href="https://lists.llvm.org/pipermail/llvm-dev/2020-March/139639.html" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/pipermail/llvm-dev/2020-March/139639.html</a> , I am not yet convinced that with the no disassembly assumption, reordering opaque sections can achieve the above goals. Post-link optimization is not a new idea and there have been several engineering efforts before Propeller. However, Propeller is the first integrating the great idea into LLVM. As I said I look forward to its bright future. I just hope that we can create a generic framework. Our focus is currently section reordering. When we start to think future optimization opportunities, we don't need to create one, two, three, four more frameworks.<br>
<br>
I saw Rahman posted <a href="https://lists.llvm.org/pipermail/llvm-dev/2020-March/140134.html" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/pipermail/llvm-dev/2020-March/140134.html</a> yesterday. Sorry that I did not have time reading it today. If the idea is that more layout work will be done by the compiler, then it starts to look good to me.<br>
<br>
<br>
CHANGES SINCE LAST ACTION<br>
  <a href="https://reviews.llvm.org/D68065/new/" rel="noreferrer noreferrer" target="_blank">https://reviews.llvm.org/D68065/new/</a><br>
<br>
<a href="https://reviews.llvm.org/D68065" rel="noreferrer noreferrer" target="_blank">https://reviews.llvm.org/D68065</a><br>
<br>
<br>
<br>
</blockquote></div>