[pull] master from golang:master#139
Merged
Merged
Conversation
…onstant
For unsigned 32-bit division by a constant d on 64-bit targets (amd64,
arm64, riscv64, ...), when the magic multiplier M = 2^32 + m has m odd
(i.e. M is truly 33-bit and cannot be halved to fit in 32 bits), use a
pre-shifted constant C = M << (32 - s) so that a single Hmul64u gives
the quotient directly:
x / d = Hmul64u(ZeroExt32to64(x), C)
This replaces the avg-based sequence for odd divisors (Case 3) and the
SHR+IMULQ+SHR sequence for even divisors whose underlying magic is
33-bit (e.g. d=14=2×7). Divisors where m is even (Case 6) keep their
existing 32-bit constant path to avoid loading a large 64-bit constant
on arm64/riscv64.
Benchmark on Intel Xeon w9-3495X (3 divisions per iteration, go1.26.3):
BenchmarkOdd (d=7,19,107): 3.07 ns/op → 1.92 ns/op (~38% faster)
BenchmarkEven (d=14,38,214): 2.04 ns/op → 1.92 ns/op (~6% faster)
Ref: https://arxiv.org/abs/2604.07902
llvm/llvm-project#181288
Fixes #79780
Change-Id: I33f551f4f6715ddbcc39f9f56c1331f31f0eca33
Reviewed-on: https://go-review.googlesource.com/c/go/+/785960
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Added a newline after each section header and its following paragraph, so the sections would render properly. Ran gofmt, which indented the code blocks with tab characters and replaced * bullets with - ones. Note: this documentation is intentionally NOT general package documentation, but is now formatted consistently with other doc comments. For #80397 Change-Id: Ib651e204fc9813122934357a67f3c75bd453483c Reviewed-on: https://go-review.googlesource.com/c/go/+/801900 Reviewed-by: Michael Pratt <mpratt@google.com> Auto-Submit: Mark Freeman <markfreeman@google.com> Reviewed-by: Mark Freeman <markfreeman@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
t.Parallel and the operations that forbid it (t.Setenv, t.Chdir, and cryptotest.SetGlobalRandom) shared a single panic message that listed all three operations, so the panic never named the one that actually caused the conflict. A test that only calls t.Setenv could panic with a message mentioning cryptotest.SetGlobalRandom, which is confusing. Record the specific operation that denies parallelism and report it in both directions: when t.Parallel is called after one of those operations, and when one of them is called on a test that is already parallel. Fixes #80267 Change-Id: I749e22f3e6df3552795c512636a5d2466d95af4f GitHub-Last-Rev: 68ecf1b GitHub-Pull-Request: #80313 Reviewed-on: https://go-review.googlesource.com/c/go/+/798641 Reviewed-by: Sean Liao <sean@liao.dev> Auto-Submit: Sean Liao <sean@liao.dev> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Alan Donovan <adonovan@google.com> Auto-Submit: Alan Donovan <adonovan@google.com>
Fixes #77320 Change-Id: I1ca7480dceb0a95d223ae1618c0e9dd23abe5d49 Reviewed-on: https://go-review.googlesource.com/c/go/+/787940 Auto-Submit: Damien Neil <dneil@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
We don't support binary-only packages, and haven't for a while. We would only check for binary only packages when actually executing the action graph. But it seems more natural to report the error when loading packages. The only difference is the reporting of staleness but it doesn't really make sense to report staleness if we don't even support building those packages. While we're here remove the unused needStale need bit. This also slightly simplifies the logic in checkCacheForBuild. For #28152 Change-Id: I2bad74152d2c4323026c7513537265a36a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/799002 Auto-Submit: Michael Matloob <matloob@golang.org> TryBot-Bypass: Michael Matloob <matloob@golang.org> Reviewed-by: Michael Matloob <matloob@google.com> Reviewed-by: Hongxiang Jiang <hxjiang@golang.org>
This CL addresses https://go-review.googlesource.com/c/go/+/799984/comments/03458ed5_ce76e7f6 Fixes #80278 Change-Id: Id32c6ef68aad91dcbccf2e6e5e9822656a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/801620 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Jorropo <jorropo.pgm@gmail.com> Reviewed-by: Michael Pratt <mpratt@google.com> Auto-Submit: Michael Matloob <matloob@golang.org> Reviewed-by: Michael Matloob <matloob@google.com>
I filed #49331 about five years ago, suggesting that the compiler should re-associate some computations to support ILP. There was general consensus that it was a decent idea, and I believe that Ryan Berger may have attempted it, but so far, nothing has landed. For md5 in particular, which was the motivating example, we can get the desired parallelism by adjusting the source code. So do that. We can always revert if/when the compiler pass lands. Each MD5 step is of the form arg0 = arg1 + RotateLeft32(F(arg1,arg2,arg3) + arg0 + x + k, s) where arg1 is the output of the previous step. The generated code has the form a+(b+(c+d)) rather than (a+b)+(c+d), which has a long serial dependency chain. This is a significant source of the performance difference between the generic Go code and the handwritten assembly. Adjust the generator to impose the association we desire. Group the arg1-independent terms as F + (arg0+x+k). This lets the compiler schedule the inner sum in parallel with F, trimming the chain to a single add after F is calculated. Add two further expression tweaks. In round 2, use the direct selection form (x&z)|(y&^z) instead of the XOR-trick form ((x^y)&z)^y. The direct form puts arg1 on a 2-op path to F instead of 3, which reduces serialization on the critical path and shortens variable lifetimes. On arm64, both forms are 3 logical ops. On default amd64, this adds an instruction, but it's off the critical path. And BMI1 is available at GOAMD64 >= v3. In round 3, associate arg1^arg2^arg3 as arg1^(arg2^arg3), again for ILP. Before this commit, asm was about ~30% faster than purego on my arm64 machine, and ~37% on the amd64 machine I have access to (no GOAMD64). This commit narrows the gap to ~13% and ~20%, respectively. I have follow-up work planned that shrinks the gap further and should enable deletion of the md5 assembly. Updates #49248 Updates #49331 Change-Id: Ia317e20cd73c88c4fb9303b31f5b6b441bfa6b63 Reviewed-on: https://go-review.googlesource.com/c/go/+/801240 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Russ Cox <rsc@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
This CL should have been part of CL 796480, but was mistakenly omitted. Updates #77485. Change-Id: Ib18dbbcd01ad2080d14c64494e2c71421a1bd2f5 Reviewed-on: https://go-review.googlesource.com/c/go/+/801960 Reviewed-by: Richard Miller <millerresearch@gmail.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: David Chase <drchase@google.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
7 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )