| Age | Commit message (Collapse) | Author |
|
|
|
When unifying an interface against a concrete type, interface inference
looks up each interface method on the concrete type and unifies the
signatures. If the concrete method is generic, the *Signature unify
case (which ignores type parameter lists) would unify the method's own
type parameter into the inference variable, leading to errors mentioning
a leaked P and recording the wrong type in Info.
A generic method never satisfies an interface method, so fail the
unification at the lookup site instead.
Change-Id: Id01eefcde492399cb94f4452f5627c4edbd22a1c
Reviewed-on: https://go-review.googlesource.com/c/go/+/766160
Reviewed-by: Robert Griesemer <gri@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>
|
|
Since negating min int will overflows back to itself, causing a panic
inside subWillUnderflow check.
Fixes #78641
Change-Id: Ibbf2fa3228b9890a1a76ac6f4ff504b7e125b29f
Reviewed-on: https://go-review.googlesource.com/c/go/+/766260
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Jorropo <jorropo.pgm@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
|
|
Change-Id: If524465cc898a36a31f9034d5b2f13e8842357a9
GitHub-Last-Rev: bdf52219d7d38b94213529f3d399acca69fa5bae
GitHub-Pull-Request: golang/go#78604
Reviewed-on: https://go-review.googlesource.com/c/go/+/764361
Reviewed-by: Mark Freeman <markfreeman@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Sean Liao <sean@liao.dev>
Reviewed-by: Keith Randall <khr@google.com>
|
|
The SSA generic rewrite rules implement DeMorgan's laws but are
missing the closely related boolean absorption laws:
x & (x | y) == x
x | (x & y) == x
These are fundamental boolean algebra identities (see
https://en.wikipedia.org/wiki/Absorption_law) that hold for all
bit patterns, all widths, signed and unsigned. Both GCC and LLVM
recognize and optimize these patterns at -O2.
Add two generic rules covering all four widths (8, 16, 32, 64).
Commutativity of AND/OR is handled automatically by the rule
engine, so all argument orderings are matched.
The rules eliminate two redundant ALU instructions per occurrence
and fire on real code (defer bit-manipulation patterns in runtime,
testing, go/parser, and third-party packages).
Fixes #78632
Change-Id: Ib59e839081302ad1635e823309d8aec768c25dcf
GitHub-Last-Rev: 23f8296ece08c77fcaeeaf59c2c2d8ce23d1202c
GitHub-Pull-Request: golang/go#78634
Reviewed-on: https://go-review.googlesource.com/c/go/+/765580
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Jorropo <jorropo.pgm@gmail.com>
|
|
Upgrading to V4 early doesn't seem to make much sense while we refine
things. Any change to encoding would require another version gate and
propagation; this gets tedious fast.
Instead, let's keep on V3 and test locally with V4. We can commit
skipped tests as we refine and then turn them all on *with* the bump
up to V4.
Change-Id: I571715e5da75095612f68b224c82e6d22ad3ab25
Reviewed-on: https://go-review.googlesource.com/c/go/+/765444
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Mark Freeman <markfreeman@google.com>
|
|
Change-Id: Ia9ee618aa68aad5bab73ee62eea176084ee162da
GitHub-Last-Rev: 4cc005d3cd1ae4e5eaa283b1799c7be26b2279f5
GitHub-Pull-Request: golang/go#78625
Reviewed-on: https://go-review.googlesource.com/c/go/+/765280
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
|
|
All literals are initialized in init function context, thus it's safe to
remove the type and simplify all its usage.
Change-Id: If128e915cf63199ab0b23b240e0f31508be8f377
Reviewed-on: https://go-review.googlesource.com/c/go/+/764021
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
|
|
Fixes #78558
I've also added tests to make sure PPC still generate ISEL when
the constant isn't 1.
This is to make sure we aren't generating a sequence that wouldn't
work right now.
But it does not mean we couldn't try to optimize other constants
on PPC64 if a fast sequence exists; for example like arm64's
inline register shifts.
Change-Id: Ic241d593149b7a11533948f5d4c52db357cc134f
Reviewed-on: https://go-review.googlesource.com/c/go/+/763340
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Jorropo <jorropo.pgm@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Jayanth Krishnamurthy <jayanth.krishnamurthy@ibm.com>
Reviewed-by: Paul Murphy <paumurph@redhat.com>
|
|
Original algorithm merges stores with the first
mergeable store in the chain, but it misses some
cases. Additionally, creating list of STs, which
store data to adjacent memory cells allows merging them
according to the direction of increase of their addresses.
I have already tried another algorithm in CL 698097,
but it was reverted. This algorithm works differently
and fixes bug, generated by variant from another CL.
Fixes #71987, #75365
There are the results of sweet benchmarks
│ base.stat │ opt.stat │
│ sec/op │ sec/op vs base │
ESBuildThreeJS-4 1.088 ± 2% 1.086 ± 1% ~ (p=1.000 n=10)
ESBuildRomeTS-4 263.0m ± 2% 260.8m ± 1% ~ (p=0.105 n=10)
EtcdPut-4 73.08m ± 1% 73.16m ± 1% ~ (p=0.971 n=10)
EtcdSTM-4 414.9m ± 1% 415.4m ± 1% ~ (p=0.393 n=10)
GoBuildKubelet-4 203.3 ± 0% 203.5 ± 0% ~ (p=0.393 n=10)
GoBuildKubeletLink-4 19.06 ± 1% 19.05 ± 0% ~ (p=0.280 n=10)
GoBuildIstioctl-4 156.6 ± 0% 156.6 ± 0% ~ (p=0.796 n=10)
GoBuildIstioctlLink-4 14.16 ± 1% 14.18 ± 1% ~ (p=0.853 n=10)
GoBuildFrontend-4 56.45 ± 1% 56.57 ± 0% ~ (p=0.579 n=10)
GoBuildFrontendLink-4 3.635 ± 1% 3.646 ± 0% ~ (p=0.436 n=10)
GoBuildTsgo-4 103.0 ± 1% 103.4 ± 1% ~ (p=0.529 n=10)
GoBuildTsgoLink-4 1.865 ± 1% 1.860 ± 1% ~ (p=0.684 n=10)
GopherLuaKNucleotide-4 33.55 ± 0% 33.58 ± 0% ~ (p=0.075 n=10)
MarkdownRenderXHTML-4 281.0m ± 0% 280.3m ± 0% -0.23% (p=0.019 n=10)
Tile38QueryLoad-4 970.0µ ± 1% 969.3µ ± 0% ~ (p=0.436 n=10)
geomean 3.128 3.128 -0.01%
Change-Id: Ia548b43601b1bdb1c1723d300a4b8b907ab0c040
Reviewed-on: https://go-review.googlesource.com/c/go/+/760100
Reviewed-by: Mark Freeman <markfreeman@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Keith Randall <khr@golang.org>
|
|
CL 737821 removed the last functional use of inNonInitFunction.
This field and its associated logic are now dead code and can
be safely deleted.
Change-Id: I4023ec7ef5d10c94ef54b9726f18cda863ee2ff4
Reviewed-on: https://go-review.googlesource.com/c/go/+/764020
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
|
|
addWillOverflow and subWillOverflow has an implicit assumption that y is
positive, using it outside of addU and subU is really incorrect. This CL
fixes those incorrect usage to use the correct logic in place.
Thanks to Jakub Ciolek for reporting this issue.
Fixes #78333
Fixes CVE-2026-27143
Change-Id: I263e8e7ac227e2a68109eb7bbd45f66569ed22ec
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/3700
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Neal Patel <nealpatel@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/763765
Reviewed-by: Jakub Ciolek <jakub@ciolek.dev>
Reviewed-by: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: David Chase <drchase@google.com>
|
|
When a no-op interface conversion is wrapped around the rhs of an
assignment, the memory overlap detection logic in the compiler failed to
peel down conversion to see the actual pointer, causing an incorrect
no-overlapping determination.
Thanks to Jakub Ciolek for reporting this issue.
Fixes #78371
Fixes CVE-2026-27144
Change-Id: I55ff0806b099e1447bdbfba7fde6c6597db5d65c
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/3780
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Neal Patel <nealpatel@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/763764
Auto-Submit: David Chase <drchase@google.com>
TryBot-Bypass: David Chase <drchase@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Jakub Ciolek <jakub@ciolek.dev>
|
|
This patch fixes a bug introduced in the recent DWARF refactor / cleanup
where `shouldEmitDwarf` was unified and ended up pruning certain dot
prefixed vars that are necessary for debuggers.
Other dot prefixed vars are already pruned in earlier passes, those that
remain are intentional and should be preserved.
Change-Id: Ib0cee520e2b99770479889feb44f3981a518137b
Reviewed-on: https://go-review.googlesource.com/c/go/+/763557
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
|
|
Lookup tables for switch statements can be generalized to also support
bools, strings, floats, and complex numbers.
Change-Id: Ic3ece41fe2009050fbf08ba6f06ea8a567407974
Reviewed-on: https://go-review.googlesource.com/c/go/+/763320
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
|
|
Change-Id: If8acdbf0e48ed600c4ba3f762802879335df1465
Reviewed-on: https://go-review.googlesource.com/c/go/+/761980
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Without this CL, when compiling test/range4.go:func9, we get:
b1:
v1 = StaticLECall <runtime.deferrangefunc>
mem = SelectN [1] v1
Defer v1 -> b2 b3
b2:
v2 = SelectN [0] v1
That select in b2 should really live in b1. This doesn't cause a bug
as far as I can tell, but it makes a check fail when when checkEnabled
is set in the compiler.
Change-Id: I8fe928fa8c376b81131ec712fc69d5fd39a1d4bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/747740
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
|
|
When a map element or key type is 2GB or larger, the compiler crashed
with "internal compiler error: map elem too big" in reflectdata.ZeroAddr.
Add a size check in types.CalcSize for TMAP, similar to the existing
check for channel element types, so that oversized map elements are
reported as a normal error before reaching ZeroAddr.
Fixes #78355
Change-Id: I281a5f0ec7dda6dac084787859156d4409dc860c
Reviewed-on: https://go-review.googlesource.com/c/go/+/760600
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Change-Id: I27696b1a5fa0593d9f36743efa3559a36d23ec4b
Reviewed-on: https://go-review.googlesource.com/c/go/+/760844
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Jorropo <jorropo.pgm@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
|
|
- fix a bug where it wouldn't recognize 1<<63 as a power of two
- remove the IsSigned check; there is no such thing as a signed Mul
If the rule works for signed numbers it works for unsigned ones too.
Even if the intermediary steps makes no sense, it ends up wrapping
the right way around in the end.
Change-Id: I86182762aec5eff784e2d9bc49ee028825fb9ea0
Reviewed-on: https://go-review.googlesource.com/c/go/+/760843
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Jorropo <jorropo.pgm@gmail.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
|
|
(I copied Ilya Tocar's CL 27656 and heavily modified it.)
This adds an optimization that moves loop invariant computations
out of the loop. For example:
a:= ...
for ... {
b:= a + 15
// uses of b
}
Turns into
a:= ...
b:= a + 15
for ... {
// uses of b
}
Change-Id: I36c8c7e2b3bc1c5e6b4b293bed3a76dc20d6c825
Reviewed-on: https://go-review.googlesource.com/c/go/+/697235
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
|
|
Change-Id: Iac9428fe8d2fb3e6fde30940470bf5d3ac9751cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/763141
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Mark Freeman <markfreeman@google.com>
|
|
Change-Id: Ic97f661c68180ff7adb9976fcc61279e1e1f04a4
Reviewed-on: https://go-review.googlesource.com/c/go/+/760842
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Jorropo <jorropo.pgm@gmail.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
On amd64 along:
if b { x += 1 } => x += b
We can also implement constants 2 4 and 8:
if b { x += 2 } => x += b * 2
This compiles to a displacement LEA.
Change-Id: Ib00fcc5059acb0ebb346e056c4a656f164cc63df
Reviewed-on: https://go-review.googlesource.com/c/go/+/760841
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Jorropo <jorropo.pgm@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
|
|
Refactor the DWARF variable generation in the compiler:
1. Replace the intermediate []byte location list encoding with a
structured LocListEntry type. The old code packed SSA block/value
IDs into pointer-sized integers, wrote them alongside DWARF4-format
length-prefixed expressions, then re-read and decoded everything
during final encoding. The new approach stores entries as
{StartBlock, StartValue, EndBlock, EndValue, Expr} structs that
PutLocationListDwarf4/5 directly encode into the appropriate format.
This eliminates encodeValue, decodeValue, appendPtr, writePtr,
readPtr, and SetupLocList, and removes the DWARF4 re-encoding in
PutLocationListDwarf5.
2. Unify createDwarfVars into a single processing loop. The old code
had three mutually exclusive paths (createSimpleVars, createABIVars,
createComplexVars) selected by build mode, followed by a separate
conservative-var loop. The new code uses one loop that tries
createComplexVar first (when SSA debug info is available), then
falls back to createSimpleVar. This removes createSimpleVars,
createABIVars, and createComplexVars.
3. Extract createConservativeVar and shouldEmitDwarfVar as named
functions, consolidating inline code and scattered filtering logic.
4. Fix createHeapDerefLocationList to return []LocListEntry instead
of raw bytes, consistent with the new representation.
Change-Id: If6fb755c22e398d7615dccaf33b1367828e6c47e
Reviewed-on: https://go-review.googlesource.com/c/go/+/750920
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
|
|
Logical ops on uint8/uint16 (AND/OR/XOR) with constants sometimes
materialized the mask via MOVD (often as a negative immediate), even
when the value fit in the UI-immediate range. This prevented the backend
from selecting andi. / ori / xori forms.
This CL makes:
UI-immediate truncation is performed only at the use-site of
logical-immediate ops, and only when the constant does not fit in the
8- or 16-bit unsigned domain (m != uint8(m) / m != uint16(m)).
This avoids negative-mask materialization and enables correct emission of
UI-form logical instructions. Arithmetic SI-immediate instructions (addi, subfic, etc.) and other
use-patterns are unchanged.
Codegen tests are added to ensure the expected andi./ori/xori
patterns appear and that MOVD is not emitted for valid 8/16-bit masks.
Change-Id: I9fcdf4498c4e984c7587814fb9019a75865c4a0d
Cq-Include-Trybots: luci.golang.try:gotip-linux-ppc64_power10,gotip-linux-ppc64_power8,gotip-linux-ppc64le_power8,gotip-linux-ppc64le_power9,gotip-linux-ppc64le_power10
Reviewed-on: https://go-review.googlesource.com/c/go/+/704015
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Paul Murphy <paumurph@redhat.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Mark Freeman <markfreeman@google.com>
|
|
Switch statement containing integer constant cases and case bodies just
returning a constant should be optimizable to a simpler and faster table
lookup instead of a jump table.
That is, a switch like this:
switch x {
case 0: return 10
case 1: return 20
case 2: return 30
case 3: return 40
default: return -1
}
Could be optimized to this:
var table = [4]int{10, 20, 30, 40}
if uint(x) < 4 { return table[x] }
return -1
The resulting code is smaller and faster, especially on platforms where
jump tables are not supported.
goos: windows
goarch: arm64
pkg: cmd/compile/internal/test
│ .\old.txt │ .\new.txt │
│ sec/op │ sec/op vs base │
SwitchLookup8Predictable-12 2.708n ± 6% 2.249n ± 5% -16.97% (p=0.000 n=10)
SwitchLookup8Unpredictable-12 8.758n ± 7% 3.272n ± 4% -62.65% (p=0.000 n=10)
SwitchLookup32Predictable-12 2.672n ± 5% 2.373n ± 6% -11.21% (p=0.000 n=10)
SwitchLookup32Unpredictable-12 9.372n ± 7% 3.385n ± 6% -63.89% (p=0.000 n=10)
geomean 4.937n 2.772n -43.84%
Fixes #78203
Change-Id: I74fa3d77ef618412951b2e5c3cb6ebc760ce4ff1
Reviewed-on: https://go-review.googlesource.com/c/go/+/756340
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
This change slightly extends expression traversal to recognize
explicit instantiation of generic methods. The relevant MethodVal
and MethodExpr snippets are extracted into helper functions, since
they are needed in two places.
Change-Id: I85d49d89f2422fa4c2d09de28fb6552f171a2a1f
Reviewed-on: https://go-review.googlesource.com/c/go/+/762560
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Griesemer <gri@google.com>
|
|
If the bool comes from a local operation this is foldable into the comparison.
if a == b {
} else {
x++
}
becomes:
x += !(a == b)
becomes:
x += a != b
If the bool is passed in or loaded rather than being locally computed
this adds an extra XOR ^1 to invert it.
But at worst it should make the math equal to the compute + CMP + CMOV
which is a tie on modern CPUs which can execute CMOV on all int ALUs
and a win on the cheaper or older ones which can't.
Change-Id: Idd2566c7a3826ec432ebfbba7b3898aa0db4b812
Reviewed-on: https://go-review.googlesource.com/c/go/+/760922
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Jorropo <jorropo.pgm@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
|
|
Emitting wrapper functions for generic methods is tricky for 2 reasons:
1. Existing downstream machinery expects that it can make certain
assumptions about a method if it sees a wrapper function. We
may violate those assumptions with generic method wrappers.
2. Signatures for generic methods are generic and hence cannot be
encoded using w.typ.
This has the slight downside of not using a statically computed
wrapper for generic methods and instead dynamically computing the
dictionary pointer. Thus, we miss out on a performance optimization
for generic methods for now. Code that does not use generic methods
is unaffected.
Change-Id: I72c626ef0f807c0cb54d8cf040250de8177303cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/762382
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Mark Freeman <markfreeman@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
|
|
Change-Id: I9846b8086bacbc69e438a8e39e3e26c46316fb08
Reviewed-on: https://go-review.googlesource.com/c/go/+/762022
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Mark Freeman <markfreeman@google.com>
|
|
When a writer goes to encode use of a type parameter, it only records
an index because the writer knows all of the type parameters in scope
for that object.
The writer orders the type parameteres as implicits first, then
receivers, then explicits actually on the object. Note that receivers
*are* explicit type arguments, they're just inherited from the type.
For instance, given:
func (T[P]) m[Q, R any]()
This has:
- 0 implicits
- 1 receiver
- 2 explicits
With this ordering, P is at 0, Q is at 1, and R is at 2. In contrast,
inspecting TypeParam.index for Q yields 0, and for R yields 1; hence
the offset is needed.
Change-Id: If12f342e109fbc5935ba278f574ac2809c889335
Reviewed-on: https://go-review.googlesource.com/c/go/+/762021
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Mark Freeman <markfreeman@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Change-Id: I7a66fba400a743f4ef2fb989cd8e74e955e22b0f
Reviewed-on: https://go-review.googlesource.com/c/go/+/762020
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Mark Freeman <markfreeman@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
|
|
We have not yet added the decoding on the reader side.
Change-Id: Ic7f8dc51b6b9a2c214b402b1314ee84c0085c16a
Reviewed-on: https://go-review.googlesource.com/c/go/+/761983
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Mark Freeman <markfreeman@google.com>
|
|
This splits objTypeParams into objTypeParams and objRecvTypeParams. The
type parameters on a generic method and its receiver need to be reported
separately to the reader.
Change-Id: If9eb93ca66a5a5e4bdce71364627ff4bee110311
Reviewed-on: https://go-review.googlesource.com/c/go/+/761981
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Mark Freeman <markfreeman@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
|
|
Fixes #78483.
For #78314.
Change-Id: If83983c0bf79840aa02dc0d2fa8945f5e8b4e969
Reviewed-on: https://go-review.googlesource.com/c/go/+/761682
Auto-Submit: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Jakub Ciolek <jakub@ciolek.dev>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Mark Freeman <markfreeman@google.com>
|
|
Change-Id: I1f2fc247cdf979a40cbd48b4feab449c0ff6182e
Reviewed-on: https://go-review.googlesource.com/c/go/+/761860
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Mark Freeman <markfreeman@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
|
|
In the standard library, there are a number of linknames, for
sharing symbols within the standard library. They are not supposed
to be accessed externally. But currently there is no good
mechanism to prevent that. In the linker we have a blocklist of
linknames, which forbids linkname references other than explicitly
allowed packages. The blocklist is manually maintained, requiring
periodic manual update.
To move away from that manually maintained blocklist, this CL
introduces a new directive, linknamestd, that marks a linkname
for use within the standard library only. The linker will allow
references within the standard library and forbid others.
For a proof of concept, runtime.coroswitch is removed from the
blocklist, and replaced with linknamestd. An external reference to
it is still disallowed by the linker, as tested with
cmd/link.TestCheckLinkname with testdata/linkname/coro.go.
Change-Id: I0d0f8746b8835d8cdcfc3ff835d22a551da5f038
Reviewed-on: https://go-review.googlesource.com/c/go/+/749942
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
|
|
This doesn't need a version guard here because we will bump the version
in Go 1.27. It will be impossible to witness a generic method at the UIR
layer without being at an appropriate bitstream version.
Change-Id: Ie6c89fb98d55a3dccbd53e87860d6103582a921e
Reviewed-on: https://go-review.googlesource.com/c/go/+/761582
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Mark Freeman <markfreeman@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Generic methods have 2 sources of explicit type arguments-the receiver
and the method itself. We simply concatenate these lists when
constructing the dictionary.
Change-Id: I8ba99fa7274b594941867e9bf6c2a22356c03e46
Reviewed-on: https://go-review.googlesource.com/c/go/+/761341
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Mark Freeman <markfreeman@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Mangling produces shaped qualified identifiers using a dictionary. It's
important for determining the stenciled type to use for a given
instantiation.
Since generic methods have qualified identifiers, they need mangling.
Suppose a generic method like T[P].m[Q] and a shaped dictionary like:
{
implicits: 0
receivers: 1
targs: [go.shape.int, go.shape.int]
}
This would be shaped to T[go.shape.int].m[go.shape.int].
Change-Id: Idc4c825f77a4e9209da65b5b0acb74b9f845bde7
Reviewed-on: https://go-review.googlesource.com/c/go/+/761340
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Mark Freeman <markfreeman@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
|
|
Generic methods will be hoisted to objects so that they can get their
own dictionaries. We need to avoid name collisions, so within a
package, we qualify generic methods using their defining type.
We don't differentiate method identifiers by whether they have a pointer
or value receiver for simplicity.
Change-Id: Ied06c5e4a4c5a6f8de8027358ddbe38fc40ae452
Reviewed-on: https://go-review.googlesource.com/c/go/+/761263
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Mark Freeman <markfreeman@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Change-Id: Ia7ba5484ef5258cc8edc19b7d500e334c0e0365d
Reviewed-on: https://go-review.googlesource.com/c/go/+/761261
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Mark Freeman <markfreeman@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
This change permits shaping method expressions for generic methods.
The API is slightly different for generic and non-generic methods,
as explained in code comments.
Using OMETHEXPR minimizes the necessary changes, but forces us to
split / rejoin the linker symbol for generic methods. While a bit
odd, it seems sound.
Change-Id: Iff28b9b11b9e83f450225aba0873644633f20633
Reviewed-on: https://go-review.googlesource.com/c/go/+/761220
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Mark Freeman <markfreeman@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
During the rangefunc rewrite, the compiler must correctly identify
the target of branch statements. When a label is defined within a
nested scope - such as inside a function literal or a closure - it
can shadow a label with the same name in the outer scope.
If the rewrite logic does not account for this shadowing, it may
incorrectly associate a branch with a nested label rather than the
intended loop label. Since the typechecker already guarantees that
labels are unique within their respective scopes, any duplicate label
name encountered must belong to a nested scope. These should be
skipped to ensure branch computing correctly targets the current
range-loop scope.
Fixes #78408
Change-Id: I4dce8a4d956f41b3a717a509f8c3f7478720be9f
Reviewed-on: https://go-review.googlesource.com/c/go/+/761420
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Jakub Ciolek <jakub@ciolek.dev>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Reviewed-by: Keith Randall <khr@google.com>
|
|
The order pass ensures that initialization operations for clear(expr)
are scheduled. However, if 'expr' is a conversion that the walk pass
subsequently optimizes away or transforms, the resulting nodes can
be left in an un-walked state.
These un-walked nodes reach the SSA backend, which does not expect
high-level IR, resulting in an ICE.
This change ensures the expression is always walked during the
transformation of the 'clear' builtin.
Fixes #78410
Change-Id: I1997a28af020f39b2d325a58429eff9495048b1f
Reviewed-on: https://go-review.googlesource.com/c/go/+/760981
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
|
|
Similar to CL 685676 but for XOR.
Change-Id: Ib5ffd4c13348f176a808b3218fdbbafc2c42794f
Reviewed-on: https://go-review.googlesource.com/c/go/+/760921
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Auto-Submit: Jorropo <jorropo.pgm@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
|
|
Similar to CL 685676 but for OR.
Change-Id: I0ddfd457ed9e8888462306138a251ac48ad42084
Reviewed-on: https://go-review.googlesource.com/c/go/+/760920
Auto-Submit: Jorropo <jorropo.pgm@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
|
|
The sync package uses linkname to access internal/runtime/atomic
package's LoadAcquintptr and StoreReluintptr functions. It was not
able to import the package when the package was
runtime/internal/atomic. Now that it moves to internal/runtime,
the sync package can just import it and call the functions
normally.
Change-Id: Ic7399e33d0e965fdcdf505be67a7f90e0260ddee
Reviewed-on: https://go-review.googlesource.com/c/go/+/750160
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
|
|
Set a limit of 10 GiB for strings obtained via constant string addition.
Fixes #78346.
Change-Id: I35dbdff94f3ed32bf69654f4b3da435dad9f6236
Reviewed-on: https://go-review.googlesource.com/c/go/+/761300
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Mark Freeman <markfreeman@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Jakub Ciolek <jakub@ciolek.dev>
|