aboutsummaryrefslogtreecommitdiff
path: root/src/cmd/compile/internal/noder/reader.go
AgeCommit message (Collapse)Author
43 hourscmd/compile: remove redundant codeWeixie Cui
Change-Id: If524465cc898a36a31f9034d5b2f13e8842357a9 GitHub-Last-Rev: bdf52219d7d38b94213529f3d399acca69fa5bae GitHub-Pull-Request: golang/go#78604 Reviewed-on: https://go-review.googlesource.com/c/go/+/764361 Reviewed-by: Mark Freeman <markfreeman@google.com> Auto-Submit: Keith Randall <khr@golang.org> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Sean Liao <sean@liao.dev> Reviewed-by: Keith Randall <khr@google.com>
12 dayscmd/compile/internal/noder: omit wrapper functions for generic methodsMark Freeman
Emitting wrapper functions for generic methods is tricky for 2 reasons: 1. Existing downstream machinery expects that it can make certain assumptions about a method if it sees a wrapper function. We may violate those assumptions with generic method wrappers. 2. Signatures for generic methods are generic and hence cannot be encoded using w.typ. This has the slight downside of not using a statically computed wrapper for generic methods and instead dynamically computing the dictionary pointer. Thus, we miss out on a performance optimization for generic methods for now. Code that does not use generic methods is unaffected. Change-Id: I72c626ef0f807c0cb54d8cf040250de8177303cc Reviewed-on: https://go-review.googlesource.com/c/go/+/762382 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Mark Freeman <markfreeman@google.com> Reviewed-by: Robert Griesemer <gri@google.com>
12 dayscmd/compile/internal/noder: decode generic methods and pipe receiversMark Freeman
Change-Id: I7a66fba400a743f4ef2fb989cd8e74e955e22b0f Reviewed-on: https://go-review.googlesource.com/c/go/+/762020 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Mark Freeman <markfreeman@google.com> Reviewed-by: Robert Griesemer <gri@google.com>
14 dayscmd/compile, cmd/link: add linknamestd directive for std-only linknamesCherry Mui
In the standard library, there are a number of linknames, for sharing symbols within the standard library. They are not supposed to be accessed externally. But currently there is no good mechanism to prevent that. In the linker we have a blocklist of linknames, which forbids linkname references other than explicitly allowed packages. The blocklist is manually maintained, requiring periodic manual update. To move away from that manually maintained blocklist, this CL introduces a new directive, linknamestd, that marks a linkname for use within the standard library only. The linker will allow references within the standard library and forbid others. For a proof of concept, runtime.coroswitch is removed from the blocklist, and replaced with linknamestd. An external reference to it is still disallowed by the linker, as tested with cmd/link.TestCheckLinkname with testdata/linkname/coro.go. Change-Id: I0d0f8746b8835d8cdcfc3ff835d22a551da5f038 Reviewed-on: https://go-review.googlesource.com/c/go/+/749942 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com>
2026-03-31cmd/compile/internal/noder: mangle method namesMark Freeman
Mangling produces shaped qualified identifiers using a dictionary. It's important for determining the stenciled type to use for a given instantiation. Since generic methods have qualified identifiers, they need mangling. Suppose a generic method like T[P].m[Q] and a shaped dictionary like: { implicits: 0 receivers: 1 targs: [go.shape.int, go.shape.int] } This would be shaped to T[go.shape.int].m[go.shape.int]. Change-Id: Idc4c825f77a4e9209da65b5b0acb74b9f845bde7 Reviewed-on: https://go-review.googlesource.com/c/go/+/761340 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Mark Freeman <markfreeman@google.com> Reviewed-by: Robert Griesemer <gri@google.com>
2026-03-31cmd/compile/internal/noder: method expressions have nil implicitsMark Freeman
Change-Id: Ia7ba5484ef5258cc8edc19b7d500e334c0e0365d Reviewed-on: https://go-review.googlesource.com/c/go/+/761261 Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Mark Freeman <markfreeman@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-03-31cmd/compile/internal/noder: method expressions for generic methodsMark Freeman
This change permits shaping method expressions for generic methods. The API is slightly different for generic and non-generic methods, as explained in code comments. Using OMETHEXPR minimizes the necessary changes, but forces us to split / rejoin the linker symbol for generic methods. While a bit odd, it seems sound. Change-Id: Iff28b9b11b9e83f450225aba0873644633f20633 Reviewed-on: https://go-review.googlesource.com/c/go/+/761220 Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Mark Freeman <markfreeman@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-03-26cmd/compile/internal/noder: set hasShape for shaped functionsMark Freeman
A signature with a shape will be overwritten using shapeSig, but it arguably still has a shape because it's using a shaped dictionary. This mimics the approach for ObjType. Change-Id: I4646cd73129606772a9218662de76a37217366b4 Reviewed-on: https://go-review.googlesource.com/c/go/+/759721 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Robert Griesemer <gri@google.com>
2026-03-26cmd/compile/internal/noder: shapeSig must return shaped signaturesMark Freeman
Suppose a signature f[P any]() shaped to f[go.shape.int](). This function does not flag f[go.shape.int]() as having a shape because it does not mention a shaped type in its parameter or return fields. This doesn't seem right. Change-Id: I87c4e3b259328b7d27ff0a98d65ed400b4895a69 Reviewed-on: https://go-review.googlesource.com/c/go/+/759660 Auto-Submit: Mark Freeman <markfreeman@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Robert Griesemer <gri@google.com>
2026-03-26cmd/compile: skip incomplete types in needWrapperCuong Manh Le
A recursive pointer type *T may still be a TFORW when the compiler determines if method wrappers are needed. This leads to an incorrect decision and triggers an internal compiler error. Fix this by skipping incomplete types during the method wrapper generation check. Fixes #78295 Change-Id: I4005e525e9b076c6656aed5419283c0418edcac6 Reviewed-on: https://go-review.googlesource.com/c/go/+/758922 Reviewed-by: Jakub Ciolek <jakub@ciolek.dev> Auto-Submit: 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> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2026-03-20cmd/compile/internal/noder: don't shoot oneself (fix silly mistake)Robert Griesemer
When reading multiple promoted fields in a struct literal from UIR, don't overwrite the (top-level) struct literal type needed for the next field. Fixes #78262. For #9859. Change-Id: Ifac64537bebcb7dbb79a6173d0cd032cbf0b8ed8 Reviewed-on: https://go-review.googlesource.com/c/go/+/757225 Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Robert Griesemer <gri@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com>
2026-03-19cmd/compile/internal/noder: encode promoted struct fields for composite ↵Robert Griesemer
literals in UIR This change requires an encoding format change for struct literals. Introduce a new UIR version (V3) and use the opportunity to encode all composite literals more compactly: specifically, when we know that (composite literal) keys are always present, avoid encoding a bool value for each key. Do not yet enable the new format. For #9859. Change-Id: Ic6dc9adb1aa494e923eadaf578f8cfc61efd5ea4 Reviewed-on: https://go-review.googlesource.com/c/go/+/754664 Reviewed-by: Mark Freeman <markfreeman@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Robert Griesemer <gri@google.com>
2026-03-06cmd/compile: use tail calls for wrappers for embedded interfacesKeith Randall
type I interface { foo() } type S struct { I } Because I is embedded in S, S needs a foo method. We generate a wrapper function to implement (*S).foo. It just loads the embedded field I out of S and calls foo on it. When the thing in S.I itself needs a wrapper, then we have a wrapper calling another wrapper. This can continue, leaving a potentially long sequence of wrappers on the stack. When we then call runtime.Callers or friends, we have to walk an unbounded number of frames to find a bounded number of non-wrapper frames. This really happens, for instance with I = context.Context, S = context.ValueCtx, and runtime.Callers = pprof sample (for any of context.Context's methods). To fix, make the interface call in the wrapper a tail call. That way, the number of wrapper frames on the stack does not increase when there are lots of wrappers happening. Fixes #75764 Fixes #77781 Change-Id: I03b1731159d9218c7f14f72ecbbac822d6a6bb87 Reviewed-on: https://go-review.googlesource.com/c/go/+/751465 Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com>
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>
generated by cgit v1.3 (git 2.53.0) at 2026-04-15 12:55:29 +0000