I worry a bit about an overwhelming flood of messages, versus targeted debug flags.

Probably not for Go 1.7?

FWIW, anything printed with -m should be understandable by end users (to contrast -m with -d).

There are 2 things that used to be reported by -m which are now missing with SSA. One is "shift bounds check elided", the other is "index bounds check elided". The former seems difficult as that removal is now implicitly embedded in rewrite rules. You could also argue it isn't that interesting. The latter we should probably replicate wherever SSA removes bounds checks.

I agree shift bounds checks are not that interesting. On the other hand I
wonder if maybe reporting certain optimizations applied during the general
rewrite rules is something that will come up again.

On Tue, May 17, 2016 at 5:05 PM Keith Randall notifications@github.com
wrote:

There are 2 things that used to be reported by -m which are now missing
with SSA. One is "shift bounds check elided", the other is "index bounds
check elided". The former seems difficult as that removal is now implicitly
embedded in rewrite rules. You could also argue it isn't that interesting.
The latter we should probably replicate wherever SSA removes bounds checks.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#15086 (comment)

Yes, it would be nice to know if certain rules fired or not. All the rules is too much, but we could label certain rules with strings that we would print when the rules fired (if -m or something similar was set).

We need to cross-reference work here with work on #13068, so I'll assign myself.

This bug is wrong. The 'index bounds check elided' error comes from walk.go, and we're still producing it; the test for this (bounds.go) is enabled for amd64 and does not fail. What more nearly needs to activate ssa/prove/debug is -d slice for sliceopt.go (that's bug #13608) though everything there is stated in terms of the ssa check operand that can be proved redundant, instead of the context (1st slice operand, 2nd slice operand, etc) so it still requires a separate test, or substantial replumbing in the prove code to get the context passed through properly to replicate these messages. And if the recommended change is made (-m activates ssa/prove/debug), the only change to the output anywhere in the tests is 4 new errors in escape2.go that have nothing to do with escape analysis.

The append optimizations, I am not sure that we are doing them; I went looking, and it's not clear where they would be, so that might be a bug of sorts. But that's not this bug.

Append optimizations were done in CLs 21813 and 22197.

Part of the value in -m is the automated tests, but part is in helping interested users understand what the compiler is thinking. I suppose those can just be added ad hoc as we notice that they would be useful.

Some of the chit-chat for the append optimizations I just added (seconds ago) in https://go-review.googlesource.com/23290 .