summaryrefslogtreecommitdiff
path: root/test
Commit message (Collapse)AuthorAgeFilesLines
* cmd/compile: enable more lenient type inference for untyped argumentsRobert Griesemer2023-05-181-0/+19
| | | | | | | | | | | | | | | | | This enables the implementation for proposal #58671, which is a likely accept. By enabling it early we get a bit extra soak time for this feature. The change can be reverted trivially, if need be. For #58671. Change-Id: Id6c27515e45ff79f4f1d2fc1706f3f672ccdd1ab Reviewed-on: https://go-review.googlesource.com/c/go/+/495955 Run-TryBot: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Robert Findley <rfindley@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* cmd/compile/internal/noder: suppress unionType consistency checkMatthew Dempsky2023-05-161-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | In the types1 universe, we only need to represent value types. For interfaces, this means we only need to worry about pure interfaces. A pure interface can embed a union type, but the overall union must be equivalent to "any". In go.dev/cl/458619, we changed the types1 reader to return "any", but to incorporate a consistency check to make sure this is valid. Unfortunately, a pure interface can actually still reference impure interfaces, and in general this is hard to check precisely without reimplementing a lot of types2 data structures and logic into types1. We haven't had any other reports of this check failing since 1.20, so it seems simplest to just suppress for now. Fixes #60117. Change-Id: I5053faafe2d1068c6d438b2193347546bf5330cd Reviewed-on: https://go-review.googlesource.com/c/go/+/495455 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Auto-Submit: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@google.com>
* cmd/compile: make memcombine pass a bit more robust to reassociation of exprsKeith Randall2023-05-161-0/+26
| | | | | | | | | | | | | | | Be more liberal about expanding the OR tree. Handle any tree shape instead of a fully left or right associative tree. Also remove tail feature, it isn't ever needed. Change-Id: If16bebef94b952a604d6069e9be3d9129994cb6f Reviewed-on: https://go-review.googlesource.com/c/go/+/494056 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Ryan Berger <ryanbberger@gmail.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: David Chase <drchase@google.com>
* cmd/compile: enhance tighten pass for memory valueseric fang2023-05-161-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [This is a roll-forward of CL 458755, which was reverted due to make.bash being broken on GOAMD64=v3. But it turned out that the problem was caused by wrong bswap/load rewrite rules, and it was fixed in CL 492616.] This CL enhances the tighten pass. Previously if a value has memory arg, then the tighten pass won't move it, actually if the memory state is consistent among definition and use block, we can move the value. This CL optimizes this case. This is useful for the following situation: b1: x = load(...mem) if(...) goto b2 else b3 b2: use(x) b3: some_op_not_use_x For the micro-benchmark mentioned in #56620, the performance improvement is about 15%. There's no noticeable performance change in the go1 benchmark. Fixes #56620 Change-Id: I36ea68bed384986cd3ae81cb9e6efe84bb213adc Reviewed-on: https://go-review.googlesource.com/c/go/+/492895 Reviewed-by: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com> Reviewed-by: Keith Randall <khr@google.com> Run-TryBot: Eric Fang <eric.fang@arm.com>
* cmd/compile: update rules to generate more prefixed instructionsLynn Boger2023-05-151-0/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This modifies some existing rules to allow more prefixed instructions to be generated when using GOPPC64=power10. Some rules also check if PCRel is available, which is currently supported for linux/ppc64le and linux/ppc64 (internal linking only). Prior to p10, DS-offset loads and stores had a 16 bit size limit for the offset field. If the offset of the data for load or store was beyond this range then an indexed load or store would be selected by the rules. In p10 the assembler can generate prefixed instructions in this case, but does not if an indexed instruction was selected during the lowering pass. This allows many more cases to use prefixed loads or stores, reducing function sizes and improving performance in some cases where the code change happens in key loops. For example in strconv BenchmarkAppendQuoteRune before: 12c5e4: 15 00 10 06 pla r10,1425660 12c5e8: fc c0 40 39 12c5ec: 00 00 6a e8 ld r3,0(r10) 12c5f0: 10 00 aa e8 ld r5,16(r10) After this change: 12a828: 15 00 10 04 pld r3,1433272 12a82c: b8 de 60 e4 12a830: 15 00 10 04 pld r5,1433280 12a834: c0 de a0 e4 Performs better in the second case. A testcase was added to verify that the rules correctly select a load or store based on the offset and whether power10 or earlier. Change-Id: I4335fed0bd9b8aba8a4f84d69b89f819cc464846 Reviewed-on: https://go-review.googlesource.com/c/go/+/477398 Reviewed-by: Heschi Kreinick <heschi@google.com> Reviewed-by: Archana Ravindar <aravind5@in.ibm.com> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> Reviewed-by: Paul Murphy <murp@ibm.com>
* test: add escape test for reflect.Value operationsCherry Mui2023-05-121-0/+462
| | | | | | | | | | | | | | | | | | With CL 408826 reflect.Value does not always escape. We need to make sure Value operations does (or does not) escape the Value correctly. This CL adds a test. There are still a few unfortunate cases, where some Value operations escape more than necessary (comparing to a non-reflect version of the code), but hard to fix. These are mostly that a Value would escape conditionally (mostly on the type of the Value), but currently we don't have a good way to express that. Change-Id: I9fdfc7584670aa09c5a01f6b2803f2043aaddb65 Reviewed-on: https://go-review.googlesource.com/c/go/+/441938 Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
* reflect: do not escape Value.TypeCherry Mui2023-05-121-2/+2
| | | | | | | | | | | | | | | | | | | Types are either static (for compiler-created types) or heap allocated and always reachable (for reflection-created types, held in the central map). So there is no need to escape types. With CL 408826 reflect.Value does not always escape. Some functions that escapes Value.typ would make the Value escape without this CL. Had to add a special case for the inliner to keep (*Value).Type still inlineable. Change-Id: I7c14d35fd26328347b509a06eb5bd1534d40775f Reviewed-on: https://go-review.googlesource.com/c/go/+/413474 Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* internal/testdir: move to cmd/internal/testdirDmitri Shuralyov2023-05-122-3/+3
| | | | | | | | | | | | | | | | | | The effect and motivation is for the test to be selected when doing 'go test cmd' and not when doing 'go test std' since it's primarily about testing the Go compiler and linker. Other than that, it's run by all.bash and 'go test std cmd' as before. For #56844. Fixes #60059. Change-Id: I2d499af013f9d9b8761fdf4573f8d27d80c1fccf Reviewed-on: https://go-review.googlesource.com/c/go/+/493876 Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
* test/bench: deleteAustin Clements2023-05-1223-3759/+0
| | | | | | | | | | | | | | | | | | | | Russ added test/bench/go1 in CL 5484071 to have a stable suite of programs to use as benchmarks. For the compiler and runtime we had back then, those were reasonable benchmarks, but the compiler and runtime are now far more sophisticated and these benchmarks no longer have good coverage. We also now have better benchmark suites maintained outside the repo (e.g., golang.org/x/benchmarks). Keeping test/bench/go1 at this point is actively misleading. Indirectly related to #37486, as this also removes the last package dist test runs outside of src/. Change-Id: I2867ef303fe48a02acce58ace4ee682add8acdbf Reviewed-on: https://go-review.googlesource.com/c/go/+/494193 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Russ Cox <rsc@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
* test,internal/testdir: don't set GOOS/GOARCHAustin Clements2023-05-121-5/+8
| | | | | | | | | | | | | | | | | | The test directory driver currently sets the GOOS/GOARCH environment variables if they aren't set. This appears to be in service of a single test, test/env.go, which was introduced in September 2008 along with os.Getenv. It's not entirely clear what that test is even trying to check, since runtime.GOOS isn't necessarily the same as $GOOS. We keep the test around because golang.org/x/tools/go/ssa/interp uses it as a test case, but we simplify the test and eliminate the need for the driver to set GOOS/GOARCH. Change-Id: I5acc0093b557c95d1f0a526d031210256a68222d Reviewed-on: https://go-review.googlesource.com/c/go/+/493601 Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Bryan Mills <bcmills@google.com>
* cmd/compile: add De Morgan's rewrite ruleStefan2023-05-101-0/+14
| | | | | | | | | | | | | | | Adds rules that rewrites statements such as ~P&~Q as ~(P|Q) and ~P|~Q as ~(P&Q), removing an extraneous instruction. Change-Id: Icedb97df741680ddf9799df79df78657173aa500 GitHub-Last-Rev: f22e2350c95e9052e990b2351c3c2b0af810e381 GitHub-Pull-Request: golang/go#60018 Reviewed-on: https://go-review.googlesource.com/c/go/+/493175 Reviewed-by: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Stefan M <st3f4nm4d4@gmail.com> Reviewed-by: Keith Randall <khr@google.com> Run-TryBot: Cherry Mui <cherryyz@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
* test: add memcombine testcases for ppc64Lynn Boger2023-05-081-4/+95
| | | | | | | | | | | | | | | | | | | | | | Thanks to the recent addition of the memcombine pass, the ppc64 ports now have the memcombine optimizations. Previously in PPC64.rules, the memcombine rules were only added for ppc64le targets due to the significant increase in size of the rewritePPC64.go file when those rules were added. The ppc64 and ppc64le rules had to be different because of the byte order due to endianness differences. This enables the memcombine tests to be run on ppc64 as well as ppc64le. Change-Id: I4081e2d94617a1b66541d536c0c2662e266c9c1e Reviewed-on: https://go-review.googlesource.com/c/go/+/492615 Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Auto-Submit: Lynn Boger <laboger@linux.vnet.ibm.com>
* math: optimize math.Abs on mipsxJunxian Zhu2023-05-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit optimized math.Abs function implementation on mipsx. Tested on loongson 3A2000. goos: linux goarch: mipsle pkg: math │ oldmath │ newmath │ │ sec/op │ sec/op vs base │ Acos-4 282.6n ± 0% 282.3n ± 0% ~ (p=0.140 n=7) Acosh-4 506.1n ± 0% 451.8n ± 0% -10.73% (p=0.001 n=7) Asin-4 272.3n ± 0% 272.2n ± 0% ~ (p=0.808 n=7) Asinh-4 529.7n ± 0% 475.3n ± 0% -10.27% (p=0.001 n=7) Atan-4 208.2n ± 0% 207.9n ± 0% ~ (p=0.134 n=7) Atanh-4 503.4n ± 1% 449.7n ± 0% -10.67% (p=0.001 n=7) Atan2-4 310.5n ± 0% 310.5n ± 0% ~ (p=0.928 n=7) Cbrt-4 359.3n ± 0% 358.8n ± 0% ~ (p=0.121 n=7) Ceil-4 203.9n ± 0% 204.0n ± 0% ~ (p=0.600 n=7) Compare-4 23.11n ± 0% 23.11n ± 0% ~ (p=0.702 n=7) Compare32-4 19.09n ± 0% 19.12n ± 0% ~ (p=0.070 n=7) Copysign-4 33.20n ± 0% 34.02n ± 0% +2.47% (p=0.001 n=7) Cos-4 422.5n ± 0% 385.4n ± 1% -8.78% (p=0.001 n=7) Cosh-4 628.0n ± 0% 545.5n ± 0% -13.14% (p=0.001 n=7) Erf-4 193.7n ± 2% 192.7n ± 1% ~ (p=0.430 n=7) Erfc-4 192.8n ± 1% 193.0n ± 0% ~ (p=0.245 n=7) Erfinv-4 220.7n ± 1% 221.5n ± 2% ~ (p=0.272 n=7) Erfcinv-4 221.3n ± 1% 220.4n ± 2% ~ (p=0.738 n=7) Exp-4 471.4n ± 0% 435.1n ± 0% -7.70% (p=0.001 n=7) ExpGo-4 470.6n ± 0% 434.0n ± 0% -7.78% (p=0.001 n=7) Expm1-4 243.1n ± 0% 243.4n ± 0% ~ (p=0.417 n=7) Exp2-4 463.1n ± 0% 427.0n ± 0% -7.80% (p=0.001 n=7) Exp2Go-4 462.4n ± 0% 426.2n ± 5% -7.83% (p=0.001 n=7) Abs-4 37.000n ± 0% 8.039n ± 9% -78.27% (p=0.001 n=7) Dim-4 18.09n ± 0% 18.11n ± 0% ~ (p=0.094 n=7) Floor-4 151.9n ± 0% 151.8n ± 0% ~ (p=0.190 n=7) Max-4 116.7n ± 1% 116.7n ± 1% ~ (p=0.842 n=7) Min-4 116.6n ± 1% 116.6n ± 0% ~ (p=0.464 n=7) Mod-4 1244.0n ± 0% 980.9n ± 0% -21.15% (p=0.001 n=7) Frexp-4 199.0n ± 0% 146.7n ± 0% -26.28% (p=0.001 n=7) Gamma-4 516.4n ± 0% 479.3n ± 1% -7.18% (p=0.001 n=7) Hypot-4 169.8n ± 0% 117.8n ± 2% -30.62% (p=0.001 n=7) HypotGo-4 170.8n ± 0% 117.5n ± 0% -31.21% (p=0.001 n=7) Ilogb-4 160.8n ± 0% 109.5n ± 0% -31.90% (p=0.001 n=7) J0-4 1.359µ ± 0% 1.305µ ± 0% -3.97% (p=0.001 n=7) J1-4 1.386µ ± 0% 1.334µ ± 0% -3.75% (p=0.001 n=7) Jn-4 2.864µ ± 0% 2.758µ ± 0% -3.70% (p=0.001 n=7) Ldexp-4 202.9n ± 0% 151.7n ± 0% -25.23% (p=0.001 n=7) Lgamma-4 234.0n ± 0% 234.3n ± 0% ~ (p=0.199 n=7) Log-4 444.1n ± 0% 407.9n ± 0% -8.15% (p=0.001 n=7) Logb-4 157.8n ± 0% 121.6n ± 0% -22.94% (p=0.001 n=7) Log1p-4 354.8n ± 0% 315.4n ± 0% -11.10% (p=0.001 n=7) Log10-4 453.9n ± 0% 417.9n ± 0% -7.93% (p=0.001 n=7) Log2-4 245.3n ± 0% 209.1n ± 0% -14.76% (p=0.001 n=7) Modf-4 126.6n ± 0% 126.6n ± 0% ~ (p=0.126 n=7) Nextafter32-4 112.5n ± 0% 112.5n ± 0% ~ (p=0.853 n=7) Nextafter64-4 141.7n ± 0% 141.6n ± 0% ~ (p=0.331 n=7) PowInt-4 878.8n ± 1% 758.3n ± 1% -13.71% (p=0.001 n=7) PowFrac-4 1.809µ ± 0% 1.615µ ± 0% -10.72% (p=0.001 n=7) Pow10Pos-4 18.10n ± 0% 18.12n ± 0% ~ (p=0.464 n=7) Pow10Neg-4 17.09n ± 0% 17.09n ± 0% ~ (p=0.263 n=7) Round-4 68.36n ± 0% 68.33n ± 0% ~ (p=0.325 n=7) RoundToEven-4 78.40n ± 0% 78.40n ± 0% ~ (p=0.934 n=7) Remainder-4 894.0n ± 1% 753.4n ± 1% -15.73% (p=0.001 n=7) Signbit-4 18.09n ± 0% 18.09n ± 0% ~ (p=0.761 n=7) Sin-4 389.8n ± 1% 389.8n ± 0% ~ (p=0.995 n=7) Sincos-4 416.0n ± 0% 415.9n ± 0% ~ (p=0.361 n=7) Sinh-4 634.6n ± 4% 585.6n ± 1% -7.72% (p=0.001 n=7) SqrtIndirect-4 8.035n ± 0% 8.036n ± 0% ~ (p=0.523 n=7) SqrtLatency-4 8.039n ± 0% 8.037n ± 0% ~ (p=0.218 n=7) SqrtIndirectLatency-4 8.040n ± 0% 8.040n ± 0% ~ (p=0.652 n=7) SqrtGoLatency-4 895.7n ± 0% 896.6n ± 0% +0.10% (p=0.004 n=7) SqrtPrime-4 5.406µ ± 0% 5.407µ ± 0% ~ (p=0.592 n=7) Tan-4 406.1n ± 0% 405.8n ± 1% ~ (p=0.435 n=7) Tanh-4 627.6n ± 0% 545.5n ± 0% -13.08% (p=0.001 n=7) Trunc-4 146.7n ± 1% 146.7n ± 0% ~ (p=0.755 n=7) Y0-4 1.359µ ± 0% 1.310µ ± 0% -3.61% (p=0.001 n=7) Y1-4 1.351µ ± 0% 1.301µ ± 0% -3.70% (p=0.001 n=7) Yn-4 2.829µ ± 0% 2.729µ ± 0% -3.53% (p=0.001 n=7) Float64bits-4 14.08n ± 0% 14.07n ± 0% ~ (p=0.069 n=7) Float64frombits-4 19.09n ± 0% 19.10n ± 0% ~ (p=0.755 n=7) Float32bits-4 13.06n ± 0% 13.07n ± 1% ~ (p=0.586 n=7) Float32frombits-4 13.06n ± 0% 13.06n ± 0% ~ (p=0.853 n=7) FMA-4 606.9n ± 0% 606.8n ± 0% ~ (p=0.393 n=7) geomean 201.1n 185.4n -7.81% Change-Id: I6d41a97ad3789ed5731588588859ac0b8b13b664 Reviewed-on: https://go-review.googlesource.com/c/go/+/484675 Reviewed-by: Rong Zhang <rongrong@oss.cipunited.com> Reviewed-by: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Than McIntosh <thanm@google.com>
* cmd/compile: allow more inlining of functions that construct closuresThan McIntosh2023-05-051-11/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [This is a roll-forward of CL 479095, which was reverted due to a bad interaction between inlining and escape analysis, then later fixed first with an attempt in CL 482355, then again in CL 484859, and then one more time with CL 492135.] Currently, when the inliner is determining if a function is inlineable, it descends into the bodies of closures constructed by that function. This has several unfortunate consequences: - If the closure contains a disallowed operation (e.g., a defer), then the outer function can't be inlined. It makes sense that the *closure* can't be inlined in this case, but it doesn't make sense to punish the function that constructs the closure. - The hairiness of the closure counts against the inlining budget of the outer function. Since we currently copy the closure body when inlining the outer function, this makes sense from the perspective of export data size and binary size, but ultimately doesn't make much sense from the perspective of what should be inlineable. - Since the inliner walks into every closure created by an outer function in addition to starting a walk at every closure, this adds an n^2 factor to inlinability analysis. This CL simply drops this behavior. In std, this makes 57 more functions inlinable, and disallows inlining for 10 (due to the basic instability of our bottom-up inlining approach), for an net increase of 47 inlinable functions (+0.6%). This will help significantly with the performance of the functions to be added for #56102, which have a somewhat complicated nesting of closures with a performance-critical fast path. The downside of this seems to be a potential increase in export data and text size, but the practical impact of this seems to be negligible: │ before │ after │ │ bytes │ bytes vs base │ Go/binary 15.12Mi ± 0% 15.14Mi ± 0% +0.16% (n=1) Go/text 5.220Mi ± 0% 5.237Mi ± 0% +0.32% (n=1) Compile/binary 22.92Mi ± 0% 22.94Mi ± 0% +0.07% (n=1) Compile/text 8.428Mi ± 0% 8.435Mi ± 0% +0.08% (n=1) Change-Id: I5f75fcceb177f05853996b75184a486528eafe96 Reviewed-on: https://go-review.googlesource.com/c/go/+/492017 Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Than McIntosh <thanm@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
* cmd/compile: un-hide closure func if parent expr moved to staticinitThan McIntosh2023-05-051-0/+100
| | | | | | | | | | | | | | | | | | If the function referenced by a closure expression is incorporated into a static init, be sure to mark it as non-hidden, since otherwise it will be live but no longer reachable from the init func, hence it will be skipped during escape analysis, which can lead to miscompilations. Fixes #59680. Change-Id: Ib858aee296efcc0b7655d25c23ab8a6a8dbdc5f9 Reviewed-on: https://go-review.googlesource.com/c/go/+/492135 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Than McIntosh <thanm@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
* cmd/compile: rework marking of dead hidden closure functionsThan McIntosh2023-05-057-0/+202
| | | | | | | | | | | | | | | | | | | | [This is a roll-forward of CL 484859, this time including a fix for issue #59709. The call to do dead function marking was taking place in the wrong spot, causing it to run more than once if generics were instantiated.] This patch generalizes the code in the inliner that marks unreferenced hidden closure functions as dead. Rather than doing the marking on the fly (previous approach), this new approach does a single pass at the end of inlining, which catches more dead functions. Change-Id: I0e079ad755c21295477201acbd7e1a732a98fffd Reviewed-on: https://go-review.googlesource.com/c/go/+/492016 Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Run-TryBot: Than McIntosh <thanm@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
* math: optimize math.Abs on mips64xJunxian Zhu2023-05-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit optimized math.Abs function implementation on mips64x. Tested on loongson 3A2000. goos: linux goarch: mips64le pkg: math │ oldmath │ newmath │ │ sec/op │ sec/op vs base │ Acos-4 258.0n ± ∞ ¹ 257.1n ± ∞ ¹ -0.35% (p=0.008 n=5) Acosh-4 417.0n ± ∞ ¹ 377.9n ± ∞ ¹ -9.38% (p=0.008 n=5) Asin-4 248.0n ± ∞ ¹ 259.9n ± ∞ ¹ +4.80% (p=0.008 n=5) Asinh-4 439.6n ± ∞ ¹ 408.3n ± ∞ ¹ -7.12% (p=0.008 n=5) Atan-4 189.6n ± ∞ ¹ 188.8n ± ∞ ¹ ~ (p=0.056 n=5) Atanh-4 390.0n ± ∞ ¹ 356.4n ± ∞ ¹ -8.62% (p=0.008 n=5) Atan2-4 279.0n ± ∞ ¹ 263.9n ± ∞ ¹ -5.41% (p=0.008 n=5) Cbrt-4 314.2n ± ∞ ¹ 322.3n ± ∞ ¹ +2.58% (p=0.008 n=5) Ceil-4 139.7n ± ∞ ¹ 136.6n ± ∞ ¹ -2.22% (p=0.008 n=5) Compare-4 21.11n ± ∞ ¹ 21.09n ± ∞ ¹ ~ (p=0.405 n=5) Compare32-4 20.10n ± ∞ ¹ 20.12n ± ∞ ¹ ~ (p=0.206 n=5) Copysign-4 32.17n ± ∞ ¹ 35.71n ± ∞ ¹ +11.00% (p=0.008 n=5) Cos-4 222.8n ± ∞ ¹ 169.8n ± ∞ ¹ -23.79% (p=0.008 n=5) Cosh-4 550.2n ± ∞ ¹ 477.4n ± ∞ ¹ -13.23% (p=0.008 n=5) Erf-4 171.6n ± ∞ ¹ 174.5n ± ∞ ¹ ~ (p=0.635 n=5) Erfc-4 182.6n ± ∞ ¹ 170.2n ± ∞ ¹ -6.79% (p=0.008 n=5) Erfinv-4 177.6n ± ∞ ¹ 196.6n ± ∞ ¹ +10.70% (p=0.008 n=5) Erfcinv-4 177.8n ± ∞ ¹ 197.8n ± ∞ ¹ +11.25% (p=0.008 n=5) Exp-4 422.8n ± ∞ ¹ 382.1n ± ∞ ¹ -9.63% (p=0.008 n=5) ExpGo-4 416.1n ± ∞ ¹ 383.2n ± ∞ ¹ -7.91% (p=0.008 n=5) Expm1-4 232.9n ± ∞ ¹ 252.2n ± ∞ ¹ +8.29% (p=0.008 n=5) Exp2-4 404.8n ± ∞ ¹ 389.1n ± ∞ ¹ -3.88% (p=0.008 n=5) Exp2Go-4 407.0n ± ∞ ¹ 372.3n ± ∞ ¹ -8.53% (p=0.008 n=5) Abs-4 30.120n ± ∞ ¹ 3.014n ± ∞ ¹ -89.99% (p=0.008 n=5) Dim-4 5.021n ± ∞ ¹ 5.023n ± ∞ ¹ ~ (p=0.071 n=5) Floor-4 127.8n ± ∞ ¹ 127.1n ± ∞ ¹ -0.55% (p=0.008 n=5) Max-4 77.69n ± ∞ ¹ 76.33n ± ∞ ¹ -1.75% (p=0.008 n=5) Min-4 83.27n ± ∞ ¹ 77.87n ± ∞ ¹ -6.48% (p=0.008 n=5) Mod-4 906.2n ± ∞ ¹ 692.9n ± ∞ ¹ -23.54% (p=0.008 n=5) Frexp-4 150.6n ± ∞ ¹ 108.6n ± ∞ ¹ -27.89% (p=0.008 n=5) Gamma-4 418.4n ± ∞ ¹ 386.1n ± ∞ ¹ -7.72% (p=0.008 n=5) Hypot-4 148.20n ± ∞ ¹ 93.78n ± ∞ ¹ -36.72% (p=0.008 n=5) HypotGo-4 148.20n ± ∞ ¹ 94.47n ± ∞ ¹ -36.26% (p=0.008 n=5) Ilogb-4 135.50n ± ∞ ¹ 92.38n ± ∞ ¹ -31.82% (p=0.008 n=5) J0-4 937.7n ± ∞ ¹ 861.7n ± ∞ ¹ -8.10% (p=0.008 n=5) J1-4 915.4n ± ∞ ¹ 875.9n ± ∞ ¹ -4.32% (p=0.008 n=5) Jn-4 1.974µ ± ∞ ¹ 1.863µ ± ∞ ¹ -5.62% (p=0.008 n=5) Ldexp-4 158.5n ± ∞ ¹ 129.3n ± ∞ ¹ -18.42% (p=0.008 n=5) Lgamma-4 209.0n ± ∞ ¹ 211.8n ± ∞ ¹ ~ (p=0.095 n=5) Log-4 326.4n ± ∞ ¹ 295.2n ± ∞ ¹ -9.56% (p=0.008 n=5) Logb-4 147.7n ± ∞ ¹ 105.0n ± ∞ ¹ -28.91% (p=0.008 n=5) Log1p-4 303.4n ± ∞ ¹ 266.3n ± ∞ ¹ -12.23% (p=0.008 n=5) Log10-4 329.2n ± ∞ ¹ 298.3n ± ∞ ¹ -9.39% (p=0.008 n=5) Log2-4 187.4n ± ∞ ¹ 153.0n ± ∞ ¹ -18.36% (p=0.008 n=5) Modf-4 110.5n ± ∞ ¹ 103.5n ± ∞ ¹ -6.33% (p=0.008 n=5) Nextafter32-4 128.4n ± ∞ ¹ 121.5n ± ∞ ¹ -5.37% (p=0.016 n=5) Nextafter64-4 109.5n ± ∞ ¹ 110.5n ± ∞ ¹ +0.91% (p=0.008 n=5) PowInt-4 603.3n ± ∞ ¹ 516.4n ± ∞ ¹ -14.40% (p=0.008 n=5) PowFrac-4 1.365µ ± ∞ ¹ 1.183µ ± ∞ ¹ -13.33% (p=0.008 n=5) Pow10Pos-4 15.07n ± ∞ ¹ 15.07n ± ∞ ¹ ~ (p=0.738 n=5) Pow10Neg-4 21.11n ± ∞ ¹ 21.10n ± ∞ ¹ ~ (p=0.190 n=5) Round-4 44.23n ± ∞ ¹ 44.22n ± ∞ ¹ ~ (p=0.635 n=5) RoundToEven-4 50.25n ± ∞ ¹ 46.27n ± ∞ ¹ -7.92% (p=0.008 n=5) Remainder-4 675.6n ± ∞ ¹ 530.4n ± ∞ ¹ -21.49% (p=0.008 n=5) Signbit-4 17.07n ± ∞ ¹ 17.95n ± ∞ ¹ +5.16% (p=0.008 n=5) Sin-4 171.6n ± ∞ ¹ 189.1n ± ∞ ¹ +10.20% (p=0.008 n=5) Sincos-4 201.5n ± ∞ ¹ 200.5n ± ∞ ¹ ~ (p=0.421 n=5) Sinh-4 529.6n ± ∞ ¹ 484.6n ± ∞ ¹ -8.50% (p=0.008 n=5) SqrtIndirect-4 5.021n ± ∞ ¹ 5.023n ± ∞ ¹ +0.04% (p=0.048 n=5) SqrtLatency-4 8.032n ± ∞ ¹ 8.039n ± ∞ ¹ +0.09% (p=0.024 n=5) SqrtIndirectLatency-4 8.036n ± ∞ ¹ 8.038n ± ∞ ¹ ~ (p=0.056 n=5) SqrtGoLatency-4 338.8n ± ∞ ¹ 338.7n ± ∞ ¹ ~ (p=0.841 n=5) SqrtPrime-4 5.379µ ± ∞ ¹ 5.382µ ± ∞ ¹ +0.06% (p=0.048 n=5) Tan-4 182.7n ± ∞ ¹ 191.8n ± ∞ ¹ +4.98% (p=0.008 n=5) Tanh-4 558.7n ± ∞ ¹ 497.6n ± ∞ ¹ -10.94% (p=0.008 n=5) Trunc-4 122.5n ± ∞ ¹ 122.6n ± ∞ ¹ ~ (p=0.405 n=5) Y0-4 892.8n ± ∞ ¹ 851.7n ± ∞ ¹ -4.60% (p=0.008 n=5) Y1-4 887.2n ± ∞ ¹ 863.2n ± ∞ ¹ -2.71% (p=0.008 n=5) Yn-4 1.889µ ± ∞ ¹ 1.832µ ± ∞ ¹ -3.02% (p=0.008 n=5) Float64bits-4 13.05n ± ∞ ¹ 13.06n ± ∞ ¹ +0.08% (p=0.040 n=5) Float64frombits-4 13.05n ± ∞ ¹ 13.06n ± ∞ ¹ ~ (p=0.143 n=5) Float32bits-4 13.05n ± ∞ ¹ 13.06n ± ∞ ¹ +0.08% (p=0.008 n=5) Float32frombits-4 13.05n ± ∞ ¹ 13.08n ± ∞ ¹ +0.23% (p=0.016 n=5) FMA-4 445.7n ± ∞ ¹ 448.1n ± ∞ ¹ +0.54% (p=0.008 n=5) geomean 157.2n 142.8n -9.17% Change-Id: I9bf104848b588c9ecf79401a81d483d7fcdb0a79 Reviewed-on: https://go-review.googlesource.com/c/go/+/481575 Reviewed-by: M Zhuo <mzh@golangcn.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Auto-Submit: Than McIntosh <thanm@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Than McIntosh <thanm@google.com> Reviewed-by: Rong Zhang <rongrong@oss.cipunited.com>
* cmd/compile: fix compilation of inferred type argumentsMatthew Dempsky2023-05-031-9/+7
| | | | | | | | | | | | | | | | | | Previously, type arguments could only be inferred for generic functions in call expressions, whereas with the reverse type inference proposal they can now be inferred in assignment contexts too. As a consequence, we now need to check Info.Instances to find the inferred type for more cases now. Updates #59338. Fixes #59955. Change-Id: I9b6465395869459c2387d0424febe7337b28b90e Reviewed-on: https://go-review.googlesource.com/c/go/+/492455 Auto-Submit: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com>
* Revert "cmd/compile: enhance tighten pass for memory values"Daniel Martí2023-05-031-22/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts CL 458755. Reason for revert: broke make.bash on GOAMD64=v3: /workdir/go/src/crypto/sha1/sha1.go:54:35: internal compiler error: '(*digest).MarshalBinary': func (*digest).MarshalBinary, startMem[b13] has different values, old v206, new v338 goroutine 34 [running]: runtime/debug.Stack() /workdir/go/src/runtime/debug/stack.go:24 +0x9f bootstrap/cmd/compile/internal/base.FatalfAt({0x13, 0xaa0f1}, {0xc000db4440, 0x40}, {0xc0013b0000, 0x5, 0x5}) /workdir/go/src/cmd/compile/internal/base/print.go:234 +0x2d1 bootstrap/cmd/compile/internal/base.Fatalf(...) /workdir/go/src/cmd/compile/internal/base/print.go:203 bootstrap/cmd/compile/internal/ssagen.(*ssafn).Fatalf(0xc000d90000, {0x13, 0xaa0f1}, {0xcb7b91, 0x3a}, {0xc000d99bc0, 0x4, 0x4}) /workdir/go/src/cmd/compile/internal/ssagen/ssa.go:7896 +0x1f8 bootstrap/cmd/compile/internal/ssa.(*Func).Fatalf(0xc000d82340, {0xcb7b91, 0x3a}, {0xc000d99bc0, 0x4, 0x4}) /workdir/go/src/cmd/compile/internal/ssa/func.go:716 +0x342 bootstrap/cmd/compile/internal/ssa.memState(0xc000d82340, {0xc000ec6200, 0x22, 0x40}, {0xc001046000, 0x22, 0x40}) /workdir/go/src/cmd/compile/internal/ssa/tighten.go:240 +0x6c5 bootstrap/cmd/compile/internal/ssa.tighten(0xc000d82340) [...] Change-Id: Ic445fb48fe0f2c60ac67abe259b66594f1419152 Reviewed-on: https://go-review.googlesource.com/c/go/+/492335 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: David Chase <drchase@google.com>
* cmd/compile: enhance tighten pass for memory valueserifan012023-05-031-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This CL enhances the tighten pass. Previously if a value has memory arg, then the tighten pass won't move it, actually if the memory state is consistent among definition and use block, we can move the value. This CL optimizes this case. This is useful for the following situation: b1: x = load(...mem) if(...) goto b2 else b3 b2: use(x) b3: some_op_not_use_x For the micro-benchmark mentioned in #56620, the performance improvement is about 15%. There's no noticeable performance change in the go1 benchmark. Fixes #56620 Change-Id: I9b152754f27231f583a6995fc7cd8472aa7d390c Reviewed-on: https://go-review.googlesource.com/c/go/+/458755 TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@google.com> Run-TryBot: Keith Randall <khr@golang.org>
* cmd/compile: enable reverse type inferenceRobert Griesemer2023-05-031-0/+39
| | | | | | | | | | | | For #59338. Change-Id: I8141d421cdc60e47ee5794fc1ca81246bd8a8a25 Reviewed-on: https://go-review.googlesource.com/c/go/+/491475 Reviewed-by: Robert Findley <rfindley@google.com> Auto-Submit: Robert Griesemer <gri@google.com> Run-TryBot: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* cmd/link: put zero-sized data symbols at same address as runtime.zerobaseCherry Mui2023-04-281-0/+33
| | | | | | | | | | | | Put zero-sized data symbols at same address as runtime.zerobase, so zero-sized global variables have the same address as zero-sized allocations. Change-Id: Ib3145dc1b663a9794dfabc0e6abd2384960f2c49 Reviewed-on: https://go-review.googlesource.com/c/go/+/490435 Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
* runtime, cmd: rationalize StackLimit and StackGuardAustin Clements2023-04-211-10/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current definitions of StackLimit and StackGuard only indirectly specify the NOSPLIT stack limit and duplicate a literal constant (928). Currently, they define the stack guard delta, and from there compute the NOSPLIT limit. Rationalize these by defining a new constant, abi.StackNosplitBase, which consolidates and directly specifies the NOSPLIT stack limit (in the default case). From this we then compute the stack guard delta, inverting the relationship between these two constants. While we're here, we rename StackLimit to StackNosplit to make it clearer what's being limited. This change does not affect the values of these constants in the default configuration. It does slightly change how StackGuardMultiplier values other than 1 affect the constants, but this multiplier is a pretty rough heuristic anyway. before after stackNosplit 800 800 _StackGuard 928 928 stackNosplit -race 1728 1600 _StackGuard -race 1856 1728 For #59670. Change-Id: Ia94094c5e47897e7c088d24b4a5e33f5c2768db5 Reviewed-on: https://go-review.googlesource.com/c/go/+/486976 Auto-Submit: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* Revert "runtime, cmd: rationalize StackLimit and StackGuard"Austin Clements2023-04-201-3/+10
| | | | | | | | | | | This reverts commit CL 486380. Submitted out of order and breaks bootstrap. Change-Id: I67bd225094b5c9713b97f70feba04d2c99b7da76 Reviewed-on: https://go-review.googlesource.com/c/go/+/486916 Reviewed-by: David Chase <drchase@google.com> TryBot-Bypass: Austin Clements <austin@google.com>
* runtime, cmd: rationalize StackLimit and StackGuardAustin Clements2023-04-201-10/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current definitions of StackLimit and StackGuard only indirectly specify the NOSPLIT stack limit and duplicate a literal constant (928). Currently, they define the stack guard delta, and from there compute the NOSPLIT limit. Rationalize these by defining a new constant, abi.StackNosplitBase, which consolidates and directly specifies the NOSPLIT stack limit (in the default case). From this we then compute the stack guard delta, inverting the relationship between these two constants. While we're here, we rename StackLimit to StackNosplit to make it clearer what's being limited. This change does not affect the values of these constants in the default configuration. It does slightly change how StackGuardMultiplier values other than 1 affect the constants, but this multiplier is a pretty rough heuristic anyway. before after stackNosplit 800 800 _StackGuard 928 928 stackNosplit -race 1728 1600 _StackGuard -race 1856 1728 For #59670. Change-Id: Ibe20825ebe0076bbd7b0b7501177b16c9dbcb79e Reviewed-on: https://go-review.googlesource.com/c/go/+/486380 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* cmd/compile/internal/types2: only mark variables as used if they areRobert Griesemer2023-04-193-3/+3
| | | | | | | | | | | | | | | | | | | Marking variables in erroneous variable declarations as used is convenient for tests but doesn't necessarily hide follow-on errors in real code: either the variable is not supposed to be declared in the first place and then we should get an error if it is not used, or it is there because it is intended to be used, and the we expect an error it if is not used. This brings types2 closer to go/types. Change-Id: If7ee1298fc770f7ad0cefe7e968533fd50ec2343 Reviewed-on: https://go-review.googlesource.com/c/go/+/486175 Run-TryBot: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Robert Findley <rfindley@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* cmd/compile: remove memequal call from string compares in more casesKeith Randall2023-04-181-0/+41
| | | | | | | | | | | | | | | | | Add more rules to ensure that order doesn't matter. Add memequal 0 rule. Try to use a constant argument to memequal when one is available. Fixes #59684 Change-Id: I36e85ffbd949396ed700ed6e8ec2bc3ae013f5d2 Reviewed-on: https://go-review.googlesource.com/c/go/+/485535 Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
* Revert "cmd/compile: rework marking of dead hidden closure functions"Than McIntosh2023-04-181-65/+0
| | | | | | | | | | | | | This reverts commit http://go.dev/cl//484859 Reason for revert: causes linker errors in a number of google-internal tests. Change-Id: I322252f784a46d2b1d447ebcdca86ce14bc0cc91 Reviewed-on: https://go-review.googlesource.com/c/go/+/485755 Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Than McIntosh <thanm@google.com>
* Revert "cmd/compile: allow more inlining of functions that construct closures"Michael Knyszek2023-04-171-15/+11
| | | | | | | | | | | | | | This reverts commit f8162a0e726f4b3a9df60a37e8ca7883dde61914. Reason for revert: https://github.com/golang/go/issues/59680 Change-Id: I91821c691a2d019ff0ad5b69509e32f3d56b8f67 Reviewed-on: https://go-review.googlesource.com/c/go/+/485498 Reviewed-by: Russ Cox <rsc@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Michael Knyszek <mknyszek@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Auto-Submit: Michael Knyszek <mknyszek@google.com>
* cmd/compile: allow more inlining of functions that construct closuresThan McIntosh2023-04-171-11/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [This is a roll-forward of CL 479095, which was reverted due to a bad interaction between inlining and escape analysis, then later fixed fist with an attempt in CL 482355, then again in 484859 .] Currently, when the inliner is determining if a function is inlineable, it descends into the bodies of closures constructed by that function. This has several unfortunate consequences: - If the closure contains a disallowed operation (e.g., a defer), then the outer function can't be inlined. It makes sense that the *closure* can't be inlined in this case, but it doesn't make sense to punish the function that constructs the closure. - The hairiness of the closure counts against the inlining budget of the outer function. Since we currently copy the closure body when inlining the outer function, this makes sense from the perspective of export data size and binary size, but ultimately doesn't make much sense from the perspective of what should be inlineable. - Since the inliner walks into every closure created by an outer function in addition to starting a walk at every closure, this adds an n^2 factor to inlinability analysis. This CL simply drops this behavior. In std, this makes 57 more functions inlinable, and disallows inlining for 10 (due to the basic instability of our bottom-up inlining approach), for an net increase of 47 inlinable functions (+0.6%). This will help significantly with the performance of the functions to be added for #56102, which have a somewhat complicated nesting of closures with a performance-critical fast path. The downside of this seems to be a potential increase in export data and text size, but the practical impact of this seems to be negligible: │ before │ after │ │ bytes │ bytes vs base │ Go/binary 15.12Mi ± 0% 15.14Mi ± 0% +0.16% (n=1) Go/text 5.220Mi ± 0% 5.237Mi ± 0% +0.32% (n=1) Compile/binary 22.92Mi ± 0% 22.94Mi ± 0% +0.07% (n=1) Compile/text 8.428Mi ± 0% 8.435Mi ± 0% +0.08% (n=1) Updates #56102. Change-Id: I6e938d596992ffb473cf51e7e598f372ce08deb0 Reviewed-on: https://go-review.googlesource.com/c/go/+/484860 Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
* cmd/compile: rework marking of dead hidden closure functionsThan McIntosh2023-04-171-0/+65
| | | | | | | | | | | | | | | | | | This patch generalizes the code in the inliner that marks unreferenced hidden closure functions as dead. Rather than doing the marking on the fly (previous approach), this new approach does a single pass at the end of inlining, which catches more dead functions. Fixes #59638. Updates #59404. Updates #59547. Change-Id: I54fd63e9e37c9123b08a3e7def7d1989919bba91 Reviewed-on: https://go-review.googlesource.com/c/go/+/484859 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* cmd/compile: better code generation for constant-fold switchCuong Manh Le2023-04-141-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CL 399694 added constant-fold switch early in compilation. So function: func f() string { switch intSize { case 32: return "32" case 64: return "64" default: panic("unreachable") } } will be constant-fold to: func f() string { switch intSize { case 64: return "64" } } When this function get inlined, there is a check whether we can delay declaring the result parameter until the "return" statement. For the original function, we can't delay the result, because there's more than one return statement. However, the constant-fold one can, because there's on one return statement in the body now. The result parameter ~R0 ends up declaring inside the switch statement scope. Now, when walking the switch statement, it's re-written into if-else statement. Without typecheck.EvalConst, the if condition "if 64 == 64" is passed as-is to the ssa generation pass. Because "64 == 64" is not a constant, the ssagen creates normal blocks for branching the results. This confuses the liveness analysis, because ~R0 is only live inside the if block. With typecheck.EvalConst, "64 == 64" is evaluated to "true", so ssagen can branch the result without emitting conditional blocks. Instead, the constant-fold can be re-written as: switch { case true: // Body } So it does not depend on the delay results check during inlining. Adding a test, which will fail when typecheck.EvalConst is removed, so we can do the cleanup without breaking things. Change-Id: I638730bb147140de84260653741431b807ff2f15 Reviewed-on: https://go-review.googlesource.com/c/go/+/484316 Reviewed-by: Keith Randall <khr@google.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
* cmd/compile: reenable inline static initCuong Manh Le2023-04-144-4/+4
| | | | | | | | | | | | | | Updates #58293 Updates #58339 Fixes #58439 Change-Id: I06d2d92f86fa4a672d69515c4066d69d3e0fc75b Reviewed-on: https://go-review.googlesource.com/c/go/+/467016 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
* cmd/compile: handle string concatenation in static init inlinerCuong Manh Le2023-04-141-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | Static init inliner is using typecheck.EvalConst to handle string concatenation expressions. But static init inliner may reveal constant expressions after substitution, and the compiler needs to evaluate those expressions in non-constant semantic. Using typecheck.EvalConst, which always evaluates expressions in constant semantic, is not the right choice. For safety, this CL fold the logic to handle string concatenation to static init inliner, so there won't be regression in handling constant expressions in non-constant semantic. And also, future CL can simplify typecheck.EvalConst logic. Updates #58293 Updates #58339 Fixes #58439 Change-Id: I74068d99c245938e576afe9460cbd2b39677bbff Reviewed-on: https://go-review.googlesource.com/c/go/+/466277 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: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@golang.org>
* cmd/link: establish dependable package initialization orderKeith Randall2023-04-142-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | (This is a retry of CL 462035 which was reverted at 474976. The only change from that CL is the aix fix SRODATA->SNOPTRDATA at inittask.go:141) As described here: https://github.com/golang/go/issues/31636#issuecomment-493271830 "Find the lexically earliest package that is not initialized yet, but has had all its dependencies initialized, initialize that package, and repeat." Simplify the runtime a bit, by just computing the ordering required in the linker and giving a list to the runtime. Update #31636 Fixes #57411 RELNOTE=yes Change-Id: I28c09451d6aa677d7394c179d23c2c02c503fc56 Reviewed-on: https://go-review.googlesource.com/c/go/+/478916 Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
* Revert "cmd/compile: allow more inlining of functions that construct closures"Than McIntosh2023-04-141-15/+11
| | | | | | | | | | | | | | | This reverts commit http://go.dev/cl/c/482356. Reason for revert: Reverting this change again, since it is causing additional failures in google-internal testing. Change-Id: I9234946f62e5bb18c2f873a65e8b298d04af0809 Reviewed-on: https://go-review.googlesource.com/c/go/+/484735 Reviewed-by: Florian Zenker <floriank@google.com> Run-TryBot: Than McIntosh <thanm@google.com> Auto-Submit: Than McIntosh <thanm@google.com> Reviewed-by: Than McIntosh <thanm@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
* cmd/compile: fix ir.StaticValue for ORANGEJunwei Zuo2023-04-122-0/+33
| | | | | | | | | | | | | | | Range statement will mutate the key and value, so we should treat them as reassigned. Fixes #59572 Change-Id: I9c6b67d938760a0c6a1d9739f2737c67af4a3a10 Reviewed-on: https://go-review.googlesource.com/c/go/+/483855 Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org>
* all: add wasip1 supportJohan Brandhorst-Satzkorn2023-04-1125-27/+27
| | | | | | | | | | | | | | | | | Fixes #58141 Co-authored-by: Richard Musiol <neelance@gmail.com> Co-authored-by: Achille Roussel <achille.roussel@gmail.com> Co-authored-by: Julien Fabre <ju.pryz@gmail.com> Co-authored-by: Evan Phoenix <evan@phx.io> Change-Id: I49b66946acc90fdf09ed9223096bfec9a1e5b923 Reviewed-on: https://go-review.googlesource.com/c/go/+/479627 Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Auto-Submit: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> Auto-Submit: Ian Lance Taylor <iant@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Bypass: Ian Lance Taylor <iant@golang.org>
* cmd/compile: teach prove about bitwise OR operationCuong Manh Le2023-04-101-0/+5
| | | | | | | | | | | | | | | | | | For now, only apply the rule if either of arguments are constants. That would catch a lot of real user code, without slowing down the compiler with code generated for string comparison (experience in CL 410336). Updates #57959 Fixes #45928 Change-Id: Ie2e830d6d0d71cda3947818b22c2775bd94f7971 Reviewed-on: https://go-review.googlesource.com/c/go/+/483359 Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
* runtime: mark map bucket slots as empty during map clearCuong Manh Le2023-04-081-0/+77
| | | | | | | | | | | | | | | | | | So iterators that are in progress can know entries have been deleted and terminate the iterator properly. Update #55002 Update #56351 Fixes #59411 Change-Id: I924f16a00fe4ed6564f730a677348a6011d3fb67 Reviewed-on: https://go-review.googlesource.com/c/go/+/481935 Reviewed-by: Keith Randall <khr@golang.org> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Keith Randall <khr@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* cmd/compile: use correct type for byteswaps on multi-byte storesKeith Randall2023-04-071-0/+80
| | | | | | | | | | | | | | | | | | | | | | | | | Use the type of the store for the byteswap, not the type of the store's value argument. Normally when we're storing a 16-bit value, the value being stored is also typed as 16 bits. But sometimes it is typed as something smaller, usually because it is the result of an upcast from a smaller value, and that upcast needs no instructions. If the type of the store's arg is thinner than the type being stored, and the byteswap'd value uses that thinner type, and the byteswap'd value needs to be spilled & restored, that spill/restore happens using the thinner type, which causes us to lose some of the top bits of the value. Fixes #59367 Change-Id: If6ce1e8a76f18bf8e9d79871b6caa438bc3cce4d Reviewed-on: https://go-review.googlesource.com/c/go/+/481395 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
* cmd/compile: allow more inlining of functions that construct closuresThan McIntosh2023-04-071-11/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [This is a roll-forward of CL 479095, which was reverted due to a bad interaction between inlining and escape analysis since fixed in CL 482355.] Currently, when the inliner is determining if a function is inlineable, it descends into the bodies of closures constructed by that function. This has several unfortunate consequences: - If the closure contains a disallowed operation (e.g., a defer), then the outer function can't be inlined. It makes sense that the *closure* can't be inlined in this case, but it doesn't make sense to punish the function that constructs the closure. - The hairiness of the closure counts against the inlining budget of the outer function. Since we currently copy the closure body when inlining the outer function, this makes sense from the perspective of export data size and binary size, but ultimately doesn't make much sense from the perspective of what should be inlineable. - Since the inliner walks into every closure created by an outer function in addition to starting a walk at every closure, this adds an n^2 factor to inlinability analysis. This CL simply drops this behavior. In std, this makes 57 more functions inlinable, and disallows inlining for 10 (due to the basic instability of our bottom-up inlining approach), for an net increase of 47 inlinable functions (+0.6%). This will help significantly with the performance of the functions to be added for #56102, which have a somewhat complicated nesting of closures with a performance-critical fast path. The downside of this seems to be a potential increase in export data and text size, but the practical impact of this seems to be negligible: │ before │ after │ │ bytes │ bytes vs base │ Go/binary 15.12Mi ± 0% 15.14Mi ± 0% +0.16% (n=1) Go/text 5.220Mi ± 0% 5.237Mi ± 0% +0.32% (n=1) Compile/binary 22.92Mi ± 0% 22.94Mi ± 0% +0.07% (n=1) Compile/text 8.428Mi ± 0% 8.435Mi ± 0% +0.08% (n=1) Updates #56102. Change-Id: I1f4fc96c71609c8feb59fecdb92b69ba7e3b5b41 Reviewed-on: https://go-review.googlesource.com/c/go/+/482356 Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Run-TryBot: Than McIntosh <thanm@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* cmd/compile: deadcode unreferenced hidden closures during inliningThan McIntosh2023-04-072-0/+85
| | | | | | | | | | | | | | | | | | | | | | When a closure is inlined, it may contain other hidden closures, which the inliner will duplicate, rendering the original nested closures as unreachable. Because they are unreachable, they don't get processed in escape analysis, meaning that go/defer statements don't get rewritten, which can then in turn trigger errors in walk. This patch looks for nested hidden closures and marks them as dead, so that they can be skipped later on in the compilation flow. NB: if during escape analysis we rediscover a hidden closure (due to an explicit reference) that was previously marked dead, revive it at that point. Fixes #59404. Change-Id: I76db1e9cf1ee38bd1147aeae823f916dbbbf081b Reviewed-on: https://go-review.googlesource.com/c/go/+/482355 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Than McIntosh <thanm@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
* cmd/compile: get more bounds info from logic operators in prove passruinan2023-04-072-1/+20
| | | | | | | | | | | | | | | | | | | | Currently, the prove pass can get knowledge from some specific logic operators only before the CFG is explored, which means that the bounds information of the branch will be ignored. This CL updates the facts table by the logic operators in every branch. Combined with the branch information, this will be helpful for BCE in some circumstances. Fixes #57243 Change-Id: I0bd164f1b47804ccfc37879abe9788740b016fd5 Reviewed-on: https://go-review.googlesource.com/c/go/+/419555 Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: Eric Fang <eric.fang@arm.com> Reviewed-by: Keith Randall <khr@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com>
* cmd/compile: don't set range expr key/value type if already setCuong Manh Le2023-04-051-0/+26
| | | | | | | | | | | | | | Unified IR already records the correct type for them. Fixes #59378 Change-Id: I275c45b48f67bde55c8e2079d60b5868d0acde7f Reviewed-on: https://go-review.googlesource.com/c/go/+/481555 Reviewed-by: Michael Knyszek <mknyszek@google.com> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
* Revert "cmd/compile: allow more inlining of functions that construct closures"Than McIntosh2023-04-031-15/+11
| | | | | | | | | | | | This reverts commit http://go.dev/cl//479095 Reason for revert: causes failures in google-internal testing Change-Id: If1018b35be0b8627e2959f116179ada24d44d67c Reviewed-on: https://go-review.googlesource.com/c/go/+/481637 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> Run-TryBot: Than McIntosh <thanm@google.com>
* crypto/subtle: don't cast to *uintptr when word size is 0Keith Randall2023-03-311-0/+18
| | | | | | | | | | | | | | | | | | | Casting to a *uintptr is not ok if there isn't at least 8 bytes of data backing that pointer (on 64-bit archs). So although we end up making a slice of 0 length with that pointer, the cast itself doesn't know that. Instead, bail early if the result is going to be 0 length. Fixes #59334 Change-Id: Id3c0e09d341d838835c0382cccfb0f71dc3dc7e6 Reviewed-on: https://go-review.googlesource.com/c/go/+/480575 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com>
* cmd/compile: allow more inlining of functions that construct closuresAustin Clements2023-03-311-11/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, when the inliner is determining if a function is inlineable, it descends into the bodies of closures constructed by that function. This has several unfortunate consequences: - If the closure contains a disallowed operation (e.g., a defer), then the outer function can't be inlined. It makes sense that the *closure* can't be inlined in this case, but it doesn't make sense to punish the function that constructs the closure. - The hairiness of the closure counts against the inlining budget of the outer function. Since we currently copy the closure body when inlining the outer function, this makes sense from the perspective of export data size and binary size, but ultimately doesn't make much sense from the perspective of what should be inlineable. - Since the inliner walks into every closure created by an outer function in addition to starting a walk at every closure, this adds an n^2 factor to inlinability analysis. This CL simply drops this behavior. In std, this makes 57 more functions inlinable, and disallows inlining for 10 (due to the basic instability of our bottom-up inlining approach), for an net increase of 47 inlinable functions (+0.6%). This will help significantly with the performance of the functions to be added for #56102, which have a somewhat complicated nesting of closures with a performance-critical fast path. The downside of this seems to be a potential increase in export data and text size, but the practical impact of this seems to be negligible: │ before │ after │ │ bytes │ bytes vs base │ Go/binary 15.12Mi ± 0% 15.14Mi ± 0% +0.16% (n=1) Go/text 5.220Mi ± 0% 5.237Mi ± 0% +0.32% (n=1) Compile/binary 22.92Mi ± 0% 22.94Mi ± 0% +0.07% (n=1) Compile/text 8.428Mi ± 0% 8.435Mi ± 0% +0.08% (n=1) Change-Id: Ie9e38104fed5689a94c368288653fd7cb4b7a35e Reviewed-on: https://go-review.googlesource.com/c/go/+/479095 Reviewed-by: Than McIntosh <thanm@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Auto-Submit: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com>
* cmd/compile: casts from slices to array pointers are known to be non-nilKeith Randall2023-03-291-0/+7
| | | | | | | | | | | | | | | | | The cast is proceeded by a bounds check. If the bounds check passes then we know the pointer in the slice is non-nil. ... except casts to pointers of 0-sized arrays. They are strange, as the bounds check can pass for a nil input. Change-Id: Ic01cf4a82d59fbe3071d4b271c94efca9cafaec1 Reviewed-on: https://go-review.googlesource.com/c/go/+/479335 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Auto-Submit: Keith Randall <khr@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
* go/types, types2: don't report assignment mismatch errors if there are other ↵Robert Griesemer2023-03-281-1/+1
| | | | | | | | | | | | | | | | | | errors Change the Checker.use/useLHS functions to report if all "used" expressions evaluated without error. Use that information to control whether to report an assignment mismatch error or not. This will reduce the number of errors reported per assignment, where the assignment mismatch is only one of the errors. Change-Id: Ia0fc3203253b002e4e1d5759d8d5644999af6884 Reviewed-on: https://go-review.googlesource.com/c/go/+/478756 Reviewed-by: Robert Findley <rfindley@google.com> Reviewed-by: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Robert Griesemer <gri@google.com> Auto-Submit: Robert Griesemer <gri@google.com>
View Lorry Controller Status