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

[Eric Christopher via llvm-commits]

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?

I am curious about the JCC erratum side of things, but that can also
probably be handled later as well?

Mostly don't think we should hold up making progress unless it's going to
inhibit more progress?

On Fri, Mar 20, 2020 at 5:55 PM Fangrui Song via Phabricator <
reviews at reviews.llvm.org> wrote:

> MaskRay requested changes to this revision.
> MaskRay added a comment.
> This revision now requires changes to proceed.
>
> 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).
>
>
> 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/20200320/bf801b2d/attachment.html>