Previously, mkvar treated, for example, 0(AX) the same as AX.
As a result, a move to an indirect address would be marked as
*setting* the register, rather than just using it, resulting
in unnecessary register moves.  Fix this by not producing
variables for indirect addresses.

LGTM=rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/164610043

So far all of our architectures have had at most 32 registers,
so we've been able to use entry 0 in the Bits uint32 array
directly as a register mask.  Power64 has 64 registers, so
this converts Bits to a uint64 array so we can continue to use
entry 0 directly as a register mask on Power64.

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/169060043

On power64x, this one line in live.go reports that t is live
because of missing optimization passes.  This isn't what this
test is trying to test, so shuffle bad40 so that it still
accomplishes the intent of the test without also depending on
optimization.

LGTM=rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/167110043

The remaining failures in this test are because of incomplete
optimization support on power64x.  Tracked in issue 9058.

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/168130043

Print PC stored in target Prog* of branch instructions when
available instead of the offset stored in the branch
instruction.  The offset tends to be wrong after code
transformations, so previously this led to confusing listings.

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/168980043

Previously, nilopt was disabled on power64x because it threw
away "seemly random segments of code."  Indeed, excise on
power64x failed to preserve the link field, so it excised not
only the requested instruction but all following instructions
in the function.  Fix excise to retain the link field while
otherwise zeroing the instruction.

This makes nilopt safe on power64x.  It still fails
nilptr3.go's tests for removal of repeated nil checks because
those depend on also optimizing away repeated loads, which
doesn't currently happen on power64x.

LGTM=dave, rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/168120043

Trivial merge except for src/runtime/asm_power64x.s and
src/runtime/signal_power64x.c

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/168950044

LGTM=r, rsc
R=r, rsc, adg
CC=golang-codereviews
https://golang.org/cl/168890043

LGTM=rsc, austin
R=austin, rsc, bradfitz
CC=golang-codereviews
https://golang.org/cl/164300043

On heavily loaded build servers, a 5 second timeout is too aggressive,
which causes this test to fail spuriously.

LGTM=iant
R=iant
CC=golang-codereviews, sqweek
https://golang.org/cl/170850043

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/164410043

The GC info masks for slices and strings were changed in
commit caab29a25f68, but the reference masks used by
gcinfo_test for power64x hadn't caught up.  Now they're
identical to amd64, so this CL fixes this test by combining
the reference masks for these platforms.

LGTM=rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/162620044

reflect/asm_power64x.s was missing changes made to other
platforms for stack maps.  This CL ports those changes.  With
this fix, the reflect test passes on power64x.

LGTM=rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/170870043

fastrand1 depends on testing the high bit of its uint32 state.
For efficiency, all of the architectures implement this as a
sign bit test.  However, on power64, fastrand1 was using a
64-bit sign test on the zero-extended 32-bit state.  This
always failed, causing fastrand1 to have very short periods
and often decay to 0 and get stuck.

Fix this by using a 32-bit signed compare instead of a 64-bit
compare.  This fixes various tests for the randomization of
select of map iteration.

LGTM=rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/166990043

LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/168860044

Using -test.cpu=1,1 made it crash before.

Fixes #9024

LGTM=iant
R=adg, iant
CC=golang-codereviews
https://golang.org/cl/169860043

LGTM=iant
R=golang-codereviews, iant, bradfitz
CC=golang-codereviews
https://golang.org/cl/163690043

LGTM=bradfitz
R=adg, bradfitz
CC=golang-codereviews
https://golang.org/cl/162580043

All three cases of clearfat were wrong on power64x.

The cases that handle 1032 bytes and up and 32 bytes and up
both use MOVDU (one directly generated in a loop and the other
via duffzero), which leaves the pointer register pointing at
the *last written* address.  The generated code was not
accounting for this, so the byte fill loop was re-zeroing the
last zeroed dword, rather than the bytes following the last
zeroed dword.  Fix this by simply adding an additional 8 byte
offset to the byte zeroing loop.

