Page MenuHomePhabricator

Flags for displaying only hot nodes in CFGPrinter graph
ClosedPublic

Authored by knaumov on Feb 10 2020, 10:27 AM.

Details

Summary

Added flags to display only the hot nodes (nodes who have at least one a successor who doesn't end
in deopt or unreachable) in the CFGPrinter graph. Before displaying the graph, the first run of the
function isNodeHidden launches a check for every BB in the graph on a matter of being hidden.
Before answering, each node and its successors are being checked for ending in deopt or unreachable
and verified with the corresponding flags ("cfg-hide-unreachable-paths" and "cfg-hide-deoptimize-paths")
being turned on. If the leaf node is such as described before, it is marked to be not shown in the graph.
If any node has all of its successors not being shown, this node is automatically not shown as well. This
check uses post-order traversal to make sure that all of the successors already have been visited before
making the analysis for the said node.

Diff Detail

Event Timeline

knaumov created this revision.Feb 10 2020, 10:27 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 10 2020, 10:27 AM
apilipenko accepted this revision.Feb 12 2020, 12:17 PM

LGTM with the renaming addressed.

llvm/lib/Analysis/CFGPrinter.cpp
39–44

Suggest renaming to HideUnreachablePaths, HideDeoptimizePaths.

This revision is now accepted and ready to land.Feb 12 2020, 12:17 PM

what is the use case of these options? Do hidden nodes create too much noise?

knaumov updated this revision to Diff 244267.Feb 12 2020, 1:37 PM

Resolving @apilipenko 's suggestions
As I don't have commit access, can you please commit the change for me?

Replying to @davidxl
This option is useful when you are analyzing only the "hot" paths on the CFG.
Using these flags you are getting rid of all the unnecessary paths in the graph (the ones that end in deopt or are unreachable)

what is the use case of these options? Do hidden nodes create too much noise?

This is mostly for performance analysis. In our compiler we end up with many code paths resulting in deoptimization. These code paths are supposed to be cold and are not interesting when we are looking for the "fast path" performance. Filtering these has a nice effect of streamlining the CFG to the common path only.

what is the use case of these options? Do hidden nodes create too much noise?

This is mostly for performance analysis. In our compiler we end up with many code paths resulting in deoptimization. These code paths are supposed to be cold and are not interesting when we are looking for the "fast path" performance. Filtering these has a nice effect of streamlining the CFG to the common path only.

Makes sense to add rationale like this as a paragraph to revision description.

davidxl accepted this revision.Feb 18 2020, 9:04 AM

lgtm

This revision was automatically updated to reflect the committed changes.