Correct 'an' to 'on' in the comment above the Stable() function.
Change-Id: I714e38b2d3a79dfd539d5368967d1c6b519cb948
Reviewed-on: https://go-review.googlesource.com/13662
Reviewed-by: Rob Pike <r@golang.org>
Fixesgolang/go#12133
CL 13630 fixed the use of a stale reg[] array in the various arch
backends which was causing the check in clearfat to pass
unconditionally on arm64.
With this check fixed, arm64 now considers REGRT1 to always be in use
as it is part of the reserved register set, see arm64/gsubr.go.
However, ppc64 does not consider REGRT1 and REGRT2 to be part of its
reserved set, so its identical clearfat check passes.
This CL removes the Reginuse check inside clearfat as REGRT1 is
guarenteed always be free on arm64.
Change-Id: I4719150d3c3378fae155b863c474529df18d4c17
Reviewed-on: https://go-review.googlesource.com/13650
Reviewed-by: Russ Cox <rsc@golang.org>
Using the type of the store argument is not safe, it may change
during rewriting, giving us the wrong store width.
(Store ptr (Trunc32to16 val) mem)
This should be a 2-byte store. But we have the rule:
(Trunc32to16 x) -> x
So if the Trunc rewrite happens before the Store -> MOVW rewrite,
then the Store thinks that the value it is storing is 4 bytes
in size and uses a MOVL. Bad things ensue.
Fix this by encoding the store width explicitly in the auxint field.
In general, we can't rely on the type of arguments, as they may
change during rewrites. The type of the op itself (as used by
the Load rules) is still ok to use.
Change-Id: I9e2359e4f657bb0ea0e40038969628bf0f84e584
Reviewed-on: https://go-review.googlesource.com/13636
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Use runtime.GOROOT instead of os.Getenv("GOROOT") to reference
trace-viewer html file. GOROOT env var is not necessary set,
runtime.GOROOT has a default value for such case.
Change-Id: I906a720f6822915bd9575756e6cbf6d622857c2b
Reviewed-on: https://go-review.googlesource.com/13593
Reviewed-by: Russ Cox <rsc@golang.org>
The reg[] array in .../gc is where truth lies. The copy in .../ARCH
is incorrect as it is mostly not updated to reflect regalloc decisions.
This bug was introduced in the rewrite
https://go-review.googlesource.com/#/c/7853/. The new reg[] array was
introduced in .../gc but not all of the uses were removed in the
.../ARCH directories.
Fixes#12133
Change-Id: I6364fc403cdab92d802d17f2913ba1607734037c
Reviewed-on: https://go-review.googlesource.com/13630
Reviewed-by: Russ Cox <rsc@golang.org>
Mul8 is lowered to MULW, but the rules for constant
folding do not handle the fact that the operands
are int8.
Change-Id: I2c336686d86249393a8079a471c6ff74e6228f3d
Reviewed-on: https://go-review.googlesource.com/13642
Reviewed-by: Keith Randall <khr@golang.org>
Disable CX as output for shift operations.
Change-Id: I85e6b22d09009b38847082dc375b6108c2dee80a
Reviewed-on: https://go-review.googlesource.com/13370
Reviewed-by: Keith Randall <khr@golang.org>
This is an initial implementation.
There are many rough edges and TODOs,
which will hopefully be polished out
with use.
Fixes#12071.
Change-Id: I1d6fd5a343063b5200623bceef2c2cfcc885794e
Reviewed-on: https://go-review.googlesource.com/13472
Reviewed-by: Keith Randall <khr@golang.org>
This omission was causing the new regalloc to fail.
Change-Id: If7ba7be38a436dbd0dd443828ddd7ebf6e35be0e
Reviewed-on: https://go-review.googlesource.com/13632
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Generating logging code every time causes large
diffs for small changes.
Since the intent is to use this for debugging only,
generate logging code only when requested.
Committed generated code will be logging free.
Change-Id: I9ef9e29c88b76c2557bad4c6b424b9db1255ec8b
Reviewed-on: https://go-review.googlesource.com/13623
Reviewed-by: Keith Randall <khr@golang.org>
Fix one test that build a violating CFG.
Change-Id: Ie0296ced602984d914a70461c76559c507ce2510
Reviewed-on: https://go-review.googlesource.com/13621
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
This makes it easier to investigate and
understand rewrite behavior.
Change-Id: I790e8964922caf98362ce8a6d6972f52d83eefa8
Reviewed-on: https://go-review.googlesource.com/13588
Reviewed-by: Keith Randall <khr@golang.org>
This claims to be autogenerated from go tool dist,
but I don't see where.
In any case, the update is trivial.
Change-Id: I58daaba755f3d34a0396005046b89411a02ada7e
Reviewed-on: https://go-review.googlesource.com/13584
Reviewed-by: Keith Randall <khr@golang.org>
We need to move the memory variable update back to before endBlock
so that all successors use the right memory value.
See https://go-review.googlesource.com/13560
Change-Id: Id72e5526c56e5e070b933d3b28dc503a5a2978dc
Reviewed-on: https://go-review.googlesource.com/13586
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Update #12108
If DUFFZERO is used within a tail call method it will overwrite the
link register.
Change-Id: I6abd2fde0f0ad909ccd55eb119b992673a74f0e2
Reviewed-on: https://go-review.googlesource.com/13570
Reviewed-by: Russ Cox <rsc@golang.org>
Fix the test broken with dee1f2 by implementing Elem()
Change-Id: I7a4a487885267c24fdc52d79fb7d450231328812
Reviewed-on: https://go-review.googlesource.com/13551
Reviewed-by: Keith Randall <khr@golang.org>
Consider OpZero to be a store so it can be eliminated by dse.
Change-Id: Idebb6a190657b76966f0c5b20f2ec9f52fe47499
Reviewed-on: https://go-review.googlesource.com/13447
Reviewed-by: Keith Randall <khr@golang.org>
Introduce pseudo-ops PanicMem and LoweredPanicMem.
PanicMem could be rewritten directly into MOVL
during lowering, but then we couldn't log nil checks.
With this change, runnable nil check tests pass:
GOSSAPKG=main go run run.go -- nil*.go
Compiler output nil check tests fail:
GOSSAPKG=p go run run.go -- nil*.go
This is due to several factors:
* SSA has improved elimination of unnecessary nil checks.
* SSA is missing elimination of implicit nil checks.
* SSA is missing extra logging about why nil checks were removed.
I'm not sure how best to resolve these failures,
particularly in a world in which the two backends
will live side by side for some time.
For now, punt on the problem.
Change-Id: Ib2ca6824551671f92e0e1800b036f5ca0905e2a3
Reviewed-on: https://go-review.googlesource.com/13474
Reviewed-by: Keith Randall <khr@golang.org>
We were not recording function calls as
changing the state of memory.
As a result, the scheduler was not aware that
storing values to the stack in order to make a
function call must happen *after* retrieving
results from the stack from a just-completed
function call.
This fixes the container/ring tests.
This was my first experience debugging an issue
using the HTML output. I'm feeling quite
pleased with it.
Change-Id: I9e8276846be9fd7a60422911b11816c5175e3d0a
Reviewed-on: https://go-review.googlesource.com/13560
Reviewed-by: Keith Randall <khr@golang.org>
p.ImportPath is the directory-derived path (like cmd/go).
p.Name is the actual package name.
Fixes#12089.
Change-Id: Ief76d42a85f811b0dfe2218affb48551527a7d44
Reviewed-on: https://go-review.googlesource.com/13530
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Hardcoded the limit on constants only allowed.
Change-Id: Idb9b07b4871db7a752a79e492671e9b41207b956
Reviewed-on: https://go-review.googlesource.com/13257
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Fixes#12086
Belongs in 1.5
There remains a question of why the Statenames table's elements
are not printed. What purpose does that serve?
Change-Id: I83fd57b81d5e5065c3397a66ed457fc0d1c041bd
Reviewed-on: https://go-review.googlesource.com/13462
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Move the known-non-nil scan outside the work loop to resolve an issue
with values that were declared outside the block being operated on.
Also consider phis whose arguments are all non-nil, as non-nil.
Change-Id: I4d5b840042de9eb181f2cb918f36913fb5d517a2
Reviewed-on: https://go-review.googlesource.com/13441
Reviewed-by: Keith Randall <khr@golang.org>
Use a version of Floyd's cycle finding algorithm,
but advance by 1 and 1/2 steps per cycle rather
than by 1 and 2. It is simpler and should be cheaper
in the normal, acyclic case.
This should fix the 386 and arm builds,
which are currently hung.
Change-Id: If8bd443011b28a5ecb004a549239991d3dfc862b
Reviewed-on: https://go-review.googlesource.com/13473
Reviewed-by: Keith Randall <khr@golang.org>
We must make sure that all loads that use a store are scheduled
before the next store. Add additional dependency edges to the
value graph to enforce this constraint.
Change-Id: Iab83644f68bc4c30637085b82ca7467b9d5513a5
Reviewed-on: https://go-review.googlesource.com/13470
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
When scanning a hex byte at EOF, the code was ungetting the eof,
which backed up the input and caused double-scanning of a byte.
Delete the call to UnreadRune.
This line appeared in 1.5 for some reason; it was not in 1.4 and
should be removed again for 1.5
Fixes#12090.
Change-Id: Iad1ce8e7db8ec26615c5271310f4b0228cca7d78
Reviewed-on: https://go-review.googlesource.com/13461
Reviewed-by: Andrew Gerrand <adg@golang.org>
Fixes#12062
Updates #11961
The sRPC nameservice was removed in pepper 42. For Go 1.5 stipulate
that NaCl requires pepper 41 only.
Change-Id: Ic88ba342d41f673391efaa96fb581712fa10a0fd
Reviewed-on: https://go-review.googlesource.com/13341
Reviewed-by: Andrew Gerrand <adg@golang.org>
Changes the torture test in #12068 from failing about 1/10 times
to not failing in almost 2,000 runs.
This was only happening in -race mode because functions are
bigger in -race mode, so a few of the helpers for heapBitsBulkBarrier
were not being inlined, and they were not marked nosplit,
so (only in -race mode) the write barrier was being preempted by GC,
causing missed pointer updates.
Filed issue #12069 for diagnosis of any other similar errors.
Fixes#12068.
Change-Id: Ic174d9b050ba278b18b08ab0d85a73c33bd5b175
Reviewed-on: https://go-review.googlesource.com/13364
Reviewed-by: Austin Clements <austin@google.com>
Also, crash early on non-Linux SMP ARM systems when GOARM < 7;
without the proper synchronization, SMP cannot work.
Linux is okay because we call kernel-provided routines for
synchronization and barriers, and the kernel takes care of
providing the right routines for the current system.
On non-Linux systems we are left to fend for ourselves.
It is possible to use different synchronization on GOARM=6,
but it's too late to do that in the Go 1.5 cycle.
We don't believe there are any non-Linux SMP GOARM=6 systems anyway.
Fixes#12067.
Change-Id: I771a556e47893ed540ec2cd33d23c06720157ea3
Reviewed-on: https://go-review.googlesource.com/13363
Reviewed-by: Austin Clements <austin@google.com>
Don't nilcheck values that were constructed as a result of OpAddr or
OpAddPtr.
Change-Id: I38053e905d1b76a2a64e77f84e444d38a5217108
Reviewed-on: https://go-review.googlesource.com/13256
Reviewed-by: David Chase <drchase@google.com>
Rather than require an explicit Copy on the RHS of rewrite rules,
use rulegen magic to add it.
The advantages to handling this in rulegen are:
* simpler rules
* harder to accidentally miss a Copy
Change-Id: I46853bade83bdf517eee9495bf5a553175277b53
Reviewed-on: https://go-review.googlesource.com/13242
Reviewed-by: Keith Randall <khr@golang.org>
Currently, runtime.Goexit() calls goexit()—the goroutine exit stub—to
terminate the goroutine. This *mostly* works, but can cause a
"leftover stack barriers" panic if the following happens:
1. Goroutine A has a reasonably large stack.
2. The garbage collector scan phase runs and installs stack barriers
in A's stack. The top-most stack barrier happens to fall at address X.
3. Goroutine A unwinds the stack far enough to be a candidate for
stack shrinking, but not past X.
4. Goroutine A calls runtime.Goexit(), which calls goexit(), which
calls goexit1().
5. The garbage collector enters mark termination.
6. Goroutine A is preempted right at the prologue of goexit1() and
performs a stack shrink, which calls gentraceback.
gentraceback stops as soon as it sees goexit on the stack, which is
only two frames up at this point, even though there may really be many
frames above it. More to the point, the stack barrier at X is above
the goexit frame, so gentraceback never sees that stack barrier. At
the end of gentraceback, it checks that it saw all of the stack
barriers and panics because it didn't see the one at X.
The fix is simple: call goexit1, which actually implements the process
of exiting a goroutine, rather than goexit, the exit stub.
To make sure this doesn't happen again in the future, we also add an
argument to the stub prototype of goexit so you really, really have to
want to call it in order to call it. We were able to reliably
reproduce the above sequence with a fair amount of awful code inserted
at the right places in the runtime, but chose to change the goexit
prototype to ensure this wouldn't happen again rather than pollute the
runtime with ugly testing code.
Change-Id: Ifb6fb53087e09a252baddadc36eebf954468f2a8
Reviewed-on: https://go-review.googlesource.com/13323
Reviewed-by: Russ Cox <rsc@golang.org>
This makes TestTraceStressStartStop much less flaky.
Running under stress, it changes the failure rate from
above 1/100 to under 1/50000. That very unlikely
failure happens when an unexpected GoSysExit is
written. Not sure how that happens yet, but it is much
less important.
Fixes#11953.
Change-Id: I034671936334b4f3ab733614ef239aa121d20247
Reviewed-on: https://go-review.googlesource.com/13321
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>