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: don't generate newobject call for 0-sized types #29446
Comments
Change https://golang.org/cl/155840 mentions this issue: |
What's the size impact on a large Go binary like |
@mvdan, for |
Huh, I'd expect this to happen often and to shave off at least a few kilobytes from most large binaries. Did you check if the compiled binary changes at all? |
|
I have a handful of newobject changes, including this one, in my tree. I didn’t mail this one because it basically never triggers. Others include specializing newobject in various ways. I didn’t mail the rest because I think we should move newobject to SSA construction world first. |
To be clear, I’m game to see the optimization go in. But I do think we should move that code before it gets too complex. I peeked at the other things I was playing with. One was a specialized newstring, which doesn’t need a typ arg. (Use SoleComponent for best effect.) Another was for newobject for SSA-able types containing no pointers. In that case you can allocate without zeroing and then zero on the caller side, in the hope that that zeroing will be optimized away in favor of later writes. Just in case you wanted to see either of those through. :) One minor complication is that newobject is treated as special throughout SSA world. |
I'm a bit confused. I would imagine that statements like Also, if this optimization basically never triggers, how come |
It does trigger for empty slices as well as offtopic2019 is coming 🎄 :) |
https://go-review.googlesource.com/c/go/+/167957 moves newobject handling to ssa conversion. |
Sometimes compiler generates a
runtime.newobject(t)
call wheret
size is statically known to be 0.That call would return
&runtime.zerobase
:go/src/runtime/malloc.go
Lines 809 to 816 in c043fc4
While
new(zeroSizedType)
case is not very interesting, empty slice literals also emit a call tonewobject
(see below).Instead of generating
runtime.newobject
call, compiler could insert the returned expression itself.Impact on performance can be measured by this simple benchmark:
The impact on the code size is also positive.
Old generated code for
newSlice
(amd64/linux):New generated code for
newSlice
:The important part is that there is no more call to
runtime.newobject(SB)
.I'll send a CL with that optimization applied.
The text was updated successfully, but these errors were encountered: