I've dropped the note that sched.timeToRun is protected by sched.lock,
as it does not seem to be true.
For #53821.
Change-Id: I03f8dc6ca0bcd4ccf3ec113010a0aa39c6f7d6ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/419449
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
This converts a few unsynchronized accesses.
For #53821.
Change-Id: Ie2728779111e3e042696f15648981c5d5a86ca6d
Reviewed-on: https://go-review.googlesource.com/c/go/+/419448
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Note that this replaces numerous unsynchronized loads throughout the
scheduler.
For #53821.
Change-Id: Ica80b04c9e8c184bfef186e549526fc3f117c387
Reviewed-on: https://go-review.googlesource.com/c/go/+/419447
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Note that this converts nmspinning from uint32 to int32 for consistency
with the other count fields in schedt.
For #53821.
Change-Id: Ia6ca7a2b476128eda3b68e9f0c7775ae66c0c744
Reviewed-on: https://go-review.googlesource.com/c/go/+/419446
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Note that this converts npidle from uint32 to int32 for consistency with
the other count fields in schedt and the type of p.id.
Note that this changes previously unsynchronized operations to
synchronized operations in:
* handoffp
* injectglist
* schedtrace
* schedEnableUser
* sync_runtime_canSpin
For #53821.
Change-Id: I36d1b3b4a28131c9d47884fade6bc44439dd6937
Reviewed-on: https://go-review.googlesource.com/c/go/+/419445
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Note that this converts ngsys from uint32 to int32 to match the other
(non-atomic) counters.
For #53821.
Change-Id: I3acbfbbd1dabc59b0ea5ddc86a97e0d0afa9f80c
Reviewed-on: https://go-review.googlesource.com/c/go/+/419444
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Note that this converts pollUntil from uint64 to int64, the type used by
nanotime().
For #53821.
Change-Id: Iec9ec7e09d3350552561d0708ba6ea9e8a8ae7ab
Reviewed-on: https://go-review.googlesource.com/c/go/+/419443
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Note that this changes the type from uint64 to int64, the type used by
nanotime(). It also adds an atomic load in pollWork(), which used to use
a non-atomic load.
For #53821.
Change-Id: I6173c90f20bfdc0e0a4bc3a7b1c798d1c429fff5
Reviewed-on: https://go-review.googlesource.com/c/go/+/419442
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
We currently print these as -1, but some are technically uint64. We can
be more explicit about their irrelevance by printing 'nil' rather than
-1.
Change-Id: I267fd8830564c75032bfe9176af59047f5a90202
Reviewed-on: https://go-review.googlesource.com/c/go/+/419441
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
schedt.goidgen and p.goidcache are already uint64, this makes all cases
consistent.
The only oddball here is schedtrace which prints -1 as an equivalent for
N/A or nil. A future CL will make this more explicit.
Change-Id: I489626f3232799f6ca333d0d103b71d9d3aa7494
Reviewed-on: https://go-review.googlesource.com/c/go/+/419440
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
If a program only uses ecdh.P256(), the implementation of the other
curves shouldn't end up in the binary. This mostly required moving some
operations from init() time. Small performance hit in uncompressed
Bytes/SetBytes, but not big enough to show up in higher-level
benchmarks. If it becomes a problem, we can fix it by pregenerating the
p-1 bytes representation in generate.go.
For #52182
Updates #52221
Change-Id: I64460973b59ee3df787d7e967a6c2bcbc114ba65
Reviewed-on: https://go-review.googlesource.com/c/go/+/402555
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Fernando Lobato Meeser <felobato@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
We use crypto/internal/edwards25519/field to implement X25519 directly,
so that golang.org/x/crypto/curve25519 can be dropped from the src
module dependencies, and eventually replaced with a crypto/ecdh wrapper,
removing the need to keep golang.org/x/crypto/curve25519/internal/field
in sync with crypto/internal/edwards25519/field.
In crypto/internal/nistec, we add BytesX to serialize only the x
coordinate, which we'll need for the horrible ECDSA x-coord-to-scalar
operation, too.
In crypto/tls, we replace the ECDHE implementation with crypto/ecdh,
dropping the X25519 special cases and related scaffolding.
Finally, FINALLY, we deprecate the ~white whale~ big.Int-based APIs of
the crypto/elliptic package. •_•) ( •_•)>⌐■-■ (⌐■_■)
Fixes#52182Fixes#34648Fixes#52221
Change-Id: Iccdda210319cc892e96bb28a0e7b7123551982c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/398914
Reviewed-by: Fernando Lobato Meeser <felobato@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
ONAME nodes are shared, so using their position for anything is almost
always a mistake. There are probably more instances of this mistake
elsewhere. For now, handle the case of map key temporaries, where it's
been a problem.
Fixes#53456.
Change-Id: Id44e845d08d428592ad3ba31986635b6b87b0041
Reviewed-on: https://go-review.googlesource.com/c/go/+/417076
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
For #47653Fixes#45599Fixes#52522
Change-Id: Id6a80186434080cb0a205978ad7f224252674604
Reviewed-on: https://go-review.googlesource.com/c/go/+/408679
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Now that we've moved the trace locks to the leaf of the lock graph, we
can safely annotate that any trace event may acquire trace.lock even
if dynamically it turns out a particular event doesn't need to flush
and acquire this lock.
This reveals a new edge where we can trace while holding the mheap
lock, so we add this to the lock graph.
For #53789.
Updates #53979.
Change-Id: I13e2f6cd1b621cca4bed0cc13ef12e64d05c89a7
Reviewed-on: https://go-review.googlesource.com/c/go/+/418720
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Now that trace.lock cannot be held over a stack split, we can move
that lock and traceStackTab to the leaf of the lock graph. We add a
couple edges to STACKGROW that were previously passing through trace.
Fixes#53979.
Change-Id: Ie664ff7bb33973745f991f7516dc6106e60f5892
Reviewed-on: https://go-review.googlesource.com/c/go/+/418957
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently, trace.lock can be acquired while on a user G and stack
splits can happen while holding trace.lock. That means every lock used
by the stack allocator must be okay to acquire while holding
trace.lock, including various locks related to span allocation. In
turn, we cannot safely emit trace events while holding any
allocation-related locks because this would cause a cycle in the lock
rank graph.
To fix this, require that trace.lock only be acquired on the system
stack, like mheap.lock. This pushes it into the "bottom half" and
eliminates the lock rank relationship between tracing and stack
allocation, making it safe to emit trace events in many more places.
One subtlety is that the trace code has race annotations and uses
maps, which have race annotations. By default, we can't have race
annotations on the system stack, so we borrow the user race context
for these situations.
We'll update the lock graph itself in the next CL.
For #53979. This CL technically fixes the problem, but the lock rank
checker doesn't know that yet.
Change-Id: I9f5187a9c52a67bee4f7064db124b1ad53e5178f
Reviewed-on: https://go-review.googlesource.com/c/go/+/418956
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
We're about to require that all uses of trace.lock be on the system
stack. That's mostly easy, except that it's involving parking the
trace reader. Fix this by changing that parking protocol so it instead
synchronizes through an atomic.
For #53979.
Change-Id: Icd6db8678dd01094029d7ad1c612029f571b4cbb
Reviewed-on: https://go-review.googlesource.com/c/go/+/418955
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Writing out the trace footer currently manages trace buffers
differently from the rest of trace code. Rearrange it so it looks like
the rest of the code. In particular, we now write the frequency event
out to the trace buffer rather than returning it in a special byte
slice, and (*traceStackTable).dump threads a traceBufPtr like most
other functions that write to the trace buffers.
Change-Id: I3d0e108e56df884e7bd19823310dfbc0e21af9a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/422974
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Following up on the previous CL, this CL removes a unnecessary stack
copy of a large object in a range loop. This drops another 64 KiB from
(*traceStackTable).dump's stack frame so it is now roughly 80 bytes
depending on architecture, which will easily fit on the system stack.
For #53979.
Change-Id: I16f642f6f1982d0ed0a62371bf2e19379e5870eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/422955
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Currently, the stack frame of (*traceStackTable).dump is 68KiB. We're
about to move (*traceStackTable).dump to the system stack, where we
often don't have this much room.
5140 bytes of this is an on-stack temporary buffer for constructing
potentially large trace events before copying these out to the actual
trace buffer.
Reduce the stack frame size by writing these events directly to the
trace buffer rather than temporary space. This introduces a couple
complications:
- The trace event starts with a varint encoding the event payload's
length in bytes. These events are large and somewhat complicated, so
it's hard to know the size ahead of time. That's not a problem with
the temporary buffer because we can just construct the event and see
how long it is. In order to support writing directly to the trace
buffer, we reserve enough bytes for a maximum size varint and add
support for populating a reserved space after the fact.
- Emitting a stack event calls traceFrameForPC, which can itself emit
string events. If these were emitted in the middle of the stack
event, it would corrupt the stream. We already allocate a []Frame to
convert the PC slice to frames, and then convert each Frame into a
traceFrame with trace string IDs, so we address this by combining
these two steps into one so that all trace string events are emitted
before we start constructing the stack event.
For #53979.
Change-Id: Ie60704be95199559c426b551f8e119b14e06ddac
Reviewed-on: https://go-review.googlesource.com/c/go/+/422954
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In go.dev/cl/413396, I implemented implicit conversions by setting the
conversion's position to the enclosing statement that necessitated the
conversion. However, users actually want the position information to
be at the expression itself, and this seems sensible anyway.
This was noticed because x/tools had a test for:
fmt.Println(42)
and it was checking where the escape analysis diagnostic for
`42` (really `any(42)`) was reported.
Historically, we reported the column of the `4`; but CL 413396 caused
unified IR to instead report the column of the `(` instead (the
position associated with the call expression, which forced `42` to be
implicitly converted from `int` to `any`).
I chalk this mistake up to being accustomed to working with ir, where
we can't reliably use n.Pos() because of how ONAME positions work, so
I was trying to avoid relying on the implicitly converted expression's
own position.
Change-Id: I762076af6f65ebe6d444d64630722a5016dc2698
Reviewed-on: https://go-review.googlesource.com/c/go/+/422976
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
I structured the test for issue54343.go after issue46725.go, where I
was careful to use `[4]int`, which is a type large enough to avoid the
tiny object allocator (which interferes with finalizer semantics). But
in that test, I didn't note the importance of that type, so I
mistakenly used just `int` in issue54343.go.
This CL switches issue54343.go to use `[4]int` too, and then adds
comments to both pointing out the significance of this type.
Updates #54343.
Change-Id: I699b3e64b844ff6d8438bbcb4d1935615a6d8cc4
Reviewed-on: https://go-review.googlesource.com/c/go/+/423115
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: David Chase <drchase@google.com>
Broken out of debug/pe. Update debug/pe to use it.
For #47653
Change-Id: Ib3037ee04073e005c4b435d0128b8437a075b00a
Reviewed-on: https://go-review.googlesource.com/c/go/+/408678
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dan Kortschak <dan@kortschak.io>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Version 2022b was released on 2022-08-10 and we can start using it.
Its release announcement was
https://mm.icann.org/pipermail/tz-announce/2022-August/000071.html.
For #22487.
Change-Id: I0ec68968d82561da566f945608bfacb3c8b0e958
Reviewed-on: https://go-review.googlesource.com/c/go/+/422875
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
With GOEXPERIMENT=unified, the order variables are printed in "live at
entry to f.func1" is sensitive to whether regabi is enabled for some
reason. The order shouldn't matter to correctness, but it is odd.
For now, this CL just relaxes the test expectation order to unblock
enabling GOEXPERIMENT=unified by default. I've filed #54402 to
investigate further to confirm this a concern.
Updates #54402.
Change-Id: Iddfbb12c6cf7cc17b2aec8102b33761abd5f93ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/422975
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
For selector expression "x.M" where "M" is a promoted method, irgen is using
the type of receiver "x" for determining the typeparams for instantiation.
However, because M is a promoted method, so its associated receiver is
not "x", but "x.T" where "T" is the embedded field of "x". That casues a
mismatch when converting non-shape types arguments.
Fixing it by using the actual receiver which has the method, instead of
using the base receiver.
Fixes#53982
Change-Id: I1836fc422d734df14e9e6664d4bd014503960bfc
Reviewed-on: https://go-review.googlesource.com/c/go/+/419294
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
When making the recursive call to fprint,
we just need to know how many bytes were written
and whether multiple lines were written.
We don't need a buffer to accomplish those;
a custom writer can keep track of the two in a cheap way,
avoiding the allocation of a byte slice and copying bytes.
name old time/op new time/op delta
Print-16 6.28ms ± 2% 6.12ms ± 1% -2.50% (p=0.000 n=10+9)
name old speed new speed delta
Print-16 8.26MB/s ± 3% 8.47MB/s ± 1% +2.56% (p=0.000 n=10+9)
name old alloc/op new alloc/op delta
Print-16 483kB ± 0% 443kB ± 0% -8.20% (p=0.000 n=10+10)
name old allocs/op new allocs/op delta
Print-16 17.8k ± 0% 17.3k ± 0% -2.31% (p=0.000 n=9+10)
Change-Id: Ib8411ae6738a2acae6af6d185da71727ce2eb97a
Reviewed-on: https://go-review.googlesource.com/c/go/+/412555
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
The current implementation of compilerVersion incorrectly gives an
error message that the compiler version is too old even though the
system has a recent compiler. This happens for specifically for the
gcc compiler and causes ASAN tests to be skipped.
Replacing -v with gcc dump version options seems to fix it. Running
./testsanitizers.test -test.v now shows the ASAN tests being run.
--- PASS: TestASAN (16.81s)
--- PASS: TestASAN/asan_useAfterReturn (0.60s)
--- PASS: TestASAN/asan_global5 (0.61s)
--- PASS: TestASAN/asan_unsafe_fail1 (0.73s)
--- PASS: TestASAN/asan_unsafe_fail3 (0.73s)
--- PASS: TestASAN/asan_unsafe_fail2 (0.74s)
--- PASS: TestASAN/asan_global4_fail (0.74s)
--- PASS: TestASAN/asan5_fail (0.74s)
--- PASS: TestASAN/asan3_fail (0.88s)
--- PASS: TestASAN/asan4_fail (0.89s)
--- PASS: TestASAN/asan2_fail (0.99s)
--- PASS: TestASAN/asan_global3_fail (1.00s)
--- PASS: TestASAN/asan_global1_fail (1.01s)
--- PASS: TestASAN/asan1_fail (1.01s)
--- PASS: TestASAN/asan_global2_fail (1.02s)
PASS
Fixes#54370
Change-Id: Iac13a1cf37de54432a6e49555f61e9ec1d781ab8
Reviewed-on: https://go-review.googlesource.com/c/go/+/422574
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Archana Ravindar <aravind5@in.ibm.com>
Reviewed-by: Than McIntosh <thanm@google.com>
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>
Using build tool tags instead of relying on GOAMD64 env, which can be
overriden at make.bash time.
Change-Id: I96bb4b7416ea0bd1ab552feec9ede45b89a584c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/422614
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
When trampolines are needed (e.g. Darwin ARM64), the DWARF LPT (Line
Program Table - see DWARF section 6.1) generation fails because the
replacement symbols are marked as external symbols and skipped during
the DWARF LPT generation phase.
Fixes#54320
Change-Id: I6c93f5378f50e5edf30d5121402a48214abb1ce2
GitHub-Last-Rev: 085bbc55db
GitHub-Pull-Request: golang/go#54321
Reviewed-on: https://go-review.googlesource.com/c/go/+/422154
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Change the type of Conn.handshakeStatus from an atomically
accessed uint32 to an atomic.Bool. Change its name to
Conn.isHandshakeComplete to indicate it is a boolean value.
Eliminate the handshakeComplete() helper function, which checks
for equality with 1, in favor of the simpler
c.isHandshakeComplete.Load().
Change-Id: I084c83956fff266e2145847e8645372bef6ae9df
Reviewed-on: https://go-review.googlesource.com/c/go/+/422296
Auto-Submit: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
This CL adds a helper expression code for receiver addressing; i.e.,
the implicit addressing, dereferencing, and field selections involved
in changing the `x` in `x.M()` into an appropriate expression to pass
as an argument to the method.
Change-Id: I9be933e2a38c8f94f6a85d95b54f34164e5efb0a
Reviewed-on: https://go-review.googlesource.com/c/go/+/421820
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Unified IR uses static dictionaries for some itabs and function/method
expressions, and they're roughly the right idea. But at the same time,
they're actually somewhat brittle and I need to reorganize some ideas
anyway to get shaped-based stenciling working. So this CL just rips
them out entirely.
Note: the code for emitting runtime dictionaries with *runtime._type
symbols is still present, and continues to demonstrate that basic
runtime dictionary handling is working.
Change-Id: I44eb1c7974fb397909ad5db12987659e7505c2ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/421819
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL separates out the handling of selector expressions for field
values, method values, and method expressions. Again part of
refactoring to make it possible to access runtime dictionaries where
needed.
No behavioral change; just duplicating and then streamlining the
existing code paths.
Change-Id: I53b2a344f4bdba2c9f37ef370dc9a091a3941021
Reviewed-on: https://go-review.googlesource.com/c/go/+/421818
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
This CL changes unified IR to explicitly handle function
instantiations within expression handling, rather than leaving it to
the underlying object reading logic.
Change-Id: I009a56013fbe9fbc4dabf80eea98993d34af4272
Reviewed-on: https://go-review.googlesource.com/c/go/+/421817
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
There was a TODO about quadratic performance, and indeed,
it can get bad. Added a map, made some integers that are
unlikely to exceed a few million into 32-bit integers.
Change-Id: I6facf2eabc00483e943b326ca8dcae2f778093da
Reviewed-on: https://go-review.googlesource.com/c/go/+/422297
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This CL applies the same change to test/live.go that was previously
applied to test/live_regabi.go in golang.org/cl/415240. This wasn't
noticed at the time though, because GOEXPERIMENT=unified was only
being tested on linux-amd64, which is a regabi platform.
Change-Id: I0c75c2b7097544305e4174c2f5ec6ec283c81a8e
Reviewed-on: https://go-review.googlesource.com/c/go/+/422254
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
`go env GOEXPERIMENT` prints what experiments are enabled relative to
the baseline configuration, so it's not a very robust way to detect
what experiments have been statically enabled at bootstrap time.
Instead, we can check build.Default.ToolTags, which has goexperiment.*
for all currently enabled experiments, independent of baseline.
Change-Id: I6132deaa73b1e79ac24176ef4de5af67a507ee26
Reviewed-on: https://go-review.googlesource.com/c/go/+/422234
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
