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.
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
cmd/compile: redundant information produced in compiler optimization debug output #46328
Comments
It looks the difference here is |
Another example, in which it is NOT (edited) clear whether or not the package main
type T int
const N = 1<<12
var i = N - 1
func main() {
var r1 = g() // make([]T, N) does not escape
println(r1[i])
}
func g() []T {
var ts = make([]T, N) // make([]T, N) escapes to heap
return ts
}
|
It looks like you're passing the IIUC, this is mainly compiler debug output. I'm all for making that better, but I think in this particular case you do want to know both things. Looking at your most recent example, I think it's saying that the inlined version doesn't cause an allocation while the non-inlined version does. Both pieces of information are useful, not redundant. |
Thanks for the explanation. Personally, I think brings some noises and misunderstanding. |
Generally speaking, I think if someone is trying to work with the compiler on these optimizations, these sorts of situations would be more clear to them. And again, I think more information here is better than less. For large projects, it might be better to use the JSON output ( |
More on To get this information, pass The format is described here: https://go.googlesource.com/go/+/refs/heads/master/src/cmd/compile/internal/logopt/log_opts.go#24 I wrote a proof of concept for combining this with profile output, https://github.com/dr2chase/gc-lsp-tools . |
Sometimes, not always. BTW, do all the messages at every call sites of the same inlined function are the same?
Like:
|
Again, if this is important to you, I recommend looking at the -json output. We're very unlikely to add more compiler flags to tweak the output of -m. |
OK. Thanks for letting me know the |
The answer should be false. So got it. |
It looks no changes needed to be made here. So close it. |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What did you do?
What did you expect to see?
Either remove the message for line 31, or output the similar message for line 32.
The former way is recommended, because the current outputs is too much.
What did you see instead?
The text was updated successfully, but these errors were encountered: