Adds crypto/dsa, crypto/rand, x509 files and changes for the new
wasip1 port.
For #58141
Co-authored-by: Richard Musiol <neelance@gmail.com>
Co-authored-by: Achille Roussel <achille.roussel@gmail.com>
Co-authored-by: Julien Fabre <ju.pryz@gmail.com>
Co-authored-by: Evan Phoenix <evan@phx.io>
Change-Id: I9609e3d021cd7e06b813eedf5912febc52cc0f2c
Reviewed-on: https://go-review.googlesource.com/c/go/+/479624
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Auto-Submit: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
CL 404058 modified the generated file p256.go without modifying
the generator program. This CL updates the generator program so
that it generates the p256.go file currently in the tree.
For #52709
Change-Id: I86927a8bb84b2e17426b7ba74a86f1aba781628e
Reviewed-on: https://go-review.googlesource.com/c/go/+/483715
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
While running "go generate" I noticed that there has been a change.
For #58113
Change-Id: Icca349d0a100dd4b11d34e4bbcfd1aef57346db7
Reviewed-on: https://go-review.googlesource.com/c/go/+/483716
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Quim Muntal <quimmuntal@gmail.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: Bryan Mills <bcmills@google.com>
Re-run all go:generate stringer commands. This mostly adds checks
that the constant values did not change, but does add new strings
for the debug/dwarf and internal/pkgbits packages.
Change-Id: I5fc41f20da47338152c183d45d5ae65074e2fccf
Reviewed-on: https://go-review.googlesource.com/c/go/+/483717
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
For #57001, compilers and others tools will need to understand that
a different Go version can be used in different files in a program,
according to the //go:build lines in those files.
This CL adds a GoVersion string field to ast.File, to allow exposing this
per-file Go version information.
For #59033.
Change-Id: I3931ea86c237983d152964f48dce498bcb1f06aa
Reviewed-on: https://go-review.googlesource.com/c/go/+/476276
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
For #57001, programs need to be able to deduce the Go version
implied by a given build constraint. GoVersion determines that,
by discarding all build tags other than Go versions and computing
the minimum Go version implied by the resulting expression.
For #59033.
Change-Id: Ifb1e7af2bdbdf172f82aa490c826c9b6ca5e824b
Reviewed-on: https://go-review.googlesource.com/c/go/+/476275
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
In the case where a user program requests overlapped I/O directly on a
handlethat is managed by the runtime, it is possible that
runtime.netpoll will attempt to dereference a pointer with an invalid
value. This CL prevents the runtime from accessing the invalid pointer
value by adding a special key to each overlapped I/O operation that it
creates.
Fixes#58870
Co-authored-by: quimmuntal@gmail.com
Change-Id: Ib58ee757bb5555efba24c29101fc6d1a0dedd61a
Reviewed-on: https://go-review.googlesource.com/c/go/+/482495
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Add support for the Read Processor ID (RDPID) instruction to the x86
assembler. This returns the current logical processor's ID in the
specified register, as a faster alternative to RDTSCP.
Fixes#56525
Change-Id: I43482e42431dfc385ce2e7f6d44b9746b0cc4548
Reviewed-on: https://go-review.googlesource.com/c/go/+/482955
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
As of CL 482163, this test now works when only a loopback network is
available.
Updates #59497.
Change-Id: I32be4b74bbc663eb109763ea19d79f22c63f50ae
Reviewed-on: https://go-review.googlesource.com/c/go/+/483696
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Bypass: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
In the language specification under "Constants" the lists matching default
types to untyped contstant types is missing an Oxford comma in the first
list. I found a number of other places in the spec and #23442 that use the
Oxford comma to support its use.
Add missing Oxford comma in Constants default type list.
Change-Id: I4562d692610334bc82452db076145d2414617a04
GitHub-Last-Rev: 8acdb60d6e
GitHub-Pull-Request: golang/go#59528
Reviewed-on: https://go-review.googlesource.com/c/go/+/483555
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@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>
It's fine to ignore errors when reading trim.txt, since it might not
exist or might be corrupted. However, if we encounter an error in
writing the file, we will end up trimming again at every cmd/go
invocation, which will cause invocations to become progressively
slower (because each command will check more and more cache files for
trimming).
Although that situation would not cause the output of any 'go' command
to be invalid, it still seems better to escalate the problem to the
user to be fixed instead of proceeding in a degraded state.
Returning an explicit error also allows TestCacheTrim to skip if the
Trim error indicates that a required operation (in this case, file
locking) is not supported by the platform or filesystem.
For #58141.
Updates #35220.
Updates #26794.
Change-Id: Iedb94bff4544fd9914f5ac779a783a116372c80f
Reviewed-on: https://go-review.googlesource.com/c/go/+/482795
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Update to use the common macros to ensure all ELFv2 callee-save registers
are saved properly when transitioning from ELFv2 to Go calling/stack
conventions. Simplify the inlined Go function call, and remove the asm
hacks which inhibited implicit stack frame management.
Change-Id: Iee118a4069962a791436c6fe19370e1929404a8d
Reviewed-on: https://go-review.googlesource.com/c/go/+/479795
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In rare cases, elf will get a corrupted section starts with 0x1,
which happens to be COMPRESS_ZLIB that causing decompress twice.
This CL drops sectionData decompress data after open section.
Fixes#59208
Change-Id: I7999a55868b3b3481509e1ac35985f7580f0f688
Reviewed-on: https://go-review.googlesource.com/c/go/+/480895
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: M Zhuo <mzh@golangcn.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
setPos is called for most nodes, and in a number of cases,
the position is already the same.
PositionFor is a relatively expensive call,
as it needs to "unpack" a token.Pos into a token.Position.
If we can tell that the position is the same in a cheap way,
we can then avoid calling setPos and PositionFor.
Luckily, we can get the position's offset within the file,
and it doesn't involve the relatively expensive unpacking.
name old time/op new time/op delta
PrintFile-16 4.79ms ± 1% 4.36ms ± 1% -8.88% (p=0.008 n=5+5)
name old speed new speed delta
PrintFile-16 10.8MB/s ± 1% 11.9MB/s ± 1% +9.73% (p=0.008 n=5+5)
name old alloc/op new alloc/op delta
PrintFile-16 106kB ± 1% 106kB ± 1% ~ (p=0.167 n=5+5)
name old allocs/op new allocs/op delta
PrintFile-16 2.42k ± 0% 2.42k ± 0% ~ (all equal)
This does assume that the positions of a node being printed are all
within a file, as go/token.Position.Offset is relative to each file.
This seems like a perfectly fine assumption to make right now,
as the largest node which can be printed is an *ast.File.
Change-Id: I2ae55f507ba8ba9f280898c9c8e01c994d9b2a26
Reviewed-on: https://go-review.googlesource.com/c/go/+/461739
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Previously, we need calculate both quotient and remainder together.
However, in most cases, only one result is needed. By separating these
instructions, we can save one instruction in most cases.
Change-Id: I0a2d4167cda68ab606783ba1aa2720ede19d6b53
Reviewed-on: https://go-review.googlesource.com/c/go/+/475315
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org>
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Fixes#59506
Change-Id: I2f8b92e93b706b061ca0eb0bd52e5cf798ce9ede
Reviewed-on: https://go-review.googlesource.com/c/go/+/483358
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
The function just calculates the number of needed padding bytes,
instead of actually carrying out the alignment operation. And it has
the context argument at the end of the argument list, while contexts
idiomatically come first. Indeed, this is the only case in
cmd/internal/obj where ctxt is not the only argument and does not come
first.
Fix those two nits; no functional change intended.
Suggested by Ian during review of CL 479815 (that introduces a copy of
this helper into the loong64 port).
Change-Id: Ieb221ead23282abe6e04804d537e1234c7ab21d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/483155
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
The behavior in #18806 can be tested with a localhost-only port,
provided that we're willing to assume what format the listener would
report for an external dual-stack port.
Fixes#59497.
Change-Id: I171fb03eb46aee8e85480e04626a23f4f3b923e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/482163
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
cmd/doc passes structs to go/format, but that means that comments
on fields within those structs don't look like what cmd/doc prints
when asked for a struct field directly. Tweak the field comments
so that they look the same either way.
Fixes#56592
Change-Id: I198cb7a58e3d8558406c386072c630332f91c6b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/483055
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Stop depending on DepsErrors to report errors to the user and instead
only use it and compute it in list. Instead, use Incomplete to figure
out when a package or its depencies have an error, and only if they
do, do the work of finding all those errors.
For #59157
Change-Id: Ied927f53e7b1f66fad9248b40dd11ed960b3ef91
Reviewed-on: https://go-review.googlesource.com/c/go/+/483495
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Change-Id: Iae6ac32db5c2aacb323793a7e0dc34e09648d035
Reviewed-on: https://go-review.googlesource.com/c/go/+/482295
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Change-Id: I5d02279d0593a8368b2f249a6b53650b89aed7b7
Reviewed-on: https://go-review.googlesource.com/c/go/+/482275
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Standard inlining has a reduced maximum cost of callees (20 instead of
80) when inlining into a "big" function, to limit how much bigger we
will make an already big function.
When adding PGO hot call budget increases, we inadvertently bypassed
this "big" function restriction, allowing hot calls of up to
inlineHotMaxBudget, even into big functions.
Add the restriction back, even for hot calls. If a function is already
very large, we probably shouldn't inline even more.
A very important note here is that function "big"-ness is computed prior
to any inlining. One potential problem with PGO is that many hot calls
inline into an initially-small function and ultimately make it very
large. This CL does nothing to address that case, which would require
recomputing size after inlining.
This CL has no impact on sweet PGO benchmarks. I specifically dug into
tile38, which contained 0 hot big functions. Other benchmarks are
probably similar.
Change-Id: I3b6304eaf7738a219359d4b8bb121d68babfea8b
Reviewed-on: https://go-review.googlesource.com/c/go/+/482157
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
And assign the error to the importing package. Before this change, for
some errors for bad imports, such as importing a vendored package with
the wrong path, we would make a dummy package for the imported package
with the error on it. Instead report the error on the importing
package where it belongs. Do so by returning an error from loadImport
and handling it on the importing package.
For #59157
Change-Id: I952e1a82af3857efc5da4fd3f8bc6be473a60cf5
Reviewed-on: https://go-review.googlesource.com/c/go/+/482877
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
It appears to have been unused since https://go.dev/cl/298670
in April 2021, as that change removed its only use.
It is always in the git history if it is needed again.
Change-Id: Ie55d059c102dfaa75bd253e09d48a4b30f45e941
Reviewed-on: https://go-review.googlesource.com/c/go/+/483136
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
GOTRACEBACK=wer is a new traceback level that acts as "crash" and
also enables WER. The same effect can be achieved using
debug.SetTraceback("wer").
The Go runtime currently crashes using exit(2), which bypasses WER
even if it is enabled. To best way to trigger WER is calling
RaiseFailFastException [1] instead, which internally launches the
WER machinery.
This CL also changes how GOTRACEBACK=crash crashes, so both "wer" and
"crash" crash using RaiseFailFastException, which simplifies the
implementation and resolves a longstanding TODO.
Fixes#57441Fixes#20498
[1] https://learn.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-raisefailfastexception
Change-Id: I45669d619fbbd2f6413ce5e5f08425ed1d9aeb64
Reviewed-on: https://go-review.googlesource.com/c/go/+/474915
Reviewed-by: Davis Goodin <dagood@microsoft.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
For now, only apply the rule if either of arguments are constants. That
would catch a lot of real user code, without slowing down the compiler
with code generated for string comparison (experience in CL 410336).
Updates #57959Fixes#45928
Change-Id: Ie2e830d6d0d71cda3947818b22c2775bd94f7971
Reviewed-on: https://go-review.googlesource.com/c/go/+/483359
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
No change in semantics, just removing an unneeded helper.
Also align rules a bit.
Change-Id: Ie4dabb99392315a7700c645b3d0931eb8766a5fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/483439
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Argument type is dangerous because it may be thinner than the actual
store being issued.
Change-Id: Id19fbd8e6c41390a453994f897dd5048473136aa
Reviewed-on: https://go-review.googlesource.com/c/go/+/483438
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: David Chase <drchase@google.com>
These c-shared related CLs are follow up of CLs 455016, 455017, 455018. Here we
follow the LoongArch ELF psABI v2 standard, which requires the support of the
PCALAU12I instruction.
Updates #53301
Updates #58784
Change-Id: I7f1ddbf3b2470d610f12069d147aa9b3a6a96f32
Reviewed-on: https://go-review.googlesource.com/c/go/+/425474
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
Reviewed-by: WANG Xuerui <git@xen0n.name>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Knyszek <mknyszek@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 LoongArch ELF psABI v2 [1] relocs are vastly simplified from the v1
which involved a stack machine for computing the reloc values, but the
details of PC-relative addressing are changed as well. Specifically, the
`pcaddu12i` instruction is substituted with the `pcalau12i`, which is
like arm64's `adrp` -- meaning the lower bits of a symbol's address now
have to be absolute and not PC-relative.
However, apart from the little bit of added complexity, the obvious
advantage is that only 1 reloc needs to be emitted for every kind of
external reloc we care about. This can mean substantial space savings
(each RELA reloc occupies 24 bytes), and no open-coded stack ops has to
remain any more.
While at it, update the preset value for the output ELF's flags to
indicate the psABI update.
Fixes#58784
[1]: https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html
Change-Id: I5c13bc710eaf58293a32e930dd33feff2ef14c28
Reviewed-on: https://go-review.googlesource.com/c/go/+/455017
Run-TryBot: Ben Shi <powerman1st@163.com>
Reviewed-by: xiaodong liu <teaofmoli@gmail.com>
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Meidan Li <limeidan@loongson.cn>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This is actually not tied to the ELF psABI v2 upgrade, and can be
enabled "for free".
Change-Id: I6906d9eb4bd8655c685b059283e200cb7e210369
Reviewed-on: https://go-review.googlesource.com/c/go/+/455075
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
Run-TryBot: Ben Shi <powerman1st@163.com>
Reviewed-by: Meidan Li <limeidan@loongson.cn>
Run-TryBot: WANG Xuerui <git@xen0n.name>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: David Chase <drchase@google.com>
In order to avoid a CPU exception resulting from signed overflow, the signed
division code tests if the divisor is -1 and if it is, runs fix up code to
manually compute the quotient and remainder (thus avoiding IDIV and potential
signed overflow).
However, the way that this is currently structured means that the normal code
path for the case where the divisor is not -1 results in five instructions
and two branches (CMP, JEQ, followed by sign extension, IDIV and another JMP
to skip over the fix up code).
Rework the fix up code such that the final JMP is incurred by the less likely
divisor is -1 code path, rather than more likely code path (which is already
more expensive due to IDIV). This result in a four instruction sequence
(CMP, JNE, sign extension, IDIV), with only a single branch.
Updates #59089
Change-Id: Ie8d065750a178518d7397e194920b201afeb0530
Reviewed-on: https://go-review.googlesource.com/c/go/+/482658
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
The same switch statement handles code generation for signed division of
words, double words and quad words. Rather than using multiple switch
statements to select the appropriate instructions, determine all of the
correctly sized operands up front, then use them as needed.
Updates #59089
Change-Id: I2b7567c8e0ecb9904c37607332538c95b0521dca
Reviewed-on: https://go-review.googlesource.com/c/go/+/482657
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
So iterators that are in progress can know entries have been deleted and
terminate the iterator properly.
Update #55002
Update #56351Fixes#59411
Change-Id: I924f16a00fe4ed6564f730a677348a6011d3fb67
Reviewed-on: https://go-review.googlesource.com/c/go/+/481935
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
For #58141
Co-authored-by: Richard Musiol <neelance@gmail.com>
Co-authored-by: Achille Roussel <achille.roussel@gmail.com>
Co-authored-by: Julien Fabre <ju.pryz@gmail.com>
Co-authored-by: Evan Phoenix <evan@phx.io>
Change-Id: I52e3e161f81dcbe8605570e47d732992979c4d34
Reviewed-on: https://go-review.googlesource.com/c/go/+/479623
Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
For #58141
Co-authored-by: Richard Musiol <neelance@gmail.com>
Co-authored-by: Achille Roussel <achille.roussel@gmail.com>
Co-authored-by: Julien Fabre <ju.pryz@gmail.com>
Co-authored-by: Evan Phoenix <evan@phx.io>
Change-Id: I1488726e5b43cd21c5f83900476afd2fb63d70c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/479622
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Fixes#54768
Change-Id: I588ae33c13e0bbd9d324c11771667b22a864047d
Reviewed-on: https://go-review.googlesource.com/c/go/+/483175
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Eli Bendersky <eliben@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Use the type of the store for the byteswap, not the type of the
store's value argument.
Normally when we're storing a 16-bit value, the value being stored is
also typed as 16 bits. But sometimes it is typed as something smaller,
usually because it is the result of an upcast from a smaller value,
and that upcast needs no instructions.
If the type of the store's arg is thinner than the type being stored,
and the byteswap'd value uses that thinner type, and the byteswap'd
value needs to be spilled & restored, that spill/restore happens using
the thinner type, which causes us to lose some of the top bits of the
value.
Fixes#59367
Change-Id: If6ce1e8a76f18bf8e9d79871b6caa438bc3cce4d
Reviewed-on: https://go-review.googlesource.com/c/go/+/481395
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
HashDebugPos function/method included a parameter that was always
the same, and a variable in the same package as the hashdebug code.
So remove it.
(I wrote that code, there was no reason for it to be that way).
Also corrects a stale comment in the loopvar code.
Change-Id: Id3da69cfe6dadeb31d5de62fb76d15103a5d6152
Reviewed-on: https://go-review.googlesource.com/c/go/+/482816
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
The ELF ABI just requires that the address and the offset of a
segment are congruent modulo the alignment, but does not require
the start address to be aligned. While usually the segment's
start address is aligned, apparently the zig linker generates
binary with unaligned address.
At the run time, the memory mapping that contains the segment
starts at an aligned address (rounding down). Use the aligned
address for the load address, which matches the mapping.
Apparently this is what the pprof library expects.
Fixes#59466.
Change-Id: Ife78909b20b7bc975ac4c76f2c5f5db325ddec9b
Reviewed-on: https://go-review.googlesource.com/c/go/+/483035
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
The loong64 PCALIGN directive works with PCs relative to beginning of
functions. So if the function alignment is less than that requested by
PCALIGN, the following code may in fact not be aligned as such, leading
to unexpected performance.
The current function alignment on loong64 is 8 bytes, which seems to
stem from mips64 or riscv64. In order to make performance more
predictable on loong64, it is raised to 16 bytes to ensure that at
least `PCALIGN $16` works.
As alignment of loops written in Go is yet to be tackled, and the
codegen is not otherwise touched, benchmark numbers for this change are
not going to be meaningful, and not included.
Change-Id: I2120ef3746ce067e274920c82091810073bfa3be
Reviewed-on: https://go-review.googlesource.com/c/go/+/481936
Auto-Submit: 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@google.com>
Run-TryBot: WANG Xuerui <git@xen0n.name>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
