[PATCH] D68065: Propeller: LLD Support for Basic Block Sections

[Fangrui Song via Phabricator via llvm-commits]

MaskRay added a comment.

In D68065#1937331 <https://reviews.llvm.org/D68065#1937331>, @tmsriram wrote:

> In D68065#1934866 <https://reviews.llvm.org/D68065#1934866>, @MaskRay wrote:
>
> > I am very glad to see that we have made progress by landing D68063 <https://reviews.llvm.org/D68063> (llvm/CodeGen/CommandFlags.inc) and D73674 <https://reviews.llvm.org/D73674> (llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp). Basic block sections is agreed to be useful even outside Properller.
> >
> > There are several optimizations goals:
> >
> > - Alignment inserting
> > - Automatic cache prefetching
> > - 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.
> > - ...
> >
> >   There is a CPU erratum that we want to mitigate.
> > - Intel's Jump Condition Code Erratum
> >
> >   By making this change, we will go the object file level route: annotate object files with metadata so that certain transformations can be performed.
> >
> >   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.
> >
> >   On https://lists.llvm.org/pipermail/llvm-dev/2020-February/139543.html (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"
> >
> >   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).
>
>
> @echristo @ruiu
>
> 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 : http://lists.llvm.org/pipermail/llvm-dev/2020-March/140134.html
>
> 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?


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:

- Alignment inserting
- Automatic cache prefetching
- 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. ...
- ...

These points were already listed in my previous comments. I believe internally you probably have more brainstorming thoughts. As I said on https://lists.llvm.org/pipermail/llvm-dev/2020-March/139639.html , 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.

I saw Rahman posted https://lists.llvm.org/pipermail/llvm-dev/2020-March/140134.html 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.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68065/new/

https://reviews.llvm.org/D68065