In case of a handshake timeout, the goroutine running addTLS
closes the underlying connection, which should unblock the call
to tlsConn.HandshakeContext. However, it didn't then wait for
HandshakeContext to actually return.
I thought this might have something to do with #57602, but as
far as I can tell it does not. Still, it seems best to avoid the leak:
if tracing is enabled we emit a TLSHandshakeDone event, and it seems
misleading to produce that event when the handshake is still in
progress.
For #57602.
Change-Id: Ibfc0cf4ef8df2ccf11d8897f23d7d79ee482d5fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/529755
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Commit-Queue: Bryan Mills <bcmills@google.com>
Add compiler support for range over functions.
See the large comment at the top of
cmd/compile/internal/rangefunc/rewrite.go for details.
This is only reachable if GOEXPERIMENT=range is set,
because otherwise type checking will fail.
For proposal #61405 (but behind a GOEXPERIMENT).
For #61717.
Change-Id: I05717f94e63089c503acc49b28b47edeb4e011b4
Reviewed-on: https://go-review.googlesource.com/c/go/+/510541
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
Add compiler implementation of range over integers.
This is only reachable if GOEXPERIMENT=range is set,
because otherwise type checking will fail.
For proposal #61405 (but behind a GOEXPERIMENT).
For #61717.
Change-Id: I4e35a73c5df1ac57f61ffb54033a433967e5be51
Reviewed-on: https://go-review.googlesource.com/c/go/+/510538
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
Add type-checking logic for range over integers and functions,
behind GOEXPERIMENT=range.
For proposal #61405 (but behind a GOEXPERIMENT).
For #61717.
Change-Id: Ibf78cf381798b450dbe05eb922df82af2b009403
Reviewed-on: https://go-review.googlesource.com/c/go/+/510537
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Currently, for the shared build mode, we don't generate the module
inittasks. Instead, we rely on the main executable to do the
initialization, for both the executable and the shared library.
But, with the model as of CL 478916, the main executable only
has relocations to packages that are directly imported. It won't
see the dependency edges between packages within a shared library.
Therefore indirect dependencies are not included, and thus not
initialized. E.g. main imports a, which imports b, but main
doesn't directly import b. a and b are in a shared object. When
linking main, it sees main depends on a, so it generates main's
inittasks to run a's init before main's, but it doesn't know b,
so b's init doesn't run.
This CL makes it initialize all packages in a shared library when
the library is loaded, as any of them could potentially be
imported, directly or indirectly.
Also, in the runtime, when running the init functions, make sure
to go through the DSOs in dependency order. Otherwise packages
can be initialized in the wrong order.
Fixes#61973.
Change-Id: I2a090336fe9fa0d6c7e43912f3ab233c9c47e247
Reviewed-on: https://go-review.googlesource.com/c/go/+/520375
Reviewed-by: Than McIntosh <thanm@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
We don't index multis, so a corpus full of them will take quadratic
time to check for conflicts. How slow is that going to be in practice?
This benchmark indexes and checks a thousand multi patterns, all disjoint.
It runs in about 35ms.
Change-Id: Id27940ab19ad003627bd5c43c53466e01456b796
Reviewed-on: https://go-review.googlesource.com/c/go/+/529477
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Replace the fuzz test with one that enumerates all relevant patterns
up to a certain length.
For conflict detection, we don't need to check every possible method,
host and segment, only a few that cover all the possibilities. There
are only 2400 distinct patterns in the corpus we generate, and the
test generates, indexes and compares them all in about a quarter of a
second.
Change-Id: I9fde88e87cec07b1b244306119e4e71f7205bb77
Reviewed-on: https://go-review.googlesource.com/c/go/+/529556
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
[This is an unmodified redo of CL 527056.]
Standard Ms set g0.stackguard1 to the same value as stackguard0 in
mstart0. For consistency, extra Ms should do the same for their g0. Do
this in needm -> callbackUpdateSystemStack.
Background: getg().stackguard1 is used as the stack guard for the stack
growth prolouge in functions marked //go:systemstack [1]. User Gs set
stackguard1 to ^uintptr(0) so that the check always fail, calling
morestackc, which throws to report a //go:systemstack function call on a
user stack.
g0 setting stackguard1 is unnecessary for this functionality. 0 would be
sufficient, as g0 is always allowed to call //go:systemstack functions.
However, since we have the check anyway, setting stackguard1 to the
actual stack bound is useful to detect actual stack overflows on g0
(though morestackc doesn't detect this case and would report a
misleading message about user stacks).
[1] cmd/internal/obj calls //go:systemstack functions AttrCFunc. This is
a holdover from when the runtime contained actual C functions. But since
CL 2275, it has simply meant "pretend this is a C function, which would
thus need to use the system stack". Hence the name morestackc. At this
point, this terminology is pretty far removed from reality and should
probably be updated to something more intuitive.
Change-Id: If315677217354465fbbfbd0d406d79be20db0cc3
Reviewed-on: https://go-review.googlesource.com/c/go/+/527716
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Track the offset in the pattern string being parsed so we can show it
in the error message.
Change-Id: I495b99378d866f359f45974ffc33587e2c1e366d
Reviewed-on: https://go-review.googlesource.com/c/go/+/529123
Run-TryBot: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
It can be difficult to tell at a glance why two patterns conflict, so
explain it with example paths.
Change-Id: Ie384f0a4ef64f30e6e6898bce4b88027bc81034b
Reviewed-on: https://go-review.googlesource.com/c/go/+/529122
Run-TryBot: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Add an index so that pattern registration isn't always quadratic.
If there were no index, then every pattern that was registered would
have to be compared to every existing pattern for conflicts. This
would make registration quadratic in the number of patterns, in every
case.
The index in this CL should help most of the time. If a pattern has a
literal segment, it will weed out all other patterns that have a
different literal in that position.
The worst case will still be quadratic, but it is unlikely that a set
of such patterns would arise naturally.
One novel (to me) aspect of the CL is the use of fuzz testing on data
that is neither a string nor a byte slice. The test uses fuzzing to
generate a byte slice, then decodes the byte slice into a valid
pattern (most of the time). This test actually caught a bug: see
https://go.dev/cl/529119.
Change-Id: Ice0be6547decb5ce75a8062e4e17227815d5d0b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/529121
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
The riscv64 assembler and linker generate three types of calls.
Most calls are made via a single JAL instruction, however this is
limited to +/-1MB of text. In the case where a call target is
unreachable (or unknown), the JAL targets an AUIPC+JALR trampoline.
All other cases use AUIPC+JALR pairs, including the case where a
single function exceeds 1MB in text size, potentially making it
impossible to reach trampolines.
Currently, the single instruction JAL call is marked with R_RISCV_CALL
and the two instruction AUIPC+JALR call is marked with
R_RISCV_PCREL_ITYPE, which is also used for memory load instructions.
This means that we have no way to identify that the latter is a call.
Switch to using R_RISCV_CALL to mark the AUIPC+JALR pair (aligning
somewhat with the elf.R_RISCV_CALL, which is deprecated in favour of
elf.R_RISCV_CALL_PLT). Add R_RISCV_JAL and use this to mark the single
instruction JAL direct calls. This is clearer and allows us to map
elf.R_RISCV_CALL_PLT to Go's R_RISCV_CALL.
Add all three types to IsDirectCall, so that direct calls are correctly
identified when a function exceeds 1MB of text.
Fixes#62465
Change-Id: Id3eea09688a2b7d6e481eae9ed0aa0d1f9a3a48f
Reviewed-on: https://go-review.googlesource.com/c/go/+/520095
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Than McIntosh <thanm@google.com>
Previously the test used an unbuffered channel, but testConn.Close
sends to it with a select-with-default, so the send would be dropped
if the test goroutine happened not to have parked on the receive yet.
To make this kind of bug less likely in future tests, use a
newTestConn helper function instead of constructing testConn channel
literals in each test individually.
Fixes#62622.
Change-Id: I016cd0a89cf8a2a748ed57a4cdbd01a178f04dab
Reviewed-on: https://go-review.googlesource.com/c/go/+/529475
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
When a PGO build fails or produces incorrect program, it is often
unclear what the problem is. Add pgo hash so we can bisect to
individual optimization decisions, which often helps debugging.
Related to #58153.
Change-Id: I651ffd9c53bad60f2f28c8ec2a90a3f532982712
Reviewed-on: https://go-review.googlesource.com/c/go/+/528400
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
CL 457995 introduced syscall_linux_accept.go which is used on linux/arm
to generate accept and use it in Accept. However, that CL forgot to
include the file in the list of files used with mksyscall.pl to generate
the syscall wrappers. This lead to accept no longer being generated when
re-running mkall.sh on linux/arm.
Change-Id: I7747399afae47a883a7fb079c82e835b90f366cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/529055
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Commit-Queue: Tobias Klauser <tobias.klauser@gmail.com>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
This test checks a behavior of GOTOOLCHAIN when an appropriate
toolchain is found in PATH. That requires it to exclude any suitable
toolchain binaries from the user's $PATH, which may otherwise
interfere.
Fixes#62709.
Change-Id: Ie9161e52d33a65be0b5265cb49e9f2bc8473e057
Reviewed-on: https://go-review.googlesource.com/c/go/+/529217
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
combineRelationships was wrong on one case: if one part of a pattern
overlaps and the other is disjoint, the result is disjoint, not overlaps.
For example:
/a/{x}/c
/{x}/b/d
Here the prefix consisting of the first two segments overlaps, but the
third segments are disjoint. The patterns as a whole are disjoint.
comparePaths was wrong in a couple of ways:
First, the loop shouldn't exit early when it sees an overlap,
for the reason above: later information may change that.
Once the loop was allowed to continue, we had to handle the "overlaps"
case at the end. The insight there, which generalized the existing
code, is that if the shorter path ends in a multi, that multi matches
the remainder of the longer path and more. (It must be "and more": the
longer path has at least two segments, so it couldn't match one
segment while the shorter path's multi can.) That means we can treat
the result as the combination moreGeneral and the relationship of the
common prefix.
Change-Id: I11dab2c020d820730fb38296d9d6b072bd2a5350
Reviewed-on: https://go-review.googlesource.com/c/go/+/529119
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In 'go test -json' we expect stdout to contain only JSON events,
not unstructured text. Unstructured text should either go to stderr
or be wrapped in a JSON event.
(If we add structured build output in #62067, we can emit this output
as a build event instead of a test event.)
Fixes#35169.
For #54378.
Change-Id: Ibedd28e79b5adf8d6ae56165b9f0393b14ece9aa
Reviewed-on: https://go-review.googlesource.com/c/go/+/529120
Reviewed-by: Austin Clements <austin@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Run 'unconvert -safe -apply' (https://github.com/mdempsky/unconvert)
Change-Id: I24b7cd7d286cddce86431d8470d15c5f3f0d1106
GitHub-Last-Rev: 022e75384c
GitHub-Pull-Request: golang/go#62662
Reviewed-on: https://go-review.googlesource.com/c/go/+/528696
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Change-Id: I11d0947d6d2ffa91745c8e36a3984ffee85abbd0
Reviewed-on: https://go-review.googlesource.com/c/go/+/528896
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
To get them to pass, implement more fake syscalls.
To make those syscalls easier to reason about, replace
the use of sync.Cond with selectable channels.
Fixes#59718.
Fixes#50216.
Change-Id: I135a6656f5c48f0e5c43dc4d4bcbdb48ee5535d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/526117
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Achille Roussel <achille.roussel@gmail.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The afterFuncContext type, used only in tests, contains a
set of registered afterfuncs indexed by an arbitrary unique key.
That key is currently a *struct{}. Unfortunately, all
*struct{} pointers are equal to each other, so all registered
funcs share the same key. Fortunately, the tests using this
type never register more than one afterfunc.
Change the key to a *byte.
Change-Id: Icadf7d6f258e328f6e3375846d29ce0f98b60924
Reviewed-on: https://go-review.googlesource.com/c/go/+/526655
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
While it is possible to embed a GNU build ID into the linked
executable by passing `-B 0xBUILDID` to the linker, the build ID will
need to be precomputed by the build system somehow. This makes it
unnecessarily complex to generate a deterministic build ID as it
either requires the build system to hash all inputs manually or to
build the binary twice, once to compute its hash and once with the GNU
build ID derived from that hash. Despite being complex, it is also
inefficient as it requires the build system to duplicate some of the
work that the Go linker already performs anyway.
Introduce a new argument "gobuildid" that can be passed to `-B` that
causes the linker to automatically derive the GNU build ID from the Go
build ID. Given that the Go build ID is deterministically computed
from all of its inputs, the resulting GNU build ID should be
deterministic in the same way, which is the desired behaviour.
Furthermore, given that the `-B` flag currently requires a "0x" prefix
for all values passed to it, using "gobuildid" as value is a backwards
compatible change.
An alternative would be to unconditionally calculate the GNU build ID
unless otherwise specified. This would require some larger rework
though because building the Go toolchain would not converge anymore
due the GNU build ID changing on every stage, which in turn would
cause the Go build ID to change as well.
Fixes#41004
Change-Id: I707c5fc321749c00761643d6cc79d44bf2cd744d
GitHub-Last-Rev: 5483305a85
GitHub-Pull-Request: golang/go#61469
Reviewed-on: https://go-review.googlesource.com/c/go/+/511475
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Apparently it falls into infinite printing loop. Skipping for now.
Will investigate.
For #62671.
Change-Id: I5be8e8c1d0f4f2eaa231d6bcdfe13e7f08c28b98
Reviewed-on: https://go-review.googlesource.com/c/go/+/528403
Reviewed-by: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Clang 14+ introduced a warning when using mixed packed and unpacked structs.
This can cause problems when taking an address of the unpacked struct, which
may end up having a different alignment than expected.
This is not a problem in cgo, which does not take pointers from the packed
struct.
Updated version of https://go.dev/cl/526915, which includes
"-Wunknown-warning-option" for compilers that do not have the specific flag.
Fixes#62480
Change-Id: I788c6604d0ed5267949f4367f148fa26d2116f51
Reviewed-on: https://go-review.googlesource.com/c/go/+/528935
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Change immIFits to return an error in the case that it does not fit.
This allows for deduplication and consistency of error messages.
Additionally, since we've already calculated the min and max values,
we can easily include these in the message. Also provide and use
immEven, for the same reasons.
Change-Id: Ie680558744f3e9bc19d6913c4144ce9ddbd0429c
Reviewed-on: https://go-review.googlesource.com/c/go/+/523458
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Mark Ryan <markdryan@rivosinc.com>
Run-TryBot: M Zhuo <mzh@golangcn.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: M Zhuo <mzh@golangcn.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
If the call to ReadString returns an error, the closure in
testServerGracefulClose will return an error and retry the test with a
longer timeout. If that happens, we need to wait for the conn.Write
goroutine to complete so that we don't leak connections across tests.
Updates #57084.
Fixes#62643.
Change-Id: Ia86c1bbd0a5e5d0aeccf4dfeb994c19d1fb10b00
Reviewed-on: https://go-review.googlesource.com/c/go/+/528398
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Not sure why this bug didn't cause a complete failure, but it
certainly makes for doing a lot more work than is necessary.
Fixes#62604
Change-Id: If0be4acb6eafc3d7eeb42d2f4263c21b4e6e1c7d
Reviewed-on: https://go-review.googlesource.com/c/go/+/527699
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
The failure observed in
https://build.golang.org/log/766ad55d098ee1979ba1ae261e0813063567743e
appears to be spurious. If it is, this change will fix it.
If it is not, and somehow the Read has deadlocked,
then this change will help to diagnose it
(by causing the test to time out and dump its running goroutines).
For #56196.
Change-Id: Ic74f018384a64e95566a5b5d8126cbd59ab5e5fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/528399
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
When a filesystem with non-regular files is used
the resulting files inside the zip archive are empty.
In this case we can be explicit and return an error.
Fixes#61875
Change-Id: I1aeac544521002e0c4bad328e73f51852ad4eee3
GitHub-Last-Rev: 5e53dcfd7c
GitHub-Pull-Request: golang/go#61876
Reviewed-on: https://go-review.googlesource.com/c/go/+/517475
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Mauri de Souza Meneguzzo <mauri870@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: David Chase <drchase@google.com>
If no pattern matches a request, but a pattern would have
matched if the request had a different method, then
serve a 405 (Method Not Allowed), and populate the
"Allow" header with the methods that would have succeeded.
Updates #61640.
Change-Id: I0ae9eb95e62c71ff7766a03043525a97099ac1bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/528401
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reject -R value that is not a power of 2, or less than 4K.
Fixes#62660.
Change-Id: I3fa33c23c25311a93c0accc9acbd1e465789b8c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/528715
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Preparation for Alias type nodes. Using a predicate will ensure
that alias indirection can be taken care of when needed, eventually.
Change-Id: I689fab6052060eb6bcb2eeac28ba09fdb73f6868
Reviewed-on: https://go-review.googlesource.com/c/go/+/528695
Reviewed-by: Heschi Kreinick <heschi@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>
If the rotate argument is the constant 0, rlwnm may be generated
instead of rlwinm. In all reasonable cases, this is OK as R0 should
hold 0. However, this could be problematic in some cases when
writing PPC64 assembly.
This consolidates the RLWNM and RLWMI optab entries. Invalid RLWMI
usage is still rejected, however the error will be be slightly
different. The invalid usage will be caught in oprrr instead of oplook.
Change-Id: I9958bd24660fea5f8fc9e3e50d51daa7349e3206
Reviewed-on: https://go-review.googlesource.com/c/go/+/527275
Reviewed-by: Heschi Kreinick <heschi@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
As pointed by @bcmills, upstream fixed this in 3.1.0 in 30143860ceFixes#62620.
Change-Id: I9fa179a5293aec59496ddd401edec02e1080f1a5
GitHub-Last-Rev: 6066b05054
GitHub-Pull-Request: golang/go#62652
Reviewed-on: https://go-review.googlesource.com/c/go/+/528437
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
There is no need to handwrite the "last" function, the bytealg package already provides "LastIndexByteString".
Change-Id: I6000705bffe8450a10cf8f3fa716a8d4605ada1f
GitHub-Last-Rev: 6627c65fb4
GitHub-Pull-Request: golang/go#62647
Reviewed-on: https://go-review.googlesource.com/c/go/+/527976
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Add a post-processing pass that updates the scores on callsites based
on how their results are used. This is similar to the "param feeds
unmodified into <XXX>" heuristics, but applies to returned results
instead: if we know that function F always returns a constant, and we
can see that the result from a given call feeds unmodified into an
if/switch, then decrease the score on the call to encourage inlining.
Change-Id: If513765c79d868cbdf672facbff9d92ad24f909e
Reviewed-on: https://go-review.googlesource.com/c/go/+/521819
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Minor changes to debug tracing and to the -d=dumpinlfuncprops
debug flag implementation.
Change-Id: Ibaefd489c94675ac7f5a04ec0331b7f888c15a49
Reviewed-on: https://go-review.googlesource.com/c/go/+/521818
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Make use of the "never returns" flag bit in ir.Func when computing
function properties: update the bit when we're done looking at a given
function, and read the bit from imported functions during flag
analysis. The advantage of using the ir.Func flag is that it will get
set (and will propagate through to export data) for all functions,
nost just those that are inline candidates.
Change-Id: I7002364b2c4ff5424ed70748fad87fad1a9e4786
Reviewed-on: https://go-review.googlesource.com/c/go/+/518257
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Add a new debug flag "-d=dumpinlcallsitescores" that dumps out a
summary of all callsites in the package being compiled with info on
inlining heuristics, for human consumption. Sample output lines:
Score Adjustment Status Callee CallerPos ScoreFlags
...
115 40 DEMOTED cmd/compile/internal/abi.(*ABIParamAssignment).Offset expand_calls.go:1679:14|6 panicPathAdj
...
76 -5 PROMOTED runtime.persistentalloc mcheckmark.go:48:45|3 inLoopAdj
...
201 0 --- PGO unicode.DecodeRuneInString utf8.go:312:30|1
...
7 -5 --- PGO internal/abi.Name.DataChecked type.go:625:22|0 inLoopAdj
Here "Score" is the final score calculated for the callsite,
"Adjustment" is the amount added to or subtracted from the original
hairyness estimate to form the score. "Status" shows whether anything
changed with the site -- did the adjustment bump it down just below
the threshold ("PROMOTED") or instead bump it above the threshold
("DEMOTED") or did nothing happen as a result of the heuristics
("---"); "Status" also shows whether PGO was involved. "Callee" is the
name of the function called, "CallerPos" is the position of the
callsite, and "ScoreFlags" is a digest of the specific properties we
used to make adjustments to callsite score via heuristics.
Change-Id: Iea4b1cbfee038bc68df6ab81e9973f145636300b
Reviewed-on: https://go-review.googlesource.com/c/go/+/513455
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Introduce a new mode of execution for instrumenting packages that have
no test files. Instead of just skipping packages with no test files
(during "go test -cover" runs), the go command will invoke cmd/cover
on the package passing in an option in the config file indicating that
it should emit a coverage meta-data file directly for the package (if
the package has no functions, an empty file is emitted). Note that
this CL doesn't actually wire up this functionality in the Go command,
that will come in a later patch.
Updates #27261.
Updates #58770
Updates #24570.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Change-Id: I01e8a3edb62441698c7246596e4bacbd966591c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/495446
Reviewed-by: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This patch changes the inliner to use callsite scores when deciding to
inline as opposed to looking only at callee cost/hairyness.
For this to work, we have to relax the inline budget cutoff as part of
CanInline to allow for the possibility that a given function might
start off with a cost of N where N > 80, but then be called from a
callsites whose score is less than 80. Once a given function F in
package P has been approved by CanInline (based on the relaxed budget)
it will then be emitted as part of the export data, meaning that other
packages importing P will need to also need to compute callsite scores
appropriately.
For a function F that calls function G, if G is marked as potentially
inlinable then the hairyness computation for F will use G's cost for
the call to G as opposed to the default call cost; for this to work
with the new scheme (given relaxed cost change described above) we
use G's cost only if it falls below inlineExtraCallCost, otherwise
just use inlineExtraCallCost.
Included in this patch are a bunch of skips and workarounds to
selected 'errorcheck' tests in the <GOROOT>/test directory to deal
with the additional "can inline" messages emitted when the new inliner
is turned on.
Change-Id: I9be5f8cd0cd8676beb4296faf80d2f6be7246335
Reviewed-on: https://go-review.googlesource.com/c/go/+/519197
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
