cmd/compile: non-symmetric inline cost when using named vs non-named returns #38419
Comments
Yes, the inlining cost estimate is not very sophisticated. Explicit declarations count, implicit ones (args+returns) don't. I worry about the more general issue though. The inlining cost model is just an estimate. It's always going to be wrong in some situations, even in otherwise silly ways (e.g. So I guess the question is - where do we draw the line? What constitutes an inlining cost "bug" and what doesn't? Do we really want to fix this one bug, only to have lots of similar bugs dribble in over time? I'm kind of inclined to say "not a bug". Even if we fix this bug, there's no guarantee we won't reweight the inliner next release and break your inlinings anyway. But I'm open to other ideas. |
@randall77 I agree with you, if the inline model is designed to give rough estimates, then this is not a bug but an improvement request. I would also agree on closing this issue if a more generic one is created (if not there yet) for tracking a complete inliner. Else I´m inclined to leave it opened until this specific case is correctly managed.
Thanks for pointing me out this other issue. I will iterate some more time on |
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?
Code: https://play.golang.org/p/bM-akhk0QXG
go build -gcflags "-m=2"
What did you expect to see?
NewTriangleInline
is equivalent toNewTriangleNoInline
, the only difference is that the first uses a named return and the second one doesn´t, therefore I would expect that both have the same inline cost.What did you see instead?
The text was updated successfully, but these errors were encountered: