JIT: show profile data for dot flowgraph dumps

[AndyAyersMS]

Also, tweak layout a bit, and update so that if a method is jitted
multiple times the files don't overwrite one another. Instead a
suffix is added to indicate the kind of jit codegen.

[AndyAyersMS]

@CarolEidt PTAL. cc @dotnet/jit-contrib

Sample output (InsertionSort) from a tiered PGO run, after the struct promotion phase. Note there are various inconsistencies in the counts.

• 5-sided blocks are entries and exits.
• The dog-eared blocks are BBF_INTERNAL.
• green edges are lexical backedges
• blue edges are flow to bbNext

[AndyAyersMS]

If you dump the FG per phase you'll see that once we've computed edge weights the dumps switch to a normalized view, that is:

Might make sense to always show one or the other though I'm not sure we're set up to do that easily.

[AndyAyersMS]

Also very early on there are no edges as the code relies on pred lists. So wondering if I should instead/in addition use the successor iterator to show edges.

(need to look at some EH cases too, suspect handlers will be disconnected).

[AndyAyersMS]

@dotnet/jit-contrib thoughts on the following?

• remove the xml style dumps (not sure what can parse these)
• rework to allow (but not yet support) other graph markup formats (dgml?)
• always use successor iterator instead of chasing flow edges
• some means for tying in EH flow (possibly edges from start and maybe end of try regions to associated handlers?) I have done fine-grained EH edges in the past and it gets to be overwhelming. Or (for dot) we could use cluster subgraphs to show extent of try regions
• normalized vs raw counts
• distinguish synthetic weights from profile data?

[AndyAyersMS]

@dotnet/jit-contrib anyone want to take a look? Feedback on options noted above is welcome.

[CarolEidt]

Might make sense to always show one or the other though I'm not sure we're set up to do that easily

I'd be in favor of always showing a normalized count. I can't imagine it would be terribly difficult, though I can imagine that it might be imperfect - I think that it makes the visualization much easier to reason about.

[CarolEidt]

Although I realize that it may not always be the best layout, I find it so much easier to reason about these graphs when the nodes are in sequential order by bbNum. IIRC this was an imperfect mechanism for doing so, but it mostly worked.

[AndyAyersMS]

So you'd like to see a spine of blocks in increasing bbNum order? I can add the invisible edges back.

[CarolEidt]

Yes, that would be my preference, unless there's consensus against it.

[briansull]

Internal blocks like a loop preheader block have a high number at the are allocated as the highest block number. (Until we renumber the blocks)

[briansull]

My preference is to have the fall through block always be a short straight line down to the next block:

block A  ------ taken branch
     |
     |
block B  ------- taken branch

[AndyAyersMS]

I can do invisible edges to encourage bbNext order, that will give bbNum order if you've recently renumbered, and bbNext order otherwise.

[CarolEidt]

That sounds great to me.

[AndyAyersMS]

One issue with always showing normalized counts is that we currently have to do a bunch of work to compute the true method entry count because we don't cleanly handle the case where IL offset 0 is a branch target during instrumentation. I plan to fix this but we need to be a bit careful because we also would like to remain backwards compatible with the legacy IBC scheme.

So we currently have 3 phases of "evolution" of the flow graph with profile data:

• Importer through Build Preds: raw block weights only, no pred edges
• Build Preds through Compute Edge weights: raw block weights only, pred egdes but no weights
• post Compute Edge Weights: normalized block weights, pred lists, edge weights

I intend to have the jit start building a more fully descriptive flow graph earlier, but it will take some work.

But if we can get at the "called count" simply from instrumentation then we can have normalized weights from the start, without needing pred edges or pred edge weights.

[briansull]

LGTM

[AndyAyersMS]

Here's what the above would look like with invisible heavy-weight bbNext edges. @CarolEidt is this what you had in mind?

[CarolEidt]

@CarolEidt is this what you had in mind?

Yes, precisely - thanks!

[CarolEidt]

LGTM - thanks!