aboutsummaryrefslogtreecommitdiff
path: root/src/cmd/compile
AgeCommit message (Collapse)Author
2023-02-17cmd/compile: move raw writes out of write barrier codeKeith Randall
Previously, the write barrier calls themselves did the actual writes to memory. Instead, move those writes out to a common location that both the wb-enabled and wb-disabled code paths share. This enables us to optimize the write barrier path without having to worry about performing the actual writes. Change-Id: Ia71ab651908ec124cc33141afb52e4ca19733ac6 Reviewed-on: https://go-review.googlesource.com/c/go/+/447780 Reviewed-by: Michael Knyszek <mknyszek@google.com> TryBot-Bypass: Keith Randall <khr@golang.org> Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
2023-02-17runtime: remove the restriction that write barrier ptrs come in pairsKeith Randall
Future CLs will remove the invariant that pointers are always put in the write barrier in pairs. The behavior of the assembly code changes a bit, where instead of writing the pointers unconditionally and then checking for overflow, check for overflow first and then write the pointers. Also changed the write barrier flush function to not take the src/dst as arguments. Change-Id: I2ef708038367b7b82ea67cbaf505a1d5904c775c Reviewed-on: https://go-review.googlesource.com/c/go/+/447779 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> TryBot-Bypass: Keith Randall <khr@golang.org>
2023-02-17Revert "cmd/compile: use ONAME node directly from generated hash func"Matthew Dempsky
This reverts commit 25f5d9d4a253cb880bff909ebbdc05c8941c4a48. Causes ICE on valid code. Updates #58572. Change-Id: Ib276c87d9b0362bbd2a760ac2a242f82d4e20400 Reviewed-on: https://go-review.googlesource.com/c/go/+/468879 Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> Auto-Submit: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Keith Randall <khr@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-02-17cmd/compile: ensure constant folding of pointer arithmetic remains a pointerKeith Randall
For c + nil, we want the result to still be of pointer type. Fixes ppc64le build failure with CL 468455, in issue33724.go. The problem in that test is that it requires a nil check to be scheduled before the corresponding load. This normally happens fine because we prioritize nil checks. If we have nilcheck(p) and load(p), once p is scheduled the nil check will always go before the load. The issue we saw in 33724 is that when p is a nil pointer, we ended up with two different p's, an int64(0) as the argument to the nil check and an (*Outer)(0) as the argument to the load. Those two zeroes don't get CSEd, so if the (*Outer)(0) happens to get scheduled first, the load can end up before the nilcheck. Fix this by always having constant arithmetic preserve the pointerness of the value, so that both zeroes are of type *Outer and get CSEd. Update #58482 Update #33724 Change-Id: Ib9b8c0446f1690b574e0f3c0afb9934efbaf3513 Reviewed-on: https://go-review.googlesource.com/c/go/+/468615 Reviewed-by: Keith Randall <khr@google.com> Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: David Chase <drchase@google.com> TryBot-Bypass: Keith Randall <khr@golang.org>
2023-02-16cmd/compile: ensure InitMem comes after ArgsKeith Randall
The debug info generation currently depends on this invariant. A small update to CL 468455. Update #58482 Change-Id: Ica305d360d9af04036c604b6a65b683f7cb6e212 Reviewed-on: https://go-review.googlesource.com/c/go/+/468695 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: David Chase <drchase@google.com>
2023-02-16runtime: reimplement GODEBUG=cgocheck=2 as a GOEXPERIMENTKeith Randall
Move this knob from a binary-startup thing to a build-time thing. This will enable followon optmizations to the write barrier. Change-Id: Ic3323348621c76a7dc390c09ff55016b19c43018 Reviewed-on: https://go-review.googlesource.com/c/go/+/447778 Reviewed-by: Michael Knyszek <mknyszek@google.com> Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
2023-02-16cmd/compile: detect write barrier completion differentlyKeith Randall
Instead of keeping track of in which blocks write barriers complete, introduce a new op that marks the exact memory state where the write barrier completes. For future use. This allows us to move some of the write barrier code to between the start of the merging block and the WBend marker. Change-Id: If3809b260292667d91bf0ee18d7b4d0eb1e929f0 Reviewed-on: https://go-review.googlesource.com/c/go/+/447777 Reviewed-by: Keith Randall <khr@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Keith Randall <khr@golang.org>
2023-02-16cmd/compile: reorganize write barrier code a bitKeith Randall
This exposes mightBeHeapPointer and mightContainHeapPointer which I plan to use in future CLs. Change-Id: Ice4ae3b33127936868fff6cc045d8703d0b1a79a Reviewed-on: https://go-review.googlesource.com/c/go/+/447776 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Keith Randall <khr@google.com> Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-02-15cmd/compile: share compiler allocations of similar shapesKeith Randall
Use the same allocator for, e.g., []int32 and []int8. Anything with similar base shapes and be coerced into a single allocator, which helps reuse memory more often. There is not much unsafe in the compiler currently. This adds quite a bit, joining cmd/compiler/internal/base/mapfile_mmap.go and some unsafe.Sizeof calls. Change-Id: I95d6d6e47c42b9f0a45f3556f4d7605735e65d99 Reviewed-on: https://go-review.googlesource.com/c/go/+/461084 Reviewed-by: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Keith Randall <khr@golang.org>
2023-02-15cmd/compile: schedule SP earlierKeith Randall
The actual scheduling of SP early doesn't really matter, but lots of early spills (of arguments) depend on SP so they can't schedule until SP does. Fixes #58482 Change-Id: Ie581fba7cb173d665c11f797f39d824b1c040a2d Reviewed-on: https://go-review.googlesource.com/c/go/+/468455 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Alessandro Arzilli <alessandro.arzilli@gmail.com> Reviewed-by: Keith Randall <khr@google.com> Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: David Chase <drchase@google.com>
2023-02-13cmd/compile: fix wrong escape analysis for go/defer generic callsCuong Manh Le
For go/defer calls like "defer f(x, y)", the compiler rewrites it to: x1, y1 := x, y defer func() { f(x1, y1) }() However, if "f" needs runtime type information, the "RType" field will refer to the outer ".dict" param, causing wrong liveness analysis. To fix this, if "f" refers to outer ".dict", the dict param will be copied to an autotmp, and "f" will refer to this autotmp instead. Fixes #58341 Change-Id: I238b6e75441442b5540d39bc818205398e80c94d Reviewed-on: https://go-review.googlesource.com/c/go/+/466035 Reviewed-by: David Chase <drchase@google.com> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-02-10cmd/compile/internal/pgo: fix hard-coded PGO sample data positionFrederic Branczyk
This patch detects at which index position profiling samples that have the value-type samples count are, instead of the previously hard-coded position of index 1. Runtime generated profiles always generate CPU profiling data with the 0 index being CPU nanoseconds, and samples count at index 1, which is why this previously hasn't come up. This is a redo of CL 465135, now allowing empty profiles. Note that preprocessProfileGraph will already cause pgo.New to return nil for empty profiles. Fixes #58292 Change-Id: Ia6c94f0793f6ca9b0882b5e2c4d34f38e600c1e3 Reviewed-on: https://go-review.googlesource.com/c/go/+/466675 Run-TryBot: Michael Pratt <mpratt@google.com> Reviewed-by: Austin Clements <austin@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-02-09go/types, types2: remove need to store type parameter list in unifierRobert Griesemer
For unification we only need the handles map. The type parameter list was stored for reproducible printing only, but we can achieve the same effect with sorting. This opens the door to adding type parameters from different types/functions that we may want to infer together. They may be added through separate "addTypeParams" calls in the future. Printing (which is used for debugging only) will remain reproducible. Change-Id: I23b56c63fa45a7d687761f2efcf558e61b004584 Reviewed-on: https://go-review.googlesource.com/c/go/+/466955 Reviewed-by: Robert Griesemer <gri@google.com> Run-TryBot: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com> Auto-Submit: Robert Griesemer <gri@google.com>
2023-02-09go/types, types2: simplify unify.inferred signatureRobert Griesemer
Rather than referring back to the type parameter list stored with the unifier, return inferred types for a given list of type parameters. This decouples the unifier more and opens the door for inference to consider type parameters from multiple types for inference. While at it, introduce an internal flag to control whether inference results of the two inference implementations should be compared or not. Change-Id: I23b254c6c1c750f5bd1360aa2bb088cc466434f3 Reviewed-on: https://go-review.googlesource.com/c/go/+/466795 Reviewed-by: Robert Griesemer <gri@google.com> Run-TryBot: Robert Griesemer <gri@google.com> Reviewed-by: Robert Findley <rfindley@google.com> Auto-Submit: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-02-09cmd/compile: disable inline static init optimizationCuong Manh Le
There are a plenty of regression in 1.20 with this optimization. This CL disable inline static init, so it's safer to backport to 1.20 branch. The optimization will be enabled again during 1.21 cycle. Updates #58293 Updates #58339 For #58293 Change-Id: If5916008597b46146b4dc7108c6b389d53f35e95 Reviewed-on: https://go-review.googlesource.com/c/go/+/467015 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2023-02-09cmd/compile: remove reflectdata.AfterGlobalEscapeAnalysisCuong Manh Le
This global variable was used by the old frontend to decide whether to perform escape analysis during method wrapper generation. The old frontend is gone now, the variable is not used anywhere else. Change-Id: I448f2761ea608a9a2ec39a9920fcf7aa12d98799 Reviewed-on: https://go-review.googlesource.com/c/go/+/466278 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Keith Randall <khr@google.com> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-02-09cmd/compile/internal/staticinit: fix panic in interface conversionSung Yoon Whang
This patch fixes a panic from incorrect interface conversion from *ir.BasicLit to *ir.ConstExpr. This only occurs when nounified GOEXPERIMENT is set, so ideally it should be backported to Go 1.20 and removed from master. Fixes #58339 Change-Id: I357069d7ee1707d5cc6811bd2fbdd7b0456323ae GitHub-Last-Rev: 641dedb5f9f95e6f8d46723d445a8c9609719ce4 GitHub-Pull-Request: golang/go#58389 Reviewed-on: https://go-review.googlesource.com/c/go/+/466175 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@google.com>
2023-02-09cmd/compile: remove constant arithmetic overflows during typecheckCuong Manh Le
Since go1.19, these errors are already reported by types2 for any user's Go code. Compiler generated code, which looks like constant expression should be evaluated as non-constant semantic, which allows overflows. Fixes #58293 Change-Id: I6f0049a69bdb0a8d0d7a0db49c7badaa92598ea2 Reviewed-on: https://go-review.googlesource.com/c/go/+/465096 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: David Chase <drchase@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
2023-02-08cmd/compile: use MakeResult in empty MakeSlice eliminationJorropo
This gets eliminated by thoses rules above: // for rewriting results of some late-expanded rewrites (below) (SelectN [0] (MakeResult x ___)) => x (SelectN [1] (MakeResult x y ___)) => y (SelectN [2] (MakeResult x y z ___)) => z Fixes #58161 Change-Id: I4fbfd52c72c06b6b3db906bd9910b6dbb7fe8975 Reviewed-on: https://go-review.googlesource.com/c/go/+/463846 Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com>
2023-02-08Revert "cmd/compile/internal/pgo: fix hard-coded PGO sample data position"Michael Pratt
This reverts CL 465135. Reason for revert: This broke cmd/go.TestScript/build_pgo on the linux-amd64-longtest builder: https://build.golang.org/log/8f8ed7bf576f891a06d295c4a5bca987c6e941d6 Change-Id: Ie2f2cc2731099eb28eda6b94dded4dfc34e29441 Reviewed-on: https://go-review.googlesource.com/c/go/+/466439 Run-TryBot: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com> Auto-Submit: Michael Pratt <mpratt@google.com>
2023-02-08cmd/compile/internal/pgo: fix hard-coded PGO sample data positionFrederic Branczyk
This patch detects at which index position profiling samples that have the value-type samples count are, instead of the previously hard-coded position of index 1. Runtime generated profiles always generate CPU profiling data with the 0 index being CPU nanoseconds, and samples count at index 1, which is why this previously hasn't come up. Fixes #58292 Change-Id: Idde761d53b02259f3076c4e5dcb4a96a9d53df0e GitHub-Last-Rev: dabbf9f88c560286e150e9b136a27c3ac23c5ec1 GitHub-Pull-Request: golang/go#58294 Reviewed-on: https://go-review.googlesource.com/c/go/+/465135 Auto-Submit: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> Run-TryBot: Michael Pratt <mpratt@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2023-02-08cmd/compile: intrinsify math/bits/ReverseBytes{32|64} for 386Wayne Zuo
The BSWAPL instruction is supported in i486 and newer. https://github.com/golang/go/wiki/MinimumRequirements#386 says we support "All Pentium MMX or later". The Pentium is also referred to as i586, so that we are safe with these instructions. Change-Id: I6dea1f9d864a45bb07c8f8f35a81cfe16cca216c Reviewed-on: https://go-review.googlesource.com/c/go/+/465515 Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org> Reviewed-by: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Keith Randall <khr@google.com>
2023-02-08cmd/compile: fix inline static init arguments substitued treeCuong Manh Le
Blank node must be ignored when building arguments substitued tree. Otherwise, it could be used to replace other blank node in left hand side of an assignment, causing an invalid IR node. Consider the following code: type S1 struct { s2 S2 } type S2 struct{} func (S2) Make() S2 { return S2{} } func (S1) Make() S1 { return S1{s2: S2{}.Make()} } var _ = S1{}.Make() After staticAssignInlinedCall, the assignment becomes: var _ = S1{s2: S2{}.Make()} and the arg substitued tree is "map[*ir.Name]ir.Node{_: S1{}}". Now, when doing static assignment, if there is any assignment to blank node, for example: _ := S2{} That blank node will be replaced with "S1{}": S1{} := S2{} So constructing an invalid IR which causes the ICE. Fixes #58325 Change-Id: I21b48357f669a7e02a7eb4325246aadc31f78fb9 Reviewed-on: https://go-review.googlesource.com/c/go/+/465098 Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: David Chase <drchase@google.com>
2023-02-07cmd/compile: remove unused ISELB PPC64 ssa opcodePaul E. Murphy
The usage of ISELB has been removed as part of changes made to support Power10 SETBC instructions. Change-Id: I2fce4370f48c1eeee65d411dfd1bea4201f45b45 Reviewed-on: https://go-review.googlesource.com/c/go/+/465575 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Paul Murphy <murp@ibm.com> Reviewed-by: Archana Ravindar <aravind5@in.ibm.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
2023-02-06cmd/link: linker portion of dead map removalThan McIntosh
This patch contains the linker changes needed to enable deadcoding of large unreferenced map variables, in combination with a previous compiler change. We add a new cleanup function that runs just after deadcode that looks for relocations in "init" funcs that are weak, of type R_CALL (and siblings), and are targeting an unreachable function. If we find such a relocation, after checking to make sure it targets a map.init.XXX helper, we redirect the relocation to a point to a no-op routine ("mapinitnoop") in the runtime. Compilebench results for this change: │ out.base.txt │ out.wrap.txt │ │ sec/op │ sec/op vs base │ Template 218.6m ± 2% 221.1m ± 1% ~ (p=0.129 n=39) Unicode 180.5m ± 1% 178.9m ± 1% -0.93% (p=0.006 n=39) GoTypes 1.162 ± 1% 1.156 ± 1% ~ (p=0.850 n=39) Compiler 143.6m ± 1% 142.6m ± 1% ~ (p=0.743 n=39) SSA 8.698 ± 1% 8.719 ± 1% ~ (p=0.145 n=39) Flate 142.6m ± 1% 143.9m ± 3% ~ (p=0.287 n=39) GoParser 247.7m ± 1% 248.8m ± 1% ~ (p=0.265 n=39) Reflect 588.0m ± 1% 590.4m ± 1% ~ (p=0.269 n=39) Tar 198.5m ± 1% 201.3m ± 1% +1.38% (p=0.005 n=39) XML 259.1m ± 1% 260.0m ± 1% ~ (p=0.376 n=39) LinkCompiler 746.8m ± 2% 747.8m ± 1% ~ (p=0.706 n=39) ExternalLinkCompiler 1.906 ± 0% 1.902 ± 1% ~ (p=0.207 n=40) LinkWithoutDebugCompiler 522.4m ± 21% 471.1m ± 1% -9.81% (p=0.000 n=40) StdCmd 21.32 ± 0% 21.39 ± 0% +0.32% (p=0.035 n=40) geomean 609.2m 606.0m -0.53% │ out.base.txt │ out.wrap.txt │ │ user-sec/op │ user-sec/op vs base │ Template 401.9m ± 3% 406.9m ± 2% ~ (p=0.291 n=39) Unicode 191.9m ± 6% 196.1m ± 3% ~ (p=0.052 n=39) GoTypes 3.967 ± 3% 4.056 ± 1% ~ (p=0.099 n=39) Compiler 171.1m ± 3% 173.4m ± 3% ~ (p=0.415 n=39) SSA 30.04 ± 4% 30.25 ± 4% ~ (p=0.106 n=39) Flate 246.3m ± 3% 248.9m ± 4% ~ (p=0.499 n=39) GoParser 518.7m ± 1% 520.6m ± 2% ~ (p=0.531 n=39) Reflect 1.670 ± 1% 1.656 ± 2% ~ (p=0.137 n=39) Tar 352.7m ± 2% 360.3m ± 2% ~ (p=0.117 n=39) XML 528.8m ± 2% 521.1m ± 2% ~ (p=0.296 n=39) LinkCompiler 1.128 ± 2% 1.140 ± 2% ~ (p=0.324 n=39) ExternalLinkCompiler 2.165 ± 2% 2.147 ± 2% ~ (p=0.537 n=40) LinkWithoutDebugCompiler 484.2m ± 4% 490.7m ± 3% ~ (p=0.897 n=40) geomean 818.5m 825.1m +0.80% │ out.base.txt │ out.wrap.txt │ │ text-bytes │ text-bytes vs base │ HelloSize 766.0Ki ± 0% 766.0Ki ± 0% ~ (p=1.000 n=40) ¹ CmdGoSize 10.02Mi ± 0% 10.02Mi ± 0% -0.03% (n=40) geomean 2.738Mi 2.738Mi -0.01% ¹ all samples are equal │ out.base.txt │ out.wrap.txt │ │ data-bytes │ data-bytes vs base │ HelloSize 14.17Ki ± 0% 14.17Ki ± 0% ~ (p=1.000 n=40) ¹ CmdGoSize 308.3Ki ± 0% 298.5Ki ± 0% -3.19% (n=40) geomean 66.10Ki 65.04Ki -1.61% ¹ all samples are equal │ out.base.txt │ out.wrap.txt │ │ bss-bytes │ bss-bytes vs base │ HelloSize 197.3Ki ± 0% 197.3Ki ± 0% ~ (p=1.000 n=40) ¹ CmdGoSize 228.2Ki ± 0% 228.1Ki ± 0% -0.01% (n=40) geomean 212.2Ki 212.1Ki -0.01% ¹ all samples are equal │ out.base.txt │ out.wrap.txt │ │ exe-bytes │ exe-bytes vs base │ HelloSize 1.192Mi ± 0% 1.192Mi ± 0% +0.00% (p=0.000 n=40) CmdGoSize 14.85Mi ± 0% 14.83Mi ± 0% -0.09% (n=40) geomean 4.207Mi 4.205Mi -0.05% Also tested for any linker changes by benchmarking relink of k8s "kubelet"; no changes to speak of there. Updates #2559. Updates #36021. Updates #14840. Change-Id: I4cc5370b3f20679a1065aaaf87bdf2881e257631 Reviewed-on: https://go-review.googlesource.com/c/go/+/463395 Run-TryBot: Than McIntosh <thanm@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-02-06cmd/compile: enable deadcode of unreferenced large global mapsThan McIntosh
This patch changes the compiler's pkg init machinery to pick out large initialization assignments to global maps (e.g. var mymap = map[string]int{"foo":1, "bar":2, ... } and extract the map init code into a separate outlined function, which is then called from the main init function with a weak relocation: var mymap map[string]int // KEEP reloc -> map.init.0 func init() { map.init.0() // weak relocation } func map.init.0() { mymap = map[string]int{"foo":1, "bar":2} } The map init outlining is done selectively (only in the case where the RHS code exceeds a size limit of 20 IR nodes). In order to ensure that a given map.init.NNN function is included when its corresponding map is live, we add dummy R_KEEP relocation from the map variable to the map init function. This first patch includes the main compiler compiler changes, and with the weak relocation addition disabled. Subsequent patch includes the requred linker changes along with switching to the call to the outlined routine to a weak relocation. See the later linker change for associated compile time performance numbers. Updates #2559. Updates #36021. Updates #14840. Change-Id: I1fd6fd6397772be1ebd3eb397caf68ae9a3147e9 Reviewed-on: https://go-review.googlesource.com/c/go/+/461315 Run-TryBot: Than McIntosh <thanm@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-02-06cmd/compile: ensure first instruction in a function is not inlinedKeith Randall
People are using this to get the name of the function from a function type: runtime.FuncForPC(reflect.ValueOf(fn).Pointer()).Name() Unfortunately, this technique falls down when the first instruction of the function is from an inlined callee. Then the expression above gets you the name of the inlined function instead of the function itself. To fix this, ensure that the first instruction is never from an inlinee. Normally functions have prologs so those are already fine. In just the cases where a function is a leaf with no local variables, and an instruction from an inlinee appears first in the prog list, add a nop at the start of the function to hold a non-inlined position. Consider the nop a "mini-prolog" for leaf functions. Fixes #58300 Change-Id: Ie37092f4ac3167fe8e5ef4a2207b14abc1786897 Reviewed-on: https://go-review.googlesource.com/c/go/+/465076 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com> Reviewed-by: David Chase <drchase@google.com>
2023-02-06cmd/internal/obj: flag init functions in object fileThan McIntosh
Introduce a flag in the object file indicating whether a given function corresponds to a compiler-generated (not user-written) init function, such as "os.init" or "syscall.init". Add code to the compiler to fill in the correct value for the flag, and add support to the loader package in the linker for testing the flag. The new loader API is currently unused, but will be needed in the next CL in this stack. Updates #2559. Updates #36021. Updates #14840. Change-Id: Iea7ad2adda487e4af7a44f062f9817977c53b394 Reviewed-on: https://go-review.googlesource.com/c/go/+/463855 Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-02-06go/types, types2: eliminate need to sort arguments for type inferenceRobert Griesemer
When unifying types, we always consider underlying types if inference would fail otherwise. If a type parameter has a (non-defined) type inferred and later matches against a defined type, make sure to keep that defined type instead. For #43056. Change-Id: I24e4cd2939df7c8069e505be10914017c1c1c288 Reviewed-on: https://go-review.googlesource.com/c/go/+/464348 Reviewed-by: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com> Auto-Submit: Robert Griesemer <gri@google.com> Run-TryBot: Robert Griesemer <gri@google.com>
2023-02-06cmd/compile: replace os.MkdirTemp with T.TempDirOleksandr Redko
Updates #45402 Change-Id: Ieffd1c8b0b5e4e63024b5be2e1f910fb4411eb94 GitHub-Last-Rev: fa7418c8eb977b7214311e774f9df7a1220a3dfd GitHub-Pull-Request: golang/go#57940 Reviewed-on: https://go-review.googlesource.com/c/go/+/462896 Reviewed-by: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: Keith Randall <khr@golang.org>
2023-02-06cmd/compile: add rules to emit SETBC/R instructions on power10Archana R
This CL adds rules that replaces instances of ISEL that produce a boolean result based on a condition register by SETBC/SETBCR operations. On Power10 these are convereted to SETBC/SETBCR instructions that use one register instead of 3 registers conventionally used by ISEL and hence reduces register pressure. On loops written specifically to exercise such instances of ISEL extensively, a performance improvement of 2.5% is seen on Power10. Also added verification tests to verify correct generation of SETBC/SETBCR instructions on Power10. Change-Id: Ib719897f09d893de40324440a43052dca026e8fa Reviewed-on: https://go-review.googlesource.com/c/go/+/449795 Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Run-TryBot: Archana Ravindar <aravind5@in.ibm.com> Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-02-04cmd/compile: use ONAME node directly from generated hash funcCuong Manh Le
Same as CL 436436, but for hashfor. However, this passes toolstash-check, because the order of compiling functions do not change. Change-Id: Icc7d042e9c28b0fe4bb40a2b98b7f60cf3549bd1 Reviewed-on: https://go-review.googlesource.com/c/go/+/436961 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2023-02-04cmd/compile: factor out code to generate hash funcCuong Manh Le
Passes toolstash-check. Change-Id: I86a078ffc5948cbcbec84ce8012f3dfb1c2269b2 Reviewed-on: https://go-review.googlesource.com/c/go/+/436960 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.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>
2023-02-04cmd/compile: use runtime hash func for known typesCuong Manh Le
Those functions are defined in package runtime already, so just use them instead of creating ONAME nodes with nil Func. Change-Id: If29814a5254793c578c15b70f9c194b7414911d4 Reviewed-on: https://go-review.googlesource.com/c/go/+/436959 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: Keith Randall <khr@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2023-02-04cmd/compile: use memhash from package runtimeCuong Manh Le
Simplify the code, and prevent creating ONAME node with nil Func. Passes toolstash-check. Change-Id: I5e5be660510dc0ef5521d278c6b9214a80b994eb Reviewed-on: https://go-review.googlesource.com/c/go/+/436958 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: Keith Randall <khr@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2023-02-04cmd/compile: generate type equal func during walkCuong Manh Le
So we don't generate ONAME node with nil Func. Do not pass toolstash-check because the CL changes the order of compiling functions. Change-Id: Ib967328f36b8c59a5525445667103c0c80ccdc82 Reviewed-on: https://go-review.googlesource.com/c/go/+/436436 Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2023-02-04cmd/compile: factor out code to generate equal funcCuong Manh Le
So next CL can use it for generating equal func during walk compare. Passes toolstash-check. Change-Id: I76545c1d471eb496be352908db1b05feae83fc33 Reviewed-on: https://go-review.googlesource.com/c/go/+/436435 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2023-02-03cmd/compile: intrinsify math/bits/ReverseBytes{16|32|64} for ppc64/power10Archana R
This change intrinsifies ReverseBytes{16|32|64} by generating the corresponding new instructions in Power10: brh, brd and brw and adds a verification test for the same. On Power 9 and 8, the .go code performs optimally as it is. Performance improvement seen on Power10: ReverseBytes32 1.38ns ± 0% 1.18ns ± 0% -14.2 ReverseBytes64 1.52ns ± 0% 1.11ns ± 0% -26.87 ReverseBytes16 1.41ns ± 1% 1.18ns ± 0% -16.47 Change-Id: I88f127f3ab9ba24a772becc21ad90acfba324b37 Reviewed-on: https://go-review.googlesource.com/c/go/+/446675 Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2023-02-02go/types, types2: enable new type inferenceRobert Griesemer
Enable new type inference and compare result with old inference implementation - the result must be identical in a correct program. Change-Id: Ic802d29fcee744f6f826d5e433a3d0c0e73b68e3 Reviewed-on: https://go-review.googlesource.com/c/go/+/464341 Auto-Submit: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com> Run-TryBot: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com>
2023-02-02go/types, types2: implement simpler type inference (infer2)Robert Griesemer
This change implements infer2 which is a drop-in replacement for infer; it can be enabled by setting the useNewTypeInference flag in infer2.go. It is currently disabled (but tested manually). infer2 uses the same machinery like infer but in a simpler approach that is more amenable to precise description and future extensions. The goal of type inference is to determine a set of (missing) type arguments from a set of other given facts. Currently, these other facts are function arguments and type constraints. In the following, when we refer to "type parameters", we mean the type parameters defined by the generic function to which we apply type inference. More precisely, in the algorithm, these are the type parameters recorded with the unifier. The approach is as follows: - A single unifier is set up which tracks all type parameters and corresponding inferred types. - The unifier is then fed all the facts we have. The order is not relevant (*) except that we use default types of untyped constant arguments only as a last resort, at the end. - We start with all function arguments: for each generic function parameter with a typed function argument, we unify the parameter and function type. - We then unify each type parameter with its type constraint. This step is iterated until nothing changes anymore, because each unification may enable further unification. - If there are any type parameters left without inferred types, and which are used as function parameters with untyped constant arguments, unify them with the default types of those arguments. Because of unification with constraints which themselves may contain type parameters, inferred types may contain type parameters. Thus, in a final step we substitute type parameters for their inferred types until there are no type parameters left in the inferred types. All these individual steps are the same as in infer, but there is no need to do constraint type inference twice (all the facts have already been used for inference). Also, we only need a single unifier which serves as the holder for the inferred type parameter types. Type inference fails if any unification step fails or if not all type arguments could be inferred. By always using all available facts (**) we ensure that order doesn't matter. By using more facts, type inference can now be extended to become more powerful. The code can be split up into smaller components that are more easily digestable. Because we forsee more simplifications, we defer such cleanups to later CLs. (*) We currently have a sorting phase in the beginning such that function argument types that are named types are used before any other type. We believe this step can be eliminated by modifying the unifier slightly. (**) When unifying constraints, in some cases we don't report an error if unification fails. We believe we can modify the unifier and then consistently report an inference failure in this case as well. Change-Id: If1640a5461bc102fa7fd31dc6e741be667c97e7f Reviewed-on: https://go-review.googlesource.com/c/go/+/463746 Reviewed-by: Robert Findley <rfindley@google.com> Run-TryBot: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-02-02go/types, types2: simplify symmetric codeRobert Griesemer
Because unification is symmetric, in cases where we have symmetric code for x and y depending on some property we can swap x and y as needed and simplify the code. Also, change u.depth increment/decrement position for slightly nicer tracing ooutput. Change-Id: I2e84570d463d1c32f6556108f3cb54062b57c718 Reviewed-on: https://go-review.googlesource.com/c/go/+/464896 TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Robert Griesemer <gri@google.com> Run-TryBot: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-by: Robert Findley <rfindley@google.com>
2023-02-02go/types, types2: use a comparer struct to control the identical predicateRobert Griesemer
This makes it easier to configure the behavior of identical: we can simply add fields to the comparer instead of adding more parameters to identical. Change-Id: I9a6f5451b3ee5c37e71486060653c5a6e8f24304 Reviewed-on: https://go-review.googlesource.com/c/go/+/464937 Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Robert Findley <rfindley@google.com> Run-TryBot: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@google.com>
2023-02-02src/cmd/compile: clarify //go:linkname documentationAlan Donovan
Change-Id: I0407950bfc84082683012944b2051e46dc682ba0 Reviewed-on: https://go-review.googlesource.com/c/go/+/463136 Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Alan Donovan <adonovan@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
2023-02-02go/types, types2: avoid recursive invocation when unifying underlying typesRobert Griesemer
There's no need to invoke unifier.nify recursively when we decide to unify underlying types. Just update the respective type variable and continue. Change-Id: I3abe335464786dc509d18651dff14b20022c7d63 Reviewed-on: https://go-review.googlesource.com/c/go/+/464347 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Robert Findley <rfindley@google.com> Run-TryBot: Robert Griesemer <gri@google.com>
2023-02-02go/types, types2: remove (internal) exactUnification flagRobert Griesemer
Neither infer nor infer2 will correctly work if we require exact unification. Remove the flag and simplify the respective code. Change-Id: I329f207f72b6d97fa076f27275481b754e55fecf Reviewed-on: https://go-review.googlesource.com/c/go/+/464346 Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-by: Robert Findley <rfindley@google.com> Run-TryBot: Robert Griesemer <gri@google.com> Auto-Submit: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-02-01cmd/compile/internal/types: remove misleading commentMatthew Dempsky
The runtime's knowledge of these constants was removed in CL 261364. Change-Id: I65e5a5ab084c6301eee1c9791bc76df9b824e466 Reviewed-on: https://go-review.googlesource.com/c/go/+/463754 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-02-01go/types, types2: use go.dev/issue/nnnnn when referring to an issue (cleanup)Robert Griesemer
Follow-up on CL 462856 which missed a few places. Fixed manually. Change-Id: I924560ecae8923d9228027016805a3cc892f8ac2 Reviewed-on: https://go-review.googlesource.com/c/go/+/463749 Reviewed-by: Robert Findley <rfindley@google.com> Reviewed-by: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Robert Griesemer <gri@google.com> Run-TryBot: Robert Griesemer <gri@google.com>
2023-02-01go/types, types2: better error when trying to use ~ as bitwise operationRobert Griesemer
When coming from C, the bitwise integer complement (bitwise negation) operator is ~, but in Go it is ^. Report an error mentioning ^ when ~ is used with an integer operand. Background: Some articles on the web claim that Go doesn't have a bitwise complement operator. Change-Id: I41185cae4a70d528754e44f42c13c013ed91bf27 Reviewed-on: https://go-review.googlesource.com/c/go/+/463747 Auto-Submit: Robert Griesemer <gri@google.com> Run-TryBot: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-by: Robert Findley <rfindley@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-02-01go/types, types2: unifier constructor to accept type parameters and argumentsRobert Griesemer
Change-Id: I2f20cb8f1dd95ba97de7630d0bbe6dee4e019f94 Reviewed-on: https://go-review.googlesource.com/c/go/+/463990 Reviewed-by: Robert Griesemer <gri@google.com> Run-TryBot: Robert Griesemer <gri@google.com> Auto-Submit: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
2023-02-01go/types, types2: further simplify unificationRobert Griesemer
Allocate all handles up-front: in a correct program, all type parameters must be resolved and thus eventually will get a handle. Also, sharing of handles caused by unified type parameters is rare and so it's ok to not optimize for that case (and delay handle allocation). This removes a (premature) optimization whis further simplifies unification. Change-Id: Ie1259b86ea5e966538667ab9557676e9be9f6364 Reviewed-on: https://go-review.googlesource.com/c/go/+/463989 Reviewed-by: Robert Findley <rfindley@google.com> Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com> Run-TryBot: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
generated by cgit v1.3 (git 2.53.0) at 2026-04-15 11:16:50 +0000