aboutsummaryrefslogtreecommitdiff
path: root/src/cmd/compile/internal/noder/reader.go
AgeCommit message (Collapse)Author
2026-01-22cmd/compile: speedup large init function compile timeCuong Manh Le
Fixes #77153 Change-Id: Ia3906e4d686281be78b65daf7a7a4fd1b2b2483d Reviewed-on: https://go-review.googlesource.com/c/go/+/737880 Reviewed-by: Keith Randall <khr@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2025-10-21all: eliminate unnecessary type conversionsJes Cok
Found by github.com/mdempsky/unconvert Change-Id: I88ce10390a49ba768a4deaa0df9057c93c1164de GitHub-Last-Rev: 3b0f7e8f74f58340637f33287c238765856b2483 GitHub-Pull-Request: golang/go#75974 Reviewed-on: https://go-review.googlesource.com/c/go/+/712940 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@golang.org> Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: David Chase <drchase@google.com>
2025-10-08cmd/compile/internal/devirtualize: improve concrete type analysisMateusz Poliwczak
This change improves the concrete type analysis in the devirtualizer, it not longer relies on ir.Reassigned, it now statically tries to determine the concrete type of an interface, even when assigned multiple times, following type assertions and iface conversions. Alternative to CL 649195 Updates #69521 Fixes #64824 Change-Id: Ib1656e19f3619ab2e1e6b2c78346cc320490b2af GitHub-Last-Rev: e8fa0b12f0a7b1d7ae00e5edb54ce04d1f702c09 GitHub-Pull-Request: golang/go#71935 Reviewed-on: https://go-review.googlesource.com/c/go/+/652036 Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Keith Randall <khr@golang.org>
2025-09-26cmd/compile: fix ICE with new(<untyped expr>)Cuong Manh Le
Fixes #75617 Change-Id: Iaee7d4556db54b9999f5ba8458e7c05c11ccfc36 Reviewed-on: https://go-review.googlesource.com/c/go/+/707075 Reviewed-by: Junyang Shao <shaojunyang@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Alan Donovan <adonovan@google.com>
2025-09-23cmd/compile/internal: support new(expr)Alan Donovan
This CL adds compiler support for new(expr), a feature of go1.26 that allows the user to specify the initial value of the variable instead of its type. Also, a basic test of dynamic behavior. See CL 704737 for spec change and CL 704935 for type-checker changes. For #45624 Change-Id: I65d27de1ee3aabb819b57cce8ea77f3073447757 Reviewed-on: https://go-review.googlesource.com/c/go/+/705157 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Mateusz Poliwczak <mpoliwczak34@gmail.com> Auto-Submit: Alan Donovan <adonovan@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com>
2025-09-23cmd/compile: prevent shapifying of pointer shape typeCuong Manh Le
CL 641955 changes the Unified IR reader to not doing shapify when reading reshaping expression, prevent losing of the original type. This is an oversight, as the main problem isn't about shaping during the reshaping process itself, but about the specific case of shaping a pointer shape type. This bug occurs when instantiating a generic function within another generic function with a pointer shape type as type parameter, which will convert `*[]go.shape.T` to `*go.shape.uint8`, resulting in the loss of the original expression's type. This commit changes Unified IR reader to avoid pointer shaping for `*[]go.shape.T`, ensures that the original type is preserved when processing reshaping expressions. Updates #71184 Updates #73947 Fixes #74260 Fixes #75461 Change-Id: Icede6b73247d0d367bb485619f2dafb60ad66806 Reviewed-on: https://go-review.googlesource.com/c/go/+/704095 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: Junyang Shao <shaojunyang@google.com>
2025-08-05cmd: remove dead codeqiulaidongfeng
Fixes #74076 Change-Id: Icc67b3d4e342f329584433bd1250c56ae8f5a73d Reviewed-on: https://go-review.googlesource.com/c/go/+/690635 Reviewed-by: Alan Donovan <adonovan@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Commit-Queue: Alan Donovan <adonovan@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Auto-Submit: Alan Donovan <adonovan@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2025-06-09cmd/compile: relax reshaping conditionCuong Manh Le
CL 641955 changes the Unified IR reader to not doing shapify when reading reshaping expression. However, this condition only matters with pointer type shaping, which will lose the original type, causes the reshaping ends up with a completely different type. This CL relaxes the condition, always allow non-pointer types shaping. Updates #71184 Fixes #73947 Change-Id: Ib0bafd8932c52d99266f311b6cbfc75c00383f9b Reviewed-on: https://go-review.googlesource.com/c/go/+/678335 Reviewed-by: Keith Randall <khr@golang.org> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Keith Randall <khr@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
2025-06-04Revert "cmd/compile: Enable inlining of tail calls"Cherry Mui
This reverts CL 650455 and CL 655816. Reason for revert: it causes #73747. Properly fixing it gets into trickiness with defer/recover, wrapper, and inlining. We're late in the Go 1.25 release cycle. Fixes #73747. Change-Id: Ifb343d522b18fec3fec73a7c886678032ac8e4df Reviewed-on: https://go-review.googlesource.com/c/go/+/678575 Reviewed-by: Carlos Amedee <carlos@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2025-05-22cmd/compile: do not shapify when reading reshaping exprCuong Manh Le
Fixes #71184 Change-Id: I22e7ae5203311e86a90502bfe155b0597007887d Reviewed-on: https://go-review.googlesource.com/c/go/+/641955 Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Keith Randall <khr@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: David Chase <drchase@google.com>
2025-05-22cmd/compile: fix ICE with recursive alias type parameterCuong Manh Le
CL 585399 fixed an initialization loop during IR contruction that involving alias type, by avoiding publishing alias declarations until the RHS type expression has been constructed. There's an assertion to ensure that the alias's type must be the same during the initialization. However, that assertion is too strict, since we may construct different instances of the same type, if the type is an instantination of generic type. To fix this, we could use types.IdenticalStrict to ensure that these types matching exactly. Updates #66873. Updates #73309. Change-Id: I2559bed37e21615854333fb1057d7349406e6a1b Reviewed-on: https://go-review.googlesource.com/c/go/+/668175 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@golang.org> 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: Keith Randall <khr@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>
2025-05-06pkgbits: replace references to RelocKind with SectionKindMark Freeman
Change-Id: Id194a42645d1da6440558bf12dc252f347072f86 Reviewed-on: https://go-review.googlesource.com/c/go/+/670175 Auto-Submit: Mark Freeman <mark@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Mark Freeman <mark@golang.org> Reviewed-by: Robert Griesemer <gri@google.com>
2025-03-11cmd/compile: Enable inlining of tail callsAlexander Musman
Enable inlining tail calls and do not limit emitting tail calls only to the non-inlineable methods when generating wrappers. This change produces additional code size reduction. Code size difference measured with this change (tried for x86_64): etcd binary: .text section size: 10613393 -> 10593841 (0.18%) total binary size: 33450787 -> 33424307 (0.07%) compile binary: .text section size: 10171025 -> 10126545 (0.43%) total binary size: 28241012 -> 28192628 (0.17%) cockroach binary: .text section size: 83947260 -> 83694140 (0.3%) total binary size: 263799808 -> 263534160 (0.1%) Change-Id: I694f83cb838e64bd4c51f05b7b9f2bf0193bb551 Reviewed-on: https://go-review.googlesource.com/c/go/+/650455 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@golang.org> Auto-Submit: Keith Randall <khr@golang.org>
2024-11-04cmd/compile: fix inlining name mangling for blank labelCuong Manh Le
Fixes #70175 Change-Id: I13767d951455854b03ad6707ff9292cfe9097ee9 Reviewed-on: https://go-review.googlesource.com/c/go/+/624377 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Keith Randall <khr@golang.org> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Keith Randall <khr@google.com> Auto-Submit: Keith Randall <khr@golang.org>
2024-10-07cmd/compile: avoid dynamic type when possibleCuong Manh Le
If the expression type is a single compile-time known type, use that type instead of the dynamic one, so the later passes of the compiler could skip un-necessary runtime calls. Thanks Youlin Feng for writing the original test case. Change-Id: I3f65ab90f041474a9731338a82136c1d394c1773 Reviewed-on: https://go-review.googlesource.com/c/go/+/616975 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: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2024-09-11cmd/compile: remove types.Type rparams fieldCuong Manh Le
This field is present during the initial development of generic support inside compiler, and indicating whether a type is fully instantiated is the solely purpose at this moment. Further, its name is also confused, and there have been a TODO to chose a better name for it. Instead, just using a bit to track whether a type is fully instantiated, then this rparams field can be removed to simplify the code. Change-Id: Ia29c6dd5792487c440b83b0f3b77bd60917c2019 Reviewed-on: https://go-review.googlesource.com/c/go/+/611255 Reviewed-by: Tim King <taking@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Keith Randall <khr@golang.org>
2024-09-09cmd/compile: emit tail call wrappers when possibleamusman
Use OTAILCALL in wrapper if the receiver and method are both pointers and it is not going to be inlined, similar to how it is done in reflectdata.methodWrapper. Currently tail call may be used for functions with identical argument types. This change updates wrappers where both wrapper and the wrapped method's receiver are pointers. In this case, we have the same signature for the wrapper and the wrapped method (modulo the receiver's pointed-to types), and do not need any local variables in the generated wrapper (on stack) because the arguments are immediately passed to the wrapped method in place (without need to move some value passed to other register or to change any argument/return passed through stack). Thus, the wrapper does not need its own stack frame. This applies to promoted methods, e.g. when we have some struct type U with an embedded type *T and construct a wrapper like func (recv *U) M(arg int) bool { return recv.T.M(i) } See also test/abi/method_wrapper.go for a running example. Code size difference measured with this change (tried for x86_64): etcd binary: .text section size: 21472251 -> 21432350 (0.2%) total binary size: 32226640 -> 32191136 (0.1%) compile binary: .text section size: 17419073 -> 17413929 (0.03%) total binary size: 26744743 -> 26737567 (0.03%) Change-Id: I9bbe730568f6def21a8e61118a6b6f503d98049c Reviewed-on: https://go-review.googlesource.com/c/go/+/578235 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com>
2024-09-04cmd: do not use notsha256Cuong Manh Le
CL 402595 used notsha256 to prevent the compiler from depending on cgo-based implementations of sha1 and sha256. However, since CL 454836, cmd is built with CGO_ENABLED=0, which will disable boringcrypto. Thus all usages of notsha256 is not necessary anymore. Updates #51940 Updates #64751 Change-Id: I503090f7a2efb5723e8a79523b143dc7cdb4edd0 Reviewed-on: https://go-review.googlesource.com/c/go/+/610596 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: Keith Randall <khr@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2024-08-26cmd/compile: deprecate derived info needed fieldCuong Manh Le
This field is unused since shape-based stenciling was added for Unified IR (CL 421821). The derived types information is now explicitly using derived-type dictionaries (CL 331829). This CL follows the pattern used in CL 606035. Updates #68778 Change-Id: Ie784b6443c0a651854bfbcebb8a5166b1481408b Reviewed-on: https://go-review.googlesource.com/c/go/+/608216 Reviewed-by: Robert Griesemer <gri@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Tim King <taking@google.com>
2024-08-23cmd/compile/internal: write type parameters for aliasesTim King
Writes the field for type parameter names for aliases when the bitstream is >= V2. This is a no-op at the moment as the writer is hardwired to V1. Updates #68778 Change-Id: I5887e3608239b9a6a47e3cc21cacb75b84e1d186 Reviewed-on: https://go-review.googlesource.com/c/go/+/607235 Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Robert Griesemer <gri@google.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-08-09cmd/compile: add basic wasmexport supportCherry Mui
This CL adds a compiler directive go:wasmexport, which applies to a Go function and makes it an exported function of the Wasm module being built, so it can be called directly from the host. As proposed in #65199, parameter and result types are limited to 32-bit and 64-bit integers and floats, and there can be at most one result. As the Go and Wasm calling conventions are different, for a wasmexport function we generate a wrapper function does the ABI conversion at compile time. Currently this CL only adds basic support. In particular, - it only supports executable mode, i.e. the Go wasm module calls into the host via wasmimport, which then calls back to Go via wasmexport. Library (c-shared) mode is not implemented yet. - only supports wasip1, not js. - if the exported function unwinds stacks (goroutine switch, stack growth, etc.), it probably doesn't work. TODO: support stack unwinding, c-shared mode, js. For #65199. Change-Id: Id1777c2d44f7d51942c1caed3173c0a82f120cc4 Reviewed-on: https://go-review.googlesource.com/c/go/+/603055 Reviewed-by: Than McIntosh <thanm@golang.org> Reviewed-by: Randy Reddig <randy.reddig@fastly.com> Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-07-22cmd/compile: retire "IsHiddenClosure" and "IsDeadcodeClosure"Cuong Manh Le
Since CL 522318, all closures are now hidden. Thus this CL removes all codes that worries about hidden vs non-hidden closures. Change-Id: I1ea124168c76cedbfc4053d2f150937a382aa330 Reviewed-on: https://go-review.googlesource.com/c/go/+/523275 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Than McIntosh <thanm@google.com>
2024-07-16cmd/compile: fix recursive generic interface instantiationCuong Manh Le
When shapifying recursive instantiated types, the compiler ends up leaving the type as-is if it already has been a shape type. However, if both of type arguments are interfaces, and one of them is a recursive one, it ends up being shaped as-is, while the other is shaped to its underlying, causing mismatch in function signature. Fixing this by shapifying an interface type as-is, if it is fully instantiated and already been a shape type. Fixes #65362 Fixes #66663 Change-Id: I839d266e0443b41238b1b7362aca09adc0177362 Reviewed-on: https://go-review.googlesource.com/c/go/+/559656 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: Cherry Mui <cherryyz@google.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2024-05-23runtime: move exit hooks into internal/runtime/exithookRuss Cox
This removes a //go:linkname usage in the coverage implementation. For #67401. Change-Id: I0602172c7e372a84465160dbf46d9fa371582fff Reviewed-on: https://go-review.googlesource.com/c/go/+/586259 Auto-Submit: Russ Cox <rsc@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.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-05-15cmd/compile/internal/noder: enable type aliases in type checkerMatthew Dempsky
This CL fixes an initialization loop during IR construction, that stems from IR lacking first-class support for aliases. As a workaround, we avoid publishing alias declarations until the RHS type expression has been constructed. Thanks to gri@ for investigating while I was out. Fixes #66873. Change-Id: I11e0d96ea6c357c295da47f44b6ec408edef89b7 Reviewed-on: https://go-review.googlesource.com/c/go/+/585399 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Auto-Submit: Matthew Dempsky <mdempsky@google.com>
2024-05-10cmd/compile, cmd/link: disallow linkname of some newly added internal functionsCherry Mui
Go API is defined through exported symbols. When a package is imported, the compiler ensures that only exported symbols can be accessed, and the go command ensures that internal packages cannot be imported. This ensures API integrity. But there is a hole: using linkname, one can access internal or non-exported symbols. Linkname is a mechanism to give access of a symbol to a package without adding it to the public API. It is intended for coupled packages to share some implementation details, or to break circular dependencies, and both "push" (definition) and "pull" (reference) sides are controlled, so they can be updated in sync. Nevertheless, it is abused as a mechanism to reach into internal details of other packages uncontrolled by the user, notably the runtime. As the other package evolves, the code often breaks, because the linknamed symbol may no longer exist, or change its signature or semantics. This CL adds a mechanism to enforce the integrity of linknames. Generally, "push" linkname is allowed, as the package defining the symbol explicitly opt in for access outside of the package. "Pull" linkname is checked and only allowed in some circumstances. Given that there are existing code that use "pull"-only linkname to access other package's internals, disallowing it completely is too much a change at this point in the release cycle. For a start, implement a hard-coded blocklist, which contains some newly added internal functions that, if used inappropriately, may break memory safety or runtime integrity. All blocked symbols are newly added in Go 1.23. So existing code that builds with Go 1.22 will continue to build. For the implementation, when compiling a package, we mark linknamed symbols in the current package with an attribute. At link time, marked linknamed symbols are checked against the blocklist. Care is taken so it distinguishes a linkname reference in the current package vs. a reference of a linkname from another package and propagated to the current package (e.g. through inlining or instantiation). Symbol references in assembly code are similar to linknames, and are treated similarly. Change-Id: I8067efe29c122740cd4f1effd2dec2d839147d5d Reviewed-on: https://go-review.googlesource.com/c/go/+/584598 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2024-03-20cmd/compile/internal/noder: remove wrapNameMatthew Dempsky
The OPARENs inserted here used to be necessary for better error diagnostics, but now those are handled by types2. Change-Id: I88d50d34d9e00cdd7d0fb32f6e460a179345a787 Reviewed-on: https://go-review.googlesource.com/c/go/+/573115 Auto-Submit: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Than McIntosh <thanm@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-02-27cmd/compile/internal/noder: add method wrapper commentsMatthew Dempsky
Add commentary explaining why and how we create method wrappers. Change-Id: Idf35a77d0483f24c2163e11f5e001fd5536cca63 Reviewed-on: https://go-review.googlesource.com/c/go/+/558395 Auto-Submit: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.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>
2024-01-10cmd/compile: use hashed symbol name for go.shape types if too longThan McIntosh
Shape-based stenciling in the Go compiler's generic instantiation phase looks up shape types using the underlying type of a given target type. This has a beneficial effect in most cases (e.g. we can use the same shape type for two different named types whose underlying type is "int"), but causes some problems when the underlying type is a very large structure. The link string for the underlying type of a large imported struct can be extremely long, since the link string essentially enumerates the full package path for every field type; this can produce a "go.shape.struct { ... " symbol name that is absurdly long. This patch switches the compiler to use a hash of the underlying type link string instead of the string itself, which should continue to provide commoning but keep symbol name lengths reasonable for shape types based on large imported structs. Fixes #65030. Change-Id: I87d602626c43172beb99c186b8ef72327b8227a2 Reviewed-on: https://go-review.googlesource.com/c/go/+/554975 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Than McIntosh <thanm@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.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-17cmd/compile: use internal/buildcfg for checking newinliner enableCuong Manh Le
internal/goexperiment reports what GOEXPERIMENT the compiler itself was compiled with, not what experiment to use for the object code that the compiler is compiling. Fixes #64189 Change-Id: I892d78611f8c76376032fd7459e755380afafac6 Reviewed-on: https://go-review.googlesource.com/c/go/+/542995 Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Than McIntosh <thanm@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2023-11-15cmd/compile: check for iteration after range func loop exitDavid Chase
When this happens, panic. This is a revised version of a check that used #next, where this one instead uses a per-loop #exit flag, and catches more problematic iterators. Updates #56413. Updates #61405. Change-Id: I6574f754e475bb67b9236b4f6c25979089f9b629 Reviewed-on: https://go-review.googlesource.com/c/go/+/540263 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2023-10-09cmd/compile: fix typecheck range over negative integerCuong Manh Le
Before range over integer, types2 leaves constant expression in RHS of non-constant shift untyped, so idealType do the validation to ensure that constant value must be an int >= 0. With range over int, the range expression can also be left untyped, and can be an negative integer, causing the validation false. Fixing this by relaxing the validation in idealType, and moving the check to Unified IR reader. Fixes #63378 Change-Id: I43042536c09afd98d52c5981adff5dbc5e7d882a Reviewed-on: https://go-review.googlesource.com/c/go/+/532835 Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@golang.org>
2023-10-05cmd/compile/internal/ir: tweak a couple namesMatthew Dempsky
CallExpr.X -> CallExpr.Fun This consistent with go/ast and cmd/compile/internal/syntax. OPRINTN -> OPRINTLN This op represents the "println" builtin; might as well spell it the same way. Change-Id: Iead1b007776658c717879cf0997b3c48028428f4 Reviewed-on: https://go-review.googlesource.com/c/go/+/532795 Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Keith Randall <khr@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com> Auto-Submit: Matthew Dempsky <mdempsky@google.com>
2023-09-20cmd/compile: implement range over funcRuss Cox
Add compiler support for range over functions. See the large comment at the top of cmd/compile/internal/rangefunc/rewrite.go for details. This is only reachable if GOEXPERIMENT=range is set, because otherwise type checking will fail. For proposal #61405 (but behind a GOEXPERIMENT). For #61717. Change-Id: I05717f94e63089c503acc49b28b47edeb4e011b4 Reviewed-on: https://go-review.googlesource.com/c/go/+/510541 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Auto-Submit: Russ Cox <rsc@golang.org>
2023-09-14cmd/compile/internal/noder: drop unused *types.Pkg resultsMatthew Dempsky
Several methods return a (*types.Pkg, *types.Sym) pair instead of just a *types.Sym, because we used to need to preserve the *types.Pkg for certain types so that we could write out export data for go/types to use (which exposes these through its APIs). But now that we write export data from the types2 representation directly, there's no need for the rest of the compiler to be concerned about that. Change-Id: I6ac81a6db71b8e0795ff2f33399b839871564eb7 Reviewed-on: https://go-review.googlesource.com/c/go/+/528416 Reviewed-by: Than McIntosh <thanm@google.com> Auto-Submit: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2023-09-14cmd/compile/internal/ir: add Func.DeclareParamsMatthew Dempsky
There's several copies of this function. We only need one. While here, normalize so that we always declare parameters, and always use the names ~pNN for params and ~rNN for results. Change-Id: I49e90d3fd1820f3c07936227ed5cfefd75d49a1c Reviewed-on: https://go-review.googlesource.com/c/go/+/528415 Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Auto-Submit: Matthew Dempsky <mdempsky@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Than McIntosh <thanm@google.com>
2023-09-12cmd/compile/internal/ir: add NewZeroMatthew Dempsky
This constructs a zero value of any type, which helps address some corner case scenarios. It should also eventually handle the predeclared "zero" value, at least as currently implemented in go.dev/cl/520336. For #61372. Change-Id: I3a86a94fd8fa388c9c6bf281da8aa532b3da00fc Reviewed-on: https://go-review.googlesource.com/c/go/+/527696 Auto-Submit: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-by: Than McIntosh <thanm@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2023-09-12cmd/compile: stop changing Field.Sym for parametersMatthew Dempsky
Field.Sym now always contains the original symbol as it appeared in Go source, so we don't need OrigSym anymore. Instead, when the mangled name is desired, Field.Nname.Sym() can be used instead, which is always non-nil if Nname is non-nil. Change-Id: I96cd61db6458d4a2e07ec5810239236e3dfba747 Reviewed-on: https://go-review.googlesource.com/c/go/+/527516 Auto-Submit: Matthew Dempsky <mdempsky@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> Reviewed-by: Than McIntosh <thanm@google.com>
2023-09-11cmd/compile/internal/noder: handle unsafe.Sizeof, etc in unified IRMatthew Dempsky
Previously, the unified frontend implemented unsafe.Sizeof, etc that involved derived types by constructing a normal OSIZEOF, etc expression, including fully instantiating their argument. (When unsafe.Sizeof is applied to a non-generic type, types2 handles constant folding it.) This worked, but involves unnecessary work, since all we really need to track is the argument type (and the field selections, for unsafe.Offsetof). Further, the argument expression could generate temporary variables, which would then go unused after typecheck replaced the OSIZEOF expression with an OLITERAL. This results in compiler failures after CL 523315, which made later passes stricter about expecting the frontend to not construct unused temporaries. Fixes #62515. Change-Id: I37baed048fd2e35648c59243f66c97c24413aa94 Reviewed-on: https://go-review.googlesource.com/c/go/+/527097 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@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> Auto-Submit: Matthew Dempsky <mdempsky@google.com>
2023-09-11cmd/compile/internal/ir: add Type param to NewBasicLitMatthew Dempsky
This CL adds an explicit Type parameter to NewBasicLit so that callers can directly construct typed OLITERAL nodes. Change-Id: I0ab50ac3d7ddb7adcc903633a62ac496921165e9 Reviewed-on: https://go-review.googlesource.com/c/go/+/527096 Auto-Submit: Matthew Dempsky <mdempsky@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2023-09-08cmd/compile: write "properties" to export data for inlinable funcsThan McIntosh
Augment the ir.Inline container to include an entry for function properties (currently serialized as a string), and if GOEXPERIMENT=newinliner is set, compute and store function properties for all inline candidates processed by the inliner. The idea here is that if the function properties are going to drive inlining decisions, we'd like to have the same info from non-local / imported functions as for local / in-package functions, hence we need to include the properties in the export data. Hand testing on the compiler itself and with k8s kubelet shows that this increases the size of export data overall by about 2-3 percent, so a pretty modest increase. Updates #61502. Change-Id: I9d1c311aa8418d02ffea3629c3dd9d8076886d15 Reviewed-on: https://go-review.googlesource.com/c/go/+/511562 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2023-09-08cmd/compile: cleanup uses of ir.Orig and ir.SepCopyMatthew Dempsky
Mostly automated refactoring with gofmt: gofmt -r 'ir.Orig(n) -> n' gofmt -r 'ir.SepCopy(n) -> ir.Copy(n)' Followed by some manual cleanups. Change-Id: Ib35abeba9e60b70ba463e161fb39358fb058a83e Reviewed-on: https://go-review.googlesource.com/c/go/+/526398 Reviewed-by: Keith Randall <khr@golang.org> Auto-Submit: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2023-09-08cmd/compile/internal/noder: stop preserving original const stringsMatthew Dempsky
One of the more tedious quirks of the original frontend (i.e., typecheck) to preserve was that it preserved the original representation of constants into the backend. To fit into the unified IR model, I ended up implementing a fairly heavyweight workaround: simply record the original constant's string expression in the export data, so that diagnostics could still report it back, and match the old test expectations. But now that there's just a single frontend to support, it's easy enough to just update the test expectations and drop this support for "raw" constant expressions. Change-Id: I1d859c5109d679879d937a2b213e777fbddf4f2f Reviewed-on: https://go-review.googlesource.com/c/go/+/526376 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2023-08-29cmd/compile/internal/ir: drop Inl.BodyMatthew Dempsky
We don't actually depend on Inl.Body anywhere, except it implicitly serves to indicate whether Inl.Dcl has been populated. So replace it with a boolean so we don't need to keep a useless copy of every inlinable function body in memory. While here, also add some Fatalfs to make sure there are no unused local variables. The unified frontend now omits unreachable code during export data writing, so there shouldn't be unused local variables. Also, since unified IR uses the same code/data to construct the original function as inlined and/or imported functions, the Dcl list should always be the same, which addresses the real root issue (i.e., that export/import could skew the Dcl lists). Change-Id: I6e3435f3a0352f6efbae787344006efac1891e84 Reviewed-on: https://go-review.googlesource.com/c/go/+/523315 Auto-Submit: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
generated by cgit v1.3 (git 2.53.0) at 2026-04-15 13:58:41 +0000