cmd/compile: optimize redundant iface->iface type assertions #41174
Labels
Milestone
Comments
Note that |
Hmm. This is subtle detail I missed. We can close this issue (and CL) if this rewrite violates the correctness (it looks like it does). |
It does, although nil checking you could do in a cheaper way than calling |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
See https://go-review.googlesource.com/c/go/+/247478
For the real-world cases see https://github.com/VKCOM/noverify/blob/77ed62ed18e976f619031a5c828ea1f4b49c15ba/src/ir/irutil/clone.go#L219
That code was initially auto-generated, but it has a minor problem: it did
F().(T)
even in cases whereF()
already returnsT
. This is not a big problem, but since this optimization is so simple to implement in the compiler, maybe we can do it?What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Compile this program:
What did you expect to see?
Both
example1
andexample2
compiled to the same (efficient) code without type assertions.What did you see instead?
example1
produces the type assertionCALL runtime.assertI2I(SB)
(and a lot of code around it, as expected).The text was updated successfully, but these errors were encountered: