A bunch of tests had broken yet undetected syntax errors
in their assembly output regexps. Things like mismatched quotes,
using ^ instead of - for negation, etc.
In addition, since CL 716060 using commas as separators between
regexps doesn't work, and ends up just silently dropping every
regexp after the comma.
Fix all these things, and add a test to make sure that we're not
silently dropping regexps on the floor.
After this CL I will do some cleanup to align with CL 716060, like
replacing commas and \s with spaces (which was the point of that CL,
but wasn't consistently rewritten everywhere).
Change-Id: I54f226120a311ead0c6c62eaf5d152ceed106034
Reviewed-on: https://go-review.googlesource.com/c/go/+/760521
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Paul Murphy <paumurph@redhat.com>
Auto-Submit: Keith Randall <khr@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>
This is hit 308 times (unique by LOC) when building the std.
There are many hits in defer generated code.
My original intent was to optimize cryptographic code that
uses And to implement modulus by a power of two but the
number is always smaller than the modulus,
it also works there but there (unsurprisingly) far fewer hits.
Change-Id: Ia7a9a57099b98de966673c6e8231ef09f7c80964
Reviewed-on: https://go-review.googlesource.com/c/go/+/750200
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Jorropo <jorropo.pgm@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
On the final iteration we need space below start (which becomes end)
such that i-step does not overflow or underflow.
In other words the code used to assume that the last time the loop header
execute `start < i - step` (or `<=`, `>` `>=` based on the loop)
is always false.
And it seems correct since by definition the only way for it to be the
last's loop header execution is when the condition becomes false.
However here is an example with uint (even tho the code doesn't
already support them) to make things simpler:
start = 1
i = 2
step = 100
We do 2 - 100 which should give us 1 < -98 == false breaking the loop;
Instead we get 18446744073709551518 which gives
1 < 18446744073709551518 == true which keeps the loop going.
This patch fixes this issue by ensuring that in the last execution of
a loop header the induction variable does not underflow or overflow.
Fixes#78303
Change-Id: I64e8e8592b023d79fdbc7f1598d584726ed601f5
Reviewed-on: https://go-review.googlesource.com/c/go/+/758801
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Jorropo <jorropo.pgm@gmail.com>
Reviewed-by: Jakub Ciolek <jakub@ciolek.dev>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
On ppc64/ppc64le, rewrite (x + x) << c to x << (c+1) for constant shifts. This removes an ADD, shortens the dependency chain, and reduces code size.
Add rules for both 64-bit (SLDconst) and 32-bit (SLWconst), and extend
test/codegen/shift.go with ppc64x checks to assert a single SLD/SLW and
forbid ADD. Aligns ppc64 with other architectures that already assert
similar codegen in shift.go.
Change-Id: Ie564afbb029a5bd48887b82b0c455ca1dddd5508
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/+/712000
Reviewed-by: Archana Ravindar <aravinda@redhat.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
The test is only run when GOEXPERIMENT=simd, and currently
there are no trybots for that. This error was found after
merging to dev.simd, where such trybots ARE run.
To run this test:
```
GOEXPERIMENT=simd go test -run=Test/simd.go -v cmd/internal/testdir -target=darwin/amd64
```
or -target=linux/amd64 if that is your OS.
Change-Id: I70e469f080bc62300ff9c18350cc805985e33f9e
Reviewed-on: https://go-review.googlesource.com/c/go/+/758980
Auto-Submit: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Look into the following block(s) for a load that can be paired with
the load we're trying to pair up.
This particularly helps the generated equality functions. Instead of doing
MOVD x(R0), R2
MOVD x(R1), R3
CMP R2, R3
BNE noteq
MOVD x+8(R0), R2
MOVD x+8(R1), R3
CMP R2, R3
BNE noteq
we do
LDP x(R0), (R2, R4)
LDP x(R1), (R3, R5)
CMP R2, R3
BNE noteq
CMP R4, R5
BNE noteq
Removes 5296 bytes of code from cmd/go.
Change-Id: I6368686892ac944783c8b07ed7252126d1ef4031
Reviewed-on: https://go-review.googlesource.com/c/go/+/740741
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Contrive to have a bunch of stack shrinking going on during
memclrNoHeapPointersPreemptible calls.
Fails at tip with this patch:
--- a/src/runtime/malloc.go
+++ b/src/runtime/malloc.go
@@ -2184,6 +2184,7 @@ func reusableSize(size uintptr) bool {
// Use this with care; if the data being cleared is tagged to contain
// pointers, this allows the GC to run before it is all cleared.
func memclrNoHeapPointersChunked(size uintptr, x unsafe.Pointer) {
+ y := uintptr(x)
if getg().preempt {
// TODO: no need for this, except to test that
// the preemption point is ok for small zeroings.
@@ -2193,6 +2194,7 @@ func memclrNoHeapPointersChunked(size uintptr, x unsafe.Pointer) {
// may hold locks, e.g., profiling
goschedguarded()
}
+ x = unsafe.Pointer(y)
// got this from benchmarking. 128k is too small, 512k is too large.
const chunkBytes = 256 * 1024
for size > chunkBytes {
Update #78081
Change-Id: Id8f87a4b0d0970cbf971c90ab87703a9e5b3f121
Reviewed-on: https://go-review.googlesource.com/c/go/+/755942
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Fixes#77720
Add a generic SSA rewrite that forwards `Load` from a `Move` destination
back to the `Move` source when it is provably safe, so field reads like
`s.h.Value().typ` don’t force a full struct copy.
- Add `Load <- Move` rewrite in `generic.rules` with safety guard:
non-volatile source
- Tweak `fixedbugs/issue22200*` so that it can still trigger the "stack frame too large" error.
- Regenerate `rewritegeneric.go`.
- Add `test/codegen/moveload.go` to assert no `MOVUPS` and direct `MOVBLZX`
in both direct and inlined forms.
Benchmark results (linux/amd64, i7-14700KF):
$ go test cmd/compile/internal/test -run='^$' -bench='MoveLoad' -count=20
Before:
BenchmarkMoveLoadTypViaValue-20 ~76.9 ns/op
BenchmarkMoveLoadTypViaPtr-20 ~1.97 ns/op
After:
BenchmarkMoveLoadTypViaValue-20 ~1.894 ns/op
BenchmarkMoveLoadTypViaPtr-20 ~1.905 ns/op
The rewrite removes the redundant struct copy in
`s.h.Value().typ`, bringing it in line with the direct pointer form.
Change-Id: Iddf2263e390030ba013e0642a695b87c75f899da
Reviewed-on: https://go-review.googlesource.com/c/go/+/748200
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Mark Freeman <markfreeman@google.com>
type I interface {
foo()
}
type S struct {
I
}
Because I is embedded in S, S needs a foo method. We generate a
wrapper function to implement (*S).foo. It just loads the embedded
field I out of S and calls foo on it.
When the thing in S.I itself needs a wrapper, then we have a wrapper
calling another wrapper. This can continue, leaving a potentially long
sequence of wrappers on the stack. When we then call runtime.Callers
or friends, we have to walk an unbounded number of frames to find a
bounded number of non-wrapper frames.
This really happens, for instance with I = context.Context, S =
context.ValueCtx, and runtime.Callers = pprof sample (for any of
context.Context's methods).
To fix, make the interface call in the wrapper a tail call.
That way, the number of wrapper frames on the stack does not
increase when there are lots of wrappers happening.
Fixes#75764Fixes#77781
Change-Id: I03b1731159d9218c7f14f72ecbbac822d6a6bb87
Reviewed-on: https://go-review.googlesource.com/c/go/+/751465
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@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>
Before this CL, the simdgen contains a sign check to selectively enable
such rules for deduplication purposes. This left out `VPSRL` as it's
only available in unsigned form. This CL fixes that.
It looks like the previous documentation fix to SHA instruction might
not had run go generate, so this CL also contains the generated code for
that fix.
There is also a weird phantom import in
cmd/compile/internal/ssa/issue77582_test.go
This CL also fixes that
The trybot didn't complain?
Change-Id: Ibbf9f789c1a67af1474f0285ab376bc07f17667e
Reviewed-on: https://go-review.googlesource.com/c/go/+/748501
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
