RFR: 8251464: make Node::dump(int depth) support indent

[Liu, Xin]

Thanks. Andrew.   
I didn't think of that. Indeed, No matter du-chain or du-chain, there may have more than one path. 
So far, I only need to know one path.  it's because I am debugging why IterGVN and CCP wipe out my nodes. 
Let me think about it more. I will find a JBS issue about it. 

@Tobias, 
Could you take a look at my PR? 
https://github.com/openjdk/jdk/pull/371

You reviewed it before. I just fixed a bug since then.
Here I set indentation number when a node enqueues. This guarantees the output can indent in BFS order. 
https://github.com/openjdk/jdk/pull/371/commits/2c5376f092f50a6e918f6730a472de9a64cca6ee#diff-e1c5a771a82d5fdb7e88c5b90b444736R1891

thanks,
--lx

________________________________________
From: Andrew Dinn <adinn at redhat.com>
Sent: Monday, September 28, 2020 2:07 AM
To: Liu, Xin; Tobias Hartmann; 'hotspot-compiler-dev at openjdk.java.net'
Subject: RE: [EXTERNAL] RFR: 8251464: make Node::dump(int depth) support indent

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



Hi Xin Liu,

On 26/09/2020 08:08, Liu, Xin wrote:
> This feature is intended to dump a small portion of ideal graph in
> the debugger. In that scenario, I think indentation does help my
> eyes.

Yes, I think it is most useful when dumping subgraphs at depths between
2 and, say, 5.

> Thank you to share your experiences. yes, I tried it(sort -n file)
> and this tip is incredibly effective! The ordered nodes can help
> people to catch what they are looking for quickly.

Good. I'm glad sharing my working practice was useful to at least one
person :-)

> I don't want to break anybody's established workflow, so I reset the
> flag PrintIdealIndentThreshold to 0. It means node.dump won't use any
> indentation until we set it.
> https://openjdk.github.io/cr/?repo=jdk&pr=371&range=00#udiff-0

That's very considerate of you. Thank you.

> You guys must have some fancy gdb scripts, emacs lisp plugin or handy
> shell scripts etc. The only downside is they are personal arsenal and
> it may be not easy to maintain them sometime. On the other side of
> spectrum, starters like me need to bootstrap in long way.  Sometimes,

I'm afraid I don't have a lot more to share. Mostly, I don't write
scripts. I usually just write the dump output to a file and then
process it with bash, sed and awk code written on the command line. I
have written extensive elisp search and formatting functions in the past
but not for parsing ideal graphs.

> we need to reinvent the wheel. eg. I spent a lot of time to develop a
> function to query a node by idx. I finished it but eventually came
> across this handy function in node.cpp.  that's what I did!
>
> // Call this from debugger with root node as default: Node*
> find_node(const int idx) { return
> Compile::current()->root()->find(idx); }

Well, now you have taught me something I didn't know in return. Thanks
for sharing ;-)

> That's why I'd like to put some debug functionalities to c2 codebase.
> I think we can collect those handy functions in an individual file.
>  What do you think? I have another 2 candidates I plan to work on. 1.
> dump all node and sorted them by indices 2. dump a path from node a
> to node b.  We can have a depth-first search along du or ud chains.

Option 1 is easily achieved by writing the graph dump to file and
passing through sort -n so it's not a great step forward.

Option 2 sounds like it would be more useful. Initially I was wondering
what you would do when there are multiple paths. then I thought perhaps
the command ought to list all paths in some well-defined order? That
would make the case where the nodes are not connected uniform with the
cases where there is one or more path i.e. print 0 paths, 1 path, 2
paths etc

regards,


Andrew Dinn
-----------