[llvm-dev] [RFC] Moving tools/llvm-mca/lib into lib/MCA

David Greene via llvm-dev llvm-dev at lists.llvm.org
Wed Dec 12 13:37:46 PST 2018


+1.  Great work!

                            -David

Andrea Di Biagio via llvm-dev <llvm-dev at lists.llvm.org> writes:

> Thanks Clement for working on this.
>
> I like the idea of moving the core abstractions of llvm-mca in
> llvm/lib, as it potentially enables a number of interesting use cases
> and future developments.
>
> As you wrote, the patch is very simple (a pretty mechanical change).
> From my point of view, this all looks good. Let see if other people
> have the same opinion on this.
>
> -Andrea
>
> On Wed, Dec 12, 2018 at 11:58 AM Clement Courbet <courbet at google.com>
> wrote:
>
>         (on the correct mailing list)
>
>     
>         Hi all,
>
>     tl;dr: We'd like to propose moving tools/llvm-mca/lib into lib/MCA
>     and create a new MCA library in LLVM.
>
>     llvm-mca has recently been split into its core part and the tool
>     part.
>
>     *       The core part simulates the execution of a basic block of
>       machine instructions as modeled by the llvm SchedModel.
>
>     *       The tool part deals with the plumbing and interacting with
>       the user.
>
>     The core part can be used by parts of LLVM that deal with cost
>     modeling (e.g. scheduling and vectorization). MCA provides a more
>     realistic target for optimization than the heuristics typically
>     used to drive these passes. We think that using approaches based
>     on fine-grained cost modeling can greatly improve the performance
>     of critically hot code, by trading compile time for performance.
>
>     As an example of how MCA can be used to improve scheduling, we
>     have built a prototype machine scheduler that optimizes the
>     simulated latency of a block of code under the constraints of the
>     scheduling DAG. We've had interesting wins of 2-3% on assembly
>     kernels for webp and gemmlowp*.
>
>     The patch is completely mechanical and can be seen here. It only
>     moves the files and updates all references.
>
>     We'd like to hear if there are any things comments/objections to
>     this change.
>
>     Thanks !
>
>     *note: We did this before llvm-mca was released and were using a
>     different simulator, but the idea remains the same.
>
>     
>     On Wed, Dec 12, 2018 at 11:44 AM Clement Courbet
>     <courbet at google.com> wrote:
>     
>     
>                 Hi all,
>
>         tl;dr: We'd like to propose moving tools/llvm-mca/lib into
>         lib/MCA and create a new MCA library in LLVM.
>
>         llvm-mca has recently been split into its core part and the
>         tool part.
>
>         *           The core part simulates the execution of a basic
>           block of machine instructions as modeled by the llvm
>           SchedModel.
>
>         *           The tool part deals with the plumbing and
>           interacting with the user.
>
>         The core part can be used by parts of LLVM that deal with cost
>         modeling (e.g. scheduling and vectorization). MCA provides a
>         more realistic target for optimization than the heuristics
>         typically used to drive these passes. We think that using
>         approaches based on fine-grained cost modeling can greatly
>         improve the performance of critically hot code, by trading
>         compile time for performance.
>
>         As an example of how MCA can be used to improve scheduling, we
>         have built a prototype machine scheduler that optimizes the
>         simulated latency of a block of code under the constraints of
>         the scheduling DAG. We've had interesting wins of 2-3% on
>         assembly kernels for webp and gemmlowp*.
>
>         The patch is completely mechanical and can be seen here. It
>         only moves the files and updates all references.
>
>         We'd like to hear if there are any things comments/objections
>         to this change.
>
>         Thanks !
>
>         *note: We did this before llvm-mca was released and were using
>         a different simulator, but the idea remains the same.
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


More information about the llvm-dev mailing list