<div dir="ltr">I think that the change itself isn't too invasive right now and could lead to more understanding of how we should move forward. Perhaps we could have it in for now and see how it develops?<div><br></div><div>I am curious about the JCC erratum side of things, but that can also probably be handled later as well?</div><div><br></div><div>Mostly don't think we should hold up making progress unless it's going to inhibit more progress?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 20, 2020 at 5:55 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">MaskRay requested changes to this revision.<br>
MaskRay added a comment.<br>
This revision now requires changes to proceed.<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" target="_blank">https://reviews.llvm.org/D68063</a>> (llvm/CodeGen/CommandFlags.inc) and D73674 <<a href="https://reviews.llvm.org/D73674" rel="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>
<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" 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>
CHANGES SINCE LAST ACTION<br>
  <a href="https://reviews.llvm.org/D68065/new/" rel="noreferrer" target="_blank">https://reviews.llvm.org/D68065/new/</a><br>
<br>
<a href="https://reviews.llvm.org/D68065" rel="noreferrer" target="_blank">https://reviews.llvm.org/D68065</a><br>
<br>
<br>
<br>
</blockquote></div>