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

[Andrea Di Biagio via llvm-dev]

 Hi Philip,

On Fri, Mar 2, 2018 at 6:06 PM, Philip Reames <listmail at philipreames.com>
wrote:

> Reading through this last night got be thinking about how to model control
> flow.  Given most of my source code tends to be very branchy, be limited to
> straight line code is quite restrictive.  The main thing is that it
> requires a lot of hand simplification which can be rather error prone at
> times.
>
> It occurs to me that we could remove the restriction around branches
> without necessarily fully modeling fetch, decode, or prediction.  If in
> addition to an assembly file, we also feed the tool a trace of branch
> executions, the tool could essentially unroll all loops dynamically.  The
> type of thing I'm thinking of would look like something like this: (ENTRY,
> branch_dest, branch_dest, branch_dest) where each "branch_dest" is the
> taken successor of the next encountered branch instruction.
>
> As an example, consider a simple loop which executes 3 times:
> ENTRY:
>   # fallthrough
> bb1:
>   # various instructions
>   jne bb1
> bb2:
>   ret
>
> The trace for this would look like: (ENTRY, bb1, bb1, bb1, FALLTHROUGH).
>
> The nice thing about such a branch trace is that it separate the source of
> the trace from the analysis tool.  You could provide an actual trace
> collected through instrumentation, or a predicted trace generated from
> sample profiling information.
>

I think so too. That would be an interesting extension.

Ideally, a trace could contain even more than just branch information. As
Andy wrote in his first comment " Combining the static model with a sampled
dynamic hardware event profile would be amazing.".  The idea of having a
branch trace is nice and it can be a start.


>
> (There are obvious extensions to handle indirect branches, calls, and such
> here.  I'm leaving that as an exercise for the reader at the moment.)
>
> By itself, this seems like a really useful usability improvement.
>
> You could also build on top of this notion to model both branch prediction
> mispredicts and resource limitations.  (Or only one or the other.)  From
> the perspective of the predictor, the trace would be ground truth so you
> could analyze how well a particularly prediction strategy works on that
> particular trace.  Distinct from the prediction, you could model delay
> between branch execution and condition satisfaction to identify resource
> limits in the actual speculative execution.  (I'm very deliberately being
> vague here; it's been a long time since I looked into this aspect of things
> and don't remember the appropriate terminology.  Figured it was better to
> be vague than potentially misleading by getting it wrong.)
>


Makes sense. Thanks for the idea.

-Andrea


>
> Philip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180302/310c06b5/attachment.html>