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

[Eric Christopher via llvm-commits]

Hi all,

This thread appears to be going poorly.

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.

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.



On Mon, Mar 23, 2020, 11:22 PM Fangrui Song via Phabricator <
reviews at reviews.llvm.org> wrote:

> 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20200324/b3babf6d/attachment.html>