-
Type:
Enhancement
-
Resolution: Unresolved
-
Priority:
P4
-
Affects Version/s: 26
-
Component/s: hotspot
We currently rely on Node::dump() to do IR matching. This provides some useful information but also a lot of noise (e.g. node indices are useless).
We should optimize this dump for the IR framework. We probably do not want to cut down on information currently dumped with Node::dump() because that is useful for debugging sessions. On the other hand, we also do not want to add more information that is actually not that useful for debugging sessions and only adds noise.
This naturally suggests that we should come up with an IR framework specific node dump. This could be highly optimized and easy to parse for the framework.
Possible ways to tackle this:
Use IGV dumps
---------------------
Play around with reusing IGV dumps to do IR matching on. These already provide a lot more interesting information on top of Node::dump(). Some useful additions for the IR framework can also be beneficial to be shown in IGV for debugging sessions.
Upside: Sounds easier and more straight forward. Possible to get quick results.
Downside: We dump a lot of information that is probably not needed for IR matching. Could be slow.
Refined dumps
---------------------
1) Identify what node information is currently used in IR matching by going over all entries in IRNode.java.
2) Categorize the needed information by node groups/classes.
3) Most of the nodes only match on the node name. We could provide a generic dump in Node::dump_for_ir_framework() (name TBD) that only dumps the node name. By the categorization done in 2), we can identify which sub classes need to extend this dump.
4) Once we agree on the information, we need to find a new format on how to print this information such that parsing can pick it up correctly.
Upside: Fewer information dumped which is faster while dumping and later at parsing, parsing becomes easier, we could also explore the possibility to get away from -XX:+LogCompilation while tackling this and include all the necessary information in a own file.
Downside: More complex to implement, limited information available to match on things previously possible with Node::dump() (a workaround could be to still somehow enable Node::dump() for specific regexes).
Useful information to add:
- Loop Depth
- direct input nodes
- direct output nodes
- placement within Java code
Doing this could be a trade-off between the regex matching we have today with Node::dump() and having a full-blown IR graph parsing where we can query whatever we want.
We should optimize this dump for the IR framework. We probably do not want to cut down on information currently dumped with Node::dump() because that is useful for debugging sessions. On the other hand, we also do not want to add more information that is actually not that useful for debugging sessions and only adds noise.
This naturally suggests that we should come up with an IR framework specific node dump. This could be highly optimized and easy to parse for the framework.
Possible ways to tackle this:
Use IGV dumps
---------------------
Play around with reusing IGV dumps to do IR matching on. These already provide a lot more interesting information on top of Node::dump(). Some useful additions for the IR framework can also be beneficial to be shown in IGV for debugging sessions.
Upside: Sounds easier and more straight forward. Possible to get quick results.
Downside: We dump a lot of information that is probably not needed for IR matching. Could be slow.
Refined dumps
---------------------
1) Identify what node information is currently used in IR matching by going over all entries in IRNode.java.
2) Categorize the needed information by node groups/classes.
3) Most of the nodes only match on the node name. We could provide a generic dump in Node::dump_for_ir_framework() (name TBD) that only dumps the node name. By the categorization done in 2), we can identify which sub classes need to extend this dump.
4) Once we agree on the information, we need to find a new format on how to print this information such that parsing can pick it up correctly.
Upside: Fewer information dumped which is faster while dumping and later at parsing, parsing becomes easier, we could also explore the possibility to get away from -XX:+LogCompilation while tackling this and include all the necessary information in a own file.
Downside: More complex to implement, limited information available to match on things previously possible with Node::dump() (a workaround could be to still somehow enable Node::dump() for specific regexes).
Useful information to add:
- Loop Depth
- direct input nodes
- direct output nodes
- placement within Java code
Doing this could be a trade-off between the regex matching we have today with Node::dump() and having a full-blown IR graph parsing where we can query whatever we want.