cmd/compile: optimize print call sequences

[josharian]

The runtime is full of debugging calls of the form println("a=", hex(a), "b=", hex(b)), followed by a throw. These are very useful when something goes wrong, but the generated code for them is very verbose. It can easily account for half of the generated code in hot runtime routines. It is placed at the end of the function, but for icache purposes, it'd be better for it to be outlined and placed far away.

Given the poor share the inliner is in, I'm going to assume that we're not going to add an outliner (even one manually triggered) any time soon.

As an easier fix, I did some work a year ago on this, adding a bunch of helper print routines, like printonestring, which does printlock; printstring; printunlock, all in a single call. And there are probably other helpful combinations I didn't add, like printstringhex, which does printstring; printhex. (An analysis of call ngrams would be useful.) It might also be useful to have a printstringptr that accepts a pointer to a string to print, instead of the string itself, for use particularly with constant strings. And maybe there are other inventive solutions that can shrink call sites further.

The work I did is at josharian@9d18ed5, with preparatory commits josharian@18a0eff and josharian@ce3a481.

It no longer applies cleanly due to substantive compiler refactoring in the intervening year, but perhaps someone is interested in re-creating those patches at tip. And maybe improving them.

Because there's some existing code written to work from, this might be a good first issue for someone new to the compiler.

[rsc]

How big are the icache lines? 64 bytes?
It seems hard to believe that if the prints are at the end of the function,
that they are taking up any space in hot lines.

[RyanMuzzey]

Is this still an issue available to new contributors?

[RyanMuzzey]

It looks like this was addressed in this change which added lock before and unlock after the print functions are called. Is there still a need for further changes here, or can this issue be closed?

[josharian]

That change was just code re-arrangement. (It even comments as much in the commit message.) Given Russ's comments above, though, this is probably not a good place to spend time. I'll close it. Thanks for poking at it, @RyanMuzzey .