aboutsummaryrefslogtreecommitdiff
path: root/src/cmd/compile/internal/noder/unified.go
AgeCommit message (Collapse)Author
5 dayscmd/compile/internal/noder: revert to UIR V3Mark Freeman
Upgrading to V4 early doesn't seem to make much sense while we refine things. Any change to encoding would require another version gate and propagation; this gets tedious fast. Instead, let's keep on V3 and test locally with V4. We can commit skipped tests as we refine and then turn them all on *with* the bump up to V4. Change-Id: I571715e5da75095612f68b224c82e6d22ad3ab25 Reviewed-on: https://go-review.googlesource.com/c/go/+/765444 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Alan Donovan <adonovan@google.com> Auto-Submit: Mark Freeman <markfreeman@google.com>
8 dayscmd/compile/internal/noder: use UIR V4Mark Freeman
Change-Id: If8acdbf0e48ed600c4ba3f762802879335df1465 Reviewed-on: https://go-review.googlesource.com/c/go/+/761980 Reviewed-by: Robert Griesemer <gri@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-03-19cmd/compile: enable promoted field selectors as keys in struct literalsRobert Griesemer
Switch the generated UIR version from V2 to V3. Adjust cmd/compile/internal/types to accept promoted field selectors in composite literals. Fixes #9859. Change-Id: Ie314e28567cfa6cf4c9e962a07b32dd05b06bf5e Reviewed-on: https://go-review.googlesource.com/c/go/+/755740 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Mark Freeman <markfreeman@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2026-03-16cmd/compile/internal/noder: factor out common UIR versionRobert Griesemer
Ensure that the writers and readers use the same UIR version by defining the currently used version in one place rather than setting it in two places which might diverge. Change-Id: Iae139e08c3c01e553250ba6f4f171132b06eb8c9 Reviewed-on: https://go-review.googlesource.com/c/go/+/754662 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-by: Mark Freeman <markfreeman@google.com> Auto-Submit: Robert Griesemer <gri@google.com>
2025-08-12all: delete aliastypeparams GOEXPERIMENTCherry Mui
Always enable aliastypeparams and remove the GOEXPERIMENT. Change-Id: Ic38fe25b0bba312a7f83f7bb94b57ab75ce0f0c3 Reviewed-on: https://go-review.googlesource.com/c/go/+/691956 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Mark Freeman <markfreeman@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2025-05-12internal/pkgbits: rename Reloc* to Section*Mark Freeman
This is a basic refactoring. This enumeration refers primarily to the different sections of a UIR file, so this naming is a bit more direct. Change-Id: Ib70ab054e97effaabc035450d246ae4354da8075 Reviewed-on: https://go-review.googlesource.com/c/go/+/671935 Reviewed-by: Robert Griesemer <gri@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Mark Freeman <mark@golang.org>
2024-09-05cmd/compile: use slices.{Sort,SortFunc}Cuong Manh Le
Now that we're bootstrapping from a toolchain that has the slices package. Updates #64751 Change-Id: I2e63d95577d058670d3dc75bd45d6e050c6f0e25 Reviewed-on: https://go-review.googlesource.com/c/go/+/610601 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-08-28cmd/compile/internal/noder: write V2 bitstream aliastypeparams=1Tim King
Enables V2 unified IR bitstreams when GOEXPERIMENT aliastypeparams are enabled. Allows pkgbits.NewPkgEncoder to set the output version. Reenables support for writing V0 streams. Updates #68778 Updates #68526 Change-Id: I590c494d81ab7db148232ceaba52229068d1e986 Reviewed-on: https://go-review.googlesource.com/c/go/+/608595 Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2024-08-20cmd/compile: deprecate has init and derived func instanceTim King
Removes 'has init' and 'derived func instance' fields from unified IR starting with V2. This should be a no-op at the moment as the writer is hardwired to create V1. Updates #68778 Change-Id: I84a606cbc27cd6d8bd6eee2aff44c89f4aa7413c Reviewed-on: https://go-review.googlesource.com/c/go/+/606035 Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-08-20cmd/compile/internal/noder: reduce clutter a bit (cosmetic changes)Robert Griesemer
- introduce index alias - inline the two short tables in stmt.go (removes a TODO) - move assert out of stencil.go and remove that file (we can always re-introduce it) Also, replace two if's with a simpler switch. Change-Id: I25c3104164574999dd9826dee6166dd8a8488908 Reviewed-on: https://go-review.googlesource.com/c/go/+/607236 Reviewed-by: Robert Griesemer <gri@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Tim King <taking@google.com>
2024-07-31cmd/compile: add comment for the context on mismatch import pathCuong Manh Le
Follow up suggestion in CL 596396. Updates #54542 Change-Id: I47bf66684bb8397dc1cfbc4479e2279e59a40cfb Reviewed-on: https://go-review.googlesource.com/c/go/+/596515 Reviewed-by: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2024-07-03cmd/compile: emit error message on mismatch import pathCuong Manh Le
Fixes #54542 Change-Id: I16cfb84fc54892923106d0a6f0b3ba810886d077 Reviewed-on: https://go-review.googlesource.com/c/go/+/596396 Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
2024-06-12cmd/compile/internal: add a PGO devirt post-lookup cleanup hookThan McIntosh
The PGO-based devirtualization helper pgoir.addIndirectEdges makes a series of calls into the unified IR reader to import functions that would not normally be imported but may be the target of a hot indirect call from the current package. This importing primarily targets at non-generic functions and methods, but as part of the process we can encounter types that have methods (including generic methods) whose bodies need to be read in. When the reader encounters an inlinable func of this sort, it may (depending on the context) decide not to read the body right away, but instead adds the func to a list ("todoBodies") to be read in later on in a more convenient context. In the bug in question, a hot method lookup takes place in pgoir.addIndirectEdges, and as part of the import process we wind up with a type T with method M that is in this partially created state, and in addition T gets added to the unified IR's list of types that may need method wrappers. During wrapper generation we create a new wrapper "(*T).M" whose body has a call to "T.M", then farther on down the pike during escape analysis we try to analyze the two functions; this causes a crash due to "T.M" being in partially constructed state. As a fix, add a new "PostLookupCleanup" hook (in the unified IR reader) that pgoir.addIndirectEdges can invoke that takes care of reading in the bodies of any functions that have been added to the "todoBodies" list. [Note: creating a test case for this problem is proving to be very tricky; a new test will be added in a subsequent patch]. Fixes #67746. Change-Id: Ibc47ee79e08a55421728d35341df80a865231cff Reviewed-on: https://go-review.googlesource.com/c/go/+/591075 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-05-21cmd/compile: for rangefunc, add checks and tests, fix panic interactionsDavid Chase
Modify rangefunc #next protocol to make it more robust Extra-terrible nests of rangefunc iterators caused the prior implementation to misbehave non-locally (in outer loops). Add more rangefunc exit flag tests, parallel and tricky This tests the assertion that a rangefunc iterator running in parallel can trigger the race detector if any of the parallel goroutines attempts an early exit. It also verifies that if everything else is carefully written, that it does NOT trigger the race detector if all the parts run time completion. Another test tries to rerun a yield function within a loop, so that any per-line shared checking would be fooled. Added all the use-of-body/yield-function checking. These checks handle pathological cases that would cause rangefunc for loops to behave in surprising ways (compared to "regular" for loops). For example, a rangefunc iterator might defer-recover a panic thrown in the syntactic body of a loop; this notices the fault and panics with an explanation Modified closure naming to ID rangefunc bodies Add a "-range<N>" suffix to the name of any closure generated for a rangefunc loop body, as provided in Alessandro Arzilli's CL (which is merged into this one). Fix return values for panicky range functions This removes the delayed implementation of "return x" by ensuring that return values (in rangefunc-return-containing functions) always have names and translating the "return x" into "#rv1 = x" where #rv1 is the synthesized name of the first result. Updates #61405. Change-Id: I933299ecce04ceabcf1c0c2de8e610b2ecd1cfd8 Reviewed-on: https://go-review.googlesource.com/c/go/+/584596 Reviewed-by: Matthew Dempsky <mdempsky@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Tim King <taking@google.com>
2024-04-24cmd/compile: bail PGO method lookup on interface typesMichael Pratt
Interface types don't have concrete method implementations, so it does not make sense to attempt a lookup. An interface method would not normally appear in a PGO profile as it has no symbol in the final binary. However it can appear if the method was concrete when the profile was collected and it has since been refactored to an interface method in the code being compiled. The guards here (OTYPE, !Alias, !IsInterface) now match noder.linker.relocObj, which does a similar iteration of all methods. Fixes #67016. Change-Id: I858c58929c890ac0b2019fbd7c99f683ab63f8bb Reviewed-on: https://go-review.googlesource.com/c/go/+/581436 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2024-04-04all: fix some commentscui fliter
Change-Id: I0ee85161846c13d938213ef04d3a34f690a93e48 Reviewed-on: https://go-review.googlesource.com/c/go/+/553435 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@golang.org>
2024-03-27cmd/compile: rename cmd/compile/internal/pgo to cmd/compile/internal/pgoirMichael Pratt
This helps reduce confusion with cmd/internal/pgo, which performs compilation-independent analysis. pgoir associates that data with the IR from the current package compilation. For #58102. Change-Id: I9ef1c8bc41db466d3340f41f6d071b95c09566de Reviewed-on: https://go-review.googlesource.com/c/go/+/569338 Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-02-09cmd/compile: fail noder.LookupFunc gracefully if function genericMichael Pratt
PGO uses noder.LookupFunc to look for devirtualization targets in export data. LookupFunc does not support type-parameterized functions, and will currently fail the build when attempting to lookup a type-parameterized function because objIdx is passed the wrong number of type arguments. This doesn't usually come up, as a PGO profile will report a generic function with a symbol name like Func[.go.shape.foo]. In export data, this is just Func, so when we do LookupFunc("Func[.go.shape.foo]") lookup simply fails because the name doesn't exist. However, if Func is not generic when the profile is collected, but the source has since changed to make Func generic, then LookupFunc("Func") will find the object successfully, only to fail the build because we failed to provide type arguments. Handle this with a objIdxMayFail, which allows graceful failure if the object requires type arguments. Bumping the language version to 1.21 in pgo_devirtualize_test.go is required for type inference of the uses of mult.MultFn in cmd/compile/internal/test/testdata/pgo/devirtualize/devirt_test.go. Fixes #65615. Change-Id: I84d9344840b851182f5321b8f7a29a591221b29f Reviewed-on: https://go-review.googlesource.com/c/go/+/562737 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2023-11-20cmd/compile: interleave devirtualization and inliningMatthew Dempsky
This CL interleaves devirtualization and inlining, so that devirtualized calls can be inlined. Fixes #52193. Change-Id: I681e7c55bdb90ebf6df315d334e7a58f05110d9c Reviewed-on: https://go-review.googlesource.com/c/go/+/528321 Auto-Submit: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Bypass: Matthew Dempsky <mdempsky@google.com>
2023-11-13cmd/compile: support lookup of functions from export dataMichael Pratt
As of CL 539699, PGO-based devirtualization supports devirtualization of function values in addition to interface method calls. As with CL 497175, we need to explicitly look up functions from export data that may not be imported already. Symbol naming is ambiguous (`foo.Bar.func1` could be a closure or a method), so we simply attempt to do both types of lookup. That said, closures are defined in export data only as OCLOSURE nodes in the enclosing function, which this CL does not yet attempt to expand. For #61577. Change-Id: Ic7205b046218a4dfb8c4162ece3620ed1c3cb40a Reviewed-on: https://go-review.googlesource.com/c/go/+/540258 Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2023-10-13cmd/compile: lookup indirect callees from export data for devirtualizationMichael Pratt
Today, the PGO IR graph only contains entries for ir.Func loaded into the package. This can include functions from transitive dependencies, but only if they happen to be referenced by something in the current package. If they are not referenced, noder never bothers to load them. This leads to a deficiency in PGO devirtualization: some callee methods are available in transitive dependencies but do not devirtualize because they happen to not get loaded from export data. Resolve this by adding an explicit lookup from export data of callees mentioned in the profile. I have chosen to do this during loading of the profile for simplicity: the PGO IR graph always contains all of the functions we might need. That said, it isn't strictly necessary. PGO devirtualization could do the lookup lazily if it decides it actually needs a method. This saves work at the expense of a bit more complexity, but I've chosen the simpler approach for now as I measured the cost of this as significantly less than the rest of PGO loading. For #61577. Change-Id: Ieafb2a549510587027270ee6b4c3aefd149a901f Reviewed-on: https://go-review.googlesource.com/c/go/+/497175 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2023-08-25cmd/compile: remove ErrorfVers and base.Flag.Lang hackMatthew Dempsky
ErrorfVers used to be used by typecheck to report when new language functionality was used, but the -lang flag (from go.mod) was set to an older version. However, all of the callers have been since removed, now that this is handled by types2. And for the same reason, we can stop changing base.Flag.Lang. This was previously a workaround so that the unified frontend could generate arbitrary IR without upsetting typecheck, at a time when typecheck was itself a real frontend. Now it's just a glorified desugaring pass. Change-Id: I1c0316dbfe2e08ba089acd50fdfe20b17176be25 Reviewed-on: https://go-review.googlesource.com/c/go/+/522877 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Auto-Submit: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Keith Randall <khr@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-08-22cmd/compile: redo IsRuntimePkg/IsReflectPkg predicateAustin Clements
Currently, the types package has IsRuntimePkg and IsReflectPkg predicates for testing if a Pkg is the runtime or reflect packages. IsRuntimePkg returns "true" for any "CompilingRuntime" package, which includes all of the packages imported by the runtime. This isn't inherently wrong, except that all but one use of it is of the form "is this Sym a specific runtime.X symbol?" for which we clearly only want the package "runtime" itself. IsRuntimePkg was introduced (as isRuntime) in CL 37538 as part of separating the real runtime package from the compiler built-in fake runtime package. As of that CL, the "runtime" package couldn't import any other packages, so this was adequate at the time. We could fix this by just changing the implementation of IsRuntimePkg, but the meaning of this API is clearly somewhat ambiguous. Instead, we replace it with a new RuntimeSymName function that returns the name of a symbol if it's in package "runtime", or "" if not. This is what every call site (except one) actually wants, which lets us simplify the callers, and also more clearly addresses the ambiguity between package "runtime" and the general concept of a runtime package. IsReflectPkg doesn't have the same issue of ambiguity, but it parallels IsRuntimePkg and is used in the same way, so we replace it with a new ReflectSymName for consistency. Change-Id: If3a81d7d11732a9ab2cac9488d17508415cfb597 Reviewed-on: https://go-review.googlesource.com/c/go/+/521696 Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-08-17cmd/compile: always construct typechecked closuresMatthew Dempsky
This CL extends ir.NewClosureFunc to take the signature type argument, and to handle naming the closure and adding it to typecheck.Target. It also removes the code for typechecking OCLOSURE and ODCLFUNC nodes, by having them always constructed as typechecked. ODCLFUNC node construction will be further simplified in the followup CL. Change-Id: Iabde4557d33051ee470a3bc4fd49599490024cba Reviewed-on: https://go-review.googlesource.com/c/go/+/520337 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2023-08-17cmd/compile/internal/ir: add typ parameter to NewNameAtMatthew Dempsky
Start making progress towards constructing IR with proper types. Change-Id: Iad32c1cf60f30ceb8e07c31c8871b115570ac3bd Reviewed-on: https://go-review.googlesource.com/c/go/+/520263 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2023-08-11cmd/compile: cleanup ir.PackageMatthew Dempsky
Decls used to contain initializer statement for package-level variables, but now it only contains ir.Funcs. So we might as well rename it to Funcs and tighten its type to []*ir.Func. Similarly, Externs always contains *ir.Names, so its type can be constrained too. Change-Id: I85b833e2f83d9d3559ab0ef8ab5d8324f4bc37b6 Reviewed-on: https://go-review.googlesource.com/c/go/+/517855 Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Auto-Submit: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-08-09cmd/compile: mark instantiated functions from package runtime as noraceCuong Manh Le
Fixes #60439 Change-Id: I09fcd2d3deb7f80ed012a769fdb6f53b09c0290b Reviewed-on: https://go-review.googlesource.com/c/go/+/502895 Reviewed-by: Michael Knyszek <mknyszek@google.com> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2023-03-22cmd/compile: re-compile instantiated generic methods in linkshared modeCuong Manh Le
For G[T] that was seen and compiled in imported package, it is not added to typecheck.Target.Decls, prevent wasting compile time re-creating DUPOKS symbols. However, the linker do not support a type symbol referencing a method symbol across DSO boundary. That causes unreachable sym error when building under -linkshared mode. To fix it, always re-compile generic methods in linkshared mode. Fixes #58966 Change-Id: I894b417cfe8234ae1fe809cc975889345df22cef Reviewed-on: https://go-review.googlesource.com/c/go/+/477375 Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-01-27cmd/compile/internal/noder: remove unused noding codeMatthew Dempsky
This CL simplifies and removes some old noding code, which isn't necessary any more. Most notably, we no longer need separate posMaps for each noder, because noders are only used for parsing now. Before we started using types2, noders were also responsible for constructed (untyped) IR, so posMaps were necessary to translate syntax.Pos into src.XPos. Change-Id: Ic761abcd727f5ecefc71b611635a0f5b088c941f Reviewed-on: https://go-review.googlesource.com/c/go/+/463738 Auto-Submit: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Keith Randall <khr@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2022-11-15cmd/compile: add testing-flag guard to package-is-collected assertDavid Chase
On advice of the department of garbage collection, forcing a garbage collection generally does not improve performance. However, this-data-is-now-unreachable is a good property to be able to test, and that requires finalizers and a forced GC. So, to save build time, this test was removed from the compiler itself, but to verify the property, it was added to the fma_test (and the end-to-end dependence on the flag was tested with an inserted failure in testing the test). TODO: also turn on the new -d=gccheck=1 debug flag on the ssacheck builder. Benchmarking reveals that it is profitable to avoid this GC, with about 1.5% reduction in both user and wall time. (48 p) https://perf.golang.org/search?q=upload:20221103.3 (12 p) https://perf.golang.org/search?q=upload:20221103.5 Change-Id: I4c4816d619735838a32388acf0cc5eb1cd5f0db5 Reviewed-on: https://go-review.googlesource.com/c/go/+/447359 Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2022-11-08cmd/compile: fix transitive inlining of generic functionsMatthew Dempsky
If an imported, non-generic function F transitively calls a generic function G[T], we may need to call CanInline on G[T]. While here, we can also take advantage of the fact that we know G[T] was already seen and compiled in an imported package, so we don't need to call InlineCalls or add it to typecheck.Target.Decls. This saves us from wasting compile time re-creating DUPOK symbols that we know already exist in the imported package's link objects. Fixes #56280. Change-Id: I3336786bee01616ee9f2b18908738e4ca41c8102 Reviewed-on: https://go-review.googlesource.com/c/go/+/443535 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Auto-Submit: Matthew Dempsky <mdempsky@google.com>
2022-08-31cmd/compile: use HaveInlineBody for unified IRMatthew Dempsky
In go.dev/cl/419674 I added a mechanism to the inliner to allow inlining to fail gracefully when a function body is missing, but I missed we already have a mechanism for that: typecheck.HaveInlineBody. This CL makes it overridable so that unified IR can plug in its appropriate logic, like it does with the logic for building the ir.InlinedCallExpr node. While here, rename inline.NewInline to inline.InlineCall, because the name "NewInline" is now a misnomer since we initialize it to oldInline (now named oldInlineCall). Change-Id: I4e65618d3725919f69e6f43cf409699d20fb797c Reviewed-on: https://go-review.googlesource.com/c/go/+/427234 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> Auto-Submit: Matthew Dempsky <mdempsky@google.com>
2022-08-31cmd/compile/internal/noder: reuse package scope's namesshaoliming
Change-Id: I2cc62efb7bb3b47f1ee3ed0bb77e35c47e2df9a1 GitHub-Last-Rev: 106cb494de6fb08302018bff55944ee120ef4545 GitHub-Pull-Request: golang/go#54718 Reviewed-on: https://go-review.googlesource.com/c/go/+/426297 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2022-08-18cmd/compile/internal/noder: shape-based stenciling for unified IRMatthew Dempsky
This CL switches unified IR to use shape-based stenciling with runtime dictionaries, like the existing non-unified frontend. Specifically, when instantiating generic functions and types `X[T]`, we now also instantiated shaped variants `X[shapify(T)]` that can be shared by `T`'s with common underlying types. For example, for generic function `F`, `F[int](args...)` will be rewritten to `F[go.shape.int](&.dict.F[int], args...)`. For generic type `T` with method `M` and value `t` of type `T[int]`, `t.M(args...)` will be rewritten to `T[go.shape.int].M(t, &.dict.T[int], args...)`. Two notable distinctions from the non-unified frontend: 1. For simplicity, currently shaping is limited to simply converting type arguments to their underlying type. Subsequent CLs will implement more aggressive shaping. 2. For generic types, a single dictionary is generated to be shared by all methods, rather than separate dictionaries for each method. I originally went with this design because I have an idea of changing interface calls to pass the itab pointer via the closure register (which should have zero overhead), and then the interface wrappers for generic methods could use the *runtime.itab to find the runtime dictionary that corresponds to the dynamic type. This would allow emitting fewer method wrappers. However, this choice does have the consequence that currently even if a method is unused and its code is pruned by the linker, it may have produced runtime dictionary entries that need to be kept alive anyway. I'm open to changing this to generate per-method dictionaries, though this would require changing the unified IR export data format; so it would be best to make this decision before Go 1.20. The other option is making the linker smarter about pruning unneeded dictionary entries, like how it already prunes itab entries. For example, the runtime dictionary for `T[int]` could have a `R_DICTTYPE` meta-relocation against symbol `.dicttype.T[go.shape.int]` that declares it's a dictionary associated with that type; and then each method on `T[go.shape.T]` could have `R_DICTUSE` meta-relocations against `.dicttype.T[go.shape.T]+offset` indicating which fields within dictionaries of that type need to be preserved. Change-Id: I369580b1d93d19640a4b5ecada4f6231adcce3fd Reviewed-on: https://go-review.googlesource.com/c/go/+/421821 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-08-04all: clean up TODO after fixing issue 44505hopehook
For #44505 Change-Id: I89220be02372b5340cb987bf2ac870a9346a8c8f Reviewed-on: https://go-review.googlesource.com/c/go/+/421079 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2022-08-03[dev.unified] cmd/compile: start using runtime dictionariesMatthew Dempsky
This CL switches unified IR to start using runtime dictionaries, rather than pure stenciling. In particular, for each instantiated function `F[T]`, it now: 1. Generates a global variable `F[T]-dict` of type `[N]uintptr`, with all of the `*runtime._type` values needed by `F[T]`. 2. Generates a function `F[T]-shaped`, with an extra `.dict *[N]uintptr` parameter and indexing into that parameter for derived types. (N.B., this function is not yet actually using shape types.) 3. Changes `F[T]` to instead be a wrapper function that calls `F[T]-shaped` passing `&F[T]-dict` as the `.dict` parameter. This is done in one pass to make sure the overall wiring is all working (especially, function literals and inlining). Subsequent CLs will write more information into `F[T]-dict` and update `F[T]-shaped` to use it instead of relying on `T`-derived information itself. Once that's done, `F[T]-shaped` can be changed to `F[shapify(T)]` (e.g., `F[go.shape.int]`) and deduplicated. Change-Id: I0e802a4d9934794e01a6bfc367820af893335155 Reviewed-on: https://go-review.googlesource.com/c/go/+/420416 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: David Chase <drchase@google.com>
2022-07-28[dev.unified] cmd/compile: move "has init" to private metadataMatthew Dempsky
Currently, there's a "has init" bool in the public metadata section, which is only needed by cmd/compile; but because it's in the public metadata section, it's known to the go/types importers too. This CL moves it instead to the new compiler-only private metadata section added in the last CL for the inline bodies index. The existing bool in the public metadata section is left in place, and just always set to false, to avoid breaking the x/tools importer. The next time we bump the export version number, we can remove the bool properly. But no urgency just yet. Change-Id: I380f358652374b5a221f85020a53dc65912ddb29 Reviewed-on: https://go-review.googlesource.com/c/go/+/419676 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: David Chase <drchase@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-07-28[dev.unified] cmd/compile: implement simple inline body pruning heuristicMatthew Dempsky
An important optimization in the existing export data format is the pruning of unreachable inline bodies. That is, when re-exporting transitively imported types, omitting the inline bodies for methods that can't actually be needed due to importing that package. The existing logic (implemented in typecheck/crawler.go) is fairly sophisticated, but also relies on actually expanding inline bodies in the process, which is undesirable. However, including all inline bodies is also prohibitive for testing GOEXPERIMENT=unified against very large Go code bases that impose size limits on build action inputs. As a short-term solution, this CL implements a simple heuristic for GOEXPERIMENT=unified: include the inline bodies for all locally-declared functions/methods, and for any imported functions/methods that were inlined into this package. Change-Id: I686964a0cd9262b77d3d5587f89cfbcfe8b2e521 Reviewed-on: https://go-review.googlesource.com/c/go/+/419675 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2022-06-14[dev.unified] cmd/compile: more Unified IR docs and reviewMatthew Dempsky
This adds more documentation throughout the core Unified IR logic and removes their UNREVIEWED notices. Updates #48194. Change-Id: Iddd30edaee1c6ea8a05a5a7e013480e02be00d29 Reviewed-on: https://go-review.googlesource.com/c/go/+/411917 Auto-Submit: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: David Chase <drchase@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-06-06[dev.unified] cmd/compile: remove package heightCuong Manh Le
After CL 410654, symbols are now sorted by package path, package height is not necessary anymore. Updates #51734 Change-Id: I976edd2e574dda68eb5c76cf95645b9dce051393 Reviewed-on: https://go-review.googlesource.com/c/go/+/410342 Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2022-05-25internal/pkgbits: add Index typeMatthew Dempsky
Element indices are very common in the pkgbits API, so introduce a new defined type to help make that clearer. Change-Id: I8f9493e2335601c740eb403d1fdcd11183122907 Reviewed-on: https://go-review.googlesource.com/c/go/+/407435 Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-05-16cmd/compile: set LocalPkg.Path to -p flagMatthew Dempsky
Since CL 391014, cmd/compile now requires the -p flag to be set the build system. This CL changes it to initialize LocalPkg.Path to the provided path, rather than relying on writing out `"".` into object files and expecting cmd/link to substitute them. However, this actually involved a rather long tail of fixes. Many have already been submitted, but a few notable ones that have to land simultaneously with changing LocalPkg: 1. When compiling package runtime, there are really two "runtime" packages: types.LocalPkg (the source package itself) and ir.Pkgs.Runtime (the compiler's internal representation, for synthetic references). Previously, these ended up creating separate link symbols (`"".xxx` and `runtime.xxx`, respectively), but now they both end up as `runtime.xxx`, which causes lsym collisions (notably inittask and funcsyms). 2. test/codegen tests need to be updated to expect symbols to be named `command-line-arguments.xxx` rather than `"".foo`. 3. The issue20014 test case is sensitive to the sort order of field tracking symbols. In particular, the local package now sorts to its natural place in the list, rather than to the front. Thanks to David Chase for helping track down all of the fixes needed for this CL. Updates #51734. Change-Id: Iba3041cf7ad967d18c6e17922fa06ba11798b565 Reviewed-on: https://go-review.googlesource.com/c/go/+/393715 Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2022-05-13cmd/compile: tidy up noder's unified IR docsDaniel Martí
Hopefully made the wording clearer as I was reading it. Change-Id: I241ce3f2ac7ae77de00dbc969540c09ef0b77496 Reviewed-on: https://go-review.googlesource.com/c/go/+/395394 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: David Chase <drchase@google.com>
2022-05-13cmd/compile/internal/noder: remove unified IR assumptions on LocalPkg.Path == ""Matthew Dempsky
Replace `pkg.Path == ""` check with `pkg == types.LocalPkg`. This is a prep refactoring for CL 393715, which will properly initialize types.LocalPkg. Updates #51734. Change-Id: I7a5428ef1f422de396762b6bc6d323992834b27c Reviewed-on: https://go-review.googlesource.com/c/go/+/406056 Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-04-11all: gofmt main repoRuss Cox
[This CL is part of a sequence implementing the proposal #51082. The design doc is at https://go.dev/s/godocfmt-design.] Run the updated gofmt, which reformats doc comments, on the main repository. Vendored files are excluded. For #51082. Change-Id: I7332f099b60f716295fb34719c98c04eb1a85407 Reviewed-on: https://go-review.googlesource.com/c/go/+/384268 Reviewed-by: Jonathan Amsterdam <jba@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2022-04-04cmd/compile: switch to final unified IR export formatMatthew Dempsky
Now that there's a native go/types importer for unified IR, the compiler no longer needs to stay backwards compatible with old iexport importers. This CL also updates the go/types and go/internal/gcimporter tests to expect that the unified IR importer sets the receiver parameter type to the underlying Interface type, rather than the Named type. This is a temporary workaround until we make a decision on #49906. Notably, this makes `GOEXPERIMENT=unified go test` work on generics code without requiring `-vet=off` (because previously cmd/vet was relying on unified IR's backwards-compatible iexport data, which omitted generic types). Change-Id: Iac7a2346bb7a91e6690fb2978fb702fadae5559d Reviewed-on: https://go-review.googlesource.com/c/go/+/386004 Trust: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-04-01all: fix various doc comment formatting nitsRuss Cox
A run of lines that are indented with any number of spaces or tabs format as a <pre> block. This commit fixes various doc comments that format badly according to that (standard) rule. For example, consider: // - List item. // Second line. // - Another item. Because the - lines are unindented, this is actually two paragraphs separated by a one-line <pre> block. This CL rewrites it to: // - List item. // Second line. // - Another item. Today, that will format as a single <pre> block. In a future release, we hope to format it as a bulleted list. Various other minor fixes as well, all in preparation for reformatting. For #51082. Change-Id: I95cf06040d4186830e571cd50148be3bf8daf189 Reviewed-on: https://go-review.googlesource.com/c/go/+/384257 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-03-07cmd/compile: fix reentrancy issue in unified IR function body readingMatthew Dempsky
We shouldn't need to read in function bodies for new functions found during inlining, but something is expecting them to still be read in. We should fix that code to not depend on them being read in, but in the mean time reading them in anyway is at least correct, albeit less efficient in time and space. Fixes #49536. Updates #50552. Change-Id: I949ef45e7be09406e5a8149e251d78e015aca5fa Reviewed-on: https://go-review.googlesource.com/c/go/+/390335 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Trust: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-03-01cmd/compile: move unified IR's reader2 into importer packageMatthew Dempsky
This keeps cmd/compile/internal/importer similar to how go/internal/gcimporter will work after unified IR support is added in a subsequent CL. Change-Id: Id3c000f3a13a54a725602552c6b3191d1affb184 Reviewed-on: https://go-review.googlesource.com/c/go/+/388614 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Trust: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2022-03-01internal/pkgbits: extract unified IR coding-level logicMatthew Dempsky
This logic is needed for the go/types unified IR importer, so extract it into a separate internal package so we can reuse a single copy. Change-Id: I5f734b76e580fdb69ee39e45ac553c22d01c5909 Reviewed-on: https://go-review.googlesource.com/c/go/+/386000 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Trust: Matthew Dempsky <mdempsky@google.com>
generated by cgit v1.3 (git 2.53.0) at 2026-04-15 09:44:44 +0000