When we deadcode-remove a block which is a write barrier test,
remove that block from the list of write barrier test blocks.
Fixes#25516
Change-Id: I1efe732d5476003eab4ad6bf67d0340d7874ff0c
Reviewed-on: https://go-review.googlesource.com/115037
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
It's harmless, and can be useful to see what's happening under the hood.
Fixes#24593.
Change-Id: Iacff378471e86c33aa048161cd65c504709fb339
Reviewed-on: https://go-review.googlesource.com/115075
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
vet's buildtag check looks for malformed build tag comments. Since these
can appear in Go files as well as non-Go files (such as assembly files),
it must read the file line by line instead of using go/token or go/ast
directly.
However, this method runs into false positives if there are any lines in
the code that look like comments, but are not. For example:
$ cat f.go
package main
const foo = `
//+build ignore
`
$ go vet f.go
./f.go:3: +build comment must appear before package clause and be followed by a blank line
This bug has been popping up more frequently since vet started being run
with go test, so it is important to make the check as precise as
possible.
To avoid the false positive, when checking a Go file, cross-check that a
line that looks like a comment actually corresponds to a comment in the
go/ast syntax tree. Since vet already obtains the syntax trees for all
the Go files, it checks, this change means very little extra work for
the check.
While at it, add a badf helper function to simplify the code that
reports warnings in the buildtag check.
Fixes#13533.
Change-Id: I484a16da01363b409ec418c313634171bf85250b
Reviewed-on: https://go-review.googlesource.com/111415
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Extend stack frame limit of 1GB to include large argument/return areas.
Argument/return areas are part of the parent frame, not the frame itself,
so they need to be handled separately.
Fixes#25507.
Change-Id: I309298a58faee3e7c1dac80bd2f1166c82460087
Reviewed-on: https://go-review.googlesource.com/115036
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Change cgo to follow https://golang.org/s/generatedcode.
For the C code we continue to use /* */ comments, so they don't follow
the format exactly. It doesn't really matter since the format is only
for Go code anyhow. This CL changes the C code to be similar for
consistency.
Fixes#25623
Change-Id: Idcfee53ec4069924d173ab8cedeb7bcfb7312863
Reviewed-on: https://go-review.googlesource.com/115035
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
This change uses errorCheck and wantedErrors functions copied from
the test/run.go to eliminate use of the test/errchk perl script.
Tests' error messages that contained full filenames were changed to
have base filenames because the errorCheck function processes output
from "go vet" in the same way.
Fixes#20032.
Change-Id: Ieb7be67c2d7281b9648171c698398449b7e2d4dd
Reviewed-on: https://go-review.googlesource.com/114176
Run-TryBot: Yury Smolsky <yury@smolsky.by>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
If a span of coverable code is empty (e.g. an empty select clause)
then there will be two Boundary values with the same offset. In that
case, the starting Boundary needs to come first so that the generated
HTML output will open the <span> tag before it tries to close it.
Change-Id: Ib44a8b7c36ae57757c18b6cceb7a88ffa4e95394
Reviewed-on: https://go-review.googlesource.com/114855
Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
We look for "-o /dev/null", and, if found, pretend that there was no
"-o" option and don't generate an action to create the final executable.
We look for "go build x.go", and, if found, and if -o was not used,
pretend that the user specified "-o x".
Unfortunately, we were doing those in the wrong order, so that "go
build -o /dev/null x.go" would first clear the "-o" option and then
set it to "-o x".
This CL flips the order so that the right thing happens.
Fixes#25579
Change-Id: Ic9556ac0a57f7b45b685951bc96ba5ea4633b860
Reviewed-on: https://go-review.googlesource.com/114715
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
I don't know why these files were not formatted. Perhaps because
their changes came from Github PRs?
Change-Id: Ida8d7b9a36f0d1064caf74ca1911696a247a9bbe
Reviewed-on: https://go-review.googlesource.com/114824
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
go build
command is short for
go build .
and it builds . package. When command above is executed from
directory inside of GOPATH, it uses GOPATH to calculate package
source directory. So . package uses GOPATH as part of package
source directory.
On the other hand
go build -ldflags=abc
only passes flag to the linker for packages that are listed
on the command line. The command above assumes . package again,
and that package source path is compared with current directory.
Current code compares result of os.Getwd with what GOPATH
environment variable contains. But these values might differ
in letter case on Windows. For example, one might return
c:\gopath\..., while the other might contain C:\GOPATH.
Fixes#24750Fixes#24232Fixes#25046
Change-Id: I03d8c7a9b73e847f88ae61c88cd41efa546c6d0e
Reviewed-on: https://go-review.googlesource.com/109235
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Fix a problem in DWARF inline debug generation relating to handling of
statically unreachable local variables. For a function such as:
const always = true
func HasDeadLocal() int {
if always {
return 9
}
x := new(Something)
...
return x.y
}
the variable "x" is placed onto the Dcl list for the function during
parsing, but the actual declaration node is deleted later on when
gc.Main invokes "deadcode". Later in the compile the DWARF code emits
an abstract function with "x" (since "x" was on the Dcl list at the
point of the inline), but the export data emitted does not contain
"x". This then creates clashing/inconsistant DWARF abstract function
DIEs later on if HasDeadLocal is inlined in somewhere else.
As a fix, the inliner now pruned away variables such as "x" when
creating a copy of the Dcl list as part of the inlining; this means
that both the export data generator and the DWARF emitter wind up
seeing a consistent picture.
Fixes#25459
Change-Id: I753dc4e9f9ec694340adba5f43c907ba8cc9badc
Reviewed-on: https://go-review.googlesource.com/114090
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
While fixing some failing tests, CL 114416 also picked up the newly
added TestXattr from golang.org/x/sys/unix which fails on android. Pick
up CL 114535 to fix it as well.
Also pick up CL 114616 to fix TestStatx occasionally failing on linux.
Change-Id: I6ebebd7761fa7a086d96ee0447dbbc5c6b94131d
Reviewed-on: https://go-review.googlesource.com/114575
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-W and -w turn on printing of Nodes for both order and walk.
I have found their output mildly incomprehensible for years.
Improve it, at long last.
Change-Id: Ia05d77e59aa741c2dfc9fcca07f45019420b655e
Reviewed-on: https://go-review.googlesource.com/114520
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When using gccgo/GoLLVM, there is no package file for a standard
library package. Since it is impossible for the go tool to rebuild the
package, and since the package file exists only in the form of a .gox
file, this seems like the best choice. Unfortunately it was confusing
vet, which wanted to see a real file. This caused vet to report errors
about missing package files for standard library packages. The
gccgoimporter knows how to correctly handle this case. Fix this by
1) telling vet which packages are standard;
2) letting vet skip those packages;
3) letting the gccgoimporter handle this case.
As a separate required fix, gccgo/GoLLVM has no runtime/cgo package,
so don't try to depend on it (as it happens, this fixes#25324).
The result is that the cmd/go vet tests pass when using -compiler=gccgo.
Fixes#25324
Change-Id: Iba8f948fe944da5dc674f580bd3321929ee50fa0
Reviewed-on: https://go-review.googlesource.com/113716
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Pick up the changes from CL 114395, CL 114396 and CL 114415.
By re-running govendor in the latest version, some files from
golang.org/x/sys/unix which are ignored for the build also got removed
from the vendored copy.
Updates #25528
Updates #25535
Change-Id: I5c0002fc3a37d6abaafed2e15cc3e2ade803ad7b
Reviewed-on: https://go-review.googlesource.com/114416
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This commit fixes a regression with wasm caused by a367f44c18.
It adds optimizations to the lowering rules of wasm to ensure
that the lowered version of the code generated for write barriers
is simple enough so it can be processed by Liveness.markUnsafePoints.
Change-Id: Ic98f0dd3791fe1df23dcb34d2457fbde7ffce441
Reviewed-on: https://go-review.googlesource.com/114375
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Apparently a LoadReg can take a Phi as its argument. The Phi has names
in the NamedValue table, so just read the Load's names from the Phi.
The example given, XORKeyStream in chacha20, is pretty complicated so I
didn't try to actually debug it and verify that the results are right.
But the debug logging looks reasonable, with the right names in the right
registers at the right times.
Fixes#25404
Change-Id: I2c3183dcfb033948556d6805bd66c22c0b45625c
Reviewed-on: https://go-review.googlesource.com/114008
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Remove the unexpected function, which is a lot less relevant now that
the generation basically can't detect invalid states, and make sure no
logging appears without -d locationlists=2.
Updates #25404
Change-Id: If3522df5a7397f2e7b43cb808936e319132132b6
Reviewed-on: https://go-review.googlesource.com/114007
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Go's SSA instructions only operate on registers. For example, an add
instruction would read two registers, do the addition and then write
to a register. WebAssembly's instructions, on the other hand, operate
on the stack. The add instruction first pops two values from the stack,
does the addition, then pushes the result to the stack. To fulfill
Go's semantics, one needs to map Go's single add instruction to
4 WebAssembly instructions:
- Push the value of local variable A to the stack
- Push the value of local variable B to the stack
- Do addition
- Write value from stack to local variable C
Now consider that B was set to the constant 42 before the addition:
- Push constant 42 to the stack
- Write value from stack to local variable B
This works, but is inefficient. Instead, the stack is used directly
by inlining instructions if possible. With inlining it becomes:
- Push the value of local variable A to the stack (add)
- Push constant 42 to the stack (constant)
- Do addition (add)
- Write value from stack to local variable C (add)
Note that the two SSA instructions can not be generated sequentially
anymore, because their WebAssembly instructions are interleaved.
Design doc: https://docs.google.com/document/d/131vjr4DH6JFnb-blm_uRdaC0_Nv3OUwjEY5qVCxCup4
Updates #18892
Change-Id: Ie35e1c0bebf4985fddda0d6330eb2066f9ad6dec
Reviewed-on: https://go-review.googlesource.com/103535
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The upstream pprof implements the readline feature using
the github.com/chzyer/readline package in its pprof.go main.
It would be ideal to use the same readline support package as
the upstream for better user experience and code maintenance.
However, bringing in third-party packages requires more work
than I envisioned (e.g. clean up the vendored code to meet the
expected standard - iow don't break builders).
As a result, this change implements the similar feature
for the pprof command included in the go distribution
(cmd/pprof/pprof.go) using golang.org/x/crypto/ssh/terminal
for now.
Auto-completion is not yet supported (same in the upstream).
The feature is enabled only in linux, windows, darwin, and
only when terminal support is available.
This change brings in new vendored packages,
golang.org/x/crypto/ssh/terminal and
golang.org/x/sys/{unix,windows}.
For #14041
Change-Id: If4a790796acf2ab20f7e81268b9d9354c5a5cd2b
Reviewed-on: https://go-review.googlesource.com/112436
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
While next-ing over a call in gdb, if execution of that call
causes a goroutine's stack to grow (i.e., be moved), gdb loses
track and runs ahead to the next breakpoint, or to the end of
the program, whichever comes first.
Prevent this by preemptively growing the stack so that
ssa/debug_test.go will reliably measure what is intended,
the goodness of line number placement and variable printing.
Fixes#25497.
Change-Id: I8daf931650292a8c8faad2285d7fd405f2157bd2
Reviewed-on: https://go-review.googlesource.com/114080
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This change adds Yi8 forms for every ytab that had them before AVX-512 patch.
The rationale is backwards-compatibility.
EVEX forms remain strict and unchanged as they're not bound to any
backwards-compatibility issues.
Fixes#25510
Change-Id: Icd692266010ed64c9fe47cc837afc2edf2ad2d1d
Reviewed-on: https://go-review.googlesource.com/114136
Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ilya Tocar <ilya.tocar@intel.com>
Fixes builders that do not have cgo installed.
Change-Id: I719b7959226b0e67c3ffc11e071784787cabc5ab
Reviewed-on: https://go-review.googlesource.com/114235
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Windows does not allow to delete opened file.
Fixes#24704
Change-Id: Idfca2d00a2c46bdd9bd2a721478bfd003c474ece
Reviewed-on: https://go-review.googlesource.com/113935
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In rare circumstances that we don't yet fully understand, the g
register can be spilled to the stack and then reloaded. If this
happens, liveness analysis sees a pointer load into a
non-general-purpose register and panics.
We should fix the root cause of this, but fix the build for now by
ignoring pointer loads into the g register.
For #25504.
Change-Id: I0dfee1af9750c8e9157c7637280cdf07118ef2ca
Reviewed-on: https://go-review.googlesource.com/114081
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
There's semantically-but-not-literally equivalent code in
two cases for joining blocks' value lists in ssa/fuse.go.
It can be made literally equivalent, then commoned up.
Updates #25426.
Change-Id: Id1819366c9d22e5126f9203dcd4c622423994110
Reviewed-on: https://go-review.googlesource.com/113719
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
This moves the bvec hash table logic out of Liveness.compact and into
a bvecSet type. Furthermore, the bvecSet type has the ability to grow
dynamically, which the current implementation doesn't. In addition to
making the code cleaner, this will make it possible to incrementally
compact liveness bitmaps.
Passes toolstash -cmp
Updates #24543.
Change-Id: I46c53e504494206061a1f790ae4a02d768a65681
Reviewed-on: https://go-review.googlesource.com/110176
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Currently Liveness.epilogue makes three passes over the Blocks, but
there's no need to do this. Combine them into a single pass. This
eliminates the need for blockEffects.lastbitmapindex, but, more
importantly, will let us incrementally compact the liveness bitmaps
and significantly reduce allocatons in Liveness.epilogue.
Passes toolstash -cmp.
Updates #24543.
Change-Id: I27802bcd00d23aa122a7ec16cdfd739ae12dd7aa
Reviewed-on: https://go-review.googlesource.com/110175
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Until vgo sorts out and cleans up the vendoring process.
Ran govendor to update packages the cmd/pprof depends on
which resulted in deletion of some of unnecessary files.
Change-Id: Idfba53e94414e90a5e280222750a6df77e979a16
Reviewed-on: https://go-review.googlesource.com/114079
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
On OSX 10.12 and earlier, paired with XCode 9.0,
specifying DWARF version 3 causes dsymutil to misbehave.
Version 2 appears to be good enough to allow processing
of the prologue_end opcode on (at least one version of)
Linux and OSX 10.13.
Fixes#25451.
Change-Id: Ic760e34248393a5386be96351c8e492da1d3413b
Reviewed-on: https://go-review.googlesource.com/114015
Reviewed-by: Alessandro Arzilli <alessandro.arzilli@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Needs the go compiler to be build with GOEXPERIMENT=debugcpu to be active.
The GODEBUGCPU environment variable can be used to disable usage of
specific processor features in the Go standard library.
This is useful for testing and benchmarking different code paths that
are guarded by internal/cpu variable checks.
Use of processor features can not be enabled through GODEBUGCPU.
To disable usage of AVX and SSE41 cpu features on GOARCH amd64 use:
GODEBUGCPU=avx=0,sse41=0
The special "all" option can be used to disable all options:
GODEBUGCPU=all=0
Updates #12805
Updates #15403
Change-Id: I699c2e6f74d98472b6fb4b1e5ffbf29b15697aab
Reviewed-on: https://go-review.googlesource.com/91737
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
When rulegen complains about a missing type, report the line number
in the rules file.
Change-Id: Ic7c19e1d5f29547911909df5788945848a6080ff
Reviewed-on: https://go-review.googlesource.com/114004
Reviewed-by: David Chase <drchase@google.com>
This adds a mechanism for debuggers to safely inject calls to Go
functions on amd64. Debuggers must participate in a protocol with the
runtime, and need to know how to lay out a call frame, but the runtime
support takes care of the details of handling live pointers in
registers, stack growth, and detecting the trickier conditions when it
is unsafe to inject a user function call.
Fixes#21678.
Updates derekparker/delve#119.
Change-Id: I56d8ca67700f1f77e19d89e7fc92ab337b228834
Reviewed-on: https://go-review.googlesource.com/109699
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This extends the liveness analysis to track registers containing live
pointers. We do this by tracking bitmaps for live pointer registers
in parallel with bitmaps for stack variables.
This does not yet do anything with these liveness maps, though they do
appear in the debug output for -live=2.
We'll optimize this in later CLs:
name old time/op new time/op delta
Template 193ms ± 5% 195ms ± 2% ~ (p=0.050 n=9+9)
Unicode 97.7ms ± 2% 98.4ms ± 2% ~ (p=0.315 n=9+10)
GoTypes 674ms ± 2% 685ms ± 1% +1.72% (p=0.001 n=9+9)
Compiler 3.21s ± 1% 3.28s ± 1% +2.28% (p=0.000 n=10+9)
SSA 7.70s ± 1% 7.79s ± 1% +1.07% (p=0.015 n=10+10)
Flate 130ms ± 3% 133ms ± 2% +2.19% (p=0.003 n=10+10)
GoParser 159ms ± 3% 161ms ± 2% +1.51% (p=0.019 n=10+10)
Reflect 444ms ± 1% 450ms ± 1% +1.43% (p=0.000 n=9+10)
Tar 181ms ± 2% 183ms ± 2% +1.45% (p=0.010 n=10+9)
XML 230ms ± 1% 234ms ± 1% +1.56% (p=0.000 n=8+9)
[Geo mean] 405ms 411ms +1.48%
No effect on binary size because we're not yet emitting the register
maps.
For #24543.
Change-Id: Ieb022f0aea89c0ea9a6f035195bce2f0e67dbae4
Reviewed-on: https://go-review.googlesource.com/109352
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
For register maps, we need a dense numbering of registers that may
contain pointers of interest to the garbage collector. Add this to
Register and compute it from the GP register set.
For #24543.
Change-Id: If6f0521effca5eca4d17895468b1fc52d67e0f32
Reviewed-on: https://go-review.googlesource.com/109351
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Compiling without optimizations (-N) can result in write barrier
blocks that have been optimized away but not actually pruned from the
block set. Fix unsafe-point analysis to recognize and ignore these.
For #24543.
Change-Id: I2ca86fb1a0346214ec71d7d6c17b6a121857b01d
Reviewed-on: https://go-review.googlesource.com/114076
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
- Uncomment tests for AVX512 encoder
- Permit instruction suffixes for x86
- Permit limited reg list [reg-reg] syntax for x86 for multi-source ops
- EVEX encoding support in obj/x86 (Z-cases, asmevex, etc.)
- optabs and ytabs generated by x86avxgen (https://golang.org/cl/107216)
Note: suffix formatting implemented with updated CConv function.
Now arch asm backend should register formatting function by
calling RegisterOpSuffix.
Updates #22779
Change-Id: I076a167ee49582700e058c56ad74e6696710c8c8
Reviewed-on: https://go-review.googlesource.com/113315
Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This modifies issafepoint in liveness analysis to report almost every
operation as a safe point. There are four things we don't mark as
safe-points:
1. Runtime code (other than at calls).
2. go:nosplit functions (other than at calls).
3. Instructions between the load of the write barrier-enabled flag and
the write.
4. Instructions leading up to a uintptr -> unsafe.Pointer conversion.
We'll optimize this in later CLs:
name old time/op new time/op delta
Template 185ms ± 2% 190ms ± 2% +2.95% (p=0.000 n=10+10)
Unicode 96.3ms ± 3% 96.4ms ± 1% ~ (p=0.905 n=10+9)
GoTypes 658ms ± 0% 669ms ± 1% +1.72% (p=0.000 n=10+9)
Compiler 3.14s ± 1% 3.18s ± 1% +1.56% (p=0.000 n=9+10)
SSA 7.41s ± 2% 7.59s ± 1% +2.48% (p=0.000 n=9+10)
Flate 126ms ± 1% 128ms ± 1% +2.08% (p=0.000 n=10+10)
GoParser 153ms ± 1% 157ms ± 2% +2.38% (p=0.000 n=10+10)
Reflect 437ms ± 1% 442ms ± 1% +0.98% (p=0.001 n=10+10)
Tar 178ms ± 1% 179ms ± 1% +0.67% (p=0.035 n=10+9)
XML 223ms ± 1% 229ms ± 1% +2.58% (p=0.000 n=10+10)
[Geo mean] 394ms 401ms +1.75%
No effect on binary size because we're not yet emitting these extra
safe points.
For #24543.
Change-Id: I16a1eebb9183cad7cef9d53c0fd21a973cad6859
Reviewed-on: https://go-review.googlesource.com/109348
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Currently liveness only produces a stack map index at each safe point,
so the information is summarized in a map[*ssa.Value]int. We're about
to have both a stack map index and a register map index, so replace
the int with a LivenessIndex type we can extend, and replace the map
with a LivenessMap that we can also change more easily in the future.
This also gives us an easy hook for defining the value that means "not
a safe point".
Passes toolstash -cmp.
For #24543.
Change-Id: Ic4c069839635efed4fd0f603899b80f8be3b56ec
Reviewed-on: https://go-review.googlesource.com/109347
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Tim Cooper
Keith Randall
Daniel Martí
Ian Lance Taylor
Josh Bleecher Snyder
Yury Smolsky
David Symonds
Elias Naur
Alex Brainman
Than McIntosh
Tobias Klauser
Richard Musiol
Heschi Kreinick
Hana Kim
Hana (Hyang-Ah) Kim
David Chase
isharipo
Austin Clements
Martin Möhrmann