You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 -gcflags=all=-d=inlstaticinit=0.
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.)
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.
interesting... Kubernetes arm builds have been working since #17028, so 6+ years of luck was... pretty lucky
Activity
gopherbot commentedon Dec 20, 2022
Change https://go.dev/cl/458624 mentions this issue:
cmd/compile/internal/types: remove more unused features
gopherbot commentedon Dec 20, 2022
Change https://go.dev/cl/458623 mentions this issue:
cmd/compile/internal/types: remove NewSignature's tparams parameter
gopherbot commentedon Dec 20, 2022
Change https://go.dev/cl/458617 mentions this issue:
cmd/compile: remove -d=typecheckinl flag
gopherbot commentedon Dec 20, 2022
Change https://go.dev/cl/458622 mentions this issue:
cmd/compile/internal/types: remove Type.Pkg
gopherbot commentedon Dec 20, 2022
Change https://go.dev/cl/458619 mentions this issue:
cmd/compile/internal/noder: stop creating TUNION types
gopherbot commentedon Dec 20, 2022
Change https://go.dev/cl/458618 mentions this issue:
cmd/compile: change some unreachable code paths into Fatalf
gopherbot commentedon Dec 20, 2022
Change https://go.dev/cl/458575 mentions this issue:
cmd/compile: revert package typecheck part of CL 422914
gopherbot commentedon Dec 20, 2022
Change https://go.dev/cl/458620 mentions this issue:
cmd/compile: remove GOEXPERIMENT=nounified frontend
gopherbot commentedon Dec 20, 2022
Change https://go.dev/cl/458616 mentions this issue:
cmd/compile/internal/pkginit: remove dependency on typecheck.Resolve
gopherbot commentedon Dec 20, 2022
Change https://go.dev/cl/458621 mentions this issue:
cmd/compile/internal/types: remove TTYPEPARAM and TUNION types
gopherbot commentedon Dec 20, 2022
Change https://go.dev/cl/458615 mentions this issue:
cmd: remove GOEXPERIMENT=nounified knob
14 remaining items
test: enable inlining tests for functions with local type
liggitt commentedon Feb 10, 2023
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
mdempsky commentedon Feb 10, 2023
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
-gcflags=all=-d=inlstaticinit=0
.Thanks for your patience while we address the reported regressions.
mdempsky commentedon Feb 10, 2023
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.
randall77 commentedon Feb 10, 2023
@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.)
liggitt commentedon Feb 10, 2023
interesting... Kubernetes arm builds have been working since #17028, so 6+ years of luck was... pretty lucky
cmd/compile: cleanup atomic.Pointer[T] inline test
test: enable inlining tests for functions with local type
gopherbot commentedon May 9, 2023
Change https://go.dev/cl/493995 mentions this issue:
cmd/compile: update README.md for unified IR