JIT: show profile data for dot flowgraph dumps#42657
JIT: show profile data for dot flowgraph dumps#42657AndyAyersMS merged 2 commits intodotnet:masterfrom
Conversation
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.
|
@CarolEidt PTAL. cc @dotnet/jit-contrib Sample output (
|
|
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. |
|
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). |
|
@dotnet/jit-contrib thoughts on the following?
|
|
@dotnet/jit-contrib anyone want to take a look? Feedback on options noted above is welcome. |
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. |
| break; | ||
| default: | ||
| // These may or may not have an edge to the next block. | ||
| // Add a transparent edge to keep nodes ordered. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
So you'd like to see a spine of blocks in increasing bbNum order? I can add the invisible edges back.
There was a problem hiding this comment.
Yes, that would be my preference, unless there's consensus against it.
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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
There was a problem hiding this comment.
I can do invisible edges to encourage bbNext order, that will give bbNum order if you've recently renumbered, and bbNext order otherwise.
There was a problem hiding this comment.
That sounds great to me.
|
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:
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. |
|
Here's what the above would look like with invisible heavy-weight
|
Yes, precisely - thanks! |
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.