[llvm-dev] [RFC] llvm-mca: a static performance analysis tool

[Andrea Di Biagio via llvm-dev]

(sending this message again. Apparently it didn't make it into llvm-dev
because the message was too long. Sorry for the spam).


Hi Clement!

On Fri, Mar 2, 2018 at 12:33 PM, Clement Courbet <courbet at google.com> wrote:

> Hi Andrea,
>
> Thanks for this great RFC ! I've put some high-level comments here, and
> I'll give more focused comments in the review on Phabricator.
>
>
Thanks!


>
> On Thu, Mar 1, 2018 at 6:22 PM, Andrea Di Biagio <
> andrea.dibiagio at gmail.com> wrote:
>
>> Hi all,
>>
>> At Sony we developed an LLVM based performance analysis tool named
>> llvm-mca. We
>> currently use it internally to statically measure the performance of
>> code, and
>> to help triage potential problems with target scheduling models.  We
>> decided to
>> post this RFC because we are interested in the feedback from the
>> community, and
>> we also believe that other people might be interested in a tool like this.
>>
>>
> We are definitely interested in tools like this. As a matter of fact, we
> (Google) have developed a similar tool. Our approach is very similar to the
> one described here, so I’m confident that we can merge our tool with the
> one proposed here. There are some similarities and differences in the
> design, which I’ll quickly go over here. I’ll give my opinions about
> respective merits of each approach when discussing specific points below.
>
> The main differences with the design are:
>
>    -
>
>    We simulate the CPU frontend too (parse/decode). We’ve found out that
>    some kernels benefit from instruction reorderings that do not change port
>    pressure but change how instructions are parsed and decoded (e.g. parse
>    window can be a bottleneck).
>    -
>
>    Our code is more modular on the subtarget model side. Our simulator is
>    divided in four parts:
>    -
>
>       CPU components (parser/decoder/renamer/ROB/Issue Port/...) are
>       modeled and unit tested individually. These are intended to be mostly
>       target-independant.
>       -
>
>       Each subtarget describes how to assemble these components together.
>       This is where knowledge about the target is injected.
>       -
>
>       The framework drives the components in a subtarget-agnostic way.
>       Events are logged to a `SimulationLog` object. This is similar to the
>       `HWEventListener` interface in llvm-mca.
>       -
>
>       Analysis passes analyze the `SimulationLog` to extract whatever
>       metric they care about (e.g. port pressure or IPC), or generate an
>       annotated trace. A similar functionality is provided in llvm-mca `XXView`
>       implementations.
>
> We also have a IACA-like binary that displays analysis results.
>
> For reference, our code can be found here: https://github.com/google/EXEg
> esis/tree/master/llvm_sim
>

Thanks for the info. I will definitely look into your code.

I had a look at some of your comments in the review, and I agree that the
design can/should be improved.Our plan is also to move at one point the
analysis into a library in order to make it accessible from the compiler
(this was requested by Simon (Pilgrim) many times :-)).
It would be great if we could work together on this tool, and I like your
idea of integrating features from your tool into this one.
We could start by further modularizing the tool (as you have already
suggested in the phabricator review). We could then integrate all the
missing analysis (plus improvements) from your code into this.
Cheers,
-Andrea
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180302/1c12ba68/attachment.html>