Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upcmd/compile: many new no-ops as a result of mid-stack inlining #29571
Comments
This comment has been minimized.
This comment has been minimized.
There's generally one nop per inlining that the compiler does. These are the InlMark opcodes that represent the callsite of an inlined function. They are required to get stack tracebacks correct when mid-stack inlining is enabled. There's two ways to reduce them, both of which I was going to leave for 1.13 (but let me know if this is painful enough to try to get in for 1.12):
I checked one of the cases you reported and the number of nops looks correct. For |
This comment has been minimized.
This comment has been minimized.
For now it's only painful to me because of how it looks. I will do some testing to see if it affects performance in any meaningful way. Otherwise your fixes for 1.13 sound OK.
|
This comment has been minimized.
This comment has been minimized.
Not always. |
This comment has been minimized.
This comment has been minimized.
I'm OK with leaving this as is for 1.12 if there will be improvements in 1.13. |
This comment has been minimized.
This comment has been minimized.
Keeping this issue is fine. |
This comment has been minimized.
This comment has been minimized.
Change https://golang.org/cl/158021 mentions this issue: |
Instead of always inserting a nop to use as the target of an inline mark, see if we can instead find an instruction we're issuing anyway with the correct line number, and use that instruction. That way, we don't need to issue a nop. Makes cmd/go 0.3% smaller. Update #29571 Change-Id: If6cfc93ab3352ec2c6e0878f8074a3bf0786b2f8 Reviewed-on: https://go-review.googlesource.com/c/go/+/158021 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
This comment has been minimized.
This comment has been minimized.
Change https://golang.org/cl/170445 mentions this issue: |
If no other instruction mentions an inline mark, we can get rid of it. This normally happens when the inlined function is empty, or when all of its code is folded into other instructions. Also use consistent statement-ness for inline mark positions, so that more of them can be removed in favor of existing instructions. Update #29571 Fixes #31172 Change-Id: I71f84d355101f37a27960d9e8528f42f92767496 Reviewed-on: https://go-review.googlesource.com/c/go/+/170445 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
This comment has been minimized.
This comment has been minimized.
I don't plan on doing anything more on this for 1.13. Any further work here I think involves either associating multiple source lines with an instruction, and/or with encoding that fact in dwarf. |
What version of Go are you using (
go version
)?latest
Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env
)?ppc64le and ppc64
What did you do?
I was inspecting code for another reason and I saw a lot of new no-ops in unexpected places. For example in runtime.cgoCheckTypedBlock:
What did you expect to see?
I should only see no-ops where they are expected.
What did you see instead?
Lots of no-ops in unexpected places. In the test for bytes there are almost 9000 extra no-ops with this commit.
I have not found runtime breakage because of this but performance could be affected depending where the unnecessary no-ops occur.