Assuming the two values are valid and non-comparable, Equal should panic.
x := reflect.ValueOf([]int{1, 2, 3})
x.Equal(x) // can not report false, should panic
Assuming one of them is non-comparable and the other is invalid, it should
always report false.
x := reflect.ValueOf([]int{1, 2, 3})
y := reflect.ValueOf(nil)
x.Equal(y) // should report false
For #46746.
Change-Id: Ifecd77ca0b3de3019fae2be39048f9277831676c
Reviewed-on: https://go-review.googlesource.com/c/go/+/440037
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The Grow method is like the proposed slices.Grow function
in that it ensures that the slice has enough capacity to append
n elements without allocating.
The implementation of Grow is a thin wrapper over runtime.growslice.
This also changes Append and AppendSlice to use growslice under the hood.
Fixes#48000
Change-Id: I992a58584a2ff1448c1c2bc0877fe76073609111
Reviewed-on: https://go-review.googlesource.com/c/go/+/389635
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This change adds the arenas package and a function to reflect for
allocating from an arena via reflection, but all the new API is placed
behind a GOEXPERIMENT.
For #51317.
Change-Id: I026d46294e26ab386d74625108c19a0024fbcedc
Reviewed-on: https://go-review.googlesource.com/c/go/+/423361
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Imagine that initFuncTypes is called with n=3, funcTypes will be
[nil, nil, nil, **reflect.rtype] afterward, then it's called with n=2.
The current implementation will copy funcTypes because funcTypes[2] is
nil. This is unnecessary. It should make a new slice and copy funcTypes
into it only when n >= len(funcTypes).
Updates #56011.
Change-Id: Ia093d2f550d6924a4c58bcd21325093e32b40baa
GitHub-Last-Rev: a599eae7c2
GitHub-Pull-Request: golang/go#56024
Reviewed-on: https://go-review.googlesource.com/c/go/+/438395
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
CL 425314 made creating funcTypes using StructOf, and using a mutex to
protect read+write to funcTypes. However, after initializing funcTypes,
it is accessed in FuncOf without holding lock, causing a race.
Fixing it by returning the n-th Type directly from initFuncTypes, so the
accessing funcTypes will always be guarded by a mutex.
Fixes#56011
Change-Id: I1b50d1ae342943f16f368b8606f2614076dc90fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/437997
Reviewed-by: Keith Randall <khr@google.com>
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: Bryan Mills <bcmills@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
For #46746
Change-Id: Ic7a31ddf7cd6bf6dd0db6b9eb3fee68fc180f72e
Reviewed-on: https://go-review.googlesource.com/c/go/+/435277
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
follow the TODO to use StructOf, this cl can save the used memory.
for example, old code alloc [128]*rtype for func with 65 arguments(in+out),
this cl change to alloc [65]*rtype to save memory.
Change-Id: I1494bb6b3524d0d46869c3f24a628fec88119d8b
Reviewed-on: https://go-review.googlesource.com/c/go/+/425314
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
using Type.Comparable to simplify the Value.Comparable,
and return true directly when exit the for loop of kind == array and elements type is interface or array or struct.
Change-Id: Ib0b06a70642ba24c9215c69e7d619960fbeeed90
Reviewed-on: https://go-review.googlesource.com/c/go/+/426457
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: xie cui <523516579@qq.com>
Change-Id: If36e9fd7d6b1993ca2d0d382e7fa52212170c798
Reviewed-on: https://go-review.googlesource.com/c/go/+/425481
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
all_test.go is quite big, so let it contain tests only.
Change-Id: I5003db4a8b1e2384ea8470f5e89e1c26d61d10ae
Reviewed-on: https://go-review.googlesource.com/c/go/+/429759
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Jenny Rakoczy <jenny@golang.org>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
After we deprecated reflect.{SliceHeader, StringHeader}, it is recommended
to use unsafe.{Slice, String} to replace its work. However, the compiler
and linker cannot be migrated for the time being.
As a temporary strategy, using the "internal/unsafeheader" package like
other code is the most suitable choice at present.
For #53003.
Change-Id: I69d0ef72e2d95caabd0706bbb247a719d225c758
Reviewed-on: https://go-review.googlesource.com/c/go/+/429755
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: hopehook <hopehook@golangcn.org>
As discussed in CL 401434 there are substantial misuses of these in the
wild, and they are a potential source of unsafety even for code that
does not use them directly.
Since proposal #53003 has already been implemented, now is the right
time to deprecate reflect.{SliceHeader, StringHeader}.
For #53003.
Change-Id: I724cf46d4b22d2ed3cbf2b948e6aac5ee4bf0f6e
Reviewed-on: https://go-review.googlesource.com/c/go/+/428757
Run-TryBot: hopehook <hopehook@golangcn.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
The lowests fives bits are the kind, and the next five bits are attributes,
not the other way around.
Change-Id: I5e1d13b195b766e99f66bb1227cc7f84e85dc49d
Reviewed-on: https://go-review.googlesource.com/c/go/+/425185
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
Change-Id: Ie100a2a6f272b84fa2da6ac7b64452985242d788
Reviewed-on: https://go-review.googlesource.com/c/go/+/428275
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
v.SetIterXXX(i) is semantically identical to v.Set(i.XXX()).
If the latter panics for unexported values, so should the former.
This change may breaking some programs, but the change is justified
under the "Go 1 and the Future of Go Programs" document because
the "library has a bug that violates the specification".
In this case, the "reflect" package does not accurately match
the behavior of the Go language specification.
Also, this API was recently released, so the number of users
who could be depending on this behavior is hopefully lower.
Fixes#54628
Change-Id: If86ede51f286e38093f6697944c089f616525115
Reviewed-on: https://go-review.googlesource.com/c/go/+/425184
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: David Chase <drchase@google.com>
go:notinheap will be replaced by runtime/internal/sys.NotInHeap, and for
longer term, we want to restrict all of its usages inside the runtime
package only.
Updates #46731
Change-Id: I267adc2a19f0dc8a1ed29b5b4aeec1a7dc7318d5
Reviewed-on: https://go-review.googlesource.com/c/go/+/421880
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The current implementation always returns false for non-comparable
values, update the doc to reflect that.
Change-Id: I87f2da408874b0a209c8f51949e3310da15c5904
Reviewed-on: https://go-review.googlesource.com/c/go/+/426195
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: xie cui <523516579@qq.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: hopehook <hopehook@golangcn.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
If array element is not interface, array or struct, we just need to
check whether the array element type is comparable.
Change-Id: I1ab94cfa17ae86feb6cd3fbdf878af5a776e7bec
Reviewed-on: https://go-review.googlesource.com/c/go/+/426194
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
For #46746
Change-Id: I879124974cdb55932cd9d07d3b384d49d5059857
Reviewed-on: https://go-review.googlesource.com/c/go/+/423794
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Fixes#54669
Change-Id: I34cbe729d187437ddeafbaa910af6ed001b2603f
Reviewed-on: https://go-review.googlesource.com/c/go/+/425461
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
If a struct or array is comparable, then we can leverage rtype.equal,
which is almost always faster than what Go reflection can achieve.
As a secondary optimization, pre-compute Value.Len and Value.NumField
outside of the loop conditional.
Performance:
name old time/op new time/op delta
IsZero/ArrayComparable 136ns ± 4% 16ns ± 1% -88.28% (p=0.008 n=5+5)
IsZero/ArrayIncomparable 197ns ±10% 123ns ± 1% -37.74% (p=0.008 n=5+5)
IsZero/StructComparable 26.4ns ± 0% 9.6ns ± 1% -63.68% (p=0.016 n=4+5)
IsZero/StructIncomparable 43.5ns ± 1% 27.8ns ± 1% -36.21% (p=0.008 n=5+5)
The incomparable types gain a performance boost since
they are generally constructed from nested comparable types.
Change-Id: If2c1929f8bb1b5b19306ef0c69f3c95a27d4b60d
Reviewed-on: https://go-review.googlesource.com/c/go/+/411478
Reviewed-by: Dan Kortschak <dan@kortschak.io>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
As CL 422214 did, this CL intends to clean up the rest
unreachable "Continue" after Fatal.
Change-Id: I3b7e1b59bdfccb185e20525ce113e241d277dad3
Reviewed-on: https://go-review.googlesource.com/c/go/+/422514
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: hopehook <hopehook@qq.com>
[This is a retry of CL 407036 + its revert CL 422394. The only
content change is the 1-line change in cmd/internal/obj/objfile.go.]
Read the bitmaps one uintptr at a time instead of one byte at a time.
Performance so far:
Allocation heavy, no retention: ~30% faster in heapBitsSetType
Scan heavy, ~no allocation: ~even in scanobject
Change-Id: I04d899e1dbd23e989e9f552cdc1880318779c14c
Reviewed-on: https://go-review.googlesource.com/c/go/+/422635
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
[this is a retry of CL 407035 + its revert CL 422395. The content is unchanged]
Use just 1 bit per word to record the ptr/nonptr bitmap.
Use word-sized operations to manipulate the bitmap, so we can operate
on up to 64 ptr/nonptr bits at a time.
Use a separate bitmap, one bit per word of the ptr/nonptr bitmap,
to encode a no-more-pointers signal. Since we can check 64 ptr/nonptr
bits at once, knowing the exact last pointer location is not necessary.
As a followon CL, we should make the gcdata bitmap an array of
uintptr instead of an array of byte, so we can load 64 bits of it at once.
Similarly for the processing of gc programs.
Change-Id: Ica5eb622f5b87e647be64f471d67b02732ef8be6
Reviewed-on: https://go-review.googlesource.com/c/go/+/422634
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
The comment claims that reflect users cannot obtain an unsafe.Pointer
without also importing the unsafe package explicitly.
This is no longer true now that the Value.UnsafePointer method
directly returns an unsafe.Pointer.
Change-Id: Ia5bf2e8aead681c8fac5b011129954d075ae5a43
Reviewed-on: https://go-review.googlesource.com/c/go/+/404396
Reviewed-by: 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: Ian Lance Taylor <iant@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
This reverts commit b589208c8c.
Reason for revert: Bug somewhere in this code, causing wasm and maybe linux/386 to fail.
Change-Id: I5e1e501d839584e0219271bb937e94348f83c11f
Reviewed-on: https://go-review.googlesource.com/c/go/+/422395
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Keith Randall <khr@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This reverts commit c3833a5543.
Reason for revert: Bug somewhere in this code, causing wasm and maybe linux/386 to fail.
Change-Id: I05f7cfa467598ca0c2c84fd4f752cc4ef117cc51
Reviewed-on: https://go-review.googlesource.com/c/go/+/422394
Run-TryBot: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
So we don't have to duplicate the logic to detect noopt builder in
multiple places.
Based on khr@'s suggestion in CL 422037.
Change-Id: Idb338e8bc08cdf00460574bfc0d2f7018c79bbd5
Reviewed-on: https://go-review.googlesource.com/c/go/+/422038
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Calling TypeOf to initialize variables forces any import of "reflect"
to link in the declared types of "reflect" even if they are unused.
TypeOf operates on Type and which will pull in
all transitive dependencies of Type, which includes Value as well.
Avoid this problem by declaring a rtypeOf function that
directly extracts the *rtype from an interface value
without going through Type as an intermediate type.
For a program that blank imports "reflect",
this reduces the binary size by ~34 KiB.
Updates #54097
Change-Id: I8dc7d8da8fedc48cc0dd842b69f510d17144827e
Reviewed-on: https://go-review.googlesource.com/c/go/+/419757
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Read the bitmaps one uintptr at a time instead of one byte at a time.
Performance so far:
Allocation heavy, no retention: ~30% faster in heapBitsSetType
Scan heavy, ~no allocation: ~even in scanobject
Change-Id: I40d492b50d7f89d1b4261c2de58f6d255fa5e93e
Reviewed-on: https://go-review.googlesource.com/c/go/+/407036
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Use just 1 bit per word to record the ptr/nonptr bitmap.
Use word-sized operations to manipulate the bitmap, so we can operate
on up to 64 ptr/nonptr bits at a time.
Use a separate bitmap, one bit per word of the ptr/nonptr bitmap,
to encode a no-more-pointers signal. Since we can check 64 ptr/nonptr
bits at once, knowing the exact last pointer location is not necessary.
This cleans up the bitmap implementation significantly, which will
hopefully make it faster. TODO: measure
As a followon CL, we should make the gcdata bitmap an array of
uintptr instead of an array of byte, so we can load 64 bits of it at once.
Similarly for the processing of gc programs.
Change-Id: I18151b1876d9543599800dec51e2a1b19df97d49
Reviewed-on: https://go-review.googlesource.com/c/go/+/407035
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Change-Id: Icb552dc7106afbf6bd4bd3660d632f174153f834
Reviewed-on: https://go-review.googlesource.com/c/go/+/408914
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Previously we stole a bit from the field offset to encode whether
a struct field was embedded.
Instead, encode that bit in the name field, where we already have
some unused bits to play with. The bit associates naturally with
the name in any case.
This leaves a full uintptr to specify field offsets. This will make
the fix for #52740 cleaner.
Change-Id: I0bfb85564dc26e8c18101bc8b432f332176d7836
Reviewed-on: https://go-review.googlesource.com/c/go/+/412138
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
This reverts CL 401434.
Reason for revert: We should't deprecate these without a replacement.
Fixes#53079
Change-Id: I5515b03e39787d4e528a98c733cdb643b86b17ce
Reviewed-on: https://go-review.googlesource.com/c/go/+/408815
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
The code comment says that the receiver doesn't need to go into
the pointer slot as it will be kept alive in this frame. But it
doesn't. There is no direct reference of rcvr or v (the receiver)
after storing the arguments. Also, it is clearer to explicitly
keep it alive.
Fixes#52800.
Change-Id: Ie3fa8e83f6ecc69d62e8bfab767314d5181f5dc0
Reviewed-on: https://go-review.googlesource.com/c/go/+/407508
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Contributors to the loong64 port are:
Weining Lu <luweining@loongson.cn>
Lei Wang <wanglei@loongson.cn>
Lingqin Gong <gonglingqin@loongson.cn>
Xiaolin Zhao <zhaoxiaolin@loongson.cn>
Meidan Li <limeidan@loongson.cn>
Xiaojuan Zhai <zhaixiaojuan@loongson.cn>
Qiyuan Pu <puqiyuan@loongson.cn>
Guoqi Chen <chenguoqi@loongson.cn>
This port has been updated to Go 1.15.6:
https://github.com/loongson/go
Updates #46229
Change-Id: I2ad9ed01fc913b90e75023ac0fa70de87a9f5de1
Reviewed-on: https://go-review.googlesource.com/c/go/+/342324
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Change-Id: I47e1cc261fdcd6f83a8593893b979d130150d0b2
Reviewed-on: https://go-review.googlesource.com/c/go/+/407174
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
As discussed in CL 401434 there are substantial misuses of these in the
wild, and they are a potential source of unsafety even for code that
does not use them directly.
We should either keep them as-is and document when/how they can be used
safely, or deprecate them so that uses will eventually die out.
After some discussion, it was decided to deprecate them outright.
Since the docs already mentioned that they may be unstable across
releases, it should be possible to get rid of them completely later on.
Change-Id: I3b75819409177b5a286c1e9861a2edb6fd1301b8
Reviewed-on: https://go-review.googlesource.com/c/go/+/401434
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
This CL implement archFloat32FromReg and archFloat32ToReg
need for riscv64 due to differences in the way float32 are
represented in registers as compared to other platforms.
Change-Id: I5eab27df242f84b387b0c8dc7f347c93b3fd9df0
Reviewed-on: https://go-review.googlesource.com/c/go/+/403134
Run-TryBot: mzh <mzh@golangcn.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
methodName was brittle in that it assumed exactly where
in the call stack the exported Value method is.
This broke since recent inlining optimizations changed
exactly which frame the exported method was located.
Instead, iterate through a sufficient number of stack entries
and dynamically determined the exported Value method name.
This is more maintainable, but slightly slower.
The slowdown is acceptable since panics are not the common case.
Change-Id: I9fc939627007d7bae004b4969516ad44be09c270
Reviewed-on: https://go-review.googlesource.com/c/go/+/403494
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
Fixes#52411
Change-Id: I2fd13a453622992c52d49aade7cd058cfc8a77ca
GitHub-Last-Rev: d5987c2ec8
GitHub-Pull-Request: golang/go#52423
Reviewed-on: https://go-review.googlesource.com/c/go/+/400954
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Keith Randall <khr@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
The following Value methods are now inlineable:
Bool for ~bool
String for ~string (but not other kinds)
Bytes for []byte (but not ~[]byte or ~[N]byte)
Len for ~[]T (but not ~[N]T, ~chan T, ~map[K]V, or ~string)
Cap for ~[]T (but not ~[N]T or ~chan T)
For Bytes, we only have enough inline budget to inline one type,
so we optimize for unnamed []byte, which is far more common than
named []byte or [N]byte.
For Len and Cap, we only have enough inline budget to inline one kind,
so we optimize for ~[]T, which is more common than the others.
The exception is string, but the size of a string can be obtained
through len(v.String()).
Performance:
Bool 1.65ns ± 0% 0.51ns ± 3% -68.81% (p=0.008 n=5+5)
String 1.97ns ± 1% 0.70ns ± 1% -64.25% (p=0.008 n=5+5)
Bytes 8.90ns ± 2% 0.89ns ± 1% -89.95% (p=0.008 n=5+5)
NamedBytes 8.89ns ± 1% 8.88ns ± 1% ~ (p=0.548 n=5+5)
BytesArray 10.0ns ± 2% 10.2ns ± 1% +1.58% (p=0.048 n=5+5)
SliceLen 1.97ns ± 1% 0.45ns ± 1% -77.22% (p=0.008 n=5+5)
MapLen 2.62ns ± 1% 3.07ns ± 1% +17.24% (p=0.008 n=5+5)
StringLen 1.96ns ± 1% 1.98ns ± 2% ~ (p=0.151 n=5+5)
ArrayLen 1.96ns ± 1% 2.19ns ± 1% +11.46% (p=0.008 n=5+5)
SliceCap 1.76ns ± 1% 0.45ns ± 2% -74.28% (p=0.008 n=5+5)
There's a slight slowdown (~10-20%) for obtaining the length
of a string or map, but a substantial improvement for slices.
Performance according to encoding/json:
CodeMarshal 555µs ± 2% 562µs ± 4% ~ (p=0.421 n=5+5)
MarshalBytes/32 163ns ± 1% 157ns ± 1% -3.82% (p=0.008 n=5+5)
MarshalBytes/256 453ns ± 1% 447ns ± 1% ~ (p=0.056 n=5+5)
MarshalBytes/4096 4.10µs ± 1% 4.09µs ± 0% ~ (p=1.000 n=5+4)
CodeUnmarshal 3.16ms ± 2% 3.02ms ± 1% -4.18% (p=0.008 n=5+5)
CodeUnmarshalReuse 2.64ms ± 3% 2.51ms ± 2% -4.81% (p=0.016 n=5+5)
UnmarshalString 65.4ns ± 4% 64.1ns ± 0% ~ (p=0.190 n=5+4)
UnmarshalFloat64 59.8ns ± 5% 58.9ns ± 2% ~ (p=0.222 n=5+5)
UnmarshalInt64 51.7ns ± 1% 50.0ns ± 2% -3.26% (p=0.008 n=5+5)
EncodeMarshaler 23.6ns ±11% 20.8ns ± 1% -12.10% (p=0.016 n=5+4)
Add all inlineable methods of Value to cmd/compile/internal/test/inl_test.go.
Change-Id: Ifc192491918af6b62f7fe3a094a5a5256bfb326d
Reviewed-on: https://go-review.googlesource.com/c/go/+/400676
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Also correct parameter name in comment.
Change-Id: Ic9486e08c2eea184faccf181cda7da808793def6
Reviewed-on: https://go-review.googlesource.com/c/go/+/400674
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dan Kortschak <dan@kortschak.io>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
overflowPad variable in bucketOf function is a holdover from a NaCl port
and never used now.
Change-Id: Ib68fdb054e1b6a655ffbfd34521a3f8773a22694
GitHub-Last-Rev: f281be9c11
GitHub-Pull-Request: golang/go#52449
Reviewed-on: https://go-review.googlesource.com/c/go/+/401274
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Change-Id: If2887f84b3d14fac3c059fc5bad4186ec9d69d0f
Reviewed-on: https://go-review.googlesource.com/c/go/+/401077
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Keith Randall <khr@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
hopehook
Joe Tsai
Michael Anthony Knyszek
Zeke Lu
Cuong Manh Le
Ian Lance Taylor
cuiweixie
Keith Randall
Keith Randall
Koichi Shiraishi
Cherry Mui
Xiaodong Liu
Mostafa Solati
Carlo Alberto Ferraris
Meng Zhuo
Dan Kortschak
Phil Kulin