qbit/go
1
0
Fork 0
mirror of https://github.com/golang/go synced 2024-11-22 22:40:02 -07:00
Code Releases Activity
3b2e846e11
go/test/codegen/mapaccess.go

485 lines
9.1 KiB
Go
Raw Normal View History

cmd/compile: avoid mapaccess at m[k]=append(m[k].. Currently rvalue m[k] is transformed during walk into: tmp1 := *mapaccess(m, k) tmp2 := append(tmp1, ...) *mapassign(m, k) = tmp2 However, this is suboptimal, as we could instead produce just: tmp := mapassign(m, k) *tmp := append(*tmp, ...) Optimization is possible only if during Order it may tell that m[k] is exactly the same at left and right part of assignment. It doesn't work: 1) m[f(k)] = append(m[f(k)], ...) 2) sink, m[k] = sink, append(m[k]...) 3) m[k] = append(..., m[k],...) Benchmark: name old time/op new time/op delta MapAppendAssign/Int32/256-8 33.5ns ± 3% 22.4ns ±10% -33.24% (p=0.000 n=16+18) MapAppendAssign/Int32/65536-8 68.2ns ± 6% 48.5ns ±29% -28.90% (p=0.000 n=20+20) MapAppendAssign/Int64/256-8 34.3ns ± 4% 23.3ns ± 5% -32.23% (p=0.000 n=17+18) MapAppendAssign/Int64/65536-8 65.9ns ± 7% 61.2ns ±19% -7.06% (p=0.002 n=18+20) MapAppendAssign/Str/256-8 116ns ±12% 79ns ±16% -31.70% (p=0.000 n=20+19) MapAppendAssign/Str/65536-8 134ns ±15% 111ns ±45% -16.95% (p=0.000 n=19+20) name old alloc/op new alloc/op delta MapAppendAssign/Int32/256-8 47.0B ± 0% 46.0B ± 0% -2.13% (p=0.000 n=19+18) MapAppendAssign/Int32/65536-8 27.0B ± 0% 20.7B ±30% -23.33% (p=0.000 n=20+20) MapAppendAssign/Int64/256-8 47.0B ± 0% 46.0B ± 0% -2.13% (p=0.000 n=20+17) MapAppendAssign/Int64/65536-8 27.0B ± 0% 27.0B ± 0% ~ (all equal) MapAppendAssign/Str/256-8 94.0B ± 0% 78.0B ± 0% -17.02% (p=0.000 n=20+16) MapAppendAssign/Str/65536-8 54.0B ± 0% 54.0B ± 0% ~ (all equal) Fixes #24364 Updates #5147 Change-Id: Id257d052b75b9a445b4885dc571bf06ce6f6b409 Reviewed-on: https://go-review.googlesource.com/100838 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-03-14 02:16:43 -06:00
// asmcheck
// Copyright 2018 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
package codegen
// These tests check that mapaccess calls are not used.
// Issues #23661 and #24364.
func mapCompoundAssignmentInt8() {
m := make(map[int8]int8, 0)
var k int8 = 0
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k] += 67
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k] -= 123
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k] *= 45
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k] |= 78
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k] ^= 89
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k] <<= 9
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k] >>= 10
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k]++
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k]--
}
func mapCompoundAssignmentInt32() {
m := make(map[int32]int32, 0)
var k int32 = 0
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k] += 67890
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k] -= 123
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k] *= 456
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k] |= 78
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k] ^= 89
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k] <<= 9
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k] >>= 10
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k]++
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k]--
}
func mapCompoundAssignmentInt64() {
m := make(map[int64]int64, 0)
var k int64 = 0
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k] += 67890
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k] -= 123
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k] *= 456
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k] |= 78
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k] ^= 89
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k] <<= 9
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k] >>= 10
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k]++
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k]--
}
func mapCompoundAssignmentComplex128() {
m := make(map[complex128]complex128, 0)
var k complex128 = 0
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k] += 67890
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k] -= 123
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k] *= 456
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k]++
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k]--
}
func mapCompoundAssignmentString() {
m := make(map[string]string, 0)
var k string = "key"
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k] += "value"
}
var sinkAppend bool
func mapAppendAssignmentInt8() {
m := make(map[int8][]int8, 0)
var k int8 = 0
cmd/compile: stop using VARKILL With the introduction of stack objects, VARKILL information is no longer needed. With stack objects, an object is dead when there are no more static references to it, and the stack scanner can't find any live pointers to it. VARKILL information isn't used to establish live ranges for address-taken variables any more. In effect, the last static reference *is* the VARKILL, and there's an additional dynamic liveness check during stack scanning. Next CL will actually rip out the VARKILL opcodes. Change-Id: I030a2ab867445cf4e0e69397911f8a2e2f0ed07b Reviewed-on: https://go-review.googlesource.com/c/go/+/419234 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Keith Randall <khr@golang.org>
2022-07-22 15:58:40 -06:00
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
cmd/compile: avoid mapaccess at m[k]=append(m[k].. Currently rvalue m[k] is transformed during walk into: tmp1 := *mapaccess(m, k) tmp2 := append(tmp1, ...) *mapassign(m, k) = tmp2 However, this is suboptimal, as we could instead produce just: tmp := mapassign(m, k) *tmp := append(*tmp, ...) Optimization is possible only if during Order it may tell that m[k] is exactly the same at left and right part of assignment. It doesn't work: 1) m[f(k)] = append(m[f(k)], ...) 2) sink, m[k] = sink, append(m[k]...) 3) m[k] = append(..., m[k],...) Benchmark: name old time/op new time/op delta MapAppendAssign/Int32/256-8 33.5ns ± 3% 22.4ns ±10% -33.24% (p=0.000 n=16+18) MapAppendAssign/Int32/65536-8 68.2ns ± 6% 48.5ns ±29% -28.90% (p=0.000 n=20+20) MapAppendAssign/Int64/256-8 34.3ns ± 4% 23.3ns ± 5% -32.23% (p=0.000 n=17+18) MapAppendAssign/Int64/65536-8 65.9ns ± 7% 61.2ns ±19% -7.06% (p=0.002 n=18+20) MapAppendAssign/Str/256-8 116ns ±12% 79ns ±16% -31.70% (p=0.000 n=20+19) MapAppendAssign/Str/65536-8 134ns ±15% 111ns ±45% -16.95% (p=0.000 n=19+20) name old alloc/op new alloc/op delta MapAppendAssign/Int32/256-8 47.0B ± 0% 46.0B ± 0% -2.13% (p=0.000 n=19+18) MapAppendAssign/Int32/65536-8 27.0B ± 0% 20.7B ±30% -23.33% (p=0.000 n=20+20) MapAppendAssign/Int64/256-8 47.0B ± 0% 46.0B ± 0% -2.13% (p=0.000 n=20+17) MapAppendAssign/Int64/65536-8 27.0B ± 0% 27.0B ± 0% ~ (all equal) MapAppendAssign/Str/256-8 94.0B ± 0% 78.0B ± 0% -17.02% (p=0.000 n=20+16) MapAppendAssign/Str/65536-8 54.0B ± 0% 54.0B ± 0% ~ (all equal) Fixes #24364 Updates #5147 Change-Id: Id257d052b75b9a445b4885dc571bf06ce6f6b409 Reviewed-on: https://go-review.googlesource.com/100838 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-03-14 02:16:43 -06:00
m[k] = append(m[k], 1)
cmd/compile: stop using VARKILL With the introduction of stack objects, VARKILL information is no longer needed. With stack objects, an object is dead when there are no more static references to it, and the stack scanner can't find any live pointers to it. VARKILL information isn't used to establish live ranges for address-taken variables any more. In effect, the last static reference *is* the VARKILL, and there's an additional dynamic liveness check during stack scanning. Next CL will actually rip out the VARKILL opcodes. Change-Id: I030a2ab867445cf4e0e69397911f8a2e2f0ed07b Reviewed-on: https://go-review.googlesource.com/c/go/+/419234 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Keith Randall <khr@golang.org>
2022-07-22 15:58:40 -06:00
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
cmd/compile: avoid mapaccess at m[k]=append(m[k].. Currently rvalue m[k] is transformed during walk into: tmp1 := *mapaccess(m, k) tmp2 := append(tmp1, ...) *mapassign(m, k) = tmp2 However, this is suboptimal, as we could instead produce just: tmp := mapassign(m, k) *tmp := append(*tmp, ...) Optimization is possible only if during Order it may tell that m[k] is exactly the same at left and right part of assignment. It doesn't work: 1) m[f(k)] = append(m[f(k)], ...) 2) sink, m[k] = sink, append(m[k]...) 3) m[k] = append(..., m[k],...) Benchmark: name old time/op new time/op delta MapAppendAssign/Int32/256-8 33.5ns ± 3% 22.4ns ±10% -33.24% (p=0.000 n=16+18) MapAppendAssign/Int32/65536-8 68.2ns ± 6% 48.5ns ±29% -28.90% (p=0.000 n=20+20) MapAppendAssign/Int64/256-8 34.3ns ± 4% 23.3ns ± 5% -32.23% (p=0.000 n=17+18) MapAppendAssign/Int64/65536-8 65.9ns ± 7% 61.2ns ±19% -7.06% (p=0.002 n=18+20) MapAppendAssign/Str/256-8 116ns ±12% 79ns ±16% -31.70% (p=0.000 n=20+19) MapAppendAssign/Str/65536-8 134ns ±15% 111ns ±45% -16.95% (p=0.000 n=19+20) name old alloc/op new alloc/op delta MapAppendAssign/Int32/256-8 47.0B ± 0% 46.0B ± 0% -2.13% (p=0.000 n=19+18) MapAppendAssign/Int32/65536-8 27.0B ± 0% 20.7B ±30% -23.33% (p=0.000 n=20+20) MapAppendAssign/Int64/256-8 47.0B ± 0% 46.0B ± 0% -2.13% (p=0.000 n=20+17) MapAppendAssign/Int64/65536-8 27.0B ± 0% 27.0B ± 0% ~ (all equal) MapAppendAssign/Str/256-8 94.0B ± 0% 78.0B ± 0% -17.02% (p=0.000 n=20+16) MapAppendAssign/Str/65536-8 54.0B ± 0% 54.0B ± 0% ~ (all equal) Fixes #24364 Updates #5147 Change-Id: Id257d052b75b9a445b4885dc571bf06ce6f6b409 Reviewed-on: https://go-review.googlesource.com/100838 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-03-14 02:16:43 -06:00
m[k] = append(m[k], 1, 2, 3)
a := []int8{7, 8, 9, 0}
cmd/compile: stop using VARKILL With the introduction of stack objects, VARKILL information is no longer needed. With stack objects, an object is dead when there are no more static references to it, and the stack scanner can't find any live pointers to it. VARKILL information isn't used to establish live ranges for address-taken variables any more. In effect, the last static reference *is* the VARKILL, and there's an additional dynamic liveness check during stack scanning. Next CL will actually rip out the VARKILL opcodes. Change-Id: I030a2ab867445cf4e0e69397911f8a2e2f0ed07b Reviewed-on: https://go-review.googlesource.com/c/go/+/419234 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Keith Randall <khr@golang.org>
2022-07-22 15:58:40 -06:00
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
cmd/compile: avoid mapaccess at m[k]=append(m[k].. Currently rvalue m[k] is transformed during walk into: tmp1 := *mapaccess(m, k) tmp2 := append(tmp1, ...) *mapassign(m, k) = tmp2 However, this is suboptimal, as we could instead produce just: tmp := mapassign(m, k) *tmp := append(*tmp, ...) Optimization is possible only if during Order it may tell that m[k] is exactly the same at left and right part of assignment. It doesn't work: 1) m[f(k)] = append(m[f(k)], ...) 2) sink, m[k] = sink, append(m[k]...) 3) m[k] = append(..., m[k],...) Benchmark: name old time/op new time/op delta MapAppendAssign/Int32/256-8 33.5ns ± 3% 22.4ns ±10% -33.24% (p=0.000 n=16+18) MapAppendAssign/Int32/65536-8 68.2ns ± 6% 48.5ns ±29% -28.90% (p=0.000 n=20+20) MapAppendAssign/Int64/256-8 34.3ns ± 4% 23.3ns ± 5% -32.23% (p=0.000 n=17+18) MapAppendAssign/Int64/65536-8 65.9ns ± 7% 61.2ns ±19% -7.06% (p=0.002 n=18+20) MapAppendAssign/Str/256-8 116ns ±12% 79ns ±16% -31.70% (p=0.000 n=20+19) MapAppendAssign/Str/65536-8 134ns ±15% 111ns ±45% -16.95% (p=0.000 n=19+20) name old alloc/op new alloc/op delta MapAppendAssign/Int32/256-8 47.0B ± 0% 46.0B ± 0% -2.13% (p=0.000 n=19+18) MapAppendAssign/Int32/65536-8 27.0B ± 0% 20.7B ±30% -23.33% (p=0.000 n=20+20) MapAppendAssign/Int64/256-8 47.0B ± 0% 46.0B ± 0% -2.13% (p=0.000 n=20+17) MapAppendAssign/Int64/65536-8 27.0B ± 0% 27.0B ± 0% ~ (all equal) MapAppendAssign/Str/256-8 94.0B ± 0% 78.0B ± 0% -17.02% (p=0.000 n=20+16) MapAppendAssign/Str/65536-8 54.0B ± 0% 54.0B ± 0% ~ (all equal) Fixes #24364 Updates #5147 Change-Id: Id257d052b75b9a445b4885dc571bf06ce6f6b409 Reviewed-on: https://go-review.googlesource.com/100838 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-03-14 02:16:43 -06:00
m[k] = append(m[k], a...)
// Exceptions
// 386:".*mapaccess"
// amd64:".*mapaccess"
// arm:".*mapaccess"
// arm64:".*mapaccess"
m[k] = append(a, m[k]...)
// 386:".*mapaccess"
// amd64:".*mapaccess"
// arm:".*mapaccess"
// arm64:".*mapaccess"
sinkAppend, m[k] = !sinkAppend, append(m[k], 99)
// 386:".*mapaccess"
// amd64:".*mapaccess"
// arm:".*mapaccess"
// arm64:".*mapaccess"
m[k] = append(m[k+1], 100)
}
func mapAppendAssignmentInt32() {
m := make(map[int32][]int32, 0)
var k int32 = 0
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k] = append(m[k], 1)
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k] = append(m[k], 1, 2, 3)
a := []int32{7, 8, 9, 0}
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k] = append(m[k], a...)
cmd/compile/internal/gc: handle arith ops in samesafeexpr Teach samesafeexpr to handle arithmetic unary and binary ops. It makes map lookup optimization possible in m[k+1] = append(m[k+1], ...) m[-k] = append(m[-k], ...) ... etc Does not cover "+" for strings (concatenation). Change-Id: Ibbb16ac3faf176958da344be1471b06d7cf33a6c Reviewed-on: https://go-review.googlesource.com/135795 Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2018-09-17 12:37:30 -06:00
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k+1] = append(m[k+1], a...)
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[-k] = append(m[-k], a...)
cmd/compile: avoid mapaccess at m[k]=append(m[k].. Currently rvalue m[k] is transformed during walk into: tmp1 := *mapaccess(m, k) tmp2 := append(tmp1, ...) *mapassign(m, k) = tmp2 However, this is suboptimal, as we could instead produce just: tmp := mapassign(m, k) *tmp := append(*tmp, ...) Optimization is possible only if during Order it may tell that m[k] is exactly the same at left and right part of assignment. It doesn't work: 1) m[f(k)] = append(m[f(k)], ...) 2) sink, m[k] = sink, append(m[k]...) 3) m[k] = append(..., m[k],...) Benchmark: name old time/op new time/op delta MapAppendAssign/Int32/256-8 33.5ns ± 3% 22.4ns ±10% -33.24% (p=0.000 n=16+18) MapAppendAssign/Int32/65536-8 68.2ns ± 6% 48.5ns ±29% -28.90% (p=0.000 n=20+20) MapAppendAssign/Int64/256-8 34.3ns ± 4% 23.3ns ± 5% -32.23% (p=0.000 n=17+18) MapAppendAssign/Int64/65536-8 65.9ns ± 7% 61.2ns ±19% -7.06% (p=0.002 n=18+20) MapAppendAssign/Str/256-8 116ns ±12% 79ns ±16% -31.70% (p=0.000 n=20+19) MapAppendAssign/Str/65536-8 134ns ±15% 111ns ±45% -16.95% (p=0.000 n=19+20) name old alloc/op new alloc/op delta MapAppendAssign/Int32/256-8 47.0B ± 0% 46.0B ± 0% -2.13% (p=0.000 n=19+18) MapAppendAssign/Int32/65536-8 27.0B ± 0% 20.7B ±30% -23.33% (p=0.000 n=20+20) MapAppendAssign/Int64/256-8 47.0B ± 0% 46.0B ± 0% -2.13% (p=0.000 n=20+17) MapAppendAssign/Int64/65536-8 27.0B ± 0% 27.0B ± 0% ~ (all equal) MapAppendAssign/Str/256-8 94.0B ± 0% 78.0B ± 0% -17.02% (p=0.000 n=20+16) MapAppendAssign/Str/65536-8 54.0B ± 0% 54.0B ± 0% ~ (all equal) Fixes #24364 Updates #5147 Change-Id: Id257d052b75b9a445b4885dc571bf06ce6f6b409 Reviewed-on: https://go-review.googlesource.com/100838 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-03-14 02:16:43 -06:00
// Exceptions
// 386:".*mapaccess"
// amd64:".*mapaccess"
// arm:".*mapaccess"
// arm64:".*mapaccess"
m[k] = append(a, m[k]...)
// 386:".*mapaccess"
// amd64:".*mapaccess"
// arm:".*mapaccess"
// arm64:".*mapaccess"
sinkAppend, m[k] = !sinkAppend, append(m[k], 99)
// 386:".*mapaccess"
// amd64:".*mapaccess"
// arm:".*mapaccess"
// arm64:".*mapaccess"
m[k] = append(m[k+1], 100)
}
func mapAppendAssignmentInt64() {
m := make(map[int64][]int64, 0)
var k int64 = 0
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k] = append(m[k], 1)
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k] = append(m[k], 1, 2, 3)
a := []int64{7, 8, 9, 0}
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k] = append(m[k], a...)
cmd/compile/internal/gc: handle arith ops in samesafeexpr Teach samesafeexpr to handle arithmetic unary and binary ops. It makes map lookup optimization possible in m[k+1] = append(m[k+1], ...) m[-k] = append(m[-k], ...) ... etc Does not cover "+" for strings (concatenation). Change-Id: Ibbb16ac3faf176958da344be1471b06d7cf33a6c Reviewed-on: https://go-review.googlesource.com/135795 Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2018-09-17 12:37:30 -06:00
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k+1] = append(m[k+1], a...)
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[-k] = append(m[-k], a...)
cmd/compile: avoid mapaccess at m[k]=append(m[k].. Currently rvalue m[k] is transformed during walk into: tmp1 := *mapaccess(m, k) tmp2 := append(tmp1, ...) *mapassign(m, k) = tmp2 However, this is suboptimal, as we could instead produce just: tmp := mapassign(m, k) *tmp := append(*tmp, ...) Optimization is possible only if during Order it may tell that m[k] is exactly the same at left and right part of assignment. It doesn't work: 1) m[f(k)] = append(m[f(k)], ...) 2) sink, m[k] = sink, append(m[k]...) 3) m[k] = append(..., m[k],...) Benchmark: name old time/op new time/op delta MapAppendAssign/Int32/256-8 33.5ns ± 3% 22.4ns ±10% -33.24% (p=0.000 n=16+18) MapAppendAssign/Int32/65536-8 68.2ns ± 6% 48.5ns ±29% -28.90% (p=0.000 n=20+20) MapAppendAssign/Int64/256-8 34.3ns ± 4% 23.3ns ± 5% -32.23% (p=0.000 n=17+18) MapAppendAssign/Int64/65536-8 65.9ns ± 7% 61.2ns ±19% -7.06% (p=0.002 n=18+20) MapAppendAssign/Str/256-8 116ns ±12% 79ns ±16% -31.70% (p=0.000 n=20+19) MapAppendAssign/Str/65536-8 134ns ±15% 111ns ±45% -16.95% (p=0.000 n=19+20) name old alloc/op new alloc/op delta MapAppendAssign/Int32/256-8 47.0B ± 0% 46.0B ± 0% -2.13% (p=0.000 n=19+18) MapAppendAssign/Int32/65536-8 27.0B ± 0% 20.7B ±30% -23.33% (p=0.000 n=20+20) MapAppendAssign/Int64/256-8 47.0B ± 0% 46.0B ± 0% -2.13% (p=0.000 n=20+17) MapAppendAssign/Int64/65536-8 27.0B ± 0% 27.0B ± 0% ~ (all equal) MapAppendAssign/Str/256-8 94.0B ± 0% 78.0B ± 0% -17.02% (p=0.000 n=20+16) MapAppendAssign/Str/65536-8 54.0B ± 0% 54.0B ± 0% ~ (all equal) Fixes #24364 Updates #5147 Change-Id: Id257d052b75b9a445b4885dc571bf06ce6f6b409 Reviewed-on: https://go-review.googlesource.com/100838 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-03-14 02:16:43 -06:00
// Exceptions
// 386:".*mapaccess"
// amd64:".*mapaccess"
// arm:".*mapaccess"
// arm64:".*mapaccess"
m[k] = append(a, m[k]...)
// 386:".*mapaccess"
// amd64:".*mapaccess"
// arm:".*mapaccess"
// arm64:".*mapaccess"
sinkAppend, m[k] = !sinkAppend, append(m[k], 99)
// 386:".*mapaccess"
// amd64:".*mapaccess"
// arm:".*mapaccess"
// arm64:".*mapaccess"
m[k] = append(m[k+1], 100)
}
func mapAppendAssignmentComplex128() {
m := make(map[complex128][]complex128, 0)
var k complex128 = 0
cmd/compile: stop using VARKILL With the introduction of stack objects, VARKILL information is no longer needed. With stack objects, an object is dead when there are no more static references to it, and the stack scanner can't find any live pointers to it. VARKILL information isn't used to establish live ranges for address-taken variables any more. In effect, the last static reference *is* the VARKILL, and there's an additional dynamic liveness check during stack scanning. Next CL will actually rip out the VARKILL opcodes. Change-Id: I030a2ab867445cf4e0e69397911f8a2e2f0ed07b Reviewed-on: https://go-review.googlesource.com/c/go/+/419234 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Keith Randall <khr@golang.org>
2022-07-22 15:58:40 -06:00
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
cmd/compile: avoid mapaccess at m[k]=append(m[k].. Currently rvalue m[k] is transformed during walk into: tmp1 := *mapaccess(m, k) tmp2 := append(tmp1, ...) *mapassign(m, k) = tmp2 However, this is suboptimal, as we could instead produce just: tmp := mapassign(m, k) *tmp := append(*tmp, ...) Optimization is possible only if during Order it may tell that m[k] is exactly the same at left and right part of assignment. It doesn't work: 1) m[f(k)] = append(m[f(k)], ...) 2) sink, m[k] = sink, append(m[k]...) 3) m[k] = append(..., m[k],...) Benchmark: name old time/op new time/op delta MapAppendAssign/Int32/256-8 33.5ns ± 3% 22.4ns ±10% -33.24% (p=0.000 n=16+18) MapAppendAssign/Int32/65536-8 68.2ns ± 6% 48.5ns ±29% -28.90% (p=0.000 n=20+20) MapAppendAssign/Int64/256-8 34.3ns ± 4% 23.3ns ± 5% -32.23% (p=0.000 n=17+18) MapAppendAssign/Int64/65536-8 65.9ns ± 7% 61.2ns ±19% -7.06% (p=0.002 n=18+20) MapAppendAssign/Str/256-8 116ns ±12% 79ns ±16% -31.70% (p=0.000 n=20+19) MapAppendAssign/Str/65536-8 134ns ±15% 111ns ±45% -16.95% (p=0.000 n=19+20) name old alloc/op new alloc/op delta MapAppendAssign/Int32/256-8 47.0B ± 0% 46.0B ± 0% -2.13% (p=0.000 n=19+18) MapAppendAssign/Int32/65536-8 27.0B ± 0% 20.7B ±30% -23.33% (p=0.000 n=20+20) MapAppendAssign/Int64/256-8 47.0B ± 0% 46.0B ± 0% -2.13% (p=0.000 n=20+17) MapAppendAssign/Int64/65536-8 27.0B ± 0% 27.0B ± 0% ~ (all equal) MapAppendAssign/Str/256-8 94.0B ± 0% 78.0B ± 0% -17.02% (p=0.000 n=20+16) MapAppendAssign/Str/65536-8 54.0B ± 0% 54.0B ± 0% ~ (all equal) Fixes #24364 Updates #5147 Change-Id: Id257d052b75b9a445b4885dc571bf06ce6f6b409 Reviewed-on: https://go-review.googlesource.com/100838 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-03-14 02:16:43 -06:00
m[k] = append(m[k], 1)
cmd/compile: stop using VARKILL With the introduction of stack objects, VARKILL information is no longer needed. With stack objects, an object is dead when there are no more static references to it, and the stack scanner can't find any live pointers to it. VARKILL information isn't used to establish live ranges for address-taken variables any more. In effect, the last static reference *is* the VARKILL, and there's an additional dynamic liveness check during stack scanning. Next CL will actually rip out the VARKILL opcodes. Change-Id: I030a2ab867445cf4e0e69397911f8a2e2f0ed07b Reviewed-on: https://go-review.googlesource.com/c/go/+/419234 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Keith Randall <khr@golang.org>
2022-07-22 15:58:40 -06:00
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
cmd/compile: avoid mapaccess at m[k]=append(m[k].. Currently rvalue m[k] is transformed during walk into: tmp1 := *mapaccess(m, k) tmp2 := append(tmp1, ...) *mapassign(m, k) = tmp2 However, this is suboptimal, as we could instead produce just: tmp := mapassign(m, k) *tmp := append(*tmp, ...) Optimization is possible only if during Order it may tell that m[k] is exactly the same at left and right part of assignment. It doesn't work: 1) m[f(k)] = append(m[f(k)], ...) 2) sink, m[k] = sink, append(m[k]...) 3) m[k] = append(..., m[k],...) Benchmark: name old time/op new time/op delta MapAppendAssign/Int32/256-8 33.5ns ± 3% 22.4ns ±10% -33.24% (p=0.000 n=16+18) MapAppendAssign/Int32/65536-8 68.2ns ± 6% 48.5ns ±29% -28.90% (p=0.000 n=20+20) MapAppendAssign/Int64/256-8 34.3ns ± 4% 23.3ns ± 5% -32.23% (p=0.000 n=17+18) MapAppendAssign/Int64/65536-8 65.9ns ± 7% 61.2ns ±19% -7.06% (p=0.002 n=18+20) MapAppendAssign/Str/256-8 116ns ±12% 79ns ±16% -31.70% (p=0.000 n=20+19) MapAppendAssign/Str/65536-8 134ns ±15% 111ns ±45% -16.95% (p=0.000 n=19+20) name old alloc/op new alloc/op delta MapAppendAssign/Int32/256-8 47.0B ± 0% 46.0B ± 0% -2.13% (p=0.000 n=19+18) MapAppendAssign/Int32/65536-8 27.0B ± 0% 20.7B ±30% -23.33% (p=0.000 n=20+20) MapAppendAssign/Int64/256-8 47.0B ± 0% 46.0B ± 0% -2.13% (p=0.000 n=20+17) MapAppendAssign/Int64/65536-8 27.0B ± 0% 27.0B ± 0% ~ (all equal) MapAppendAssign/Str/256-8 94.0B ± 0% 78.0B ± 0% -17.02% (p=0.000 n=20+16) MapAppendAssign/Str/65536-8 54.0B ± 0% 54.0B ± 0% ~ (all equal) Fixes #24364 Updates #5147 Change-Id: Id257d052b75b9a445b4885dc571bf06ce6f6b409 Reviewed-on: https://go-review.googlesource.com/100838 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-03-14 02:16:43 -06:00
m[k] = append(m[k], 1, 2, 3)
a := []complex128{7, 8, 9, 0}
cmd/compile: stop using VARKILL With the introduction of stack objects, VARKILL information is no longer needed. With stack objects, an object is dead when there are no more static references to it, and the stack scanner can't find any live pointers to it. VARKILL information isn't used to establish live ranges for address-taken variables any more. In effect, the last static reference *is* the VARKILL, and there's an additional dynamic liveness check during stack scanning. Next CL will actually rip out the VARKILL opcodes. Change-Id: I030a2ab867445cf4e0e69397911f8a2e2f0ed07b Reviewed-on: https://go-review.googlesource.com/c/go/+/419234 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Keith Randall <khr@golang.org>
2022-07-22 15:58:40 -06:00
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
cmd/compile: avoid mapaccess at m[k]=append(m[k].. Currently rvalue m[k] is transformed during walk into: tmp1 := *mapaccess(m, k) tmp2 := append(tmp1, ...) *mapassign(m, k) = tmp2 However, this is suboptimal, as we could instead produce just: tmp := mapassign(m, k) *tmp := append(*tmp, ...) Optimization is possible only if during Order it may tell that m[k] is exactly the same at left and right part of assignment. It doesn't work: 1) m[f(k)] = append(m[f(k)], ...) 2) sink, m[k] = sink, append(m[k]...) 3) m[k] = append(..., m[k],...) Benchmark: name old time/op new time/op delta MapAppendAssign/Int32/256-8 33.5ns ± 3% 22.4ns ±10% -33.24% (p=0.000 n=16+18) MapAppendAssign/Int32/65536-8 68.2ns ± 6% 48.5ns ±29% -28.90% (p=0.000 n=20+20) MapAppendAssign/Int64/256-8 34.3ns ± 4% 23.3ns ± 5% -32.23% (p=0.000 n=17+18) MapAppendAssign/Int64/65536-8 65.9ns ± 7% 61.2ns ±19% -7.06% (p=0.002 n=18+20) MapAppendAssign/Str/256-8 116ns ±12% 79ns ±16% -31.70% (p=0.000 n=20+19) MapAppendAssign/Str/65536-8 134ns ±15% 111ns ±45% -16.95% (p=0.000 n=19+20) name old alloc/op new alloc/op delta MapAppendAssign/Int32/256-8 47.0B ± 0% 46.0B ± 0% -2.13% (p=0.000 n=19+18) MapAppendAssign/Int32/65536-8 27.0B ± 0% 20.7B ±30% -23.33% (p=0.000 n=20+20) MapAppendAssign/Int64/256-8 47.0B ± 0% 46.0B ± 0% -2.13% (p=0.000 n=20+17) MapAppendAssign/Int64/65536-8 27.0B ± 0% 27.0B ± 0% ~ (all equal) MapAppendAssign/Str/256-8 94.0B ± 0% 78.0B ± 0% -17.02% (p=0.000 n=20+16) MapAppendAssign/Str/65536-8 54.0B ± 0% 54.0B ± 0% ~ (all equal) Fixes #24364 Updates #5147 Change-Id: Id257d052b75b9a445b4885dc571bf06ce6f6b409 Reviewed-on: https://go-review.googlesource.com/100838 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-03-14 02:16:43 -06:00
m[k] = append(m[k], a...)
// Exceptions
// 386:".*mapaccess"
// amd64:".*mapaccess"
// arm:".*mapaccess"
// arm64:".*mapaccess"
m[k] = append(a, m[k]...)
// 386:".*mapaccess"
// amd64:".*mapaccess"
// arm:".*mapaccess"
// arm64:".*mapaccess"
sinkAppend, m[k] = !sinkAppend, append(m[k], 99)
// 386:".*mapaccess"
// amd64:".*mapaccess"
// arm:".*mapaccess"
// arm64:".*mapaccess"
m[k] = append(m[k+1], 100)
}
func mapAppendAssignmentString() {
m := make(map[string][]string, 0)
var k string = "key"
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k] = append(m[k], "1")
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k] = append(m[k], "1", "2", "3")
a := []string{"7", "8", "9", "0"}
// 386:-".*mapaccess"
// amd64:-".*mapaccess"
// arm:-".*mapaccess"
// arm64:-".*mapaccess"
m[k] = append(m[k], a...)
// Exceptions
// 386:".*mapaccess"
// amd64:".*mapaccess"
// arm:".*mapaccess"
// arm64:".*mapaccess"
m[k] = append(a, m[k]...)
// 386:".*mapaccess"
// amd64:".*mapaccess"
// arm:".*mapaccess"
// arm64:".*mapaccess"
sinkAppend, m[k] = !sinkAppend, append(m[k], "99")
// 386:".*mapaccess"
// amd64:".*mapaccess"
// arm:".*mapaccess"
// arm64:".*mapaccess"
m[k] = append(m[k+"1"], "100")
}
Copy Permalink