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

Sriraman Tallam via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Mar 23 10:21:52 PDT 2020


tmsriram added a comment.

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?


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

https://reviews.llvm.org/D68065





More information about the llvm-commits mailing list