Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

cmd/compile: make SSA output more readable #12071

Closed
josharian opened this issue Aug 7, 2015 · 6 comments
Closed

cmd/compile: make SSA output more readable #12071

josharian opened this issue Aug 7, 2015 · 6 comments
Labels
FrozenDueToAge
Milestone
Unplanned

Comments

@josharian
Copy link
Contributor

@alandonovan said during GopherCon that we should make our SSA printer amazing, since we're going to spend a lot of time poring over the output. I see more and more how right he was.

This issue is to discuss ideas for making the output more readable.

A few thoughts:

  • I wonder whether we should steal any SSA formatting techniques from Alan's SSA work.
  • A couple of weeks ago I hacked together a dot printer for functions, so you could use graphviz to see the control flow structure, but for all but the simplest functions, it was overwhelming.
  • The main things I have wanted recently are:
    • the ability to easily see how a function changes over time
    • easy navigation within a function--from a value to its uses, from a block/value mention to its definition, etc.
    • the ability to annotate values/blocks/etc with what I know about them

Perhaps generating HTML might be a good way to achieve this second goal--javascript and links could maybe help with the navigation challenges. It might also help with the first. For example, if every pass was laid out in a new column, and clicking a value highlighted its definition and uses across all passes, then it might be easier to navigate across time. There is an implementation question here: We'd need to have a notion of value/block identity across passes, which is non-trivial. However, we also need that for other purposes, like generating debug info. As for annotation, ideally all relevant annotation would eventually be automatically inserted, once we know what kinds of things we need to know.

What do you want from an SSA printer? Got ideas?

cc @randall77 @tzneal @dr2chase @alandonovan
@josharian josharian added this to the Unplanned milestone Aug 7, 2015
@josharian
Copy link
Contributor Author

@griesemer did you close this by accident? Reopening...

@josharian josharian reopened this Aug 7, 2015
@griesemer
Copy link
Contributor

@josharian Apologies - this is happening to me lately. I was about to add something to this issue but then decided that all was said already. For some reason I appear to subconsciously interpret "Close and comment" as "Cancel" I think.

(It's really a bad UI layout. Close should be red, and not the biggest button right next to "Comment").

But now that I'm here:

I 100% agree with Alan Donovan's sentiment. Probably the single-biggest useful feature of the "C1" (client) compiler in the Java HotSpot VM (written back in the day) was the relatively "pretty" and easy-to-read output of the intermediate representation. It was (basic) block-by-block, with one line for each "instruction". The original code was not based on SSA but had an SSA-like format. The one major piece of code that survived from that time (almost 20yrs back!), even after they transitioned to SSA intermediate representation, is the code printing that output. So, yes, great, readable output for intermediate representation pays over time.

@bradfitz
Copy link
Contributor

bradfitz commented Aug 7, 2015

I was also thinking an HTML-based viewer would be nice to let you visualize the passes.

@tzneal
Copy link
Member

tzneal commented Aug 8, 2015

Some more nice to have features:

  • dead values marked as dead (light gray or some other light color if in html)
  • block dominators/dominees (e.g. CL 13331 + dominees)
  • if HTML + js, allow toggling annotations on/off (e.g. turn off dominator display)

If HTML is chosen, it would still be good if the console output was as nice as possible. I would likely use the console output most of the time and resort to html output for more complex use cases.

@josharian
Copy link
Contributor Author

Thanks, @tzneal, good ideas.

I'll aim to pull together a quick and dirty HTML prototype that is entirely independent of the console output, and we can see how we feel about it.

More input always welcome.

@gopherbot
Copy link

CL https://golang.org/cl/13472 mentions this issue.

@golang golang locked and limited conversation to collaborators Mar 1, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
5 participants
@bradfitz @tzneal @josharian @griesemer @gopherbot