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

[Eric Christopher via Phabricator via llvm-commits]

echristo 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?


I agree. While the erratum is going to be important I think that this going in now doesn't block any future work on erratum handling in the linker or make it more difficult to add other than adding it on top of propeller perhaps, but that's a different issue?

@MaskRay : Is the propeller patch going to (outside of in propeller) going to cause implementing the jcc erratum to be more difficult? If not, then I think we should go forward. If so, can you propose some (hopefully narrow) changes to this patch in order to make that more possible - even "you asked for jcc erratum and we can't do that here" as an error seems like it would be an ok incremental step forward?


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

https://reviews.llvm.org/D68065