The case that handled under 32 bytes was also wrong.  It
didn't update the pointer register at all, so the byte zeroing
loop was simply re-zeroing the beginning of region.  Again,
the fix is to add an offset to the byte zeroing loop to
account for this.

LGTM=dave, bradfitz
R=rsc, dave, bradfitz
CC=golang-codereviews
https://golang.org/cl/168870043

Fixes #9029

LGTM=adg, r
R=r, adg
CC=golang-codereviews
https://golang.org/cl/161630044

Apparently I had already moved on to fixing another problem
when I submitted CL 169790043.

LGTM=dave
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/165210043

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/170770043

TBR=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/155560045

LGTM=iant
R=golang-codereviews, iant
CC=adg, golang-codereviews
https://golang.org/cl/165170043

No real problems found.  Just lots of argument names that
didn't quite match up.

LGTM=rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/169790043

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/169800043

+ Regression test.

Fixes #9026.

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/162490043

LGTM=bradfitz
R=rsc, bradfitz
CC=golang-codereviews
https://golang.org/cl/162500043

This adds a test to runtime·check to ensure CAS of large
unsigned 32-bit numbers does not accidentally sign-extend its
arguments.

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/162490044

Previously, the power64x runtime assembly was sloppy about
using sign-extending versus zero-extending moves of arguments
and return values.  I think all of the cases that actually
mattered have been fixed in recent CLs; this CL fixes up the
few remaining mismatches.

LGTM=rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/162480043

It doesn't simplify, because it wasn't even possible before.

LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/164250043

LGTM=adg
R=r, adg
CC=golang-codereviews
https://golang.org/cl/165890043

TBR=rsc
R=r, rsc
CC=golang-codereviews
https://golang.org/cl/164240043

TBR=adg
CC=golang-codereviews
https://golang.org/cl/167890043

If you get a stack of PCs from Callers, it would be expected
that every PC is immediately after a call instruction, so to find
the line of the call, you look up the line for PC-1.
CL 163550043 now explicitly documents that.

The most common exception to this is the top-most return PC
on the stack, which is the entry address of the runtime.goexit
function. Subtracting 1 from that PC will end up in a different
function entirely.

To remove this special case, make the top-most return PC
goexit+PCQuantum and then implement goexit in assembly
so that the first instruction can be skipped.

Fixes #7690.

LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/170720043

LGTM=rsc
R=golang-codereviews, bradfitz, rsc
CC=golang-codereviews
https://golang.org/cl/163540043

First draft now complete.

LGTM=rsc
R=golang-codereviews, rsc
CC=golang-codereviews
https://golang.org/cl/170750043

This removes a bunch of ugly duplicate code.
The end goal is to factor the disassembly code
into cmd/internal/objfile too, so that pprof can use it,
but one step at a time.

LGTM=r, iant
R=r, alex.brainman, iant
CC=golang-codereviews
https://golang.org/cl/149400043

LGTM=iant, cmang
R=cmang, iant, rsc
CC=golang-codereviews
https://golang.org/cl/169760043

Originally traceback was only used for printing the stack
when an unexpected signal came in. In that case, the
initial PC is taken from the signal and should be used
unaltered. For the callers, the PC is the return address,
which might be on the line after the call; we subtract 1
to get to the CALL instruction.

Traceback is now used for a variety of things, and for
almost all of those the initial PC is a return address,
whether from getcallerpc, or gp->sched.pc, or gp->syscallpc.
In those cases, we need to subtract 1 from this initial PC,
but the traceback code had a hard rule "never subtract 1
from the initial PC", left over from the signal handling days.

Change gentraceback to take a flag that specifies whether
we are tracing a trap.

Change traceback to default to "starting with a return PC",
which is the overwhelmingly common case.

Add tracebacktrap, like traceback but starting with a trap PC.

Use tracebacktrap in signal handlers.

Fixes #7690.

LGTM=iant, r
R=r, iant
CC=golang-codereviews
https://golang.org/cl/167810044