-
Notifications
You must be signed in to change notification settings - Fork 18k
cmd/compile: remove GOEXPERIMENT=nounified #57410
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
Comments
Change https://go.dev/cl/458624 mentions this issue: |
Change https://go.dev/cl/458623 mentions this issue: |
Change https://go.dev/cl/458617 mentions this issue: |
Change https://go.dev/cl/458622 mentions this issue: |
Change https://go.dev/cl/458619 mentions this issue: |
Change https://go.dev/cl/458618 mentions this issue: |
Change https://go.dev/cl/458575 mentions this issue: |
Change https://go.dev/cl/458620 mentions this issue: |
Change https://go.dev/cl/458616 mentions this issue: |
Change https://go.dev/cl/458621 mentions this issue: |
Change https://go.dev/cl/458615 mentions this issue: |
This code path is unreachable anyway, and it adds new uses of Type.Pkg, which shouldn't be used anymore. Mark Type.Pkg as deprecated while here. Updates #57410. Change-Id: I1eec1c8ed99207d58d0ba0c44822bbad29dc64f3 Reviewed-on: https://go-review.googlesource.com/c/go/+/458575 Reviewed-by: David Chase <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Run-TryBot: Matthew Dempsky <[email protected]> Reviewed-by: Cherry Mui <[email protected]>
This CL removes the GOEXPERIMENT=nounified knob, and any conditional statements that depend on that knob. Further CLs to remove unreachable code follow this one. Updates #57410. Change-Id: I39c147e1a83601c73f8316a001705778fee64a91 Reviewed-on: https://go-review.googlesource.com/c/go/+/458615 Run-TryBot: Matthew Dempsky <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Cherry Mui <[email protected]>
The use of typecheck.Resolve was previously necessary to interoperate with the non-unified frontend, because it hooked into iimport. It's no longer necessary with unified IR, where we can just lookup the ".inittask" symbol and access Def directly. Updates #57410. Change-Id: I73bdfd53f65988ececd2b777743cd8b591a6db48 Reviewed-on: https://go-review.googlesource.com/c/go/+/458616 Auto-Submit: Matthew Dempsky <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Keith Randall <[email protected]> Run-TryBot: Matthew Dempsky <[email protected]> Reviewed-by: Keith Randall <[email protected]>
This flag forced the compiler to eagerly type check all available inline function bodies, which presumably was useful in the early days of implementing inlining support. However, it shouldn't have any significance with the unified frontend, since the same code paths are used for constructing normal function bodies as for inlining. Updates #57410. Change-Id: I6842cf86bcd0fbf22ac336f2fc0b7b8fe14bccca Reviewed-on: https://go-review.googlesource.com/c/go/+/458617 Reviewed-by: Keith Randall <[email protected]> Run-TryBot: Matthew Dempsky <[email protected]> Reviewed-by: Keith Randall <[email protected]> Auto-Submit: Matthew Dempsky <[email protected]> TryBot-Result: Gopher Robot <[email protected]>
Now that GOEXPERIMENT=nounified is removed, we can assume InlineCall and HaveInlineBody will always be overridden with the unified frontend's implementations. Similarly, we can assume expandDecl will never be called. This CL changes the code paths into Fatalfs, so subsequent CLs can remove all the unreachable code. Updates #57410. Change-Id: I2a0c3edb32916c30dd63c4dce4f1bd6f18e07468 Reviewed-on: https://go-review.googlesource.com/c/go/+/458618 Auto-Submit: Matthew Dempsky <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Keith Randall <[email protected]> Run-TryBot: Matthew Dempsky <[email protected]> Reviewed-by: Keith Randall <[email protected]>
In the types1 universe under the unified frontend, we never need to worry about type parameter constraints, so we only see pure interfaces. However, we might still see interfaces that contain union types, because of interfaces like "interface{ any | int }" (equivalent to just "any"). We can handle these without needing to actually represent type unions within types1 by simply mapping any union to "any". Updates #57410. Change-Id: I5e4efcf0339edbb01f4035c54fb6fb1f9ddc0c65 Reviewed-on: https://go-review.googlesource.com/c/go/+/458619 Run-TryBot: Matthew Dempsky <[email protected]> Reviewed-by: Keith Randall <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Keith Randall <[email protected]>
This CL removes most of the code specific to the nounified frontend. To simplify review, it's a strict remove-only CL. Updates #57410. Change-Id: Ic3196570aa4286618c1d5e7fd0d0e6601a18195b Reviewed-on: https://go-review.googlesource.com/c/go/+/458620 Run-TryBot: Matthew Dempsky <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Auto-Submit: Matthew Dempsky <[email protected]> Reviewed-by: Keith Randall <[email protected]> Reviewed-by: Keith Randall <[email protected]>
These were used by the nounified frontend for representing uninstantiated generic types; however, the unified frontend only needs types1 to represent instantiated types. Updates #57410. Change-Id: Iac417fbf2b86f4e08bd7fdd26ae8ed17395ce833 Reviewed-on: https://go-review.googlesource.com/c/go/+/458621 Run-TryBot: Matthew Dempsky <[email protected]> Reviewed-by: Keith Randall <[email protected]> Reviewed-by: Keith Randall <[email protected]> TryBot-Result: Gopher Robot <[email protected]>
This CL removes a handful of features that were only needed for the pre-unified frontends. In particular, Type.Pkg was a hack for iexport so that go/types.Var.Pkg could be precisely populated for struct fields and signature parameters by gcimporter, but it's no longer necessary with the unified export data format because we now write export data directly from types2-supplied type descriptors. Several other features (e.g., OrigType, implicit interfaces, type parameters on signatures) are no longer relevant to the unified frontend, because it only uses types1 to represent instantiated generic types. Updates #57410. Change-Id: I84fd1da5e0b65d2ab91d244a7bb593821ee916e7 Reviewed-on: https://go-review.googlesource.com/c/go/+/458622 Reviewed-by: Keith Randall <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Run-TryBot: Matthew Dempsky <[email protected]> Reviewed-by: Keith Randall <[email protected]>
Change https://go.dev/cl/463998 mentions this issue: |
Change https://go.dev/cl/463997 mentions this issue: |
Updates #57410 Change-Id: I9be38e20c6b83d14f7785049a66de77ac7ecdf15 Reviewed-on: https://go-review.googlesource.com/c/go/+/463997 Run-TryBot: Cuong Manh Le <[email protected]> Reviewed-by: Keith Randall <[email protected]> Auto-Submit: Cuong Manh Le <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Matthew Dempsky <[email protected]>
Updates #57410 Change-Id: Ibe1f5523a4635d2b844b9a5db94514e07eb0bc0f Reviewed-on: https://go-review.googlesource.com/c/go/+/463998 Reviewed-by: Keith Randall <[email protected]> Auto-Submit: Cuong Manh Le <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Run-TryBot: Cuong Manh Le <[email protected]> Reviewed-by: Matthew Dempsky <[email protected]>
FYI, we're seeing regressions on ARM builds in go1.20 that bisected to 833367e where the unified experiment was enabled by default (#58425 (comment)) Should the experiment remain until we're confident regressions in the unified build on go1.20 are resolved? If I understand correctly, go1.20 (released 10 days ago) is the first time the unified build was used by default, which means it has had very little time to be adopted |
The nounified frontend used in the 1.18 and 1.19 releases was the first to support generics, but we've experienced a lot of subtle correctness issues with it, which became untenable to fix. E.g., for 1.18, we decided to stop backporting generics fixes, because every time we attempted to fix one issue, we introduced at least one new one. The unified frontend has been in use internally within Google for months. The compiler team decided as a whole to commit to the unified frontend for 1.20 and forward. We talked about whether it made sense to keep the code around longer, but we have a lot of other work planned for 1.21 (e.g., overhauling how inlining works, for better PGO support), which was hindered by the technical burden of maintaining two frontends. We did expect hiccups in the transition though, which is why GOEXPERIMENT=nounified is still available and supported in the 1.20 release branch. And admittedly #58339 is a bit embarrassing, but that will be fixed in 1.20.1. In 1.20, it can be worked around with Thanks for your patience while we address the reported regressions. |
Closing this issue because the nounified frontend has been removed at tip. There's still more cleanup work to do, but that can happen without a tracking issue. |
@liggitt I don't think the "relocation truncated" error is particularly related to the unified frontend. That's just the change that happened to reorder functions such that the branch distance was exceeded. When I compile your repro from #58425 successfully with 1.20, it generates a binary whose text size is 66MB, when the branch (call) distance on arm32 is +/- 32 MB. I'm kind of surprised it ever worked before - you probably just got lucky using the old frontend. Not that there couldn't be reasons why the unified frontend exacerbates the situation, but once your program is >32MB of text it's just a matter of time before some benign change causes relocation errors. (Until #58425 is fixed, probably by adding trampolines or something.) |
interesting... Kubernetes arm builds have been working since #17028, so 6+ years of luck was... pretty lucky |
Updates golang#57410 Change-Id: I9be38e20c6b83d14f7785049a66de77ac7ecdf15 Reviewed-on: https://go-review.googlesource.com/c/go/+/463997 Run-TryBot: Cuong Manh Le <[email protected]> Reviewed-by: Keith Randall <[email protected]> Auto-Submit: Cuong Manh Le <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Matthew Dempsky <[email protected]>
Updates golang#57410 Change-Id: Ibe1f5523a4635d2b844b9a5db94514e07eb0bc0f Reviewed-on: https://go-review.googlesource.com/c/go/+/463998 Reviewed-by: Keith Randall <[email protected]> Auto-Submit: Cuong Manh Le <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Run-TryBot: Cuong Manh Le <[email protected]> Reviewed-by: Matthew Dempsky <[email protected]>
Change https://go.dev/cl/493995 mentions this issue: |
Tracking issue for removing GOEXPERIMENT=nounified for Go 1.21.
The text was updated successfully, but these errors were encountered: