go/src/cmd/compile/internal/ssa/regalloc.go

3167 lines
94 KiB
Go
Raw Normal View History

// Copyright 2015 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
// Register allocation.
//
// We use a version of a linear scan register allocator. We treat the
// whole function as a single long basic block and run through
// it using a greedy register allocator. Then all merge edges
// (those targeting a block with len(Preds)>1) are processed to
// shuffle data into the place that the target of the edge expects.
//
// The greedy allocator moves values into registers just before they
// are used, spills registers only when necessary, and spills the
// value whose next use is farthest in the future.
//
// The register allocator requires that a block is not scheduled until
// at least one of its predecessors have been scheduled. The most recent
// such predecessor provides the starting register state for a block.
//
// It also requires that there are no critical edges (critical =
// comes from a block with >1 successor and goes to a block with >1
// predecessor). This makes it easy to add fixup code on merge edges -
// the source of a merge edge has only one successor, so we can add
// fixup code to the end of that block.
// Spilling
//
cmd/compile: put spills in better places Previously we always issued a spill right after the op that was being spilled. This CL pushes spills father away from the generator, hopefully pushing them into unlikely branches. For example: x = ... if unlikely { call ... } ... use x ... Used to compile to x = ... spill x if unlikely { call ... restore x } It now compiles to x = ... if unlikely { spill x call ... restore x } This is particularly useful for code which appends, as the only call is an unlikely call to growslice. It also helps for the spills needed around write barrier calls. The basic algorithm is walk down the dominator tree following a path where the block still dominates all of the restores. We're looking for a block that: 1) dominates all restores 2) has the value being spilled in a register 3) has a loop depth no deeper than the value being spilled The walking-down code is iterative. I was forced to limit it to searching 100 blocks so it doesn't become O(n^2). Maybe one day we'll find a better way. I had to delete most of David's code which pushed spills out of loops. I suspect this CL subsumes most of the cases that his code handled. Generally positive performance improvements, but hard to tell for sure with all the noise. (compilebench times are unchanged.) name old time/op new time/op delta BinaryTree17-12 2.91s ±15% 2.80s ±12% ~ (p=0.063 n=10+10) Fannkuch11-12 3.47s ± 0% 3.30s ± 4% -4.91% (p=0.000 n=9+10) FmtFprintfEmpty-12 48.0ns ± 1% 47.4ns ± 1% -1.32% (p=0.002 n=9+9) FmtFprintfString-12 85.6ns ±11% 79.4ns ± 3% -7.27% (p=0.005 n=10+10) FmtFprintfInt-12 91.8ns ±10% 85.9ns ± 4% ~ (p=0.203 n=10+9) FmtFprintfIntInt-12 135ns ±13% 127ns ± 1% -5.72% (p=0.025 n=10+9) FmtFprintfPrefixedInt-12 167ns ± 1% 168ns ± 2% ~ (p=0.580 n=9+10) FmtFprintfFloat-12 249ns ±11% 230ns ± 1% -7.32% (p=0.000 n=10+10) FmtManyArgs-12 504ns ± 7% 506ns ± 1% ~ (p=0.198 n=9+9) GobDecode-12 6.95ms ± 1% 7.04ms ± 1% +1.37% (p=0.001 n=10+10) GobEncode-12 6.32ms ±13% 6.04ms ± 1% ~ (p=0.063 n=10+10) Gzip-12 233ms ± 1% 235ms ± 0% +1.01% (p=0.000 n=10+9) Gunzip-12 40.1ms ± 1% 39.6ms ± 0% -1.12% (p=0.000 n=10+8) HTTPClientServer-12 227µs ± 9% 221µs ± 5% ~ (p=0.114 n=9+8) JSONEncode-12 16.1ms ± 2% 15.8ms ± 1% -2.09% (p=0.002 n=9+8) JSONDecode-12 61.8ms ±11% 57.9ms ± 1% -6.30% (p=0.000 n=10+9) Mandelbrot200-12 4.30ms ± 3% 4.28ms ± 1% ~ (p=0.203 n=10+8) GoParse-12 3.18ms ± 2% 3.18ms ± 2% ~ (p=0.579 n=10+10) RegexpMatchEasy0_32-12 76.7ns ± 1% 77.5ns ± 1% +0.92% (p=0.002 n=9+8) RegexpMatchEasy0_1K-12 239ns ± 3% 239ns ± 1% ~ (p=0.204 n=10+10) RegexpMatchEasy1_32-12 71.4ns ± 1% 70.6ns ± 0% -1.15% (p=0.000 n=10+9) RegexpMatchEasy1_1K-12 383ns ± 2% 390ns ±10% ~ (p=0.181 n=8+9) RegexpMatchMedium_32-12 114ns ± 0% 113ns ± 1% -0.88% (p=0.000 n=9+8) RegexpMatchMedium_1K-12 36.3µs ± 1% 36.8µs ± 1% +1.59% (p=0.000 n=10+8) RegexpMatchHard_32-12 1.90µs ± 1% 1.90µs ± 1% ~ (p=0.341 n=10+10) RegexpMatchHard_1K-12 59.4µs ±11% 57.8µs ± 1% ~ (p=0.968 n=10+9) Revcomp-12 461ms ± 1% 462ms ± 1% ~ (p=1.000 n=9+9) Template-12 67.5ms ± 1% 66.3ms ± 1% -1.77% (p=0.000 n=10+8) TimeParse-12 314ns ± 3% 309ns ± 0% -1.56% (p=0.000 n=9+8) TimeFormat-12 340ns ± 2% 331ns ± 1% -2.79% (p=0.000 n=10+10) The go binary is 0.2% larger. Not really sure why the size would change. Change-Id: Ia5116e53a3aeb025ef350ffc51c14ae5cc17871c Reviewed-on: https://go-review.googlesource.com/34822 Reviewed-by: David Chase <drchase@google.com>
2017-03-07 14:45:46 -05:00
// During the normal course of the allocator, we might throw a still-live
// value out of all registers. When that value is subsequently used, we must
// load it from a slot on the stack. We must also issue an instruction to
// initialize that stack location with a copy of v.
//
// pre-regalloc:
// (1) v = Op ...
// (2) x = Op ...
// (3) ... = Op v ...
//
// post-regalloc:
// (1) v = Op ... : AX // computes v, store result in AX
// s = StoreReg v // spill v to a stack slot
// (2) x = Op ... : AX // some other op uses AX
// c = LoadReg s : CX // restore v from stack slot
// (3) ... = Op c ... // use the restored value
//
// Allocation occurs normally until we reach (3) and we realize we have
// a use of v and it isn't in any register. At that point, we allocate
// a spill (a StoreReg) for v. We can't determine the correct place for
// the spill at this point, so we allocate the spill as blockless initially.
// The restore is then generated to load v back into a register so it can
// be used. Subsequent uses of v will use the restored value c instead.
//
// What remains is the question of where to schedule the spill.
// During allocation, we keep track of the dominator of all restores of v.
// The spill of v must dominate that block. The spill must also be issued at
// a point where v is still in a register.
//
// To find the right place, start at b, the block which dominates all restores.
// - If b is v.Block, then issue the spill right after v.
// It is known to be in a register at that point, and dominates any restores.
// - Otherwise, if v is in a register at the start of b,
// put the spill of v at the start of b.
// - Otherwise, set b = immediate dominator of b, and repeat.
//
// Phi values are special, as always. We define two kinds of phis, those
// where the merge happens in a register (a "register" phi) and those where
// the merge happens in a stack location (a "stack" phi).
//
// A register phi must have the phi and all of its inputs allocated to the
cmd/compile: put spills in better places Previously we always issued a spill right after the op that was being spilled. This CL pushes spills father away from the generator, hopefully pushing them into unlikely branches. For example: x = ... if unlikely { call ... } ... use x ... Used to compile to x = ... spill x if unlikely { call ... restore x } It now compiles to x = ... if unlikely { spill x call ... restore x } This is particularly useful for code which appends, as the only call is an unlikely call to growslice. It also helps for the spills needed around write barrier calls. The basic algorithm is walk down the dominator tree following a path where the block still dominates all of the restores. We're looking for a block that: 1) dominates all restores 2) has the value being spilled in a register 3) has a loop depth no deeper than the value being spilled The walking-down code is iterative. I was forced to limit it to searching 100 blocks so it doesn't become O(n^2). Maybe one day we'll find a better way. I had to delete most of David's code which pushed spills out of loops. I suspect this CL subsumes most of the cases that his code handled. Generally positive performance improvements, but hard to tell for sure with all the noise. (compilebench times are unchanged.) name old time/op new time/op delta BinaryTree17-12 2.91s ±15% 2.80s ±12% ~ (p=0.063 n=10+10) Fannkuch11-12 3.47s ± 0% 3.30s ± 4% -4.91% (p=0.000 n=9+10) FmtFprintfEmpty-12 48.0ns ± 1% 47.4ns ± 1% -1.32% (p=0.002 n=9+9) FmtFprintfString-12 85.6ns ±11% 79.4ns ± 3% -7.27% (p=0.005 n=10+10) FmtFprintfInt-12 91.8ns ±10% 85.9ns ± 4% ~ (p=0.203 n=10+9) FmtFprintfIntInt-12 135ns ±13% 127ns ± 1% -5.72% (p=0.025 n=10+9) FmtFprintfPrefixedInt-12 167ns ± 1% 168ns ± 2% ~ (p=0.580 n=9+10) FmtFprintfFloat-12 249ns ±11% 230ns ± 1% -7.32% (p=0.000 n=10+10) FmtManyArgs-12 504ns ± 7% 506ns ± 1% ~ (p=0.198 n=9+9) GobDecode-12 6.95ms ± 1% 7.04ms ± 1% +1.37% (p=0.001 n=10+10) GobEncode-12 6.32ms ±13% 6.04ms ± 1% ~ (p=0.063 n=10+10) Gzip-12 233ms ± 1% 235ms ± 0% +1.01% (p=0.000 n=10+9) Gunzip-12 40.1ms ± 1% 39.6ms ± 0% -1.12% (p=0.000 n=10+8) HTTPClientServer-12 227µs ± 9% 221µs ± 5% ~ (p=0.114 n=9+8) JSONEncode-12 16.1ms ± 2% 15.8ms ± 1% -2.09% (p=0.002 n=9+8) JSONDecode-12 61.8ms ±11% 57.9ms ± 1% -6.30% (p=0.000 n=10+9) Mandelbrot200-12 4.30ms ± 3% 4.28ms ± 1% ~ (p=0.203 n=10+8) GoParse-12 3.18ms ± 2% 3.18ms ± 2% ~ (p=0.579 n=10+10) RegexpMatchEasy0_32-12 76.7ns ± 1% 77.5ns ± 1% +0.92% (p=0.002 n=9+8) RegexpMatchEasy0_1K-12 239ns ± 3% 239ns ± 1% ~ (p=0.204 n=10+10) RegexpMatchEasy1_32-12 71.4ns ± 1% 70.6ns ± 0% -1.15% (p=0.000 n=10+9) RegexpMatchEasy1_1K-12 383ns ± 2% 390ns ±10% ~ (p=0.181 n=8+9) RegexpMatchMedium_32-12 114ns ± 0% 113ns ± 1% -0.88% (p=0.000 n=9+8) RegexpMatchMedium_1K-12 36.3µs ± 1% 36.8µs ± 1% +1.59% (p=0.000 n=10+8) RegexpMatchHard_32-12 1.90µs ± 1% 1.90µs ± 1% ~ (p=0.341 n=10+10) RegexpMatchHard_1K-12 59.4µs ±11% 57.8µs ± 1% ~ (p=0.968 n=10+9) Revcomp-12 461ms ± 1% 462ms ± 1% ~ (p=1.000 n=9+9) Template-12 67.5ms ± 1% 66.3ms ± 1% -1.77% (p=0.000 n=10+8) TimeParse-12 314ns ± 3% 309ns ± 0% -1.56% (p=0.000 n=9+8) TimeFormat-12 340ns ± 2% 331ns ± 1% -2.79% (p=0.000 n=10+10) The go binary is 0.2% larger. Not really sure why the size would change. Change-Id: Ia5116e53a3aeb025ef350ffc51c14ae5cc17871c Reviewed-on: https://go-review.googlesource.com/34822 Reviewed-by: David Chase <drchase@google.com>
2017-03-07 14:45:46 -05:00
// same register. Register phis are spilled similarly to regular ops.
//
// A stack phi must have the phi and all of its inputs allocated to the same
// stack location. Stack phis start out life already spilled - each phi
// input must be a store (using StoreReg) at the end of the corresponding
// predecessor block.
// b1: y = ... : AX b2: z = ... : BX
// y2 = StoreReg y z2 = StoreReg z
// goto b3 goto b3
// b3: x = phi(y2, z2)
// The stack allocator knows that StoreReg args of stack-allocated phis
// must be allocated to the same stack slot as the phi that uses them.
// x is now a spilled value and a restore must appear before its first use.
// TODO
// Use an affinity graph to mark two values which should use the
// same register. This affinity graph will be used to prefer certain
// registers for allocation. This affinity helps eliminate moves that
// are required for phi implementations and helps generate allocations
// for 2-register architectures.
// Note: regalloc generates a not-quite-SSA output. If we have:
//
// b1: x = ... : AX
// x2 = StoreReg x
// ... AX gets reused for something else ...
// if ... goto b3 else b4
//
// b3: x3 = LoadReg x2 : BX b4: x4 = LoadReg x2 : CX
// ... use x3 ... ... use x4 ...
//
// b2: ... use x3 ...
//
// If b3 is the primary predecessor of b2, then we use x3 in b2 and
// add a x4:CX->BX copy at the end of b4.
// But the definition of x3 doesn't dominate b2. We should really
// insert an extra phi at the start of b2 (x5=phi(x3,x4):BX) to keep
// SSA form. For now, we ignore this problem as remaining in strict
// SSA form isn't needed after regalloc. We'll just leave the use
// of x3 not dominated by the definition of x3, and the CX->BX copy
// will have no use (so don't run deadcode after regalloc!).
// TODO: maybe we should introduce these extra phis?
package ssa
import (
"cmd/compile/internal/base"
"cmd/compile/internal/ir"
cmd/compile: change ssa.Type into *types.Type When package ssa was created, Type was in package gc. To avoid circular dependencies, we used an interface (ssa.Type) to represent type information in SSA. In the Go 1.9 cycle, gri extricated the Type type from package gc. As a result, we can now use it in package ssa. Now, instead of package types depending on package ssa, it is the other way. This is a more sensible dependency tree, and helps compiler performance a bit. Though this is a big CL, most of the changes are mechanical and uninteresting. Interesting bits: * Add new singleton globals to package types for the special SSA types Memory, Void, Invalid, Flags, and Int128. * Add two new Types, TSSA for the special types, and TTUPLE, for SSA tuple types. ssa.MakeTuple is now types.NewTuple. * Move type comparison result constants CMPlt, CMPeq, and CMPgt to package types. * We had picked the name "types" in our rules for the handy list of types provided by ssa.Config. That conflicted with the types package name, so change it to "typ". * Update the type comparison routine to handle tuples and special types inline. * Teach gc/fmt.go how to print special types. * We can now eliminate ElemTypes in favor of just Elem, and probably also some other duplicated Type methods designed to return ssa.Type instead of *types.Type. * The ssa tests were using their own dummy types, and they were not particularly careful about types in general. Of necessity, this CL switches them to use *types.Type; it does not make them more type-accurate. Unfortunately, using types.Type means initializing a bit of the types universe. This is prime for refactoring and improvement. This shrinks ssa.Value; it now fits in a smaller size class on 64 bit systems. This doesn't have a giant impact, though, since most Values are preallocated in a chunk. name old alloc/op new alloc/op delta Template 37.9MB ± 0% 37.7MB ± 0% -0.57% (p=0.000 n=10+8) Unicode 28.9MB ± 0% 28.7MB ± 0% -0.52% (p=0.000 n=10+10) GoTypes 110MB ± 0% 109MB ± 0% -0.88% (p=0.000 n=10+10) Flate 24.7MB ± 0% 24.6MB ± 0% -0.66% (p=0.000 n=10+10) GoParser 31.1MB ± 0% 30.9MB ± 0% -0.61% (p=0.000 n=10+9) Reflect 73.9MB ± 0% 73.4MB ± 0% -0.62% (p=0.000 n=10+8) Tar 25.8MB ± 0% 25.6MB ± 0% -0.77% (p=0.000 n=9+10) XML 41.2MB ± 0% 40.9MB ± 0% -0.80% (p=0.000 n=10+10) [Geo mean] 40.5MB 40.3MB -0.68% name old allocs/op new allocs/op delta Template 385k ± 0% 386k ± 0% ~ (p=0.356 n=10+9) Unicode 343k ± 1% 344k ± 0% ~ (p=0.481 n=10+10) GoTypes 1.16M ± 0% 1.16M ± 0% -0.16% (p=0.004 n=10+10) Flate 238k ± 1% 238k ± 1% ~ (p=0.853 n=10+10) GoParser 320k ± 0% 320k ± 0% ~ (p=0.720 n=10+9) Reflect 957k ± 0% 957k ± 0% ~ (p=0.460 n=10+8) Tar 252k ± 0% 252k ± 0% ~ (p=0.133 n=9+10) XML 400k ± 0% 400k ± 0% ~ (p=0.796 n=10+10) [Geo mean] 428k 428k -0.01% Removing all the interface calls helps non-trivially with CPU, though. name old time/op new time/op delta Template 178ms ± 4% 173ms ± 3% -2.90% (p=0.000 n=94+96) Unicode 85.0ms ± 4% 83.9ms ± 4% -1.23% (p=0.000 n=96+96) GoTypes 543ms ± 3% 528ms ± 3% -2.73% (p=0.000 n=98+96) Flate 116ms ± 3% 113ms ± 4% -2.34% (p=0.000 n=96+99) GoParser 144ms ± 3% 140ms ± 4% -2.80% (p=0.000 n=99+97) Reflect 344ms ± 3% 334ms ± 4% -3.02% (p=0.000 n=100+99) Tar 106ms ± 5% 103ms ± 4% -3.30% (p=0.000 n=98+94) XML 198ms ± 5% 192ms ± 4% -2.88% (p=0.000 n=92+95) [Geo mean] 178ms 173ms -2.65% name old user-time/op new user-time/op delta Template 229ms ± 5% 224ms ± 5% -2.36% (p=0.000 n=95+99) Unicode 107ms ± 6% 106ms ± 5% -1.13% (p=0.001 n=93+95) GoTypes 696ms ± 4% 679ms ± 4% -2.45% (p=0.000 n=97+99) Flate 137ms ± 4% 134ms ± 5% -2.66% (p=0.000 n=99+96) GoParser 176ms ± 5% 172ms ± 8% -2.27% (p=0.000 n=98+100) Reflect 430ms ± 6% 411ms ± 5% -4.46% (p=0.000 n=100+92) Tar 128ms ±13% 123ms ±13% -4.21% (p=0.000 n=100+100) XML 239ms ± 6% 233ms ± 6% -2.50% (p=0.000 n=95+97) [Geo mean] 220ms 213ms -2.76% Change-Id: I15c7d6268347f8358e75066dfdbd77db24e8d0c1 Reviewed-on: https://go-review.googlesource.com/42145 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2017-04-28 14:12:28 -07:00
"cmd/compile/internal/types"
"cmd/internal/src"
cmd/compile: add wasm stack optimization 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>
2018-03-09 00:14:58 +01:00
"cmd/internal/sys"
"fmt"
"internal/buildcfg"
"math"
"math/bits"
"unsafe"
)
const (
moveSpills = iota
logSpills
regDebug
stackDebug
)
cmd/compile: load some live values into registers before loop If we're about to enter a loop, load values which are live and will soon be used in the loop into registers. name old time/op new time/op delta BinaryTree17-8 2.80s ± 4% 2.62s ± 2% -6.43% (p=0.008 n=5+5) Fannkuch11-8 2.45s ± 2% 2.14s ± 1% -12.43% (p=0.008 n=5+5) FmtFprintfEmpty-8 49.0ns ± 1% 48.4ns ± 1% -1.35% (p=0.032 n=5+5) FmtFprintfString-8 160ns ± 1% 153ns ± 0% -4.63% (p=0.008 n=5+5) FmtFprintfInt-8 152ns ± 0% 150ns ± 0% -1.57% (p=0.000 n=5+4) FmtFprintfIntInt-8 252ns ± 2% 244ns ± 1% -3.02% (p=0.008 n=5+5) FmtFprintfPrefixedInt-8 223ns ± 0% 223ns ± 0% ~ (all samples are equal) FmtFprintfFloat-8 293ns ± 2% 291ns ± 2% ~ (p=0.389 n=5+5) FmtManyArgs-8 956ns ± 0% 936ns ± 0% -2.05% (p=0.008 n=5+5) GobDecode-8 7.18ms ± 0% 7.11ms ± 0% -1.02% (p=0.008 n=5+5) GobEncode-8 6.12ms ± 3% 6.07ms ± 1% ~ (p=0.690 n=5+5) Gzip-8 284ms ± 1% 284ms ± 0% ~ (p=1.000 n=5+5) Gunzip-8 40.8ms ± 1% 40.6ms ± 1% ~ (p=0.310 n=5+5) HTTPClientServer-8 69.8µs ± 1% 72.2µs ± 4% ~ (p=0.056 n=5+5) JSONEncode-8 16.1ms ± 2% 16.2ms ± 1% ~ (p=0.151 n=5+5) JSONDecode-8 54.9ms ± 0% 57.0ms ± 1% +3.79% (p=0.008 n=5+5) Mandelbrot200-8 4.35ms ± 0% 4.39ms ± 0% +0.85% (p=0.008 n=5+5) GoParse-8 3.56ms ± 1% 3.42ms ± 1% -4.03% (p=0.008 n=5+5) RegexpMatchEasy0_32-8 75.6ns ± 1% 75.0ns ± 0% -0.83% (p=0.016 n=5+4) RegexpMatchEasy0_1K-8 250ns ± 0% 252ns ± 1% +0.80% (p=0.016 n=4+5) RegexpMatchEasy1_32-8 75.0ns ± 0% 75.4ns ± 2% ~ (p=0.206 n=5+5) RegexpMatchEasy1_1K-8 401ns ± 0% 398ns ± 1% ~ (p=0.056 n=5+5) RegexpMatchMedium_32-8 119ns ± 0% 118ns ± 0% -0.84% (p=0.008 n=5+5) RegexpMatchMedium_1K-8 36.6µs ± 0% 36.9µs ± 0% +0.91% (p=0.008 n=5+5) RegexpMatchHard_32-8 1.95µs ± 1% 1.92µs ± 0% -1.23% (p=0.032 n=5+5) RegexpMatchHard_1K-8 58.3µs ± 1% 58.1µs ± 1% ~ (p=0.548 n=5+5) Revcomp-8 425ms ± 1% 389ms ± 1% -8.39% (p=0.008 n=5+5) Template-8 65.5ms ± 1% 63.6ms ± 1% -2.86% (p=0.008 n=5+5) TimeParse-8 363ns ± 0% 354ns ± 1% -2.59% (p=0.008 n=5+5) TimeFormat-8 363ns ± 0% 364ns ± 1% ~ (p=0.159 n=5+5) Fixes #14511 Change-Id: I1b79d2545271fa90d5b04712cc25573bdc94f2ce Reviewed-on: https://go-review.googlesource.com/20151 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2016-03-02 15:18:40 -08:00
// distance is a measure of how far into the future values are used.
// distance is measured in units of instructions.
const (
likelyDistance = 1
normalDistance = 10
unlikelyDistance = 100
)
// regalloc performs register allocation on f. It sets f.RegAlloc
// to the resulting allocation.
func regalloc(f *Func) {
var s regAllocState
s.init(f)
s.regalloc(f)
s.close()
}
type register uint8
const noRegister register = 255
// For bulk initializing
var noRegisters [32]register = [32]register{
noRegister, noRegister, noRegister, noRegister, noRegister, noRegister, noRegister, noRegister,
noRegister, noRegister, noRegister, noRegister, noRegister, noRegister, noRegister, noRegister,
noRegister, noRegister, noRegister, noRegister, noRegister, noRegister, noRegister, noRegister,
noRegister, noRegister, noRegister, noRegister, noRegister, noRegister, noRegister, noRegister,
}
// A regMask encodes a set of machine registers.
// TODO: regMask -> regSet?
type regMask uint64
func (m regMask) String() string {
s := ""
for r := register(0); m != 0; r++ {
if m>>r&1 == 0 {
continue
}
m &^= regMask(1) << r
if s != "" {
s += " "
}
s += fmt.Sprintf("r%d", r)
}
return s
}
func (m regMask) contains(r register) bool {
return m>>r&1 != 0
}
func (s *regAllocState) RegMaskString(m regMask) string {
str := ""
for r := register(0); m != 0; r++ {
if m>>r&1 == 0 {
continue
}
m &^= regMask(1) << r
if str != "" {
str += " "
}
str += s.registers[r].String()
}
return str
}
// countRegs returns the number of set bits in the register mask.
func countRegs(r regMask) int {
return bits.OnesCount64(uint64(r))
}
// pickReg picks an arbitrary register from the register mask.
func pickReg(r regMask) register {
if r == 0 {
panic("can't pick a register from an empty set")
}
// pick the lowest one
return register(bits.TrailingZeros64(uint64(r)))
}
type use struct {
// distance from start of the block to a use of a value
// dist == 0 used by first instruction in block
// dist == len(b.Values)-1 used by last instruction in block
// dist == len(b.Values) used by block's control value
// dist > len(b.Values) used by a subsequent block
dist int32
2016-12-15 17:17:01 -08:00
pos src.XPos // source position of the use
next *use // linked list of uses of a value in nondecreasing dist order
}
cmd/compile: put spills in better places Previously we always issued a spill right after the op that was being spilled. This CL pushes spills father away from the generator, hopefully pushing them into unlikely branches. For example: x = ... if unlikely { call ... } ... use x ... Used to compile to x = ... spill x if unlikely { call ... restore x } It now compiles to x = ... if unlikely { spill x call ... restore x } This is particularly useful for code which appends, as the only call is an unlikely call to growslice. It also helps for the spills needed around write barrier calls. The basic algorithm is walk down the dominator tree following a path where the block still dominates all of the restores. We're looking for a block that: 1) dominates all restores 2) has the value being spilled in a register 3) has a loop depth no deeper than the value being spilled The walking-down code is iterative. I was forced to limit it to searching 100 blocks so it doesn't become O(n^2). Maybe one day we'll find a better way. I had to delete most of David's code which pushed spills out of loops. I suspect this CL subsumes most of the cases that his code handled. Generally positive performance improvements, but hard to tell for sure with all the noise. (compilebench times are unchanged.) name old time/op new time/op delta BinaryTree17-12 2.91s ±15% 2.80s ±12% ~ (p=0.063 n=10+10) Fannkuch11-12 3.47s ± 0% 3.30s ± 4% -4.91% (p=0.000 n=9+10) FmtFprintfEmpty-12 48.0ns ± 1% 47.4ns ± 1% -1.32% (p=0.002 n=9+9) FmtFprintfString-12 85.6ns ±11% 79.4ns ± 3% -7.27% (p=0.005 n=10+10) FmtFprintfInt-12 91.8ns ±10% 85.9ns ± 4% ~ (p=0.203 n=10+9) FmtFprintfIntInt-12 135ns ±13% 127ns ± 1% -5.72% (p=0.025 n=10+9) FmtFprintfPrefixedInt-12 167ns ± 1% 168ns ± 2% ~ (p=0.580 n=9+10) FmtFprintfFloat-12 249ns ±11% 230ns ± 1% -7.32% (p=0.000 n=10+10) FmtManyArgs-12 504ns ± 7% 506ns ± 1% ~ (p=0.198 n=9+9) GobDecode-12 6.95ms ± 1% 7.04ms ± 1% +1.37% (p=0.001 n=10+10) GobEncode-12 6.32ms ±13% 6.04ms ± 1% ~ (p=0.063 n=10+10) Gzip-12 233ms ± 1% 235ms ± 0% +1.01% (p=0.000 n=10+9) Gunzip-12 40.1ms ± 1% 39.6ms ± 0% -1.12% (p=0.000 n=10+8) HTTPClientServer-12 227µs ± 9% 221µs ± 5% ~ (p=0.114 n=9+8) JSONEncode-12 16.1ms ± 2% 15.8ms ± 1% -2.09% (p=0.002 n=9+8) JSONDecode-12 61.8ms ±11% 57.9ms ± 1% -6.30% (p=0.000 n=10+9) Mandelbrot200-12 4.30ms ± 3% 4.28ms ± 1% ~ (p=0.203 n=10+8) GoParse-12 3.18ms ± 2% 3.18ms ± 2% ~ (p=0.579 n=10+10) RegexpMatchEasy0_32-12 76.7ns ± 1% 77.5ns ± 1% +0.92% (p=0.002 n=9+8) RegexpMatchEasy0_1K-12 239ns ± 3% 239ns ± 1% ~ (p=0.204 n=10+10) RegexpMatchEasy1_32-12 71.4ns ± 1% 70.6ns ± 0% -1.15% (p=0.000 n=10+9) RegexpMatchEasy1_1K-12 383ns ± 2% 390ns ±10% ~ (p=0.181 n=8+9) RegexpMatchMedium_32-12 114ns ± 0% 113ns ± 1% -0.88% (p=0.000 n=9+8) RegexpMatchMedium_1K-12 36.3µs ± 1% 36.8µs ± 1% +1.59% (p=0.000 n=10+8) RegexpMatchHard_32-12 1.90µs ± 1% 1.90µs ± 1% ~ (p=0.341 n=10+10) RegexpMatchHard_1K-12 59.4µs ±11% 57.8µs ± 1% ~ (p=0.968 n=10+9) Revcomp-12 461ms ± 1% 462ms ± 1% ~ (p=1.000 n=9+9) Template-12 67.5ms ± 1% 66.3ms ± 1% -1.77% (p=0.000 n=10+8) TimeParse-12 314ns ± 3% 309ns ± 0% -1.56% (p=0.000 n=9+8) TimeFormat-12 340ns ± 2% 331ns ± 1% -2.79% (p=0.000 n=10+10) The go binary is 0.2% larger. Not really sure why the size would change. Change-Id: Ia5116e53a3aeb025ef350ffc51c14ae5cc17871c Reviewed-on: https://go-review.googlesource.com/34822 Reviewed-by: David Chase <drchase@google.com>
2017-03-07 14:45:46 -05:00
// A valState records the register allocation state for a (pre-regalloc) value.
type valState struct {
regs regMask // the set of registers holding a Value (usually just one)
uses *use // list of uses in this block
cmd/compile: put spills in better places Previously we always issued a spill right after the op that was being spilled. This CL pushes spills father away from the generator, hopefully pushing them into unlikely branches. For example: x = ... if unlikely { call ... } ... use x ... Used to compile to x = ... spill x if unlikely { call ... restore x } It now compiles to x = ... if unlikely { spill x call ... restore x } This is particularly useful for code which appends, as the only call is an unlikely call to growslice. It also helps for the spills needed around write barrier calls. The basic algorithm is walk down the dominator tree following a path where the block still dominates all of the restores. We're looking for a block that: 1) dominates all restores 2) has the value being spilled in a register 3) has a loop depth no deeper than the value being spilled The walking-down code is iterative. I was forced to limit it to searching 100 blocks so it doesn't become O(n^2). Maybe one day we'll find a better way. I had to delete most of David's code which pushed spills out of loops. I suspect this CL subsumes most of the cases that his code handled. Generally positive performance improvements, but hard to tell for sure with all the noise. (compilebench times are unchanged.) name old time/op new time/op delta BinaryTree17-12 2.91s ±15% 2.80s ±12% ~ (p=0.063 n=10+10) Fannkuch11-12 3.47s ± 0% 3.30s ± 4% -4.91% (p=0.000 n=9+10) FmtFprintfEmpty-12 48.0ns ± 1% 47.4ns ± 1% -1.32% (p=0.002 n=9+9) FmtFprintfString-12 85.6ns ±11% 79.4ns ± 3% -7.27% (p=0.005 n=10+10) FmtFprintfInt-12 91.8ns ±10% 85.9ns ± 4% ~ (p=0.203 n=10+9) FmtFprintfIntInt-12 135ns ±13% 127ns ± 1% -5.72% (p=0.025 n=10+9) FmtFprintfPrefixedInt-12 167ns ± 1% 168ns ± 2% ~ (p=0.580 n=9+10) FmtFprintfFloat-12 249ns ±11% 230ns ± 1% -7.32% (p=0.000 n=10+10) FmtManyArgs-12 504ns ± 7% 506ns ± 1% ~ (p=0.198 n=9+9) GobDecode-12 6.95ms ± 1% 7.04ms ± 1% +1.37% (p=0.001 n=10+10) GobEncode-12 6.32ms ±13% 6.04ms ± 1% ~ (p=0.063 n=10+10) Gzip-12 233ms ± 1% 235ms ± 0% +1.01% (p=0.000 n=10+9) Gunzip-12 40.1ms ± 1% 39.6ms ± 0% -1.12% (p=0.000 n=10+8) HTTPClientServer-12 227µs ± 9% 221µs ± 5% ~ (p=0.114 n=9+8) JSONEncode-12 16.1ms ± 2% 15.8ms ± 1% -2.09% (p=0.002 n=9+8) JSONDecode-12 61.8ms ±11% 57.9ms ± 1% -6.30% (p=0.000 n=10+9) Mandelbrot200-12 4.30ms ± 3% 4.28ms ± 1% ~ (p=0.203 n=10+8) GoParse-12 3.18ms ± 2% 3.18ms ± 2% ~ (p=0.579 n=10+10) RegexpMatchEasy0_32-12 76.7ns ± 1% 77.5ns ± 1% +0.92% (p=0.002 n=9+8) RegexpMatchEasy0_1K-12 239ns ± 3% 239ns ± 1% ~ (p=0.204 n=10+10) RegexpMatchEasy1_32-12 71.4ns ± 1% 70.6ns ± 0% -1.15% (p=0.000 n=10+9) RegexpMatchEasy1_1K-12 383ns ± 2% 390ns ±10% ~ (p=0.181 n=8+9) RegexpMatchMedium_32-12 114ns ± 0% 113ns ± 1% -0.88% (p=0.000 n=9+8) RegexpMatchMedium_1K-12 36.3µs ± 1% 36.8µs ± 1% +1.59% (p=0.000 n=10+8) RegexpMatchHard_32-12 1.90µs ± 1% 1.90µs ± 1% ~ (p=0.341 n=10+10) RegexpMatchHard_1K-12 59.4µs ±11% 57.8µs ± 1% ~ (p=0.968 n=10+9) Revcomp-12 461ms ± 1% 462ms ± 1% ~ (p=1.000 n=9+9) Template-12 67.5ms ± 1% 66.3ms ± 1% -1.77% (p=0.000 n=10+8) TimeParse-12 314ns ± 3% 309ns ± 0% -1.56% (p=0.000 n=9+8) TimeFormat-12 340ns ± 2% 331ns ± 1% -2.79% (p=0.000 n=10+10) The go binary is 0.2% larger. Not really sure why the size would change. Change-Id: Ia5116e53a3aeb025ef350ffc51c14ae5cc17871c Reviewed-on: https://go-review.googlesource.com/34822 Reviewed-by: David Chase <drchase@google.com>
2017-03-07 14:45:46 -05:00
spill *Value // spilled copy of the Value (if any)
restoreMin int32 // minimum of all restores' blocks' sdom.entry
restoreMax int32 // maximum of all restores' blocks' sdom.exit
needReg bool // cached value of !v.Type.IsMemory() && !v.Type.IsVoid() && !.v.Type.IsFlags()
rematerializeable bool // cached value of v.rematerializeable()
}
type regState struct {
v *Value // Original (preregalloc) Value stored in this register.
c *Value // A Value equal to v which is currently in a register. Might be v or a copy of it.
// If a register is unused, v==c==nil
}
type regAllocState struct {
f *Func
cmd/compile: put spills in better places Previously we always issued a spill right after the op that was being spilled. This CL pushes spills father away from the generator, hopefully pushing them into unlikely branches. For example: x = ... if unlikely { call ... } ... use x ... Used to compile to x = ... spill x if unlikely { call ... restore x } It now compiles to x = ... if unlikely { spill x call ... restore x } This is particularly useful for code which appends, as the only call is an unlikely call to growslice. It also helps for the spills needed around write barrier calls. The basic algorithm is walk down the dominator tree following a path where the block still dominates all of the restores. We're looking for a block that: 1) dominates all restores 2) has the value being spilled in a register 3) has a loop depth no deeper than the value being spilled The walking-down code is iterative. I was forced to limit it to searching 100 blocks so it doesn't become O(n^2). Maybe one day we'll find a better way. I had to delete most of David's code which pushed spills out of loops. I suspect this CL subsumes most of the cases that his code handled. Generally positive performance improvements, but hard to tell for sure with all the noise. (compilebench times are unchanged.) name old time/op new time/op delta BinaryTree17-12 2.91s ±15% 2.80s ±12% ~ (p=0.063 n=10+10) Fannkuch11-12 3.47s ± 0% 3.30s ± 4% -4.91% (p=0.000 n=9+10) FmtFprintfEmpty-12 48.0ns ± 1% 47.4ns ± 1% -1.32% (p=0.002 n=9+9) FmtFprintfString-12 85.6ns ±11% 79.4ns ± 3% -7.27% (p=0.005 n=10+10) FmtFprintfInt-12 91.8ns ±10% 85.9ns ± 4% ~ (p=0.203 n=10+9) FmtFprintfIntInt-12 135ns ±13% 127ns ± 1% -5.72% (p=0.025 n=10+9) FmtFprintfPrefixedInt-12 167ns ± 1% 168ns ± 2% ~ (p=0.580 n=9+10) FmtFprintfFloat-12 249ns ±11% 230ns ± 1% -7.32% (p=0.000 n=10+10) FmtManyArgs-12 504ns ± 7% 506ns ± 1% ~ (p=0.198 n=9+9) GobDecode-12 6.95ms ± 1% 7.04ms ± 1% +1.37% (p=0.001 n=10+10) GobEncode-12 6.32ms ±13% 6.04ms ± 1% ~ (p=0.063 n=10+10) Gzip-12 233ms ± 1% 235ms ± 0% +1.01% (p=0.000 n=10+9) Gunzip-12 40.1ms ± 1% 39.6ms ± 0% -1.12% (p=0.000 n=10+8) HTTPClientServer-12 227µs ± 9% 221µs ± 5% ~ (p=0.114 n=9+8) JSONEncode-12 16.1ms ± 2% 15.8ms ± 1% -2.09% (p=0.002 n=9+8) JSONDecode-12 61.8ms ±11% 57.9ms ± 1% -6.30% (p=0.000 n=10+9) Mandelbrot200-12 4.30ms ± 3% 4.28ms ± 1% ~ (p=0.203 n=10+8) GoParse-12 3.18ms ± 2% 3.18ms ± 2% ~ (p=0.579 n=10+10) RegexpMatchEasy0_32-12 76.7ns ± 1% 77.5ns ± 1% +0.92% (p=0.002 n=9+8) RegexpMatchEasy0_1K-12 239ns ± 3% 239ns ± 1% ~ (p=0.204 n=10+10) RegexpMatchEasy1_32-12 71.4ns ± 1% 70.6ns ± 0% -1.15% (p=0.000 n=10+9) RegexpMatchEasy1_1K-12 383ns ± 2% 390ns ±10% ~ (p=0.181 n=8+9) RegexpMatchMedium_32-12 114ns ± 0% 113ns ± 1% -0.88% (p=0.000 n=9+8) RegexpMatchMedium_1K-12 36.3µs ± 1% 36.8µs ± 1% +1.59% (p=0.000 n=10+8) RegexpMatchHard_32-12 1.90µs ± 1% 1.90µs ± 1% ~ (p=0.341 n=10+10) RegexpMatchHard_1K-12 59.4µs ±11% 57.8µs ± 1% ~ (p=0.968 n=10+9) Revcomp-12 461ms ± 1% 462ms ± 1% ~ (p=1.000 n=9+9) Template-12 67.5ms ± 1% 66.3ms ± 1% -1.77% (p=0.000 n=10+8) TimeParse-12 314ns ± 3% 309ns ± 0% -1.56% (p=0.000 n=9+8) TimeFormat-12 340ns ± 2% 331ns ± 1% -2.79% (p=0.000 n=10+10) The go binary is 0.2% larger. Not really sure why the size would change. Change-Id: Ia5116e53a3aeb025ef350ffc51c14ae5cc17871c Reviewed-on: https://go-review.googlesource.com/34822 Reviewed-by: David Chase <drchase@google.com>
2017-03-07 14:45:46 -05:00
sdom SparseTree
registers []Register
numRegs register
SPReg register
SBReg register
GReg register
ZeroIntReg register
allocatable regMask
// live values at the end of each block. live[b.ID] is a list of value IDs
// which are live at the end of b, together with a count of how many instructions
// forward to the next use.
live [][]liveInfo
// desired register assignments at the end of each block.
// Note that this is a static map computed before allocation occurs. Dynamic
// register desires (from partially completed allocations) will trump
// this information.
desired []desiredState
// current state of each (preregalloc) Value
values []valState
cmd/compile: improve startRegs calculation In register allocation, we calculate what values are used in and after the current block. If a value is used only after a function call, since registers are clobbered in call, we don't need to mark the value live at the entrance of the block. Before this CL it is considered live, and unnecessary copy or load may be generated when resolving merge edge. Fixes #14761. On AMD64: name old time/op new time/op delta BinaryTree17-12 2.84s ± 1% 2.81s ± 1% -1.06% (p=0.000 n=10+9) Fannkuch11-12 3.61s ± 0% 3.55s ± 1% -1.77% (p=0.000 n=10+9) FmtFprintfEmpty-12 50.4ns ± 4% 50.0ns ± 1% ~ (p=0.785 n=9+8) FmtFprintfString-12 80.0ns ± 3% 78.2ns ± 3% -2.35% (p=0.004 n=10+9) FmtFprintfInt-12 81.3ns ± 4% 81.8ns ± 2% ~ (p=0.159 n=10+10) FmtFprintfIntInt-12 120ns ± 4% 118ns ± 2% ~ (p=0.218 n=10+10) FmtFprintfPrefixedInt-12 152ns ± 3% 155ns ± 2% +2.11% (p=0.026 n=10+10) FmtFprintfFloat-12 240ns ± 1% 238ns ± 1% -0.79% (p=0.005 n=9+9) FmtManyArgs-12 504ns ± 1% 510ns ± 1% +1.14% (p=0.000 n=8+9) GobDecode-12 7.00ms ± 1% 6.99ms ± 0% ~ (p=0.497 n=9+10) GobEncode-12 5.47ms ± 1% 5.48ms ± 1% ~ (p=0.218 n=10+10) Gzip-12 258ms ± 2% 256ms ± 1% -0.96% (p=0.043 n=10+9) Gunzip-12 38.6ms ± 0% 38.3ms ± 0% -0.64% (p=0.000 n=9+8) HTTPClientServer-12 90.4µs ± 3% 87.2µs ±11% ~ (p=0.053 n=9+10) JSONEncode-12 15.6ms ± 0% 15.6ms ± 1% ~ (p=0.077 n=9+9) JSONDecode-12 55.1ms ± 1% 54.6ms ± 1% -0.85% (p=0.010 n=10+9) Mandelbrot200-12 4.49ms ± 0% 4.47ms ± 0% -0.25% (p=0.000 n=10+8) GoParse-12 3.38ms ± 0% 3.37ms ± 1% ~ (p=0.315 n=8+10) RegexpMatchEasy0_32-12 82.5ns ± 4% 82.0ns ± 0% ~ (p=0.164 n=10+8) RegexpMatchEasy0_1K-12 203ns ± 1% 202ns ± 1% -0.85% (p=0.000 n=9+10) RegexpMatchEasy1_32-12 82.3ns ± 1% 81.1ns ± 0% -1.39% (p=0.000 n=10+8) RegexpMatchEasy1_1K-12 357ns ± 1% 357ns ± 1% ~ (p=0.697 n=8+9) RegexpMatchMedium_32-12 125ns ± 2% 126ns ± 2% ~ (p=0.197 n=10+10) RegexpMatchMedium_1K-12 39.6µs ± 3% 39.6µs ± 1% ~ (p=0.971 n=10+10) RegexpMatchHard_32-12 1.99µs ± 2% 1.99µs ± 4% ~ (p=0.891 n=10+9) RegexpMatchHard_1K-12 60.1µs ± 3% 60.4µs ± 3% ~ (p=0.684 n=10+10) Revcomp-12 531ms ± 6% 441ms ± 0% -16.94% (p=0.000 n=10+9) Template-12 58.9ms ± 1% 58.7ms ± 1% ~ (p=0.315 n=10+10) TimeParse-12 319ns ± 1% 320ns ± 4% ~ (p=0.215 n=9+9) TimeFormat-12 345ns ± 0% 333ns ± 1% -3.36% (p=0.000 n=9+10) [Geo mean] 52.2µs 51.6µs -1.13% On ARM64: name old time/op new time/op delta BinaryTree17-8 8.53s ± 0% 8.36s ± 0% -1.89% (p=0.000 n=10+10) Fannkuch11-8 6.15s ± 0% 6.10s ± 0% -0.67% (p=0.000 n=10+10) FmtFprintfEmpty-8 117ns ± 0% 117ns ± 0% ~ (all equal) FmtFprintfString-8 192ns ± 0% 192ns ± 0% ~ (all equal) FmtFprintfInt-8 198ns ± 0% 198ns ± 0% ~ (p=0.211 n=10+10) FmtFprintfIntInt-8 289ns ± 0% 291ns ± 0% +0.59% (p=0.000 n=7+10) FmtFprintfPrefixedInt-8 320ns ± 2% 317ns ± 0% ~ (p=0.431 n=10+8) FmtFprintfFloat-8 538ns ± 0% 538ns ± 0% ~ (all equal) FmtManyArgs-8 1.17µs ± 1% 1.18µs ± 1% ~ (p=0.063 n=10+10) GobDecode-8 17.0ms ± 1% 17.2ms ± 1% +0.83% (p=0.000 n=10+10) GobEncode-8 14.2ms ± 0% 14.1ms ± 1% -0.78% (p=0.001 n=9+10) Gzip-8 806ms ± 0% 797ms ± 0% -1.12% (p=0.000 n=6+9) Gunzip-8 131ms ± 0% 130ms ± 0% -0.51% (p=0.000 n=10+9) HTTPClientServer-8 206µs ± 9% 212µs ± 2% ~ (p=0.829 n=10+8) JSONEncode-8 40.1ms ± 0% 40.1ms ± 0% ~ (p=0.136 n=9+9) JSONDecode-8 157ms ± 0% 151ms ± 0% -3.32% (p=0.000 n=9+9) Mandelbrot200-8 10.1ms ± 0% 10.1ms ± 0% -0.05% (p=0.000 n=9+8) GoParse-8 8.43ms ± 0% 8.43ms ± 0% ~ (p=0.912 n=10+10) RegexpMatchEasy0_32-8 228ns ± 1% 227ns ± 0% -0.26% (p=0.026 n=10+9) RegexpMatchEasy0_1K-8 1.92µs ± 0% 1.63µs ± 0% -15.18% (p=0.001 n=7+7) RegexpMatchEasy1_32-8 258ns ± 1% 250ns ± 0% -2.83% (p=0.000 n=10+10) RegexpMatchEasy1_1K-8 2.39µs ± 0% 2.13µs ± 0% -10.94% (p=0.000 n=9+9) RegexpMatchMedium_32-8 352ns ± 0% 351ns ± 0% -0.29% (p=0.004 n=9+10) RegexpMatchMedium_1K-8 104µs ± 0% 105µs ± 0% +0.58% (p=0.000 n=8+9) RegexpMatchHard_32-8 5.84µs ± 0% 5.82µs ± 0% -0.27% (p=0.000 n=9+10) RegexpMatchHard_1K-8 177µs ± 0% 177µs ± 0% -0.07% (p=0.000 n=9+9) Revcomp-8 1.57s ± 1% 1.50s ± 1% -4.60% (p=0.000 n=9+10) Template-8 157ms ± 1% 153ms ± 1% -2.28% (p=0.000 n=10+9) TimeParse-8 779ns ± 1% 770ns ± 1% -1.18% (p=0.013 n=10+10) TimeFormat-8 823ns ± 2% 826ns ± 1% ~ (p=0.324 n=10+9) [Geo mean] 144µs 142µs -1.45% Reduce cmd/go text size by 0.5%. Change-Id: I9288ff983c4a7cf03fc0cb35b9b1750828013117 Reviewed-on: https://go-review.googlesource.com/38457 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2017-03-22 21:34:12 -04:00
// ID of SP, SB values
sp, sb ID
// For each Value, map from its value ID back to the
// preregalloc Value it was derived from.
orig []*Value
// current state of each register.
// Includes only registers in allocatable.
regs []regState
// registers that contain values which can't be kicked out
nospill regMask
// mask of registers currently in use
used regMask
cmd/compile/internal/ssa: drop overwritten regalloc basic block input requirements For the following description, consider the following basic block graph: b1 ───┐┌──── b2 ││ ││ ▼▼ b3 For register allocator transitions between basic blocks, there are two key passes (significant paraphrasing): First, each basic block is visited in some predetermined visit order. This is the core visitOrder range loop in regAllocState.regalloc. The specific ordering heuristics aren't important here, except that the order guarantees that when visiting a basic block at least one of its predecessors has already been visited. Upon visiting a basic block, that block sets its expected starting register state (regAllocState.startRegs) based on the ending register state (regAlloc.State.endRegs) of one of its predecessors. (How it chooses which predecessor to use is not important here.) From that starting state, registers are assigned for all values in the block, ultimately resulting in some ending register state. After all blocks have been visited, the shuffle pass (regAllocState.shuffle) ensures that for each edge, endRegs of the predecessor == startRegs of the successor. That is, it makes sure that the startRegs assumptions actually hold true for each edge. It does this by adding moves to the end of the predecessor block to place values in the expected register for the successor block. These may be moves from other registers, or from memory if the value is spilled. Now on to the actual problem: Assume that b1 places some value v1 into register R10, and thus ends with endRegs containing R10 = v1. When b3 is visited, it selects b1 as its model predecessor and sets startRegs with R10 = v1. b2 does not have v1 in R10, so later in the shuffle pass, we will add a move of v1 into R10 to the end of b2 to ensure it is available for b3. This is all perfectly fine and exactly how things should work. Now suppose that b3 does not use v1. It does need to use some other value v2, which is not currently in a register. When assigning v2 to a register, it finds all registers are already in use and it needs to dump a value. Ultimately, it decides to dump v1 from R10 and replace it with v2. This is fine, but it has downstream effects on shuffle in b2. b3's startRegs still state that R10 = v1, so b2 will add a move to R10 even though b3 will unconditionally overwrite it. i.e., the move at the end of b2 is completely useless and can result in code like: // end of b2 MOV n(SP), R10 // R10 = v1 <-- useless // start of b3 MOV m(SP), R10 // R10 = v2 This is precisely what happened in #58298. This CL addresses this problem by dropping registers from startRegs if they are never used in the basic block prior to getting dumped. This allows the shuffle pass to avoid placing those useless values into the register. There is a significant limitation to this CL, which is that it only impacts the immediate predecessors of an overwriting block. We can discuss this by zooming out a bit on the previous graph: b4 ───┐┌──── b5 ││ ││ ▼▼ b1 ───┐┌──── b2 ││ ││ ▼▼ b3 Here we have the same graph, except we can see the two predecessors of b1. Now suppose that rather than b1 assigning R10 = v1 as above, the assignment is done in b4. b1 has startRegs R10 = v1, doesn't use the value at all, and simply passes it through to endRegs R10 = v1. Now the shuffle pass will require both b2 and b5 to add a move to assigned R10 = v1, because that is specified in their successor startRegs. With this CL, b3 drops R10 = v1 from startRegs, but there is no backwards propagation, so b1 still has R10 = v1 in startRegs, and b5 still needs to add a useless move. Extending this CL with such propagation may significantly increase the number of useless moves we can remove, though it will add complexity to maintenance and could potentially impact build performance depending on how efficiently we could implement the propagation (something I haven't considered carefully). As-is, this optimization does not impact much code. In bent .text size geomean is -0.02%. In the container/heap test binary, 18 of ~2500 functions are impacted by this CL. Bent and sweet do not show a noticeable performance impact one way or another, however #58298 does show a case where this can have impact if the useless instructions end up in the hot path of a tight loop. For #58298. Change-Id: I2fcef37c955159d068fa0725f995a1848add8a5f Reviewed-on: https://go-review.googlesource.com/c/go/+/471158 Run-TryBot: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: David Chase <drchase@google.com>
2023-02-21 13:20:49 -05:00
// mask of registers used since the start of the current block
usedSinceBlockStart regMask
cmd/compile: move value around before kick it out of register When allocating registers, before kicking out the existing value, copy it to a spare register if there is one. So later use of this value can be found in register instead of reload from spill. This is very helpful for instructions of which the input and/or output can only be in specific registers, e.g. DIV on x86, MUL/DIV on MIPS. May also be helpful in general. For "go build -a cmd/go" on AMD64, reduce "spilled value remains" by 1% (not including args, which almost certainly remain). For the code in issue #16061 on AMD64: MaxRem-12 111µs ± 1% 94µs ± 0% -15.38% (p=0.008 n=5+5) Go1 benchmark on AMD64: BinaryTree17-12 2.32s ± 2% 2.30s ± 1% ~ (p=0.421 n=5+5) Fannkuch11-12 2.52s ± 0% 2.44s ± 0% -3.44% (p=0.008 n=5+5) FmtFprintfEmpty-12 39.9ns ± 3% 39.8ns ± 0% ~ (p=0.635 n=5+4) FmtFprintfString-12 114ns ± 1% 113ns ± 1% ~ (p=0.905 n=5+5) FmtFprintfInt-12 102ns ± 6% 98ns ± 1% ~ (p=0.087 n=5+5) FmtFprintfIntInt-12 146ns ± 5% 147ns ± 1% ~ (p=0.238 n=5+5) FmtFprintfPrefixedInt-12 155ns ± 2% 151ns ± 1% -2.58% (p=0.008 n=5+5) FmtFprintfFloat-12 231ns ± 1% 232ns ± 1% ~ (p=0.286 n=5+5) FmtManyArgs-12 657ns ± 1% 649ns ± 0% -1.31% (p=0.008 n=5+5) GobDecode-12 6.35ms ± 0% 6.29ms ± 1% ~ (p=0.056 n=5+5) GobEncode-12 5.38ms ± 1% 5.45ms ± 1% ~ (p=0.056 n=5+5) Gzip-12 209ms ± 0% 209ms ± 1% ~ (p=0.690 n=5+5) Gunzip-12 31.2ms ± 1% 31.1ms ± 1% ~ (p=0.548 n=5+5) HTTPClientServer-12 123µs ± 4% 130µs ± 8% ~ (p=0.151 n=5+5) JSONEncode-12 14.0ms ± 1% 14.0ms ± 1% ~ (p=0.421 n=5+5) JSONDecode-12 41.2ms ± 1% 41.1ms ± 2% ~ (p=0.421 n=5+5) Mandelbrot200-12 3.96ms ± 1% 3.98ms ± 0% ~ (p=0.421 n=5+5) GoParse-12 2.88ms ± 1% 2.88ms ± 1% ~ (p=0.841 n=5+5) RegexpMatchEasy0_32-12 68.0ns ± 3% 66.6ns ± 1% -2.00% (p=0.024 n=5+5) RegexpMatchEasy0_1K-12 728ns ± 8% 682ns ± 1% -6.26% (p=0.008 n=5+5) RegexpMatchEasy1_32-12 66.8ns ± 2% 66.0ns ± 1% ~ (p=0.302 n=5+5) RegexpMatchEasy1_1K-12 291ns ± 2% 288ns ± 1% ~ (p=0.111 n=5+5) RegexpMatchMedium_32-12 103ns ± 2% 100ns ± 0% -2.53% (p=0.016 n=5+4) RegexpMatchMedium_1K-12 31.9µs ± 1% 31.3µs ± 0% -1.75% (p=0.008 n=5+5) RegexpMatchHard_32-12 1.59µs ± 2% 1.59µs ± 1% ~ (p=0.548 n=5+5) RegexpMatchHard_1K-12 48.3µs ± 2% 47.7µs ± 1% ~ (p=0.222 n=5+5) Revcomp-12 340ms ± 1% 338ms ± 1% ~ (p=0.421 n=5+5) Template-12 46.3ms ± 1% 46.5ms ± 1% ~ (p=0.690 n=5+5) TimeParse-12 252ns ± 1% 247ns ± 0% -1.91% (p=0.000 n=5+4) TimeFormat-12 277ns ± 1% 267ns ± 0% -3.82% (p=0.008 n=5+5) [Geo mean] 48.8µs 48.3µs -0.93% It has very little effect on binary size and compiler speed. compilebench: Template 230ms ±10% 231ms ± 8% ~ (p=0.546 n=9+9) Unicode 123ms ± 6% 124ms ± 9% ~ (p=0.481 n=10+10) GoTypes 742ms ± 6% 755ms ± 3% ~ (p=0.123 n=10+10) Compiler 3.10s ± 3% 3.08s ± 1% ~ (p=0.631 n=10+10) Fixes #16061. Change-Id: Id99cdc7a182ee10a704fa0f04e8e0d0809b2ac56 Reviewed-on: https://go-review.googlesource.com/29732 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2016-09-23 09:15:51 -04:00
// mask of registers used in the current instruction
tmpused regMask
// current block we're working on
curBlock *Block
// cache of use records
freeUseRecords *use
// endRegs[blockid] is the register state at the end of each block.
// encoded as a set of endReg records.
endRegs [][]endReg
// startRegs[blockid] is the register state at the start of merge blocks.
// saved state does not include the state of phi ops in the block.
startRegs [][]startReg
cmd/compile/internal/ssa: drop overwritten regalloc basic block input requirements For the following description, consider the following basic block graph: b1 ───┐┌──── b2 ││ ││ ▼▼ b3 For register allocator transitions between basic blocks, there are two key passes (significant paraphrasing): First, each basic block is visited in some predetermined visit order. This is the core visitOrder range loop in regAllocState.regalloc. The specific ordering heuristics aren't important here, except that the order guarantees that when visiting a basic block at least one of its predecessors has already been visited. Upon visiting a basic block, that block sets its expected starting register state (regAllocState.startRegs) based on the ending register state (regAlloc.State.endRegs) of one of its predecessors. (How it chooses which predecessor to use is not important here.) From that starting state, registers are assigned for all values in the block, ultimately resulting in some ending register state. After all blocks have been visited, the shuffle pass (regAllocState.shuffle) ensures that for each edge, endRegs of the predecessor == startRegs of the successor. That is, it makes sure that the startRegs assumptions actually hold true for each edge. It does this by adding moves to the end of the predecessor block to place values in the expected register for the successor block. These may be moves from other registers, or from memory if the value is spilled. Now on to the actual problem: Assume that b1 places some value v1 into register R10, and thus ends with endRegs containing R10 = v1. When b3 is visited, it selects b1 as its model predecessor and sets startRegs with R10 = v1. b2 does not have v1 in R10, so later in the shuffle pass, we will add a move of v1 into R10 to the end of b2 to ensure it is available for b3. This is all perfectly fine and exactly how things should work. Now suppose that b3 does not use v1. It does need to use some other value v2, which is not currently in a register. When assigning v2 to a register, it finds all registers are already in use and it needs to dump a value. Ultimately, it decides to dump v1 from R10 and replace it with v2. This is fine, but it has downstream effects on shuffle in b2. b3's startRegs still state that R10 = v1, so b2 will add a move to R10 even though b3 will unconditionally overwrite it. i.e., the move at the end of b2 is completely useless and can result in code like: // end of b2 MOV n(SP), R10 // R10 = v1 <-- useless // start of b3 MOV m(SP), R10 // R10 = v2 This is precisely what happened in #58298. This CL addresses this problem by dropping registers from startRegs if they are never used in the basic block prior to getting dumped. This allows the shuffle pass to avoid placing those useless values into the register. There is a significant limitation to this CL, which is that it only impacts the immediate predecessors of an overwriting block. We can discuss this by zooming out a bit on the previous graph: b4 ───┐┌──── b5 ││ ││ ▼▼ b1 ───┐┌──── b2 ││ ││ ▼▼ b3 Here we have the same graph, except we can see the two predecessors of b1. Now suppose that rather than b1 assigning R10 = v1 as above, the assignment is done in b4. b1 has startRegs R10 = v1, doesn't use the value at all, and simply passes it through to endRegs R10 = v1. Now the shuffle pass will require both b2 and b5 to add a move to assigned R10 = v1, because that is specified in their successor startRegs. With this CL, b3 drops R10 = v1 from startRegs, but there is no backwards propagation, so b1 still has R10 = v1 in startRegs, and b5 still needs to add a useless move. Extending this CL with such propagation may significantly increase the number of useless moves we can remove, though it will add complexity to maintenance and could potentially impact build performance depending on how efficiently we could implement the propagation (something I haven't considered carefully). As-is, this optimization does not impact much code. In bent .text size geomean is -0.02%. In the container/heap test binary, 18 of ~2500 functions are impacted by this CL. Bent and sweet do not show a noticeable performance impact one way or another, however #58298 does show a case where this can have impact if the useless instructions end up in the hot path of a tight loop. For #58298. Change-Id: I2fcef37c955159d068fa0725f995a1848add8a5f Reviewed-on: https://go-review.googlesource.com/c/go/+/471158 Run-TryBot: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: David Chase <drchase@google.com>
2023-02-21 13:20:49 -05:00
// startRegsMask is a mask of the registers in startRegs[curBlock.ID].
// Registers dropped from startRegsMask are later synchronoized back to
// startRegs by dropping from there as well.
startRegsMask regMask
// spillLive[blockid] is the set of live spills at the end of each block
spillLive [][]ID
cmd/compile: move value around before kick it out of register When allocating registers, before kicking out the existing value, copy it to a spare register if there is one. So later use of this value can be found in register instead of reload from spill. This is very helpful for instructions of which the input and/or output can only be in specific registers, e.g. DIV on x86, MUL/DIV on MIPS. May also be helpful in general. For "go build -a cmd/go" on AMD64, reduce "spilled value remains" by 1% (not including args, which almost certainly remain). For the code in issue #16061 on AMD64: MaxRem-12 111µs ± 1% 94µs ± 0% -15.38% (p=0.008 n=5+5) Go1 benchmark on AMD64: BinaryTree17-12 2.32s ± 2% 2.30s ± 1% ~ (p=0.421 n=5+5) Fannkuch11-12 2.52s ± 0% 2.44s ± 0% -3.44% (p=0.008 n=5+5) FmtFprintfEmpty-12 39.9ns ± 3% 39.8ns ± 0% ~ (p=0.635 n=5+4) FmtFprintfString-12 114ns ± 1% 113ns ± 1% ~ (p=0.905 n=5+5) FmtFprintfInt-12 102ns ± 6% 98ns ± 1% ~ (p=0.087 n=5+5) FmtFprintfIntInt-12 146ns ± 5% 147ns ± 1% ~ (p=0.238 n=5+5) FmtFprintfPrefixedInt-12 155ns ± 2% 151ns ± 1% -2.58% (p=0.008 n=5+5) FmtFprintfFloat-12 231ns ± 1% 232ns ± 1% ~ (p=0.286 n=5+5) FmtManyArgs-12 657ns ± 1% 649ns ± 0% -1.31% (p=0.008 n=5+5) GobDecode-12 6.35ms ± 0% 6.29ms ± 1% ~ (p=0.056 n=5+5) GobEncode-12 5.38ms ± 1% 5.45ms ± 1% ~ (p=0.056 n=5+5) Gzip-12 209ms ± 0% 209ms ± 1% ~ (p=0.690 n=5+5) Gunzip-12 31.2ms ± 1% 31.1ms ± 1% ~ (p=0.548 n=5+5) HTTPClientServer-12 123µs ± 4% 130µs ± 8% ~ (p=0.151 n=5+5) JSONEncode-12 14.0ms ± 1% 14.0ms ± 1% ~ (p=0.421 n=5+5) JSONDecode-12 41.2ms ± 1% 41.1ms ± 2% ~ (p=0.421 n=5+5) Mandelbrot200-12 3.96ms ± 1% 3.98ms ± 0% ~ (p=0.421 n=5+5) GoParse-12 2.88ms ± 1% 2.88ms ± 1% ~ (p=0.841 n=5+5) RegexpMatchEasy0_32-12 68.0ns ± 3% 66.6ns ± 1% -2.00% (p=0.024 n=5+5) RegexpMatchEasy0_1K-12 728ns ± 8% 682ns ± 1% -6.26% (p=0.008 n=5+5) RegexpMatchEasy1_32-12 66.8ns ± 2% 66.0ns ± 1% ~ (p=0.302 n=5+5) RegexpMatchEasy1_1K-12 291ns ± 2% 288ns ± 1% ~ (p=0.111 n=5+5) RegexpMatchMedium_32-12 103ns ± 2% 100ns ± 0% -2.53% (p=0.016 n=5+4) RegexpMatchMedium_1K-12 31.9µs ± 1% 31.3µs ± 0% -1.75% (p=0.008 n=5+5) RegexpMatchHard_32-12 1.59µs ± 2% 1.59µs ± 1% ~ (p=0.548 n=5+5) RegexpMatchHard_1K-12 48.3µs ± 2% 47.7µs ± 1% ~ (p=0.222 n=5+5) Revcomp-12 340ms ± 1% 338ms ± 1% ~ (p=0.421 n=5+5) Template-12 46.3ms ± 1% 46.5ms ± 1% ~ (p=0.690 n=5+5) TimeParse-12 252ns ± 1% 247ns ± 0% -1.91% (p=0.000 n=5+4) TimeFormat-12 277ns ± 1% 267ns ± 0% -3.82% (p=0.008 n=5+5) [Geo mean] 48.8µs 48.3µs -0.93% It has very little effect on binary size and compiler speed. compilebench: Template 230ms ±10% 231ms ± 8% ~ (p=0.546 n=9+9) Unicode 123ms ± 6% 124ms ± 9% ~ (p=0.481 n=10+10) GoTypes 742ms ± 6% 755ms ± 3% ~ (p=0.123 n=10+10) Compiler 3.10s ± 3% 3.08s ± 1% ~ (p=0.631 n=10+10) Fixes #16061. Change-Id: Id99cdc7a182ee10a704fa0f04e8e0d0809b2ac56 Reviewed-on: https://go-review.googlesource.com/29732 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2016-09-23 09:15:51 -04:00
// a set of copies we generated to move things around, and
// whether it is used in shuffle. Unused copies will be deleted.
copies map[*Value]bool
loopnest *loopnest
// choose a good order in which to visit blocks for allocation purposes.
visitOrder []*Block
cmd/compile: use depth first topological sort algorithm for layout The current layout algorithm tries to put consecutive blocks together, so the priority of the successor block is higher than the priority of the zero indegree block. This algorithm is beneficial for subsequent register allocation, but will result in more branch instructions. The depth-first topological sorting algorithm is a well-known layout algorithm, which has applications in many languages, and it helps to reduce branch instructions. This CL applies it to the layout pass. The test results show that it helps to reduce the code size. This CL also includes the following changes: 1, Removed the primary predecessor mechanism. The new layout algorithm is not very friendly to register allocator in some cases, in order to adapt to the new layout algorithm, a new primary predecessor selection strategy is introduced. 2, Since the new layout implementation may place non-loop blocks between loop blocks, some adaptive modifications have also been made to looprotate pass. 3, The layout also affects the results of codegen, so this CL also adjusted several codegen tests accordingly. It is inevitable that this CL will cause the code size or performance of a few functions to decrease, but the number of cases it improves is much larger than the number of cases it drops. Statistical data from compilecmp on linux/amd64 is as follow: name old time/op new time/op delta Template 382ms ± 4% 382ms ± 4% ~ (p=0.497 n=49+50) Unicode 170ms ± 9% 169ms ± 8% ~ (p=0.344 n=48+50) GoTypes 2.01s ± 4% 2.01s ± 4% ~ (p=0.628 n=50+48) Compiler 190ms ±10% 189ms ± 9% ~ (p=0.734 n=50+50) SSA 11.8s ± 2% 11.8s ± 3% ~ (p=0.877 n=50+50) Flate 241ms ± 9% 241ms ± 8% ~ (p=0.897 n=50+49) GoParser 366ms ± 3% 361ms ± 4% -1.21% (p=0.004 n=47+50) Reflect 835ms ± 3% 838ms ± 3% ~ (p=0.275 n=50+49) Tar 336ms ± 4% 335ms ± 3% ~ (p=0.454 n=48+48) XML 433ms ± 4% 431ms ± 3% ~ (p=0.071 n=49+48) LinkCompiler 706ms ± 4% 705ms ± 4% ~ (p=0.608 n=50+49) ExternalLinkCompiler 1.85s ± 3% 1.83s ± 2% -1.47% (p=0.000 n=49+48) LinkWithoutDebugCompiler 437ms ± 5% 437ms ± 6% ~ (p=0.953 n=49+50) [Geo mean] 615ms 613ms -0.37% name old alloc/op new alloc/op delta Template 38.7MB ± 1% 38.7MB ± 1% ~ (p=0.834 n=50+50) Unicode 28.1MB ± 0% 28.1MB ± 0% -0.22% (p=0.000 n=49+50) GoTypes 168MB ± 1% 168MB ± 1% ~ (p=0.054 n=47+47) Compiler 23.0MB ± 1% 23.0MB ± 1% ~ (p=0.432 n=50+50) SSA 1.54GB ± 0% 1.54GB ± 0% +0.21% (p=0.000 n=50+50) Flate 23.6MB ± 1% 23.6MB ± 1% ~ (p=0.153 n=43+46) GoParser 35.1MB ± 1% 35.1MB ± 2% ~ (p=0.202 n=50+50) Reflect 84.7MB ± 1% 84.7MB ± 1% ~ (p=0.333 n=48+49) Tar 34.5MB ± 1% 34.5MB ± 1% ~ (p=0.406 n=46+49) XML 44.3MB ± 2% 44.2MB ± 3% ~ (p=0.981 n=50+50) LinkCompiler 131MB ± 0% 128MB ± 0% -2.74% (p=0.000 n=50+50) ExternalLinkCompiler 120MB ± 0% 120MB ± 0% +0.01% (p=0.007 n=50+50) LinkWithoutDebugCompiler 77.3MB ± 0% 77.3MB ± 0% -0.02% (p=0.000 n=50+50) [Geo mean] 69.3MB 69.1MB -0.22% file before after Δ % addr2line 4104220 4043684 -60536 -1.475% api 5342502 5249678 -92824 -1.737% asm 4973785 4858257 -115528 -2.323% buildid 2667844 2625660 -42184 -1.581% cgo 4686849 4616313 -70536 -1.505% compile 23667431 23268406 -399025 -1.686% cover 4959676 4874108 -85568 -1.725% dist 3515934 3450422 -65512 -1.863% doc 3995581 3925469 -70112 -1.755% fix 3379202 3318522 -60680 -1.796% link 6743249 6629913 -113336 -1.681% nm 4047529 3991777 -55752 -1.377% objdump 4456151 4388151 -68000 -1.526% pack 2435040 2398072 -36968 -1.518% pprof 13804080 13565808 -238272 -1.726% test2json 2690043 2645987 -44056 -1.638% trace 10418492 10232716 -185776 -1.783% vet 7258259 7121259 -137000 -1.888% total 113145867 111204202 -1941665 -1.716% The situation on linux/arm64 is as follow: name old time/op new time/op delta Template 280ms ± 1% 282ms ± 1% +0.75% (p=0.000 n=46+48) Unicode 124ms ± 2% 124ms ± 2% +0.37% (p=0.045 n=50+50) GoTypes 1.69s ± 1% 1.70s ± 1% +0.56% (p=0.000 n=49+50) Compiler 122ms ± 1% 123ms ± 1% +0.93% (p=0.000 n=50+50) SSA 12.6s ± 1% 12.7s ± 0% +0.72% (p=0.000 n=50+50) Flate 170ms ± 1% 172ms ± 1% +0.97% (p=0.000 n=49+49) GoParser 262ms ± 1% 263ms ± 1% +0.39% (p=0.000 n=49+48) Reflect 639ms ± 1% 650ms ± 1% +1.63% (p=0.000 n=49+49) Tar 243ms ± 1% 245ms ± 1% +0.82% (p=0.000 n=50+50) XML 324ms ± 1% 327ms ± 1% +0.72% (p=0.000 n=50+49) LinkCompiler 597ms ± 1% 596ms ± 1% -0.27% (p=0.001 n=48+47) ExternalLinkCompiler 1.90s ± 1% 1.88s ± 1% -1.00% (p=0.000 n=50+50) LinkWithoutDebugCompiler 364ms ± 1% 363ms ± 1% ~ (p=0.220 n=49+50) [Geo mean] 485ms 488ms +0.49% name old alloc/op new alloc/op delta Template 38.7MB ± 0% 38.8MB ± 1% ~ (p=0.093 n=43+49) Unicode 28.4MB ± 0% 28.4MB ± 0% +0.03% (p=0.000 n=49+45) GoTypes 169MB ± 1% 169MB ± 1% +0.23% (p=0.010 n=50+50) Compiler 23.2MB ± 1% 23.2MB ± 1% +0.11% (p=0.000 n=40+44) SSA 1.54GB ± 0% 1.55GB ± 0% +0.45% (p=0.000 n=47+49) Flate 23.8MB ± 2% 23.8MB ± 1% ~ (p=0.543 n=50+50) GoParser 35.3MB ± 1% 35.4MB ± 1% ~ (p=0.792 n=50+50) Reflect 85.2MB ± 1% 85.2MB ± 0% ~ (p=0.055 n=50+47) Tar 34.5MB ± 1% 34.5MB ± 1% +0.06% (p=0.015 n=50+50) XML 43.8MB ± 2% 43.9MB ± 2% +0.19% (p=0.000 n=48+48) LinkCompiler 137MB ± 0% 136MB ± 0% -0.92% (p=0.000 n=50+50) ExternalLinkCompiler 127MB ± 0% 127MB ± 0% ~ (p=0.516 n=50+50) LinkWithoutDebugCompiler 84.0MB ± 0% 84.0MB ± 0% ~ (p=0.057 n=50+50) [Geo mean] 70.4MB 70.4MB +0.01% file before after Δ % addr2line 4021557 4002933 -18624 -0.463% api 5127847 5028503 -99344 -1.937% asm 5034716 4936836 -97880 -1.944% buildid 2608118 2594094 -14024 -0.538% cgo 4488592 4398320 -90272 -2.011% compile 22501129 22213592 -287537 -1.278% cover 4742301 4713573 -28728 -0.606% dist 3388071 3365311 -22760 -0.672% doc 3802250 3776082 -26168 -0.688% fix 3306147 3216939 -89208 -2.698% link 6404483 6363699 -40784 -0.637% nm 3941026 3921930 -19096 -0.485% objdump 4383330 4295122 -88208 -2.012% pack 2404547 2389515 -15032 -0.625% pprof 12996234 12856818 -139416 -1.073% test2json 2668500 2586788 -81712 -3.062% trace 9816276 9609580 -206696 -2.106% vet 6900682 6787338 -113344 -1.643% total 108535806 107056973 -1478833 -1.363% Change-Id: Iaec1cdcaacca8025e9babb0fb8a532fddb70c87d Reviewed-on: https://go-review.googlesource.com/c/go/+/255239 Reviewed-by: eric fang <eric.fang@arm.com> Reviewed-by: Keith Randall <khr@golang.org> Trust: eric fang <eric.fang@arm.com>
2020-07-23 10:24:56 +08:00
// blockOrder[b.ID] corresponds to the index of block b in visitOrder.
blockOrder []int32
// whether to insert instructions that clobber dead registers at call sites
doClobber bool
// For each instruction index in a basic block, the index of the next call
// at or after that instruction index.
// If there is no next call, returns maxInt32.
// nextCall for a call instruction points to itself.
// (Indexes and results are pre-regalloc.)
nextCall []int32
// Index of the instruction we're currently working on.
// Index is expressed in terms of the pre-regalloc b.Values list.
curIdx int
}
type endReg struct {
r register
v *Value // pre-regalloc value held in this register (TODO: can we use ID here?)
c *Value // cached version of the value
}
type startReg struct {
r register
cmd/compile: put spills in better places Previously we always issued a spill right after the op that was being spilled. This CL pushes spills father away from the generator, hopefully pushing them into unlikely branches. For example: x = ... if unlikely { call ... } ... use x ... Used to compile to x = ... spill x if unlikely { call ... restore x } It now compiles to x = ... if unlikely { spill x call ... restore x } This is particularly useful for code which appends, as the only call is an unlikely call to growslice. It also helps for the spills needed around write barrier calls. The basic algorithm is walk down the dominator tree following a path where the block still dominates all of the restores. We're looking for a block that: 1) dominates all restores 2) has the value being spilled in a register 3) has a loop depth no deeper than the value being spilled The walking-down code is iterative. I was forced to limit it to searching 100 blocks so it doesn't become O(n^2). Maybe one day we'll find a better way. I had to delete most of David's code which pushed spills out of loops. I suspect this CL subsumes most of the cases that his code handled. Generally positive performance improvements, but hard to tell for sure with all the noise. (compilebench times are unchanged.) name old time/op new time/op delta BinaryTree17-12 2.91s ±15% 2.80s ±12% ~ (p=0.063 n=10+10) Fannkuch11-12 3.47s ± 0% 3.30s ± 4% -4.91% (p=0.000 n=9+10) FmtFprintfEmpty-12 48.0ns ± 1% 47.4ns ± 1% -1.32% (p=0.002 n=9+9) FmtFprintfString-12 85.6ns ±11% 79.4ns ± 3% -7.27% (p=0.005 n=10+10) FmtFprintfInt-12 91.8ns ±10% 85.9ns ± 4% ~ (p=0.203 n=10+9) FmtFprintfIntInt-12 135ns ±13% 127ns ± 1% -5.72% (p=0.025 n=10+9) FmtFprintfPrefixedInt-12 167ns ± 1% 168ns ± 2% ~ (p=0.580 n=9+10) FmtFprintfFloat-12 249ns ±11% 230ns ± 1% -7.32% (p=0.000 n=10+10) FmtManyArgs-12 504ns ± 7% 506ns ± 1% ~ (p=0.198 n=9+9) GobDecode-12 6.95ms ± 1% 7.04ms ± 1% +1.37% (p=0.001 n=10+10) GobEncode-12 6.32ms ±13% 6.04ms ± 1% ~ (p=0.063 n=10+10) Gzip-12 233ms ± 1% 235ms ± 0% +1.01% (p=0.000 n=10+9) Gunzip-12 40.1ms ± 1% 39.6ms ± 0% -1.12% (p=0.000 n=10+8) HTTPClientServer-12 227µs ± 9% 221µs ± 5% ~ (p=0.114 n=9+8) JSONEncode-12 16.1ms ± 2% 15.8ms ± 1% -2.09% (p=0.002 n=9+8) JSONDecode-12 61.8ms ±11% 57.9ms ± 1% -6.30% (p=0.000 n=10+9) Mandelbrot200-12 4.30ms ± 3% 4.28ms ± 1% ~ (p=0.203 n=10+8) GoParse-12 3.18ms ± 2% 3.18ms ± 2% ~ (p=0.579 n=10+10) RegexpMatchEasy0_32-12 76.7ns ± 1% 77.5ns ± 1% +0.92% (p=0.002 n=9+8) RegexpMatchEasy0_1K-12 239ns ± 3% 239ns ± 1% ~ (p=0.204 n=10+10) RegexpMatchEasy1_32-12 71.4ns ± 1% 70.6ns ± 0% -1.15% (p=0.000 n=10+9) RegexpMatchEasy1_1K-12 383ns ± 2% 390ns ±10% ~ (p=0.181 n=8+9) RegexpMatchMedium_32-12 114ns ± 0% 113ns ± 1% -0.88% (p=0.000 n=9+8) RegexpMatchMedium_1K-12 36.3µs ± 1% 36.8µs ± 1% +1.59% (p=0.000 n=10+8) RegexpMatchHard_32-12 1.90µs ± 1% 1.90µs ± 1% ~ (p=0.341 n=10+10) RegexpMatchHard_1K-12 59.4µs ±11% 57.8µs ± 1% ~ (p=0.968 n=10+9) Revcomp-12 461ms ± 1% 462ms ± 1% ~ (p=1.000 n=9+9) Template-12 67.5ms ± 1% 66.3ms ± 1% -1.77% (p=0.000 n=10+8) TimeParse-12 314ns ± 3% 309ns ± 0% -1.56% (p=0.000 n=9+8) TimeFormat-12 340ns ± 2% 331ns ± 1% -2.79% (p=0.000 n=10+10) The go binary is 0.2% larger. Not really sure why the size would change. Change-Id: Ia5116e53a3aeb025ef350ffc51c14ae5cc17871c Reviewed-on: https://go-review.googlesource.com/34822 Reviewed-by: David Chase <drchase@google.com>
2017-03-07 14:45:46 -05:00
v *Value // pre-regalloc value needed in this register
c *Value // cached version of the value
2016-12-15 17:17:01 -08:00
pos src.XPos // source position of use of this register
}
// freeReg frees up register r. Any current user of r is kicked out.
func (s *regAllocState) freeReg(r register) {
if !s.allocatable.contains(r) && !s.isGReg(r) {
return
}
v := s.regs[r].v
if v == nil {
s.f.Fatalf("tried to free an already free register %d\n", r)
}
// Mark r as unused.
if s.f.pass.debug > regDebug {
fmt.Printf("freeReg %s (dump %s/%s)\n", &s.registers[r], v, s.regs[r].c)
}
s.regs[r] = regState{}
s.values[v.ID].regs &^= regMask(1) << r
s.used &^= regMask(1) << r
}
// freeRegs frees up all registers listed in m.
func (s *regAllocState) freeRegs(m regMask) {
for m&s.used != 0 {
s.freeReg(pickReg(m & s.used))
}
}
// clobberRegs inserts instructions that clobber registers listed in m.
func (s *regAllocState) clobberRegs(m regMask) {
m &= s.allocatable & s.f.Config.gpRegMask // only integer register can contain pointers, only clobber them
for m != 0 {
r := pickReg(m)
m &^= 1 << r
x := s.curBlock.NewValue0(src.NoXPos, OpClobberReg, types.TypeVoid)
s.f.setHome(x, &s.registers[r])
}
}
// setOrig records that c's original value is the same as
// v's original value.
func (s *regAllocState) setOrig(c *Value, v *Value) {
if int(c.ID) >= cap(s.orig) {
x := s.f.Cache.allocValueSlice(int(c.ID) + 1)
copy(x, s.orig)
s.f.Cache.freeValueSlice(s.orig)
s.orig = x
}
for int(c.ID) >= len(s.orig) {
s.orig = append(s.orig, nil)
}
if s.orig[c.ID] != nil {
s.f.Fatalf("orig value set twice %s %s", c, v)
}
s.orig[c.ID] = s.orig[v.ID]
}
// assignReg assigns register r to hold c, a copy of v.
// r must be unused.
func (s *regAllocState) assignReg(r register, v *Value, c *Value) {
if s.f.pass.debug > regDebug {
fmt.Printf("assignReg %s %s/%s\n", &s.registers[r], v, c)
}
// Allocate v to r.
s.values[v.ID].regs |= regMask(1) << r
s.f.setHome(c, &s.registers[r])
// Allocate r to v.
if !s.allocatable.contains(r) && !s.isGReg(r) {
return
}
if s.regs[r].v != nil {
s.f.Fatalf("tried to assign register %d to %s/%s but it is already used by %s", r, v, c, s.regs[r].v)
}
s.regs[r] = regState{v, c}
s.used |= regMask(1) << r
}
// allocReg chooses a register from the set of registers in mask.
// If there is no unused register, a Value will be kicked out of
// a register to make room.
func (s *regAllocState) allocReg(mask regMask, v *Value) register {
cmd/compile: add wasm stack optimization 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>
2018-03-09 00:14:58 +01:00
if v.OnWasmStack {
return noRegister
}
mask &= s.allocatable
mask &^= s.nospill
if mask == 0 {
cmd/compile,test: combine byte loads and stores on ppc64le CL 74410 added rules to combine consecutive byte loads and stores when the byte order was little endian for ppc64le. This is the corresponding change for bytes that are in big endian order. These rules are all intended for a little endian target arch. This adds new testcases in test/codegen/memcombine.go Fixes #22496 Updates #24242 Benchmark improvement for encoding/binary: name old time/op new time/op delta ReadSlice1000Int32s-16 11.0µs ± 0% 9.0µs ± 0% -17.47% (p=0.029 n=4+4) ReadStruct-16 2.47µs ± 1% 2.48µs ± 0% +0.67% (p=0.114 n=4+4) ReadInts-16 642ns ± 1% 630ns ± 1% -2.02% (p=0.029 n=4+4) WriteInts-16 654ns ± 0% 653ns ± 1% -0.08% (p=0.629 n=4+4) WriteSlice1000Int32s-16 8.75µs ± 0% 8.20µs ± 0% -6.19% (p=0.029 n=4+4) PutUint16-16 1.16ns ± 0% 0.93ns ± 0% -19.83% (p=0.029 n=4+4) PutUint32-16 1.16ns ± 0% 0.93ns ± 0% -19.83% (p=0.029 n=4+4) PutUint64-16 1.85ns ± 0% 0.93ns ± 0% -49.73% (p=0.029 n=4+4) LittleEndianPutUint16-16 1.03ns ± 0% 0.93ns ± 0% -9.71% (p=0.029 n=4+4) LittleEndianPutUint32-16 0.93ns ± 0% 0.93ns ± 0% ~ (all equal) LittleEndianPutUint64-16 0.93ns ± 0% 0.93ns ± 0% ~ (all equal) PutUvarint32-16 43.0ns ± 0% 43.1ns ± 0% +0.12% (p=0.429 n=4+4) PutUvarint64-16 174ns ± 0% 175ns ± 0% +0.29% (p=0.429 n=4+4) Updates made to functions in gcm.go to enable their matching. An existing testcase prevents these functions from being replaced by those in encoding/binary due to import dependencies. Change-Id: Idb3bd1e6e7b12d86cd828fb29cb095848a3e485a Reviewed-on: https://go-review.googlesource.com/98136 Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2018-03-01 11:40:36 -05:00
s.f.Fatalf("no register available for %s", v.LongString())
}
// Pick an unused register if one is available.
if mask&^s.used != 0 {
cmd/compile/internal/ssa: drop overwritten regalloc basic block input requirements For the following description, consider the following basic block graph: b1 ───┐┌──── b2 ││ ││ ▼▼ b3 For register allocator transitions between basic blocks, there are two key passes (significant paraphrasing): First, each basic block is visited in some predetermined visit order. This is the core visitOrder range loop in regAllocState.regalloc. The specific ordering heuristics aren't important here, except that the order guarantees that when visiting a basic block at least one of its predecessors has already been visited. Upon visiting a basic block, that block sets its expected starting register state (regAllocState.startRegs) based on the ending register state (regAlloc.State.endRegs) of one of its predecessors. (How it chooses which predecessor to use is not important here.) From that starting state, registers are assigned for all values in the block, ultimately resulting in some ending register state. After all blocks have been visited, the shuffle pass (regAllocState.shuffle) ensures that for each edge, endRegs of the predecessor == startRegs of the successor. That is, it makes sure that the startRegs assumptions actually hold true for each edge. It does this by adding moves to the end of the predecessor block to place values in the expected register for the successor block. These may be moves from other registers, or from memory if the value is spilled. Now on to the actual problem: Assume that b1 places some value v1 into register R10, and thus ends with endRegs containing R10 = v1. When b3 is visited, it selects b1 as its model predecessor and sets startRegs with R10 = v1. b2 does not have v1 in R10, so later in the shuffle pass, we will add a move of v1 into R10 to the end of b2 to ensure it is available for b3. This is all perfectly fine and exactly how things should work. Now suppose that b3 does not use v1. It does need to use some other value v2, which is not currently in a register. When assigning v2 to a register, it finds all registers are already in use and it needs to dump a value. Ultimately, it decides to dump v1 from R10 and replace it with v2. This is fine, but it has downstream effects on shuffle in b2. b3's startRegs still state that R10 = v1, so b2 will add a move to R10 even though b3 will unconditionally overwrite it. i.e., the move at the end of b2 is completely useless and can result in code like: // end of b2 MOV n(SP), R10 // R10 = v1 <-- useless // start of b3 MOV m(SP), R10 // R10 = v2 This is precisely what happened in #58298. This CL addresses this problem by dropping registers from startRegs if they are never used in the basic block prior to getting dumped. This allows the shuffle pass to avoid placing those useless values into the register. There is a significant limitation to this CL, which is that it only impacts the immediate predecessors of an overwriting block. We can discuss this by zooming out a bit on the previous graph: b4 ───┐┌──── b5 ││ ││ ▼▼ b1 ───┐┌──── b2 ││ ││ ▼▼ b3 Here we have the same graph, except we can see the two predecessors of b1. Now suppose that rather than b1 assigning R10 = v1 as above, the assignment is done in b4. b1 has startRegs R10 = v1, doesn't use the value at all, and simply passes it through to endRegs R10 = v1. Now the shuffle pass will require both b2 and b5 to add a move to assigned R10 = v1, because that is specified in their successor startRegs. With this CL, b3 drops R10 = v1 from startRegs, but there is no backwards propagation, so b1 still has R10 = v1 in startRegs, and b5 still needs to add a useless move. Extending this CL with such propagation may significantly increase the number of useless moves we can remove, though it will add complexity to maintenance and could potentially impact build performance depending on how efficiently we could implement the propagation (something I haven't considered carefully). As-is, this optimization does not impact much code. In bent .text size geomean is -0.02%. In the container/heap test binary, 18 of ~2500 functions are impacted by this CL. Bent and sweet do not show a noticeable performance impact one way or another, however #58298 does show a case where this can have impact if the useless instructions end up in the hot path of a tight loop. For #58298. Change-Id: I2fcef37c955159d068fa0725f995a1848add8a5f Reviewed-on: https://go-review.googlesource.com/c/go/+/471158 Run-TryBot: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: David Chase <drchase@google.com>
2023-02-21 13:20:49 -05:00
r := pickReg(mask &^ s.used)
s.usedSinceBlockStart |= regMask(1) << r
return r
}
// Pick a value to spill. Spill the value with the
// farthest-in-the-future use.
// TODO: Prefer registers with already spilled Values?
// TODO: Modify preference using affinity graph.
// TODO: if a single value is in multiple registers, spill one of them
// before spilling a value in just a single register.
// Find a register to spill. We spill the register containing the value
// whose next use is as far in the future as possible.
// https://en.wikipedia.org/wiki/Page_replacement_algorithm#The_theoretically_optimal_page_replacement_algorithm
var r register
maxuse := int32(-1)
for t := register(0); t < s.numRegs; t++ {
if mask>>t&1 == 0 {
continue
}
v := s.regs[t].v
if n := s.values[v.ID].uses.dist; n > maxuse {
// v's next use is farther in the future than any value
// we've seen so far. A new best spill candidate.
r = t
maxuse = n
}
}
if maxuse == -1 {
s.f.Fatalf("couldn't find register to spill")
}
cmd/compile: move value around before kick it out of register When allocating registers, before kicking out the existing value, copy it to a spare register if there is one. So later use of this value can be found in register instead of reload from spill. This is very helpful for instructions of which the input and/or output can only be in specific registers, e.g. DIV on x86, MUL/DIV on MIPS. May also be helpful in general. For "go build -a cmd/go" on AMD64, reduce "spilled value remains" by 1% (not including args, which almost certainly remain). For the code in issue #16061 on AMD64: MaxRem-12 111µs ± 1% 94µs ± 0% -15.38% (p=0.008 n=5+5) Go1 benchmark on AMD64: BinaryTree17-12 2.32s ± 2% 2.30s ± 1% ~ (p=0.421 n=5+5) Fannkuch11-12 2.52s ± 0% 2.44s ± 0% -3.44% (p=0.008 n=5+5) FmtFprintfEmpty-12 39.9ns ± 3% 39.8ns ± 0% ~ (p=0.635 n=5+4) FmtFprintfString-12 114ns ± 1% 113ns ± 1% ~ (p=0.905 n=5+5) FmtFprintfInt-12 102ns ± 6% 98ns ± 1% ~ (p=0.087 n=5+5) FmtFprintfIntInt-12 146ns ± 5% 147ns ± 1% ~ (p=0.238 n=5+5) FmtFprintfPrefixedInt-12 155ns ± 2% 151ns ± 1% -2.58% (p=0.008 n=5+5) FmtFprintfFloat-12 231ns ± 1% 232ns ± 1% ~ (p=0.286 n=5+5) FmtManyArgs-12 657ns ± 1% 649ns ± 0% -1.31% (p=0.008 n=5+5) GobDecode-12 6.35ms ± 0% 6.29ms ± 1% ~ (p=0.056 n=5+5) GobEncode-12 5.38ms ± 1% 5.45ms ± 1% ~ (p=0.056 n=5+5) Gzip-12 209ms ± 0% 209ms ± 1% ~ (p=0.690 n=5+5) Gunzip-12 31.2ms ± 1% 31.1ms ± 1% ~ (p=0.548 n=5+5) HTTPClientServer-12 123µs ± 4% 130µs ± 8% ~ (p=0.151 n=5+5) JSONEncode-12 14.0ms ± 1% 14.0ms ± 1% ~ (p=0.421 n=5+5) JSONDecode-12 41.2ms ± 1% 41.1ms ± 2% ~ (p=0.421 n=5+5) Mandelbrot200-12 3.96ms ± 1% 3.98ms ± 0% ~ (p=0.421 n=5+5) GoParse-12 2.88ms ± 1% 2.88ms ± 1% ~ (p=0.841 n=5+5) RegexpMatchEasy0_32-12 68.0ns ± 3% 66.6ns ± 1% -2.00% (p=0.024 n=5+5) RegexpMatchEasy0_1K-12 728ns ± 8% 682ns ± 1% -6.26% (p=0.008 n=5+5) RegexpMatchEasy1_32-12 66.8ns ± 2% 66.0ns ± 1% ~ (p=0.302 n=5+5) RegexpMatchEasy1_1K-12 291ns ± 2% 288ns ± 1% ~ (p=0.111 n=5+5) RegexpMatchMedium_32-12 103ns ± 2% 100ns ± 0% -2.53% (p=0.016 n=5+4) RegexpMatchMedium_1K-12 31.9µs ± 1% 31.3µs ± 0% -1.75% (p=0.008 n=5+5) RegexpMatchHard_32-12 1.59µs ± 2% 1.59µs ± 1% ~ (p=0.548 n=5+5) RegexpMatchHard_1K-12 48.3µs ± 2% 47.7µs ± 1% ~ (p=0.222 n=5+5) Revcomp-12 340ms ± 1% 338ms ± 1% ~ (p=0.421 n=5+5) Template-12 46.3ms ± 1% 46.5ms ± 1% ~ (p=0.690 n=5+5) TimeParse-12 252ns ± 1% 247ns ± 0% -1.91% (p=0.000 n=5+4) TimeFormat-12 277ns ± 1% 267ns ± 0% -3.82% (p=0.008 n=5+5) [Geo mean] 48.8µs 48.3µs -0.93% It has very little effect on binary size and compiler speed. compilebench: Template 230ms ±10% 231ms ± 8% ~ (p=0.546 n=9+9) Unicode 123ms ± 6% 124ms ± 9% ~ (p=0.481 n=10+10) GoTypes 742ms ± 6% 755ms ± 3% ~ (p=0.123 n=10+10) Compiler 3.10s ± 3% 3.08s ± 1% ~ (p=0.631 n=10+10) Fixes #16061. Change-Id: Id99cdc7a182ee10a704fa0f04e8e0d0809b2ac56 Reviewed-on: https://go-review.googlesource.com/29732 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2016-09-23 09:15:51 -04:00
cmd/compile: add wasm stack optimization 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>
2018-03-09 00:14:58 +01:00
if s.f.Config.ctxt.Arch.Arch == sys.ArchWasm {
// TODO(neelance): In theory this should never happen, because all wasm registers are equal.
// So if there is still a free register, the allocation should have picked that one in the first place instead of
cmd/compile: add wasm stack optimization 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>
2018-03-09 00:14:58 +01:00
// trying to kick some other value out. In practice, this case does happen and it breaks the stack optimization.
s.freeReg(r)
return r
}
cmd/compile: move value around before kick it out of register When allocating registers, before kicking out the existing value, copy it to a spare register if there is one. So later use of this value can be found in register instead of reload from spill. This is very helpful for instructions of which the input and/or output can only be in specific registers, e.g. DIV on x86, MUL/DIV on MIPS. May also be helpful in general. For "go build -a cmd/go" on AMD64, reduce "spilled value remains" by 1% (not including args, which almost certainly remain). For the code in issue #16061 on AMD64: MaxRem-12 111µs ± 1% 94µs ± 0% -15.38% (p=0.008 n=5+5) Go1 benchmark on AMD64: BinaryTree17-12 2.32s ± 2% 2.30s ± 1% ~ (p=0.421 n=5+5) Fannkuch11-12 2.52s ± 0% 2.44s ± 0% -3.44% (p=0.008 n=5+5) FmtFprintfEmpty-12 39.9ns ± 3% 39.8ns ± 0% ~ (p=0.635 n=5+4) FmtFprintfString-12 114ns ± 1% 113ns ± 1% ~ (p=0.905 n=5+5) FmtFprintfInt-12 102ns ± 6% 98ns ± 1% ~ (p=0.087 n=5+5) FmtFprintfIntInt-12 146ns ± 5% 147ns ± 1% ~ (p=0.238 n=5+5) FmtFprintfPrefixedInt-12 155ns ± 2% 151ns ± 1% -2.58% (p=0.008 n=5+5) FmtFprintfFloat-12 231ns ± 1% 232ns ± 1% ~ (p=0.286 n=5+5) FmtManyArgs-12 657ns ± 1% 649ns ± 0% -1.31% (p=0.008 n=5+5) GobDecode-12 6.35ms ± 0% 6.29ms ± 1% ~ (p=0.056 n=5+5) GobEncode-12 5.38ms ± 1% 5.45ms ± 1% ~ (p=0.056 n=5+5) Gzip-12 209ms ± 0% 209ms ± 1% ~ (p=0.690 n=5+5) Gunzip-12 31.2ms ± 1% 31.1ms ± 1% ~ (p=0.548 n=5+5) HTTPClientServer-12 123µs ± 4% 130µs ± 8% ~ (p=0.151 n=5+5) JSONEncode-12 14.0ms ± 1% 14.0ms ± 1% ~ (p=0.421 n=5+5) JSONDecode-12 41.2ms ± 1% 41.1ms ± 2% ~ (p=0.421 n=5+5) Mandelbrot200-12 3.96ms ± 1% 3.98ms ± 0% ~ (p=0.421 n=5+5) GoParse-12 2.88ms ± 1% 2.88ms ± 1% ~ (p=0.841 n=5+5) RegexpMatchEasy0_32-12 68.0ns ± 3% 66.6ns ± 1% -2.00% (p=0.024 n=5+5) RegexpMatchEasy0_1K-12 728ns ± 8% 682ns ± 1% -6.26% (p=0.008 n=5+5) RegexpMatchEasy1_32-12 66.8ns ± 2% 66.0ns ± 1% ~ (p=0.302 n=5+5) RegexpMatchEasy1_1K-12 291ns ± 2% 288ns ± 1% ~ (p=0.111 n=5+5) RegexpMatchMedium_32-12 103ns ± 2% 100ns ± 0% -2.53% (p=0.016 n=5+4) RegexpMatchMedium_1K-12 31.9µs ± 1% 31.3µs ± 0% -1.75% (p=0.008 n=5+5) RegexpMatchHard_32-12 1.59µs ± 2% 1.59µs ± 1% ~ (p=0.548 n=5+5) RegexpMatchHard_1K-12 48.3µs ± 2% 47.7µs ± 1% ~ (p=0.222 n=5+5) Revcomp-12 340ms ± 1% 338ms ± 1% ~ (p=0.421 n=5+5) Template-12 46.3ms ± 1% 46.5ms ± 1% ~ (p=0.690 n=5+5) TimeParse-12 252ns ± 1% 247ns ± 0% -1.91% (p=0.000 n=5+4) TimeFormat-12 277ns ± 1% 267ns ± 0% -3.82% (p=0.008 n=5+5) [Geo mean] 48.8µs 48.3µs -0.93% It has very little effect on binary size and compiler speed. compilebench: Template 230ms ±10% 231ms ± 8% ~ (p=0.546 n=9+9) Unicode 123ms ± 6% 124ms ± 9% ~ (p=0.481 n=10+10) GoTypes 742ms ± 6% 755ms ± 3% ~ (p=0.123 n=10+10) Compiler 3.10s ± 3% 3.08s ± 1% ~ (p=0.631 n=10+10) Fixes #16061. Change-Id: Id99cdc7a182ee10a704fa0f04e8e0d0809b2ac56 Reviewed-on: https://go-review.googlesource.com/29732 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2016-09-23 09:15:51 -04:00
// Try to move it around before kicking out, if there is a free register.
// We generate a Copy and record it. It will be deleted if never used.
v2 := s.regs[r].v
m := s.compatRegs(v2.Type) &^ s.used &^ s.tmpused &^ (regMask(1) << r)
if m != 0 && !s.values[v2.ID].rematerializeable && countRegs(s.values[v2.ID].regs) == 1 {
cmd/compile/internal/ssa: drop overwritten regalloc basic block input requirements For the following description, consider the following basic block graph: b1 ───┐┌──── b2 ││ ││ ▼▼ b3 For register allocator transitions between basic blocks, there are two key passes (significant paraphrasing): First, each basic block is visited in some predetermined visit order. This is the core visitOrder range loop in regAllocState.regalloc. The specific ordering heuristics aren't important here, except that the order guarantees that when visiting a basic block at least one of its predecessors has already been visited. Upon visiting a basic block, that block sets its expected starting register state (regAllocState.startRegs) based on the ending register state (regAlloc.State.endRegs) of one of its predecessors. (How it chooses which predecessor to use is not important here.) From that starting state, registers are assigned for all values in the block, ultimately resulting in some ending register state. After all blocks have been visited, the shuffle pass (regAllocState.shuffle) ensures that for each edge, endRegs of the predecessor == startRegs of the successor. That is, it makes sure that the startRegs assumptions actually hold true for each edge. It does this by adding moves to the end of the predecessor block to place values in the expected register for the successor block. These may be moves from other registers, or from memory if the value is spilled. Now on to the actual problem: Assume that b1 places some value v1 into register R10, and thus ends with endRegs containing R10 = v1. When b3 is visited, it selects b1 as its model predecessor and sets startRegs with R10 = v1. b2 does not have v1 in R10, so later in the shuffle pass, we will add a move of v1 into R10 to the end of b2 to ensure it is available for b3. This is all perfectly fine and exactly how things should work. Now suppose that b3 does not use v1. It does need to use some other value v2, which is not currently in a register. When assigning v2 to a register, it finds all registers are already in use and it needs to dump a value. Ultimately, it decides to dump v1 from R10 and replace it with v2. This is fine, but it has downstream effects on shuffle in b2. b3's startRegs still state that R10 = v1, so b2 will add a move to R10 even though b3 will unconditionally overwrite it. i.e., the move at the end of b2 is completely useless and can result in code like: // end of b2 MOV n(SP), R10 // R10 = v1 <-- useless // start of b3 MOV m(SP), R10 // R10 = v2 This is precisely what happened in #58298. This CL addresses this problem by dropping registers from startRegs if they are never used in the basic block prior to getting dumped. This allows the shuffle pass to avoid placing those useless values into the register. There is a significant limitation to this CL, which is that it only impacts the immediate predecessors of an overwriting block. We can discuss this by zooming out a bit on the previous graph: b4 ───┐┌──── b5 ││ ││ ▼▼ b1 ───┐┌──── b2 ││ ││ ▼▼ b3 Here we have the same graph, except we can see the two predecessors of b1. Now suppose that rather than b1 assigning R10 = v1 as above, the assignment is done in b4. b1 has startRegs R10 = v1, doesn't use the value at all, and simply passes it through to endRegs R10 = v1. Now the shuffle pass will require both b2 and b5 to add a move to assigned R10 = v1, because that is specified in their successor startRegs. With this CL, b3 drops R10 = v1 from startRegs, but there is no backwards propagation, so b1 still has R10 = v1 in startRegs, and b5 still needs to add a useless move. Extending this CL with such propagation may significantly increase the number of useless moves we can remove, though it will add complexity to maintenance and could potentially impact build performance depending on how efficiently we could implement the propagation (something I haven't considered carefully). As-is, this optimization does not impact much code. In bent .text size geomean is -0.02%. In the container/heap test binary, 18 of ~2500 functions are impacted by this CL. Bent and sweet do not show a noticeable performance impact one way or another, however #58298 does show a case where this can have impact if the useless instructions end up in the hot path of a tight loop. For #58298. Change-Id: I2fcef37c955159d068fa0725f995a1848add8a5f Reviewed-on: https://go-review.googlesource.com/c/go/+/471158 Run-TryBot: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: David Chase <drchase@google.com>
2023-02-21 13:20:49 -05:00
s.usedSinceBlockStart |= regMask(1) << r
cmd/compile: move value around before kick it out of register When allocating registers, before kicking out the existing value, copy it to a spare register if there is one. So later use of this value can be found in register instead of reload from spill. This is very helpful for instructions of which the input and/or output can only be in specific registers, e.g. DIV on x86, MUL/DIV on MIPS. May also be helpful in general. For "go build -a cmd/go" on AMD64, reduce "spilled value remains" by 1% (not including args, which almost certainly remain). For the code in issue #16061 on AMD64: MaxRem-12 111µs ± 1% 94µs ± 0% -15.38% (p=0.008 n=5+5) Go1 benchmark on AMD64: BinaryTree17-12 2.32s ± 2% 2.30s ± 1% ~ (p=0.421 n=5+5) Fannkuch11-12 2.52s ± 0% 2.44s ± 0% -3.44% (p=0.008 n=5+5) FmtFprintfEmpty-12 39.9ns ± 3% 39.8ns ± 0% ~ (p=0.635 n=5+4) FmtFprintfString-12 114ns ± 1% 113ns ± 1% ~ (p=0.905 n=5+5) FmtFprintfInt-12 102ns ± 6% 98ns ± 1% ~ (p=0.087 n=5+5) FmtFprintfIntInt-12 146ns ± 5% 147ns ± 1% ~ (p=0.238 n=5+5) FmtFprintfPrefixedInt-12 155ns ± 2% 151ns ± 1% -2.58% (p=0.008 n=5+5) FmtFprintfFloat-12 231ns ± 1% 232ns ± 1% ~ (p=0.286 n=5+5) FmtManyArgs-12 657ns ± 1% 649ns ± 0% -1.31% (p=0.008 n=5+5) GobDecode-12 6.35ms ± 0% 6.29ms ± 1% ~ (p=0.056 n=5+5) GobEncode-12 5.38ms ± 1% 5.45ms ± 1% ~ (p=0.056 n=5+5) Gzip-12 209ms ± 0% 209ms ± 1% ~ (p=0.690 n=5+5) Gunzip-12 31.2ms ± 1% 31.1ms ± 1% ~ (p=0.548 n=5+5) HTTPClientServer-12 123µs ± 4% 130µs ± 8% ~ (p=0.151 n=5+5) JSONEncode-12 14.0ms ± 1% 14.0ms ± 1% ~ (p=0.421 n=5+5) JSONDecode-12 41.2ms ± 1% 41.1ms ± 2% ~ (p=0.421 n=5+5) Mandelbrot200-12 3.96ms ± 1% 3.98ms ± 0% ~ (p=0.421 n=5+5) GoParse-12 2.88ms ± 1% 2.88ms ± 1% ~ (p=0.841 n=5+5) RegexpMatchEasy0_32-12 68.0ns ± 3% 66.6ns ± 1% -2.00% (p=0.024 n=5+5) RegexpMatchEasy0_1K-12 728ns ± 8% 682ns ± 1% -6.26% (p=0.008 n=5+5) RegexpMatchEasy1_32-12 66.8ns ± 2% 66.0ns ± 1% ~ (p=0.302 n=5+5) RegexpMatchEasy1_1K-12 291ns ± 2% 288ns ± 1% ~ (p=0.111 n=5+5) RegexpMatchMedium_32-12 103ns ± 2% 100ns ± 0% -2.53% (p=0.016 n=5+4) RegexpMatchMedium_1K-12 31.9µs ± 1% 31.3µs ± 0% -1.75% (p=0.008 n=5+5) RegexpMatchHard_32-12 1.59µs ± 2% 1.59µs ± 1% ~ (p=0.548 n=5+5) RegexpMatchHard_1K-12 48.3µs ± 2% 47.7µs ± 1% ~ (p=0.222 n=5+5) Revcomp-12 340ms ± 1% 338ms ± 1% ~ (p=0.421 n=5+5) Template-12 46.3ms ± 1% 46.5ms ± 1% ~ (p=0.690 n=5+5) TimeParse-12 252ns ± 1% 247ns ± 0% -1.91% (p=0.000 n=5+4) TimeFormat-12 277ns ± 1% 267ns ± 0% -3.82% (p=0.008 n=5+5) [Geo mean] 48.8µs 48.3µs -0.93% It has very little effect on binary size and compiler speed. compilebench: Template 230ms ±10% 231ms ± 8% ~ (p=0.546 n=9+9) Unicode 123ms ± 6% 124ms ± 9% ~ (p=0.481 n=10+10) GoTypes 742ms ± 6% 755ms ± 3% ~ (p=0.123 n=10+10) Compiler 3.10s ± 3% 3.08s ± 1% ~ (p=0.631 n=10+10) Fixes #16061. Change-Id: Id99cdc7a182ee10a704fa0f04e8e0d0809b2ac56 Reviewed-on: https://go-review.googlesource.com/29732 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2016-09-23 09:15:51 -04:00
r2 := pickReg(m)
c := s.curBlock.NewValue1(v2.Pos, OpCopy, v2.Type, s.regs[r].c)
cmd/compile: move value around before kick it out of register When allocating registers, before kicking out the existing value, copy it to a spare register if there is one. So later use of this value can be found in register instead of reload from spill. This is very helpful for instructions of which the input and/or output can only be in specific registers, e.g. DIV on x86, MUL/DIV on MIPS. May also be helpful in general. For "go build -a cmd/go" on AMD64, reduce "spilled value remains" by 1% (not including args, which almost certainly remain). For the code in issue #16061 on AMD64: MaxRem-12 111µs ± 1% 94µs ± 0% -15.38% (p=0.008 n=5+5) Go1 benchmark on AMD64: BinaryTree17-12 2.32s ± 2% 2.30s ± 1% ~ (p=0.421 n=5+5) Fannkuch11-12 2.52s ± 0% 2.44s ± 0% -3.44% (p=0.008 n=5+5) FmtFprintfEmpty-12 39.9ns ± 3% 39.8ns ± 0% ~ (p=0.635 n=5+4) FmtFprintfString-12 114ns ± 1% 113ns ± 1% ~ (p=0.905 n=5+5) FmtFprintfInt-12 102ns ± 6% 98ns ± 1% ~ (p=0.087 n=5+5) FmtFprintfIntInt-12 146ns ± 5% 147ns ± 1% ~ (p=0.238 n=5+5) FmtFprintfPrefixedInt-12 155ns ± 2% 151ns ± 1% -2.58% (p=0.008 n=5+5) FmtFprintfFloat-12 231ns ± 1% 232ns ± 1% ~ (p=0.286 n=5+5) FmtManyArgs-12 657ns ± 1% 649ns ± 0% -1.31% (p=0.008 n=5+5) GobDecode-12 6.35ms ± 0% 6.29ms ± 1% ~ (p=0.056 n=5+5) GobEncode-12 5.38ms ± 1% 5.45ms ± 1% ~ (p=0.056 n=5+5) Gzip-12 209ms ± 0% 209ms ± 1% ~ (p=0.690 n=5+5) Gunzip-12 31.2ms ± 1% 31.1ms ± 1% ~ (p=0.548 n=5+5) HTTPClientServer-12 123µs ± 4% 130µs ± 8% ~ (p=0.151 n=5+5) JSONEncode-12 14.0ms ± 1% 14.0ms ± 1% ~ (p=0.421 n=5+5) JSONDecode-12 41.2ms ± 1% 41.1ms ± 2% ~ (p=0.421 n=5+5) Mandelbrot200-12 3.96ms ± 1% 3.98ms ± 0% ~ (p=0.421 n=5+5) GoParse-12 2.88ms ± 1% 2.88ms ± 1% ~ (p=0.841 n=5+5) RegexpMatchEasy0_32-12 68.0ns ± 3% 66.6ns ± 1% -2.00% (p=0.024 n=5+5) RegexpMatchEasy0_1K-12 728ns ± 8% 682ns ± 1% -6.26% (p=0.008 n=5+5) RegexpMatchEasy1_32-12 66.8ns ± 2% 66.0ns ± 1% ~ (p=0.302 n=5+5) RegexpMatchEasy1_1K-12 291ns ± 2% 288ns ± 1% ~ (p=0.111 n=5+5) RegexpMatchMedium_32-12 103ns ± 2% 100ns ± 0% -2.53% (p=0.016 n=5+4) RegexpMatchMedium_1K-12 31.9µs ± 1% 31.3µs ± 0% -1.75% (p=0.008 n=5+5) RegexpMatchHard_32-12 1.59µs ± 2% 1.59µs ± 1% ~ (p=0.548 n=5+5) RegexpMatchHard_1K-12 48.3µs ± 2% 47.7µs ± 1% ~ (p=0.222 n=5+5) Revcomp-12 340ms ± 1% 338ms ± 1% ~ (p=0.421 n=5+5) Template-12 46.3ms ± 1% 46.5ms ± 1% ~ (p=0.690 n=5+5) TimeParse-12 252ns ± 1% 247ns ± 0% -1.91% (p=0.000 n=5+4) TimeFormat-12 277ns ± 1% 267ns ± 0% -3.82% (p=0.008 n=5+5) [Geo mean] 48.8µs 48.3µs -0.93% It has very little effect on binary size and compiler speed. compilebench: Template 230ms ±10% 231ms ± 8% ~ (p=0.546 n=9+9) Unicode 123ms ± 6% 124ms ± 9% ~ (p=0.481 n=10+10) GoTypes 742ms ± 6% 755ms ± 3% ~ (p=0.123 n=10+10) Compiler 3.10s ± 3% 3.08s ± 1% ~ (p=0.631 n=10+10) Fixes #16061. Change-Id: Id99cdc7a182ee10a704fa0f04e8e0d0809b2ac56 Reviewed-on: https://go-review.googlesource.com/29732 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2016-09-23 09:15:51 -04:00
s.copies[c] = false
if s.f.pass.debug > regDebug {
fmt.Printf("copy %s to %s : %s\n", v2, c, &s.registers[r2])
cmd/compile: move value around before kick it out of register When allocating registers, before kicking out the existing value, copy it to a spare register if there is one. So later use of this value can be found in register instead of reload from spill. This is very helpful for instructions of which the input and/or output can only be in specific registers, e.g. DIV on x86, MUL/DIV on MIPS. May also be helpful in general. For "go build -a cmd/go" on AMD64, reduce "spilled value remains" by 1% (not including args, which almost certainly remain). For the code in issue #16061 on AMD64: MaxRem-12 111µs ± 1% 94µs ± 0% -15.38% (p=0.008 n=5+5) Go1 benchmark on AMD64: BinaryTree17-12 2.32s ± 2% 2.30s ± 1% ~ (p=0.421 n=5+5) Fannkuch11-12 2.52s ± 0% 2.44s ± 0% -3.44% (p=0.008 n=5+5) FmtFprintfEmpty-12 39.9ns ± 3% 39.8ns ± 0% ~ (p=0.635 n=5+4) FmtFprintfString-12 114ns ± 1% 113ns ± 1% ~ (p=0.905 n=5+5) FmtFprintfInt-12 102ns ± 6% 98ns ± 1% ~ (p=0.087 n=5+5) FmtFprintfIntInt-12 146ns ± 5% 147ns ± 1% ~ (p=0.238 n=5+5) FmtFprintfPrefixedInt-12 155ns ± 2% 151ns ± 1% -2.58% (p=0.008 n=5+5) FmtFprintfFloat-12 231ns ± 1% 232ns ± 1% ~ (p=0.286 n=5+5) FmtManyArgs-12 657ns ± 1% 649ns ± 0% -1.31% (p=0.008 n=5+5) GobDecode-12 6.35ms ± 0% 6.29ms ± 1% ~ (p=0.056 n=5+5) GobEncode-12 5.38ms ± 1% 5.45ms ± 1% ~ (p=0.056 n=5+5) Gzip-12 209ms ± 0% 209ms ± 1% ~ (p=0.690 n=5+5) Gunzip-12 31.2ms ± 1% 31.1ms ± 1% ~ (p=0.548 n=5+5) HTTPClientServer-12 123µs ± 4% 130µs ± 8% ~ (p=0.151 n=5+5) JSONEncode-12 14.0ms ± 1% 14.0ms ± 1% ~ (p=0.421 n=5+5) JSONDecode-12 41.2ms ± 1% 41.1ms ± 2% ~ (p=0.421 n=5+5) Mandelbrot200-12 3.96ms ± 1% 3.98ms ± 0% ~ (p=0.421 n=5+5) GoParse-12 2.88ms ± 1% 2.88ms ± 1% ~ (p=0.841 n=5+5) RegexpMatchEasy0_32-12 68.0ns ± 3% 66.6ns ± 1% -2.00% (p=0.024 n=5+5) RegexpMatchEasy0_1K-12 728ns ± 8% 682ns ± 1% -6.26% (p=0.008 n=5+5) RegexpMatchEasy1_32-12 66.8ns ± 2% 66.0ns ± 1% ~ (p=0.302 n=5+5) RegexpMatchEasy1_1K-12 291ns ± 2% 288ns ± 1% ~ (p=0.111 n=5+5) RegexpMatchMedium_32-12 103ns ± 2% 100ns ± 0% -2.53% (p=0.016 n=5+4) RegexpMatchMedium_1K-12 31.9µs ± 1% 31.3µs ± 0% -1.75% (p=0.008 n=5+5) RegexpMatchHard_32-12 1.59µs ± 2% 1.59µs ± 1% ~ (p=0.548 n=5+5) RegexpMatchHard_1K-12 48.3µs ± 2% 47.7µs ± 1% ~ (p=0.222 n=5+5) Revcomp-12 340ms ± 1% 338ms ± 1% ~ (p=0.421 n=5+5) Template-12 46.3ms ± 1% 46.5ms ± 1% ~ (p=0.690 n=5+5) TimeParse-12 252ns ± 1% 247ns ± 0% -1.91% (p=0.000 n=5+4) TimeFormat-12 277ns ± 1% 267ns ± 0% -3.82% (p=0.008 n=5+5) [Geo mean] 48.8µs 48.3µs -0.93% It has very little effect on binary size and compiler speed. compilebench: Template 230ms ±10% 231ms ± 8% ~ (p=0.546 n=9+9) Unicode 123ms ± 6% 124ms ± 9% ~ (p=0.481 n=10+10) GoTypes 742ms ± 6% 755ms ± 3% ~ (p=0.123 n=10+10) Compiler 3.10s ± 3% 3.08s ± 1% ~ (p=0.631 n=10+10) Fixes #16061. Change-Id: Id99cdc7a182ee10a704fa0f04e8e0d0809b2ac56 Reviewed-on: https://go-review.googlesource.com/29732 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2016-09-23 09:15:51 -04:00
}
s.setOrig(c, v2)
s.assignReg(r2, v2, c)
}
cmd/compile/internal/ssa: drop overwritten regalloc basic block input requirements For the following description, consider the following basic block graph: b1 ───┐┌──── b2 ││ ││ ▼▼ b3 For register allocator transitions between basic blocks, there are two key passes (significant paraphrasing): First, each basic block is visited in some predetermined visit order. This is the core visitOrder range loop in regAllocState.regalloc. The specific ordering heuristics aren't important here, except that the order guarantees that when visiting a basic block at least one of its predecessors has already been visited. Upon visiting a basic block, that block sets its expected starting register state (regAllocState.startRegs) based on the ending register state (regAlloc.State.endRegs) of one of its predecessors. (How it chooses which predecessor to use is not important here.) From that starting state, registers are assigned for all values in the block, ultimately resulting in some ending register state. After all blocks have been visited, the shuffle pass (regAllocState.shuffle) ensures that for each edge, endRegs of the predecessor == startRegs of the successor. That is, it makes sure that the startRegs assumptions actually hold true for each edge. It does this by adding moves to the end of the predecessor block to place values in the expected register for the successor block. These may be moves from other registers, or from memory if the value is spilled. Now on to the actual problem: Assume that b1 places some value v1 into register R10, and thus ends with endRegs containing R10 = v1. When b3 is visited, it selects b1 as its model predecessor and sets startRegs with R10 = v1. b2 does not have v1 in R10, so later in the shuffle pass, we will add a move of v1 into R10 to the end of b2 to ensure it is available for b3. This is all perfectly fine and exactly how things should work. Now suppose that b3 does not use v1. It does need to use some other value v2, which is not currently in a register. When assigning v2 to a register, it finds all registers are already in use and it needs to dump a value. Ultimately, it decides to dump v1 from R10 and replace it with v2. This is fine, but it has downstream effects on shuffle in b2. b3's startRegs still state that R10 = v1, so b2 will add a move to R10 even though b3 will unconditionally overwrite it. i.e., the move at the end of b2 is completely useless and can result in code like: // end of b2 MOV n(SP), R10 // R10 = v1 <-- useless // start of b3 MOV m(SP), R10 // R10 = v2 This is precisely what happened in #58298. This CL addresses this problem by dropping registers from startRegs if they are never used in the basic block prior to getting dumped. This allows the shuffle pass to avoid placing those useless values into the register. There is a significant limitation to this CL, which is that it only impacts the immediate predecessors of an overwriting block. We can discuss this by zooming out a bit on the previous graph: b4 ───┐┌──── b5 ││ ││ ▼▼ b1 ───┐┌──── b2 ││ ││ ▼▼ b3 Here we have the same graph, except we can see the two predecessors of b1. Now suppose that rather than b1 assigning R10 = v1 as above, the assignment is done in b4. b1 has startRegs R10 = v1, doesn't use the value at all, and simply passes it through to endRegs R10 = v1. Now the shuffle pass will require both b2 and b5 to add a move to assigned R10 = v1, because that is specified in their successor startRegs. With this CL, b3 drops R10 = v1 from startRegs, but there is no backwards propagation, so b1 still has R10 = v1 in startRegs, and b5 still needs to add a useless move. Extending this CL with such propagation may significantly increase the number of useless moves we can remove, though it will add complexity to maintenance and could potentially impact build performance depending on how efficiently we could implement the propagation (something I haven't considered carefully). As-is, this optimization does not impact much code. In bent .text size geomean is -0.02%. In the container/heap test binary, 18 of ~2500 functions are impacted by this CL. Bent and sweet do not show a noticeable performance impact one way or another, however #58298 does show a case where this can have impact if the useless instructions end up in the hot path of a tight loop. For #58298. Change-Id: I2fcef37c955159d068fa0725f995a1848add8a5f Reviewed-on: https://go-review.googlesource.com/c/go/+/471158 Run-TryBot: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: David Chase <drchase@google.com>
2023-02-21 13:20:49 -05:00
// If the evicted register isn't used between the start of the block
// and now then there is no reason to even request it on entry. We can
// drop from startRegs in that case.
if s.usedSinceBlockStart&(regMask(1)<<r) == 0 {
if s.startRegsMask&(regMask(1)<<r) == 1 {
cmd/compile/internal/ssa: drop overwritten regalloc basic block input requirements For the following description, consider the following basic block graph: b1 ───┐┌──── b2 ││ ││ ▼▼ b3 For register allocator transitions between basic blocks, there are two key passes (significant paraphrasing): First, each basic block is visited in some predetermined visit order. This is the core visitOrder range loop in regAllocState.regalloc. The specific ordering heuristics aren't important here, except that the order guarantees that when visiting a basic block at least one of its predecessors has already been visited. Upon visiting a basic block, that block sets its expected starting register state (regAllocState.startRegs) based on the ending register state (regAlloc.State.endRegs) of one of its predecessors. (How it chooses which predecessor to use is not important here.) From that starting state, registers are assigned for all values in the block, ultimately resulting in some ending register state. After all blocks have been visited, the shuffle pass (regAllocState.shuffle) ensures that for each edge, endRegs of the predecessor == startRegs of the successor. That is, it makes sure that the startRegs assumptions actually hold true for each edge. It does this by adding moves to the end of the predecessor block to place values in the expected register for the successor block. These may be moves from other registers, or from memory if the value is spilled. Now on to the actual problem: Assume that b1 places some value v1 into register R10, and thus ends with endRegs containing R10 = v1. When b3 is visited, it selects b1 as its model predecessor and sets startRegs with R10 = v1. b2 does not have v1 in R10, so later in the shuffle pass, we will add a move of v1 into R10 to the end of b2 to ensure it is available for b3. This is all perfectly fine and exactly how things should work. Now suppose that b3 does not use v1. It does need to use some other value v2, which is not currently in a register. When assigning v2 to a register, it finds all registers are already in use and it needs to dump a value. Ultimately, it decides to dump v1 from R10 and replace it with v2. This is fine, but it has downstream effects on shuffle in b2. b3's startRegs still state that R10 = v1, so b2 will add a move to R10 even though b3 will unconditionally overwrite it. i.e., the move at the end of b2 is completely useless and can result in code like: // end of b2 MOV n(SP), R10 // R10 = v1 <-- useless // start of b3 MOV m(SP), R10 // R10 = v2 This is precisely what happened in #58298. This CL addresses this problem by dropping registers from startRegs if they are never used in the basic block prior to getting dumped. This allows the shuffle pass to avoid placing those useless values into the register. There is a significant limitation to this CL, which is that it only impacts the immediate predecessors of an overwriting block. We can discuss this by zooming out a bit on the previous graph: b4 ───┐┌──── b5 ││ ││ ▼▼ b1 ───┐┌──── b2 ││ ││ ▼▼ b3 Here we have the same graph, except we can see the two predecessors of b1. Now suppose that rather than b1 assigning R10 = v1 as above, the assignment is done in b4. b1 has startRegs R10 = v1, doesn't use the value at all, and simply passes it through to endRegs R10 = v1. Now the shuffle pass will require both b2 and b5 to add a move to assigned R10 = v1, because that is specified in their successor startRegs. With this CL, b3 drops R10 = v1 from startRegs, but there is no backwards propagation, so b1 still has R10 = v1 in startRegs, and b5 still needs to add a useless move. Extending this CL with such propagation may significantly increase the number of useless moves we can remove, though it will add complexity to maintenance and could potentially impact build performance depending on how efficiently we could implement the propagation (something I haven't considered carefully). As-is, this optimization does not impact much code. In bent .text size geomean is -0.02%. In the container/heap test binary, 18 of ~2500 functions are impacted by this CL. Bent and sweet do not show a noticeable performance impact one way or another, however #58298 does show a case where this can have impact if the useless instructions end up in the hot path of a tight loop. For #58298. Change-Id: I2fcef37c955159d068fa0725f995a1848add8a5f Reviewed-on: https://go-review.googlesource.com/c/go/+/471158 Run-TryBot: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: David Chase <drchase@google.com>
2023-02-21 13:20:49 -05:00
if s.f.pass.debug > regDebug {
fmt.Printf("dropped from startRegs: %s\n", &s.registers[r])
}
s.startRegsMask &^= regMask(1) << r
}
}
s.freeReg(r)
cmd/compile/internal/ssa: drop overwritten regalloc basic block input requirements For the following description, consider the following basic block graph: b1 ───┐┌──── b2 ││ ││ ▼▼ b3 For register allocator transitions between basic blocks, there are two key passes (significant paraphrasing): First, each basic block is visited in some predetermined visit order. This is the core visitOrder range loop in regAllocState.regalloc. The specific ordering heuristics aren't important here, except that the order guarantees that when visiting a basic block at least one of its predecessors has already been visited. Upon visiting a basic block, that block sets its expected starting register state (regAllocState.startRegs) based on the ending register state (regAlloc.State.endRegs) of one of its predecessors. (How it chooses which predecessor to use is not important here.) From that starting state, registers are assigned for all values in the block, ultimately resulting in some ending register state. After all blocks have been visited, the shuffle pass (regAllocState.shuffle) ensures that for each edge, endRegs of the predecessor == startRegs of the successor. That is, it makes sure that the startRegs assumptions actually hold true for each edge. It does this by adding moves to the end of the predecessor block to place values in the expected register for the successor block. These may be moves from other registers, or from memory if the value is spilled. Now on to the actual problem: Assume that b1 places some value v1 into register R10, and thus ends with endRegs containing R10 = v1. When b3 is visited, it selects b1 as its model predecessor and sets startRegs with R10 = v1. b2 does not have v1 in R10, so later in the shuffle pass, we will add a move of v1 into R10 to the end of b2 to ensure it is available for b3. This is all perfectly fine and exactly how things should work. Now suppose that b3 does not use v1. It does need to use some other value v2, which is not currently in a register. When assigning v2 to a register, it finds all registers are already in use and it needs to dump a value. Ultimately, it decides to dump v1 from R10 and replace it with v2. This is fine, but it has downstream effects on shuffle in b2. b3's startRegs still state that R10 = v1, so b2 will add a move to R10 even though b3 will unconditionally overwrite it. i.e., the move at the end of b2 is completely useless and can result in code like: // end of b2 MOV n(SP), R10 // R10 = v1 <-- useless // start of b3 MOV m(SP), R10 // R10 = v2 This is precisely what happened in #58298. This CL addresses this problem by dropping registers from startRegs if they are never used in the basic block prior to getting dumped. This allows the shuffle pass to avoid placing those useless values into the register. There is a significant limitation to this CL, which is that it only impacts the immediate predecessors of an overwriting block. We can discuss this by zooming out a bit on the previous graph: b4 ───┐┌──── b5 ││ ││ ▼▼ b1 ───┐┌──── b2 ││ ││ ▼▼ b3 Here we have the same graph, except we can see the two predecessors of b1. Now suppose that rather than b1 assigning R10 = v1 as above, the assignment is done in b4. b1 has startRegs R10 = v1, doesn't use the value at all, and simply passes it through to endRegs R10 = v1. Now the shuffle pass will require both b2 and b5 to add a move to assigned R10 = v1, because that is specified in their successor startRegs. With this CL, b3 drops R10 = v1 from startRegs, but there is no backwards propagation, so b1 still has R10 = v1 in startRegs, and b5 still needs to add a useless move. Extending this CL with such propagation may significantly increase the number of useless moves we can remove, though it will add complexity to maintenance and could potentially impact build performance depending on how efficiently we could implement the propagation (something I haven't considered carefully). As-is, this optimization does not impact much code. In bent .text size geomean is -0.02%. In the container/heap test binary, 18 of ~2500 functions are impacted by this CL. Bent and sweet do not show a noticeable performance impact one way or another, however #58298 does show a case where this can have impact if the useless instructions end up in the hot path of a tight loop. For #58298. Change-Id: I2fcef37c955159d068fa0725f995a1848add8a5f Reviewed-on: https://go-review.googlesource.com/c/go/+/471158 Run-TryBot: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: David Chase <drchase@google.com>
2023-02-21 13:20:49 -05:00
s.usedSinceBlockStart |= regMask(1) << r
return r
}
cmd/compile: put spills in better places Previously we always issued a spill right after the op that was being spilled. This CL pushes spills father away from the generator, hopefully pushing them into unlikely branches. For example: x = ... if unlikely { call ... } ... use x ... Used to compile to x = ... spill x if unlikely { call ... restore x } It now compiles to x = ... if unlikely { spill x call ... restore x } This is particularly useful for code which appends, as the only call is an unlikely call to growslice. It also helps for the spills needed around write barrier calls. The basic algorithm is walk down the dominator tree following a path where the block still dominates all of the restores. We're looking for a block that: 1) dominates all restores 2) has the value being spilled in a register 3) has a loop depth no deeper than the value being spilled The walking-down code is iterative. I was forced to limit it to searching 100 blocks so it doesn't become O(n^2). Maybe one day we'll find a better way. I had to delete most of David's code which pushed spills out of loops. I suspect this CL subsumes most of the cases that his code handled. Generally positive performance improvements, but hard to tell for sure with all the noise. (compilebench times are unchanged.) name old time/op new time/op delta BinaryTree17-12 2.91s ±15% 2.80s ±12% ~ (p=0.063 n=10+10) Fannkuch11-12 3.47s ± 0% 3.30s ± 4% -4.91% (p=0.000 n=9+10) FmtFprintfEmpty-12 48.0ns ± 1% 47.4ns ± 1% -1.32% (p=0.002 n=9+9) FmtFprintfString-12 85.6ns ±11% 79.4ns ± 3% -7.27% (p=0.005 n=10+10) FmtFprintfInt-12 91.8ns ±10% 85.9ns ± 4% ~ (p=0.203 n=10+9) FmtFprintfIntInt-12 135ns ±13% 127ns ± 1% -5.72% (p=0.025 n=10+9) FmtFprintfPrefixedInt-12 167ns ± 1% 168ns ± 2% ~ (p=0.580 n=9+10) FmtFprintfFloat-12 249ns ±11% 230ns ± 1% -7.32% (p=0.000 n=10+10) FmtManyArgs-12 504ns ± 7% 506ns ± 1% ~ (p=0.198 n=9+9) GobDecode-12 6.95ms ± 1% 7.04ms ± 1% +1.37% (p=0.001 n=10+10) GobEncode-12 6.32ms ±13% 6.04ms ± 1% ~ (p=0.063 n=10+10) Gzip-12 233ms ± 1% 235ms ± 0% +1.01% (p=0.000 n=10+9) Gunzip-12 40.1ms ± 1% 39.6ms ± 0% -1.12% (p=0.000 n=10+8) HTTPClientServer-12 227µs ± 9% 221µs ± 5% ~ (p=0.114 n=9+8) JSONEncode-12 16.1ms ± 2% 15.8ms ± 1% -2.09% (p=0.002 n=9+8) JSONDecode-12 61.8ms ±11% 57.9ms ± 1% -6.30% (p=0.000 n=10+9) Mandelbrot200-12 4.30ms ± 3% 4.28ms ± 1% ~ (p=0.203 n=10+8) GoParse-12 3.18ms ± 2% 3.18ms ± 2% ~ (p=0.579 n=10+10) RegexpMatchEasy0_32-12 76.7ns ± 1% 77.5ns ± 1% +0.92% (p=0.002 n=9+8) RegexpMatchEasy0_1K-12 239ns ± 3% 239ns ± 1% ~ (p=0.204 n=10+10) RegexpMatchEasy1_32-12 71.4ns ± 1% 70.6ns ± 0% -1.15% (p=0.000 n=10+9) RegexpMatchEasy1_1K-12 383ns ± 2% 390ns ±10% ~ (p=0.181 n=8+9) RegexpMatchMedium_32-12 114ns ± 0% 113ns ± 1% -0.88% (p=0.000 n=9+8) RegexpMatchMedium_1K-12 36.3µs ± 1% 36.8µs ± 1% +1.59% (p=0.000 n=10+8) RegexpMatchHard_32-12 1.90µs ± 1% 1.90µs ± 1% ~ (p=0.341 n=10+10) RegexpMatchHard_1K-12 59.4µs ±11% 57.8µs ± 1% ~ (p=0.968 n=10+9) Revcomp-12 461ms ± 1% 462ms ± 1% ~ (p=1.000 n=9+9) Template-12 67.5ms ± 1% 66.3ms ± 1% -1.77% (p=0.000 n=10+8) TimeParse-12 314ns ± 3% 309ns ± 0% -1.56% (p=0.000 n=9+8) TimeFormat-12 340ns ± 2% 331ns ± 1% -2.79% (p=0.000 n=10+10) The go binary is 0.2% larger. Not really sure why the size would change. Change-Id: Ia5116e53a3aeb025ef350ffc51c14ae5cc17871c Reviewed-on: https://go-review.googlesource.com/34822 Reviewed-by: David Chase <drchase@google.com>
2017-03-07 14:45:46 -05:00
// makeSpill returns a Value which represents the spilled value of v.
// b is the block in which the spill is used.
func (s *regAllocState) makeSpill(v *Value, b *Block) *Value {
vi := &s.values[v.ID]
if vi.spill != nil {
// Final block not known - keep track of subtree where restores reside.
vi.restoreMin = min(vi.restoreMin, s.sdom[b.ID].entry)
vi.restoreMax = max(vi.restoreMax, s.sdom[b.ID].exit)
cmd/compile: put spills in better places Previously we always issued a spill right after the op that was being spilled. This CL pushes spills father away from the generator, hopefully pushing them into unlikely branches. For example: x = ... if unlikely { call ... } ... use x ... Used to compile to x = ... spill x if unlikely { call ... restore x } It now compiles to x = ... if unlikely { spill x call ... restore x } This is particularly useful for code which appends, as the only call is an unlikely call to growslice. It also helps for the spills needed around write barrier calls. The basic algorithm is walk down the dominator tree following a path where the block still dominates all of the restores. We're looking for a block that: 1) dominates all restores 2) has the value being spilled in a register 3) has a loop depth no deeper than the value being spilled The walking-down code is iterative. I was forced to limit it to searching 100 blocks so it doesn't become O(n^2). Maybe one day we'll find a better way. I had to delete most of David's code which pushed spills out of loops. I suspect this CL subsumes most of the cases that his code handled. Generally positive performance improvements, but hard to tell for sure with all the noise. (compilebench times are unchanged.) name old time/op new time/op delta BinaryTree17-12 2.91s ±15% 2.80s ±12% ~ (p=0.063 n=10+10) Fannkuch11-12 3.47s ± 0% 3.30s ± 4% -4.91% (p=0.000 n=9+10) FmtFprintfEmpty-12 48.0ns ± 1% 47.4ns ± 1% -1.32% (p=0.002 n=9+9) FmtFprintfString-12 85.6ns ±11% 79.4ns ± 3% -7.27% (p=0.005 n=10+10) FmtFprintfInt-12 91.8ns ±10% 85.9ns ± 4% ~ (p=0.203 n=10+9) FmtFprintfIntInt-12 135ns ±13% 127ns ± 1% -5.72% (p=0.025 n=10+9) FmtFprintfPrefixedInt-12 167ns ± 1% 168ns ± 2% ~ (p=0.580 n=9+10) FmtFprintfFloat-12 249ns ±11% 230ns ± 1% -7.32% (p=0.000 n=10+10) FmtManyArgs-12 504ns ± 7% 506ns ± 1% ~ (p=0.198 n=9+9) GobDecode-12 6.95ms ± 1% 7.04ms ± 1% +1.37% (p=0.001 n=10+10) GobEncode-12 6.32ms ±13% 6.04ms ± 1% ~ (p=0.063 n=10+10) Gzip-12 233ms ± 1% 235ms ± 0% +1.01% (p=0.000 n=10+9) Gunzip-12 40.1ms ± 1% 39.6ms ± 0% -1.12% (p=0.000 n=10+8) HTTPClientServer-12 227µs ± 9% 221µs ± 5% ~ (p=0.114 n=9+8) JSONEncode-12 16.1ms ± 2% 15.8ms ± 1% -2.09% (p=0.002 n=9+8) JSONDecode-12 61.8ms ±11% 57.9ms ± 1% -6.30% (p=0.000 n=10+9) Mandelbrot200-12 4.30ms ± 3% 4.28ms ± 1% ~ (p=0.203 n=10+8) GoParse-12 3.18ms ± 2% 3.18ms ± 2% ~ (p=0.579 n=10+10) RegexpMatchEasy0_32-12 76.7ns ± 1% 77.5ns ± 1% +0.92% (p=0.002 n=9+8) RegexpMatchEasy0_1K-12 239ns ± 3% 239ns ± 1% ~ (p=0.204 n=10+10) RegexpMatchEasy1_32-12 71.4ns ± 1% 70.6ns ± 0% -1.15% (p=0.000 n=10+9) RegexpMatchEasy1_1K-12 383ns ± 2% 390ns ±10% ~ (p=0.181 n=8+9) RegexpMatchMedium_32-12 114ns ± 0% 113ns ± 1% -0.88% (p=0.000 n=9+8) RegexpMatchMedium_1K-12 36.3µs ± 1% 36.8µs ± 1% +1.59% (p=0.000 n=10+8) RegexpMatchHard_32-12 1.90µs ± 1% 1.90µs ± 1% ~ (p=0.341 n=10+10) RegexpMatchHard_1K-12 59.4µs ±11% 57.8µs ± 1% ~ (p=0.968 n=10+9) Revcomp-12 461ms ± 1% 462ms ± 1% ~ (p=1.000 n=9+9) Template-12 67.5ms ± 1% 66.3ms ± 1% -1.77% (p=0.000 n=10+8) TimeParse-12 314ns ± 3% 309ns ± 0% -1.56% (p=0.000 n=9+8) TimeFormat-12 340ns ± 2% 331ns ± 1% -2.79% (p=0.000 n=10+10) The go binary is 0.2% larger. Not really sure why the size would change. Change-Id: Ia5116e53a3aeb025ef350ffc51c14ae5cc17871c Reviewed-on: https://go-review.googlesource.com/34822 Reviewed-by: David Chase <drchase@google.com>
2017-03-07 14:45:46 -05:00
return vi.spill
}
// Make a spill for v. We don't know where we want
// to put it yet, so we leave it blockless for now.
spill := s.f.newValueNoBlock(OpStoreReg, v.Type, v.Pos)
// We also don't know what the spill's arg will be.
// Leave it argless for now.
s.setOrig(spill, v)
vi.spill = spill
vi.restoreMin = s.sdom[b.ID].entry
vi.restoreMax = s.sdom[b.ID].exit
return spill
}
// allocValToReg allocates v to a register selected from regMask and
// returns the register copy of v. Any previous user is kicked out and spilled
// (if necessary). Load code is added at the current pc. If nospill is set the
// allocated register is marked nospill so the assignment cannot be
// undone until the caller allows it by clearing nospill. Returns a
// *Value which is either v or a copy of v allocated to the chosen register.
2016-12-15 17:17:01 -08:00
func (s *regAllocState) allocValToReg(v *Value, mask regMask, nospill bool, pos src.XPos) *Value {
cmd/compile: add wasm stack optimization 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>
2018-03-09 00:14:58 +01:00
if s.f.Config.ctxt.Arch.Arch == sys.ArchWasm && v.rematerializeable() {
c := v.copyIntoWithXPos(s.curBlock, pos)
c.OnWasmStack = true
s.setOrig(c, v)
return c
}
if v.OnWasmStack {
return v
}
vi := &s.values[v.ID]
pos = pos.WithNotStmt()
// Check if v is already in a requested register.
if mask&vi.regs != 0 {
mask &= vi.regs
r := pickReg(mask)
if mask.contains(s.SPReg) {
// Prefer the stack pointer if it is allowed.
// (Needed because the op might have an Aux symbol
// that needs SP as its base.)
r = s.SPReg
}
if !s.allocatable.contains(r) {
return v // v is in a fixed register
}
if s.regs[r].v != v || s.regs[r].c == nil {
panic("bad register state")
}
if nospill {
s.nospill |= regMask(1) << r
}
cmd/compile/internal/ssa: drop overwritten regalloc basic block input requirements For the following description, consider the following basic block graph: b1 ───┐┌──── b2 ││ ││ ▼▼ b3 For register allocator transitions between basic blocks, there are two key passes (significant paraphrasing): First, each basic block is visited in some predetermined visit order. This is the core visitOrder range loop in regAllocState.regalloc. The specific ordering heuristics aren't important here, except that the order guarantees that when visiting a basic block at least one of its predecessors has already been visited. Upon visiting a basic block, that block sets its expected starting register state (regAllocState.startRegs) based on the ending register state (regAlloc.State.endRegs) of one of its predecessors. (How it chooses which predecessor to use is not important here.) From that starting state, registers are assigned for all values in the block, ultimately resulting in some ending register state. After all blocks have been visited, the shuffle pass (regAllocState.shuffle) ensures that for each edge, endRegs of the predecessor == startRegs of the successor. That is, it makes sure that the startRegs assumptions actually hold true for each edge. It does this by adding moves to the end of the predecessor block to place values in the expected register for the successor block. These may be moves from other registers, or from memory if the value is spilled. Now on to the actual problem: Assume that b1 places some value v1 into register R10, and thus ends with endRegs containing R10 = v1. When b3 is visited, it selects b1 as its model predecessor and sets startRegs with R10 = v1. b2 does not have v1 in R10, so later in the shuffle pass, we will add a move of v1 into R10 to the end of b2 to ensure it is available for b3. This is all perfectly fine and exactly how things should work. Now suppose that b3 does not use v1. It does need to use some other value v2, which is not currently in a register. When assigning v2 to a register, it finds all registers are already in use and it needs to dump a value. Ultimately, it decides to dump v1 from R10 and replace it with v2. This is fine, but it has downstream effects on shuffle in b2. b3's startRegs still state that R10 = v1, so b2 will add a move to R10 even though b3 will unconditionally overwrite it. i.e., the move at the end of b2 is completely useless and can result in code like: // end of b2 MOV n(SP), R10 // R10 = v1 <-- useless // start of b3 MOV m(SP), R10 // R10 = v2 This is precisely what happened in #58298. This CL addresses this problem by dropping registers from startRegs if they are never used in the basic block prior to getting dumped. This allows the shuffle pass to avoid placing those useless values into the register. There is a significant limitation to this CL, which is that it only impacts the immediate predecessors of an overwriting block. We can discuss this by zooming out a bit on the previous graph: b4 ───┐┌──── b5 ││ ││ ▼▼ b1 ───┐┌──── b2 ││ ││ ▼▼ b3 Here we have the same graph, except we can see the two predecessors of b1. Now suppose that rather than b1 assigning R10 = v1 as above, the assignment is done in b4. b1 has startRegs R10 = v1, doesn't use the value at all, and simply passes it through to endRegs R10 = v1. Now the shuffle pass will require both b2 and b5 to add a move to assigned R10 = v1, because that is specified in their successor startRegs. With this CL, b3 drops R10 = v1 from startRegs, but there is no backwards propagation, so b1 still has R10 = v1 in startRegs, and b5 still needs to add a useless move. Extending this CL with such propagation may significantly increase the number of useless moves we can remove, though it will add complexity to maintenance and could potentially impact build performance depending on how efficiently we could implement the propagation (something I haven't considered carefully). As-is, this optimization does not impact much code. In bent .text size geomean is -0.02%. In the container/heap test binary, 18 of ~2500 functions are impacted by this CL. Bent and sweet do not show a noticeable performance impact one way or another, however #58298 does show a case where this can have impact if the useless instructions end up in the hot path of a tight loop. For #58298. Change-Id: I2fcef37c955159d068fa0725f995a1848add8a5f Reviewed-on: https://go-review.googlesource.com/c/go/+/471158 Run-TryBot: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: David Chase <drchase@google.com>
2023-02-21 13:20:49 -05:00
s.usedSinceBlockStart |= regMask(1) << r
return s.regs[r].c
}
cmd/compile: add wasm stack optimization 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>
2018-03-09 00:14:58 +01:00
var r register
// If nospill is set, the value is used immediately, so it can live on the WebAssembly stack.
cmd/compile: add wasm stack optimization 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>
2018-03-09 00:14:58 +01:00
onWasmStack := nospill && s.f.Config.ctxt.Arch.Arch == sys.ArchWasm
if !onWasmStack {
// Allocate a register.
r = s.allocReg(mask, v)
}
// Allocate v to the new register.
var c *Value
if vi.regs != 0 {
// Copy from a register that v is already in.
r2 := pickReg(vi.regs)
var current *Value
if !s.allocatable.contains(r2) {
current = v // v is in a fixed register
} else {
if s.regs[r2].v != v {
panic("bad register state")
}
current = s.regs[r2].c
}
cmd/compile/internal/ssa: drop overwritten regalloc basic block input requirements For the following description, consider the following basic block graph: b1 ───┐┌──── b2 ││ ││ ▼▼ b3 For register allocator transitions between basic blocks, there are two key passes (significant paraphrasing): First, each basic block is visited in some predetermined visit order. This is the core visitOrder range loop in regAllocState.regalloc. The specific ordering heuristics aren't important here, except that the order guarantees that when visiting a basic block at least one of its predecessors has already been visited. Upon visiting a basic block, that block sets its expected starting register state (regAllocState.startRegs) based on the ending register state (regAlloc.State.endRegs) of one of its predecessors. (How it chooses which predecessor to use is not important here.) From that starting state, registers are assigned for all values in the block, ultimately resulting in some ending register state. After all blocks have been visited, the shuffle pass (regAllocState.shuffle) ensures that for each edge, endRegs of the predecessor == startRegs of the successor. That is, it makes sure that the startRegs assumptions actually hold true for each edge. It does this by adding moves to the end of the predecessor block to place values in the expected register for the successor block. These may be moves from other registers, or from memory if the value is spilled. Now on to the actual problem: Assume that b1 places some value v1 into register R10, and thus ends with endRegs containing R10 = v1. When b3 is visited, it selects b1 as its model predecessor and sets startRegs with R10 = v1. b2 does not have v1 in R10, so later in the shuffle pass, we will add a move of v1 into R10 to the end of b2 to ensure it is available for b3. This is all perfectly fine and exactly how things should work. Now suppose that b3 does not use v1. It does need to use some other value v2, which is not currently in a register. When assigning v2 to a register, it finds all registers are already in use and it needs to dump a value. Ultimately, it decides to dump v1 from R10 and replace it with v2. This is fine, but it has downstream effects on shuffle in b2. b3's startRegs still state that R10 = v1, so b2 will add a move to R10 even though b3 will unconditionally overwrite it. i.e., the move at the end of b2 is completely useless and can result in code like: // end of b2 MOV n(SP), R10 // R10 = v1 <-- useless // start of b3 MOV m(SP), R10 // R10 = v2 This is precisely what happened in #58298. This CL addresses this problem by dropping registers from startRegs if they are never used in the basic block prior to getting dumped. This allows the shuffle pass to avoid placing those useless values into the register. There is a significant limitation to this CL, which is that it only impacts the immediate predecessors of an overwriting block. We can discuss this by zooming out a bit on the previous graph: b4 ───┐┌──── b5 ││ ││ ▼▼ b1 ───┐┌──── b2 ││ ││ ▼▼ b3 Here we have the same graph, except we can see the two predecessors of b1. Now suppose that rather than b1 assigning R10 = v1 as above, the assignment is done in b4. b1 has startRegs R10 = v1, doesn't use the value at all, and simply passes it through to endRegs R10 = v1. Now the shuffle pass will require both b2 and b5 to add a move to assigned R10 = v1, because that is specified in their successor startRegs. With this CL, b3 drops R10 = v1 from startRegs, but there is no backwards propagation, so b1 still has R10 = v1 in startRegs, and b5 still needs to add a useless move. Extending this CL with such propagation may significantly increase the number of useless moves we can remove, though it will add complexity to maintenance and could potentially impact build performance depending on how efficiently we could implement the propagation (something I haven't considered carefully). As-is, this optimization does not impact much code. In bent .text size geomean is -0.02%. In the container/heap test binary, 18 of ~2500 functions are impacted by this CL. Bent and sweet do not show a noticeable performance impact one way or another, however #58298 does show a case where this can have impact if the useless instructions end up in the hot path of a tight loop. For #58298. Change-Id: I2fcef37c955159d068fa0725f995a1848add8a5f Reviewed-on: https://go-review.googlesource.com/c/go/+/471158 Run-TryBot: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: David Chase <drchase@google.com>
2023-02-21 13:20:49 -05:00
s.usedSinceBlockStart |= regMask(1) << r2
c = s.curBlock.NewValue1(pos, OpCopy, v.Type, current)
} else if v.rematerializeable() {
// Rematerialize instead of loading from the spill location.
c = v.copyIntoWithXPos(s.curBlock, pos)
} else {
// Load v from its spill location.
cmd/compile: put spills in better places Previously we always issued a spill right after the op that was being spilled. This CL pushes spills father away from the generator, hopefully pushing them into unlikely branches. For example: x = ... if unlikely { call ... } ... use x ... Used to compile to x = ... spill x if unlikely { call ... restore x } It now compiles to x = ... if unlikely { spill x call ... restore x } This is particularly useful for code which appends, as the only call is an unlikely call to growslice. It also helps for the spills needed around write barrier calls. The basic algorithm is walk down the dominator tree following a path where the block still dominates all of the restores. We're looking for a block that: 1) dominates all restores 2) has the value being spilled in a register 3) has a loop depth no deeper than the value being spilled The walking-down code is iterative. I was forced to limit it to searching 100 blocks so it doesn't become O(n^2). Maybe one day we'll find a better way. I had to delete most of David's code which pushed spills out of loops. I suspect this CL subsumes most of the cases that his code handled. Generally positive performance improvements, but hard to tell for sure with all the noise. (compilebench times are unchanged.) name old time/op new time/op delta BinaryTree17-12 2.91s ±15% 2.80s ±12% ~ (p=0.063 n=10+10) Fannkuch11-12 3.47s ± 0% 3.30s ± 4% -4.91% (p=0.000 n=9+10) FmtFprintfEmpty-12 48.0ns ± 1% 47.4ns ± 1% -1.32% (p=0.002 n=9+9) FmtFprintfString-12 85.6ns ±11% 79.4ns ± 3% -7.27% (p=0.005 n=10+10) FmtFprintfInt-12 91.8ns ±10% 85.9ns ± 4% ~ (p=0.203 n=10+9) FmtFprintfIntInt-12 135ns ±13% 127ns ± 1% -5.72% (p=0.025 n=10+9) FmtFprintfPrefixedInt-12 167ns ± 1% 168ns ± 2% ~ (p=0.580 n=9+10) FmtFprintfFloat-12 249ns ±11% 230ns ± 1% -7.32% (p=0.000 n=10+10) FmtManyArgs-12 504ns ± 7% 506ns ± 1% ~ (p=0.198 n=9+9) GobDecode-12 6.95ms ± 1% 7.04ms ± 1% +1.37% (p=0.001 n=10+10) GobEncode-12 6.32ms ±13% 6.04ms ± 1% ~ (p=0.063 n=10+10) Gzip-12 233ms ± 1% 235ms ± 0% +1.01% (p=0.000 n=10+9) Gunzip-12 40.1ms ± 1% 39.6ms ± 0% -1.12% (p=0.000 n=10+8) HTTPClientServer-12 227µs ± 9% 221µs ± 5% ~ (p=0.114 n=9+8) JSONEncode-12 16.1ms ± 2% 15.8ms ± 1% -2.09% (p=0.002 n=9+8) JSONDecode-12 61.8ms ±11% 57.9ms ± 1% -6.30% (p=0.000 n=10+9) Mandelbrot200-12 4.30ms ± 3% 4.28ms ± 1% ~ (p=0.203 n=10+8) GoParse-12 3.18ms ± 2% 3.18ms ± 2% ~ (p=0.579 n=10+10) RegexpMatchEasy0_32-12 76.7ns ± 1% 77.5ns ± 1% +0.92% (p=0.002 n=9+8) RegexpMatchEasy0_1K-12 239ns ± 3% 239ns ± 1% ~ (p=0.204 n=10+10) RegexpMatchEasy1_32-12 71.4ns ± 1% 70.6ns ± 0% -1.15% (p=0.000 n=10+9) RegexpMatchEasy1_1K-12 383ns ± 2% 390ns ±10% ~ (p=0.181 n=8+9) RegexpMatchMedium_32-12 114ns ± 0% 113ns ± 1% -0.88% (p=0.000 n=9+8) RegexpMatchMedium_1K-12 36.3µs ± 1% 36.8µs ± 1% +1.59% (p=0.000 n=10+8) RegexpMatchHard_32-12 1.90µs ± 1% 1.90µs ± 1% ~ (p=0.341 n=10+10) RegexpMatchHard_1K-12 59.4µs ±11% 57.8µs ± 1% ~ (p=0.968 n=10+9) Revcomp-12 461ms ± 1% 462ms ± 1% ~ (p=1.000 n=9+9) Template-12 67.5ms ± 1% 66.3ms ± 1% -1.77% (p=0.000 n=10+8) TimeParse-12 314ns ± 3% 309ns ± 0% -1.56% (p=0.000 n=9+8) TimeFormat-12 340ns ± 2% 331ns ± 1% -2.79% (p=0.000 n=10+10) The go binary is 0.2% larger. Not really sure why the size would change. Change-Id: Ia5116e53a3aeb025ef350ffc51c14ae5cc17871c Reviewed-on: https://go-review.googlesource.com/34822 Reviewed-by: David Chase <drchase@google.com>
2017-03-07 14:45:46 -05:00
spill := s.makeSpill(v, s.curBlock)
if s.f.pass.debug > logSpills {
s.f.Warnl(vi.spill.Pos, "load spill for %v from %v", v, spill)
}
cmd/compile: put spills in better places Previously we always issued a spill right after the op that was being spilled. This CL pushes spills father away from the generator, hopefully pushing them into unlikely branches. For example: x = ... if unlikely { call ... } ... use x ... Used to compile to x = ... spill x if unlikely { call ... restore x } It now compiles to x = ... if unlikely { spill x call ... restore x } This is particularly useful for code which appends, as the only call is an unlikely call to growslice. It also helps for the spills needed around write barrier calls. The basic algorithm is walk down the dominator tree following a path where the block still dominates all of the restores. We're looking for a block that: 1) dominates all restores 2) has the value being spilled in a register 3) has a loop depth no deeper than the value being spilled The walking-down code is iterative. I was forced to limit it to searching 100 blocks so it doesn't become O(n^2). Maybe one day we'll find a better way. I had to delete most of David's code which pushed spills out of loops. I suspect this CL subsumes most of the cases that his code handled. Generally positive performance improvements, but hard to tell for sure with all the noise. (compilebench times are unchanged.) name old time/op new time/op delta BinaryTree17-12 2.91s ±15% 2.80s ±12% ~ (p=0.063 n=10+10) Fannkuch11-12 3.47s ± 0% 3.30s ± 4% -4.91% (p=0.000 n=9+10) FmtFprintfEmpty-12 48.0ns ± 1% 47.4ns ± 1% -1.32% (p=0.002 n=9+9) FmtFprintfString-12 85.6ns ±11% 79.4ns ± 3% -7.27% (p=0.005 n=10+10) FmtFprintfInt-12 91.8ns ±10% 85.9ns ± 4% ~ (p=0.203 n=10+9) FmtFprintfIntInt-12 135ns ±13% 127ns ± 1% -5.72% (p=0.025 n=10+9) FmtFprintfPrefixedInt-12 167ns ± 1% 168ns ± 2% ~ (p=0.580 n=9+10) FmtFprintfFloat-12 249ns ±11% 230ns ± 1% -7.32% (p=0.000 n=10+10) FmtManyArgs-12 504ns ± 7% 506ns ± 1% ~ (p=0.198 n=9+9) GobDecode-12 6.95ms ± 1% 7.04ms ± 1% +1.37% (p=0.001 n=10+10) GobEncode-12 6.32ms ±13% 6.04ms ± 1% ~ (p=0.063 n=10+10) Gzip-12 233ms ± 1% 235ms ± 0% +1.01% (p=0.000 n=10+9) Gunzip-12 40.1ms ± 1% 39.6ms ± 0% -1.12% (p=0.000 n=10+8) HTTPClientServer-12 227µs ± 9% 221µs ± 5% ~ (p=0.114 n=9+8) JSONEncode-12 16.1ms ± 2% 15.8ms ± 1% -2.09% (p=0.002 n=9+8) JSONDecode-12 61.8ms ±11% 57.9ms ± 1% -6.30% (p=0.000 n=10+9) Mandelbrot200-12 4.30ms ± 3% 4.28ms ± 1% ~ (p=0.203 n=10+8) GoParse-12 3.18ms ± 2% 3.18ms ± 2% ~ (p=0.579 n=10+10) RegexpMatchEasy0_32-12 76.7ns ± 1% 77.5ns ± 1% +0.92% (p=0.002 n=9+8) RegexpMatchEasy0_1K-12 239ns ± 3% 239ns ± 1% ~ (p=0.204 n=10+10) RegexpMatchEasy1_32-12 71.4ns ± 1% 70.6ns ± 0% -1.15% (p=0.000 n=10+9) RegexpMatchEasy1_1K-12 383ns ± 2% 390ns ±10% ~ (p=0.181 n=8+9) RegexpMatchMedium_32-12 114ns ± 0% 113ns ± 1% -0.88% (p=0.000 n=9+8) RegexpMatchMedium_1K-12 36.3µs ± 1% 36.8µs ± 1% +1.59% (p=0.000 n=10+8) RegexpMatchHard_32-12 1.90µs ± 1% 1.90µs ± 1% ~ (p=0.341 n=10+10) RegexpMatchHard_1K-12 59.4µs ±11% 57.8µs ± 1% ~ (p=0.968 n=10+9) Revcomp-12 461ms ± 1% 462ms ± 1% ~ (p=1.000 n=9+9) Template-12 67.5ms ± 1% 66.3ms ± 1% -1.77% (p=0.000 n=10+8) TimeParse-12 314ns ± 3% 309ns ± 0% -1.56% (p=0.000 n=9+8) TimeFormat-12 340ns ± 2% 331ns ± 1% -2.79% (p=0.000 n=10+10) The go binary is 0.2% larger. Not really sure why the size would change. Change-Id: Ia5116e53a3aeb025ef350ffc51c14ae5cc17871c Reviewed-on: https://go-review.googlesource.com/34822 Reviewed-by: David Chase <drchase@google.com>
2017-03-07 14:45:46 -05:00
c = s.curBlock.NewValue1(pos, OpLoadReg, v.Type, spill)
}
cmd/compile: add wasm stack optimization 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>
2018-03-09 00:14:58 +01:00
s.setOrig(c, v)
cmd/compile: add wasm stack optimization 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>
2018-03-09 00:14:58 +01:00
if onWasmStack {
c.OnWasmStack = true
return c
}
s.assignReg(r, v, c)
if c.Op == OpLoadReg && s.isGReg(r) {
s.f.Fatalf("allocValToReg.OpLoadReg targeting g: " + c.LongString())
}
if nospill {
s.nospill |= regMask(1) << r
}
return c
}
// isLeaf reports whether f performs any calls.
func isLeaf(f *Func) bool {
for _, b := range f.Blocks {
for _, v := range b.Values {
if v.Op.IsCall() && !v.Op.IsTailCall() {
// tail call is not counted as it does not save the return PC or need a frame
return false
}
}
}
return true
}
// needRegister reports whether v needs a register.
func (v *Value) needRegister() bool {
return !v.Type.IsMemory() && !v.Type.IsVoid() && !v.Type.IsFlags() && !v.Type.IsTuple()
}
func (s *regAllocState) init(f *Func) {
s.f = f
s.f.RegAlloc = s.f.Cache.locs[:0]
s.registers = f.Config.registers
if nr := len(s.registers); nr == 0 || nr > int(noRegister) || nr > int(unsafe.Sizeof(regMask(0))*8) {
s.f.Fatalf("bad number of registers: %d", nr)
} else {
s.numRegs = register(nr)
}
// Locate SP, SB, and g registers.
s.SPReg = noRegister
s.SBReg = noRegister
s.GReg = noRegister
s.ZeroIntReg = noRegister
for r := register(0); r < s.numRegs; r++ {
switch s.registers[r].String() {
case "SP":
s.SPReg = r
case "SB":
s.SBReg = r
case "g":
s.GReg = r
case "ZERO": // TODO: arch-specific?
s.ZeroIntReg = r
}
}
// Make sure we found all required registers.
switch noRegister {
case s.SPReg:
s.f.Fatalf("no SP register found")
case s.SBReg:
s.f.Fatalf("no SB register found")
case s.GReg:
if f.Config.hasGReg {
s.f.Fatalf("no g register found")
}
}
// Figure out which registers we're allowed to use.
s.allocatable = s.f.Config.gpRegMask | s.f.Config.fpRegMask | s.f.Config.specialRegMask
s.allocatable &^= 1 << s.SPReg
s.allocatable &^= 1 << s.SBReg
if s.f.Config.hasGReg {
s.allocatable &^= 1 << s.GReg
}
if s.ZeroIntReg != noRegister {
s.allocatable &^= 1 << s.ZeroIntReg
}
if buildcfg.FramePointerEnabled && s.f.Config.FPReg >= 0 {
s.allocatable &^= 1 << uint(s.f.Config.FPReg)
}
if s.f.Config.LinkReg != -1 {
if isLeaf(f) {
// Leaf functions don't save/restore the link register.
s.allocatable &^= 1 << uint(s.f.Config.LinkReg)
}
}
if s.f.Config.ctxt.Flag_dynlink {
switch s.f.Config.arch {
[dev.ssa] cmd/compile: fix PIC for SSA-generated code Access to globals requires a 2-instruction sequence on PIC 386. MOVL foo(SB), AX is translated by the obj package into: CALL getPCofNextInstructionInTempRegister(SB) MOVL (&foo-&thisInstruction)(tmpReg), AX The call returns the PC of the next instruction in a register. The next instruction then offsets from that register to get the address required. The tricky part is the allocation of the temp register. The legacy compiler always used CX, and forbid the register allocator from allocating CX when in PIC mode. We can't easily do that in SSA because CX is actually a required register for shift instructions. (I think the old backend got away with this because the register allocator never uses CX, only codegen knows that shifts must use CX.) Instead, we allow the temp register to be anything. When the destination of the MOV (or LEA) is an integer register, we can use that register. Otherwise, we make sure to compile the operation using an LEA to reference the global. So MOVL AX, foo(SB) is never generated directly. Instead, SSA generates: LEAL foo(SB), DX MOVL AX, (DX) which is then rewritten by the obj package to: CALL getPcInDX(SB) LEAL (&foo-&thisInstruction)(DX), AX MOVL AX, (DX) So this CL modifies the obj package to use different thunks to materialize the pc into different registers. We use the registers that regalloc chose so that SSA can still allocate the full set of registers. Change-Id: Ie095644f7164a026c62e95baf9d18a8bcaed0bba Reviewed-on: https://go-review.googlesource.com/25442 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2016-08-03 13:00:49 -07:00
case "386":
// nothing to do.
// Note that for Flag_shared (position independent code)
// we do need to be careful, but that carefulness is hidden
// in the rewrite rules so we always have a free register
// available for global load/stores. See _gen/386.rules (search for Flag_shared).
case "amd64":
s.allocatable &^= 1 << 15 // R15
case "arm":
s.allocatable &^= 1 << 9 // R9
case "arm64":
// nothing to do
case "loong64": // R2 (aka TP) already reserved.
// nothing to do
case "ppc64le": // R2 already reserved.
// nothing to do
case "riscv64": // X3 (aka GP) and X4 (aka TP) already reserved.
// nothing to do
case "s390x":
s.allocatable &^= 1 << 11 // R11
default:
s.f.fe.Fatalf(src.NoXPos, "arch %s not implemented", s.f.Config.arch)
}
}
// Linear scan register allocation can be influenced by the order in which blocks appear.
// Decouple the register allocation order from the generated block order.
// This also creates an opportunity for experiments to find a better order.
s.visitOrder = layoutRegallocOrder(f)
// Compute block order. This array allows us to distinguish forward edges
// from backward edges and compute how far they go.
cmd/compile: use depth first topological sort algorithm for layout The current layout algorithm tries to put consecutive blocks together, so the priority of the successor block is higher than the priority of the zero indegree block. This algorithm is beneficial for subsequent register allocation, but will result in more branch instructions. The depth-first topological sorting algorithm is a well-known layout algorithm, which has applications in many languages, and it helps to reduce branch instructions. This CL applies it to the layout pass. The test results show that it helps to reduce the code size. This CL also includes the following changes: 1, Removed the primary predecessor mechanism. The new layout algorithm is not very friendly to register allocator in some cases, in order to adapt to the new layout algorithm, a new primary predecessor selection strategy is introduced. 2, Since the new layout implementation may place non-loop blocks between loop blocks, some adaptive modifications have also been made to looprotate pass. 3, The layout also affects the results of codegen, so this CL also adjusted several codegen tests accordingly. It is inevitable that this CL will cause the code size or performance of a few functions to decrease, but the number of cases it improves is much larger than the number of cases it drops. Statistical data from compilecmp on linux/amd64 is as follow: name old time/op new time/op delta Template 382ms ± 4% 382ms ± 4% ~ (p=0.497 n=49+50) Unicode 170ms ± 9% 169ms ± 8% ~ (p=0.344 n=48+50) GoTypes 2.01s ± 4% 2.01s ± 4% ~ (p=0.628 n=50+48) Compiler 190ms ±10% 189ms ± 9% ~ (p=0.734 n=50+50) SSA 11.8s ± 2% 11.8s ± 3% ~ (p=0.877 n=50+50) Flate 241ms ± 9% 241ms ± 8% ~ (p=0.897 n=50+49) GoParser 366ms ± 3% 361ms ± 4% -1.21% (p=0.004 n=47+50) Reflect 835ms ± 3% 838ms ± 3% ~ (p=0.275 n=50+49) Tar 336ms ± 4% 335ms ± 3% ~ (p=0.454 n=48+48) XML 433ms ± 4% 431ms ± 3% ~ (p=0.071 n=49+48) LinkCompiler 706ms ± 4% 705ms ± 4% ~ (p=0.608 n=50+49) ExternalLinkCompiler 1.85s ± 3% 1.83s ± 2% -1.47% (p=0.000 n=49+48) LinkWithoutDebugCompiler 437ms ± 5% 437ms ± 6% ~ (p=0.953 n=49+50) [Geo mean] 615ms 613ms -0.37% name old alloc/op new alloc/op delta Template 38.7MB ± 1% 38.7MB ± 1% ~ (p=0.834 n=50+50) Unicode 28.1MB ± 0% 28.1MB ± 0% -0.22% (p=0.000 n=49+50) GoTypes 168MB ± 1% 168MB ± 1% ~ (p=0.054 n=47+47) Compiler 23.0MB ± 1% 23.0MB ± 1% ~ (p=0.432 n=50+50) SSA 1.54GB ± 0% 1.54GB ± 0% +0.21% (p=0.000 n=50+50) Flate 23.6MB ± 1% 23.6MB ± 1% ~ (p=0.153 n=43+46) GoParser 35.1MB ± 1% 35.1MB ± 2% ~ (p=0.202 n=50+50) Reflect 84.7MB ± 1% 84.7MB ± 1% ~ (p=0.333 n=48+49) Tar 34.5MB ± 1% 34.5MB ± 1% ~ (p=0.406 n=46+49) XML 44.3MB ± 2% 44.2MB ± 3% ~ (p=0.981 n=50+50) LinkCompiler 131MB ± 0% 128MB ± 0% -2.74% (p=0.000 n=50+50) ExternalLinkCompiler 120MB ± 0% 120MB ± 0% +0.01% (p=0.007 n=50+50) LinkWithoutDebugCompiler 77.3MB ± 0% 77.3MB ± 0% -0.02% (p=0.000 n=50+50) [Geo mean] 69.3MB 69.1MB -0.22% file before after Δ % addr2line 4104220 4043684 -60536 -1.475% api 5342502 5249678 -92824 -1.737% asm 4973785 4858257 -115528 -2.323% buildid 2667844 2625660 -42184 -1.581% cgo 4686849 4616313 -70536 -1.505% compile 23667431 23268406 -399025 -1.686% cover 4959676 4874108 -85568 -1.725% dist 3515934 3450422 -65512 -1.863% doc 3995581 3925469 -70112 -1.755% fix 3379202 3318522 -60680 -1.796% link 6743249 6629913 -113336 -1.681% nm 4047529 3991777 -55752 -1.377% objdump 4456151 4388151 -68000 -1.526% pack 2435040 2398072 -36968 -1.518% pprof 13804080 13565808 -238272 -1.726% test2json 2690043 2645987 -44056 -1.638% trace 10418492 10232716 -185776 -1.783% vet 7258259 7121259 -137000 -1.888% total 113145867 111204202 -1941665 -1.716% The situation on linux/arm64 is as follow: name old time/op new time/op delta Template 280ms ± 1% 282ms ± 1% +0.75% (p=0.000 n=46+48) Unicode 124ms ± 2% 124ms ± 2% +0.37% (p=0.045 n=50+50) GoTypes 1.69s ± 1% 1.70s ± 1% +0.56% (p=0.000 n=49+50) Compiler 122ms ± 1% 123ms ± 1% +0.93% (p=0.000 n=50+50) SSA 12.6s ± 1% 12.7s ± 0% +0.72% (p=0.000 n=50+50) Flate 170ms ± 1% 172ms ± 1% +0.97% (p=0.000 n=49+49) GoParser 262ms ± 1% 263ms ± 1% +0.39% (p=0.000 n=49+48) Reflect 639ms ± 1% 650ms ± 1% +1.63% (p=0.000 n=49+49) Tar 243ms ± 1% 245ms ± 1% +0.82% (p=0.000 n=50+50) XML 324ms ± 1% 327ms ± 1% +0.72% (p=0.000 n=50+49) LinkCompiler 597ms ± 1% 596ms ± 1% -0.27% (p=0.001 n=48+47) ExternalLinkCompiler 1.90s ± 1% 1.88s ± 1% -1.00% (p=0.000 n=50+50) LinkWithoutDebugCompiler 364ms ± 1% 363ms ± 1% ~ (p=0.220 n=49+50) [Geo mean] 485ms 488ms +0.49% name old alloc/op new alloc/op delta Template 38.7MB ± 0% 38.8MB ± 1% ~ (p=0.093 n=43+49) Unicode 28.4MB ± 0% 28.4MB ± 0% +0.03% (p=0.000 n=49+45) GoTypes 169MB ± 1% 169MB ± 1% +0.23% (p=0.010 n=50+50) Compiler 23.2MB ± 1% 23.2MB ± 1% +0.11% (p=0.000 n=40+44) SSA 1.54GB ± 0% 1.55GB ± 0% +0.45% (p=0.000 n=47+49) Flate 23.8MB ± 2% 23.8MB ± 1% ~ (p=0.543 n=50+50) GoParser 35.3MB ± 1% 35.4MB ± 1% ~ (p=0.792 n=50+50) Reflect 85.2MB ± 1% 85.2MB ± 0% ~ (p=0.055 n=50+47) Tar 34.5MB ± 1% 34.5MB ± 1% +0.06% (p=0.015 n=50+50) XML 43.8MB ± 2% 43.9MB ± 2% +0.19% (p=0.000 n=48+48) LinkCompiler 137MB ± 0% 136MB ± 0% -0.92% (p=0.000 n=50+50) ExternalLinkCompiler 127MB ± 0% 127MB ± 0% ~ (p=0.516 n=50+50) LinkWithoutDebugCompiler 84.0MB ± 0% 84.0MB ± 0% ~ (p=0.057 n=50+50) [Geo mean] 70.4MB 70.4MB +0.01% file before after Δ % addr2line 4021557 4002933 -18624 -0.463% api 5127847 5028503 -99344 -1.937% asm 5034716 4936836 -97880 -1.944% buildid 2608118 2594094 -14024 -0.538% cgo 4488592 4398320 -90272 -2.011% compile 22501129 22213592 -287537 -1.278% cover 4742301 4713573 -28728 -0.606% dist 3388071 3365311 -22760 -0.672% doc 3802250 3776082 -26168 -0.688% fix 3306147 3216939 -89208 -2.698% link 6404483 6363699 -40784 -0.637% nm 3941026 3921930 -19096 -0.485% objdump 4383330 4295122 -88208 -2.012% pack 2404547 2389515 -15032 -0.625% pprof 12996234 12856818 -139416 -1.073% test2json 2668500 2586788 -81712 -3.062% trace 9816276 9609580 -206696 -2.106% vet 6900682 6787338 -113344 -1.643% total 108535806 107056973 -1478833 -1.363% Change-Id: Iaec1cdcaacca8025e9babb0fb8a532fddb70c87d Reviewed-on: https://go-review.googlesource.com/c/go/+/255239 Reviewed-by: eric fang <eric.fang@arm.com> Reviewed-by: Keith Randall <khr@golang.org> Trust: eric fang <eric.fang@arm.com>
2020-07-23 10:24:56 +08:00
s.blockOrder = make([]int32, f.NumBlocks())
for i, b := range s.visitOrder {
cmd/compile: use depth first topological sort algorithm for layout The current layout algorithm tries to put consecutive blocks together, so the priority of the successor block is higher than the priority of the zero indegree block. This algorithm is beneficial for subsequent register allocation, but will result in more branch instructions. The depth-first topological sorting algorithm is a well-known layout algorithm, which has applications in many languages, and it helps to reduce branch instructions. This CL applies it to the layout pass. The test results show that it helps to reduce the code size. This CL also includes the following changes: 1, Removed the primary predecessor mechanism. The new layout algorithm is not very friendly to register allocator in some cases, in order to adapt to the new layout algorithm, a new primary predecessor selection strategy is introduced. 2, Since the new layout implementation may place non-loop blocks between loop blocks, some adaptive modifications have also been made to looprotate pass. 3, The layout also affects the results of codegen, so this CL also adjusted several codegen tests accordingly. It is inevitable that this CL will cause the code size or performance of a few functions to decrease, but the number of cases it improves is much larger than the number of cases it drops. Statistical data from compilecmp on linux/amd64 is as follow: name old time/op new time/op delta Template 382ms ± 4% 382ms ± 4% ~ (p=0.497 n=49+50) Unicode 170ms ± 9% 169ms ± 8% ~ (p=0.344 n=48+50) GoTypes 2.01s ± 4% 2.01s ± 4% ~ (p=0.628 n=50+48) Compiler 190ms ±10% 189ms ± 9% ~ (p=0.734 n=50+50) SSA 11.8s ± 2% 11.8s ± 3% ~ (p=0.877 n=50+50) Flate 241ms ± 9% 241ms ± 8% ~ (p=0.897 n=50+49) GoParser 366ms ± 3% 361ms ± 4% -1.21% (p=0.004 n=47+50) Reflect 835ms ± 3% 838ms ± 3% ~ (p=0.275 n=50+49) Tar 336ms ± 4% 335ms ± 3% ~ (p=0.454 n=48+48) XML 433ms ± 4% 431ms ± 3% ~ (p=0.071 n=49+48) LinkCompiler 706ms ± 4% 705ms ± 4% ~ (p=0.608 n=50+49) ExternalLinkCompiler 1.85s ± 3% 1.83s ± 2% -1.47% (p=0.000 n=49+48) LinkWithoutDebugCompiler 437ms ± 5% 437ms ± 6% ~ (p=0.953 n=49+50) [Geo mean] 615ms 613ms -0.37% name old alloc/op new alloc/op delta Template 38.7MB ± 1% 38.7MB ± 1% ~ (p=0.834 n=50+50) Unicode 28.1MB ± 0% 28.1MB ± 0% -0.22% (p=0.000 n=49+50) GoTypes 168MB ± 1% 168MB ± 1% ~ (p=0.054 n=47+47) Compiler 23.0MB ± 1% 23.0MB ± 1% ~ (p=0.432 n=50+50) SSA 1.54GB ± 0% 1.54GB ± 0% +0.21% (p=0.000 n=50+50) Flate 23.6MB ± 1% 23.6MB ± 1% ~ (p=0.153 n=43+46) GoParser 35.1MB ± 1% 35.1MB ± 2% ~ (p=0.202 n=50+50) Reflect 84.7MB ± 1% 84.7MB ± 1% ~ (p=0.333 n=48+49) Tar 34.5MB ± 1% 34.5MB ± 1% ~ (p=0.406 n=46+49) XML 44.3MB ± 2% 44.2MB ± 3% ~ (p=0.981 n=50+50) LinkCompiler 131MB ± 0% 128MB ± 0% -2.74% (p=0.000 n=50+50) ExternalLinkCompiler 120MB ± 0% 120MB ± 0% +0.01% (p=0.007 n=50+50) LinkWithoutDebugCompiler 77.3MB ± 0% 77.3MB ± 0% -0.02% (p=0.000 n=50+50) [Geo mean] 69.3MB 69.1MB -0.22% file before after Δ % addr2line 4104220 4043684 -60536 -1.475% api 5342502 5249678 -92824 -1.737% asm 4973785 4858257 -115528 -2.323% buildid 2667844 2625660 -42184 -1.581% cgo 4686849 4616313 -70536 -1.505% compile 23667431 23268406 -399025 -1.686% cover 4959676 4874108 -85568 -1.725% dist 3515934 3450422 -65512 -1.863% doc 3995581 3925469 -70112 -1.755% fix 3379202 3318522 -60680 -1.796% link 6743249 6629913 -113336 -1.681% nm 4047529 3991777 -55752 -1.377% objdump 4456151 4388151 -68000 -1.526% pack 2435040 2398072 -36968 -1.518% pprof 13804080 13565808 -238272 -1.726% test2json 2690043 2645987 -44056 -1.638% trace 10418492 10232716 -185776 -1.783% vet 7258259 7121259 -137000 -1.888% total 113145867 111204202 -1941665 -1.716% The situation on linux/arm64 is as follow: name old time/op new time/op delta Template 280ms ± 1% 282ms ± 1% +0.75% (p=0.000 n=46+48) Unicode 124ms ± 2% 124ms ± 2% +0.37% (p=0.045 n=50+50) GoTypes 1.69s ± 1% 1.70s ± 1% +0.56% (p=0.000 n=49+50) Compiler 122ms ± 1% 123ms ± 1% +0.93% (p=0.000 n=50+50) SSA 12.6s ± 1% 12.7s ± 0% +0.72% (p=0.000 n=50+50) Flate 170ms ± 1% 172ms ± 1% +0.97% (p=0.000 n=49+49) GoParser 262ms ± 1% 263ms ± 1% +0.39% (p=0.000 n=49+48) Reflect 639ms ± 1% 650ms ± 1% +1.63% (p=0.000 n=49+49) Tar 243ms ± 1% 245ms ± 1% +0.82% (p=0.000 n=50+50) XML 324ms ± 1% 327ms ± 1% +0.72% (p=0.000 n=50+49) LinkCompiler 597ms ± 1% 596ms ± 1% -0.27% (p=0.001 n=48+47) ExternalLinkCompiler 1.90s ± 1% 1.88s ± 1% -1.00% (p=0.000 n=50+50) LinkWithoutDebugCompiler 364ms ± 1% 363ms ± 1% ~ (p=0.220 n=49+50) [Geo mean] 485ms 488ms +0.49% name old alloc/op new alloc/op delta Template 38.7MB ± 0% 38.8MB ± 1% ~ (p=0.093 n=43+49) Unicode 28.4MB ± 0% 28.4MB ± 0% +0.03% (p=0.000 n=49+45) GoTypes 169MB ± 1% 169MB ± 1% +0.23% (p=0.010 n=50+50) Compiler 23.2MB ± 1% 23.2MB ± 1% +0.11% (p=0.000 n=40+44) SSA 1.54GB ± 0% 1.55GB ± 0% +0.45% (p=0.000 n=47+49) Flate 23.8MB ± 2% 23.8MB ± 1% ~ (p=0.543 n=50+50) GoParser 35.3MB ± 1% 35.4MB ± 1% ~ (p=0.792 n=50+50) Reflect 85.2MB ± 1% 85.2MB ± 0% ~ (p=0.055 n=50+47) Tar 34.5MB ± 1% 34.5MB ± 1% +0.06% (p=0.015 n=50+50) XML 43.8MB ± 2% 43.9MB ± 2% +0.19% (p=0.000 n=48+48) LinkCompiler 137MB ± 0% 136MB ± 0% -0.92% (p=0.000 n=50+50) ExternalLinkCompiler 127MB ± 0% 127MB ± 0% ~ (p=0.516 n=50+50) LinkWithoutDebugCompiler 84.0MB ± 0% 84.0MB ± 0% ~ (p=0.057 n=50+50) [Geo mean] 70.4MB 70.4MB +0.01% file before after Δ % addr2line 4021557 4002933 -18624 -0.463% api 5127847 5028503 -99344 -1.937% asm 5034716 4936836 -97880 -1.944% buildid 2608118 2594094 -14024 -0.538% cgo 4488592 4398320 -90272 -2.011% compile 22501129 22213592 -287537 -1.278% cover 4742301 4713573 -28728 -0.606% dist 3388071 3365311 -22760 -0.672% doc 3802250 3776082 -26168 -0.688% fix 3306147 3216939 -89208 -2.698% link 6404483 6363699 -40784 -0.637% nm 3941026 3921930 -19096 -0.485% objdump 4383330 4295122 -88208 -2.012% pack 2404547 2389515 -15032 -0.625% pprof 12996234 12856818 -139416 -1.073% test2json 2668500 2586788 -81712 -3.062% trace 9816276 9609580 -206696 -2.106% vet 6900682 6787338 -113344 -1.643% total 108535806 107056973 -1478833 -1.363% Change-Id: Iaec1cdcaacca8025e9babb0fb8a532fddb70c87d Reviewed-on: https://go-review.googlesource.com/c/go/+/255239 Reviewed-by: eric fang <eric.fang@arm.com> Reviewed-by: Keith Randall <khr@golang.org> Trust: eric fang <eric.fang@arm.com>
2020-07-23 10:24:56 +08:00
s.blockOrder[b.ID] = int32(i)
}
s.regs = make([]regState, s.numRegs)
cmd/compile: re-use regalloc's []valState Updates #27739: reduces package ssa's allocated space by 3.77%. maxrss is harder to measure, but using best-of-three-runs as reported by /usr/bin/time -l, I see ~2% reduction in maxrss. We still have a long way to go, though; the new maxrss is still 1.1gb. name old alloc/op new alloc/op delta Template 38.8MB ± 0% 37.7MB ± 0% -2.77% (p=0.008 n=5+5) Unicode 28.2MB ± 0% 28.1MB ± 0% -0.20% (p=0.008 n=5+5) GoTypes 131MB ± 0% 127MB ± 0% -2.94% (p=0.008 n=5+5) Compiler 606MB ± 0% 587MB ± 0% -3.21% (p=0.008 n=5+5) SSA 2.14GB ± 0% 2.06GB ± 0% -3.77% (p=0.008 n=5+5) Flate 24.0MB ± 0% 23.3MB ± 0% -3.00% (p=0.008 n=5+5) GoParser 28.8MB ± 0% 28.1MB ± 0% -2.61% (p=0.008 n=5+5) Reflect 83.8MB ± 0% 81.5MB ± 0% -2.71% (p=0.008 n=5+5) Tar 36.4MB ± 0% 35.4MB ± 0% -2.73% (p=0.008 n=5+5) XML 47.9MB ± 0% 46.7MB ± 0% -2.49% (p=0.008 n=5+5) [Geo mean] 84.6MB 82.4MB -2.65% name old allocs/op new allocs/op delta Template 379k ± 0% 379k ± 0% -0.05% (p=0.008 n=5+5) Unicode 340k ± 0% 340k ± 0% ~ (p=0.151 n=5+5) GoTypes 1.36M ± 0% 1.36M ± 0% -0.06% (p=0.008 n=5+5) Compiler 5.49M ± 0% 5.48M ± 0% -0.03% (p=0.008 n=5+5) SSA 17.5M ± 0% 17.5M ± 0% -0.03% (p=0.008 n=5+5) Flate 235k ± 0% 235k ± 0% -0.04% (p=0.008 n=5+5) GoParser 302k ± 0% 302k ± 0% -0.04% (p=0.008 n=5+5) Reflect 976k ± 0% 975k ± 0% -0.10% (p=0.008 n=5+5) Tar 352k ± 0% 352k ± 0% -0.06% (p=0.008 n=5+5) XML 436k ± 0% 436k ± 0% -0.03% (p=0.008 n=5+5) [Geo mean] 842k 841k -0.04% Change-Id: I0ab6631b5a0bb6303c291dcb0367b586a4e584fb Reviewed-on: https://go-review.googlesource.com/c/go/+/176221 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2019-05-09 11:31:04 -07:00
nv := f.NumValues()
if cap(s.f.Cache.regallocValues) >= nv {
s.f.Cache.regallocValues = s.f.Cache.regallocValues[:nv]
} else {
s.f.Cache.regallocValues = make([]valState, nv)
}
s.values = s.f.Cache.regallocValues
s.orig = s.f.Cache.allocValueSlice(nv)
cmd/compile: move value around before kick it out of register When allocating registers, before kicking out the existing value, copy it to a spare register if there is one. So later use of this value can be found in register instead of reload from spill. This is very helpful for instructions of which the input and/or output can only be in specific registers, e.g. DIV on x86, MUL/DIV on MIPS. May also be helpful in general. For "go build -a cmd/go" on AMD64, reduce "spilled value remains" by 1% (not including args, which almost certainly remain). For the code in issue #16061 on AMD64: MaxRem-12 111µs ± 1% 94µs ± 0% -15.38% (p=0.008 n=5+5) Go1 benchmark on AMD64: BinaryTree17-12 2.32s ± 2% 2.30s ± 1% ~ (p=0.421 n=5+5) Fannkuch11-12 2.52s ± 0% 2.44s ± 0% -3.44% (p=0.008 n=5+5) FmtFprintfEmpty-12 39.9ns ± 3% 39.8ns ± 0% ~ (p=0.635 n=5+4) FmtFprintfString-12 114ns ± 1% 113ns ± 1% ~ (p=0.905 n=5+5) FmtFprintfInt-12 102ns ± 6% 98ns ± 1% ~ (p=0.087 n=5+5) FmtFprintfIntInt-12 146ns ± 5% 147ns ± 1% ~ (p=0.238 n=5+5) FmtFprintfPrefixedInt-12 155ns ± 2% 151ns ± 1% -2.58% (p=0.008 n=5+5) FmtFprintfFloat-12 231ns ± 1% 232ns ± 1% ~ (p=0.286 n=5+5) FmtManyArgs-12 657ns ± 1% 649ns ± 0% -1.31% (p=0.008 n=5+5) GobDecode-12 6.35ms ± 0% 6.29ms ± 1% ~ (p=0.056 n=5+5) GobEncode-12 5.38ms ± 1% 5.45ms ± 1% ~ (p=0.056 n=5+5) Gzip-12 209ms ± 0% 209ms ± 1% ~ (p=0.690 n=5+5) Gunzip-12 31.2ms ± 1% 31.1ms ± 1% ~ (p=0.548 n=5+5) HTTPClientServer-12 123µs ± 4% 130µs ± 8% ~ (p=0.151 n=5+5) JSONEncode-12 14.0ms ± 1% 14.0ms ± 1% ~ (p=0.421 n=5+5) JSONDecode-12 41.2ms ± 1% 41.1ms ± 2% ~ (p=0.421 n=5+5) Mandelbrot200-12 3.96ms ± 1% 3.98ms ± 0% ~ (p=0.421 n=5+5) GoParse-12 2.88ms ± 1% 2.88ms ± 1% ~ (p=0.841 n=5+5) RegexpMatchEasy0_32-12 68.0ns ± 3% 66.6ns ± 1% -2.00% (p=0.024 n=5+5) RegexpMatchEasy0_1K-12 728ns ± 8% 682ns ± 1% -6.26% (p=0.008 n=5+5) RegexpMatchEasy1_32-12 66.8ns ± 2% 66.0ns ± 1% ~ (p=0.302 n=5+5) RegexpMatchEasy1_1K-12 291ns ± 2% 288ns ± 1% ~ (p=0.111 n=5+5) RegexpMatchMedium_32-12 103ns ± 2% 100ns ± 0% -2.53% (p=0.016 n=5+4) RegexpMatchMedium_1K-12 31.9µs ± 1% 31.3µs ± 0% -1.75% (p=0.008 n=5+5) RegexpMatchHard_32-12 1.59µs ± 2% 1.59µs ± 1% ~ (p=0.548 n=5+5) RegexpMatchHard_1K-12 48.3µs ± 2% 47.7µs ± 1% ~ (p=0.222 n=5+5) Revcomp-12 340ms ± 1% 338ms ± 1% ~ (p=0.421 n=5+5) Template-12 46.3ms ± 1% 46.5ms ± 1% ~ (p=0.690 n=5+5) TimeParse-12 252ns ± 1% 247ns ± 0% -1.91% (p=0.000 n=5+4) TimeFormat-12 277ns ± 1% 267ns ± 0% -3.82% (p=0.008 n=5+5) [Geo mean] 48.8µs 48.3µs -0.93% It has very little effect on binary size and compiler speed. compilebench: Template 230ms ±10% 231ms ± 8% ~ (p=0.546 n=9+9) Unicode 123ms ± 6% 124ms ± 9% ~ (p=0.481 n=10+10) GoTypes 742ms ± 6% 755ms ± 3% ~ (p=0.123 n=10+10) Compiler 3.10s ± 3% 3.08s ± 1% ~ (p=0.631 n=10+10) Fixes #16061. Change-Id: Id99cdc7a182ee10a704fa0f04e8e0d0809b2ac56 Reviewed-on: https://go-review.googlesource.com/29732 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2016-09-23 09:15:51 -04:00
s.copies = make(map[*Value]bool)
for _, b := range s.visitOrder {
for _, v := range b.Values {
if v.needRegister() {
s.values[v.ID].needReg = true
s.values[v.ID].rematerializeable = v.rematerializeable()
s.orig[v.ID] = v
}
// Note: needReg is false for values returning Tuple types.
// Instead, we mark the corresponding Selects as needReg.
}
}
s.computeLive()
s.endRegs = make([][]endReg, f.NumBlocks())
s.startRegs = make([][]startReg, f.NumBlocks())
s.spillLive = make([][]ID, f.NumBlocks())
s.sdom = f.Sdom()
cmd/compile: add wasm stack optimization 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>
2018-03-09 00:14:58 +01:00
// wasm: Mark instructions that can be optimized to have their values only on the WebAssembly stack.
if f.Config.ctxt.Arch.Arch == sys.ArchWasm {
canLiveOnStack := f.newSparseSet(f.NumValues())
defer f.retSparseSet(canLiveOnStack)
for _, b := range f.Blocks {
// New block. Clear candidate set.
canLiveOnStack.clear()
cmd/compile: allow multiple SSA block control values Control values are used to choose which successor of a block is jumped to. Typically a control value takes the form of a 'flags' value that represents the result of a comparison. Some architectures however use a variable in a register as a control value. Up until now we have managed with a single control value per block. However some architectures (e.g. s390x and riscv64) have combined compare-and-branch instructions that take two variables in registers as parameters. To generate these instructions we need to support 2 control values per block. This CL allows up to 2 control values to be used in a block in order to support the addition of compare-and-branch instructions. I have implemented s390x compare-and-branch instructions in a different CL. Passes toolstash-check -all. Results of compilebench: name old time/op new time/op delta Template 208ms ± 1% 209ms ± 1% ~ (p=0.289 n=20+20) Unicode 83.7ms ± 1% 83.3ms ± 3% -0.49% (p=0.017 n=18+18) GoTypes 748ms ± 1% 748ms ± 0% ~ (p=0.460 n=20+18) Compiler 3.47s ± 1% 3.48s ± 1% ~ (p=0.070 n=19+18) SSA 11.5s ± 1% 11.7s ± 1% +1.64% (p=0.000 n=19+18) Flate 130ms ± 1% 130ms ± 1% ~ (p=0.588 n=19+20) GoParser 160ms ± 1% 161ms ± 1% ~ (p=0.211 n=20+20) Reflect 465ms ± 1% 467ms ± 1% +0.42% (p=0.007 n=20+20) Tar 184ms ± 1% 185ms ± 2% ~ (p=0.087 n=18+20) XML 253ms ± 1% 253ms ± 1% ~ (p=0.377 n=20+18) LinkCompiler 769ms ± 2% 774ms ± 2% ~ (p=0.070 n=19+19) ExternalLinkCompiler 3.59s ±11% 3.68s ± 6% ~ (p=0.072 n=20+20) LinkWithoutDebugCompiler 446ms ± 5% 454ms ± 3% +1.79% (p=0.002 n=19+20) StdCmd 26.0s ± 2% 26.0s ± 2% ~ (p=0.799 n=20+20) name old user-time/op new user-time/op delta Template 238ms ± 5% 240ms ± 5% ~ (p=0.142 n=20+20) Unicode 105ms ±11% 106ms ±10% ~ (p=0.512 n=20+20) GoTypes 876ms ± 2% 873ms ± 4% ~ (p=0.647 n=20+19) Compiler 4.17s ± 2% 4.19s ± 1% ~ (p=0.093 n=20+18) SSA 13.9s ± 1% 14.1s ± 1% +1.45% (p=0.000 n=18+18) Flate 145ms ±13% 146ms ± 5% ~ (p=0.851 n=20+18) GoParser 185ms ± 5% 188ms ± 7% ~ (p=0.174 n=20+20) Reflect 534ms ± 3% 538ms ± 2% ~ (p=0.105 n=20+18) Tar 215ms ± 4% 211ms ± 9% ~ (p=0.079 n=19+20) XML 295ms ± 6% 295ms ± 5% ~ (p=0.968 n=20+20) LinkCompiler 832ms ± 4% 837ms ± 7% ~ (p=0.707 n=17+20) ExternalLinkCompiler 1.58s ± 8% 1.60s ± 4% ~ (p=0.296 n=20+19) LinkWithoutDebugCompiler 478ms ±12% 489ms ±10% ~ (p=0.429 n=20+20) name old object-bytes new object-bytes delta Template 559kB ± 0% 559kB ± 0% ~ (all equal) Unicode 216kB ± 0% 216kB ± 0% ~ (all equal) GoTypes 2.03MB ± 0% 2.03MB ± 0% ~ (all equal) Compiler 8.07MB ± 0% 8.07MB ± 0% -0.06% (p=0.000 n=20+20) SSA 27.1MB ± 0% 27.3MB ± 0% +0.89% (p=0.000 n=20+20) Flate 343kB ± 0% 343kB ± 0% ~ (all equal) GoParser 441kB ± 0% 441kB ± 0% ~ (all equal) Reflect 1.36MB ± 0% 1.36MB ± 0% ~ (all equal) Tar 487kB ± 0% 487kB ± 0% ~ (all equal) XML 632kB ± 0% 632kB ± 0% ~ (all equal) name old export-bytes new export-bytes delta Template 18.5kB ± 0% 18.5kB ± 0% ~ (all equal) Unicode 7.92kB ± 0% 7.92kB ± 0% ~ (all equal) GoTypes 35.0kB ± 0% 35.0kB ± 0% ~ (all equal) Compiler 109kB ± 0% 110kB ± 0% +0.72% (p=0.000 n=20+20) SSA 137kB ± 0% 138kB ± 0% +0.58% (p=0.000 n=20+20) Flate 4.89kB ± 0% 4.89kB ± 0% ~ (all equal) GoParser 8.49kB ± 0% 8.49kB ± 0% ~ (all equal) Reflect 11.4kB ± 0% 11.4kB ± 0% ~ (all equal) Tar 10.5kB ± 0% 10.5kB ± 0% ~ (all equal) XML 16.7kB ± 0% 16.7kB ± 0% ~ (all equal) name old text-bytes new text-bytes delta HelloSize 761kB ± 0% 761kB ± 0% ~ (all equal) CmdGoSize 10.8MB ± 0% 10.8MB ± 0% ~ (all equal) name old data-bytes new data-bytes delta HelloSize 10.7kB ± 0% 10.7kB ± 0% ~ (all equal) CmdGoSize 312kB ± 0% 312kB ± 0% ~ (all equal) name old bss-bytes new bss-bytes delta HelloSize 122kB ± 0% 122kB ± 0% ~ (all equal) CmdGoSize 146kB ± 0% 146kB ± 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 1.13MB ± 0% 1.13MB ± 0% ~ (all equal) CmdGoSize 15.1MB ± 0% 15.1MB ± 0% ~ (all equal) Change-Id: I3cc2f9829a109543d9a68be4a21775d2d3e9801f Reviewed-on: https://go-review.googlesource.com/c/go/+/196557 Run-TryBot: Michael Munday <mike.munday@ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Keith Randall <khr@golang.org>
2019-08-12 20:19:58 +01:00
for _, c := range b.ControlValues() {
if c.Uses == 1 && !opcodeTable[c.Op].generic {
canLiveOnStack.add(c.ID)
}
cmd/compile: add wasm stack optimization 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>
2018-03-09 00:14:58 +01:00
}
// Walking backwards.
for i := len(b.Values) - 1; i >= 0; i-- {
v := b.Values[i]
if canLiveOnStack.contains(v.ID) {
v.OnWasmStack = true
} else {
// Value can not live on stack. Values are not allowed to be reordered, so clear candidate set.
canLiveOnStack.clear()
}
for _, arg := range v.Args {
// Value can live on the stack if:
// - it is only used once
// - it is used in the same basic block
// - it is not a "mem" value
// - it is a WebAssembly op
if arg.Uses == 1 && arg.Block == v.Block && !arg.Type.IsMemory() && !opcodeTable[arg.Op].generic {
canLiveOnStack.add(arg.ID)
}
}
}
}
}
// The clobberdeadreg experiment inserts code to clobber dead registers
// at call sites.
// Ignore huge functions to avoid doing too much work.
if base.Flag.ClobberDeadReg && len(s.f.Blocks) <= 10000 {
// TODO: honor GOCLOBBERDEADHASH, or maybe GOSSAHASH.
s.doClobber = true
}
}
func (s *regAllocState) close() {
s.f.Cache.freeValueSlice(s.orig)
}
// Adds a use record for id at distance dist from the start of the block.
// All calls to addUse must happen with nonincreasing dist.
2016-12-15 17:17:01 -08:00
func (s *regAllocState) addUse(id ID, dist int32, pos src.XPos) {
r := s.freeUseRecords
if r != nil {
s.freeUseRecords = r.next
} else {
r = &use{}
}
r.dist = dist
r.pos = pos
r.next = s.values[id].uses
s.values[id].uses = r
if r.next != nil && dist > r.next.dist {
s.f.Fatalf("uses added in wrong order")
}
}
// advanceUses advances the uses of v's args from the state before v to the state after v.
// Any values which have no more uses are deallocated from registers.
func (s *regAllocState) advanceUses(v *Value) {
for _, a := range v.Args {
if !s.values[a.ID].needReg {
continue
}
ai := &s.values[a.ID]
r := ai.uses
ai.uses = r.next
if r.next == nil || (!opcodeTable[a.Op].fixedReg && r.next.dist > s.nextCall[s.curIdx]) {
// Value is dead (or is not used again until after a call), free all registers that hold it.
s.freeRegs(ai.regs)
}
r.next = s.freeUseRecords
s.freeUseRecords = r
}
s.dropIfUnused(v)
}
// Drop v from registers if it isn't used again, or its only uses are after
// a call instruction.
func (s *regAllocState) dropIfUnused(v *Value) {
if !s.values[v.ID].needReg {
return
}
vi := &s.values[v.ID]
r := vi.uses
if r == nil || (!opcodeTable[v.Op].fixedReg && r.dist > s.nextCall[s.curIdx]) {
s.freeRegs(vi.regs)
}
}
// liveAfterCurrentInstruction reports whether v is live after
// the current instruction is completed. v must be used by the
// current instruction.
func (s *regAllocState) liveAfterCurrentInstruction(v *Value) bool {
u := s.values[v.ID].uses
if u == nil {
panic(fmt.Errorf("u is nil, v = %s, s.values[v.ID] = %v", v.LongString(), s.values[v.ID]))
}
d := u.dist
for u != nil && u.dist == d {
u = u.next
}
return u != nil && u.dist > d
}
// Sets the state of the registers to that encoded in regs.
func (s *regAllocState) setState(regs []endReg) {
cmd/compile: reimplement location list generation Completely redesign and reimplement location list generation to be more efficient, and hopefully not too hard to understand. RegKills are gone. Instead of using the regalloc's liveness calculations, redo them using the Ops' clobber information. Besides saving a lot of Values, this avoids adding RegKills to blocks that would be empty otherwise, which was messing up optimizations. This does mean that it's much harder to tell whether the generation process is buggy (there's nothing to cross-check it with), and there may be disagreements with GC liveness. But the performance gain is significant, and it's nice not to be messing with earlier compiler phases. The intermediate representations are gone. Instead of producing ssa.BlockDebugs, then dwarf.LocationLists, and then finally real location lists, go directly from the SSA to a (mostly) real location list. Because the SSA analysis happens before assembly, it stores encoded block/value IDs where PCs would normally go. It would be easier to do the SSA analysis after assembly, but I didn't want to retain the SSA just for that. Generation proceeds in two phases: first, it traverses the function in CFG order, storing the state of the block at the beginning and end. End states are used to produce the start states of the successor blocks. In the second phase, it traverses in program text order and produces the location lists. The processing in the second phase is redundant, but much cheaper than storing the intermediate representation. It might be possible to combine the two phases somewhat to take advantage of cases where the CFG matches the block layout, but I haven't tried. Location lists are finalized by adding a base address selection entry, translating each encoded block/value ID to a real PC, and adding the terminating zero entry. This probably won't work on OSX, where dsymutil will choke on the base address selection. I tried emitting CU-relative relocations for each address, and it was *very* bad for performance -- it uses more memory storing all the relocations than it does for the actual location list bytes. I think I'm going to end up synthesizing the relocations in the linker only on OSX, but TBD. TestNexting needs updating: with more optimizations working, the debugger doesn't stop on the continue (line 88) any more, and the test's duplicate suppression kicks in. Also, dx and dy live a little longer now, but they have the correct values. Change-Id: Ie772dfe23a4e389ca573624fac4d05401ae32307 Reviewed-on: https://go-review.googlesource.com/89356 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2017-10-26 15:40:17 -04:00
s.freeRegs(s.used)
for _, x := range regs {
s.assignReg(x.r, x.v, x.c)
}
}
// compatRegs returns the set of registers which can store a type t.
cmd/compile: change ssa.Type into *types.Type When package ssa was created, Type was in package gc. To avoid circular dependencies, we used an interface (ssa.Type) to represent type information in SSA. In the Go 1.9 cycle, gri extricated the Type type from package gc. As a result, we can now use it in package ssa. Now, instead of package types depending on package ssa, it is the other way. This is a more sensible dependency tree, and helps compiler performance a bit. Though this is a big CL, most of the changes are mechanical and uninteresting. Interesting bits: * Add new singleton globals to package types for the special SSA types Memory, Void, Invalid, Flags, and Int128. * Add two new Types, TSSA for the special types, and TTUPLE, for SSA tuple types. ssa.MakeTuple is now types.NewTuple. * Move type comparison result constants CMPlt, CMPeq, and CMPgt to package types. * We had picked the name "types" in our rules for the handy list of types provided by ssa.Config. That conflicted with the types package name, so change it to "typ". * Update the type comparison routine to handle tuples and special types inline. * Teach gc/fmt.go how to print special types. * We can now eliminate ElemTypes in favor of just Elem, and probably also some other duplicated Type methods designed to return ssa.Type instead of *types.Type. * The ssa tests were using their own dummy types, and they were not particularly careful about types in general. Of necessity, this CL switches them to use *types.Type; it does not make them more type-accurate. Unfortunately, using types.Type means initializing a bit of the types universe. This is prime for refactoring and improvement. This shrinks ssa.Value; it now fits in a smaller size class on 64 bit systems. This doesn't have a giant impact, though, since most Values are preallocated in a chunk. name old alloc/op new alloc/op delta Template 37.9MB ± 0% 37.7MB ± 0% -0.57% (p=0.000 n=10+8) Unicode 28.9MB ± 0% 28.7MB ± 0% -0.52% (p=0.000 n=10+10) GoTypes 110MB ± 0% 109MB ± 0% -0.88% (p=0.000 n=10+10) Flate 24.7MB ± 0% 24.6MB ± 0% -0.66% (p=0.000 n=10+10) GoParser 31.1MB ± 0% 30.9MB ± 0% -0.61% (p=0.000 n=10+9) Reflect 73.9MB ± 0% 73.4MB ± 0% -0.62% (p=0.000 n=10+8) Tar 25.8MB ± 0% 25.6MB ± 0% -0.77% (p=0.000 n=9+10) XML 41.2MB ± 0% 40.9MB ± 0% -0.80% (p=0.000 n=10+10) [Geo mean] 40.5MB 40.3MB -0.68% name old allocs/op new allocs/op delta Template 385k ± 0% 386k ± 0% ~ (p=0.356 n=10+9) Unicode 343k ± 1% 344k ± 0% ~ (p=0.481 n=10+10) GoTypes 1.16M ± 0% 1.16M ± 0% -0.16% (p=0.004 n=10+10) Flate 238k ± 1% 238k ± 1% ~ (p=0.853 n=10+10) GoParser 320k ± 0% 320k ± 0% ~ (p=0.720 n=10+9) Reflect 957k ± 0% 957k ± 0% ~ (p=0.460 n=10+8) Tar 252k ± 0% 252k ± 0% ~ (p=0.133 n=9+10) XML 400k ± 0% 400k ± 0% ~ (p=0.796 n=10+10) [Geo mean] 428k 428k -0.01% Removing all the interface calls helps non-trivially with CPU, though. name old time/op new time/op delta Template 178ms ± 4% 173ms ± 3% -2.90% (p=0.000 n=94+96) Unicode 85.0ms ± 4% 83.9ms ± 4% -1.23% (p=0.000 n=96+96) GoTypes 543ms ± 3% 528ms ± 3% -2.73% (p=0.000 n=98+96) Flate 116ms ± 3% 113ms ± 4% -2.34% (p=0.000 n=96+99) GoParser 144ms ± 3% 140ms ± 4% -2.80% (p=0.000 n=99+97) Reflect 344ms ± 3% 334ms ± 4% -3.02% (p=0.000 n=100+99) Tar 106ms ± 5% 103ms ± 4% -3.30% (p=0.000 n=98+94) XML 198ms ± 5% 192ms ± 4% -2.88% (p=0.000 n=92+95) [Geo mean] 178ms 173ms -2.65% name old user-time/op new user-time/op delta Template 229ms ± 5% 224ms ± 5% -2.36% (p=0.000 n=95+99) Unicode 107ms ± 6% 106ms ± 5% -1.13% (p=0.001 n=93+95) GoTypes 696ms ± 4% 679ms ± 4% -2.45% (p=0.000 n=97+99) Flate 137ms ± 4% 134ms ± 5% -2.66% (p=0.000 n=99+96) GoParser 176ms ± 5% 172ms ± 8% -2.27% (p=0.000 n=98+100) Reflect 430ms ± 6% 411ms ± 5% -4.46% (p=0.000 n=100+92) Tar 128ms ±13% 123ms ±13% -4.21% (p=0.000 n=100+100) XML 239ms ± 6% 233ms ± 6% -2.50% (p=0.000 n=95+97) [Geo mean] 220ms 213ms -2.76% Change-Id: I15c7d6268347f8358e75066dfdbd77db24e8d0c1 Reviewed-on: https://go-review.googlesource.com/42145 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2017-04-28 14:12:28 -07:00
func (s *regAllocState) compatRegs(t *types.Type) regMask {
var m regMask
cmd/compile: move value around before kick it out of register When allocating registers, before kicking out the existing value, copy it to a spare register if there is one. So later use of this value can be found in register instead of reload from spill. This is very helpful for instructions of which the input and/or output can only be in specific registers, e.g. DIV on x86, MUL/DIV on MIPS. May also be helpful in general. For "go build -a cmd/go" on AMD64, reduce "spilled value remains" by 1% (not including args, which almost certainly remain). For the code in issue #16061 on AMD64: MaxRem-12 111µs ± 1% 94µs ± 0% -15.38% (p=0.008 n=5+5) Go1 benchmark on AMD64: BinaryTree17-12 2.32s ± 2% 2.30s ± 1% ~ (p=0.421 n=5+5) Fannkuch11-12 2.52s ± 0% 2.44s ± 0% -3.44% (p=0.008 n=5+5) FmtFprintfEmpty-12 39.9ns ± 3% 39.8ns ± 0% ~ (p=0.635 n=5+4) FmtFprintfString-12 114ns ± 1% 113ns ± 1% ~ (p=0.905 n=5+5) FmtFprintfInt-12 102ns ± 6% 98ns ± 1% ~ (p=0.087 n=5+5) FmtFprintfIntInt-12 146ns ± 5% 147ns ± 1% ~ (p=0.238 n=5+5) FmtFprintfPrefixedInt-12 155ns ± 2% 151ns ± 1% -2.58% (p=0.008 n=5+5) FmtFprintfFloat-12 231ns ± 1% 232ns ± 1% ~ (p=0.286 n=5+5) FmtManyArgs-12 657ns ± 1% 649ns ± 0% -1.31% (p=0.008 n=5+5) GobDecode-12 6.35ms ± 0% 6.29ms ± 1% ~ (p=0.056 n=5+5) GobEncode-12 5.38ms ± 1% 5.45ms ± 1% ~ (p=0.056 n=5+5) Gzip-12 209ms ± 0% 209ms ± 1% ~ (p=0.690 n=5+5) Gunzip-12 31.2ms ± 1% 31.1ms ± 1% ~ (p=0.548 n=5+5) HTTPClientServer-12 123µs ± 4% 130µs ± 8% ~ (p=0.151 n=5+5) JSONEncode-12 14.0ms ± 1% 14.0ms ± 1% ~ (p=0.421 n=5+5) JSONDecode-12 41.2ms ± 1% 41.1ms ± 2% ~ (p=0.421 n=5+5) Mandelbrot200-12 3.96ms ± 1% 3.98ms ± 0% ~ (p=0.421 n=5+5) GoParse-12 2.88ms ± 1% 2.88ms ± 1% ~ (p=0.841 n=5+5) RegexpMatchEasy0_32-12 68.0ns ± 3% 66.6ns ± 1% -2.00% (p=0.024 n=5+5) RegexpMatchEasy0_1K-12 728ns ± 8% 682ns ± 1% -6.26% (p=0.008 n=5+5) RegexpMatchEasy1_32-12 66.8ns ± 2% 66.0ns ± 1% ~ (p=0.302 n=5+5) RegexpMatchEasy1_1K-12 291ns ± 2% 288ns ± 1% ~ (p=0.111 n=5+5) RegexpMatchMedium_32-12 103ns ± 2% 100ns ± 0% -2.53% (p=0.016 n=5+4) RegexpMatchMedium_1K-12 31.9µs ± 1% 31.3µs ± 0% -1.75% (p=0.008 n=5+5) RegexpMatchHard_32-12 1.59µs ± 2% 1.59µs ± 1% ~ (p=0.548 n=5+5) RegexpMatchHard_1K-12 48.3µs ± 2% 47.7µs ± 1% ~ (p=0.222 n=5+5) Revcomp-12 340ms ± 1% 338ms ± 1% ~ (p=0.421 n=5+5) Template-12 46.3ms ± 1% 46.5ms ± 1% ~ (p=0.690 n=5+5) TimeParse-12 252ns ± 1% 247ns ± 0% -1.91% (p=0.000 n=5+4) TimeFormat-12 277ns ± 1% 267ns ± 0% -3.82% (p=0.008 n=5+5) [Geo mean] 48.8µs 48.3µs -0.93% It has very little effect on binary size and compiler speed. compilebench: Template 230ms ±10% 231ms ± 8% ~ (p=0.546 n=9+9) Unicode 123ms ± 6% 124ms ± 9% ~ (p=0.481 n=10+10) GoTypes 742ms ± 6% 755ms ± 3% ~ (p=0.123 n=10+10) Compiler 3.10s ± 3% 3.08s ± 1% ~ (p=0.631 n=10+10) Fixes #16061. Change-Id: Id99cdc7a182ee10a704fa0f04e8e0d0809b2ac56 Reviewed-on: https://go-review.googlesource.com/29732 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2016-09-23 09:15:51 -04:00
if t.IsTuple() || t.IsFlags() {
return 0
}
if t.IsSIMD() {
if t.Size() > 8 {
return s.f.Config.fpRegMask & s.allocatable
} else {
// K mask
return s.f.Config.gpRegMask & s.allocatable
}
}
cmd/compile: change ssa.Type into *types.Type When package ssa was created, Type was in package gc. To avoid circular dependencies, we used an interface (ssa.Type) to represent type information in SSA. In the Go 1.9 cycle, gri extricated the Type type from package gc. As a result, we can now use it in package ssa. Now, instead of package types depending on package ssa, it is the other way. This is a more sensible dependency tree, and helps compiler performance a bit. Though this is a big CL, most of the changes are mechanical and uninteresting. Interesting bits: * Add new singleton globals to package types for the special SSA types Memory, Void, Invalid, Flags, and Int128. * Add two new Types, TSSA for the special types, and TTUPLE, for SSA tuple types. ssa.MakeTuple is now types.NewTuple. * Move type comparison result constants CMPlt, CMPeq, and CMPgt to package types. * We had picked the name "types" in our rules for the handy list of types provided by ssa.Config. That conflicted with the types package name, so change it to "typ". * Update the type comparison routine to handle tuples and special types inline. * Teach gc/fmt.go how to print special types. * We can now eliminate ElemTypes in favor of just Elem, and probably also some other duplicated Type methods designed to return ssa.Type instead of *types.Type. * The ssa tests were using their own dummy types, and they were not particularly careful about types in general. Of necessity, this CL switches them to use *types.Type; it does not make them more type-accurate. Unfortunately, using types.Type means initializing a bit of the types universe. This is prime for refactoring and improvement. This shrinks ssa.Value; it now fits in a smaller size class on 64 bit systems. This doesn't have a giant impact, though, since most Values are preallocated in a chunk. name old alloc/op new alloc/op delta Template 37.9MB ± 0% 37.7MB ± 0% -0.57% (p=0.000 n=10+8) Unicode 28.9MB ± 0% 28.7MB ± 0% -0.52% (p=0.000 n=10+10) GoTypes 110MB ± 0% 109MB ± 0% -0.88% (p=0.000 n=10+10) Flate 24.7MB ± 0% 24.6MB ± 0% -0.66% (p=0.000 n=10+10) GoParser 31.1MB ± 0% 30.9MB ± 0% -0.61% (p=0.000 n=10+9) Reflect 73.9MB ± 0% 73.4MB ± 0% -0.62% (p=0.000 n=10+8) Tar 25.8MB ± 0% 25.6MB ± 0% -0.77% (p=0.000 n=9+10) XML 41.2MB ± 0% 40.9MB ± 0% -0.80% (p=0.000 n=10+10) [Geo mean] 40.5MB 40.3MB -0.68% name old allocs/op new allocs/op delta Template 385k ± 0% 386k ± 0% ~ (p=0.356 n=10+9) Unicode 343k ± 1% 344k ± 0% ~ (p=0.481 n=10+10) GoTypes 1.16M ± 0% 1.16M ± 0% -0.16% (p=0.004 n=10+10) Flate 238k ± 1% 238k ± 1% ~ (p=0.853 n=10+10) GoParser 320k ± 0% 320k ± 0% ~ (p=0.720 n=10+9) Reflect 957k ± 0% 957k ± 0% ~ (p=0.460 n=10+8) Tar 252k ± 0% 252k ± 0% ~ (p=0.133 n=9+10) XML 400k ± 0% 400k ± 0% ~ (p=0.796 n=10+10) [Geo mean] 428k 428k -0.01% Removing all the interface calls helps non-trivially with CPU, though. name old time/op new time/op delta Template 178ms ± 4% 173ms ± 3% -2.90% (p=0.000 n=94+96) Unicode 85.0ms ± 4% 83.9ms ± 4% -1.23% (p=0.000 n=96+96) GoTypes 543ms ± 3% 528ms ± 3% -2.73% (p=0.000 n=98+96) Flate 116ms ± 3% 113ms ± 4% -2.34% (p=0.000 n=96+99) GoParser 144ms ± 3% 140ms ± 4% -2.80% (p=0.000 n=99+97) Reflect 344ms ± 3% 334ms ± 4% -3.02% (p=0.000 n=100+99) Tar 106ms ± 5% 103ms ± 4% -3.30% (p=0.000 n=98+94) XML 198ms ± 5% 192ms ± 4% -2.88% (p=0.000 n=92+95) [Geo mean] 178ms 173ms -2.65% name old user-time/op new user-time/op delta Template 229ms ± 5% 224ms ± 5% -2.36% (p=0.000 n=95+99) Unicode 107ms ± 6% 106ms ± 5% -1.13% (p=0.001 n=93+95) GoTypes 696ms ± 4% 679ms ± 4% -2.45% (p=0.000 n=97+99) Flate 137ms ± 4% 134ms ± 5% -2.66% (p=0.000 n=99+96) GoParser 176ms ± 5% 172ms ± 8% -2.27% (p=0.000 n=98+100) Reflect 430ms ± 6% 411ms ± 5% -4.46% (p=0.000 n=100+92) Tar 128ms ±13% 123ms ±13% -4.21% (p=0.000 n=100+100) XML 239ms ± 6% 233ms ± 6% -2.50% (p=0.000 n=95+97) [Geo mean] 220ms 213ms -2.76% Change-Id: I15c7d6268347f8358e75066dfdbd77db24e8d0c1 Reviewed-on: https://go-review.googlesource.com/42145 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2017-04-28 14:12:28 -07:00
if t.IsFloat() || t == types.TypeInt128 {
if t.Kind() == types.TFLOAT32 && s.f.Config.fp32RegMask != 0 {
m = s.f.Config.fp32RegMask
} else if t.Kind() == types.TFLOAT64 && s.f.Config.fp64RegMask != 0 {
m = s.f.Config.fp64RegMask
} else {
m = s.f.Config.fpRegMask
}
} else {
m = s.f.Config.gpRegMask
}
return m & s.allocatable
}
// regspec returns the regInfo for operation op.
func (s *regAllocState) regspec(v *Value) regInfo {
op := v.Op
if op == OpConvert {
// OpConvert is a generic op, so it doesn't have a
// register set in the static table. It can use any
// allocatable integer register.
m := s.allocatable & s.f.Config.gpRegMask
return regInfo{inputs: []inputInfo{{regs: m}}, outputs: []outputInfo{{regs: m}}}
}
if op == OpArgIntReg {
reg := v.Block.Func.Config.intParamRegs[v.AuxInt8()]
return regInfo{outputs: []outputInfo{{regs: 1 << uint(reg)}}}
}
if op == OpArgFloatReg {
reg := v.Block.Func.Config.floatParamRegs[v.AuxInt8()]
return regInfo{outputs: []outputInfo{{regs: 1 << uint(reg)}}}
}
if op.IsCall() {
if ac, ok := v.Aux.(*AuxCall); ok && ac.reg != nil {
return *ac.Reg(&opcodeTable[op].reg, s.f.Config)
}
}
if op == OpMakeResult && s.f.OwnAux.reg != nil {
return *s.f.OwnAux.ResultReg(s.f.Config)
}
return opcodeTable[op].reg
}
func (s *regAllocState) isGReg(r register) bool {
return s.f.Config.hasGReg && s.GReg == r
}
// Dummy value used to represent the value being held in a temporary register.
var tmpVal Value
func (s *regAllocState) regalloc(f *Func) {
cmd/compile: improve startRegs calculation In register allocation, we calculate what values are used in and after the current block. If a value is used only after a function call, since registers are clobbered in call, we don't need to mark the value live at the entrance of the block. Before this CL it is considered live, and unnecessary copy or load may be generated when resolving merge edge. Fixes #14761. On AMD64: name old time/op new time/op delta BinaryTree17-12 2.84s ± 1% 2.81s ± 1% -1.06% (p=0.000 n=10+9) Fannkuch11-12 3.61s ± 0% 3.55s ± 1% -1.77% (p=0.000 n=10+9) FmtFprintfEmpty-12 50.4ns ± 4% 50.0ns ± 1% ~ (p=0.785 n=9+8) FmtFprintfString-12 80.0ns ± 3% 78.2ns ± 3% -2.35% (p=0.004 n=10+9) FmtFprintfInt-12 81.3ns ± 4% 81.8ns ± 2% ~ (p=0.159 n=10+10) FmtFprintfIntInt-12 120ns ± 4% 118ns ± 2% ~ (p=0.218 n=10+10) FmtFprintfPrefixedInt-12 152ns ± 3% 155ns ± 2% +2.11% (p=0.026 n=10+10) FmtFprintfFloat-12 240ns ± 1% 238ns ± 1% -0.79% (p=0.005 n=9+9) FmtManyArgs-12 504ns ± 1% 510ns ± 1% +1.14% (p=0.000 n=8+9) GobDecode-12 7.00ms ± 1% 6.99ms ± 0% ~ (p=0.497 n=9+10) GobEncode-12 5.47ms ± 1% 5.48ms ± 1% ~ (p=0.218 n=10+10) Gzip-12 258ms ± 2% 256ms ± 1% -0.96% (p=0.043 n=10+9) Gunzip-12 38.6ms ± 0% 38.3ms ± 0% -0.64% (p=0.000 n=9+8) HTTPClientServer-12 90.4µs ± 3% 87.2µs ±11% ~ (p=0.053 n=9+10) JSONEncode-12 15.6ms ± 0% 15.6ms ± 1% ~ (p=0.077 n=9+9) JSONDecode-12 55.1ms ± 1% 54.6ms ± 1% -0.85% (p=0.010 n=10+9) Mandelbrot200-12 4.49ms ± 0% 4.47ms ± 0% -0.25% (p=0.000 n=10+8) GoParse-12 3.38ms ± 0% 3.37ms ± 1% ~ (p=0.315 n=8+10) RegexpMatchEasy0_32-12 82.5ns ± 4% 82.0ns ± 0% ~ (p=0.164 n=10+8) RegexpMatchEasy0_1K-12 203ns ± 1% 202ns ± 1% -0.85% (p=0.000 n=9+10) RegexpMatchEasy1_32-12 82.3ns ± 1% 81.1ns ± 0% -1.39% (p=0.000 n=10+8) RegexpMatchEasy1_1K-12 357ns ± 1% 357ns ± 1% ~ (p=0.697 n=8+9) RegexpMatchMedium_32-12 125ns ± 2% 126ns ± 2% ~ (p=0.197 n=10+10) RegexpMatchMedium_1K-12 39.6µs ± 3% 39.6µs ± 1% ~ (p=0.971 n=10+10) RegexpMatchHard_32-12 1.99µs ± 2% 1.99µs ± 4% ~ (p=0.891 n=10+9) RegexpMatchHard_1K-12 60.1µs ± 3% 60.4µs ± 3% ~ (p=0.684 n=10+10) Revcomp-12 531ms ± 6% 441ms ± 0% -16.94% (p=0.000 n=10+9) Template-12 58.9ms ± 1% 58.7ms ± 1% ~ (p=0.315 n=10+10) TimeParse-12 319ns ± 1% 320ns ± 4% ~ (p=0.215 n=9+9) TimeFormat-12 345ns ± 0% 333ns ± 1% -3.36% (p=0.000 n=9+10) [Geo mean] 52.2µs 51.6µs -1.13% On ARM64: name old time/op new time/op delta BinaryTree17-8 8.53s ± 0% 8.36s ± 0% -1.89% (p=0.000 n=10+10) Fannkuch11-8 6.15s ± 0% 6.10s ± 0% -0.67% (p=0.000 n=10+10) FmtFprintfEmpty-8 117ns ± 0% 117ns ± 0% ~ (all equal) FmtFprintfString-8 192ns ± 0% 192ns ± 0% ~ (all equal) FmtFprintfInt-8 198ns ± 0% 198ns ± 0% ~ (p=0.211 n=10+10) FmtFprintfIntInt-8 289ns ± 0% 291ns ± 0% +0.59% (p=0.000 n=7+10) FmtFprintfPrefixedInt-8 320ns ± 2% 317ns ± 0% ~ (p=0.431 n=10+8) FmtFprintfFloat-8 538ns ± 0% 538ns ± 0% ~ (all equal) FmtManyArgs-8 1.17µs ± 1% 1.18µs ± 1% ~ (p=0.063 n=10+10) GobDecode-8 17.0ms ± 1% 17.2ms ± 1% +0.83% (p=0.000 n=10+10) GobEncode-8 14.2ms ± 0% 14.1ms ± 1% -0.78% (p=0.001 n=9+10) Gzip-8 806ms ± 0% 797ms ± 0% -1.12% (p=0.000 n=6+9) Gunzip-8 131ms ± 0% 130ms ± 0% -0.51% (p=0.000 n=10+9) HTTPClientServer-8 206µs ± 9% 212µs ± 2% ~ (p=0.829 n=10+8) JSONEncode-8 40.1ms ± 0% 40.1ms ± 0% ~ (p=0.136 n=9+9) JSONDecode-8 157ms ± 0% 151ms ± 0% -3.32% (p=0.000 n=9+9) Mandelbrot200-8 10.1ms ± 0% 10.1ms ± 0% -0.05% (p=0.000 n=9+8) GoParse-8 8.43ms ± 0% 8.43ms ± 0% ~ (p=0.912 n=10+10) RegexpMatchEasy0_32-8 228ns ± 1% 227ns ± 0% -0.26% (p=0.026 n=10+9) RegexpMatchEasy0_1K-8 1.92µs ± 0% 1.63µs ± 0% -15.18% (p=0.001 n=7+7) RegexpMatchEasy1_32-8 258ns ± 1% 250ns ± 0% -2.83% (p=0.000 n=10+10) RegexpMatchEasy1_1K-8 2.39µs ± 0% 2.13µs ± 0% -10.94% (p=0.000 n=9+9) RegexpMatchMedium_32-8 352ns ± 0% 351ns ± 0% -0.29% (p=0.004 n=9+10) RegexpMatchMedium_1K-8 104µs ± 0% 105µs ± 0% +0.58% (p=0.000 n=8+9) RegexpMatchHard_32-8 5.84µs ± 0% 5.82µs ± 0% -0.27% (p=0.000 n=9+10) RegexpMatchHard_1K-8 177µs ± 0% 177µs ± 0% -0.07% (p=0.000 n=9+9) Revcomp-8 1.57s ± 1% 1.50s ± 1% -4.60% (p=0.000 n=9+10) Template-8 157ms ± 1% 153ms ± 1% -2.28% (p=0.000 n=10+9) TimeParse-8 779ns ± 1% 770ns ± 1% -1.18% (p=0.013 n=10+10) TimeFormat-8 823ns ± 2% 826ns ± 1% ~ (p=0.324 n=10+9) [Geo mean] 144µs 142µs -1.45% Reduce cmd/go text size by 0.5%. Change-Id: I9288ff983c4a7cf03fc0cb35b9b1750828013117 Reviewed-on: https://go-review.googlesource.com/38457 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2017-03-22 21:34:12 -04:00
regValLiveSet := f.newSparseSet(f.NumValues()) // set of values that may be live in register
defer f.retSparseSet(regValLiveSet)
var oldSched []*Value
var phis []*Value
var phiRegs []register
var args []*Value
// Data structure used for computing desired registers.
var desired desiredState
desiredSecondReg := map[ID][4]register{} // desired register allocation for 2nd part of a tuple
// Desired registers for inputs & outputs for each instruction in the block.
type dentry struct {
out [4]register // desired output registers
in [3][4]register // desired input registers (for inputs 0,1, and 2)
}
var dinfo []dentry
if f.Entry != f.Blocks[0] {
f.Fatalf("entry block must be first")
}
for _, b := range s.visitOrder {
[dev.debug] cmd/compile: better DWARF with optimizations on Debuggers use DWARF information to find local variables on the stack and in registers. Prior to this CL, the DWARF information for functions claimed that all variables were on the stack at all times. That's incorrect when optimizations are enabled, and results in debuggers showing data that is out of date or complete gibberish. After this CL, the compiler is capable of representing variable locations more accurately, and attempts to do so. Due to limitations of the SSA backend, it's not possible to be completely correct. There are a number of problems in the current design. One of the easier to understand is that variable names currently must be attached to an SSA value, but not all assignments in the source code actually result in machine code. For example: type myint int var a int b := myint(int) and b := (*uint64)(unsafe.Pointer(a)) don't generate machine code because the underlying representation is the same, so the correct value of b will not be set when the user would expect. Generating the more precise debug information is behind a flag, dwarflocationlists. Because of the issues described above, setting the flag may not make the debugging experience much better, and may actually make it worse in cases where the variable actually is on the stack and the more complicated analysis doesn't realize it. A number of changes are included: - Add a new pseudo-instruction, RegKill, which indicates that the value in the register has been clobbered. - Adjust regalloc to emit RegKills in the right places. Significantly, this means that phis are mixed with StoreReg and RegKills after regalloc. - Track variable decomposition in ssa.LocalSlots. - After the SSA backend is done, analyze the result and build location lists for each LocalSlot. - After assembly is done, update the location lists with the assembled PC offsets, recompose variables, and build DWARF location lists. Emit the list as a new linker symbol, one per function. - In the linker, aggregate the location lists into a .debug_loc section. TODO: - currently disabled for non-X86/AMD64 because there are no data tables. go build -toolexec 'toolstash -cmp' -a std succeeds. With -dwarflocationlists false: before: f02812195637909ff675782c0b46836a8ff01976 after: 06f61e8112a42ac34fb80e0c818b3cdb84a5e7ec benchstat -geomean /tmp/220352263 /tmp/621364410 completed 15 of 15, estimated time remaining 0s (eta 3:52PM) name old time/op new time/op delta Template 199ms ± 3% 198ms ± 2% ~ (p=0.400 n=15+14) Unicode 96.6ms ± 5% 96.4ms ± 5% ~ (p=0.838 n=15+15) GoTypes 653ms ± 2% 647ms ± 2% ~ (p=0.102 n=15+14) Flate 133ms ± 6% 129ms ± 3% -2.62% (p=0.041 n=15+15) GoParser 164ms ± 5% 159ms ± 3% -3.05% (p=0.000 n=15+15) Reflect 428ms ± 4% 422ms ± 3% ~ (p=0.156 n=15+13) Tar 123ms ±10% 124ms ± 8% ~ (p=0.461 n=15+15) XML 228ms ± 3% 224ms ± 3% -1.57% (p=0.045 n=15+15) [Geo mean] 206ms 377ms +82.86% name old user-time/op new user-time/op delta Template 292ms ±10% 301ms ±12% ~ (p=0.189 n=15+15) Unicode 166ms ±37% 158ms ±14% ~ (p=0.418 n=15+14) GoTypes 962ms ± 6% 963ms ± 7% ~ (p=0.976 n=15+15) Flate 207ms ±19% 200ms ±14% ~ (p=0.345 n=14+15) GoParser 246ms ±22% 240ms ±15% ~ (p=0.587 n=15+15) Reflect 611ms ±13% 587ms ±14% ~ (p=0.085 n=15+13) Tar 211ms ±12% 217ms ±14% ~ (p=0.355 n=14+15) XML 335ms ±15% 320ms ±18% ~ (p=0.169 n=15+15) [Geo mean] 317ms 583ms +83.72% name old alloc/op new alloc/op delta Template 40.2MB ± 0% 40.2MB ± 0% -0.15% (p=0.000 n=14+15) Unicode 29.2MB ± 0% 29.3MB ± 0% ~ (p=0.624 n=15+15) GoTypes 114MB ± 0% 114MB ± 0% -0.15% (p=0.000 n=15+14) Flate 25.7MB ± 0% 25.6MB ± 0% -0.18% (p=0.000 n=13+15) GoParser 32.2MB ± 0% 32.2MB ± 0% -0.14% (p=0.003 n=15+15) Reflect 77.8MB ± 0% 77.9MB ± 0% ~ (p=0.061 n=15+15) Tar 27.1MB ± 0% 27.0MB ± 0% -0.11% (p=0.029 n=15+15) XML 42.7MB ± 0% 42.5MB ± 0% -0.29% (p=0.000 n=15+15) [Geo mean] 42.1MB 75.0MB +78.05% name old allocs/op new allocs/op delta Template 402k ± 1% 398k ± 0% -0.91% (p=0.000 n=15+15) Unicode 344k ± 1% 344k ± 0% ~ (p=0.715 n=15+14) GoTypes 1.18M ± 0% 1.17M ± 0% -0.91% (p=0.000 n=15+14) Flate 243k ± 0% 240k ± 1% -1.05% (p=0.000 n=13+15) GoParser 327k ± 1% 324k ± 1% -0.96% (p=0.000 n=15+15) Reflect 984k ± 1% 982k ± 0% ~ (p=0.050 n=15+15) Tar 261k ± 1% 259k ± 1% -0.77% (p=0.000 n=15+15) XML 411k ± 0% 404k ± 1% -1.55% (p=0.000 n=15+15) [Geo mean] 439k 755k +72.01% name old text-bytes new text-bytes delta HelloSize 694kB ± 0% 694kB ± 0% -0.00% (p=0.000 n=15+15) name old data-bytes new data-bytes delta HelloSize 5.55kB ± 0% 5.55kB ± 0% ~ (all equal) name old bss-bytes new bss-bytes delta HelloSize 133kB ± 0% 133kB ± 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 1.04MB ± 0% 1.04MB ± 0% ~ (all equal) Change-Id: I991fc553ef175db46bb23b2128317bbd48de70d8 Reviewed-on: https://go-review.googlesource.com/41770 Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
2017-07-21 18:30:19 -04:00
if s.f.pass.debug > regDebug {
fmt.Printf("Begin processing block %v\n", b)
}
s.curBlock = b
cmd/compile/internal/ssa: drop overwritten regalloc basic block input requirements For the following description, consider the following basic block graph: b1 ───┐┌──── b2 ││ ││ ▼▼ b3 For register allocator transitions between basic blocks, there are two key passes (significant paraphrasing): First, each basic block is visited in some predetermined visit order. This is the core visitOrder range loop in regAllocState.regalloc. The specific ordering heuristics aren't important here, except that the order guarantees that when visiting a basic block at least one of its predecessors has already been visited. Upon visiting a basic block, that block sets its expected starting register state (regAllocState.startRegs) based on the ending register state (regAlloc.State.endRegs) of one of its predecessors. (How it chooses which predecessor to use is not important here.) From that starting state, registers are assigned for all values in the block, ultimately resulting in some ending register state. After all blocks have been visited, the shuffle pass (regAllocState.shuffle) ensures that for each edge, endRegs of the predecessor == startRegs of the successor. That is, it makes sure that the startRegs assumptions actually hold true for each edge. It does this by adding moves to the end of the predecessor block to place values in the expected register for the successor block. These may be moves from other registers, or from memory if the value is spilled. Now on to the actual problem: Assume that b1 places some value v1 into register R10, and thus ends with endRegs containing R10 = v1. When b3 is visited, it selects b1 as its model predecessor and sets startRegs with R10 = v1. b2 does not have v1 in R10, so later in the shuffle pass, we will add a move of v1 into R10 to the end of b2 to ensure it is available for b3. This is all perfectly fine and exactly how things should work. Now suppose that b3 does not use v1. It does need to use some other value v2, which is not currently in a register. When assigning v2 to a register, it finds all registers are already in use and it needs to dump a value. Ultimately, it decides to dump v1 from R10 and replace it with v2. This is fine, but it has downstream effects on shuffle in b2. b3's startRegs still state that R10 = v1, so b2 will add a move to R10 even though b3 will unconditionally overwrite it. i.e., the move at the end of b2 is completely useless and can result in code like: // end of b2 MOV n(SP), R10 // R10 = v1 <-- useless // start of b3 MOV m(SP), R10 // R10 = v2 This is precisely what happened in #58298. This CL addresses this problem by dropping registers from startRegs if they are never used in the basic block prior to getting dumped. This allows the shuffle pass to avoid placing those useless values into the register. There is a significant limitation to this CL, which is that it only impacts the immediate predecessors of an overwriting block. We can discuss this by zooming out a bit on the previous graph: b4 ───┐┌──── b5 ││ ││ ▼▼ b1 ───┐┌──── b2 ││ ││ ▼▼ b3 Here we have the same graph, except we can see the two predecessors of b1. Now suppose that rather than b1 assigning R10 = v1 as above, the assignment is done in b4. b1 has startRegs R10 = v1, doesn't use the value at all, and simply passes it through to endRegs R10 = v1. Now the shuffle pass will require both b2 and b5 to add a move to assigned R10 = v1, because that is specified in their successor startRegs. With this CL, b3 drops R10 = v1 from startRegs, but there is no backwards propagation, so b1 still has R10 = v1 in startRegs, and b5 still needs to add a useless move. Extending this CL with such propagation may significantly increase the number of useless moves we can remove, though it will add complexity to maintenance and could potentially impact build performance depending on how efficiently we could implement the propagation (something I haven't considered carefully). As-is, this optimization does not impact much code. In bent .text size geomean is -0.02%. In the container/heap test binary, 18 of ~2500 functions are impacted by this CL. Bent and sweet do not show a noticeable performance impact one way or another, however #58298 does show a case where this can have impact if the useless instructions end up in the hot path of a tight loop. For #58298. Change-Id: I2fcef37c955159d068fa0725f995a1848add8a5f Reviewed-on: https://go-review.googlesource.com/c/go/+/471158 Run-TryBot: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: David Chase <drchase@google.com>
2023-02-21 13:20:49 -05:00
s.startRegsMask = 0
s.usedSinceBlockStart = 0
clear(desiredSecondReg)
cmd/compile: improve startRegs calculation In register allocation, we calculate what values are used in and after the current block. If a value is used only after a function call, since registers are clobbered in call, we don't need to mark the value live at the entrance of the block. Before this CL it is considered live, and unnecessary copy or load may be generated when resolving merge edge. Fixes #14761. On AMD64: name old time/op new time/op delta BinaryTree17-12 2.84s ± 1% 2.81s ± 1% -1.06% (p=0.000 n=10+9) Fannkuch11-12 3.61s ± 0% 3.55s ± 1% -1.77% (p=0.000 n=10+9) FmtFprintfEmpty-12 50.4ns ± 4% 50.0ns ± 1% ~ (p=0.785 n=9+8) FmtFprintfString-12 80.0ns ± 3% 78.2ns ± 3% -2.35% (p=0.004 n=10+9) FmtFprintfInt-12 81.3ns ± 4% 81.8ns ± 2% ~ (p=0.159 n=10+10) FmtFprintfIntInt-12 120ns ± 4% 118ns ± 2% ~ (p=0.218 n=10+10) FmtFprintfPrefixedInt-12 152ns ± 3% 155ns ± 2% +2.11% (p=0.026 n=10+10) FmtFprintfFloat-12 240ns ± 1% 238ns ± 1% -0.79% (p=0.005 n=9+9) FmtManyArgs-12 504ns ± 1% 510ns ± 1% +1.14% (p=0.000 n=8+9) GobDecode-12 7.00ms ± 1% 6.99ms ± 0% ~ (p=0.497 n=9+10) GobEncode-12 5.47ms ± 1% 5.48ms ± 1% ~ (p=0.218 n=10+10) Gzip-12 258ms ± 2% 256ms ± 1% -0.96% (p=0.043 n=10+9) Gunzip-12 38.6ms ± 0% 38.3ms ± 0% -0.64% (p=0.000 n=9+8) HTTPClientServer-12 90.4µs ± 3% 87.2µs ±11% ~ (p=0.053 n=9+10) JSONEncode-12 15.6ms ± 0% 15.6ms ± 1% ~ (p=0.077 n=9+9) JSONDecode-12 55.1ms ± 1% 54.6ms ± 1% -0.85% (p=0.010 n=10+9) Mandelbrot200-12 4.49ms ± 0% 4.47ms ± 0% -0.25% (p=0.000 n=10+8) GoParse-12 3.38ms ± 0% 3.37ms ± 1% ~ (p=0.315 n=8+10) RegexpMatchEasy0_32-12 82.5ns ± 4% 82.0ns ± 0% ~ (p=0.164 n=10+8) RegexpMatchEasy0_1K-12 203ns ± 1% 202ns ± 1% -0.85% (p=0.000 n=9+10) RegexpMatchEasy1_32-12 82.3ns ± 1% 81.1ns ± 0% -1.39% (p=0.000 n=10+8) RegexpMatchEasy1_1K-12 357ns ± 1% 357ns ± 1% ~ (p=0.697 n=8+9) RegexpMatchMedium_32-12 125ns ± 2% 126ns ± 2% ~ (p=0.197 n=10+10) RegexpMatchMedium_1K-12 39.6µs ± 3% 39.6µs ± 1% ~ (p=0.971 n=10+10) RegexpMatchHard_32-12 1.99µs ± 2% 1.99µs ± 4% ~ (p=0.891 n=10+9) RegexpMatchHard_1K-12 60.1µs ± 3% 60.4µs ± 3% ~ (p=0.684 n=10+10) Revcomp-12 531ms ± 6% 441ms ± 0% -16.94% (p=0.000 n=10+9) Template-12 58.9ms ± 1% 58.7ms ± 1% ~ (p=0.315 n=10+10) TimeParse-12 319ns ± 1% 320ns ± 4% ~ (p=0.215 n=9+9) TimeFormat-12 345ns ± 0% 333ns ± 1% -3.36% (p=0.000 n=9+10) [Geo mean] 52.2µs 51.6µs -1.13% On ARM64: name old time/op new time/op delta BinaryTree17-8 8.53s ± 0% 8.36s ± 0% -1.89% (p=0.000 n=10+10) Fannkuch11-8 6.15s ± 0% 6.10s ± 0% -0.67% (p=0.000 n=10+10) FmtFprintfEmpty-8 117ns ± 0% 117ns ± 0% ~ (all equal) FmtFprintfString-8 192ns ± 0% 192ns ± 0% ~ (all equal) FmtFprintfInt-8 198ns ± 0% 198ns ± 0% ~ (p=0.211 n=10+10) FmtFprintfIntInt-8 289ns ± 0% 291ns ± 0% +0.59% (p=0.000 n=7+10) FmtFprintfPrefixedInt-8 320ns ± 2% 317ns ± 0% ~ (p=0.431 n=10+8) FmtFprintfFloat-8 538ns ± 0% 538ns ± 0% ~ (all equal) FmtManyArgs-8 1.17µs ± 1% 1.18µs ± 1% ~ (p=0.063 n=10+10) GobDecode-8 17.0ms ± 1% 17.2ms ± 1% +0.83% (p=0.000 n=10+10) GobEncode-8 14.2ms ± 0% 14.1ms ± 1% -0.78% (p=0.001 n=9+10) Gzip-8 806ms ± 0% 797ms ± 0% -1.12% (p=0.000 n=6+9) Gunzip-8 131ms ± 0% 130ms ± 0% -0.51% (p=0.000 n=10+9) HTTPClientServer-8 206µs ± 9% 212µs ± 2% ~ (p=0.829 n=10+8) JSONEncode-8 40.1ms ± 0% 40.1ms ± 0% ~ (p=0.136 n=9+9) JSONDecode-8 157ms ± 0% 151ms ± 0% -3.32% (p=0.000 n=9+9) Mandelbrot200-8 10.1ms ± 0% 10.1ms ± 0% -0.05% (p=0.000 n=9+8) GoParse-8 8.43ms ± 0% 8.43ms ± 0% ~ (p=0.912 n=10+10) RegexpMatchEasy0_32-8 228ns ± 1% 227ns ± 0% -0.26% (p=0.026 n=10+9) RegexpMatchEasy0_1K-8 1.92µs ± 0% 1.63µs ± 0% -15.18% (p=0.001 n=7+7) RegexpMatchEasy1_32-8 258ns ± 1% 250ns ± 0% -2.83% (p=0.000 n=10+10) RegexpMatchEasy1_1K-8 2.39µs ± 0% 2.13µs ± 0% -10.94% (p=0.000 n=9+9) RegexpMatchMedium_32-8 352ns ± 0% 351ns ± 0% -0.29% (p=0.004 n=9+10) RegexpMatchMedium_1K-8 104µs ± 0% 105µs ± 0% +0.58% (p=0.000 n=8+9) RegexpMatchHard_32-8 5.84µs ± 0% 5.82µs ± 0% -0.27% (p=0.000 n=9+10) RegexpMatchHard_1K-8 177µs ± 0% 177µs ± 0% -0.07% (p=0.000 n=9+9) Revcomp-8 1.57s ± 1% 1.50s ± 1% -4.60% (p=0.000 n=9+10) Template-8 157ms ± 1% 153ms ± 1% -2.28% (p=0.000 n=10+9) TimeParse-8 779ns ± 1% 770ns ± 1% -1.18% (p=0.013 n=10+10) TimeFormat-8 823ns ± 2% 826ns ± 1% ~ (p=0.324 n=10+9) [Geo mean] 144µs 142µs -1.45% Reduce cmd/go text size by 0.5%. Change-Id: I9288ff983c4a7cf03fc0cb35b9b1750828013117 Reviewed-on: https://go-review.googlesource.com/38457 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2017-03-22 21:34:12 -04:00
// Initialize regValLiveSet and uses fields for this block.
// Walk backwards through the block doing liveness analysis.
cmd/compile: improve startRegs calculation In register allocation, we calculate what values are used in and after the current block. If a value is used only after a function call, since registers are clobbered in call, we don't need to mark the value live at the entrance of the block. Before this CL it is considered live, and unnecessary copy or load may be generated when resolving merge edge. Fixes #14761. On AMD64: name old time/op new time/op delta BinaryTree17-12 2.84s ± 1% 2.81s ± 1% -1.06% (p=0.000 n=10+9) Fannkuch11-12 3.61s ± 0% 3.55s ± 1% -1.77% (p=0.000 n=10+9) FmtFprintfEmpty-12 50.4ns ± 4% 50.0ns ± 1% ~ (p=0.785 n=9+8) FmtFprintfString-12 80.0ns ± 3% 78.2ns ± 3% -2.35% (p=0.004 n=10+9) FmtFprintfInt-12 81.3ns ± 4% 81.8ns ± 2% ~ (p=0.159 n=10+10) FmtFprintfIntInt-12 120ns ± 4% 118ns ± 2% ~ (p=0.218 n=10+10) FmtFprintfPrefixedInt-12 152ns ± 3% 155ns ± 2% +2.11% (p=0.026 n=10+10) FmtFprintfFloat-12 240ns ± 1% 238ns ± 1% -0.79% (p=0.005 n=9+9) FmtManyArgs-12 504ns ± 1% 510ns ± 1% +1.14% (p=0.000 n=8+9) GobDecode-12 7.00ms ± 1% 6.99ms ± 0% ~ (p=0.497 n=9+10) GobEncode-12 5.47ms ± 1% 5.48ms ± 1% ~ (p=0.218 n=10+10) Gzip-12 258ms ± 2% 256ms ± 1% -0.96% (p=0.043 n=10+9) Gunzip-12 38.6ms ± 0% 38.3ms ± 0% -0.64% (p=0.000 n=9+8) HTTPClientServer-12 90.4µs ± 3% 87.2µs ±11% ~ (p=0.053 n=9+10) JSONEncode-12 15.6ms ± 0% 15.6ms ± 1% ~ (p=0.077 n=9+9) JSONDecode-12 55.1ms ± 1% 54.6ms ± 1% -0.85% (p=0.010 n=10+9) Mandelbrot200-12 4.49ms ± 0% 4.47ms ± 0% -0.25% (p=0.000 n=10+8) GoParse-12 3.38ms ± 0% 3.37ms ± 1% ~ (p=0.315 n=8+10) RegexpMatchEasy0_32-12 82.5ns ± 4% 82.0ns ± 0% ~ (p=0.164 n=10+8) RegexpMatchEasy0_1K-12 203ns ± 1% 202ns ± 1% -0.85% (p=0.000 n=9+10) RegexpMatchEasy1_32-12 82.3ns ± 1% 81.1ns ± 0% -1.39% (p=0.000 n=10+8) RegexpMatchEasy1_1K-12 357ns ± 1% 357ns ± 1% ~ (p=0.697 n=8+9) RegexpMatchMedium_32-12 125ns ± 2% 126ns ± 2% ~ (p=0.197 n=10+10) RegexpMatchMedium_1K-12 39.6µs ± 3% 39.6µs ± 1% ~ (p=0.971 n=10+10) RegexpMatchHard_32-12 1.99µs ± 2% 1.99µs ± 4% ~ (p=0.891 n=10+9) RegexpMatchHard_1K-12 60.1µs ± 3% 60.4µs ± 3% ~ (p=0.684 n=10+10) Revcomp-12 531ms ± 6% 441ms ± 0% -16.94% (p=0.000 n=10+9) Template-12 58.9ms ± 1% 58.7ms ± 1% ~ (p=0.315 n=10+10) TimeParse-12 319ns ± 1% 320ns ± 4% ~ (p=0.215 n=9+9) TimeFormat-12 345ns ± 0% 333ns ± 1% -3.36% (p=0.000 n=9+10) [Geo mean] 52.2µs 51.6µs -1.13% On ARM64: name old time/op new time/op delta BinaryTree17-8 8.53s ± 0% 8.36s ± 0% -1.89% (p=0.000 n=10+10) Fannkuch11-8 6.15s ± 0% 6.10s ± 0% -0.67% (p=0.000 n=10+10) FmtFprintfEmpty-8 117ns ± 0% 117ns ± 0% ~ (all equal) FmtFprintfString-8 192ns ± 0% 192ns ± 0% ~ (all equal) FmtFprintfInt-8 198ns ± 0% 198ns ± 0% ~ (p=0.211 n=10+10) FmtFprintfIntInt-8 289ns ± 0% 291ns ± 0% +0.59% (p=0.000 n=7+10) FmtFprintfPrefixedInt-8 320ns ± 2% 317ns ± 0% ~ (p=0.431 n=10+8) FmtFprintfFloat-8 538ns ± 0% 538ns ± 0% ~ (all equal) FmtManyArgs-8 1.17µs ± 1% 1.18µs ± 1% ~ (p=0.063 n=10+10) GobDecode-8 17.0ms ± 1% 17.2ms ± 1% +0.83% (p=0.000 n=10+10) GobEncode-8 14.2ms ± 0% 14.1ms ± 1% -0.78% (p=0.001 n=9+10) Gzip-8 806ms ± 0% 797ms ± 0% -1.12% (p=0.000 n=6+9) Gunzip-8 131ms ± 0% 130ms ± 0% -0.51% (p=0.000 n=10+9) HTTPClientServer-8 206µs ± 9% 212µs ± 2% ~ (p=0.829 n=10+8) JSONEncode-8 40.1ms ± 0% 40.1ms ± 0% ~ (p=0.136 n=9+9) JSONDecode-8 157ms ± 0% 151ms ± 0% -3.32% (p=0.000 n=9+9) Mandelbrot200-8 10.1ms ± 0% 10.1ms ± 0% -0.05% (p=0.000 n=9+8) GoParse-8 8.43ms ± 0% 8.43ms ± 0% ~ (p=0.912 n=10+10) RegexpMatchEasy0_32-8 228ns ± 1% 227ns ± 0% -0.26% (p=0.026 n=10+9) RegexpMatchEasy0_1K-8 1.92µs ± 0% 1.63µs ± 0% -15.18% (p=0.001 n=7+7) RegexpMatchEasy1_32-8 258ns ± 1% 250ns ± 0% -2.83% (p=0.000 n=10+10) RegexpMatchEasy1_1K-8 2.39µs ± 0% 2.13µs ± 0% -10.94% (p=0.000 n=9+9) RegexpMatchMedium_32-8 352ns ± 0% 351ns ± 0% -0.29% (p=0.004 n=9+10) RegexpMatchMedium_1K-8 104µs ± 0% 105µs ± 0% +0.58% (p=0.000 n=8+9) RegexpMatchHard_32-8 5.84µs ± 0% 5.82µs ± 0% -0.27% (p=0.000 n=9+10) RegexpMatchHard_1K-8 177µs ± 0% 177µs ± 0% -0.07% (p=0.000 n=9+9) Revcomp-8 1.57s ± 1% 1.50s ± 1% -4.60% (p=0.000 n=9+10) Template-8 157ms ± 1% 153ms ± 1% -2.28% (p=0.000 n=10+9) TimeParse-8 779ns ± 1% 770ns ± 1% -1.18% (p=0.013 n=10+10) TimeFormat-8 823ns ± 2% 826ns ± 1% ~ (p=0.324 n=10+9) [Geo mean] 144µs 142µs -1.45% Reduce cmd/go text size by 0.5%. Change-Id: I9288ff983c4a7cf03fc0cb35b9b1750828013117 Reviewed-on: https://go-review.googlesource.com/38457 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2017-03-22 21:34:12 -04:00
regValLiveSet.clear()
for _, e := range s.live[b.ID] {
s.addUse(e.ID, int32(len(b.Values))+e.dist, e.pos) // pseudo-uses from beyond end of block
cmd/compile: improve startRegs calculation In register allocation, we calculate what values are used in and after the current block. If a value is used only after a function call, since registers are clobbered in call, we don't need to mark the value live at the entrance of the block. Before this CL it is considered live, and unnecessary copy or load may be generated when resolving merge edge. Fixes #14761. On AMD64: name old time/op new time/op delta BinaryTree17-12 2.84s ± 1% 2.81s ± 1% -1.06% (p=0.000 n=10+9) Fannkuch11-12 3.61s ± 0% 3.55s ± 1% -1.77% (p=0.000 n=10+9) FmtFprintfEmpty-12 50.4ns ± 4% 50.0ns ± 1% ~ (p=0.785 n=9+8) FmtFprintfString-12 80.0ns ± 3% 78.2ns ± 3% -2.35% (p=0.004 n=10+9) FmtFprintfInt-12 81.3ns ± 4% 81.8ns ± 2% ~ (p=0.159 n=10+10) FmtFprintfIntInt-12 120ns ± 4% 118ns ± 2% ~ (p=0.218 n=10+10) FmtFprintfPrefixedInt-12 152ns ± 3% 155ns ± 2% +2.11% (p=0.026 n=10+10) FmtFprintfFloat-12 240ns ± 1% 238ns ± 1% -0.79% (p=0.005 n=9+9) FmtManyArgs-12 504ns ± 1% 510ns ± 1% +1.14% (p=0.000 n=8+9) GobDecode-12 7.00ms ± 1% 6.99ms ± 0% ~ (p=0.497 n=9+10) GobEncode-12 5.47ms ± 1% 5.48ms ± 1% ~ (p=0.218 n=10+10) Gzip-12 258ms ± 2% 256ms ± 1% -0.96% (p=0.043 n=10+9) Gunzip-12 38.6ms ± 0% 38.3ms ± 0% -0.64% (p=0.000 n=9+8) HTTPClientServer-12 90.4µs ± 3% 87.2µs ±11% ~ (p=0.053 n=9+10) JSONEncode-12 15.6ms ± 0% 15.6ms ± 1% ~ (p=0.077 n=9+9) JSONDecode-12 55.1ms ± 1% 54.6ms ± 1% -0.85% (p=0.010 n=10+9) Mandelbrot200-12 4.49ms ± 0% 4.47ms ± 0% -0.25% (p=0.000 n=10+8) GoParse-12 3.38ms ± 0% 3.37ms ± 1% ~ (p=0.315 n=8+10) RegexpMatchEasy0_32-12 82.5ns ± 4% 82.0ns ± 0% ~ (p=0.164 n=10+8) RegexpMatchEasy0_1K-12 203ns ± 1% 202ns ± 1% -0.85% (p=0.000 n=9+10) RegexpMatchEasy1_32-12 82.3ns ± 1% 81.1ns ± 0% -1.39% (p=0.000 n=10+8) RegexpMatchEasy1_1K-12 357ns ± 1% 357ns ± 1% ~ (p=0.697 n=8+9) RegexpMatchMedium_32-12 125ns ± 2% 126ns ± 2% ~ (p=0.197 n=10+10) RegexpMatchMedium_1K-12 39.6µs ± 3% 39.6µs ± 1% ~ (p=0.971 n=10+10) RegexpMatchHard_32-12 1.99µs ± 2% 1.99µs ± 4% ~ (p=0.891 n=10+9) RegexpMatchHard_1K-12 60.1µs ± 3% 60.4µs ± 3% ~ (p=0.684 n=10+10) Revcomp-12 531ms ± 6% 441ms ± 0% -16.94% (p=0.000 n=10+9) Template-12 58.9ms ± 1% 58.7ms ± 1% ~ (p=0.315 n=10+10) TimeParse-12 319ns ± 1% 320ns ± 4% ~ (p=0.215 n=9+9) TimeFormat-12 345ns ± 0% 333ns ± 1% -3.36% (p=0.000 n=9+10) [Geo mean] 52.2µs 51.6µs -1.13% On ARM64: name old time/op new time/op delta BinaryTree17-8 8.53s ± 0% 8.36s ± 0% -1.89% (p=0.000 n=10+10) Fannkuch11-8 6.15s ± 0% 6.10s ± 0% -0.67% (p=0.000 n=10+10) FmtFprintfEmpty-8 117ns ± 0% 117ns ± 0% ~ (all equal) FmtFprintfString-8 192ns ± 0% 192ns ± 0% ~ (all equal) FmtFprintfInt-8 198ns ± 0% 198ns ± 0% ~ (p=0.211 n=10+10) FmtFprintfIntInt-8 289ns ± 0% 291ns ± 0% +0.59% (p=0.000 n=7+10) FmtFprintfPrefixedInt-8 320ns ± 2% 317ns ± 0% ~ (p=0.431 n=10+8) FmtFprintfFloat-8 538ns ± 0% 538ns ± 0% ~ (all equal) FmtManyArgs-8 1.17µs ± 1% 1.18µs ± 1% ~ (p=0.063 n=10+10) GobDecode-8 17.0ms ± 1% 17.2ms ± 1% +0.83% (p=0.000 n=10+10) GobEncode-8 14.2ms ± 0% 14.1ms ± 1% -0.78% (p=0.001 n=9+10) Gzip-8 806ms ± 0% 797ms ± 0% -1.12% (p=0.000 n=6+9) Gunzip-8 131ms ± 0% 130ms ± 0% -0.51% (p=0.000 n=10+9) HTTPClientServer-8 206µs ± 9% 212µs ± 2% ~ (p=0.829 n=10+8) JSONEncode-8 40.1ms ± 0% 40.1ms ± 0% ~ (p=0.136 n=9+9) JSONDecode-8 157ms ± 0% 151ms ± 0% -3.32% (p=0.000 n=9+9) Mandelbrot200-8 10.1ms ± 0% 10.1ms ± 0% -0.05% (p=0.000 n=9+8) GoParse-8 8.43ms ± 0% 8.43ms ± 0% ~ (p=0.912 n=10+10) RegexpMatchEasy0_32-8 228ns ± 1% 227ns ± 0% -0.26% (p=0.026 n=10+9) RegexpMatchEasy0_1K-8 1.92µs ± 0% 1.63µs ± 0% -15.18% (p=0.001 n=7+7) RegexpMatchEasy1_32-8 258ns ± 1% 250ns ± 0% -2.83% (p=0.000 n=10+10) RegexpMatchEasy1_1K-8 2.39µs ± 0% 2.13µs ± 0% -10.94% (p=0.000 n=9+9) RegexpMatchMedium_32-8 352ns ± 0% 351ns ± 0% -0.29% (p=0.004 n=9+10) RegexpMatchMedium_1K-8 104µs ± 0% 105µs ± 0% +0.58% (p=0.000 n=8+9) RegexpMatchHard_32-8 5.84µs ± 0% 5.82µs ± 0% -0.27% (p=0.000 n=9+10) RegexpMatchHard_1K-8 177µs ± 0% 177µs ± 0% -0.07% (p=0.000 n=9+9) Revcomp-8 1.57s ± 1% 1.50s ± 1% -4.60% (p=0.000 n=9+10) Template-8 157ms ± 1% 153ms ± 1% -2.28% (p=0.000 n=10+9) TimeParse-8 779ns ± 1% 770ns ± 1% -1.18% (p=0.013 n=10+10) TimeFormat-8 823ns ± 2% 826ns ± 1% ~ (p=0.324 n=10+9) [Geo mean] 144µs 142µs -1.45% Reduce cmd/go text size by 0.5%. Change-Id: I9288ff983c4a7cf03fc0cb35b9b1750828013117 Reviewed-on: https://go-review.googlesource.com/38457 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2017-03-22 21:34:12 -04:00
regValLiveSet.add(e.ID)
}
cmd/compile: allow multiple SSA block control values Control values are used to choose which successor of a block is jumped to. Typically a control value takes the form of a 'flags' value that represents the result of a comparison. Some architectures however use a variable in a register as a control value. Up until now we have managed with a single control value per block. However some architectures (e.g. s390x and riscv64) have combined compare-and-branch instructions that take two variables in registers as parameters. To generate these instructions we need to support 2 control values per block. This CL allows up to 2 control values to be used in a block in order to support the addition of compare-and-branch instructions. I have implemented s390x compare-and-branch instructions in a different CL. Passes toolstash-check -all. Results of compilebench: name old time/op new time/op delta Template 208ms ± 1% 209ms ± 1% ~ (p=0.289 n=20+20) Unicode 83.7ms ± 1% 83.3ms ± 3% -0.49% (p=0.017 n=18+18) GoTypes 748ms ± 1% 748ms ± 0% ~ (p=0.460 n=20+18) Compiler 3.47s ± 1% 3.48s ± 1% ~ (p=0.070 n=19+18) SSA 11.5s ± 1% 11.7s ± 1% +1.64% (p=0.000 n=19+18) Flate 130ms ± 1% 130ms ± 1% ~ (p=0.588 n=19+20) GoParser 160ms ± 1% 161ms ± 1% ~ (p=0.211 n=20+20) Reflect 465ms ± 1% 467ms ± 1% +0.42% (p=0.007 n=20+20) Tar 184ms ± 1% 185ms ± 2% ~ (p=0.087 n=18+20) XML 253ms ± 1% 253ms ± 1% ~ (p=0.377 n=20+18) LinkCompiler 769ms ± 2% 774ms ± 2% ~ (p=0.070 n=19+19) ExternalLinkCompiler 3.59s ±11% 3.68s ± 6% ~ (p=0.072 n=20+20) LinkWithoutDebugCompiler 446ms ± 5% 454ms ± 3% +1.79% (p=0.002 n=19+20) StdCmd 26.0s ± 2% 26.0s ± 2% ~ (p=0.799 n=20+20) name old user-time/op new user-time/op delta Template 238ms ± 5% 240ms ± 5% ~ (p=0.142 n=20+20) Unicode 105ms ±11% 106ms ±10% ~ (p=0.512 n=20+20) GoTypes 876ms ± 2% 873ms ± 4% ~ (p=0.647 n=20+19) Compiler 4.17s ± 2% 4.19s ± 1% ~ (p=0.093 n=20+18) SSA 13.9s ± 1% 14.1s ± 1% +1.45% (p=0.000 n=18+18) Flate 145ms ±13% 146ms ± 5% ~ (p=0.851 n=20+18) GoParser 185ms ± 5% 188ms ± 7% ~ (p=0.174 n=20+20) Reflect 534ms ± 3% 538ms ± 2% ~ (p=0.105 n=20+18) Tar 215ms ± 4% 211ms ± 9% ~ (p=0.079 n=19+20) XML 295ms ± 6% 295ms ± 5% ~ (p=0.968 n=20+20) LinkCompiler 832ms ± 4% 837ms ± 7% ~ (p=0.707 n=17+20) ExternalLinkCompiler 1.58s ± 8% 1.60s ± 4% ~ (p=0.296 n=20+19) LinkWithoutDebugCompiler 478ms ±12% 489ms ±10% ~ (p=0.429 n=20+20) name old object-bytes new object-bytes delta Template 559kB ± 0% 559kB ± 0% ~ (all equal) Unicode 216kB ± 0% 216kB ± 0% ~ (all equal) GoTypes 2.03MB ± 0% 2.03MB ± 0% ~ (all equal) Compiler 8.07MB ± 0% 8.07MB ± 0% -0.06% (p=0.000 n=20+20) SSA 27.1MB ± 0% 27.3MB ± 0% +0.89% (p=0.000 n=20+20) Flate 343kB ± 0% 343kB ± 0% ~ (all equal) GoParser 441kB ± 0% 441kB ± 0% ~ (all equal) Reflect 1.36MB ± 0% 1.36MB ± 0% ~ (all equal) Tar 487kB ± 0% 487kB ± 0% ~ (all equal) XML 632kB ± 0% 632kB ± 0% ~ (all equal) name old export-bytes new export-bytes delta Template 18.5kB ± 0% 18.5kB ± 0% ~ (all equal) Unicode 7.92kB ± 0% 7.92kB ± 0% ~ (all equal) GoTypes 35.0kB ± 0% 35.0kB ± 0% ~ (all equal) Compiler 109kB ± 0% 110kB ± 0% +0.72% (p=0.000 n=20+20) SSA 137kB ± 0% 138kB ± 0% +0.58% (p=0.000 n=20+20) Flate 4.89kB ± 0% 4.89kB ± 0% ~ (all equal) GoParser 8.49kB ± 0% 8.49kB ± 0% ~ (all equal) Reflect 11.4kB ± 0% 11.4kB ± 0% ~ (all equal) Tar 10.5kB ± 0% 10.5kB ± 0% ~ (all equal) XML 16.7kB ± 0% 16.7kB ± 0% ~ (all equal) name old text-bytes new text-bytes delta HelloSize 761kB ± 0% 761kB ± 0% ~ (all equal) CmdGoSize 10.8MB ± 0% 10.8MB ± 0% ~ (all equal) name old data-bytes new data-bytes delta HelloSize 10.7kB ± 0% 10.7kB ± 0% ~ (all equal) CmdGoSize 312kB ± 0% 312kB ± 0% ~ (all equal) name old bss-bytes new bss-bytes delta HelloSize 122kB ± 0% 122kB ± 0% ~ (all equal) CmdGoSize 146kB ± 0% 146kB ± 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 1.13MB ± 0% 1.13MB ± 0% ~ (all equal) CmdGoSize 15.1MB ± 0% 15.1MB ± 0% ~ (all equal) Change-Id: I3cc2f9829a109543d9a68be4a21775d2d3e9801f Reviewed-on: https://go-review.googlesource.com/c/go/+/196557 Run-TryBot: Michael Munday <mike.munday@ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Keith Randall <khr@golang.org>
2019-08-12 20:19:58 +01:00
for _, v := range b.ControlValues() {
if s.values[v.ID].needReg {
s.addUse(v.ID, int32(len(b.Values)), b.Pos) // pseudo-use by control values
regValLiveSet.add(v.ID)
}
}
if len(s.nextCall) < len(b.Values) {
s.nextCall = append(s.nextCall, make([]int32, len(b.Values)-len(s.nextCall))...)
}
var nextCall int32 = math.MaxInt32
for i := len(b.Values) - 1; i >= 0; i-- {
v := b.Values[i]
cmd/compile: improve startRegs calculation In register allocation, we calculate what values are used in and after the current block. If a value is used only after a function call, since registers are clobbered in call, we don't need to mark the value live at the entrance of the block. Before this CL it is considered live, and unnecessary copy or load may be generated when resolving merge edge. Fixes #14761. On AMD64: name old time/op new time/op delta BinaryTree17-12 2.84s ± 1% 2.81s ± 1% -1.06% (p=0.000 n=10+9) Fannkuch11-12 3.61s ± 0% 3.55s ± 1% -1.77% (p=0.000 n=10+9) FmtFprintfEmpty-12 50.4ns ± 4% 50.0ns ± 1% ~ (p=0.785 n=9+8) FmtFprintfString-12 80.0ns ± 3% 78.2ns ± 3% -2.35% (p=0.004 n=10+9) FmtFprintfInt-12 81.3ns ± 4% 81.8ns ± 2% ~ (p=0.159 n=10+10) FmtFprintfIntInt-12 120ns ± 4% 118ns ± 2% ~ (p=0.218 n=10+10) FmtFprintfPrefixedInt-12 152ns ± 3% 155ns ± 2% +2.11% (p=0.026 n=10+10) FmtFprintfFloat-12 240ns ± 1% 238ns ± 1% -0.79% (p=0.005 n=9+9) FmtManyArgs-12 504ns ± 1% 510ns ± 1% +1.14% (p=0.000 n=8+9) GobDecode-12 7.00ms ± 1% 6.99ms ± 0% ~ (p=0.497 n=9+10) GobEncode-12 5.47ms ± 1% 5.48ms ± 1% ~ (p=0.218 n=10+10) Gzip-12 258ms ± 2% 256ms ± 1% -0.96% (p=0.043 n=10+9) Gunzip-12 38.6ms ± 0% 38.3ms ± 0% -0.64% (p=0.000 n=9+8) HTTPClientServer-12 90.4µs ± 3% 87.2µs ±11% ~ (p=0.053 n=9+10) JSONEncode-12 15.6ms ± 0% 15.6ms ± 1% ~ (p=0.077 n=9+9) JSONDecode-12 55.1ms ± 1% 54.6ms ± 1% -0.85% (p=0.010 n=10+9) Mandelbrot200-12 4.49ms ± 0% 4.47ms ± 0% -0.25% (p=0.000 n=10+8) GoParse-12 3.38ms ± 0% 3.37ms ± 1% ~ (p=0.315 n=8+10) RegexpMatchEasy0_32-12 82.5ns ± 4% 82.0ns ± 0% ~ (p=0.164 n=10+8) RegexpMatchEasy0_1K-12 203ns ± 1% 202ns ± 1% -0.85% (p=0.000 n=9+10) RegexpMatchEasy1_32-12 82.3ns ± 1% 81.1ns ± 0% -1.39% (p=0.000 n=10+8) RegexpMatchEasy1_1K-12 357ns ± 1% 357ns ± 1% ~ (p=0.697 n=8+9) RegexpMatchMedium_32-12 125ns ± 2% 126ns ± 2% ~ (p=0.197 n=10+10) RegexpMatchMedium_1K-12 39.6µs ± 3% 39.6µs ± 1% ~ (p=0.971 n=10+10) RegexpMatchHard_32-12 1.99µs ± 2% 1.99µs ± 4% ~ (p=0.891 n=10+9) RegexpMatchHard_1K-12 60.1µs ± 3% 60.4µs ± 3% ~ (p=0.684 n=10+10) Revcomp-12 531ms ± 6% 441ms ± 0% -16.94% (p=0.000 n=10+9) Template-12 58.9ms ± 1% 58.7ms ± 1% ~ (p=0.315 n=10+10) TimeParse-12 319ns ± 1% 320ns ± 4% ~ (p=0.215 n=9+9) TimeFormat-12 345ns ± 0% 333ns ± 1% -3.36% (p=0.000 n=9+10) [Geo mean] 52.2µs 51.6µs -1.13% On ARM64: name old time/op new time/op delta BinaryTree17-8 8.53s ± 0% 8.36s ± 0% -1.89% (p=0.000 n=10+10) Fannkuch11-8 6.15s ± 0% 6.10s ± 0% -0.67% (p=0.000 n=10+10) FmtFprintfEmpty-8 117ns ± 0% 117ns ± 0% ~ (all equal) FmtFprintfString-8 192ns ± 0% 192ns ± 0% ~ (all equal) FmtFprintfInt-8 198ns ± 0% 198ns ± 0% ~ (p=0.211 n=10+10) FmtFprintfIntInt-8 289ns ± 0% 291ns ± 0% +0.59% (p=0.000 n=7+10) FmtFprintfPrefixedInt-8 320ns ± 2% 317ns ± 0% ~ (p=0.431 n=10+8) FmtFprintfFloat-8 538ns ± 0% 538ns ± 0% ~ (all equal) FmtManyArgs-8 1.17µs ± 1% 1.18µs ± 1% ~ (p=0.063 n=10+10) GobDecode-8 17.0ms ± 1% 17.2ms ± 1% +0.83% (p=0.000 n=10+10) GobEncode-8 14.2ms ± 0% 14.1ms ± 1% -0.78% (p=0.001 n=9+10) Gzip-8 806ms ± 0% 797ms ± 0% -1.12% (p=0.000 n=6+9) Gunzip-8 131ms ± 0% 130ms ± 0% -0.51% (p=0.000 n=10+9) HTTPClientServer-8 206µs ± 9% 212µs ± 2% ~ (p=0.829 n=10+8) JSONEncode-8 40.1ms ± 0% 40.1ms ± 0% ~ (p=0.136 n=9+9) JSONDecode-8 157ms ± 0% 151ms ± 0% -3.32% (p=0.000 n=9+9) Mandelbrot200-8 10.1ms ± 0% 10.1ms ± 0% -0.05% (p=0.000 n=9+8) GoParse-8 8.43ms ± 0% 8.43ms ± 0% ~ (p=0.912 n=10+10) RegexpMatchEasy0_32-8 228ns ± 1% 227ns ± 0% -0.26% (p=0.026 n=10+9) RegexpMatchEasy0_1K-8 1.92µs ± 0% 1.63µs ± 0% -15.18% (p=0.001 n=7+7) RegexpMatchEasy1_32-8 258ns ± 1% 250ns ± 0% -2.83% (p=0.000 n=10+10) RegexpMatchEasy1_1K-8 2.39µs ± 0% 2.13µs ± 0% -10.94% (p=0.000 n=9+9) RegexpMatchMedium_32-8 352ns ± 0% 351ns ± 0% -0.29% (p=0.004 n=9+10) RegexpMatchMedium_1K-8 104µs ± 0% 105µs ± 0% +0.58% (p=0.000 n=8+9) RegexpMatchHard_32-8 5.84µs ± 0% 5.82µs ± 0% -0.27% (p=0.000 n=9+10) RegexpMatchHard_1K-8 177µs ± 0% 177µs ± 0% -0.07% (p=0.000 n=9+9) Revcomp-8 1.57s ± 1% 1.50s ± 1% -4.60% (p=0.000 n=9+10) Template-8 157ms ± 1% 153ms ± 1% -2.28% (p=0.000 n=10+9) TimeParse-8 779ns ± 1% 770ns ± 1% -1.18% (p=0.013 n=10+10) TimeFormat-8 823ns ± 2% 826ns ± 1% ~ (p=0.324 n=10+9) [Geo mean] 144µs 142µs -1.45% Reduce cmd/go text size by 0.5%. Change-Id: I9288ff983c4a7cf03fc0cb35b9b1750828013117 Reviewed-on: https://go-review.googlesource.com/38457 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2017-03-22 21:34:12 -04:00
regValLiveSet.remove(v.ID)
if v.Op == OpPhi {
// Remove v from the live set, but don't add
// any inputs. This is the state the len(b.Preds)>1
// case below desires; it wants to process phis specially.
s.nextCall[i] = nextCall
continue
}
cmd/compile: improve startRegs calculation In register allocation, we calculate what values are used in and after the current block. If a value is used only after a function call, since registers are clobbered in call, we don't need to mark the value live at the entrance of the block. Before this CL it is considered live, and unnecessary copy or load may be generated when resolving merge edge. Fixes #14761. On AMD64: name old time/op new time/op delta BinaryTree17-12 2.84s ± 1% 2.81s ± 1% -1.06% (p=0.000 n=10+9) Fannkuch11-12 3.61s ± 0% 3.55s ± 1% -1.77% (p=0.000 n=10+9) FmtFprintfEmpty-12 50.4ns ± 4% 50.0ns ± 1% ~ (p=0.785 n=9+8) FmtFprintfString-12 80.0ns ± 3% 78.2ns ± 3% -2.35% (p=0.004 n=10+9) FmtFprintfInt-12 81.3ns ± 4% 81.8ns ± 2% ~ (p=0.159 n=10+10) FmtFprintfIntInt-12 120ns ± 4% 118ns ± 2% ~ (p=0.218 n=10+10) FmtFprintfPrefixedInt-12 152ns ± 3% 155ns ± 2% +2.11% (p=0.026 n=10+10) FmtFprintfFloat-12 240ns ± 1% 238ns ± 1% -0.79% (p=0.005 n=9+9) FmtManyArgs-12 504ns ± 1% 510ns ± 1% +1.14% (p=0.000 n=8+9) GobDecode-12 7.00ms ± 1% 6.99ms ± 0% ~ (p=0.497 n=9+10) GobEncode-12 5.47ms ± 1% 5.48ms ± 1% ~ (p=0.218 n=10+10) Gzip-12 258ms ± 2% 256ms ± 1% -0.96% (p=0.043 n=10+9) Gunzip-12 38.6ms ± 0% 38.3ms ± 0% -0.64% (p=0.000 n=9+8) HTTPClientServer-12 90.4µs ± 3% 87.2µs ±11% ~ (p=0.053 n=9+10) JSONEncode-12 15.6ms ± 0% 15.6ms ± 1% ~ (p=0.077 n=9+9) JSONDecode-12 55.1ms ± 1% 54.6ms ± 1% -0.85% (p=0.010 n=10+9) Mandelbrot200-12 4.49ms ± 0% 4.47ms ± 0% -0.25% (p=0.000 n=10+8) GoParse-12 3.38ms ± 0% 3.37ms ± 1% ~ (p=0.315 n=8+10) RegexpMatchEasy0_32-12 82.5ns ± 4% 82.0ns ± 0% ~ (p=0.164 n=10+8) RegexpMatchEasy0_1K-12 203ns ± 1% 202ns ± 1% -0.85% (p=0.000 n=9+10) RegexpMatchEasy1_32-12 82.3ns ± 1% 81.1ns ± 0% -1.39% (p=0.000 n=10+8) RegexpMatchEasy1_1K-12 357ns ± 1% 357ns ± 1% ~ (p=0.697 n=8+9) RegexpMatchMedium_32-12 125ns ± 2% 126ns ± 2% ~ (p=0.197 n=10+10) RegexpMatchMedium_1K-12 39.6µs ± 3% 39.6µs ± 1% ~ (p=0.971 n=10+10) RegexpMatchHard_32-12 1.99µs ± 2% 1.99µs ± 4% ~ (p=0.891 n=10+9) RegexpMatchHard_1K-12 60.1µs ± 3% 60.4µs ± 3% ~ (p=0.684 n=10+10) Revcomp-12 531ms ± 6% 441ms ± 0% -16.94% (p=0.000 n=10+9) Template-12 58.9ms ± 1% 58.7ms ± 1% ~ (p=0.315 n=10+10) TimeParse-12 319ns ± 1% 320ns ± 4% ~ (p=0.215 n=9+9) TimeFormat-12 345ns ± 0% 333ns ± 1% -3.36% (p=0.000 n=9+10) [Geo mean] 52.2µs 51.6µs -1.13% On ARM64: name old time/op new time/op delta BinaryTree17-8 8.53s ± 0% 8.36s ± 0% -1.89% (p=0.000 n=10+10) Fannkuch11-8 6.15s ± 0% 6.10s ± 0% -0.67% (p=0.000 n=10+10) FmtFprintfEmpty-8 117ns ± 0% 117ns ± 0% ~ (all equal) FmtFprintfString-8 192ns ± 0% 192ns ± 0% ~ (all equal) FmtFprintfInt-8 198ns ± 0% 198ns ± 0% ~ (p=0.211 n=10+10) FmtFprintfIntInt-8 289ns ± 0% 291ns ± 0% +0.59% (p=0.000 n=7+10) FmtFprintfPrefixedInt-8 320ns ± 2% 317ns ± 0% ~ (p=0.431 n=10+8) FmtFprintfFloat-8 538ns ± 0% 538ns ± 0% ~ (all equal) FmtManyArgs-8 1.17µs ± 1% 1.18µs ± 1% ~ (p=0.063 n=10+10) GobDecode-8 17.0ms ± 1% 17.2ms ± 1% +0.83% (p=0.000 n=10+10) GobEncode-8 14.2ms ± 0% 14.1ms ± 1% -0.78% (p=0.001 n=9+10) Gzip-8 806ms ± 0% 797ms ± 0% -1.12% (p=0.000 n=6+9) Gunzip-8 131ms ± 0% 130ms ± 0% -0.51% (p=0.000 n=10+9) HTTPClientServer-8 206µs ± 9% 212µs ± 2% ~ (p=0.829 n=10+8) JSONEncode-8 40.1ms ± 0% 40.1ms ± 0% ~ (p=0.136 n=9+9) JSONDecode-8 157ms ± 0% 151ms ± 0% -3.32% (p=0.000 n=9+9) Mandelbrot200-8 10.1ms ± 0% 10.1ms ± 0% -0.05% (p=0.000 n=9+8) GoParse-8 8.43ms ± 0% 8.43ms ± 0% ~ (p=0.912 n=10+10) RegexpMatchEasy0_32-8 228ns ± 1% 227ns ± 0% -0.26% (p=0.026 n=10+9) RegexpMatchEasy0_1K-8 1.92µs ± 0% 1.63µs ± 0% -15.18% (p=0.001 n=7+7) RegexpMatchEasy1_32-8 258ns ± 1% 250ns ± 0% -2.83% (p=0.000 n=10+10) RegexpMatchEasy1_1K-8 2.39µs ± 0% 2.13µs ± 0% -10.94% (p=0.000 n=9+9) RegexpMatchMedium_32-8 352ns ± 0% 351ns ± 0% -0.29% (p=0.004 n=9+10) RegexpMatchMedium_1K-8 104µs ± 0% 105µs ± 0% +0.58% (p=0.000 n=8+9) RegexpMatchHard_32-8 5.84µs ± 0% 5.82µs ± 0% -0.27% (p=0.000 n=9+10) RegexpMatchHard_1K-8 177µs ± 0% 177µs ± 0% -0.07% (p=0.000 n=9+9) Revcomp-8 1.57s ± 1% 1.50s ± 1% -4.60% (p=0.000 n=9+10) Template-8 157ms ± 1% 153ms ± 1% -2.28% (p=0.000 n=10+9) TimeParse-8 779ns ± 1% 770ns ± 1% -1.18% (p=0.013 n=10+10) TimeFormat-8 823ns ± 2% 826ns ± 1% ~ (p=0.324 n=10+9) [Geo mean] 144µs 142µs -1.45% Reduce cmd/go text size by 0.5%. Change-Id: I9288ff983c4a7cf03fc0cb35b9b1750828013117 Reviewed-on: https://go-review.googlesource.com/38457 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2017-03-22 21:34:12 -04:00
if opcodeTable[v.Op].call {
// Function call clobbers all the registers but SP and SB.
regValLiveSet.clear()
if s.sp != 0 && s.values[s.sp].uses != nil {
regValLiveSet.add(s.sp)
}
if s.sb != 0 && s.values[s.sb].uses != nil {
regValLiveSet.add(s.sb)
}
nextCall = int32(i)
cmd/compile: improve startRegs calculation In register allocation, we calculate what values are used in and after the current block. If a value is used only after a function call, since registers are clobbered in call, we don't need to mark the value live at the entrance of the block. Before this CL it is considered live, and unnecessary copy or load may be generated when resolving merge edge. Fixes #14761. On AMD64: name old time/op new time/op delta BinaryTree17-12 2.84s ± 1% 2.81s ± 1% -1.06% (p=0.000 n=10+9) Fannkuch11-12 3.61s ± 0% 3.55s ± 1% -1.77% (p=0.000 n=10+9) FmtFprintfEmpty-12 50.4ns ± 4% 50.0ns ± 1% ~ (p=0.785 n=9+8) FmtFprintfString-12 80.0ns ± 3% 78.2ns ± 3% -2.35% (p=0.004 n=10+9) FmtFprintfInt-12 81.3ns ± 4% 81.8ns ± 2% ~ (p=0.159 n=10+10) FmtFprintfIntInt-12 120ns ± 4% 118ns ± 2% ~ (p=0.218 n=10+10) FmtFprintfPrefixedInt-12 152ns ± 3% 155ns ± 2% +2.11% (p=0.026 n=10+10) FmtFprintfFloat-12 240ns ± 1% 238ns ± 1% -0.79% (p=0.005 n=9+9) FmtManyArgs-12 504ns ± 1% 510ns ± 1% +1.14% (p=0.000 n=8+9) GobDecode-12 7.00ms ± 1% 6.99ms ± 0% ~ (p=0.497 n=9+10) GobEncode-12 5.47ms ± 1% 5.48ms ± 1% ~ (p=0.218 n=10+10) Gzip-12 258ms ± 2% 256ms ± 1% -0.96% (p=0.043 n=10+9) Gunzip-12 38.6ms ± 0% 38.3ms ± 0% -0.64% (p=0.000 n=9+8) HTTPClientServer-12 90.4µs ± 3% 87.2µs ±11% ~ (p=0.053 n=9+10) JSONEncode-12 15.6ms ± 0% 15.6ms ± 1% ~ (p=0.077 n=9+9) JSONDecode-12 55.1ms ± 1% 54.6ms ± 1% -0.85% (p=0.010 n=10+9) Mandelbrot200-12 4.49ms ± 0% 4.47ms ± 0% -0.25% (p=0.000 n=10+8) GoParse-12 3.38ms ± 0% 3.37ms ± 1% ~ (p=0.315 n=8+10) RegexpMatchEasy0_32-12 82.5ns ± 4% 82.0ns ± 0% ~ (p=0.164 n=10+8) RegexpMatchEasy0_1K-12 203ns ± 1% 202ns ± 1% -0.85% (p=0.000 n=9+10) RegexpMatchEasy1_32-12 82.3ns ± 1% 81.1ns ± 0% -1.39% (p=0.000 n=10+8) RegexpMatchEasy1_1K-12 357ns ± 1% 357ns ± 1% ~ (p=0.697 n=8+9) RegexpMatchMedium_32-12 125ns ± 2% 126ns ± 2% ~ (p=0.197 n=10+10) RegexpMatchMedium_1K-12 39.6µs ± 3% 39.6µs ± 1% ~ (p=0.971 n=10+10) RegexpMatchHard_32-12 1.99µs ± 2% 1.99µs ± 4% ~ (p=0.891 n=10+9) RegexpMatchHard_1K-12 60.1µs ± 3% 60.4µs ± 3% ~ (p=0.684 n=10+10) Revcomp-12 531ms ± 6% 441ms ± 0% -16.94% (p=0.000 n=10+9) Template-12 58.9ms ± 1% 58.7ms ± 1% ~ (p=0.315 n=10+10) TimeParse-12 319ns ± 1% 320ns ± 4% ~ (p=0.215 n=9+9) TimeFormat-12 345ns ± 0% 333ns ± 1% -3.36% (p=0.000 n=9+10) [Geo mean] 52.2µs 51.6µs -1.13% On ARM64: name old time/op new time/op delta BinaryTree17-8 8.53s ± 0% 8.36s ± 0% -1.89% (p=0.000 n=10+10) Fannkuch11-8 6.15s ± 0% 6.10s ± 0% -0.67% (p=0.000 n=10+10) FmtFprintfEmpty-8 117ns ± 0% 117ns ± 0% ~ (all equal) FmtFprintfString-8 192ns ± 0% 192ns ± 0% ~ (all equal) FmtFprintfInt-8 198ns ± 0% 198ns ± 0% ~ (p=0.211 n=10+10) FmtFprintfIntInt-8 289ns ± 0% 291ns ± 0% +0.59% (p=0.000 n=7+10) FmtFprintfPrefixedInt-8 320ns ± 2% 317ns ± 0% ~ (p=0.431 n=10+8) FmtFprintfFloat-8 538ns ± 0% 538ns ± 0% ~ (all equal) FmtManyArgs-8 1.17µs ± 1% 1.18µs ± 1% ~ (p=0.063 n=10+10) GobDecode-8 17.0ms ± 1% 17.2ms ± 1% +0.83% (p=0.000 n=10+10) GobEncode-8 14.2ms ± 0% 14.1ms ± 1% -0.78% (p=0.001 n=9+10) Gzip-8 806ms ± 0% 797ms ± 0% -1.12% (p=0.000 n=6+9) Gunzip-8 131ms ± 0% 130ms ± 0% -0.51% (p=0.000 n=10+9) HTTPClientServer-8 206µs ± 9% 212µs ± 2% ~ (p=0.829 n=10+8) JSONEncode-8 40.1ms ± 0% 40.1ms ± 0% ~ (p=0.136 n=9+9) JSONDecode-8 157ms ± 0% 151ms ± 0% -3.32% (p=0.000 n=9+9) Mandelbrot200-8 10.1ms ± 0% 10.1ms ± 0% -0.05% (p=0.000 n=9+8) GoParse-8 8.43ms ± 0% 8.43ms ± 0% ~ (p=0.912 n=10+10) RegexpMatchEasy0_32-8 228ns ± 1% 227ns ± 0% -0.26% (p=0.026 n=10+9) RegexpMatchEasy0_1K-8 1.92µs ± 0% 1.63µs ± 0% -15.18% (p=0.001 n=7+7) RegexpMatchEasy1_32-8 258ns ± 1% 250ns ± 0% -2.83% (p=0.000 n=10+10) RegexpMatchEasy1_1K-8 2.39µs ± 0% 2.13µs ± 0% -10.94% (p=0.000 n=9+9) RegexpMatchMedium_32-8 352ns ± 0% 351ns ± 0% -0.29% (p=0.004 n=9+10) RegexpMatchMedium_1K-8 104µs ± 0% 105µs ± 0% +0.58% (p=0.000 n=8+9) RegexpMatchHard_32-8 5.84µs ± 0% 5.82µs ± 0% -0.27% (p=0.000 n=9+10) RegexpMatchHard_1K-8 177µs ± 0% 177µs ± 0% -0.07% (p=0.000 n=9+9) Revcomp-8 1.57s ± 1% 1.50s ± 1% -4.60% (p=0.000 n=9+10) Template-8 157ms ± 1% 153ms ± 1% -2.28% (p=0.000 n=10+9) TimeParse-8 779ns ± 1% 770ns ± 1% -1.18% (p=0.013 n=10+10) TimeFormat-8 823ns ± 2% 826ns ± 1% ~ (p=0.324 n=10+9) [Geo mean] 144µs 142µs -1.45% Reduce cmd/go text size by 0.5%. Change-Id: I9288ff983c4a7cf03fc0cb35b9b1750828013117 Reviewed-on: https://go-review.googlesource.com/38457 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2017-03-22 21:34:12 -04:00
}
for _, a := range v.Args {
if !s.values[a.ID].needReg {
continue
}
s.addUse(a.ID, int32(i), v.Pos)
cmd/compile: improve startRegs calculation In register allocation, we calculate what values are used in and after the current block. If a value is used only after a function call, since registers are clobbered in call, we don't need to mark the value live at the entrance of the block. Before this CL it is considered live, and unnecessary copy or load may be generated when resolving merge edge. Fixes #14761. On AMD64: name old time/op new time/op delta BinaryTree17-12 2.84s ± 1% 2.81s ± 1% -1.06% (p=0.000 n=10+9) Fannkuch11-12 3.61s ± 0% 3.55s ± 1% -1.77% (p=0.000 n=10+9) FmtFprintfEmpty-12 50.4ns ± 4% 50.0ns ± 1% ~ (p=0.785 n=9+8) FmtFprintfString-12 80.0ns ± 3% 78.2ns ± 3% -2.35% (p=0.004 n=10+9) FmtFprintfInt-12 81.3ns ± 4% 81.8ns ± 2% ~ (p=0.159 n=10+10) FmtFprintfIntInt-12 120ns ± 4% 118ns ± 2% ~ (p=0.218 n=10+10) FmtFprintfPrefixedInt-12 152ns ± 3% 155ns ± 2% +2.11% (p=0.026 n=10+10) FmtFprintfFloat-12 240ns ± 1% 238ns ± 1% -0.79% (p=0.005 n=9+9) FmtManyArgs-12 504ns ± 1% 510ns ± 1% +1.14% (p=0.000 n=8+9) GobDecode-12 7.00ms ± 1% 6.99ms ± 0% ~ (p=0.497 n=9+10) GobEncode-12 5.47ms ± 1% 5.48ms ± 1% ~ (p=0.218 n=10+10) Gzip-12 258ms ± 2% 256ms ± 1% -0.96% (p=0.043 n=10+9) Gunzip-12 38.6ms ± 0% 38.3ms ± 0% -0.64% (p=0.000 n=9+8) HTTPClientServer-12 90.4µs ± 3% 87.2µs ±11% ~ (p=0.053 n=9+10) JSONEncode-12 15.6ms ± 0% 15.6ms ± 1% ~ (p=0.077 n=9+9) JSONDecode-12 55.1ms ± 1% 54.6ms ± 1% -0.85% (p=0.010 n=10+9) Mandelbrot200-12 4.49ms ± 0% 4.47ms ± 0% -0.25% (p=0.000 n=10+8) GoParse-12 3.38ms ± 0% 3.37ms ± 1% ~ (p=0.315 n=8+10) RegexpMatchEasy0_32-12 82.5ns ± 4% 82.0ns ± 0% ~ (p=0.164 n=10+8) RegexpMatchEasy0_1K-12 203ns ± 1% 202ns ± 1% -0.85% (p=0.000 n=9+10) RegexpMatchEasy1_32-12 82.3ns ± 1% 81.1ns ± 0% -1.39% (p=0.000 n=10+8) RegexpMatchEasy1_1K-12 357ns ± 1% 357ns ± 1% ~ (p=0.697 n=8+9) RegexpMatchMedium_32-12 125ns ± 2% 126ns ± 2% ~ (p=0.197 n=10+10) RegexpMatchMedium_1K-12 39.6µs ± 3% 39.6µs ± 1% ~ (p=0.971 n=10+10) RegexpMatchHard_32-12 1.99µs ± 2% 1.99µs ± 4% ~ (p=0.891 n=10+9) RegexpMatchHard_1K-12 60.1µs ± 3% 60.4µs ± 3% ~ (p=0.684 n=10+10) Revcomp-12 531ms ± 6% 441ms ± 0% -16.94% (p=0.000 n=10+9) Template-12 58.9ms ± 1% 58.7ms ± 1% ~ (p=0.315 n=10+10) TimeParse-12 319ns ± 1% 320ns ± 4% ~ (p=0.215 n=9+9) TimeFormat-12 345ns ± 0% 333ns ± 1% -3.36% (p=0.000 n=9+10) [Geo mean] 52.2µs 51.6µs -1.13% On ARM64: name old time/op new time/op delta BinaryTree17-8 8.53s ± 0% 8.36s ± 0% -1.89% (p=0.000 n=10+10) Fannkuch11-8 6.15s ± 0% 6.10s ± 0% -0.67% (p=0.000 n=10+10) FmtFprintfEmpty-8 117ns ± 0% 117ns ± 0% ~ (all equal) FmtFprintfString-8 192ns ± 0% 192ns ± 0% ~ (all equal) FmtFprintfInt-8 198ns ± 0% 198ns ± 0% ~ (p=0.211 n=10+10) FmtFprintfIntInt-8 289ns ± 0% 291ns ± 0% +0.59% (p=0.000 n=7+10) FmtFprintfPrefixedInt-8 320ns ± 2% 317ns ± 0% ~ (p=0.431 n=10+8) FmtFprintfFloat-8 538ns ± 0% 538ns ± 0% ~ (all equal) FmtManyArgs-8 1.17µs ± 1% 1.18µs ± 1% ~ (p=0.063 n=10+10) GobDecode-8 17.0ms ± 1% 17.2ms ± 1% +0.83% (p=0.000 n=10+10) GobEncode-8 14.2ms ± 0% 14.1ms ± 1% -0.78% (p=0.001 n=9+10) Gzip-8 806ms ± 0% 797ms ± 0% -1.12% (p=0.000 n=6+9) Gunzip-8 131ms ± 0% 130ms ± 0% -0.51% (p=0.000 n=10+9) HTTPClientServer-8 206µs ± 9% 212µs ± 2% ~ (p=0.829 n=10+8) JSONEncode-8 40.1ms ± 0% 40.1ms ± 0% ~ (p=0.136 n=9+9) JSONDecode-8 157ms ± 0% 151ms ± 0% -3.32% (p=0.000 n=9+9) Mandelbrot200-8 10.1ms ± 0% 10.1ms ± 0% -0.05% (p=0.000 n=9+8) GoParse-8 8.43ms ± 0% 8.43ms ± 0% ~ (p=0.912 n=10+10) RegexpMatchEasy0_32-8 228ns ± 1% 227ns ± 0% -0.26% (p=0.026 n=10+9) RegexpMatchEasy0_1K-8 1.92µs ± 0% 1.63µs ± 0% -15.18% (p=0.001 n=7+7) RegexpMatchEasy1_32-8 258ns ± 1% 250ns ± 0% -2.83% (p=0.000 n=10+10) RegexpMatchEasy1_1K-8 2.39µs ± 0% 2.13µs ± 0% -10.94% (p=0.000 n=9+9) RegexpMatchMedium_32-8 352ns ± 0% 351ns ± 0% -0.29% (p=0.004 n=9+10) RegexpMatchMedium_1K-8 104µs ± 0% 105µs ± 0% +0.58% (p=0.000 n=8+9) RegexpMatchHard_32-8 5.84µs ± 0% 5.82µs ± 0% -0.27% (p=0.000 n=9+10) RegexpMatchHard_1K-8 177µs ± 0% 177µs ± 0% -0.07% (p=0.000 n=9+9) Revcomp-8 1.57s ± 1% 1.50s ± 1% -4.60% (p=0.000 n=9+10) Template-8 157ms ± 1% 153ms ± 1% -2.28% (p=0.000 n=10+9) TimeParse-8 779ns ± 1% 770ns ± 1% -1.18% (p=0.013 n=10+10) TimeFormat-8 823ns ± 2% 826ns ± 1% ~ (p=0.324 n=10+9) [Geo mean] 144µs 142µs -1.45% Reduce cmd/go text size by 0.5%. Change-Id: I9288ff983c4a7cf03fc0cb35b9b1750828013117 Reviewed-on: https://go-review.googlesource.com/38457 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2017-03-22 21:34:12 -04:00
regValLiveSet.add(a.ID)
}
s.nextCall[i] = nextCall
}
if s.f.pass.debug > regDebug {
fmt.Printf("use distances for %s\n", b)
for i := range s.values {
vi := &s.values[i]
u := vi.uses
if u == nil {
continue
}
fmt.Printf(" v%d:", i)
for u != nil {
fmt.Printf(" %d", u.dist)
u = u.next
}
fmt.Println()
}
}
// Make a copy of the block schedule so we can generate a new one in place.
// We make a separate copy for phis and regular values.
nphi := 0
for _, v := range b.Values {
if v.Op != OpPhi {
break
}
nphi++
}
phis = append(phis[:0], b.Values[:nphi]...)
oldSched = append(oldSched[:0], b.Values[nphi:]...)
b.Values = b.Values[:0]
// Initialize start state of block.
if b == f.Entry {
// Regalloc state is empty to start.
if nphi > 0 {
f.Fatalf("phis in entry block")
}
} else if len(b.Preds) == 1 {
// Start regalloc state with the end state of the previous block.
s.setState(s.endRegs[b.Preds[0].b.ID])
if nphi > 0 {
f.Fatalf("phis in single-predecessor block")
}
// Drop any values which are no longer live.
// This may happen because at the end of p, a value may be
// live but only used by some other successor of p.
for r := register(0); r < s.numRegs; r++ {
v := s.regs[r].v
cmd/compile: improve startRegs calculation In register allocation, we calculate what values are used in and after the current block. If a value is used only after a function call, since registers are clobbered in call, we don't need to mark the value live at the entrance of the block. Before this CL it is considered live, and unnecessary copy or load may be generated when resolving merge edge. Fixes #14761. On AMD64: name old time/op new time/op delta BinaryTree17-12 2.84s ± 1% 2.81s ± 1% -1.06% (p=0.000 n=10+9) Fannkuch11-12 3.61s ± 0% 3.55s ± 1% -1.77% (p=0.000 n=10+9) FmtFprintfEmpty-12 50.4ns ± 4% 50.0ns ± 1% ~ (p=0.785 n=9+8) FmtFprintfString-12 80.0ns ± 3% 78.2ns ± 3% -2.35% (p=0.004 n=10+9) FmtFprintfInt-12 81.3ns ± 4% 81.8ns ± 2% ~ (p=0.159 n=10+10) FmtFprintfIntInt-12 120ns ± 4% 118ns ± 2% ~ (p=0.218 n=10+10) FmtFprintfPrefixedInt-12 152ns ± 3% 155ns ± 2% +2.11% (p=0.026 n=10+10) FmtFprintfFloat-12 240ns ± 1% 238ns ± 1% -0.79% (p=0.005 n=9+9) FmtManyArgs-12 504ns ± 1% 510ns ± 1% +1.14% (p=0.000 n=8+9) GobDecode-12 7.00ms ± 1% 6.99ms ± 0% ~ (p=0.497 n=9+10) GobEncode-12 5.47ms ± 1% 5.48ms ± 1% ~ (p=0.218 n=10+10) Gzip-12 258ms ± 2% 256ms ± 1% -0.96% (p=0.043 n=10+9) Gunzip-12 38.6ms ± 0% 38.3ms ± 0% -0.64% (p=0.000 n=9+8) HTTPClientServer-12 90.4µs ± 3% 87.2µs ±11% ~ (p=0.053 n=9+10) JSONEncode-12 15.6ms ± 0% 15.6ms ± 1% ~ (p=0.077 n=9+9) JSONDecode-12 55.1ms ± 1% 54.6ms ± 1% -0.85% (p=0.010 n=10+9) Mandelbrot200-12 4.49ms ± 0% 4.47ms ± 0% -0.25% (p=0.000 n=10+8) GoParse-12 3.38ms ± 0% 3.37ms ± 1% ~ (p=0.315 n=8+10) RegexpMatchEasy0_32-12 82.5ns ± 4% 82.0ns ± 0% ~ (p=0.164 n=10+8) RegexpMatchEasy0_1K-12 203ns ± 1% 202ns ± 1% -0.85% (p=0.000 n=9+10) RegexpMatchEasy1_32-12 82.3ns ± 1% 81.1ns ± 0% -1.39% (p=0.000 n=10+8) RegexpMatchEasy1_1K-12 357ns ± 1% 357ns ± 1% ~ (p=0.697 n=8+9) RegexpMatchMedium_32-12 125ns ± 2% 126ns ± 2% ~ (p=0.197 n=10+10) RegexpMatchMedium_1K-12 39.6µs ± 3% 39.6µs ± 1% ~ (p=0.971 n=10+10) RegexpMatchHard_32-12 1.99µs ± 2% 1.99µs ± 4% ~ (p=0.891 n=10+9) RegexpMatchHard_1K-12 60.1µs ± 3% 60.4µs ± 3% ~ (p=0.684 n=10+10) Revcomp-12 531ms ± 6% 441ms ± 0% -16.94% (p=0.000 n=10+9) Template-12 58.9ms ± 1% 58.7ms ± 1% ~ (p=0.315 n=10+10) TimeParse-12 319ns ± 1% 320ns ± 4% ~ (p=0.215 n=9+9) TimeFormat-12 345ns ± 0% 333ns ± 1% -3.36% (p=0.000 n=9+10) [Geo mean] 52.2µs 51.6µs -1.13% On ARM64: name old time/op new time/op delta BinaryTree17-8 8.53s ± 0% 8.36s ± 0% -1.89% (p=0.000 n=10+10) Fannkuch11-8 6.15s ± 0% 6.10s ± 0% -0.67% (p=0.000 n=10+10) FmtFprintfEmpty-8 117ns ± 0% 117ns ± 0% ~ (all equal) FmtFprintfString-8 192ns ± 0% 192ns ± 0% ~ (all equal) FmtFprintfInt-8 198ns ± 0% 198ns ± 0% ~ (p=0.211 n=10+10) FmtFprintfIntInt-8 289ns ± 0% 291ns ± 0% +0.59% (p=0.000 n=7+10) FmtFprintfPrefixedInt-8 320ns ± 2% 317ns ± 0% ~ (p=0.431 n=10+8) FmtFprintfFloat-8 538ns ± 0% 538ns ± 0% ~ (all equal) FmtManyArgs-8 1.17µs ± 1% 1.18µs ± 1% ~ (p=0.063 n=10+10) GobDecode-8 17.0ms ± 1% 17.2ms ± 1% +0.83% (p=0.000 n=10+10) GobEncode-8 14.2ms ± 0% 14.1ms ± 1% -0.78% (p=0.001 n=9+10) Gzip-8 806ms ± 0% 797ms ± 0% -1.12% (p=0.000 n=6+9) Gunzip-8 131ms ± 0% 130ms ± 0% -0.51% (p=0.000 n=10+9) HTTPClientServer-8 206µs ± 9% 212µs ± 2% ~ (p=0.829 n=10+8) JSONEncode-8 40.1ms ± 0% 40.1ms ± 0% ~ (p=0.136 n=9+9) JSONDecode-8 157ms ± 0% 151ms ± 0% -3.32% (p=0.000 n=9+9) Mandelbrot200-8 10.1ms ± 0% 10.1ms ± 0% -0.05% (p=0.000 n=9+8) GoParse-8 8.43ms ± 0% 8.43ms ± 0% ~ (p=0.912 n=10+10) RegexpMatchEasy0_32-8 228ns ± 1% 227ns ± 0% -0.26% (p=0.026 n=10+9) RegexpMatchEasy0_1K-8 1.92µs ± 0% 1.63µs ± 0% -15.18% (p=0.001 n=7+7) RegexpMatchEasy1_32-8 258ns ± 1% 250ns ± 0% -2.83% (p=0.000 n=10+10) RegexpMatchEasy1_1K-8 2.39µs ± 0% 2.13µs ± 0% -10.94% (p=0.000 n=9+9) RegexpMatchMedium_32-8 352ns ± 0% 351ns ± 0% -0.29% (p=0.004 n=9+10) RegexpMatchMedium_1K-8 104µs ± 0% 105µs ± 0% +0.58% (p=0.000 n=8+9) RegexpMatchHard_32-8 5.84µs ± 0% 5.82µs ± 0% -0.27% (p=0.000 n=9+10) RegexpMatchHard_1K-8 177µs ± 0% 177µs ± 0% -0.07% (p=0.000 n=9+9) Revcomp-8 1.57s ± 1% 1.50s ± 1% -4.60% (p=0.000 n=9+10) Template-8 157ms ± 1% 153ms ± 1% -2.28% (p=0.000 n=10+9) TimeParse-8 779ns ± 1% 770ns ± 1% -1.18% (p=0.013 n=10+10) TimeFormat-8 823ns ± 2% 826ns ± 1% ~ (p=0.324 n=10+9) [Geo mean] 144µs 142µs -1.45% Reduce cmd/go text size by 0.5%. Change-Id: I9288ff983c4a7cf03fc0cb35b9b1750828013117 Reviewed-on: https://go-review.googlesource.com/38457 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2017-03-22 21:34:12 -04:00
if v != nil && !regValLiveSet.contains(v.ID) {
s.freeReg(r)
}
}
} else {
// This is the complicated case. We have more than one predecessor,
// which means we may have Phi ops.
cmd/compile: use depth first topological sort algorithm for layout The current layout algorithm tries to put consecutive blocks together, so the priority of the successor block is higher than the priority of the zero indegree block. This algorithm is beneficial for subsequent register allocation, but will result in more branch instructions. The depth-first topological sorting algorithm is a well-known layout algorithm, which has applications in many languages, and it helps to reduce branch instructions. This CL applies it to the layout pass. The test results show that it helps to reduce the code size. This CL also includes the following changes: 1, Removed the primary predecessor mechanism. The new layout algorithm is not very friendly to register allocator in some cases, in order to adapt to the new layout algorithm, a new primary predecessor selection strategy is introduced. 2, Since the new layout implementation may place non-loop blocks between loop blocks, some adaptive modifications have also been made to looprotate pass. 3, The layout also affects the results of codegen, so this CL also adjusted several codegen tests accordingly. It is inevitable that this CL will cause the code size or performance of a few functions to decrease, but the number of cases it improves is much larger than the number of cases it drops. Statistical data from compilecmp on linux/amd64 is as follow: name old time/op new time/op delta Template 382ms ± 4% 382ms ± 4% ~ (p=0.497 n=49+50) Unicode 170ms ± 9% 169ms ± 8% ~ (p=0.344 n=48+50) GoTypes 2.01s ± 4% 2.01s ± 4% ~ (p=0.628 n=50+48) Compiler 190ms ±10% 189ms ± 9% ~ (p=0.734 n=50+50) SSA 11.8s ± 2% 11.8s ± 3% ~ (p=0.877 n=50+50) Flate 241ms ± 9% 241ms ± 8% ~ (p=0.897 n=50+49) GoParser 366ms ± 3% 361ms ± 4% -1.21% (p=0.004 n=47+50) Reflect 835ms ± 3% 838ms ± 3% ~ (p=0.275 n=50+49) Tar 336ms ± 4% 335ms ± 3% ~ (p=0.454 n=48+48) XML 433ms ± 4% 431ms ± 3% ~ (p=0.071 n=49+48) LinkCompiler 706ms ± 4% 705ms ± 4% ~ (p=0.608 n=50+49) ExternalLinkCompiler 1.85s ± 3% 1.83s ± 2% -1.47% (p=0.000 n=49+48) LinkWithoutDebugCompiler 437ms ± 5% 437ms ± 6% ~ (p=0.953 n=49+50) [Geo mean] 615ms 613ms -0.37% name old alloc/op new alloc/op delta Template 38.7MB ± 1% 38.7MB ± 1% ~ (p=0.834 n=50+50) Unicode 28.1MB ± 0% 28.1MB ± 0% -0.22% (p=0.000 n=49+50) GoTypes 168MB ± 1% 168MB ± 1% ~ (p=0.054 n=47+47) Compiler 23.0MB ± 1% 23.0MB ± 1% ~ (p=0.432 n=50+50) SSA 1.54GB ± 0% 1.54GB ± 0% +0.21% (p=0.000 n=50+50) Flate 23.6MB ± 1% 23.6MB ± 1% ~ (p=0.153 n=43+46) GoParser 35.1MB ± 1% 35.1MB ± 2% ~ (p=0.202 n=50+50) Reflect 84.7MB ± 1% 84.7MB ± 1% ~ (p=0.333 n=48+49) Tar 34.5MB ± 1% 34.5MB ± 1% ~ (p=0.406 n=46+49) XML 44.3MB ± 2% 44.2MB ± 3% ~ (p=0.981 n=50+50) LinkCompiler 131MB ± 0% 128MB ± 0% -2.74% (p=0.000 n=50+50) ExternalLinkCompiler 120MB ± 0% 120MB ± 0% +0.01% (p=0.007 n=50+50) LinkWithoutDebugCompiler 77.3MB ± 0% 77.3MB ± 0% -0.02% (p=0.000 n=50+50) [Geo mean] 69.3MB 69.1MB -0.22% file before after Δ % addr2line 4104220 4043684 -60536 -1.475% api 5342502 5249678 -92824 -1.737% asm 4973785 4858257 -115528 -2.323% buildid 2667844 2625660 -42184 -1.581% cgo 4686849 4616313 -70536 -1.505% compile 23667431 23268406 -399025 -1.686% cover 4959676 4874108 -85568 -1.725% dist 3515934 3450422 -65512 -1.863% doc 3995581 3925469 -70112 -1.755% fix 3379202 3318522 -60680 -1.796% link 6743249 6629913 -113336 -1.681% nm 4047529 3991777 -55752 -1.377% objdump 4456151 4388151 -68000 -1.526% pack 2435040 2398072 -36968 -1.518% pprof 13804080 13565808 -238272 -1.726% test2json 2690043 2645987 -44056 -1.638% trace 10418492 10232716 -185776 -1.783% vet 7258259 7121259 -137000 -1.888% total 113145867 111204202 -1941665 -1.716% The situation on linux/arm64 is as follow: name old time/op new time/op delta Template 280ms ± 1% 282ms ± 1% +0.75% (p=0.000 n=46+48) Unicode 124ms ± 2% 124ms ± 2% +0.37% (p=0.045 n=50+50) GoTypes 1.69s ± 1% 1.70s ± 1% +0.56% (p=0.000 n=49+50) Compiler 122ms ± 1% 123ms ± 1% +0.93% (p=0.000 n=50+50) SSA 12.6s ± 1% 12.7s ± 0% +0.72% (p=0.000 n=50+50) Flate 170ms ± 1% 172ms ± 1% +0.97% (p=0.000 n=49+49) GoParser 262ms ± 1% 263ms ± 1% +0.39% (p=0.000 n=49+48) Reflect 639ms ± 1% 650ms ± 1% +1.63% (p=0.000 n=49+49) Tar 243ms ± 1% 245ms ± 1% +0.82% (p=0.000 n=50+50) XML 324ms ± 1% 327ms ± 1% +0.72% (p=0.000 n=50+49) LinkCompiler 597ms ± 1% 596ms ± 1% -0.27% (p=0.001 n=48+47) ExternalLinkCompiler 1.90s ± 1% 1.88s ± 1% -1.00% (p=0.000 n=50+50) LinkWithoutDebugCompiler 364ms ± 1% 363ms ± 1% ~ (p=0.220 n=49+50) [Geo mean] 485ms 488ms +0.49% name old alloc/op new alloc/op delta Template 38.7MB ± 0% 38.8MB ± 1% ~ (p=0.093 n=43+49) Unicode 28.4MB ± 0% 28.4MB ± 0% +0.03% (p=0.000 n=49+45) GoTypes 169MB ± 1% 169MB ± 1% +0.23% (p=0.010 n=50+50) Compiler 23.2MB ± 1% 23.2MB ± 1% +0.11% (p=0.000 n=40+44) SSA 1.54GB ± 0% 1.55GB ± 0% +0.45% (p=0.000 n=47+49) Flate 23.8MB ± 2% 23.8MB ± 1% ~ (p=0.543 n=50+50) GoParser 35.3MB ± 1% 35.4MB ± 1% ~ (p=0.792 n=50+50) Reflect 85.2MB ± 1% 85.2MB ± 0% ~ (p=0.055 n=50+47) Tar 34.5MB ± 1% 34.5MB ± 1% +0.06% (p=0.015 n=50+50) XML 43.8MB ± 2% 43.9MB ± 2% +0.19% (p=0.000 n=48+48) LinkCompiler 137MB ± 0% 136MB ± 0% -0.92% (p=0.000 n=50+50) ExternalLinkCompiler 127MB ± 0% 127MB ± 0% ~ (p=0.516 n=50+50) LinkWithoutDebugCompiler 84.0MB ± 0% 84.0MB ± 0% ~ (p=0.057 n=50+50) [Geo mean] 70.4MB 70.4MB +0.01% file before after Δ % addr2line 4021557 4002933 -18624 -0.463% api 5127847 5028503 -99344 -1.937% asm 5034716 4936836 -97880 -1.944% buildid 2608118 2594094 -14024 -0.538% cgo 4488592 4398320 -90272 -2.011% compile 22501129 22213592 -287537 -1.278% cover 4742301 4713573 -28728 -0.606% dist 3388071 3365311 -22760 -0.672% doc 3802250 3776082 -26168 -0.688% fix 3306147 3216939 -89208 -2.698% link 6404483 6363699 -40784 -0.637% nm 3941026 3921930 -19096 -0.485% objdump 4383330 4295122 -88208 -2.012% pack 2404547 2389515 -15032 -0.625% pprof 12996234 12856818 -139416 -1.073% test2json 2668500 2586788 -81712 -3.062% trace 9816276 9609580 -206696 -2.106% vet 6900682 6787338 -113344 -1.643% total 108535806 107056973 -1478833 -1.363% Change-Id: Iaec1cdcaacca8025e9babb0fb8a532fddb70c87d Reviewed-on: https://go-review.googlesource.com/c/go/+/255239 Reviewed-by: eric fang <eric.fang@arm.com> Reviewed-by: Keith Randall <khr@golang.org> Trust: eric fang <eric.fang@arm.com>
2020-07-23 10:24:56 +08:00
// Start with the final register state of the predecessor with least spill values.
// This is based on the following points:
// 1, The less spill value indicates that the register pressure of this path is smaller,
// so the values of this block are more likely to be allocated to registers.
// 2, Avoid the predecessor that contains the function call, because the predecessor that
// contains the function call usually generates a lot of spills and lose the previous
// allocation state.
// TODO: Improve this part. At least the size of endRegs of the predecessor also has
// an impact on the code size and compiler speed. But it is not easy to find a simple
// and efficient method that combines multiple factors.
idx := -1
for i, p := range b.Preds {
// If the predecessor has not been visited yet, skip it because its end state
// (redRegs and spillLive) has not been computed yet.
pb := p.b
if s.blockOrder[pb.ID] >= s.blockOrder[b.ID] {
continue
}
if idx == -1 {
idx = i
continue
}
pSel := b.Preds[idx].b
if len(s.spillLive[pb.ID]) < len(s.spillLive[pSel.ID]) {
idx = i
} else if len(s.spillLive[pb.ID]) == len(s.spillLive[pSel.ID]) {
// Use a bit of likely information. After critical pass, pb and pSel must
// be plain blocks, so check edge pb->pb.Preds instead of edge pb->b.
// TODO: improve the prediction of the likely predecessor. The following
// method is only suitable for the simplest cases. For complex cases,
// the prediction may be inaccurate, but this does not affect the
// correctness of the program.
// According to the layout algorithm, the predecessor with the
// smaller blockOrder is the true branch, and the test results show
// that it is better to choose the predecessor with a smaller
// blockOrder than no choice.
if pb.likelyBranch() && !pSel.likelyBranch() || s.blockOrder[pb.ID] < s.blockOrder[pSel.ID] {
idx = i
}
}
}
if idx < 0 {
cmd/compile: use depth first topological sort algorithm for layout The current layout algorithm tries to put consecutive blocks together, so the priority of the successor block is higher than the priority of the zero indegree block. This algorithm is beneficial for subsequent register allocation, but will result in more branch instructions. The depth-first topological sorting algorithm is a well-known layout algorithm, which has applications in many languages, and it helps to reduce branch instructions. This CL applies it to the layout pass. The test results show that it helps to reduce the code size. This CL also includes the following changes: 1, Removed the primary predecessor mechanism. The new layout algorithm is not very friendly to register allocator in some cases, in order to adapt to the new layout algorithm, a new primary predecessor selection strategy is introduced. 2, Since the new layout implementation may place non-loop blocks between loop blocks, some adaptive modifications have also been made to looprotate pass. 3, The layout also affects the results of codegen, so this CL also adjusted several codegen tests accordingly. It is inevitable that this CL will cause the code size or performance of a few functions to decrease, but the number of cases it improves is much larger than the number of cases it drops. Statistical data from compilecmp on linux/amd64 is as follow: name old time/op new time/op delta Template 382ms ± 4% 382ms ± 4% ~ (p=0.497 n=49+50) Unicode 170ms ± 9% 169ms ± 8% ~ (p=0.344 n=48+50) GoTypes 2.01s ± 4% 2.01s ± 4% ~ (p=0.628 n=50+48) Compiler 190ms ±10% 189ms ± 9% ~ (p=0.734 n=50+50) SSA 11.8s ± 2% 11.8s ± 3% ~ (p=0.877 n=50+50) Flate 241ms ± 9% 241ms ± 8% ~ (p=0.897 n=50+49) GoParser 366ms ± 3% 361ms ± 4% -1.21% (p=0.004 n=47+50) Reflect 835ms ± 3% 838ms ± 3% ~ (p=0.275 n=50+49) Tar 336ms ± 4% 335ms ± 3% ~ (p=0.454 n=48+48) XML 433ms ± 4% 431ms ± 3% ~ (p=0.071 n=49+48) LinkCompiler 706ms ± 4% 705ms ± 4% ~ (p=0.608 n=50+49) ExternalLinkCompiler 1.85s ± 3% 1.83s ± 2% -1.47% (p=0.000 n=49+48) LinkWithoutDebugCompiler 437ms ± 5% 437ms ± 6% ~ (p=0.953 n=49+50) [Geo mean] 615ms 613ms -0.37% name old alloc/op new alloc/op delta Template 38.7MB ± 1% 38.7MB ± 1% ~ (p=0.834 n=50+50) Unicode 28.1MB ± 0% 28.1MB ± 0% -0.22% (p=0.000 n=49+50) GoTypes 168MB ± 1% 168MB ± 1% ~ (p=0.054 n=47+47) Compiler 23.0MB ± 1% 23.0MB ± 1% ~ (p=0.432 n=50+50) SSA 1.54GB ± 0% 1.54GB ± 0% +0.21% (p=0.000 n=50+50) Flate 23.6MB ± 1% 23.6MB ± 1% ~ (p=0.153 n=43+46) GoParser 35.1MB ± 1% 35.1MB ± 2% ~ (p=0.202 n=50+50) Reflect 84.7MB ± 1% 84.7MB ± 1% ~ (p=0.333 n=48+49) Tar 34.5MB ± 1% 34.5MB ± 1% ~ (p=0.406 n=46+49) XML 44.3MB ± 2% 44.2MB ± 3% ~ (p=0.981 n=50+50) LinkCompiler 131MB ± 0% 128MB ± 0% -2.74% (p=0.000 n=50+50) ExternalLinkCompiler 120MB ± 0% 120MB ± 0% +0.01% (p=0.007 n=50+50) LinkWithoutDebugCompiler 77.3MB ± 0% 77.3MB ± 0% -0.02% (p=0.000 n=50+50) [Geo mean] 69.3MB 69.1MB -0.22% file before after Δ % addr2line 4104220 4043684 -60536 -1.475% api 5342502 5249678 -92824 -1.737% asm 4973785 4858257 -115528 -2.323% buildid 2667844 2625660 -42184 -1.581% cgo 4686849 4616313 -70536 -1.505% compile 23667431 23268406 -399025 -1.686% cover 4959676 4874108 -85568 -1.725% dist 3515934 3450422 -65512 -1.863% doc 3995581 3925469 -70112 -1.755% fix 3379202 3318522 -60680 -1.796% link 6743249 6629913 -113336 -1.681% nm 4047529 3991777 -55752 -1.377% objdump 4456151 4388151 -68000 -1.526% pack 2435040 2398072 -36968 -1.518% pprof 13804080 13565808 -238272 -1.726% test2json 2690043 2645987 -44056 -1.638% trace 10418492 10232716 -185776 -1.783% vet 7258259 7121259 -137000 -1.888% total 113145867 111204202 -1941665 -1.716% The situation on linux/arm64 is as follow: name old time/op new time/op delta Template 280ms ± 1% 282ms ± 1% +0.75% (p=0.000 n=46+48) Unicode 124ms ± 2% 124ms ± 2% +0.37% (p=0.045 n=50+50) GoTypes 1.69s ± 1% 1.70s ± 1% +0.56% (p=0.000 n=49+50) Compiler 122ms ± 1% 123ms ± 1% +0.93% (p=0.000 n=50+50) SSA 12.6s ± 1% 12.7s ± 0% +0.72% (p=0.000 n=50+50) Flate 170ms ± 1% 172ms ± 1% +0.97% (p=0.000 n=49+49) GoParser 262ms ± 1% 263ms ± 1% +0.39% (p=0.000 n=49+48) Reflect 639ms ± 1% 650ms ± 1% +1.63% (p=0.000 n=49+49) Tar 243ms ± 1% 245ms ± 1% +0.82% (p=0.000 n=50+50) XML 324ms ± 1% 327ms ± 1% +0.72% (p=0.000 n=50+49) LinkCompiler 597ms ± 1% 596ms ± 1% -0.27% (p=0.001 n=48+47) ExternalLinkCompiler 1.90s ± 1% 1.88s ± 1% -1.00% (p=0.000 n=50+50) LinkWithoutDebugCompiler 364ms ± 1% 363ms ± 1% ~ (p=0.220 n=49+50) [Geo mean] 485ms 488ms +0.49% name old alloc/op new alloc/op delta Template 38.7MB ± 0% 38.8MB ± 1% ~ (p=0.093 n=43+49) Unicode 28.4MB ± 0% 28.4MB ± 0% +0.03% (p=0.000 n=49+45) GoTypes 169MB ± 1% 169MB ± 1% +0.23% (p=0.010 n=50+50) Compiler 23.2MB ± 1% 23.2MB ± 1% +0.11% (p=0.000 n=40+44) SSA 1.54GB ± 0% 1.55GB ± 0% +0.45% (p=0.000 n=47+49) Flate 23.8MB ± 2% 23.8MB ± 1% ~ (p=0.543 n=50+50) GoParser 35.3MB ± 1% 35.4MB ± 1% ~ (p=0.792 n=50+50) Reflect 85.2MB ± 1% 85.2MB ± 0% ~ (p=0.055 n=50+47) Tar 34.5MB ± 1% 34.5MB ± 1% +0.06% (p=0.015 n=50+50) XML 43.8MB ± 2% 43.9MB ± 2% +0.19% (p=0.000 n=48+48) LinkCompiler 137MB ± 0% 136MB ± 0% -0.92% (p=0.000 n=50+50) ExternalLinkCompiler 127MB ± 0% 127MB ± 0% ~ (p=0.516 n=50+50) LinkWithoutDebugCompiler 84.0MB ± 0% 84.0MB ± 0% ~ (p=0.057 n=50+50) [Geo mean] 70.4MB 70.4MB +0.01% file before after Δ % addr2line 4021557 4002933 -18624 -0.463% api 5127847 5028503 -99344 -1.937% asm 5034716 4936836 -97880 -1.944% buildid 2608118 2594094 -14024 -0.538% cgo 4488592 4398320 -90272 -2.011% compile 22501129 22213592 -287537 -1.278% cover 4742301 4713573 -28728 -0.606% dist 3388071 3365311 -22760 -0.672% doc 3802250 3776082 -26168 -0.688% fix 3306147 3216939 -89208 -2.698% link 6404483 6363699 -40784 -0.637% nm 3941026 3921930 -19096 -0.485% objdump 4383330 4295122 -88208 -2.012% pack 2404547 2389515 -15032 -0.625% pprof 12996234 12856818 -139416 -1.073% test2json 2668500 2586788 -81712 -3.062% trace 9816276 9609580 -206696 -2.106% vet 6900682 6787338 -113344 -1.643% total 108535806 107056973 -1478833 -1.363% Change-Id: Iaec1cdcaacca8025e9babb0fb8a532fddb70c87d Reviewed-on: https://go-review.googlesource.com/c/go/+/255239 Reviewed-by: eric fang <eric.fang@arm.com> Reviewed-by: Keith Randall <khr@golang.org> Trust: eric fang <eric.fang@arm.com>
2020-07-23 10:24:56 +08:00
f.Fatalf("bad visitOrder, no predecessor of %s has been visited before it", b)
}
p := b.Preds[idx].b
s.setState(s.endRegs[p.ID])
if s.f.pass.debug > regDebug {
fmt.Printf("starting merge block %s with end state of %s:\n", b, p)
for _, x := range s.endRegs[p.ID] {
fmt.Printf(" %s: orig:%s cache:%s\n", &s.registers[x.r], x.v, x.c)
}
}
// Decide on registers for phi ops. Use the registers determined
// by the primary predecessor if we can.
// TODO: pick best of (already processed) predecessors?
// Majority vote? Deepest nesting level?
phiRegs = phiRegs[:0]
var phiUsed regMask
for _, v := range phis {
if !s.values[v.ID].needReg {
phiRegs = append(phiRegs, noRegister)
continue
}
a := v.Args[idx]
// Some instructions target not-allocatable registers.
// They're not suitable for further (phi-function) allocation.
m := s.values[a.ID].regs &^ phiUsed & s.allocatable
if m != 0 {
r := pickReg(m)
phiUsed |= regMask(1) << r
phiRegs = append(phiRegs, r)
} else {
phiRegs = append(phiRegs, noRegister)
}
}
// Second pass - deallocate all in-register phi inputs.
cmd/compile: make a copy of Phi input if it is still live Register of Phi input is allocated to the Phi. So if the Phi input is still live after Phi, we may need to use a spill. In this case, copy the Phi input to a spare register to avoid a spill. Originally targeted the code in issue #16187, and this CL indeed removes the spill, but doesn't seem to help on benchmark result. It may help in general, though. On AMD64: name old time/op new time/op delta BinaryTree17-12 2.79s ± 1% 2.76s ± 0% -1.33% (p=0.000 n=10+10) Fannkuch11-12 3.02s ± 0% 3.14s ± 0% +3.99% (p=0.000 n=10+10) FmtFprintfEmpty-12 51.2ns ± 0% 51.4ns ± 3% ~ (p=0.368 n=8+10) FmtFprintfString-12 145ns ± 0% 144ns ± 0% -0.69% (p=0.000 n=6+9) FmtFprintfInt-12 127ns ± 1% 124ns ± 1% -2.79% (p=0.000 n=10+9) FmtFprintfIntInt-12 186ns ± 0% 184ns ± 0% -1.34% (p=0.000 n=10+9) FmtFprintfPrefixedInt-12 196ns ± 0% 194ns ± 0% -0.97% (p=0.000 n=9+9) FmtFprintfFloat-12 293ns ± 2% 287ns ± 0% -2.00% (p=0.000 n=10+9) FmtManyArgs-12 847ns ± 1% 829ns ± 0% -2.17% (p=0.000 n=10+7) GobDecode-12 7.17ms ± 0% 7.18ms ± 0% ~ (p=0.123 n=10+10) GobEncode-12 6.08ms ± 1% 6.08ms ± 0% ~ (p=0.497 n=10+9) Gzip-12 277ms ± 1% 275ms ± 1% -0.47% (p=0.028 n=10+9) Gunzip-12 39.1ms ± 2% 38.2ms ± 1% -2.20% (p=0.000 n=10+9) HTTPClientServer-12 90.9µs ± 4% 87.7µs ± 2% -3.51% (p=0.001 n=9+10) JSONEncode-12 17.3ms ± 1% 16.5ms ± 0% -5.02% (p=0.000 n=9+9) JSONDecode-12 54.6ms ± 1% 54.1ms ± 0% -0.99% (p=0.000 n=9+9) Mandelbrot200-12 4.45ms ± 0% 4.45ms ± 0% -0.02% (p=0.006 n=8+9) GoParse-12 3.44ms ± 0% 3.48ms ± 1% +0.95% (p=0.000 n=10+10) RegexpMatchEasy0_32-12 84.9ns ± 0% 85.0ns ± 0% ~ (p=0.241 n=8+8) RegexpMatchEasy0_1K-12 867ns ± 3% 915ns ±11% +5.55% (p=0.037 n=10+10) RegexpMatchEasy1_32-12 82.7ns ± 5% 83.9ns ± 4% ~ (p=0.161 n=9+10) RegexpMatchEasy1_1K-12 361ns ± 1% 363ns ± 0% ~ (p=0.098 n=10+8) RegexpMatchMedium_32-12 126ns ± 0% 126ns ± 1% ~ (p=0.549 n=8+10) RegexpMatchMedium_1K-12 38.8µs ± 0% 39.1µs ± 0% +0.67% (p=0.000 n=9+8) RegexpMatchHard_32-12 1.95µs ± 0% 1.96µs ± 0% +0.43% (p=0.000 n=9+9) RegexpMatchHard_1K-12 59.0µs ± 0% 59.1µs ± 0% +0.27% (p=0.000 n=10+9) Revcomp-12 436ms ± 1% 431ms ± 1% -1.19% (p=0.005 n=10+10) Template-12 56.7ms ± 1% 57.1ms ± 1% +0.71% (p=0.001 n=10+9) TimeParse-12 312ns ± 0% 310ns ± 0% -0.80% (p=0.000 n=10+9) TimeFormat-12 336ns ± 0% 332ns ± 0% -1.19% (p=0.000 n=8+7) [Geo mean] 59.2µs 58.9µs -0.42% On PPC64: name old time/op new time/op delta BinaryTree17-2 4.67s ± 2% 4.71s ± 1% ~ (p=0.421 n=5+5) Fannkuch11-2 3.92s ± 1% 3.94s ± 0% +0.46% (p=0.032 n=5+5) FmtFprintfEmpty-2 122ns ± 0% 120ns ± 2% -1.80% (p=0.016 n=4+5) FmtFprintfString-2 305ns ± 1% 299ns ± 1% -1.84% (p=0.008 n=5+5) FmtFprintfInt-2 243ns ± 0% 241ns ± 1% -0.66% (p=0.016 n=4+5) FmtFprintfIntInt-2 361ns ± 1% 356ns ± 1% -1.49% (p=0.016 n=5+5) FmtFprintfPrefixedInt-2 355ns ± 1% 357ns ± 1% ~ (p=0.333 n=5+5) FmtFprintfFloat-2 502ns ± 2% 498ns ± 1% ~ (p=0.151 n=5+5) FmtManyArgs-2 1.55µs ± 2% 1.59µs ± 1% +2.52% (p=0.008 n=5+5) GobDecode-2 13.0ms ± 1% 13.0ms ± 1% ~ (p=0.841 n=5+5) GobEncode-2 11.8ms ± 1% 11.8ms ± 1% ~ (p=0.690 n=5+5) Gzip-2 499ms ± 1% 503ms ± 0% ~ (p=0.421 n=5+5) Gunzip-2 86.5ms ± 0% 86.4ms ± 1% ~ (p=0.841 n=5+5) HTTPClientServer-2 68.2µs ± 2% 69.6µs ± 3% ~ (p=0.151 n=5+5) JSONEncode-2 39.0ms ± 1% 37.2ms ± 1% -4.65% (p=0.008 n=5+5) JSONDecode-2 122ms ± 1% 126ms ± 1% +2.63% (p=0.008 n=5+5) Mandelbrot200-2 6.08ms ± 1% 5.89ms ± 1% -3.06% (p=0.008 n=5+5) GoParse-2 5.95ms ± 2% 5.98ms ± 1% ~ (p=0.421 n=5+5) RegexpMatchEasy0_32-2 331ns ± 1% 328ns ± 1% ~ (p=0.056 n=5+5) RegexpMatchEasy0_1K-2 1.45µs ± 0% 1.47µs ± 0% +1.13% (p=0.008 n=5+5) RegexpMatchEasy1_32-2 359ns ± 0% 353ns ± 0% -1.84% (p=0.008 n=5+5) RegexpMatchEasy1_1K-2 1.79µs ± 0% 1.81µs ± 1% +1.16% (p=0.008 n=5+5) RegexpMatchMedium_32-2 420ns ± 2% 413ns ± 0% -1.72% (p=0.008 n=5+5) RegexpMatchMedium_1K-2 70.2µs ± 1% 69.5µs ± 1% -1.09% (p=0.032 n=5+5) RegexpMatchHard_32-2 3.87µs ± 1% 3.65µs ± 0% -5.86% (p=0.008 n=5+5) RegexpMatchHard_1K-2 111µs ± 0% 105µs ± 0% -5.49% (p=0.016 n=5+4) Revcomp-2 1.00s ± 1% 1.01s ± 2% ~ (p=0.151 n=5+5) Template-2 113ms ± 1% 113ms ± 2% ~ (p=0.841 n=5+5) TimeParse-2 555ns ± 0% 550ns ± 1% -0.87% (p=0.032 n=5+5) TimeFormat-2 736ns ± 1% 704ns ± 1% -4.35% (p=0.008 n=5+5) [Geo mean] 120µs 119µs -0.77% Reduce "spilled value remains" by 0.6% in cmd/go on AMD64. Change-Id: If655df343b0f30d1a49ab1ab644f10c698b96f3e Reviewed-on: https://go-review.googlesource.com/32442 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2016-10-28 23:11:04 -04:00
for i, v := range phis {
if !s.values[v.ID].needReg {
continue
}
a := v.Args[idx]
r := phiRegs[i]
if r == noRegister {
continue
}
if regValLiveSet.contains(a.ID) {
// Input value is still live (it is used by something other than Phi).
cmd/compile: make a copy of Phi input if it is still live Register of Phi input is allocated to the Phi. So if the Phi input is still live after Phi, we may need to use a spill. In this case, copy the Phi input to a spare register to avoid a spill. Originally targeted the code in issue #16187, and this CL indeed removes the spill, but doesn't seem to help on benchmark result. It may help in general, though. On AMD64: name old time/op new time/op delta BinaryTree17-12 2.79s ± 1% 2.76s ± 0% -1.33% (p=0.000 n=10+10) Fannkuch11-12 3.02s ± 0% 3.14s ± 0% +3.99% (p=0.000 n=10+10) FmtFprintfEmpty-12 51.2ns ± 0% 51.4ns ± 3% ~ (p=0.368 n=8+10) FmtFprintfString-12 145ns ± 0% 144ns ± 0% -0.69% (p=0.000 n=6+9) FmtFprintfInt-12 127ns ± 1% 124ns ± 1% -2.79% (p=0.000 n=10+9) FmtFprintfIntInt-12 186ns ± 0% 184ns ± 0% -1.34% (p=0.000 n=10+9) FmtFprintfPrefixedInt-12 196ns ± 0% 194ns ± 0% -0.97% (p=0.000 n=9+9) FmtFprintfFloat-12 293ns ± 2% 287ns ± 0% -2.00% (p=0.000 n=10+9) FmtManyArgs-12 847ns ± 1% 829ns ± 0% -2.17% (p=0.000 n=10+7) GobDecode-12 7.17ms ± 0% 7.18ms ± 0% ~ (p=0.123 n=10+10) GobEncode-12 6.08ms ± 1% 6.08ms ± 0% ~ (p=0.497 n=10+9) Gzip-12 277ms ± 1% 275ms ± 1% -0.47% (p=0.028 n=10+9) Gunzip-12 39.1ms ± 2% 38.2ms ± 1% -2.20% (p=0.000 n=10+9) HTTPClientServer-12 90.9µs ± 4% 87.7µs ± 2% -3.51% (p=0.001 n=9+10) JSONEncode-12 17.3ms ± 1% 16.5ms ± 0% -5.02% (p=0.000 n=9+9) JSONDecode-12 54.6ms ± 1% 54.1ms ± 0% -0.99% (p=0.000 n=9+9) Mandelbrot200-12 4.45ms ± 0% 4.45ms ± 0% -0.02% (p=0.006 n=8+9) GoParse-12 3.44ms ± 0% 3.48ms ± 1% +0.95% (p=0.000 n=10+10) RegexpMatchEasy0_32-12 84.9ns ± 0% 85.0ns ± 0% ~ (p=0.241 n=8+8) RegexpMatchEasy0_1K-12 867ns ± 3% 915ns ±11% +5.55% (p=0.037 n=10+10) RegexpMatchEasy1_32-12 82.7ns ± 5% 83.9ns ± 4% ~ (p=0.161 n=9+10) RegexpMatchEasy1_1K-12 361ns ± 1% 363ns ± 0% ~ (p=0.098 n=10+8) RegexpMatchMedium_32-12 126ns ± 0% 126ns ± 1% ~ (p=0.549 n=8+10) RegexpMatchMedium_1K-12 38.8µs ± 0% 39.1µs ± 0% +0.67% (p=0.000 n=9+8) RegexpMatchHard_32-12 1.95µs ± 0% 1.96µs ± 0% +0.43% (p=0.000 n=9+9) RegexpMatchHard_1K-12 59.0µs ± 0% 59.1µs ± 0% +0.27% (p=0.000 n=10+9) Revcomp-12 436ms ± 1% 431ms ± 1% -1.19% (p=0.005 n=10+10) Template-12 56.7ms ± 1% 57.1ms ± 1% +0.71% (p=0.001 n=10+9) TimeParse-12 312ns ± 0% 310ns ± 0% -0.80% (p=0.000 n=10+9) TimeFormat-12 336ns ± 0% 332ns ± 0% -1.19% (p=0.000 n=8+7) [Geo mean] 59.2µs 58.9µs -0.42% On PPC64: name old time/op new time/op delta BinaryTree17-2 4.67s ± 2% 4.71s ± 1% ~ (p=0.421 n=5+5) Fannkuch11-2 3.92s ± 1% 3.94s ± 0% +0.46% (p=0.032 n=5+5) FmtFprintfEmpty-2 122ns ± 0% 120ns ± 2% -1.80% (p=0.016 n=4+5) FmtFprintfString-2 305ns ± 1% 299ns ± 1% -1.84% (p=0.008 n=5+5) FmtFprintfInt-2 243ns ± 0% 241ns ± 1% -0.66% (p=0.016 n=4+5) FmtFprintfIntInt-2 361ns ± 1% 356ns ± 1% -1.49% (p=0.016 n=5+5) FmtFprintfPrefixedInt-2 355ns ± 1% 357ns ± 1% ~ (p=0.333 n=5+5) FmtFprintfFloat-2 502ns ± 2% 498ns ± 1% ~ (p=0.151 n=5+5) FmtManyArgs-2 1.55µs ± 2% 1.59µs ± 1% +2.52% (p=0.008 n=5+5) GobDecode-2 13.0ms ± 1% 13.0ms ± 1% ~ (p=0.841 n=5+5) GobEncode-2 11.8ms ± 1% 11.8ms ± 1% ~ (p=0.690 n=5+5) Gzip-2 499ms ± 1% 503ms ± 0% ~ (p=0.421 n=5+5) Gunzip-2 86.5ms ± 0% 86.4ms ± 1% ~ (p=0.841 n=5+5) HTTPClientServer-2 68.2µs ± 2% 69.6µs ± 3% ~ (p=0.151 n=5+5) JSONEncode-2 39.0ms ± 1% 37.2ms ± 1% -4.65% (p=0.008 n=5+5) JSONDecode-2 122ms ± 1% 126ms ± 1% +2.63% (p=0.008 n=5+5) Mandelbrot200-2 6.08ms ± 1% 5.89ms ± 1% -3.06% (p=0.008 n=5+5) GoParse-2 5.95ms ± 2% 5.98ms ± 1% ~ (p=0.421 n=5+5) RegexpMatchEasy0_32-2 331ns ± 1% 328ns ± 1% ~ (p=0.056 n=5+5) RegexpMatchEasy0_1K-2 1.45µs ± 0% 1.47µs ± 0% +1.13% (p=0.008 n=5+5) RegexpMatchEasy1_32-2 359ns ± 0% 353ns ± 0% -1.84% (p=0.008 n=5+5) RegexpMatchEasy1_1K-2 1.79µs ± 0% 1.81µs ± 1% +1.16% (p=0.008 n=5+5) RegexpMatchMedium_32-2 420ns ± 2% 413ns ± 0% -1.72% (p=0.008 n=5+5) RegexpMatchMedium_1K-2 70.2µs ± 1% 69.5µs ± 1% -1.09% (p=0.032 n=5+5) RegexpMatchHard_32-2 3.87µs ± 1% 3.65µs ± 0% -5.86% (p=0.008 n=5+5) RegexpMatchHard_1K-2 111µs ± 0% 105µs ± 0% -5.49% (p=0.016 n=5+4) Revcomp-2 1.00s ± 1% 1.01s ± 2% ~ (p=0.151 n=5+5) Template-2 113ms ± 1% 113ms ± 2% ~ (p=0.841 n=5+5) TimeParse-2 555ns ± 0% 550ns ± 1% -0.87% (p=0.032 n=5+5) TimeFormat-2 736ns ± 1% 704ns ± 1% -4.35% (p=0.008 n=5+5) [Geo mean] 120µs 119µs -0.77% Reduce "spilled value remains" by 0.6% in cmd/go on AMD64. Change-Id: If655df343b0f30d1a49ab1ab644f10c698b96f3e Reviewed-on: https://go-review.googlesource.com/32442 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2016-10-28 23:11:04 -04:00
// Try to move it around before kicking out, if there is a free register.
// We generate a Copy in the predecessor block and record it. It will be
// deleted later if never used.
//
cmd/compile: make a copy of Phi input if it is still live Register of Phi input is allocated to the Phi. So if the Phi input is still live after Phi, we may need to use a spill. In this case, copy the Phi input to a spare register to avoid a spill. Originally targeted the code in issue #16187, and this CL indeed removes the spill, but doesn't seem to help on benchmark result. It may help in general, though. On AMD64: name old time/op new time/op delta BinaryTree17-12 2.79s ± 1% 2.76s ± 0% -1.33% (p=0.000 n=10+10) Fannkuch11-12 3.02s ± 0% 3.14s ± 0% +3.99% (p=0.000 n=10+10) FmtFprintfEmpty-12 51.2ns ± 0% 51.4ns ± 3% ~ (p=0.368 n=8+10) FmtFprintfString-12 145ns ± 0% 144ns ± 0% -0.69% (p=0.000 n=6+9) FmtFprintfInt-12 127ns ± 1% 124ns ± 1% -2.79% (p=0.000 n=10+9) FmtFprintfIntInt-12 186ns ± 0% 184ns ± 0% -1.34% (p=0.000 n=10+9) FmtFprintfPrefixedInt-12 196ns ± 0% 194ns ± 0% -0.97% (p=0.000 n=9+9) FmtFprintfFloat-12 293ns ± 2% 287ns ± 0% -2.00% (p=0.000 n=10+9) FmtManyArgs-12 847ns ± 1% 829ns ± 0% -2.17% (p=0.000 n=10+7) GobDecode-12 7.17ms ± 0% 7.18ms ± 0% ~ (p=0.123 n=10+10) GobEncode-12 6.08ms ± 1% 6.08ms ± 0% ~ (p=0.497 n=10+9) Gzip-12 277ms ± 1% 275ms ± 1% -0.47% (p=0.028 n=10+9) Gunzip-12 39.1ms ± 2% 38.2ms ± 1% -2.20% (p=0.000 n=10+9) HTTPClientServer-12 90.9µs ± 4% 87.7µs ± 2% -3.51% (p=0.001 n=9+10) JSONEncode-12 17.3ms ± 1% 16.5ms ± 0% -5.02% (p=0.000 n=9+9) JSONDecode-12 54.6ms ± 1% 54.1ms ± 0% -0.99% (p=0.000 n=9+9) Mandelbrot200-12 4.45ms ± 0% 4.45ms ± 0% -0.02% (p=0.006 n=8+9) GoParse-12 3.44ms ± 0% 3.48ms ± 1% +0.95% (p=0.000 n=10+10) RegexpMatchEasy0_32-12 84.9ns ± 0% 85.0ns ± 0% ~ (p=0.241 n=8+8) RegexpMatchEasy0_1K-12 867ns ± 3% 915ns ±11% +5.55% (p=0.037 n=10+10) RegexpMatchEasy1_32-12 82.7ns ± 5% 83.9ns ± 4% ~ (p=0.161 n=9+10) RegexpMatchEasy1_1K-12 361ns ± 1% 363ns ± 0% ~ (p=0.098 n=10+8) RegexpMatchMedium_32-12 126ns ± 0% 126ns ± 1% ~ (p=0.549 n=8+10) RegexpMatchMedium_1K-12 38.8µs ± 0% 39.1µs ± 0% +0.67% (p=0.000 n=9+8) RegexpMatchHard_32-12 1.95µs ± 0% 1.96µs ± 0% +0.43% (p=0.000 n=9+9) RegexpMatchHard_1K-12 59.0µs ± 0% 59.1µs ± 0% +0.27% (p=0.000 n=10+9) Revcomp-12 436ms ± 1% 431ms ± 1% -1.19% (p=0.005 n=10+10) Template-12 56.7ms ± 1% 57.1ms ± 1% +0.71% (p=0.001 n=10+9) TimeParse-12 312ns ± 0% 310ns ± 0% -0.80% (p=0.000 n=10+9) TimeFormat-12 336ns ± 0% 332ns ± 0% -1.19% (p=0.000 n=8+7) [Geo mean] 59.2µs 58.9µs -0.42% On PPC64: name old time/op new time/op delta BinaryTree17-2 4.67s ± 2% 4.71s ± 1% ~ (p=0.421 n=5+5) Fannkuch11-2 3.92s ± 1% 3.94s ± 0% +0.46% (p=0.032 n=5+5) FmtFprintfEmpty-2 122ns ± 0% 120ns ± 2% -1.80% (p=0.016 n=4+5) FmtFprintfString-2 305ns ± 1% 299ns ± 1% -1.84% (p=0.008 n=5+5) FmtFprintfInt-2 243ns ± 0% 241ns ± 1% -0.66% (p=0.016 n=4+5) FmtFprintfIntInt-2 361ns ± 1% 356ns ± 1% -1.49% (p=0.016 n=5+5) FmtFprintfPrefixedInt-2 355ns ± 1% 357ns ± 1% ~ (p=0.333 n=5+5) FmtFprintfFloat-2 502ns ± 2% 498ns ± 1% ~ (p=0.151 n=5+5) FmtManyArgs-2 1.55µs ± 2% 1.59µs ± 1% +2.52% (p=0.008 n=5+5) GobDecode-2 13.0ms ± 1% 13.0ms ± 1% ~ (p=0.841 n=5+5) GobEncode-2 11.8ms ± 1% 11.8ms ± 1% ~ (p=0.690 n=5+5) Gzip-2 499ms ± 1% 503ms ± 0% ~ (p=0.421 n=5+5) Gunzip-2 86.5ms ± 0% 86.4ms ± 1% ~ (p=0.841 n=5+5) HTTPClientServer-2 68.2µs ± 2% 69.6µs ± 3% ~ (p=0.151 n=5+5) JSONEncode-2 39.0ms ± 1% 37.2ms ± 1% -4.65% (p=0.008 n=5+5) JSONDecode-2 122ms ± 1% 126ms ± 1% +2.63% (p=0.008 n=5+5) Mandelbrot200-2 6.08ms ± 1% 5.89ms ± 1% -3.06% (p=0.008 n=5+5) GoParse-2 5.95ms ± 2% 5.98ms ± 1% ~ (p=0.421 n=5+5) RegexpMatchEasy0_32-2 331ns ± 1% 328ns ± 1% ~ (p=0.056 n=5+5) RegexpMatchEasy0_1K-2 1.45µs ± 0% 1.47µs ± 0% +1.13% (p=0.008 n=5+5) RegexpMatchEasy1_32-2 359ns ± 0% 353ns ± 0% -1.84% (p=0.008 n=5+5) RegexpMatchEasy1_1K-2 1.79µs ± 0% 1.81µs ± 1% +1.16% (p=0.008 n=5+5) RegexpMatchMedium_32-2 420ns ± 2% 413ns ± 0% -1.72% (p=0.008 n=5+5) RegexpMatchMedium_1K-2 70.2µs ± 1% 69.5µs ± 1% -1.09% (p=0.032 n=5+5) RegexpMatchHard_32-2 3.87µs ± 1% 3.65µs ± 0% -5.86% (p=0.008 n=5+5) RegexpMatchHard_1K-2 111µs ± 0% 105µs ± 0% -5.49% (p=0.016 n=5+4) Revcomp-2 1.00s ± 1% 1.01s ± 2% ~ (p=0.151 n=5+5) Template-2 113ms ± 1% 113ms ± 2% ~ (p=0.841 n=5+5) TimeParse-2 555ns ± 0% 550ns ± 1% -0.87% (p=0.032 n=5+5) TimeFormat-2 736ns ± 1% 704ns ± 1% -4.35% (p=0.008 n=5+5) [Geo mean] 120µs 119µs -0.77% Reduce "spilled value remains" by 0.6% in cmd/go on AMD64. Change-Id: If655df343b0f30d1a49ab1ab644f10c698b96f3e Reviewed-on: https://go-review.googlesource.com/32442 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2016-10-28 23:11:04 -04:00
// Pick a free register. At this point some registers used in the predecessor
// block may have been deallocated. Those are the ones used for Phis. Exclude
// them (and they are not going to be helpful anyway).
m := s.compatRegs(a.Type) &^ s.used &^ phiUsed
if m != 0 && !s.values[a.ID].rematerializeable && countRegs(s.values[a.ID].regs) == 1 {
r2 := pickReg(m)
c := p.NewValue1(a.Pos, OpCopy, a.Type, s.regs[r].c)
cmd/compile: make a copy of Phi input if it is still live Register of Phi input is allocated to the Phi. So if the Phi input is still live after Phi, we may need to use a spill. In this case, copy the Phi input to a spare register to avoid a spill. Originally targeted the code in issue #16187, and this CL indeed removes the spill, but doesn't seem to help on benchmark result. It may help in general, though. On AMD64: name old time/op new time/op delta BinaryTree17-12 2.79s ± 1% 2.76s ± 0% -1.33% (p=0.000 n=10+10) Fannkuch11-12 3.02s ± 0% 3.14s ± 0% +3.99% (p=0.000 n=10+10) FmtFprintfEmpty-12 51.2ns ± 0% 51.4ns ± 3% ~ (p=0.368 n=8+10) FmtFprintfString-12 145ns ± 0% 144ns ± 0% -0.69% (p=0.000 n=6+9) FmtFprintfInt-12 127ns ± 1% 124ns ± 1% -2.79% (p=0.000 n=10+9) FmtFprintfIntInt-12 186ns ± 0% 184ns ± 0% -1.34% (p=0.000 n=10+9) FmtFprintfPrefixedInt-12 196ns ± 0% 194ns ± 0% -0.97% (p=0.000 n=9+9) FmtFprintfFloat-12 293ns ± 2% 287ns ± 0% -2.00% (p=0.000 n=10+9) FmtManyArgs-12 847ns ± 1% 829ns ± 0% -2.17% (p=0.000 n=10+7) GobDecode-12 7.17ms ± 0% 7.18ms ± 0% ~ (p=0.123 n=10+10) GobEncode-12 6.08ms ± 1% 6.08ms ± 0% ~ (p=0.497 n=10+9) Gzip-12 277ms ± 1% 275ms ± 1% -0.47% (p=0.028 n=10+9) Gunzip-12 39.1ms ± 2% 38.2ms ± 1% -2.20% (p=0.000 n=10+9) HTTPClientServer-12 90.9µs ± 4% 87.7µs ± 2% -3.51% (p=0.001 n=9+10) JSONEncode-12 17.3ms ± 1% 16.5ms ± 0% -5.02% (p=0.000 n=9+9) JSONDecode-12 54.6ms ± 1% 54.1ms ± 0% -0.99% (p=0.000 n=9+9) Mandelbrot200-12 4.45ms ± 0% 4.45ms ± 0% -0.02% (p=0.006 n=8+9) GoParse-12 3.44ms ± 0% 3.48ms ± 1% +0.95% (p=0.000 n=10+10) RegexpMatchEasy0_32-12 84.9ns ± 0% 85.0ns ± 0% ~ (p=0.241 n=8+8) RegexpMatchEasy0_1K-12 867ns ± 3% 915ns ±11% +5.55% (p=0.037 n=10+10) RegexpMatchEasy1_32-12 82.7ns ± 5% 83.9ns ± 4% ~ (p=0.161 n=9+10) RegexpMatchEasy1_1K-12 361ns ± 1% 363ns ± 0% ~ (p=0.098 n=10+8) RegexpMatchMedium_32-12 126ns ± 0% 126ns ± 1% ~ (p=0.549 n=8+10) RegexpMatchMedium_1K-12 38.8µs ± 0% 39.1µs ± 0% +0.67% (p=0.000 n=9+8) RegexpMatchHard_32-12 1.95µs ± 0% 1.96µs ± 0% +0.43% (p=0.000 n=9+9) RegexpMatchHard_1K-12 59.0µs ± 0% 59.1µs ± 0% +0.27% (p=0.000 n=10+9) Revcomp-12 436ms ± 1% 431ms ± 1% -1.19% (p=0.005 n=10+10) Template-12 56.7ms ± 1% 57.1ms ± 1% +0.71% (p=0.001 n=10+9) TimeParse-12 312ns ± 0% 310ns ± 0% -0.80% (p=0.000 n=10+9) TimeFormat-12 336ns ± 0% 332ns ± 0% -1.19% (p=0.000 n=8+7) [Geo mean] 59.2µs 58.9µs -0.42% On PPC64: name old time/op new time/op delta BinaryTree17-2 4.67s ± 2% 4.71s ± 1% ~ (p=0.421 n=5+5) Fannkuch11-2 3.92s ± 1% 3.94s ± 0% +0.46% (p=0.032 n=5+5) FmtFprintfEmpty-2 122ns ± 0% 120ns ± 2% -1.80% (p=0.016 n=4+5) FmtFprintfString-2 305ns ± 1% 299ns ± 1% -1.84% (p=0.008 n=5+5) FmtFprintfInt-2 243ns ± 0% 241ns ± 1% -0.66% (p=0.016 n=4+5) FmtFprintfIntInt-2 361ns ± 1% 356ns ± 1% -1.49% (p=0.016 n=5+5) FmtFprintfPrefixedInt-2 355ns ± 1% 357ns ± 1% ~ (p=0.333 n=5+5) FmtFprintfFloat-2 502ns ± 2% 498ns ± 1% ~ (p=0.151 n=5+5) FmtManyArgs-2 1.55µs ± 2% 1.59µs ± 1% +2.52% (p=0.008 n=5+5) GobDecode-2 13.0ms ± 1% 13.0ms ± 1% ~ (p=0.841 n=5+5) GobEncode-2 11.8ms ± 1% 11.8ms ± 1% ~ (p=0.690 n=5+5) Gzip-2 499ms ± 1% 503ms ± 0% ~ (p=0.421 n=5+5) Gunzip-2 86.5ms ± 0% 86.4ms ± 1% ~ (p=0.841 n=5+5) HTTPClientServer-2 68.2µs ± 2% 69.6µs ± 3% ~ (p=0.151 n=5+5) JSONEncode-2 39.0ms ± 1% 37.2ms ± 1% -4.65% (p=0.008 n=5+5) JSONDecode-2 122ms ± 1% 126ms ± 1% +2.63% (p=0.008 n=5+5) Mandelbrot200-2 6.08ms ± 1% 5.89ms ± 1% -3.06% (p=0.008 n=5+5) GoParse-2 5.95ms ± 2% 5.98ms ± 1% ~ (p=0.421 n=5+5) RegexpMatchEasy0_32-2 331ns ± 1% 328ns ± 1% ~ (p=0.056 n=5+5) RegexpMatchEasy0_1K-2 1.45µs ± 0% 1.47µs ± 0% +1.13% (p=0.008 n=5+5) RegexpMatchEasy1_32-2 359ns ± 0% 353ns ± 0% -1.84% (p=0.008 n=5+5) RegexpMatchEasy1_1K-2 1.79µs ± 0% 1.81µs ± 1% +1.16% (p=0.008 n=5+5) RegexpMatchMedium_32-2 420ns ± 2% 413ns ± 0% -1.72% (p=0.008 n=5+5) RegexpMatchMedium_1K-2 70.2µs ± 1% 69.5µs ± 1% -1.09% (p=0.032 n=5+5) RegexpMatchHard_32-2 3.87µs ± 1% 3.65µs ± 0% -5.86% (p=0.008 n=5+5) RegexpMatchHard_1K-2 111µs ± 0% 105µs ± 0% -5.49% (p=0.016 n=5+4) Revcomp-2 1.00s ± 1% 1.01s ± 2% ~ (p=0.151 n=5+5) Template-2 113ms ± 1% 113ms ± 2% ~ (p=0.841 n=5+5) TimeParse-2 555ns ± 0% 550ns ± 1% -0.87% (p=0.032 n=5+5) TimeFormat-2 736ns ± 1% 704ns ± 1% -4.35% (p=0.008 n=5+5) [Geo mean] 120µs 119µs -0.77% Reduce "spilled value remains" by 0.6% in cmd/go on AMD64. Change-Id: If655df343b0f30d1a49ab1ab644f10c698b96f3e Reviewed-on: https://go-review.googlesource.com/32442 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2016-10-28 23:11:04 -04:00
s.copies[c] = false
if s.f.pass.debug > regDebug {
fmt.Printf("copy %s to %s : %s\n", a, c, &s.registers[r2])
cmd/compile: make a copy of Phi input if it is still live Register of Phi input is allocated to the Phi. So if the Phi input is still live after Phi, we may need to use a spill. In this case, copy the Phi input to a spare register to avoid a spill. Originally targeted the code in issue #16187, and this CL indeed removes the spill, but doesn't seem to help on benchmark result. It may help in general, though. On AMD64: name old time/op new time/op delta BinaryTree17-12 2.79s ± 1% 2.76s ± 0% -1.33% (p=0.000 n=10+10) Fannkuch11-12 3.02s ± 0% 3.14s ± 0% +3.99% (p=0.000 n=10+10) FmtFprintfEmpty-12 51.2ns ± 0% 51.4ns ± 3% ~ (p=0.368 n=8+10) FmtFprintfString-12 145ns ± 0% 144ns ± 0% -0.69% (p=0.000 n=6+9) FmtFprintfInt-12 127ns ± 1% 124ns ± 1% -2.79% (p=0.000 n=10+9) FmtFprintfIntInt-12 186ns ± 0% 184ns ± 0% -1.34% (p=0.000 n=10+9) FmtFprintfPrefixedInt-12 196ns ± 0% 194ns ± 0% -0.97% (p=0.000 n=9+9) FmtFprintfFloat-12 293ns ± 2% 287ns ± 0% -2.00% (p=0.000 n=10+9) FmtManyArgs-12 847ns ± 1% 829ns ± 0% -2.17% (p=0.000 n=10+7) GobDecode-12 7.17ms ± 0% 7.18ms ± 0% ~ (p=0.123 n=10+10) GobEncode-12 6.08ms ± 1% 6.08ms ± 0% ~ (p=0.497 n=10+9) Gzip-12 277ms ± 1% 275ms ± 1% -0.47% (p=0.028 n=10+9) Gunzip-12 39.1ms ± 2% 38.2ms ± 1% -2.20% (p=0.000 n=10+9) HTTPClientServer-12 90.9µs ± 4% 87.7µs ± 2% -3.51% (p=0.001 n=9+10) JSONEncode-12 17.3ms ± 1% 16.5ms ± 0% -5.02% (p=0.000 n=9+9) JSONDecode-12 54.6ms ± 1% 54.1ms ± 0% -0.99% (p=0.000 n=9+9) Mandelbrot200-12 4.45ms ± 0% 4.45ms ± 0% -0.02% (p=0.006 n=8+9) GoParse-12 3.44ms ± 0% 3.48ms ± 1% +0.95% (p=0.000 n=10+10) RegexpMatchEasy0_32-12 84.9ns ± 0% 85.0ns ± 0% ~ (p=0.241 n=8+8) RegexpMatchEasy0_1K-12 867ns ± 3% 915ns ±11% +5.55% (p=0.037 n=10+10) RegexpMatchEasy1_32-12 82.7ns ± 5% 83.9ns ± 4% ~ (p=0.161 n=9+10) RegexpMatchEasy1_1K-12 361ns ± 1% 363ns ± 0% ~ (p=0.098 n=10+8) RegexpMatchMedium_32-12 126ns ± 0% 126ns ± 1% ~ (p=0.549 n=8+10) RegexpMatchMedium_1K-12 38.8µs ± 0% 39.1µs ± 0% +0.67% (p=0.000 n=9+8) RegexpMatchHard_32-12 1.95µs ± 0% 1.96µs ± 0% +0.43% (p=0.000 n=9+9) RegexpMatchHard_1K-12 59.0µs ± 0% 59.1µs ± 0% +0.27% (p=0.000 n=10+9) Revcomp-12 436ms ± 1% 431ms ± 1% -1.19% (p=0.005 n=10+10) Template-12 56.7ms ± 1% 57.1ms ± 1% +0.71% (p=0.001 n=10+9) TimeParse-12 312ns ± 0% 310ns ± 0% -0.80% (p=0.000 n=10+9) TimeFormat-12 336ns ± 0% 332ns ± 0% -1.19% (p=0.000 n=8+7) [Geo mean] 59.2µs 58.9µs -0.42% On PPC64: name old time/op new time/op delta BinaryTree17-2 4.67s ± 2% 4.71s ± 1% ~ (p=0.421 n=5+5) Fannkuch11-2 3.92s ± 1% 3.94s ± 0% +0.46% (p=0.032 n=5+5) FmtFprintfEmpty-2 122ns ± 0% 120ns ± 2% -1.80% (p=0.016 n=4+5) FmtFprintfString-2 305ns ± 1% 299ns ± 1% -1.84% (p=0.008 n=5+5) FmtFprintfInt-2 243ns ± 0% 241ns ± 1% -0.66% (p=0.016 n=4+5) FmtFprintfIntInt-2 361ns ± 1% 356ns ± 1% -1.49% (p=0.016 n=5+5) FmtFprintfPrefixedInt-2 355ns ± 1% 357ns ± 1% ~ (p=0.333 n=5+5) FmtFprintfFloat-2 502ns ± 2% 498ns ± 1% ~ (p=0.151 n=5+5) FmtManyArgs-2 1.55µs ± 2% 1.59µs ± 1% +2.52% (p=0.008 n=5+5) GobDecode-2 13.0ms ± 1% 13.0ms ± 1% ~ (p=0.841 n=5+5) GobEncode-2 11.8ms ± 1% 11.8ms ± 1% ~ (p=0.690 n=5+5) Gzip-2 499ms ± 1% 503ms ± 0% ~ (p=0.421 n=5+5) Gunzip-2 86.5ms ± 0% 86.4ms ± 1% ~ (p=0.841 n=5+5) HTTPClientServer-2 68.2µs ± 2% 69.6µs ± 3% ~ (p=0.151 n=5+5) JSONEncode-2 39.0ms ± 1% 37.2ms ± 1% -4.65% (p=0.008 n=5+5) JSONDecode-2 122ms ± 1% 126ms ± 1% +2.63% (p=0.008 n=5+5) Mandelbrot200-2 6.08ms ± 1% 5.89ms ± 1% -3.06% (p=0.008 n=5+5) GoParse-2 5.95ms ± 2% 5.98ms ± 1% ~ (p=0.421 n=5+5) RegexpMatchEasy0_32-2 331ns ± 1% 328ns ± 1% ~ (p=0.056 n=5+5) RegexpMatchEasy0_1K-2 1.45µs ± 0% 1.47µs ± 0% +1.13% (p=0.008 n=5+5) RegexpMatchEasy1_32-2 359ns ± 0% 353ns ± 0% -1.84% (p=0.008 n=5+5) RegexpMatchEasy1_1K-2 1.79µs ± 0% 1.81µs ± 1% +1.16% (p=0.008 n=5+5) RegexpMatchMedium_32-2 420ns ± 2% 413ns ± 0% -1.72% (p=0.008 n=5+5) RegexpMatchMedium_1K-2 70.2µs ± 1% 69.5µs ± 1% -1.09% (p=0.032 n=5+5) RegexpMatchHard_32-2 3.87µs ± 1% 3.65µs ± 0% -5.86% (p=0.008 n=5+5) RegexpMatchHard_1K-2 111µs ± 0% 105µs ± 0% -5.49% (p=0.016 n=5+4) Revcomp-2 1.00s ± 1% 1.01s ± 2% ~ (p=0.151 n=5+5) Template-2 113ms ± 1% 113ms ± 2% ~ (p=0.841 n=5+5) TimeParse-2 555ns ± 0% 550ns ± 1% -0.87% (p=0.032 n=5+5) TimeFormat-2 736ns ± 1% 704ns ± 1% -4.35% (p=0.008 n=5+5) [Geo mean] 120µs 119µs -0.77% Reduce "spilled value remains" by 0.6% in cmd/go on AMD64. Change-Id: If655df343b0f30d1a49ab1ab644f10c698b96f3e Reviewed-on: https://go-review.googlesource.com/32442 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2016-10-28 23:11:04 -04:00
}
s.setOrig(c, a)
s.assignReg(r2, a, c)
s.endRegs[p.ID] = append(s.endRegs[p.ID], endReg{r2, a, c})
}
}
s.freeReg(r)
}
[dev.debug] cmd/compile: better DWARF with optimizations on Debuggers use DWARF information to find local variables on the stack and in registers. Prior to this CL, the DWARF information for functions claimed that all variables were on the stack at all times. That's incorrect when optimizations are enabled, and results in debuggers showing data that is out of date or complete gibberish. After this CL, the compiler is capable of representing variable locations more accurately, and attempts to do so. Due to limitations of the SSA backend, it's not possible to be completely correct. There are a number of problems in the current design. One of the easier to understand is that variable names currently must be attached to an SSA value, but not all assignments in the source code actually result in machine code. For example: type myint int var a int b := myint(int) and b := (*uint64)(unsafe.Pointer(a)) don't generate machine code because the underlying representation is the same, so the correct value of b will not be set when the user would expect. Generating the more precise debug information is behind a flag, dwarflocationlists. Because of the issues described above, setting the flag may not make the debugging experience much better, and may actually make it worse in cases where the variable actually is on the stack and the more complicated analysis doesn't realize it. A number of changes are included: - Add a new pseudo-instruction, RegKill, which indicates that the value in the register has been clobbered. - Adjust regalloc to emit RegKills in the right places. Significantly, this means that phis are mixed with StoreReg and RegKills after regalloc. - Track variable decomposition in ssa.LocalSlots. - After the SSA backend is done, analyze the result and build location lists for each LocalSlot. - After assembly is done, update the location lists with the assembled PC offsets, recompose variables, and build DWARF location lists. Emit the list as a new linker symbol, one per function. - In the linker, aggregate the location lists into a .debug_loc section. TODO: - currently disabled for non-X86/AMD64 because there are no data tables. go build -toolexec 'toolstash -cmp' -a std succeeds. With -dwarflocationlists false: before: f02812195637909ff675782c0b46836a8ff01976 after: 06f61e8112a42ac34fb80e0c818b3cdb84a5e7ec benchstat -geomean /tmp/220352263 /tmp/621364410 completed 15 of 15, estimated time remaining 0s (eta 3:52PM) name old time/op new time/op delta Template 199ms ± 3% 198ms ± 2% ~ (p=0.400 n=15+14) Unicode 96.6ms ± 5% 96.4ms ± 5% ~ (p=0.838 n=15+15) GoTypes 653ms ± 2% 647ms ± 2% ~ (p=0.102 n=15+14) Flate 133ms ± 6% 129ms ± 3% -2.62% (p=0.041 n=15+15) GoParser 164ms ± 5% 159ms ± 3% -3.05% (p=0.000 n=15+15) Reflect 428ms ± 4% 422ms ± 3% ~ (p=0.156 n=15+13) Tar 123ms ±10% 124ms ± 8% ~ (p=0.461 n=15+15) XML 228ms ± 3% 224ms ± 3% -1.57% (p=0.045 n=15+15) [Geo mean] 206ms 377ms +82.86% name old user-time/op new user-time/op delta Template 292ms ±10% 301ms ±12% ~ (p=0.189 n=15+15) Unicode 166ms ±37% 158ms ±14% ~ (p=0.418 n=15+14) GoTypes 962ms ± 6% 963ms ± 7% ~ (p=0.976 n=15+15) Flate 207ms ±19% 200ms ±14% ~ (p=0.345 n=14+15) GoParser 246ms ±22% 240ms ±15% ~ (p=0.587 n=15+15) Reflect 611ms ±13% 587ms ±14% ~ (p=0.085 n=15+13) Tar 211ms ±12% 217ms ±14% ~ (p=0.355 n=14+15) XML 335ms ±15% 320ms ±18% ~ (p=0.169 n=15+15) [Geo mean] 317ms 583ms +83.72% name old alloc/op new alloc/op delta Template 40.2MB ± 0% 40.2MB ± 0% -0.15% (p=0.000 n=14+15) Unicode 29.2MB ± 0% 29.3MB ± 0% ~ (p=0.624 n=15+15) GoTypes 114MB ± 0% 114MB ± 0% -0.15% (p=0.000 n=15+14) Flate 25.7MB ± 0% 25.6MB ± 0% -0.18% (p=0.000 n=13+15) GoParser 32.2MB ± 0% 32.2MB ± 0% -0.14% (p=0.003 n=15+15) Reflect 77.8MB ± 0% 77.9MB ± 0% ~ (p=0.061 n=15+15) Tar 27.1MB ± 0% 27.0MB ± 0% -0.11% (p=0.029 n=15+15) XML 42.7MB ± 0% 42.5MB ± 0% -0.29% (p=0.000 n=15+15) [Geo mean] 42.1MB 75.0MB +78.05% name old allocs/op new allocs/op delta Template 402k ± 1% 398k ± 0% -0.91% (p=0.000 n=15+15) Unicode 344k ± 1% 344k ± 0% ~ (p=0.715 n=15+14) GoTypes 1.18M ± 0% 1.17M ± 0% -0.91% (p=0.000 n=15+14) Flate 243k ± 0% 240k ± 1% -1.05% (p=0.000 n=13+15) GoParser 327k ± 1% 324k ± 1% -0.96% (p=0.000 n=15+15) Reflect 984k ± 1% 982k ± 0% ~ (p=0.050 n=15+15) Tar 261k ± 1% 259k ± 1% -0.77% (p=0.000 n=15+15) XML 411k ± 0% 404k ± 1% -1.55% (p=0.000 n=15+15) [Geo mean] 439k 755k +72.01% name old text-bytes new text-bytes delta HelloSize 694kB ± 0% 694kB ± 0% -0.00% (p=0.000 n=15+15) name old data-bytes new data-bytes delta HelloSize 5.55kB ± 0% 5.55kB ± 0% ~ (all equal) name old bss-bytes new bss-bytes delta HelloSize 133kB ± 0% 133kB ± 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 1.04MB ± 0% 1.04MB ± 0% ~ (all equal) Change-Id: I991fc553ef175db46bb23b2128317bbd48de70d8 Reviewed-on: https://go-review.googlesource.com/41770 Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
2017-07-21 18:30:19 -04:00
// Copy phi ops into new schedule.
b.Values = append(b.Values, phis...)
cmd/compile: optimize regalloc for phi value When allocating registers for phi value, only the primary predecessor is considered. Taking into account the allocation status of other predecessors can help reduce unnecessary copy or spill operations. Many such cases can be found in the standard library, such as runtime.wirep, moveByType, etc. The test results from benchstat also show that this change helps reduce the file size. name old time/op new time/op delta Template 328ms ± 5% 326ms ± 4% ~ (p=0.254 n=50+47) Unicode 156ms ± 7% 158ms ±10% ~ (p=0.412 n=49+49) GoTypes 1.07s ± 3% 1.07s ± 2% ~ (p=0.664 n=48+49) Compiler 4.43s ± 3% 4.44s ± 3% ~ (p=0.758 n=48+50) SSA 10.3s ± 2% 10.4s ± 2% +0.43% (p=0.017 n=50+46) Flate 208ms ± 9% 209ms ± 7% ~ (p=0.920 n=49+46) GoParser 260ms ± 5% 262ms ± 4% ~ (p=0.063 n=50+48) Reflect 687ms ± 3% 685ms ± 2% ~ (p=0.459 n=50+48) Tar 293ms ± 4% 293ms ± 5% ~ (p=0.695 n=49+48) XML 391ms ± 4% 389ms ± 3% ~ (p=0.109 n=49+46) LinkCompiler 570ms ± 5% 563ms ± 5% -1.10% (p=0.006 n=46+47) ExternalLinkCompiler 1.57s ± 3% 1.56s ± 3% ~ (p=0.118 n=47+46) LinkWithoutDebugCompiler 349ms ± 6% 349ms ± 5% ~ (p=0.726 n=49+47) [Geo mean] 645ms 645ms -0.05% name old user-time/op new user-time/op delta Template 507ms ±14% 513ms ±14% ~ (p=0.398 n=48+49) Unicode 345ms ±29% 345ms ±38% ~ (p=0.521 n=47+49) GoTypes 1.95s ±16% 1.94s ±19% ~ (p=0.324 n=50+50) Compiler 8.26s ±16% 8.22s ±14% ~ (p=0.834 n=50+50) SSA 19.6s ± 8% 19.2s ±15% ~ (p=0.056 n=50+50) Flate 293ms ± 9% 299ms ±12% ~ (p=0.057 n=47+50) GoParser 388ms ± 9% 387ms ±14% ~ (p=0.660 n=46+50) Reflect 1.15s ±28% 1.12s ±18% ~ (p=0.648 n=49+48) Tar 456ms ±10% 476ms ±15% +4.48% (p=0.001 n=46+48) XML 648ms ±27% 634ms ±16% ~ (p=0.685 n=50+46) LinkCompiler 1.00s ± 8% 1.00s ± 8% ~ (p=0.638 n=50+50) ExternalLinkCompiler 1.96s ± 5% 1.96s ± 5% ~ (p=0.792 n=50+50) LinkWithoutDebugCompiler 443ms ±10% 442ms ±11% ~ (p=0.813 n=50+50) [Geo mean] 1.05s 1.05s -0.09% name old alloc/op new alloc/op delta Template 36.0MB ± 0% 36.0MB ± 0% ~ (p=0.599 n=49+50) Unicode 29.8MB ± 0% 29.8MB ± 0% ~ (p=0.739 n=50+50) GoTypes 118MB ± 0% 118MB ± 0% ~ (p=0.436 n=50+50) Compiler 562MB ± 0% 562MB ± 0% ~ (p=0.693 n=50+50) SSA 1.42GB ± 0% 1.42GB ± 0% -0.10% (p=0.000 n=50+49) Flate 22.5MB ± 0% 22.5MB ± 0% ~ (p=0.429 n=48+49) GoParser 27.7MB ± 0% 27.7MB ± 0% ~ (p=0.705 n=49+48) Reflect 77.7MB ± 0% 77.7MB ± 0% -0.01% (p=0.043 n=50+50) Tar 33.8MB ± 0% 33.8MB ± 0% ~ (p=0.241 n=49+50) XML 42.8MB ± 0% 42.8MB ± 0% ~ (p=0.677 n=47+49) LinkCompiler 98.3MB ± 0% 98.3MB ± 0% ~ (p=0.157 n=50+50) ExternalLinkCompiler 89.4MB ± 0% 89.4MB ± 0% ~ (p=0.683 n=50+50) LinkWithoutDebugCompiler 56.7MB ± 0% 56.7MB ± 0% ~ (p=0.155 n=49+49) [Geo mean] 77.3MB 77.3MB -0.01% name old allocs/op new allocs/op delta Template 367k ± 0% 367k ± 0% ~ (p=0.863 n=50+50) Unicode 345k ± 0% 345k ± 0% ~ (p=0.744 n=49+49) GoTypes 1.28M ± 0% 1.28M ± 0% ~ (p=0.957 n=48+50) Compiler 5.39M ± 0% 5.39M ± 0% +0.00% (p=0.012 n=50+49) SSA 13.9M ± 0% 13.9M ± 0% +0.02% (p=0.000 n=47+49) Flate 230k ± 0% 230k ± 0% -0.01% (p=0.007 n=47+49) GoParser 292k ± 0% 292k ± 0% ~ (p=0.891 n=50+49) Reflect 977k ± 0% 977k ± 0% ~ (p=0.274 n=50+50) Tar 343k ± 0% 343k ± 0% ~ (p=0.942 n=50+50) XML 418k ± 0% 418k ± 0% ~ (p=0.374 n=50+49) LinkCompiler 516k ± 0% 516k ± 0% ~ (p=0.205 n=49+47) ExternalLinkCompiler 570k ± 0% 570k ± 0% ~ (p=0.783 n=49+47) LinkWithoutDebugCompiler 169k ± 0% 169k ± 0% ~ (p=0.233 n=50+46) [Geo mean] 672k 672k +0.00% name old maxRSS/op new maxRSS/op delta Template 34.5M ± 3% 34.4M ± 3% ~ (p=0.566 n=49+48) Unicode 36.0M ± 6% 35.9M ± 6% ~ (p=0.736 n=50+50) GoTypes 75.7M ± 7% 75.4M ± 5% ~ (p=0.412 n=50+50) Compiler 314M ±10% 313M ± 8% ~ (p=0.708 n=50+50) SSA 730M ± 6% 735M ± 6% ~ (p=0.324 n=50+50) Flate 25.8M ± 5% 25.6M ± 6% ~ (p=0.415 n=49+50) GoParser 28.5M ± 3% 28.5M ± 4% ~ (p=0.977 n=46+50) Reflect 57.4M ± 4% 57.2M ± 3% ~ (p=0.173 n=50+50) Tar 33.3M ± 3% 33.2M ± 4% ~ (p=0.621 n=48+50) XML 39.6M ± 5% 39.6M ± 4% ~ (p=0.997 n=50+50) LinkCompiler 168M ± 2% 167M ± 1% ~ (p=0.072 n=49+45) ExternalLinkCompiler 179M ± 1% 179M ± 1% ~ (p=0.147 n=48+50) LinkWithoutDebugCompiler 136M ± 1% 136M ± 1% ~ (p=0.789 n=47+49) [Geo mean] 79.2M 79.1M -0.12% name old text-bytes new text-bytes delta HelloSize 812kB ± 0% 811kB ± 0% -0.06% (p=0.000 n=50+50) name old data-bytes new data-bytes delta HelloSize 13.3kB ± 0% 13.3kB ± 0% ~ (all equal) name old bss-bytes new bss-bytes delta HelloSize 206kB ± 0% 206kB ± 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 1.21MB ± 0% 1.21MB ± 0% -0.03% (p=0.000 n=50+50) file before after Δ % addr2line 4057421 4056237 -1184 -0.029% api 4952451 4946715 -5736 -0.116% asm 4888993 4888185 -808 -0.017% buildid 2617705 2616441 -1264 -0.048% cgo 4521849 4520681 -1168 -0.026% compile 19143451 19141243 -2208 -0.012% cover 4847391 4837151 -10240 -0.211% dist 3473877 3472565 -1312 -0.038% doc 3821496 3820432 -1064 -0.028% fix 3220587 3220659 +72 +0.002% link 6587504 6582576 -4928 -0.075% nm 4000154 3998690 -1464 -0.037% objdump 4409449 4407625 -1824 -0.041% pack 2398086 2393110 -4976 -0.207% pprof 13599060 13606111 +7051 +0.052% test2json 2645148 2645692 +544 +0.021% trace 10355281 10355862 +581 +0.006% vet 6780026 6779666 -360 -0.005% total 106319929 106289641 -30288 -0.028% Change-Id: Ia5399286958c187c8664c769bbddf7bc4c1cae99 Reviewed-on: https://go-review.googlesource.com/c/go/+/263600 Run-TryBot: eric fang <eric.fang@arm.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: eric fang <eric.fang@arm.com> Reviewed-by: Keith Randall <khr@golang.org>
2020-10-19 11:20:24 +08:00
// Third pass - pick registers for phis whose input
// was not in a register in the primary predecessor.
for i, v := range phis {
if !s.values[v.ID].needReg {
continue
}
if phiRegs[i] != noRegister {
continue
}
m := s.compatRegs(v.Type) &^ phiUsed &^ s.used
cmd/compile: optimize regalloc for phi value When allocating registers for phi value, only the primary predecessor is considered. Taking into account the allocation status of other predecessors can help reduce unnecessary copy or spill operations. Many such cases can be found in the standard library, such as runtime.wirep, moveByType, etc. The test results from benchstat also show that this change helps reduce the file size. name old time/op new time/op delta Template 328ms ± 5% 326ms ± 4% ~ (p=0.254 n=50+47) Unicode 156ms ± 7% 158ms ±10% ~ (p=0.412 n=49+49) GoTypes 1.07s ± 3% 1.07s ± 2% ~ (p=0.664 n=48+49) Compiler 4.43s ± 3% 4.44s ± 3% ~ (p=0.758 n=48+50) SSA 10.3s ± 2% 10.4s ± 2% +0.43% (p=0.017 n=50+46) Flate 208ms ± 9% 209ms ± 7% ~ (p=0.920 n=49+46) GoParser 260ms ± 5% 262ms ± 4% ~ (p=0.063 n=50+48) Reflect 687ms ± 3% 685ms ± 2% ~ (p=0.459 n=50+48) Tar 293ms ± 4% 293ms ± 5% ~ (p=0.695 n=49+48) XML 391ms ± 4% 389ms ± 3% ~ (p=0.109 n=49+46) LinkCompiler 570ms ± 5% 563ms ± 5% -1.10% (p=0.006 n=46+47) ExternalLinkCompiler 1.57s ± 3% 1.56s ± 3% ~ (p=0.118 n=47+46) LinkWithoutDebugCompiler 349ms ± 6% 349ms ± 5% ~ (p=0.726 n=49+47) [Geo mean] 645ms 645ms -0.05% name old user-time/op new user-time/op delta Template 507ms ±14% 513ms ±14% ~ (p=0.398 n=48+49) Unicode 345ms ±29% 345ms ±38% ~ (p=0.521 n=47+49) GoTypes 1.95s ±16% 1.94s ±19% ~ (p=0.324 n=50+50) Compiler 8.26s ±16% 8.22s ±14% ~ (p=0.834 n=50+50) SSA 19.6s ± 8% 19.2s ±15% ~ (p=0.056 n=50+50) Flate 293ms ± 9% 299ms ±12% ~ (p=0.057 n=47+50) GoParser 388ms ± 9% 387ms ±14% ~ (p=0.660 n=46+50) Reflect 1.15s ±28% 1.12s ±18% ~ (p=0.648 n=49+48) Tar 456ms ±10% 476ms ±15% +4.48% (p=0.001 n=46+48) XML 648ms ±27% 634ms ±16% ~ (p=0.685 n=50+46) LinkCompiler 1.00s ± 8% 1.00s ± 8% ~ (p=0.638 n=50+50) ExternalLinkCompiler 1.96s ± 5% 1.96s ± 5% ~ (p=0.792 n=50+50) LinkWithoutDebugCompiler 443ms ±10% 442ms ±11% ~ (p=0.813 n=50+50) [Geo mean] 1.05s 1.05s -0.09% name old alloc/op new alloc/op delta Template 36.0MB ± 0% 36.0MB ± 0% ~ (p=0.599 n=49+50) Unicode 29.8MB ± 0% 29.8MB ± 0% ~ (p=0.739 n=50+50) GoTypes 118MB ± 0% 118MB ± 0% ~ (p=0.436 n=50+50) Compiler 562MB ± 0% 562MB ± 0% ~ (p=0.693 n=50+50) SSA 1.42GB ± 0% 1.42GB ± 0% -0.10% (p=0.000 n=50+49) Flate 22.5MB ± 0% 22.5MB ± 0% ~ (p=0.429 n=48+49) GoParser 27.7MB ± 0% 27.7MB ± 0% ~ (p=0.705 n=49+48) Reflect 77.7MB ± 0% 77.7MB ± 0% -0.01% (p=0.043 n=50+50) Tar 33.8MB ± 0% 33.8MB ± 0% ~ (p=0.241 n=49+50) XML 42.8MB ± 0% 42.8MB ± 0% ~ (p=0.677 n=47+49) LinkCompiler 98.3MB ± 0% 98.3MB ± 0% ~ (p=0.157 n=50+50) ExternalLinkCompiler 89.4MB ± 0% 89.4MB ± 0% ~ (p=0.683 n=50+50) LinkWithoutDebugCompiler 56.7MB ± 0% 56.7MB ± 0% ~ (p=0.155 n=49+49) [Geo mean] 77.3MB 77.3MB -0.01% name old allocs/op new allocs/op delta Template 367k ± 0% 367k ± 0% ~ (p=0.863 n=50+50) Unicode 345k ± 0% 345k ± 0% ~ (p=0.744 n=49+49) GoTypes 1.28M ± 0% 1.28M ± 0% ~ (p=0.957 n=48+50) Compiler 5.39M ± 0% 5.39M ± 0% +0.00% (p=0.012 n=50+49) SSA 13.9M ± 0% 13.9M ± 0% +0.02% (p=0.000 n=47+49) Flate 230k ± 0% 230k ± 0% -0.01% (p=0.007 n=47+49) GoParser 292k ± 0% 292k ± 0% ~ (p=0.891 n=50+49) Reflect 977k ± 0% 977k ± 0% ~ (p=0.274 n=50+50) Tar 343k ± 0% 343k ± 0% ~ (p=0.942 n=50+50) XML 418k ± 0% 418k ± 0% ~ (p=0.374 n=50+49) LinkCompiler 516k ± 0% 516k ± 0% ~ (p=0.205 n=49+47) ExternalLinkCompiler 570k ± 0% 570k ± 0% ~ (p=0.783 n=49+47) LinkWithoutDebugCompiler 169k ± 0% 169k ± 0% ~ (p=0.233 n=50+46) [Geo mean] 672k 672k +0.00% name old maxRSS/op new maxRSS/op delta Template 34.5M ± 3% 34.4M ± 3% ~ (p=0.566 n=49+48) Unicode 36.0M ± 6% 35.9M ± 6% ~ (p=0.736 n=50+50) GoTypes 75.7M ± 7% 75.4M ± 5% ~ (p=0.412 n=50+50) Compiler 314M ±10% 313M ± 8% ~ (p=0.708 n=50+50) SSA 730M ± 6% 735M ± 6% ~ (p=0.324 n=50+50) Flate 25.8M ± 5% 25.6M ± 6% ~ (p=0.415 n=49+50) GoParser 28.5M ± 3% 28.5M ± 4% ~ (p=0.977 n=46+50) Reflect 57.4M ± 4% 57.2M ± 3% ~ (p=0.173 n=50+50) Tar 33.3M ± 3% 33.2M ± 4% ~ (p=0.621 n=48+50) XML 39.6M ± 5% 39.6M ± 4% ~ (p=0.997 n=50+50) LinkCompiler 168M ± 2% 167M ± 1% ~ (p=0.072 n=49+45) ExternalLinkCompiler 179M ± 1% 179M ± 1% ~ (p=0.147 n=48+50) LinkWithoutDebugCompiler 136M ± 1% 136M ± 1% ~ (p=0.789 n=47+49) [Geo mean] 79.2M 79.1M -0.12% name old text-bytes new text-bytes delta HelloSize 812kB ± 0% 811kB ± 0% -0.06% (p=0.000 n=50+50) name old data-bytes new data-bytes delta HelloSize 13.3kB ± 0% 13.3kB ± 0% ~ (all equal) name old bss-bytes new bss-bytes delta HelloSize 206kB ± 0% 206kB ± 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 1.21MB ± 0% 1.21MB ± 0% -0.03% (p=0.000 n=50+50) file before after Δ % addr2line 4057421 4056237 -1184 -0.029% api 4952451 4946715 -5736 -0.116% asm 4888993 4888185 -808 -0.017% buildid 2617705 2616441 -1264 -0.048% cgo 4521849 4520681 -1168 -0.026% compile 19143451 19141243 -2208 -0.012% cover 4847391 4837151 -10240 -0.211% dist 3473877 3472565 -1312 -0.038% doc 3821496 3820432 -1064 -0.028% fix 3220587 3220659 +72 +0.002% link 6587504 6582576 -4928 -0.075% nm 4000154 3998690 -1464 -0.037% objdump 4409449 4407625 -1824 -0.041% pack 2398086 2393110 -4976 -0.207% pprof 13599060 13606111 +7051 +0.052% test2json 2645148 2645692 +544 +0.021% trace 10355281 10355862 +581 +0.006% vet 6780026 6779666 -360 -0.005% total 106319929 106289641 -30288 -0.028% Change-Id: Ia5399286958c187c8664c769bbddf7bc4c1cae99 Reviewed-on: https://go-review.googlesource.com/c/go/+/263600 Run-TryBot: eric fang <eric.fang@arm.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: eric fang <eric.fang@arm.com> Reviewed-by: Keith Randall <khr@golang.org>
2020-10-19 11:20:24 +08:00
// If one of the other inputs of v is in a register, and the register is available,
// select this register, which can save some unnecessary copies.
for i, pe := range b.Preds {
cmd/compile: use depth first topological sort algorithm for layout The current layout algorithm tries to put consecutive blocks together, so the priority of the successor block is higher than the priority of the zero indegree block. This algorithm is beneficial for subsequent register allocation, but will result in more branch instructions. The depth-first topological sorting algorithm is a well-known layout algorithm, which has applications in many languages, and it helps to reduce branch instructions. This CL applies it to the layout pass. The test results show that it helps to reduce the code size. This CL also includes the following changes: 1, Removed the primary predecessor mechanism. The new layout algorithm is not very friendly to register allocator in some cases, in order to adapt to the new layout algorithm, a new primary predecessor selection strategy is introduced. 2, Since the new layout implementation may place non-loop blocks between loop blocks, some adaptive modifications have also been made to looprotate pass. 3, The layout also affects the results of codegen, so this CL also adjusted several codegen tests accordingly. It is inevitable that this CL will cause the code size or performance of a few functions to decrease, but the number of cases it improves is much larger than the number of cases it drops. Statistical data from compilecmp on linux/amd64 is as follow: name old time/op new time/op delta Template 382ms ± 4% 382ms ± 4% ~ (p=0.497 n=49+50) Unicode 170ms ± 9% 169ms ± 8% ~ (p=0.344 n=48+50) GoTypes 2.01s ± 4% 2.01s ± 4% ~ (p=0.628 n=50+48) Compiler 190ms ±10% 189ms ± 9% ~ (p=0.734 n=50+50) SSA 11.8s ± 2% 11.8s ± 3% ~ (p=0.877 n=50+50) Flate 241ms ± 9% 241ms ± 8% ~ (p=0.897 n=50+49) GoParser 366ms ± 3% 361ms ± 4% -1.21% (p=0.004 n=47+50) Reflect 835ms ± 3% 838ms ± 3% ~ (p=0.275 n=50+49) Tar 336ms ± 4% 335ms ± 3% ~ (p=0.454 n=48+48) XML 433ms ± 4% 431ms ± 3% ~ (p=0.071 n=49+48) LinkCompiler 706ms ± 4% 705ms ± 4% ~ (p=0.608 n=50+49) ExternalLinkCompiler 1.85s ± 3% 1.83s ± 2% -1.47% (p=0.000 n=49+48) LinkWithoutDebugCompiler 437ms ± 5% 437ms ± 6% ~ (p=0.953 n=49+50) [Geo mean] 615ms 613ms -0.37% name old alloc/op new alloc/op delta Template 38.7MB ± 1% 38.7MB ± 1% ~ (p=0.834 n=50+50) Unicode 28.1MB ± 0% 28.1MB ± 0% -0.22% (p=0.000 n=49+50) GoTypes 168MB ± 1% 168MB ± 1% ~ (p=0.054 n=47+47) Compiler 23.0MB ± 1% 23.0MB ± 1% ~ (p=0.432 n=50+50) SSA 1.54GB ± 0% 1.54GB ± 0% +0.21% (p=0.000 n=50+50) Flate 23.6MB ± 1% 23.6MB ± 1% ~ (p=0.153 n=43+46) GoParser 35.1MB ± 1% 35.1MB ± 2% ~ (p=0.202 n=50+50) Reflect 84.7MB ± 1% 84.7MB ± 1% ~ (p=0.333 n=48+49) Tar 34.5MB ± 1% 34.5MB ± 1% ~ (p=0.406 n=46+49) XML 44.3MB ± 2% 44.2MB ± 3% ~ (p=0.981 n=50+50) LinkCompiler 131MB ± 0% 128MB ± 0% -2.74% (p=0.000 n=50+50) ExternalLinkCompiler 120MB ± 0% 120MB ± 0% +0.01% (p=0.007 n=50+50) LinkWithoutDebugCompiler 77.3MB ± 0% 77.3MB ± 0% -0.02% (p=0.000 n=50+50) [Geo mean] 69.3MB 69.1MB -0.22% file before after Δ % addr2line 4104220 4043684 -60536 -1.475% api 5342502 5249678 -92824 -1.737% asm 4973785 4858257 -115528 -2.323% buildid 2667844 2625660 -42184 -1.581% cgo 4686849 4616313 -70536 -1.505% compile 23667431 23268406 -399025 -1.686% cover 4959676 4874108 -85568 -1.725% dist 3515934 3450422 -65512 -1.863% doc 3995581 3925469 -70112 -1.755% fix 3379202 3318522 -60680 -1.796% link 6743249 6629913 -113336 -1.681% nm 4047529 3991777 -55752 -1.377% objdump 4456151 4388151 -68000 -1.526% pack 2435040 2398072 -36968 -1.518% pprof 13804080 13565808 -238272 -1.726% test2json 2690043 2645987 -44056 -1.638% trace 10418492 10232716 -185776 -1.783% vet 7258259 7121259 -137000 -1.888% total 113145867 111204202 -1941665 -1.716% The situation on linux/arm64 is as follow: name old time/op new time/op delta Template 280ms ± 1% 282ms ± 1% +0.75% (p=0.000 n=46+48) Unicode 124ms ± 2% 124ms ± 2% +0.37% (p=0.045 n=50+50) GoTypes 1.69s ± 1% 1.70s ± 1% +0.56% (p=0.000 n=49+50) Compiler 122ms ± 1% 123ms ± 1% +0.93% (p=0.000 n=50+50) SSA 12.6s ± 1% 12.7s ± 0% +0.72% (p=0.000 n=50+50) Flate 170ms ± 1% 172ms ± 1% +0.97% (p=0.000 n=49+49) GoParser 262ms ± 1% 263ms ± 1% +0.39% (p=0.000 n=49+48) Reflect 639ms ± 1% 650ms ± 1% +1.63% (p=0.000 n=49+49) Tar 243ms ± 1% 245ms ± 1% +0.82% (p=0.000 n=50+50) XML 324ms ± 1% 327ms ± 1% +0.72% (p=0.000 n=50+49) LinkCompiler 597ms ± 1% 596ms ± 1% -0.27% (p=0.001 n=48+47) ExternalLinkCompiler 1.90s ± 1% 1.88s ± 1% -1.00% (p=0.000 n=50+50) LinkWithoutDebugCompiler 364ms ± 1% 363ms ± 1% ~ (p=0.220 n=49+50) [Geo mean] 485ms 488ms +0.49% name old alloc/op new alloc/op delta Template 38.7MB ± 0% 38.8MB ± 1% ~ (p=0.093 n=43+49) Unicode 28.4MB ± 0% 28.4MB ± 0% +0.03% (p=0.000 n=49+45) GoTypes 169MB ± 1% 169MB ± 1% +0.23% (p=0.010 n=50+50) Compiler 23.2MB ± 1% 23.2MB ± 1% +0.11% (p=0.000 n=40+44) SSA 1.54GB ± 0% 1.55GB ± 0% +0.45% (p=0.000 n=47+49) Flate 23.8MB ± 2% 23.8MB ± 1% ~ (p=0.543 n=50+50) GoParser 35.3MB ± 1% 35.4MB ± 1% ~ (p=0.792 n=50+50) Reflect 85.2MB ± 1% 85.2MB ± 0% ~ (p=0.055 n=50+47) Tar 34.5MB ± 1% 34.5MB ± 1% +0.06% (p=0.015 n=50+50) XML 43.8MB ± 2% 43.9MB ± 2% +0.19% (p=0.000 n=48+48) LinkCompiler 137MB ± 0% 136MB ± 0% -0.92% (p=0.000 n=50+50) ExternalLinkCompiler 127MB ± 0% 127MB ± 0% ~ (p=0.516 n=50+50) LinkWithoutDebugCompiler 84.0MB ± 0% 84.0MB ± 0% ~ (p=0.057 n=50+50) [Geo mean] 70.4MB 70.4MB +0.01% file before after Δ % addr2line 4021557 4002933 -18624 -0.463% api 5127847 5028503 -99344 -1.937% asm 5034716 4936836 -97880 -1.944% buildid 2608118 2594094 -14024 -0.538% cgo 4488592 4398320 -90272 -2.011% compile 22501129 22213592 -287537 -1.278% cover 4742301 4713573 -28728 -0.606% dist 3388071 3365311 -22760 -0.672% doc 3802250 3776082 -26168 -0.688% fix 3306147 3216939 -89208 -2.698% link 6404483 6363699 -40784 -0.637% nm 3941026 3921930 -19096 -0.485% objdump 4383330 4295122 -88208 -2.012% pack 2404547 2389515 -15032 -0.625% pprof 12996234 12856818 -139416 -1.073% test2json 2668500 2586788 -81712 -3.062% trace 9816276 9609580 -206696 -2.106% vet 6900682 6787338 -113344 -1.643% total 108535806 107056973 -1478833 -1.363% Change-Id: Iaec1cdcaacca8025e9babb0fb8a532fddb70c87d Reviewed-on: https://go-review.googlesource.com/c/go/+/255239 Reviewed-by: eric fang <eric.fang@arm.com> Reviewed-by: Keith Randall <khr@golang.org> Trust: eric fang <eric.fang@arm.com>
2020-07-23 10:24:56 +08:00
if i == idx {
cmd/compile: optimize regalloc for phi value When allocating registers for phi value, only the primary predecessor is considered. Taking into account the allocation status of other predecessors can help reduce unnecessary copy or spill operations. Many such cases can be found in the standard library, such as runtime.wirep, moveByType, etc. The test results from benchstat also show that this change helps reduce the file size. name old time/op new time/op delta Template 328ms ± 5% 326ms ± 4% ~ (p=0.254 n=50+47) Unicode 156ms ± 7% 158ms ±10% ~ (p=0.412 n=49+49) GoTypes 1.07s ± 3% 1.07s ± 2% ~ (p=0.664 n=48+49) Compiler 4.43s ± 3% 4.44s ± 3% ~ (p=0.758 n=48+50) SSA 10.3s ± 2% 10.4s ± 2% +0.43% (p=0.017 n=50+46) Flate 208ms ± 9% 209ms ± 7% ~ (p=0.920 n=49+46) GoParser 260ms ± 5% 262ms ± 4% ~ (p=0.063 n=50+48) Reflect 687ms ± 3% 685ms ± 2% ~ (p=0.459 n=50+48) Tar 293ms ± 4% 293ms ± 5% ~ (p=0.695 n=49+48) XML 391ms ± 4% 389ms ± 3% ~ (p=0.109 n=49+46) LinkCompiler 570ms ± 5% 563ms ± 5% -1.10% (p=0.006 n=46+47) ExternalLinkCompiler 1.57s ± 3% 1.56s ± 3% ~ (p=0.118 n=47+46) LinkWithoutDebugCompiler 349ms ± 6% 349ms ± 5% ~ (p=0.726 n=49+47) [Geo mean] 645ms 645ms -0.05% name old user-time/op new user-time/op delta Template 507ms ±14% 513ms ±14% ~ (p=0.398 n=48+49) Unicode 345ms ±29% 345ms ±38% ~ (p=0.521 n=47+49) GoTypes 1.95s ±16% 1.94s ±19% ~ (p=0.324 n=50+50) Compiler 8.26s ±16% 8.22s ±14% ~ (p=0.834 n=50+50) SSA 19.6s ± 8% 19.2s ±15% ~ (p=0.056 n=50+50) Flate 293ms ± 9% 299ms ±12% ~ (p=0.057 n=47+50) GoParser 388ms ± 9% 387ms ±14% ~ (p=0.660 n=46+50) Reflect 1.15s ±28% 1.12s ±18% ~ (p=0.648 n=49+48) Tar 456ms ±10% 476ms ±15% +4.48% (p=0.001 n=46+48) XML 648ms ±27% 634ms ±16% ~ (p=0.685 n=50+46) LinkCompiler 1.00s ± 8% 1.00s ± 8% ~ (p=0.638 n=50+50) ExternalLinkCompiler 1.96s ± 5% 1.96s ± 5% ~ (p=0.792 n=50+50) LinkWithoutDebugCompiler 443ms ±10% 442ms ±11% ~ (p=0.813 n=50+50) [Geo mean] 1.05s 1.05s -0.09% name old alloc/op new alloc/op delta Template 36.0MB ± 0% 36.0MB ± 0% ~ (p=0.599 n=49+50) Unicode 29.8MB ± 0% 29.8MB ± 0% ~ (p=0.739 n=50+50) GoTypes 118MB ± 0% 118MB ± 0% ~ (p=0.436 n=50+50) Compiler 562MB ± 0% 562MB ± 0% ~ (p=0.693 n=50+50) SSA 1.42GB ± 0% 1.42GB ± 0% -0.10% (p=0.000 n=50+49) Flate 22.5MB ± 0% 22.5MB ± 0% ~ (p=0.429 n=48+49) GoParser 27.7MB ± 0% 27.7MB ± 0% ~ (p=0.705 n=49+48) Reflect 77.7MB ± 0% 77.7MB ± 0% -0.01% (p=0.043 n=50+50) Tar 33.8MB ± 0% 33.8MB ± 0% ~ (p=0.241 n=49+50) XML 42.8MB ± 0% 42.8MB ± 0% ~ (p=0.677 n=47+49) LinkCompiler 98.3MB ± 0% 98.3MB ± 0% ~ (p=0.157 n=50+50) ExternalLinkCompiler 89.4MB ± 0% 89.4MB ± 0% ~ (p=0.683 n=50+50) LinkWithoutDebugCompiler 56.7MB ± 0% 56.7MB ± 0% ~ (p=0.155 n=49+49) [Geo mean] 77.3MB 77.3MB -0.01% name old allocs/op new allocs/op delta Template 367k ± 0% 367k ± 0% ~ (p=0.863 n=50+50) Unicode 345k ± 0% 345k ± 0% ~ (p=0.744 n=49+49) GoTypes 1.28M ± 0% 1.28M ± 0% ~ (p=0.957 n=48+50) Compiler 5.39M ± 0% 5.39M ± 0% +0.00% (p=0.012 n=50+49) SSA 13.9M ± 0% 13.9M ± 0% +0.02% (p=0.000 n=47+49) Flate 230k ± 0% 230k ± 0% -0.01% (p=0.007 n=47+49) GoParser 292k ± 0% 292k ± 0% ~ (p=0.891 n=50+49) Reflect 977k ± 0% 977k ± 0% ~ (p=0.274 n=50+50) Tar 343k ± 0% 343k ± 0% ~ (p=0.942 n=50+50) XML 418k ± 0% 418k ± 0% ~ (p=0.374 n=50+49) LinkCompiler 516k ± 0% 516k ± 0% ~ (p=0.205 n=49+47) ExternalLinkCompiler 570k ± 0% 570k ± 0% ~ (p=0.783 n=49+47) LinkWithoutDebugCompiler 169k ± 0% 169k ± 0% ~ (p=0.233 n=50+46) [Geo mean] 672k 672k +0.00% name old maxRSS/op new maxRSS/op delta Template 34.5M ± 3% 34.4M ± 3% ~ (p=0.566 n=49+48) Unicode 36.0M ± 6% 35.9M ± 6% ~ (p=0.736 n=50+50) GoTypes 75.7M ± 7% 75.4M ± 5% ~ (p=0.412 n=50+50) Compiler 314M ±10% 313M ± 8% ~ (p=0.708 n=50+50) SSA 730M ± 6% 735M ± 6% ~ (p=0.324 n=50+50) Flate 25.8M ± 5% 25.6M ± 6% ~ (p=0.415 n=49+50) GoParser 28.5M ± 3% 28.5M ± 4% ~ (p=0.977 n=46+50) Reflect 57.4M ± 4% 57.2M ± 3% ~ (p=0.173 n=50+50) Tar 33.3M ± 3% 33.2M ± 4% ~ (p=0.621 n=48+50) XML 39.6M ± 5% 39.6M ± 4% ~ (p=0.997 n=50+50) LinkCompiler 168M ± 2% 167M ± 1% ~ (p=0.072 n=49+45) ExternalLinkCompiler 179M ± 1% 179M ± 1% ~ (p=0.147 n=48+50) LinkWithoutDebugCompiler 136M ± 1% 136M ± 1% ~ (p=0.789 n=47+49) [Geo mean] 79.2M 79.1M -0.12% name old text-bytes new text-bytes delta HelloSize 812kB ± 0% 811kB ± 0% -0.06% (p=0.000 n=50+50) name old data-bytes new data-bytes delta HelloSize 13.3kB ± 0% 13.3kB ± 0% ~ (all equal) name old bss-bytes new bss-bytes delta HelloSize 206kB ± 0% 206kB ± 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 1.21MB ± 0% 1.21MB ± 0% -0.03% (p=0.000 n=50+50) file before after Δ % addr2line 4057421 4056237 -1184 -0.029% api 4952451 4946715 -5736 -0.116% asm 4888993 4888185 -808 -0.017% buildid 2617705 2616441 -1264 -0.048% cgo 4521849 4520681 -1168 -0.026% compile 19143451 19141243 -2208 -0.012% cover 4847391 4837151 -10240 -0.211% dist 3473877 3472565 -1312 -0.038% doc 3821496 3820432 -1064 -0.028% fix 3220587 3220659 +72 +0.002% link 6587504 6582576 -4928 -0.075% nm 4000154 3998690 -1464 -0.037% objdump 4409449 4407625 -1824 -0.041% pack 2398086 2393110 -4976 -0.207% pprof 13599060 13606111 +7051 +0.052% test2json 2645148 2645692 +544 +0.021% trace 10355281 10355862 +581 +0.006% vet 6780026 6779666 -360 -0.005% total 106319929 106289641 -30288 -0.028% Change-Id: Ia5399286958c187c8664c769bbddf7bc4c1cae99 Reviewed-on: https://go-review.googlesource.com/c/go/+/263600 Run-TryBot: eric fang <eric.fang@arm.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: eric fang <eric.fang@arm.com> Reviewed-by: Keith Randall <khr@golang.org>
2020-10-19 11:20:24 +08:00
continue
}
ri := noRegister
for _, er := range s.endRegs[pe.b.ID] {
if er.v == s.orig[v.Args[i].ID] {
ri = er.r
break
}
}
if ri != noRegister && m>>ri&1 != 0 {
m = regMask(1) << ri
break
}
}
if m != 0 {
r := pickReg(m)
phiRegs[i] = r
phiUsed |= regMask(1) << r
}
}
// Set registers for phis. Add phi spill code.
for i, v := range phis {
if !s.values[v.ID].needReg {
continue
}
r := phiRegs[i]
if r == noRegister {
// stack-based phi
// Spills will be inserted in all the predecessors below.
cmd/compile: put spills in better places Previously we always issued a spill right after the op that was being spilled. This CL pushes spills father away from the generator, hopefully pushing them into unlikely branches. For example: x = ... if unlikely { call ... } ... use x ... Used to compile to x = ... spill x if unlikely { call ... restore x } It now compiles to x = ... if unlikely { spill x call ... restore x } This is particularly useful for code which appends, as the only call is an unlikely call to growslice. It also helps for the spills needed around write barrier calls. The basic algorithm is walk down the dominator tree following a path where the block still dominates all of the restores. We're looking for a block that: 1) dominates all restores 2) has the value being spilled in a register 3) has a loop depth no deeper than the value being spilled The walking-down code is iterative. I was forced to limit it to searching 100 blocks so it doesn't become O(n^2). Maybe one day we'll find a better way. I had to delete most of David's code which pushed spills out of loops. I suspect this CL subsumes most of the cases that his code handled. Generally positive performance improvements, but hard to tell for sure with all the noise. (compilebench times are unchanged.) name old time/op new time/op delta BinaryTree17-12 2.91s ±15% 2.80s ±12% ~ (p=0.063 n=10+10) Fannkuch11-12 3.47s ± 0% 3.30s ± 4% -4.91% (p=0.000 n=9+10) FmtFprintfEmpty-12 48.0ns ± 1% 47.4ns ± 1% -1.32% (p=0.002 n=9+9) FmtFprintfString-12 85.6ns ±11% 79.4ns ± 3% -7.27% (p=0.005 n=10+10) FmtFprintfInt-12 91.8ns ±10% 85.9ns ± 4% ~ (p=0.203 n=10+9) FmtFprintfIntInt-12 135ns ±13% 127ns ± 1% -5.72% (p=0.025 n=10+9) FmtFprintfPrefixedInt-12 167ns ± 1% 168ns ± 2% ~ (p=0.580 n=9+10) FmtFprintfFloat-12 249ns ±11% 230ns ± 1% -7.32% (p=0.000 n=10+10) FmtManyArgs-12 504ns ± 7% 506ns ± 1% ~ (p=0.198 n=9+9) GobDecode-12 6.95ms ± 1% 7.04ms ± 1% +1.37% (p=0.001 n=10+10) GobEncode-12 6.32ms ±13% 6.04ms ± 1% ~ (p=0.063 n=10+10) Gzip-12 233ms ± 1% 235ms ± 0% +1.01% (p=0.000 n=10+9) Gunzip-12 40.1ms ± 1% 39.6ms ± 0% -1.12% (p=0.000 n=10+8) HTTPClientServer-12 227µs ± 9% 221µs ± 5% ~ (p=0.114 n=9+8) JSONEncode-12 16.1ms ± 2% 15.8ms ± 1% -2.09% (p=0.002 n=9+8) JSONDecode-12 61.8ms ±11% 57.9ms ± 1% -6.30% (p=0.000 n=10+9) Mandelbrot200-12 4.30ms ± 3% 4.28ms ± 1% ~ (p=0.203 n=10+8) GoParse-12 3.18ms ± 2% 3.18ms ± 2% ~ (p=0.579 n=10+10) RegexpMatchEasy0_32-12 76.7ns ± 1% 77.5ns ± 1% +0.92% (p=0.002 n=9+8) RegexpMatchEasy0_1K-12 239ns ± 3% 239ns ± 1% ~ (p=0.204 n=10+10) RegexpMatchEasy1_32-12 71.4ns ± 1% 70.6ns ± 0% -1.15% (p=0.000 n=10+9) RegexpMatchEasy1_1K-12 383ns ± 2% 390ns ±10% ~ (p=0.181 n=8+9) RegexpMatchMedium_32-12 114ns ± 0% 113ns ± 1% -0.88% (p=0.000 n=9+8) RegexpMatchMedium_1K-12 36.3µs ± 1% 36.8µs ± 1% +1.59% (p=0.000 n=10+8) RegexpMatchHard_32-12 1.90µs ± 1% 1.90µs ± 1% ~ (p=0.341 n=10+10) RegexpMatchHard_1K-12 59.4µs ±11% 57.8µs ± 1% ~ (p=0.968 n=10+9) Revcomp-12 461ms ± 1% 462ms ± 1% ~ (p=1.000 n=9+9) Template-12 67.5ms ± 1% 66.3ms ± 1% -1.77% (p=0.000 n=10+8) TimeParse-12 314ns ± 3% 309ns ± 0% -1.56% (p=0.000 n=9+8) TimeFormat-12 340ns ± 2% 331ns ± 1% -2.79% (p=0.000 n=10+10) The go binary is 0.2% larger. Not really sure why the size would change. Change-Id: Ia5116e53a3aeb025ef350ffc51c14ae5cc17871c Reviewed-on: https://go-review.googlesource.com/34822 Reviewed-by: David Chase <drchase@google.com>
2017-03-07 14:45:46 -05:00
s.values[v.ID].spill = v // v starts life spilled
continue
}
// register-based phi
s.assignReg(r, v, v)
}
cmd/compile: improve startRegs calculation In register allocation, we calculate what values are used in and after the current block. If a value is used only after a function call, since registers are clobbered in call, we don't need to mark the value live at the entrance of the block. Before this CL it is considered live, and unnecessary copy or load may be generated when resolving merge edge. Fixes #14761. On AMD64: name old time/op new time/op delta BinaryTree17-12 2.84s ± 1% 2.81s ± 1% -1.06% (p=0.000 n=10+9) Fannkuch11-12 3.61s ± 0% 3.55s ± 1% -1.77% (p=0.000 n=10+9) FmtFprintfEmpty-12 50.4ns ± 4% 50.0ns ± 1% ~ (p=0.785 n=9+8) FmtFprintfString-12 80.0ns ± 3% 78.2ns ± 3% -2.35% (p=0.004 n=10+9) FmtFprintfInt-12 81.3ns ± 4% 81.8ns ± 2% ~ (p=0.159 n=10+10) FmtFprintfIntInt-12 120ns ± 4% 118ns ± 2% ~ (p=0.218 n=10+10) FmtFprintfPrefixedInt-12 152ns ± 3% 155ns ± 2% +2.11% (p=0.026 n=10+10) FmtFprintfFloat-12 240ns ± 1% 238ns ± 1% -0.79% (p=0.005 n=9+9) FmtManyArgs-12 504ns ± 1% 510ns ± 1% +1.14% (p=0.000 n=8+9) GobDecode-12 7.00ms ± 1% 6.99ms ± 0% ~ (p=0.497 n=9+10) GobEncode-12 5.47ms ± 1% 5.48ms ± 1% ~ (p=0.218 n=10+10) Gzip-12 258ms ± 2% 256ms ± 1% -0.96% (p=0.043 n=10+9) Gunzip-12 38.6ms ± 0% 38.3ms ± 0% -0.64% (p=0.000 n=9+8) HTTPClientServer-12 90.4µs ± 3% 87.2µs ±11% ~ (p=0.053 n=9+10) JSONEncode-12 15.6ms ± 0% 15.6ms ± 1% ~ (p=0.077 n=9+9) JSONDecode-12 55.1ms ± 1% 54.6ms ± 1% -0.85% (p=0.010 n=10+9) Mandelbrot200-12 4.49ms ± 0% 4.47ms ± 0% -0.25% (p=0.000 n=10+8) GoParse-12 3.38ms ± 0% 3.37ms ± 1% ~ (p=0.315 n=8+10) RegexpMatchEasy0_32-12 82.5ns ± 4% 82.0ns ± 0% ~ (p=0.164 n=10+8) RegexpMatchEasy0_1K-12 203ns ± 1% 202ns ± 1% -0.85% (p=0.000 n=9+10) RegexpMatchEasy1_32-12 82.3ns ± 1% 81.1ns ± 0% -1.39% (p=0.000 n=10+8) RegexpMatchEasy1_1K-12 357ns ± 1% 357ns ± 1% ~ (p=0.697 n=8+9) RegexpMatchMedium_32-12 125ns ± 2% 126ns ± 2% ~ (p=0.197 n=10+10) RegexpMatchMedium_1K-12 39.6µs ± 3% 39.6µs ± 1% ~ (p=0.971 n=10+10) RegexpMatchHard_32-12 1.99µs ± 2% 1.99µs ± 4% ~ (p=0.891 n=10+9) RegexpMatchHard_1K-12 60.1µs ± 3% 60.4µs ± 3% ~ (p=0.684 n=10+10) Revcomp-12 531ms ± 6% 441ms ± 0% -16.94% (p=0.000 n=10+9) Template-12 58.9ms ± 1% 58.7ms ± 1% ~ (p=0.315 n=10+10) TimeParse-12 319ns ± 1% 320ns ± 4% ~ (p=0.215 n=9+9) TimeFormat-12 345ns ± 0% 333ns ± 1% -3.36% (p=0.000 n=9+10) [Geo mean] 52.2µs 51.6µs -1.13% On ARM64: name old time/op new time/op delta BinaryTree17-8 8.53s ± 0% 8.36s ± 0% -1.89% (p=0.000 n=10+10) Fannkuch11-8 6.15s ± 0% 6.10s ± 0% -0.67% (p=0.000 n=10+10) FmtFprintfEmpty-8 117ns ± 0% 117ns ± 0% ~ (all equal) FmtFprintfString-8 192ns ± 0% 192ns ± 0% ~ (all equal) FmtFprintfInt-8 198ns ± 0% 198ns ± 0% ~ (p=0.211 n=10+10) FmtFprintfIntInt-8 289ns ± 0% 291ns ± 0% +0.59% (p=0.000 n=7+10) FmtFprintfPrefixedInt-8 320ns ± 2% 317ns ± 0% ~ (p=0.431 n=10+8) FmtFprintfFloat-8 538ns ± 0% 538ns ± 0% ~ (all equal) FmtManyArgs-8 1.17µs ± 1% 1.18µs ± 1% ~ (p=0.063 n=10+10) GobDecode-8 17.0ms ± 1% 17.2ms ± 1% +0.83% (p=0.000 n=10+10) GobEncode-8 14.2ms ± 0% 14.1ms ± 1% -0.78% (p=0.001 n=9+10) Gzip-8 806ms ± 0% 797ms ± 0% -1.12% (p=0.000 n=6+9) Gunzip-8 131ms ± 0% 130ms ± 0% -0.51% (p=0.000 n=10+9) HTTPClientServer-8 206µs ± 9% 212µs ± 2% ~ (p=0.829 n=10+8) JSONEncode-8 40.1ms ± 0% 40.1ms ± 0% ~ (p=0.136 n=9+9) JSONDecode-8 157ms ± 0% 151ms ± 0% -3.32% (p=0.000 n=9+9) Mandelbrot200-8 10.1ms ± 0% 10.1ms ± 0% -0.05% (p=0.000 n=9+8) GoParse-8 8.43ms ± 0% 8.43ms ± 0% ~ (p=0.912 n=10+10) RegexpMatchEasy0_32-8 228ns ± 1% 227ns ± 0% -0.26% (p=0.026 n=10+9) RegexpMatchEasy0_1K-8 1.92µs ± 0% 1.63µs ± 0% -15.18% (p=0.001 n=7+7) RegexpMatchEasy1_32-8 258ns ± 1% 250ns ± 0% -2.83% (p=0.000 n=10+10) RegexpMatchEasy1_1K-8 2.39µs ± 0% 2.13µs ± 0% -10.94% (p=0.000 n=9+9) RegexpMatchMedium_32-8 352ns ± 0% 351ns ± 0% -0.29% (p=0.004 n=9+10) RegexpMatchMedium_1K-8 104µs ± 0% 105µs ± 0% +0.58% (p=0.000 n=8+9) RegexpMatchHard_32-8 5.84µs ± 0% 5.82µs ± 0% -0.27% (p=0.000 n=9+10) RegexpMatchHard_1K-8 177µs ± 0% 177µs ± 0% -0.07% (p=0.000 n=9+9) Revcomp-8 1.57s ± 1% 1.50s ± 1% -4.60% (p=0.000 n=9+10) Template-8 157ms ± 1% 153ms ± 1% -2.28% (p=0.000 n=10+9) TimeParse-8 779ns ± 1% 770ns ± 1% -1.18% (p=0.013 n=10+10) TimeFormat-8 823ns ± 2% 826ns ± 1% ~ (p=0.324 n=10+9) [Geo mean] 144µs 142µs -1.45% Reduce cmd/go text size by 0.5%. Change-Id: I9288ff983c4a7cf03fc0cb35b9b1750828013117 Reviewed-on: https://go-review.googlesource.com/38457 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2017-03-22 21:34:12 -04:00
// Deallocate any values which are no longer live. Phis are excluded.
for r := register(0); r < s.numRegs; r++ {
if phiUsed>>r&1 != 0 {
continue
}
v := s.regs[r].v
if v != nil && !regValLiveSet.contains(v.ID) {
s.freeReg(r)
}
}
// Save the starting state for use by merge edges.
cmd/compile: reduce allocations in regAllocState.regalloc name old time/op new time/op delta Template 281ms ± 2% 282ms ± 3% ~ (p=0.428 n=19+20) Unicode 138ms ± 6% 138ms ± 7% ~ (p=0.813 n=19+20) GoTypes 901ms ± 2% 895ms ± 2% ~ (p=0.050 n=19+20) Compiler 4.25s ± 1% 4.23s ± 1% -0.31% (p=0.031 n=19+18) SSA 9.77s ± 1% 9.78s ± 1% ~ (p=0.512 n=20+20) Flate 187ms ± 3% 187ms ± 4% ~ (p=0.687 n=20+19) GoParser 224ms ± 4% 222ms ± 3% ~ (p=0.301 n=20+20) Reflect 576ms ± 2% 576ms ± 2% ~ (p=0.620 n=20+20) Tar 262ms ± 3% 263ms ± 3% ~ (p=0.599 n=19+18) XML 322ms ± 4% 322ms ± 2% ~ (p=0.512 n=20+20) name old user-time/op new user-time/op delta Template 403ms ± 3% 399ms ± 5% ~ (p=0.149 n=17+20) Unicode 217ms ±12% 217ms ± 9% ~ (p=0.883 n=20+20) GoTypes 1.24s ± 3% 1.24s ± 3% ~ (p=0.718 n=20+20) Compiler 5.90s ± 3% 5.84s ± 5% ~ (p=0.217 n=18+20) SSA 14.0s ± 6% 14.1s ± 5% ~ (p=0.235 n=19+20) Flate 253ms ± 6% 254ms ± 5% ~ (p=0.749 n=20+19) GoParser 309ms ± 7% 307ms ± 5% ~ (p=0.398 n=20+20) Reflect 772ms ± 3% 771ms ± 3% ~ (p=0.901 n=20+19) Tar 368ms ± 5% 369ms ± 8% ~ (p=0.429 n=20+20) XML 435ms ± 5% 434ms ± 5% ~ (p=0.841 n=20+20) name old alloc/op new alloc/op delta Template 39.0MB ± 0% 38.9MB ± 0% -0.21% (p=0.000 n=20+19) Unicode 29.0MB ± 0% 29.0MB ± 0% -0.03% (p=0.000 n=20+20) GoTypes 116MB ± 0% 115MB ± 0% -0.33% (p=0.000 n=20+20) Compiler 498MB ± 0% 496MB ± 0% -0.37% (p=0.000 n=19+20) SSA 1.41GB ± 0% 1.40GB ± 0% -0.24% (p=0.000 n=20+20) Flate 25.0MB ± 0% 25.0MB ± 0% -0.22% (p=0.000 n=20+19) GoParser 31.0MB ± 0% 30.9MB ± 0% -0.23% (p=0.000 n=20+17) Reflect 77.1MB ± 0% 77.0MB ± 0% -0.12% (p=0.000 n=20+20) Tar 39.7MB ± 0% 39.6MB ± 0% -0.17% (p=0.000 n=20+20) XML 44.9MB ± 0% 44.8MB ± 0% -0.29% (p=0.000 n=20+20) name old allocs/op new allocs/op delta Template 386k ± 0% 385k ± 0% -0.28% (p=0.000 n=20+20) Unicode 337k ± 0% 336k ± 0% -0.07% (p=0.000 n=20+20) GoTypes 1.20M ± 0% 1.20M ± 0% -0.41% (p=0.000 n=20+20) Compiler 4.71M ± 0% 4.68M ± 0% -0.52% (p=0.000 n=20+20) SSA 11.7M ± 0% 11.6M ± 0% -0.31% (p=0.000 n=20+19) Flate 238k ± 0% 237k ± 0% -0.28% (p=0.000 n=18+20) GoParser 320k ± 0% 319k ± 0% -0.34% (p=0.000 n=20+19) Reflect 961k ± 0% 959k ± 0% -0.12% (p=0.000 n=20+20) Tar 397k ± 0% 396k ± 0% -0.23% (p=0.000 n=20+20) XML 419k ± 0% 417k ± 0% -0.39% (p=0.000 n=20+19) Change-Id: Ic7ec3614808d9892c1cab3991b996b7a3b8eff21 Reviewed-on: https://go-review.googlesource.com/102676 Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2018-03-27 13:24:45 +02:00
// We append to a stack allocated variable that we'll
// later copy into s.startRegs in one fell swoop, to save
// on allocations.
regList := make([]startReg, 0, 32)
for r := register(0); r < s.numRegs; r++ {
v := s.regs[r].v
if v == nil {
continue
}
if phiUsed>>r&1 != 0 {
// Skip registers that phis used, we'll handle those
// specially during merge edge processing.
continue
}
cmd/compile: put spills in better places Previously we always issued a spill right after the op that was being spilled. This CL pushes spills father away from the generator, hopefully pushing them into unlikely branches. For example: x = ... if unlikely { call ... } ... use x ... Used to compile to x = ... spill x if unlikely { call ... restore x } It now compiles to x = ... if unlikely { spill x call ... restore x } This is particularly useful for code which appends, as the only call is an unlikely call to growslice. It also helps for the spills needed around write barrier calls. The basic algorithm is walk down the dominator tree following a path where the block still dominates all of the restores. We're looking for a block that: 1) dominates all restores 2) has the value being spilled in a register 3) has a loop depth no deeper than the value being spilled The walking-down code is iterative. I was forced to limit it to searching 100 blocks so it doesn't become O(n^2). Maybe one day we'll find a better way. I had to delete most of David's code which pushed spills out of loops. I suspect this CL subsumes most of the cases that his code handled. Generally positive performance improvements, but hard to tell for sure with all the noise. (compilebench times are unchanged.) name old time/op new time/op delta BinaryTree17-12 2.91s ±15% 2.80s ±12% ~ (p=0.063 n=10+10) Fannkuch11-12 3.47s ± 0% 3.30s ± 4% -4.91% (p=0.000 n=9+10) FmtFprintfEmpty-12 48.0ns ± 1% 47.4ns ± 1% -1.32% (p=0.002 n=9+9) FmtFprintfString-12 85.6ns ±11% 79.4ns ± 3% -7.27% (p=0.005 n=10+10) FmtFprintfInt-12 91.8ns ±10% 85.9ns ± 4% ~ (p=0.203 n=10+9) FmtFprintfIntInt-12 135ns ±13% 127ns ± 1% -5.72% (p=0.025 n=10+9) FmtFprintfPrefixedInt-12 167ns ± 1% 168ns ± 2% ~ (p=0.580 n=9+10) FmtFprintfFloat-12 249ns ±11% 230ns ± 1% -7.32% (p=0.000 n=10+10) FmtManyArgs-12 504ns ± 7% 506ns ± 1% ~ (p=0.198 n=9+9) GobDecode-12 6.95ms ± 1% 7.04ms ± 1% +1.37% (p=0.001 n=10+10) GobEncode-12 6.32ms ±13% 6.04ms ± 1% ~ (p=0.063 n=10+10) Gzip-12 233ms ± 1% 235ms ± 0% +1.01% (p=0.000 n=10+9) Gunzip-12 40.1ms ± 1% 39.6ms ± 0% -1.12% (p=0.000 n=10+8) HTTPClientServer-12 227µs ± 9% 221µs ± 5% ~ (p=0.114 n=9+8) JSONEncode-12 16.1ms ± 2% 15.8ms ± 1% -2.09% (p=0.002 n=9+8) JSONDecode-12 61.8ms ±11% 57.9ms ± 1% -6.30% (p=0.000 n=10+9) Mandelbrot200-12 4.30ms ± 3% 4.28ms ± 1% ~ (p=0.203 n=10+8) GoParse-12 3.18ms ± 2% 3.18ms ± 2% ~ (p=0.579 n=10+10) RegexpMatchEasy0_32-12 76.7ns ± 1% 77.5ns ± 1% +0.92% (p=0.002 n=9+8) RegexpMatchEasy0_1K-12 239ns ± 3% 239ns ± 1% ~ (p=0.204 n=10+10) RegexpMatchEasy1_32-12 71.4ns ± 1% 70.6ns ± 0% -1.15% (p=0.000 n=10+9) RegexpMatchEasy1_1K-12 383ns ± 2% 390ns ±10% ~ (p=0.181 n=8+9) RegexpMatchMedium_32-12 114ns ± 0% 113ns ± 1% -0.88% (p=0.000 n=9+8) RegexpMatchMedium_1K-12 36.3µs ± 1% 36.8µs ± 1% +1.59% (p=0.000 n=10+8) RegexpMatchHard_32-12 1.90µs ± 1% 1.90µs ± 1% ~ (p=0.341 n=10+10) RegexpMatchHard_1K-12 59.4µs ±11% 57.8µs ± 1% ~ (p=0.968 n=10+9) Revcomp-12 461ms ± 1% 462ms ± 1% ~ (p=1.000 n=9+9) Template-12 67.5ms ± 1% 66.3ms ± 1% -1.77% (p=0.000 n=10+8) TimeParse-12 314ns ± 3% 309ns ± 0% -1.56% (p=0.000 n=9+8) TimeFormat-12 340ns ± 2% 331ns ± 1% -2.79% (p=0.000 n=10+10) The go binary is 0.2% larger. Not really sure why the size would change. Change-Id: Ia5116e53a3aeb025ef350ffc51c14ae5cc17871c Reviewed-on: https://go-review.googlesource.com/34822 Reviewed-by: David Chase <drchase@google.com>
2017-03-07 14:45:46 -05:00
regList = append(regList, startReg{r, v, s.regs[r].c, s.values[v.ID].uses.pos})
cmd/compile/internal/ssa: drop overwritten regalloc basic block input requirements For the following description, consider the following basic block graph: b1 ───┐┌──── b2 ││ ││ ▼▼ b3 For register allocator transitions between basic blocks, there are two key passes (significant paraphrasing): First, each basic block is visited in some predetermined visit order. This is the core visitOrder range loop in regAllocState.regalloc. The specific ordering heuristics aren't important here, except that the order guarantees that when visiting a basic block at least one of its predecessors has already been visited. Upon visiting a basic block, that block sets its expected starting register state (regAllocState.startRegs) based on the ending register state (regAlloc.State.endRegs) of one of its predecessors. (How it chooses which predecessor to use is not important here.) From that starting state, registers are assigned for all values in the block, ultimately resulting in some ending register state. After all blocks have been visited, the shuffle pass (regAllocState.shuffle) ensures that for each edge, endRegs of the predecessor == startRegs of the successor. That is, it makes sure that the startRegs assumptions actually hold true for each edge. It does this by adding moves to the end of the predecessor block to place values in the expected register for the successor block. These may be moves from other registers, or from memory if the value is spilled. Now on to the actual problem: Assume that b1 places some value v1 into register R10, and thus ends with endRegs containing R10 = v1. When b3 is visited, it selects b1 as its model predecessor and sets startRegs with R10 = v1. b2 does not have v1 in R10, so later in the shuffle pass, we will add a move of v1 into R10 to the end of b2 to ensure it is available for b3. This is all perfectly fine and exactly how things should work. Now suppose that b3 does not use v1. It does need to use some other value v2, which is not currently in a register. When assigning v2 to a register, it finds all registers are already in use and it needs to dump a value. Ultimately, it decides to dump v1 from R10 and replace it with v2. This is fine, but it has downstream effects on shuffle in b2. b3's startRegs still state that R10 = v1, so b2 will add a move to R10 even though b3 will unconditionally overwrite it. i.e., the move at the end of b2 is completely useless and can result in code like: // end of b2 MOV n(SP), R10 // R10 = v1 <-- useless // start of b3 MOV m(SP), R10 // R10 = v2 This is precisely what happened in #58298. This CL addresses this problem by dropping registers from startRegs if they are never used in the basic block prior to getting dumped. This allows the shuffle pass to avoid placing those useless values into the register. There is a significant limitation to this CL, which is that it only impacts the immediate predecessors of an overwriting block. We can discuss this by zooming out a bit on the previous graph: b4 ───┐┌──── b5 ││ ││ ▼▼ b1 ───┐┌──── b2 ││ ││ ▼▼ b3 Here we have the same graph, except we can see the two predecessors of b1. Now suppose that rather than b1 assigning R10 = v1 as above, the assignment is done in b4. b1 has startRegs R10 = v1, doesn't use the value at all, and simply passes it through to endRegs R10 = v1. Now the shuffle pass will require both b2 and b5 to add a move to assigned R10 = v1, because that is specified in their successor startRegs. With this CL, b3 drops R10 = v1 from startRegs, but there is no backwards propagation, so b1 still has R10 = v1 in startRegs, and b5 still needs to add a useless move. Extending this CL with such propagation may significantly increase the number of useless moves we can remove, though it will add complexity to maintenance and could potentially impact build performance depending on how efficiently we could implement the propagation (something I haven't considered carefully). As-is, this optimization does not impact much code. In bent .text size geomean is -0.02%. In the container/heap test binary, 18 of ~2500 functions are impacted by this CL. Bent and sweet do not show a noticeable performance impact one way or another, however #58298 does show a case where this can have impact if the useless instructions end up in the hot path of a tight loop. For #58298. Change-Id: I2fcef37c955159d068fa0725f995a1848add8a5f Reviewed-on: https://go-review.googlesource.com/c/go/+/471158 Run-TryBot: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: David Chase <drchase@google.com>
2023-02-21 13:20:49 -05:00
s.startRegsMask |= regMask(1) << r
}
cmd/compile: reduce allocations in regAllocState.regalloc name old time/op new time/op delta Template 281ms ± 2% 282ms ± 3% ~ (p=0.428 n=19+20) Unicode 138ms ± 6% 138ms ± 7% ~ (p=0.813 n=19+20) GoTypes 901ms ± 2% 895ms ± 2% ~ (p=0.050 n=19+20) Compiler 4.25s ± 1% 4.23s ± 1% -0.31% (p=0.031 n=19+18) SSA 9.77s ± 1% 9.78s ± 1% ~ (p=0.512 n=20+20) Flate 187ms ± 3% 187ms ± 4% ~ (p=0.687 n=20+19) GoParser 224ms ± 4% 222ms ± 3% ~ (p=0.301 n=20+20) Reflect 576ms ± 2% 576ms ± 2% ~ (p=0.620 n=20+20) Tar 262ms ± 3% 263ms ± 3% ~ (p=0.599 n=19+18) XML 322ms ± 4% 322ms ± 2% ~ (p=0.512 n=20+20) name old user-time/op new user-time/op delta Template 403ms ± 3% 399ms ± 5% ~ (p=0.149 n=17+20) Unicode 217ms ±12% 217ms ± 9% ~ (p=0.883 n=20+20) GoTypes 1.24s ± 3% 1.24s ± 3% ~ (p=0.718 n=20+20) Compiler 5.90s ± 3% 5.84s ± 5% ~ (p=0.217 n=18+20) SSA 14.0s ± 6% 14.1s ± 5% ~ (p=0.235 n=19+20) Flate 253ms ± 6% 254ms ± 5% ~ (p=0.749 n=20+19) GoParser 309ms ± 7% 307ms ± 5% ~ (p=0.398 n=20+20) Reflect 772ms ± 3% 771ms ± 3% ~ (p=0.901 n=20+19) Tar 368ms ± 5% 369ms ± 8% ~ (p=0.429 n=20+20) XML 435ms ± 5% 434ms ± 5% ~ (p=0.841 n=20+20) name old alloc/op new alloc/op delta Template 39.0MB ± 0% 38.9MB ± 0% -0.21% (p=0.000 n=20+19) Unicode 29.0MB ± 0% 29.0MB ± 0% -0.03% (p=0.000 n=20+20) GoTypes 116MB ± 0% 115MB ± 0% -0.33% (p=0.000 n=20+20) Compiler 498MB ± 0% 496MB ± 0% -0.37% (p=0.000 n=19+20) SSA 1.41GB ± 0% 1.40GB ± 0% -0.24% (p=0.000 n=20+20) Flate 25.0MB ± 0% 25.0MB ± 0% -0.22% (p=0.000 n=20+19) GoParser 31.0MB ± 0% 30.9MB ± 0% -0.23% (p=0.000 n=20+17) Reflect 77.1MB ± 0% 77.0MB ± 0% -0.12% (p=0.000 n=20+20) Tar 39.7MB ± 0% 39.6MB ± 0% -0.17% (p=0.000 n=20+20) XML 44.9MB ± 0% 44.8MB ± 0% -0.29% (p=0.000 n=20+20) name old allocs/op new allocs/op delta Template 386k ± 0% 385k ± 0% -0.28% (p=0.000 n=20+20) Unicode 337k ± 0% 336k ± 0% -0.07% (p=0.000 n=20+20) GoTypes 1.20M ± 0% 1.20M ± 0% -0.41% (p=0.000 n=20+20) Compiler 4.71M ± 0% 4.68M ± 0% -0.52% (p=0.000 n=20+20) SSA 11.7M ± 0% 11.6M ± 0% -0.31% (p=0.000 n=20+19) Flate 238k ± 0% 237k ± 0% -0.28% (p=0.000 n=18+20) GoParser 320k ± 0% 319k ± 0% -0.34% (p=0.000 n=20+19) Reflect 961k ± 0% 959k ± 0% -0.12% (p=0.000 n=20+20) Tar 397k ± 0% 396k ± 0% -0.23% (p=0.000 n=20+20) XML 419k ± 0% 417k ± 0% -0.39% (p=0.000 n=20+19) Change-Id: Ic7ec3614808d9892c1cab3991b996b7a3b8eff21 Reviewed-on: https://go-review.googlesource.com/102676 Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2018-03-27 13:24:45 +02:00
s.startRegs[b.ID] = make([]startReg, len(regList))
copy(s.startRegs[b.ID], regList)
if s.f.pass.debug > regDebug {
fmt.Printf("after phis\n")
for _, x := range s.startRegs[b.ID] {
fmt.Printf(" %s: v%d\n", &s.registers[x.r], x.v.ID)
}
}
}
// Drop phis from registers if they immediately go dead.
for i, v := range phis {
s.curIdx = i
s.dropIfUnused(v)
}
// Allocate space to record the desired registers for each value.
cmd/compile: avoid some allocations in regalloc Compilebench: name old time/op new time/op delta Template 283ms ± 3% 281ms ± 4% ~ (p=0.242 n=20+20) Unicode 137ms ± 6% 135ms ± 6% ~ (p=0.194 n=20+19) GoTypes 890ms ± 2% 883ms ± 1% -0.74% (p=0.001 n=19+19) Compiler 4.21s ± 2% 4.20s ± 2% -0.40% (p=0.033 n=20+19) SSA 9.86s ± 2% 9.68s ± 1% -1.80% (p=0.000 n=20+19) Flate 185ms ± 5% 185ms ± 7% ~ (p=0.429 n=20+20) GoParser 222ms ± 3% 222ms ± 4% ~ (p=0.588 n=19+20) Reflect 572ms ± 2% 570ms ± 3% ~ (p=0.113 n=19+20) Tar 263ms ± 4% 259ms ± 2% -1.41% (p=0.013 n=20+20) XML 321ms ± 2% 321ms ± 4% ~ (p=0.835 n=20+19) name old user-time/op new user-time/op delta Template 400ms ± 5% 405ms ± 5% ~ (p=0.096 n=20+20) Unicode 217ms ± 8% 213ms ± 8% ~ (p=0.242 n=20+20) GoTypes 1.23s ± 3% 1.22s ± 3% ~ (p=0.923 n=19+20) Compiler 5.76s ± 6% 5.81s ± 2% ~ (p=0.687 n=20+19) SSA 14.2s ± 4% 14.0s ± 4% ~ (p=0.121 n=20+20) Flate 248ms ± 7% 251ms ±10% ~ (p=0.369 n=20+20) GoParser 308ms ± 5% 305ms ± 6% ~ (p=0.336 n=19+20) Reflect 771ms ± 2% 766ms ± 2% ~ (p=0.113 n=20+19) Tar 370ms ± 5% 362ms ± 7% -2.06% (p=0.036 n=19+20) XML 435ms ± 4% 432ms ± 5% ~ (p=0.369 n=20+20) name old alloc/op new alloc/op delta Template 39.5MB ± 0% 39.4MB ± 0% -0.20% (p=0.000 n=20+20) Unicode 29.1MB ± 0% 29.1MB ± 0% ~ (p=0.064 n=20+20) GoTypes 117MB ± 0% 117MB ± 0% -0.17% (p=0.000 n=20+20) Compiler 503MB ± 0% 502MB ± 0% -0.15% (p=0.000 n=19+19) SSA 1.42GB ± 0% 1.42GB ± 0% -0.16% (p=0.000 n=20+20) Flate 25.3MB ± 0% 25.3MB ± 0% -0.19% (p=0.000 n=20+20) GoParser 31.4MB ± 0% 31.3MB ± 0% -0.14% (p=0.000 n=20+18) Reflect 78.1MB ± 0% 77.9MB ± 0% -0.34% (p=0.000 n=20+19) Tar 40.1MB ± 0% 40.0MB ± 0% -0.17% (p=0.000 n=20+20) XML 45.3MB ± 0% 45.2MB ± 0% -0.13% (p=0.000 n=20+20) name old allocs/op new allocs/op delta Template 393k ± 0% 392k ± 0% -0.21% (p=0.000 n=20+19) Unicode 337k ± 0% 337k ± 0% -0.02% (p=0.000 n=20+20) GoTypes 1.22M ± 0% 1.22M ± 0% -0.21% (p=0.000 n=20+20) Compiler 4.77M ± 0% 4.76M ± 0% -0.16% (p=0.000 n=20+20) SSA 11.8M ± 0% 11.8M ± 0% -0.12% (p=0.000 n=20+20) Flate 242k ± 0% 241k ± 0% -0.20% (p=0.000 n=20+20) GoParser 324k ± 0% 324k ± 0% -0.14% (p=0.000 n=20+20) Reflect 985k ± 0% 981k ± 0% -0.38% (p=0.000 n=20+20) Tar 403k ± 0% 402k ± 0% -0.19% (p=0.000 n=20+20) XML 424k ± 0% 424k ± 0% -0.16% (p=0.000 n=19+20) Change-Id: I131e382b64cd6db11a9263a477d45d80c180c499 Reviewed-on: https://go-review.googlesource.com/102421 Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2018-03-24 19:03:54 +01:00
if l := len(oldSched); cap(dinfo) < l {
dinfo = make([]dentry, l)
} else {
dinfo = dinfo[:l]
clear(dinfo)
}
// Load static desired register info at the end of the block.
desired.copy(&s.desired[b.ID])
// Check actual assigned registers at the start of the next block(s).
// Dynamically assigned registers will trump the static
// desired registers computed during liveness analysis.
// Note that we do this phase after startRegs is set above, so that
// we get the right behavior for a block which branches to itself.
for _, e := range b.Succs {
succ := e.b
// TODO: prioritize likely successor?
for _, x := range s.startRegs[succ.ID] {
cmd/compile: put spills in better places Previously we always issued a spill right after the op that was being spilled. This CL pushes spills father away from the generator, hopefully pushing them into unlikely branches. For example: x = ... if unlikely { call ... } ... use x ... Used to compile to x = ... spill x if unlikely { call ... restore x } It now compiles to x = ... if unlikely { spill x call ... restore x } This is particularly useful for code which appends, as the only call is an unlikely call to growslice. It also helps for the spills needed around write barrier calls. The basic algorithm is walk down the dominator tree following a path where the block still dominates all of the restores. We're looking for a block that: 1) dominates all restores 2) has the value being spilled in a register 3) has a loop depth no deeper than the value being spilled The walking-down code is iterative. I was forced to limit it to searching 100 blocks so it doesn't become O(n^2). Maybe one day we'll find a better way. I had to delete most of David's code which pushed spills out of loops. I suspect this CL subsumes most of the cases that his code handled. Generally positive performance improvements, but hard to tell for sure with all the noise. (compilebench times are unchanged.) name old time/op new time/op delta BinaryTree17-12 2.91s ±15% 2.80s ±12% ~ (p=0.063 n=10+10) Fannkuch11-12 3.47s ± 0% 3.30s ± 4% -4.91% (p=0.000 n=9+10) FmtFprintfEmpty-12 48.0ns ± 1% 47.4ns ± 1% -1.32% (p=0.002 n=9+9) FmtFprintfString-12 85.6ns ±11% 79.4ns ± 3% -7.27% (p=0.005 n=10+10) FmtFprintfInt-12 91.8ns ±10% 85.9ns ± 4% ~ (p=0.203 n=10+9) FmtFprintfIntInt-12 135ns ±13% 127ns ± 1% -5.72% (p=0.025 n=10+9) FmtFprintfPrefixedInt-12 167ns ± 1% 168ns ± 2% ~ (p=0.580 n=9+10) FmtFprintfFloat-12 249ns ±11% 230ns ± 1% -7.32% (p=0.000 n=10+10) FmtManyArgs-12 504ns ± 7% 506ns ± 1% ~ (p=0.198 n=9+9) GobDecode-12 6.95ms ± 1% 7.04ms ± 1% +1.37% (p=0.001 n=10+10) GobEncode-12 6.32ms ±13% 6.04ms ± 1% ~ (p=0.063 n=10+10) Gzip-12 233ms ± 1% 235ms ± 0% +1.01% (p=0.000 n=10+9) Gunzip-12 40.1ms ± 1% 39.6ms ± 0% -1.12% (p=0.000 n=10+8) HTTPClientServer-12 227µs ± 9% 221µs ± 5% ~ (p=0.114 n=9+8) JSONEncode-12 16.1ms ± 2% 15.8ms ± 1% -2.09% (p=0.002 n=9+8) JSONDecode-12 61.8ms ±11% 57.9ms ± 1% -6.30% (p=0.000 n=10+9) Mandelbrot200-12 4.30ms ± 3% 4.28ms ± 1% ~ (p=0.203 n=10+8) GoParse-12 3.18ms ± 2% 3.18ms ± 2% ~ (p=0.579 n=10+10) RegexpMatchEasy0_32-12 76.7ns ± 1% 77.5ns ± 1% +0.92% (p=0.002 n=9+8) RegexpMatchEasy0_1K-12 239ns ± 3% 239ns ± 1% ~ (p=0.204 n=10+10) RegexpMatchEasy1_32-12 71.4ns ± 1% 70.6ns ± 0% -1.15% (p=0.000 n=10+9) RegexpMatchEasy1_1K-12 383ns ± 2% 390ns ±10% ~ (p=0.181 n=8+9) RegexpMatchMedium_32-12 114ns ± 0% 113ns ± 1% -0.88% (p=0.000 n=9+8) RegexpMatchMedium_1K-12 36.3µs ± 1% 36.8µs ± 1% +1.59% (p=0.000 n=10+8) RegexpMatchHard_32-12 1.90µs ± 1% 1.90µs ± 1% ~ (p=0.341 n=10+10) RegexpMatchHard_1K-12 59.4µs ±11% 57.8µs ± 1% ~ (p=0.968 n=10+9) Revcomp-12 461ms ± 1% 462ms ± 1% ~ (p=1.000 n=9+9) Template-12 67.5ms ± 1% 66.3ms ± 1% -1.77% (p=0.000 n=10+8) TimeParse-12 314ns ± 3% 309ns ± 0% -1.56% (p=0.000 n=9+8) TimeFormat-12 340ns ± 2% 331ns ± 1% -2.79% (p=0.000 n=10+10) The go binary is 0.2% larger. Not really sure why the size would change. Change-Id: Ia5116e53a3aeb025ef350ffc51c14ae5cc17871c Reviewed-on: https://go-review.googlesource.com/34822 Reviewed-by: David Chase <drchase@google.com>
2017-03-07 14:45:46 -05:00
desired.add(x.v.ID, x.r)
}
// Process phi ops in succ.
pidx := e.i
for _, v := range succ.Values {
if v.Op != OpPhi {
cmd/compile: reimplement location list generation Completely redesign and reimplement location list generation to be more efficient, and hopefully not too hard to understand. RegKills are gone. Instead of using the regalloc's liveness calculations, redo them using the Ops' clobber information. Besides saving a lot of Values, this avoids adding RegKills to blocks that would be empty otherwise, which was messing up optimizations. This does mean that it's much harder to tell whether the generation process is buggy (there's nothing to cross-check it with), and there may be disagreements with GC liveness. But the performance gain is significant, and it's nice not to be messing with earlier compiler phases. The intermediate representations are gone. Instead of producing ssa.BlockDebugs, then dwarf.LocationLists, and then finally real location lists, go directly from the SSA to a (mostly) real location list. Because the SSA analysis happens before assembly, it stores encoded block/value IDs where PCs would normally go. It would be easier to do the SSA analysis after assembly, but I didn't want to retain the SSA just for that. Generation proceeds in two phases: first, it traverses the function in CFG order, storing the state of the block at the beginning and end. End states are used to produce the start states of the successor blocks. In the second phase, it traverses in program text order and produces the location lists. The processing in the second phase is redundant, but much cheaper than storing the intermediate representation. It might be possible to combine the two phases somewhat to take advantage of cases where the CFG matches the block layout, but I haven't tried. Location lists are finalized by adding a base address selection entry, translating each encoded block/value ID to a real PC, and adding the terminating zero entry. This probably won't work on OSX, where dsymutil will choke on the base address selection. I tried emitting CU-relative relocations for each address, and it was *very* bad for performance -- it uses more memory storing all the relocations than it does for the actual location list bytes. I think I'm going to end up synthesizing the relocations in the linker only on OSX, but TBD. TestNexting needs updating: with more optimizations working, the debugger doesn't stop on the continue (line 88) any more, and the test's duplicate suppression kicks in. Also, dx and dy live a little longer now, but they have the correct values. Change-Id: Ie772dfe23a4e389ca573624fac4d05401ae32307 Reviewed-on: https://go-review.googlesource.com/89356 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2017-10-26 15:40:17 -04:00
break
}
if !s.values[v.ID].needReg {
continue
}
rp, ok := s.f.getHome(v.ID).(*Register)
if !ok {
cmd/compile: optimize regalloc for phi value When allocating registers for phi value, only the primary predecessor is considered. Taking into account the allocation status of other predecessors can help reduce unnecessary copy or spill operations. Many such cases can be found in the standard library, such as runtime.wirep, moveByType, etc. The test results from benchstat also show that this change helps reduce the file size. name old time/op new time/op delta Template 328ms ± 5% 326ms ± 4% ~ (p=0.254 n=50+47) Unicode 156ms ± 7% 158ms ±10% ~ (p=0.412 n=49+49) GoTypes 1.07s ± 3% 1.07s ± 2% ~ (p=0.664 n=48+49) Compiler 4.43s ± 3% 4.44s ± 3% ~ (p=0.758 n=48+50) SSA 10.3s ± 2% 10.4s ± 2% +0.43% (p=0.017 n=50+46) Flate 208ms ± 9% 209ms ± 7% ~ (p=0.920 n=49+46) GoParser 260ms ± 5% 262ms ± 4% ~ (p=0.063 n=50+48) Reflect 687ms ± 3% 685ms ± 2% ~ (p=0.459 n=50+48) Tar 293ms ± 4% 293ms ± 5% ~ (p=0.695 n=49+48) XML 391ms ± 4% 389ms ± 3% ~ (p=0.109 n=49+46) LinkCompiler 570ms ± 5% 563ms ± 5% -1.10% (p=0.006 n=46+47) ExternalLinkCompiler 1.57s ± 3% 1.56s ± 3% ~ (p=0.118 n=47+46) LinkWithoutDebugCompiler 349ms ± 6% 349ms ± 5% ~ (p=0.726 n=49+47) [Geo mean] 645ms 645ms -0.05% name old user-time/op new user-time/op delta Template 507ms ±14% 513ms ±14% ~ (p=0.398 n=48+49) Unicode 345ms ±29% 345ms ±38% ~ (p=0.521 n=47+49) GoTypes 1.95s ±16% 1.94s ±19% ~ (p=0.324 n=50+50) Compiler 8.26s ±16% 8.22s ±14% ~ (p=0.834 n=50+50) SSA 19.6s ± 8% 19.2s ±15% ~ (p=0.056 n=50+50) Flate 293ms ± 9% 299ms ±12% ~ (p=0.057 n=47+50) GoParser 388ms ± 9% 387ms ±14% ~ (p=0.660 n=46+50) Reflect 1.15s ±28% 1.12s ±18% ~ (p=0.648 n=49+48) Tar 456ms ±10% 476ms ±15% +4.48% (p=0.001 n=46+48) XML 648ms ±27% 634ms ±16% ~ (p=0.685 n=50+46) LinkCompiler 1.00s ± 8% 1.00s ± 8% ~ (p=0.638 n=50+50) ExternalLinkCompiler 1.96s ± 5% 1.96s ± 5% ~ (p=0.792 n=50+50) LinkWithoutDebugCompiler 443ms ±10% 442ms ±11% ~ (p=0.813 n=50+50) [Geo mean] 1.05s 1.05s -0.09% name old alloc/op new alloc/op delta Template 36.0MB ± 0% 36.0MB ± 0% ~ (p=0.599 n=49+50) Unicode 29.8MB ± 0% 29.8MB ± 0% ~ (p=0.739 n=50+50) GoTypes 118MB ± 0% 118MB ± 0% ~ (p=0.436 n=50+50) Compiler 562MB ± 0% 562MB ± 0% ~ (p=0.693 n=50+50) SSA 1.42GB ± 0% 1.42GB ± 0% -0.10% (p=0.000 n=50+49) Flate 22.5MB ± 0% 22.5MB ± 0% ~ (p=0.429 n=48+49) GoParser 27.7MB ± 0% 27.7MB ± 0% ~ (p=0.705 n=49+48) Reflect 77.7MB ± 0% 77.7MB ± 0% -0.01% (p=0.043 n=50+50) Tar 33.8MB ± 0% 33.8MB ± 0% ~ (p=0.241 n=49+50) XML 42.8MB ± 0% 42.8MB ± 0% ~ (p=0.677 n=47+49) LinkCompiler 98.3MB ± 0% 98.3MB ± 0% ~ (p=0.157 n=50+50) ExternalLinkCompiler 89.4MB ± 0% 89.4MB ± 0% ~ (p=0.683 n=50+50) LinkWithoutDebugCompiler 56.7MB ± 0% 56.7MB ± 0% ~ (p=0.155 n=49+49) [Geo mean] 77.3MB 77.3MB -0.01% name old allocs/op new allocs/op delta Template 367k ± 0% 367k ± 0% ~ (p=0.863 n=50+50) Unicode 345k ± 0% 345k ± 0% ~ (p=0.744 n=49+49) GoTypes 1.28M ± 0% 1.28M ± 0% ~ (p=0.957 n=48+50) Compiler 5.39M ± 0% 5.39M ± 0% +0.00% (p=0.012 n=50+49) SSA 13.9M ± 0% 13.9M ± 0% +0.02% (p=0.000 n=47+49) Flate 230k ± 0% 230k ± 0% -0.01% (p=0.007 n=47+49) GoParser 292k ± 0% 292k ± 0% ~ (p=0.891 n=50+49) Reflect 977k ± 0% 977k ± 0% ~ (p=0.274 n=50+50) Tar 343k ± 0% 343k ± 0% ~ (p=0.942 n=50+50) XML 418k ± 0% 418k ± 0% ~ (p=0.374 n=50+49) LinkCompiler 516k ± 0% 516k ± 0% ~ (p=0.205 n=49+47) ExternalLinkCompiler 570k ± 0% 570k ± 0% ~ (p=0.783 n=49+47) LinkWithoutDebugCompiler 169k ± 0% 169k ± 0% ~ (p=0.233 n=50+46) [Geo mean] 672k 672k +0.00% name old maxRSS/op new maxRSS/op delta Template 34.5M ± 3% 34.4M ± 3% ~ (p=0.566 n=49+48) Unicode 36.0M ± 6% 35.9M ± 6% ~ (p=0.736 n=50+50) GoTypes 75.7M ± 7% 75.4M ± 5% ~ (p=0.412 n=50+50) Compiler 314M ±10% 313M ± 8% ~ (p=0.708 n=50+50) SSA 730M ± 6% 735M ± 6% ~ (p=0.324 n=50+50) Flate 25.8M ± 5% 25.6M ± 6% ~ (p=0.415 n=49+50) GoParser 28.5M ± 3% 28.5M ± 4% ~ (p=0.977 n=46+50) Reflect 57.4M ± 4% 57.2M ± 3% ~ (p=0.173 n=50+50) Tar 33.3M ± 3% 33.2M ± 4% ~ (p=0.621 n=48+50) XML 39.6M ± 5% 39.6M ± 4% ~ (p=0.997 n=50+50) LinkCompiler 168M ± 2% 167M ± 1% ~ (p=0.072 n=49+45) ExternalLinkCompiler 179M ± 1% 179M ± 1% ~ (p=0.147 n=48+50) LinkWithoutDebugCompiler 136M ± 1% 136M ± 1% ~ (p=0.789 n=47+49) [Geo mean] 79.2M 79.1M -0.12% name old text-bytes new text-bytes delta HelloSize 812kB ± 0% 811kB ± 0% -0.06% (p=0.000 n=50+50) name old data-bytes new data-bytes delta HelloSize 13.3kB ± 0% 13.3kB ± 0% ~ (all equal) name old bss-bytes new bss-bytes delta HelloSize 206kB ± 0% 206kB ± 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 1.21MB ± 0% 1.21MB ± 0% -0.03% (p=0.000 n=50+50) file before after Δ % addr2line 4057421 4056237 -1184 -0.029% api 4952451 4946715 -5736 -0.116% asm 4888993 4888185 -808 -0.017% buildid 2617705 2616441 -1264 -0.048% cgo 4521849 4520681 -1168 -0.026% compile 19143451 19141243 -2208 -0.012% cover 4847391 4837151 -10240 -0.211% dist 3473877 3472565 -1312 -0.038% doc 3821496 3820432 -1064 -0.028% fix 3220587 3220659 +72 +0.002% link 6587504 6582576 -4928 -0.075% nm 4000154 3998690 -1464 -0.037% objdump 4409449 4407625 -1824 -0.041% pack 2398086 2393110 -4976 -0.207% pprof 13599060 13606111 +7051 +0.052% test2json 2645148 2645692 +544 +0.021% trace 10355281 10355862 +581 +0.006% vet 6780026 6779666 -360 -0.005% total 106319929 106289641 -30288 -0.028% Change-Id: Ia5399286958c187c8664c769bbddf7bc4c1cae99 Reviewed-on: https://go-review.googlesource.com/c/go/+/263600 Run-TryBot: eric fang <eric.fang@arm.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: eric fang <eric.fang@arm.com> Reviewed-by: Keith Randall <khr@golang.org>
2020-10-19 11:20:24 +08:00
// If v is not assigned a register, pick a register assigned to one of v's inputs.
// Hopefully v will get assigned that register later.
// If the inputs have allocated register information, add it to desired,
// which may reduce spill or copy operations when the register is available.
for _, a := range v.Args {
rp, ok = s.f.getHome(a.ID).(*Register)
if ok {
break
}
}
if !ok {
continue
}
}
desired.add(v.Args[pidx].ID, register(rp.num))
}
}
// Walk values backwards computing desired register info.
// See computeLive for more comments.
for i := len(oldSched) - 1; i >= 0; i-- {
v := oldSched[i]
prefs := desired.remove(v.ID)
regspec := s.regspec(v)
desired.clobber(regspec.clobbers)
for _, j := range regspec.inputs {
if countRegs(j.regs) != 1 {
continue
}
desired.clobber(j.regs)
desired.add(v.Args[j.idx].ID, pickReg(j.regs))
}
if opcodeTable[v.Op].resultInArg0 || v.Op == OpAMD64ADDQconst || v.Op == OpAMD64ADDLconst || v.Op == OpSelect0 {
if opcodeTable[v.Op].commutative {
desired.addList(v.Args[1].ID, prefs)
}
desired.addList(v.Args[0].ID, prefs)
}
// Save desired registers for this value.
dinfo[i].out = prefs
for j, a := range v.Args {
if j >= len(dinfo[i].in) {
break
}
dinfo[i].in[j] = desired.get(a.ID)
}
if v.Op == OpSelect1 && prefs[0] != noRegister {
// Save desired registers of select1 for
// use by the tuple generating instruction.
desiredSecondReg[v.Args[0].ID] = prefs
}
}
// Process all the non-phi values.
for idx, v := range oldSched {
s.curIdx = nphi + idx
tmpReg := noRegister
if s.f.pass.debug > regDebug {
fmt.Printf(" processing %s\n", v.LongString())
}
regspec := s.regspec(v)
if v.Op == OpPhi {
f.Fatalf("phi %s not at start of block", v)
}
if opcodeTable[v.Op].fixedReg {
switch v.Op {
case OpSP:
s.assignReg(s.SPReg, v, v)
s.sp = v.ID
case OpSB:
s.assignReg(s.SBReg, v, v)
s.sb = v.ID
case OpARM64ZERO:
s.assignReg(s.ZeroIntReg, v, v)
default:
f.Fatalf("unknown fixed-register op %s", v)
}
b.Values = append(b.Values, v)
s.advanceUses(v)
continue
}
if v.Op == OpSelect0 || v.Op == OpSelect1 || v.Op == OpSelectN {
if s.values[v.ID].needReg {
if v.Op == OpSelectN {
s.assignReg(register(s.f.getHome(v.Args[0].ID).(LocResults)[int(v.AuxInt)].(*Register).num), v, v)
} else {
var i = 0
if v.Op == OpSelect1 {
i = 1
}
s.assignReg(register(s.f.getHome(v.Args[0].ID).(LocPair)[i].(*Register).num), v, v)
}
}
b.Values = append(b.Values, v)
s.advanceUses(v)
continue
}
if v.Op == OpGetG && s.f.Config.hasGReg {
// use hardware g register
if s.regs[s.GReg].v != nil {
s.freeReg(s.GReg) // kick out the old value
}
s.assignReg(s.GReg, v, v)
b.Values = append(b.Values, v)
s.advanceUses(v)
continue
}
if v.Op == OpArg {
// Args are "pre-spilled" values. We don't allocate
// any register here. We just set up the spill pointer to
// point at itself and any later user will restore it to use it.
s.values[v.ID].spill = v
b.Values = append(b.Values, v)
s.advanceUses(v)
continue
}
if v.Op == OpKeepAlive {
// Make sure the argument to v is still live here.
s.advanceUses(v)
a := v.Args[0]
vi := &s.values[a.ID]
if vi.regs == 0 && !vi.rematerializeable {
// Use the spill location.
// This forces later liveness analysis to make the
// value live at this point.
v.SetArg(0, s.makeSpill(a, b))
} else if _, ok := a.Aux.(*ir.Name); ok && vi.rematerializeable {
// Rematerializeable value with a *ir.Name. This is the address of
// a stack object (e.g. an LEAQ). Keep the object live.
// Change it to VarLive, which is what plive expects for locals.
v.Op = OpVarLive
v.SetArgs1(v.Args[1])
v.Aux = a.Aux
} else {
// In-register and rematerializeable values are already live.
// These are typically rematerializeable constants like nil,
// or values of a variable that were modified since the last call.
v.Op = OpCopy
v.SetArgs1(v.Args[1])
}
b.Values = append(b.Values, v)
continue
}
if len(regspec.inputs) == 0 && len(regspec.outputs) == 0 {
// No register allocation required (or none specified yet)
if s.doClobber && v.Op.IsCall() {
s.clobberRegs(regspec.clobbers)
}
s.freeRegs(regspec.clobbers)
b.Values = append(b.Values, v)
s.advanceUses(v)
continue
}
if s.values[v.ID].rematerializeable {
// Value is rematerializeable, don't issue it here.
// It will get issued just before each use (see
// allocValueToReg).
for _, a := range v.Args {
a.Uses--
}
s.advanceUses(v)
continue
}
if s.f.pass.debug > regDebug {
fmt.Printf("value %s\n", v.LongString())
fmt.Printf(" out:")
for _, r := range dinfo[idx].out {
if r != noRegister {
fmt.Printf(" %s", &s.registers[r])
}
}
fmt.Println()
for i := 0; i < len(v.Args) && i < 3; i++ {
fmt.Printf(" in%d:", i)
for _, r := range dinfo[idx].in[i] {
if r != noRegister {
fmt.Printf(" %s", &s.registers[r])
}
}
fmt.Println()
}
}
// Move arguments to registers.
// First, if an arg must be in a specific register and it is already
// in place, keep it.
args = append(args[:0], make([]*Value, len(v.Args))...)
for i, a := range v.Args {
if !s.values[a.ID].needReg {
args[i] = a
}
}
for _, i := range regspec.inputs {
mask := i.regs
if countRegs(mask) == 1 && mask&s.values[v.Args[i.idx].ID].regs != 0 {
args[i.idx] = s.allocValToReg(v.Args[i.idx], mask, true, v.Pos)
}
}
// Then, if an arg must be in a specific register and that
// register is free, allocate that one. Otherwise when processing
// another input we may kick a value into the free register, which
// then will be kicked out again.
// This is a common case for passing-in-register arguments for
// function calls.
for {
freed := false
for _, i := range regspec.inputs {
if args[i.idx] != nil {
continue // already allocated
}
mask := i.regs
if countRegs(mask) == 1 && mask&^s.used != 0 {
args[i.idx] = s.allocValToReg(v.Args[i.idx], mask, true, v.Pos)
// If the input is in other registers that will be clobbered by v,
// or the input is dead, free the registers. This may make room
// for other inputs.
oldregs := s.values[v.Args[i.idx].ID].regs
if oldregs&^regspec.clobbers == 0 || !s.liveAfterCurrentInstruction(v.Args[i.idx]) {
s.freeRegs(oldregs &^ mask &^ s.nospill)
freed = true
}
}
}
if !freed {
break
}
}
// Last, allocate remaining ones, in an ordering defined
// by the register specification (most constrained first).
for _, i := range regspec.inputs {
if args[i.idx] != nil {
continue // already allocated
}
mask := i.regs
if mask&s.values[v.Args[i.idx].ID].regs == 0 {
// Need a new register for the input.
mask &= s.allocatable
mask &^= s.nospill
// Used desired register if available.
if i.idx < 3 {
for _, r := range dinfo[idx].in[i.idx] {
if r != noRegister && (mask&^s.used)>>r&1 != 0 {
// Desired register is allowed and unused.
mask = regMask(1) << r
break
}
}
}
// Avoid registers we're saving for other values.
if mask&^desired.avoid != 0 {
mask &^= desired.avoid
}
}
if mask&s.values[v.Args[i.idx].ID].regs&(1<<s.SPReg) != 0 {
// Prefer SP register. This ensures that local variables
// use SP as their base register (instead of a copy of the
// stack pointer living in another register). See issue 74836.
mask = 1 << s.SPReg
}
args[i.idx] = s.allocValToReg(v.Args[i.idx], mask, true, v.Pos)
}
// If the output clobbers the input register, make sure we have
// at least two copies of the input register so we don't
// have to reload the value from the spill location.
if opcodeTable[v.Op].resultInArg0 {
var m regMask
if !s.liveAfterCurrentInstruction(v.Args[0]) {
// arg0 is dead. We can clobber its register.
goto ok
}
if opcodeTable[v.Op].commutative && !s.liveAfterCurrentInstruction(v.Args[1]) {
args[0], args[1] = args[1], args[0]
goto ok
}
if s.values[v.Args[0].ID].rematerializeable {
// We can rematerialize the input, don't worry about clobbering it.
goto ok
}
if opcodeTable[v.Op].commutative && s.values[v.Args[1].ID].rematerializeable {
args[0], args[1] = args[1], args[0]
goto ok
}
if countRegs(s.values[v.Args[0].ID].regs) >= 2 {
// we have at least 2 copies of arg0. We can afford to clobber one.
goto ok
}
if opcodeTable[v.Op].commutative && countRegs(s.values[v.Args[1].ID].regs) >= 2 {
args[0], args[1] = args[1], args[0]
goto ok
}
// We can't overwrite arg0 (or arg1, if commutative). So we
// need to make a copy of an input so we have a register we can modify.
// Possible new registers to copy into.
m = s.compatRegs(v.Args[0].Type) &^ s.used
if m == 0 {
// No free registers. In this case we'll just clobber
// an input and future uses of that input must use a restore.
// TODO(khr): We should really do this like allocReg does it,
// spilling the value with the most distant next use.
goto ok
}
// Try to move an input to the desired output, if allowed.
for _, r := range dinfo[idx].out {
if r != noRegister && (m&regspec.outputs[0].regs)>>r&1 != 0 {
m = regMask(1) << r
args[0] = s.allocValToReg(v.Args[0], m, true, v.Pos)
// Note: we update args[0] so the instruction will
// use the register copy we just made.
goto ok
}
}
// Try to copy input to its desired location & use its old
// location as the result register.
for _, r := range dinfo[idx].in[0] {
if r != noRegister && m>>r&1 != 0 {
m = regMask(1) << r
c := s.allocValToReg(v.Args[0], m, true, v.Pos)
cmd/compile: move value around before kick it out of register When allocating registers, before kicking out the existing value, copy it to a spare register if there is one. So later use of this value can be found in register instead of reload from spill. This is very helpful for instructions of which the input and/or output can only be in specific registers, e.g. DIV on x86, MUL/DIV on MIPS. May also be helpful in general. For "go build -a cmd/go" on AMD64, reduce "spilled value remains" by 1% (not including args, which almost certainly remain). For the code in issue #16061 on AMD64: MaxRem-12 111µs ± 1% 94µs ± 0% -15.38% (p=0.008 n=5+5) Go1 benchmark on AMD64: BinaryTree17-12 2.32s ± 2% 2.30s ± 1% ~ (p=0.421 n=5+5) Fannkuch11-12 2.52s ± 0% 2.44s ± 0% -3.44% (p=0.008 n=5+5) FmtFprintfEmpty-12 39.9ns ± 3% 39.8ns ± 0% ~ (p=0.635 n=5+4) FmtFprintfString-12 114ns ± 1% 113ns ± 1% ~ (p=0.905 n=5+5) FmtFprintfInt-12 102ns ± 6% 98ns ± 1% ~ (p=0.087 n=5+5) FmtFprintfIntInt-12 146ns ± 5% 147ns ± 1% ~ (p=0.238 n=5+5) FmtFprintfPrefixedInt-12 155ns ± 2% 151ns ± 1% -2.58% (p=0.008 n=5+5) FmtFprintfFloat-12 231ns ± 1% 232ns ± 1% ~ (p=0.286 n=5+5) FmtManyArgs-12 657ns ± 1% 649ns ± 0% -1.31% (p=0.008 n=5+5) GobDecode-12 6.35ms ± 0% 6.29ms ± 1% ~ (p=0.056 n=5+5) GobEncode-12 5.38ms ± 1% 5.45ms ± 1% ~ (p=0.056 n=5+5) Gzip-12 209ms ± 0% 209ms ± 1% ~ (p=0.690 n=5+5) Gunzip-12 31.2ms ± 1% 31.1ms ± 1% ~ (p=0.548 n=5+5) HTTPClientServer-12 123µs ± 4% 130µs ± 8% ~ (p=0.151 n=5+5) JSONEncode-12 14.0ms ± 1% 14.0ms ± 1% ~ (p=0.421 n=5+5) JSONDecode-12 41.2ms ± 1% 41.1ms ± 2% ~ (p=0.421 n=5+5) Mandelbrot200-12 3.96ms ± 1% 3.98ms ± 0% ~ (p=0.421 n=5+5) GoParse-12 2.88ms ± 1% 2.88ms ± 1% ~ (p=0.841 n=5+5) RegexpMatchEasy0_32-12 68.0ns ± 3% 66.6ns ± 1% -2.00% (p=0.024 n=5+5) RegexpMatchEasy0_1K-12 728ns ± 8% 682ns ± 1% -6.26% (p=0.008 n=5+5) RegexpMatchEasy1_32-12 66.8ns ± 2% 66.0ns ± 1% ~ (p=0.302 n=5+5) RegexpMatchEasy1_1K-12 291ns ± 2% 288ns ± 1% ~ (p=0.111 n=5+5) RegexpMatchMedium_32-12 103ns ± 2% 100ns ± 0% -2.53% (p=0.016 n=5+4) RegexpMatchMedium_1K-12 31.9µs ± 1% 31.3µs ± 0% -1.75% (p=0.008 n=5+5) RegexpMatchHard_32-12 1.59µs ± 2% 1.59µs ± 1% ~ (p=0.548 n=5+5) RegexpMatchHard_1K-12 48.3µs ± 2% 47.7µs ± 1% ~ (p=0.222 n=5+5) Revcomp-12 340ms ± 1% 338ms ± 1% ~ (p=0.421 n=5+5) Template-12 46.3ms ± 1% 46.5ms ± 1% ~ (p=0.690 n=5+5) TimeParse-12 252ns ± 1% 247ns ± 0% -1.91% (p=0.000 n=5+4) TimeFormat-12 277ns ± 1% 267ns ± 0% -3.82% (p=0.008 n=5+5) [Geo mean] 48.8µs 48.3µs -0.93% It has very little effect on binary size and compiler speed. compilebench: Template 230ms ±10% 231ms ± 8% ~ (p=0.546 n=9+9) Unicode 123ms ± 6% 124ms ± 9% ~ (p=0.481 n=10+10) GoTypes 742ms ± 6% 755ms ± 3% ~ (p=0.123 n=10+10) Compiler 3.10s ± 3% 3.08s ± 1% ~ (p=0.631 n=10+10) Fixes #16061. Change-Id: Id99cdc7a182ee10a704fa0f04e8e0d0809b2ac56 Reviewed-on: https://go-review.googlesource.com/29732 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2016-09-23 09:15:51 -04:00
s.copies[c] = false
// Note: no update to args[0] so the instruction will
// use the original copy.
goto ok
}
}
if opcodeTable[v.Op].commutative {
for _, r := range dinfo[idx].in[1] {
if r != noRegister && m>>r&1 != 0 {
m = regMask(1) << r
c := s.allocValToReg(v.Args[1], m, true, v.Pos)
cmd/compile: move value around before kick it out of register When allocating registers, before kicking out the existing value, copy it to a spare register if there is one. So later use of this value can be found in register instead of reload from spill. This is very helpful for instructions of which the input and/or output can only be in specific registers, e.g. DIV on x86, MUL/DIV on MIPS. May also be helpful in general. For "go build -a cmd/go" on AMD64, reduce "spilled value remains" by 1% (not including args, which almost certainly remain). For the code in issue #16061 on AMD64: MaxRem-12 111µs ± 1% 94µs ± 0% -15.38% (p=0.008 n=5+5) Go1 benchmark on AMD64: BinaryTree17-12 2.32s ± 2% 2.30s ± 1% ~ (p=0.421 n=5+5) Fannkuch11-12 2.52s ± 0% 2.44s ± 0% -3.44% (p=0.008 n=5+5) FmtFprintfEmpty-12 39.9ns ± 3% 39.8ns ± 0% ~ (p=0.635 n=5+4) FmtFprintfString-12 114ns ± 1% 113ns ± 1% ~ (p=0.905 n=5+5) FmtFprintfInt-12 102ns ± 6% 98ns ± 1% ~ (p=0.087 n=5+5) FmtFprintfIntInt-12 146ns ± 5% 147ns ± 1% ~ (p=0.238 n=5+5) FmtFprintfPrefixedInt-12 155ns ± 2% 151ns ± 1% -2.58% (p=0.008 n=5+5) FmtFprintfFloat-12 231ns ± 1% 232ns ± 1% ~ (p=0.286 n=5+5) FmtManyArgs-12 657ns ± 1% 649ns ± 0% -1.31% (p=0.008 n=5+5) GobDecode-12 6.35ms ± 0% 6.29ms ± 1% ~ (p=0.056 n=5+5) GobEncode-12 5.38ms ± 1% 5.45ms ± 1% ~ (p=0.056 n=5+5) Gzip-12 209ms ± 0% 209ms ± 1% ~ (p=0.690 n=5+5) Gunzip-12 31.2ms ± 1% 31.1ms ± 1% ~ (p=0.548 n=5+5) HTTPClientServer-12 123µs ± 4% 130µs ± 8% ~ (p=0.151 n=5+5) JSONEncode-12 14.0ms ± 1% 14.0ms ± 1% ~ (p=0.421 n=5+5) JSONDecode-12 41.2ms ± 1% 41.1ms ± 2% ~ (p=0.421 n=5+5) Mandelbrot200-12 3.96ms ± 1% 3.98ms ± 0% ~ (p=0.421 n=5+5) GoParse-12 2.88ms ± 1% 2.88ms ± 1% ~ (p=0.841 n=5+5) RegexpMatchEasy0_32-12 68.0ns ± 3% 66.6ns ± 1% -2.00% (p=0.024 n=5+5) RegexpMatchEasy0_1K-12 728ns ± 8% 682ns ± 1% -6.26% (p=0.008 n=5+5) RegexpMatchEasy1_32-12 66.8ns ± 2% 66.0ns ± 1% ~ (p=0.302 n=5+5) RegexpMatchEasy1_1K-12 291ns ± 2% 288ns ± 1% ~ (p=0.111 n=5+5) RegexpMatchMedium_32-12 103ns ± 2% 100ns ± 0% -2.53% (p=0.016 n=5+4) RegexpMatchMedium_1K-12 31.9µs ± 1% 31.3µs ± 0% -1.75% (p=0.008 n=5+5) RegexpMatchHard_32-12 1.59µs ± 2% 1.59µs ± 1% ~ (p=0.548 n=5+5) RegexpMatchHard_1K-12 48.3µs ± 2% 47.7µs ± 1% ~ (p=0.222 n=5+5) Revcomp-12 340ms ± 1% 338ms ± 1% ~ (p=0.421 n=5+5) Template-12 46.3ms ± 1% 46.5ms ± 1% ~ (p=0.690 n=5+5) TimeParse-12 252ns ± 1% 247ns ± 0% -1.91% (p=0.000 n=5+4) TimeFormat-12 277ns ± 1% 267ns ± 0% -3.82% (p=0.008 n=5+5) [Geo mean] 48.8µs 48.3µs -0.93% It has very little effect on binary size and compiler speed. compilebench: Template 230ms ±10% 231ms ± 8% ~ (p=0.546 n=9+9) Unicode 123ms ± 6% 124ms ± 9% ~ (p=0.481 n=10+10) GoTypes 742ms ± 6% 755ms ± 3% ~ (p=0.123 n=10+10) Compiler 3.10s ± 3% 3.08s ± 1% ~ (p=0.631 n=10+10) Fixes #16061. Change-Id: Id99cdc7a182ee10a704fa0f04e8e0d0809b2ac56 Reviewed-on: https://go-review.googlesource.com/29732 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2016-09-23 09:15:51 -04:00
s.copies[c] = false
args[0], args[1] = args[1], args[0]
goto ok
}
}
}
// Avoid future fixed uses if we can.
if m&^desired.avoid != 0 {
m &^= desired.avoid
}
// Save input 0 to a new register so we can clobber it.
c := s.allocValToReg(v.Args[0], m, true, v.Pos)
cmd/compile: move value around before kick it out of register When allocating registers, before kicking out the existing value, copy it to a spare register if there is one. So later use of this value can be found in register instead of reload from spill. This is very helpful for instructions of which the input and/or output can only be in specific registers, e.g. DIV on x86, MUL/DIV on MIPS. May also be helpful in general. For "go build -a cmd/go" on AMD64, reduce "spilled value remains" by 1% (not including args, which almost certainly remain). For the code in issue #16061 on AMD64: MaxRem-12 111µs ± 1% 94µs ± 0% -15.38% (p=0.008 n=5+5) Go1 benchmark on AMD64: BinaryTree17-12 2.32s ± 2% 2.30s ± 1% ~ (p=0.421 n=5+5) Fannkuch11-12 2.52s ± 0% 2.44s ± 0% -3.44% (p=0.008 n=5+5) FmtFprintfEmpty-12 39.9ns ± 3% 39.8ns ± 0% ~ (p=0.635 n=5+4) FmtFprintfString-12 114ns ± 1% 113ns ± 1% ~ (p=0.905 n=5+5) FmtFprintfInt-12 102ns ± 6% 98ns ± 1% ~ (p=0.087 n=5+5) FmtFprintfIntInt-12 146ns ± 5% 147ns ± 1% ~ (p=0.238 n=5+5) FmtFprintfPrefixedInt-12 155ns ± 2% 151ns ± 1% -2.58% (p=0.008 n=5+5) FmtFprintfFloat-12 231ns ± 1% 232ns ± 1% ~ (p=0.286 n=5+5) FmtManyArgs-12 657ns ± 1% 649ns ± 0% -1.31% (p=0.008 n=5+5) GobDecode-12 6.35ms ± 0% 6.29ms ± 1% ~ (p=0.056 n=5+5) GobEncode-12 5.38ms ± 1% 5.45ms ± 1% ~ (p=0.056 n=5+5) Gzip-12 209ms ± 0% 209ms ± 1% ~ (p=0.690 n=5+5) Gunzip-12 31.2ms ± 1% 31.1ms ± 1% ~ (p=0.548 n=5+5) HTTPClientServer-12 123µs ± 4% 130µs ± 8% ~ (p=0.151 n=5+5) JSONEncode-12 14.0ms ± 1% 14.0ms ± 1% ~ (p=0.421 n=5+5) JSONDecode-12 41.2ms ± 1% 41.1ms ± 2% ~ (p=0.421 n=5+5) Mandelbrot200-12 3.96ms ± 1% 3.98ms ± 0% ~ (p=0.421 n=5+5) GoParse-12 2.88ms ± 1% 2.88ms ± 1% ~ (p=0.841 n=5+5) RegexpMatchEasy0_32-12 68.0ns ± 3% 66.6ns ± 1% -2.00% (p=0.024 n=5+5) RegexpMatchEasy0_1K-12 728ns ± 8% 682ns ± 1% -6.26% (p=0.008 n=5+5) RegexpMatchEasy1_32-12 66.8ns ± 2% 66.0ns ± 1% ~ (p=0.302 n=5+5) RegexpMatchEasy1_1K-12 291ns ± 2% 288ns ± 1% ~ (p=0.111 n=5+5) RegexpMatchMedium_32-12 103ns ± 2% 100ns ± 0% -2.53% (p=0.016 n=5+4) RegexpMatchMedium_1K-12 31.9µs ± 1% 31.3µs ± 0% -1.75% (p=0.008 n=5+5) RegexpMatchHard_32-12 1.59µs ± 2% 1.59µs ± 1% ~ (p=0.548 n=5+5) RegexpMatchHard_1K-12 48.3µs ± 2% 47.7µs ± 1% ~ (p=0.222 n=5+5) Revcomp-12 340ms ± 1% 338ms ± 1% ~ (p=0.421 n=5+5) Template-12 46.3ms ± 1% 46.5ms ± 1% ~ (p=0.690 n=5+5) TimeParse-12 252ns ± 1% 247ns ± 0% -1.91% (p=0.000 n=5+4) TimeFormat-12 277ns ± 1% 267ns ± 0% -3.82% (p=0.008 n=5+5) [Geo mean] 48.8µs 48.3µs -0.93% It has very little effect on binary size and compiler speed. compilebench: Template 230ms ±10% 231ms ± 8% ~ (p=0.546 n=9+9) Unicode 123ms ± 6% 124ms ± 9% ~ (p=0.481 n=10+10) GoTypes 742ms ± 6% 755ms ± 3% ~ (p=0.123 n=10+10) Compiler 3.10s ± 3% 3.08s ± 1% ~ (p=0.631 n=10+10) Fixes #16061. Change-Id: Id99cdc7a182ee10a704fa0f04e8e0d0809b2ac56 Reviewed-on: https://go-review.googlesource.com/29732 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2016-09-23 09:15:51 -04:00
s.copies[c] = false
// Normally we use the register of the old copy of input 0 as the target.
// However, if input 0 is already in its desired register then we use
// the register of the new copy instead.
if regspec.outputs[0].regs>>s.f.getHome(c.ID).(*Register).num&1 != 0 {
if rp, ok := s.f.getHome(args[0].ID).(*Register); ok {
r := register(rp.num)
for _, r2 := range dinfo[idx].in[0] {
if r == r2 {
args[0] = c
break
}
}
}
}
}
cmd/compile: move value around before kick it out of register When allocating registers, before kicking out the existing value, copy it to a spare register if there is one. So later use of this value can be found in register instead of reload from spill. This is very helpful for instructions of which the input and/or output can only be in specific registers, e.g. DIV on x86, MUL/DIV on MIPS. May also be helpful in general. For "go build -a cmd/go" on AMD64, reduce "spilled value remains" by 1% (not including args, which almost certainly remain). For the code in issue #16061 on AMD64: MaxRem-12 111µs ± 1% 94µs ± 0% -15.38% (p=0.008 n=5+5) Go1 benchmark on AMD64: BinaryTree17-12 2.32s ± 2% 2.30s ± 1% ~ (p=0.421 n=5+5) Fannkuch11-12 2.52s ± 0% 2.44s ± 0% -3.44% (p=0.008 n=5+5) FmtFprintfEmpty-12 39.9ns ± 3% 39.8ns ± 0% ~ (p=0.635 n=5+4) FmtFprintfString-12 114ns ± 1% 113ns ± 1% ~ (p=0.905 n=5+5) FmtFprintfInt-12 102ns ± 6% 98ns ± 1% ~ (p=0.087 n=5+5) FmtFprintfIntInt-12 146ns ± 5% 147ns ± 1% ~ (p=0.238 n=5+5) FmtFprintfPrefixedInt-12 155ns ± 2% 151ns ± 1% -2.58% (p=0.008 n=5+5) FmtFprintfFloat-12 231ns ± 1% 232ns ± 1% ~ (p=0.286 n=5+5) FmtManyArgs-12 657ns ± 1% 649ns ± 0% -1.31% (p=0.008 n=5+5) GobDecode-12 6.35ms ± 0% 6.29ms ± 1% ~ (p=0.056 n=5+5) GobEncode-12 5.38ms ± 1% 5.45ms ± 1% ~ (p=0.056 n=5+5) Gzip-12 209ms ± 0% 209ms ± 1% ~ (p=0.690 n=5+5) Gunzip-12 31.2ms ± 1% 31.1ms ± 1% ~ (p=0.548 n=5+5) HTTPClientServer-12 123µs ± 4% 130µs ± 8% ~ (p=0.151 n=5+5) JSONEncode-12 14.0ms ± 1% 14.0ms ± 1% ~ (p=0.421 n=5+5) JSONDecode-12 41.2ms ± 1% 41.1ms ± 2% ~ (p=0.421 n=5+5) Mandelbrot200-12 3.96ms ± 1% 3.98ms ± 0% ~ (p=0.421 n=5+5) GoParse-12 2.88ms ± 1% 2.88ms ± 1% ~ (p=0.841 n=5+5) RegexpMatchEasy0_32-12 68.0ns ± 3% 66.6ns ± 1% -2.00% (p=0.024 n=5+5) RegexpMatchEasy0_1K-12 728ns ± 8% 682ns ± 1% -6.26% (p=0.008 n=5+5) RegexpMatchEasy1_32-12 66.8ns ± 2% 66.0ns ± 1% ~ (p=0.302 n=5+5) RegexpMatchEasy1_1K-12 291ns ± 2% 288ns ± 1% ~ (p=0.111 n=5+5) RegexpMatchMedium_32-12 103ns ± 2% 100ns ± 0% -2.53% (p=0.016 n=5+4) RegexpMatchMedium_1K-12 31.9µs ± 1% 31.3µs ± 0% -1.75% (p=0.008 n=5+5) RegexpMatchHard_32-12 1.59µs ± 2% 1.59µs ± 1% ~ (p=0.548 n=5+5) RegexpMatchHard_1K-12 48.3µs ± 2% 47.7µs ± 1% ~ (p=0.222 n=5+5) Revcomp-12 340ms ± 1% 338ms ± 1% ~ (p=0.421 n=5+5) Template-12 46.3ms ± 1% 46.5ms ± 1% ~ (p=0.690 n=5+5) TimeParse-12 252ns ± 1% 247ns ± 0% -1.91% (p=0.000 n=5+4) TimeFormat-12 277ns ± 1% 267ns ± 0% -3.82% (p=0.008 n=5+5) [Geo mean] 48.8µs 48.3µs -0.93% It has very little effect on binary size and compiler speed. compilebench: Template 230ms ±10% 231ms ± 8% ~ (p=0.546 n=9+9) Unicode 123ms ± 6% 124ms ± 9% ~ (p=0.481 n=10+10) GoTypes 742ms ± 6% 755ms ± 3% ~ (p=0.123 n=10+10) Compiler 3.10s ± 3% 3.08s ± 1% ~ (p=0.631 n=10+10) Fixes #16061. Change-Id: Id99cdc7a182ee10a704fa0f04e8e0d0809b2ac56 Reviewed-on: https://go-review.googlesource.com/29732 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2016-09-23 09:15:51 -04:00
ok:
for i := 0; i < 2; i++ {
if !(i == 0 && regspec.clobbersArg0 || i == 1 && regspec.clobbersArg1) {
continue
}
if !s.liveAfterCurrentInstruction(v.Args[i]) {
// arg is dead. We can clobber its register.
continue
}
if s.values[v.Args[i].ID].rematerializeable {
// We can rematerialize the input, don't worry about clobbering it.
continue
}
if countRegs(s.values[v.Args[i].ID].regs) >= 2 {
// We have at least 2 copies of arg. We can afford to clobber one.
continue
}
// Possible new registers to copy into.
m := s.compatRegs(v.Args[i].Type) &^ s.used
if m == 0 {
// No free registers. In this case we'll just clobber the
// input and future uses of that input must use a restore.
// TODO(khr): We should really do this like allocReg does it,
// spilling the value with the most distant next use.
continue
}
// Copy input to a new clobberable register.
c := s.allocValToReg(v.Args[i], m, true, v.Pos)
s.copies[c] = false
args[i] = c
}
// Pick a temporary register if needed.
// It should be distinct from all the input registers, so we
// allocate it after all the input registers, but before
// the input registers are freed via advanceUses below.
// (Not all instructions need that distinct part, but it is conservative.)
// We also ensure it is not any of the single-choice output registers.
if opcodeTable[v.Op].needIntTemp {
m := s.allocatable & s.f.Config.gpRegMask
for _, out := range regspec.outputs {
if countRegs(out.regs) == 1 {
m &^= out.regs
}
}
if m&^desired.avoid&^s.nospill != 0 {
m &^= desired.avoid
}
tmpReg = s.allocReg(m, &tmpVal)
s.nospill |= regMask(1) << tmpReg
s.tmpused |= regMask(1) << tmpReg
}
if regspec.clobbersArg0 {
s.freeReg(register(s.f.getHome(args[0].ID).(*Register).num))
}
if regspec.clobbersArg1 {
s.freeReg(register(s.f.getHome(args[1].ID).(*Register).num))
}
// Now that all args are in regs, we're ready to issue the value itself.
// Before we pick a register for the output value, allow input registers
// to be deallocated. We do this here so that the output can use the
// same register as a dying input.
if !opcodeTable[v.Op].resultNotInArgs {
cmd/compile: move value around before kick it out of register When allocating registers, before kicking out the existing value, copy it to a spare register if there is one. So later use of this value can be found in register instead of reload from spill. This is very helpful for instructions of which the input and/or output can only be in specific registers, e.g. DIV on x86, MUL/DIV on MIPS. May also be helpful in general. For "go build -a cmd/go" on AMD64, reduce "spilled value remains" by 1% (not including args, which almost certainly remain). For the code in issue #16061 on AMD64: MaxRem-12 111µs ± 1% 94µs ± 0% -15.38% (p=0.008 n=5+5) Go1 benchmark on AMD64: BinaryTree17-12 2.32s ± 2% 2.30s ± 1% ~ (p=0.421 n=5+5) Fannkuch11-12 2.52s ± 0% 2.44s ± 0% -3.44% (p=0.008 n=5+5) FmtFprintfEmpty-12 39.9ns ± 3% 39.8ns ± 0% ~ (p=0.635 n=5+4) FmtFprintfString-12 114ns ± 1% 113ns ± 1% ~ (p=0.905 n=5+5) FmtFprintfInt-12 102ns ± 6% 98ns ± 1% ~ (p=0.087 n=5+5) FmtFprintfIntInt-12 146ns ± 5% 147ns ± 1% ~ (p=0.238 n=5+5) FmtFprintfPrefixedInt-12 155ns ± 2% 151ns ± 1% -2.58% (p=0.008 n=5+5) FmtFprintfFloat-12 231ns ± 1% 232ns ± 1% ~ (p=0.286 n=5+5) FmtManyArgs-12 657ns ± 1% 649ns ± 0% -1.31% (p=0.008 n=5+5) GobDecode-12 6.35ms ± 0% 6.29ms ± 1% ~ (p=0.056 n=5+5) GobEncode-12 5.38ms ± 1% 5.45ms ± 1% ~ (p=0.056 n=5+5) Gzip-12 209ms ± 0% 209ms ± 1% ~ (p=0.690 n=5+5) Gunzip-12 31.2ms ± 1% 31.1ms ± 1% ~ (p=0.548 n=5+5) HTTPClientServer-12 123µs ± 4% 130µs ± 8% ~ (p=0.151 n=5+5) JSONEncode-12 14.0ms ± 1% 14.0ms ± 1% ~ (p=0.421 n=5+5) JSONDecode-12 41.2ms ± 1% 41.1ms ± 2% ~ (p=0.421 n=5+5) Mandelbrot200-12 3.96ms ± 1% 3.98ms ± 0% ~ (p=0.421 n=5+5) GoParse-12 2.88ms ± 1% 2.88ms ± 1% ~ (p=0.841 n=5+5) RegexpMatchEasy0_32-12 68.0ns ± 3% 66.6ns ± 1% -2.00% (p=0.024 n=5+5) RegexpMatchEasy0_1K-12 728ns ± 8% 682ns ± 1% -6.26% (p=0.008 n=5+5) RegexpMatchEasy1_32-12 66.8ns ± 2% 66.0ns ± 1% ~ (p=0.302 n=5+5) RegexpMatchEasy1_1K-12 291ns ± 2% 288ns ± 1% ~ (p=0.111 n=5+5) RegexpMatchMedium_32-12 103ns ± 2% 100ns ± 0% -2.53% (p=0.016 n=5+4) RegexpMatchMedium_1K-12 31.9µs ± 1% 31.3µs ± 0% -1.75% (p=0.008 n=5+5) RegexpMatchHard_32-12 1.59µs ± 2% 1.59µs ± 1% ~ (p=0.548 n=5+5) RegexpMatchHard_1K-12 48.3µs ± 2% 47.7µs ± 1% ~ (p=0.222 n=5+5) Revcomp-12 340ms ± 1% 338ms ± 1% ~ (p=0.421 n=5+5) Template-12 46.3ms ± 1% 46.5ms ± 1% ~ (p=0.690 n=5+5) TimeParse-12 252ns ± 1% 247ns ± 0% -1.91% (p=0.000 n=5+4) TimeFormat-12 277ns ± 1% 267ns ± 0% -3.82% (p=0.008 n=5+5) [Geo mean] 48.8µs 48.3µs -0.93% It has very little effect on binary size and compiler speed. compilebench: Template 230ms ±10% 231ms ± 8% ~ (p=0.546 n=9+9) Unicode 123ms ± 6% 124ms ± 9% ~ (p=0.481 n=10+10) GoTypes 742ms ± 6% 755ms ± 3% ~ (p=0.123 n=10+10) Compiler 3.10s ± 3% 3.08s ± 1% ~ (p=0.631 n=10+10) Fixes #16061. Change-Id: Id99cdc7a182ee10a704fa0f04e8e0d0809b2ac56 Reviewed-on: https://go-review.googlesource.com/29732 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2016-09-23 09:15:51 -04:00
s.tmpused = s.nospill
s.nospill = 0
s.advanceUses(v) // frees any registers holding args that are no longer live
}
// Dump any registers which will be clobbered
if s.doClobber && v.Op.IsCall() {
// clobber registers that are marked as clobber in regmask, but
// don't clobber inputs.
s.clobberRegs(regspec.clobbers &^ s.tmpused &^ s.nospill)
}
s.freeRegs(regspec.clobbers)
cmd/compile: move value around before kick it out of register When allocating registers, before kicking out the existing value, copy it to a spare register if there is one. So later use of this value can be found in register instead of reload from spill. This is very helpful for instructions of which the input and/or output can only be in specific registers, e.g. DIV on x86, MUL/DIV on MIPS. May also be helpful in general. For "go build -a cmd/go" on AMD64, reduce "spilled value remains" by 1% (not including args, which almost certainly remain). For the code in issue #16061 on AMD64: MaxRem-12 111µs ± 1% 94µs ± 0% -15.38% (p=0.008 n=5+5) Go1 benchmark on AMD64: BinaryTree17-12 2.32s ± 2% 2.30s ± 1% ~ (p=0.421 n=5+5) Fannkuch11-12 2.52s ± 0% 2.44s ± 0% -3.44% (p=0.008 n=5+5) FmtFprintfEmpty-12 39.9ns ± 3% 39.8ns ± 0% ~ (p=0.635 n=5+4) FmtFprintfString-12 114ns ± 1% 113ns ± 1% ~ (p=0.905 n=5+5) FmtFprintfInt-12 102ns ± 6% 98ns ± 1% ~ (p=0.087 n=5+5) FmtFprintfIntInt-12 146ns ± 5% 147ns ± 1% ~ (p=0.238 n=5+5) FmtFprintfPrefixedInt-12 155ns ± 2% 151ns ± 1% -2.58% (p=0.008 n=5+5) FmtFprintfFloat-12 231ns ± 1% 232ns ± 1% ~ (p=0.286 n=5+5) FmtManyArgs-12 657ns ± 1% 649ns ± 0% -1.31% (p=0.008 n=5+5) GobDecode-12 6.35ms ± 0% 6.29ms ± 1% ~ (p=0.056 n=5+5) GobEncode-12 5.38ms ± 1% 5.45ms ± 1% ~ (p=0.056 n=5+5) Gzip-12 209ms ± 0% 209ms ± 1% ~ (p=0.690 n=5+5) Gunzip-12 31.2ms ± 1% 31.1ms ± 1% ~ (p=0.548 n=5+5) HTTPClientServer-12 123µs ± 4% 130µs ± 8% ~ (p=0.151 n=5+5) JSONEncode-12 14.0ms ± 1% 14.0ms ± 1% ~ (p=0.421 n=5+5) JSONDecode-12 41.2ms ± 1% 41.1ms ± 2% ~ (p=0.421 n=5+5) Mandelbrot200-12 3.96ms ± 1% 3.98ms ± 0% ~ (p=0.421 n=5+5) GoParse-12 2.88ms ± 1% 2.88ms ± 1% ~ (p=0.841 n=5+5) RegexpMatchEasy0_32-12 68.0ns ± 3% 66.6ns ± 1% -2.00% (p=0.024 n=5+5) RegexpMatchEasy0_1K-12 728ns ± 8% 682ns ± 1% -6.26% (p=0.008 n=5+5) RegexpMatchEasy1_32-12 66.8ns ± 2% 66.0ns ± 1% ~ (p=0.302 n=5+5) RegexpMatchEasy1_1K-12 291ns ± 2% 288ns ± 1% ~ (p=0.111 n=5+5) RegexpMatchMedium_32-12 103ns ± 2% 100ns ± 0% -2.53% (p=0.016 n=5+4) RegexpMatchMedium_1K-12 31.9µs ± 1% 31.3µs ± 0% -1.75% (p=0.008 n=5+5) RegexpMatchHard_32-12 1.59µs ± 2% 1.59µs ± 1% ~ (p=0.548 n=5+5) RegexpMatchHard_1K-12 48.3µs ± 2% 47.7µs ± 1% ~ (p=0.222 n=5+5) Revcomp-12 340ms ± 1% 338ms ± 1% ~ (p=0.421 n=5+5) Template-12 46.3ms ± 1% 46.5ms ± 1% ~ (p=0.690 n=5+5) TimeParse-12 252ns ± 1% 247ns ± 0% -1.91% (p=0.000 n=5+4) TimeFormat-12 277ns ± 1% 267ns ± 0% -3.82% (p=0.008 n=5+5) [Geo mean] 48.8µs 48.3µs -0.93% It has very little effect on binary size and compiler speed. compilebench: Template 230ms ±10% 231ms ± 8% ~ (p=0.546 n=9+9) Unicode 123ms ± 6% 124ms ± 9% ~ (p=0.481 n=10+10) GoTypes 742ms ± 6% 755ms ± 3% ~ (p=0.123 n=10+10) Compiler 3.10s ± 3% 3.08s ± 1% ~ (p=0.631 n=10+10) Fixes #16061. Change-Id: Id99cdc7a182ee10a704fa0f04e8e0d0809b2ac56 Reviewed-on: https://go-review.googlesource.com/29732 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2016-09-23 09:15:51 -04:00
s.tmpused |= regspec.clobbers
// Pick registers for outputs.
{
outRegs := noRegisters // TODO if this is costly, hoist and clear incrementally below.
maxOutIdx := -1
var used regMask
if tmpReg != noRegister {
// Ensure output registers are distinct from the temporary register.
// (Not all instructions need that distinct part, but it is conservative.)
used |= regMask(1) << tmpReg
}
for _, out := range regspec.outputs {
if out.regs == 0 {
continue
}
mask := out.regs & s.allocatable &^ used
if mask == 0 {
s.f.Fatalf("can't find any output register %s", v.LongString())
}
if opcodeTable[v.Op].resultInArg0 && out.idx == 0 {
if !opcodeTable[v.Op].commutative {
// Output must use the same register as input 0.
r := register(s.f.getHome(args[0].ID).(*Register).num)
if mask>>r&1 == 0 {
s.f.Fatalf("resultInArg0 value's input %v cannot be an output of %s", s.f.getHome(args[0].ID).(*Register), v.LongString())
}
mask = regMask(1) << r
} else {
// Output must use the same register as input 0 or 1.
r0 := register(s.f.getHome(args[0].ID).(*Register).num)
r1 := register(s.f.getHome(args[1].ID).(*Register).num)
// Check r0 and r1 for desired output register.
found := false
for _, r := range dinfo[idx].out {
if (r == r0 || r == r1) && (mask&^s.used)>>r&1 != 0 {
mask = regMask(1) << r
found = true
if r == r1 {
args[0], args[1] = args[1], args[0]
}
break
}
}
if !found {
// Neither are desired, pick r0.
mask = regMask(1) << r0
}
}
}
if out.idx == 0 { // desired registers only apply to the first element of a tuple result
for _, r := range dinfo[idx].out {
if r != noRegister && (mask&^s.used)>>r&1 != 0 {
// Desired register is allowed and unused.
mask = regMask(1) << r
break
}
}
}
if out.idx == 1 {
if prefs, ok := desiredSecondReg[v.ID]; ok {
for _, r := range prefs {
if r != noRegister && (mask&^s.used)>>r&1 != 0 {
// Desired register is allowed and unused.
mask = regMask(1) << r
break
}
}
}
}
// Avoid registers we're saving for other values.
if mask&^desired.avoid&^s.nospill&^s.used != 0 {
mask &^= desired.avoid
}
r := s.allocReg(mask, v)
if out.idx > maxOutIdx {
maxOutIdx = out.idx
}
outRegs[out.idx] = r
used |= regMask(1) << r
cmd/compile: move value around before kick it out of register When allocating registers, before kicking out the existing value, copy it to a spare register if there is one. So later use of this value can be found in register instead of reload from spill. This is very helpful for instructions of which the input and/or output can only be in specific registers, e.g. DIV on x86, MUL/DIV on MIPS. May also be helpful in general. For "go build -a cmd/go" on AMD64, reduce "spilled value remains" by 1% (not including args, which almost certainly remain). For the code in issue #16061 on AMD64: MaxRem-12 111µs ± 1% 94µs ± 0% -15.38% (p=0.008 n=5+5) Go1 benchmark on AMD64: BinaryTree17-12 2.32s ± 2% 2.30s ± 1% ~ (p=0.421 n=5+5) Fannkuch11-12 2.52s ± 0% 2.44s ± 0% -3.44% (p=0.008 n=5+5) FmtFprintfEmpty-12 39.9ns ± 3% 39.8ns ± 0% ~ (p=0.635 n=5+4) FmtFprintfString-12 114ns ± 1% 113ns ± 1% ~ (p=0.905 n=5+5) FmtFprintfInt-12 102ns ± 6% 98ns ± 1% ~ (p=0.087 n=5+5) FmtFprintfIntInt-12 146ns ± 5% 147ns ± 1% ~ (p=0.238 n=5+5) FmtFprintfPrefixedInt-12 155ns ± 2% 151ns ± 1% -2.58% (p=0.008 n=5+5) FmtFprintfFloat-12 231ns ± 1% 232ns ± 1% ~ (p=0.286 n=5+5) FmtManyArgs-12 657ns ± 1% 649ns ± 0% -1.31% (p=0.008 n=5+5) GobDecode-12 6.35ms ± 0% 6.29ms ± 1% ~ (p=0.056 n=5+5) GobEncode-12 5.38ms ± 1% 5.45ms ± 1% ~ (p=0.056 n=5+5) Gzip-12 209ms ± 0% 209ms ± 1% ~ (p=0.690 n=5+5) Gunzip-12 31.2ms ± 1% 31.1ms ± 1% ~ (p=0.548 n=5+5) HTTPClientServer-12 123µs ± 4% 130µs ± 8% ~ (p=0.151 n=5+5) JSONEncode-12 14.0ms ± 1% 14.0ms ± 1% ~ (p=0.421 n=5+5) JSONDecode-12 41.2ms ± 1% 41.1ms ± 2% ~ (p=0.421 n=5+5) Mandelbrot200-12 3.96ms ± 1% 3.98ms ± 0% ~ (p=0.421 n=5+5) GoParse-12 2.88ms ± 1% 2.88ms ± 1% ~ (p=0.841 n=5+5) RegexpMatchEasy0_32-12 68.0ns ± 3% 66.6ns ± 1% -2.00% (p=0.024 n=5+5) RegexpMatchEasy0_1K-12 728ns ± 8% 682ns ± 1% -6.26% (p=0.008 n=5+5) RegexpMatchEasy1_32-12 66.8ns ± 2% 66.0ns ± 1% ~ (p=0.302 n=5+5) RegexpMatchEasy1_1K-12 291ns ± 2% 288ns ± 1% ~ (p=0.111 n=5+5) RegexpMatchMedium_32-12 103ns ± 2% 100ns ± 0% -2.53% (p=0.016 n=5+4) RegexpMatchMedium_1K-12 31.9µs ± 1% 31.3µs ± 0% -1.75% (p=0.008 n=5+5) RegexpMatchHard_32-12 1.59µs ± 2% 1.59µs ± 1% ~ (p=0.548 n=5+5) RegexpMatchHard_1K-12 48.3µs ± 2% 47.7µs ± 1% ~ (p=0.222 n=5+5) Revcomp-12 340ms ± 1% 338ms ± 1% ~ (p=0.421 n=5+5) Template-12 46.3ms ± 1% 46.5ms ± 1% ~ (p=0.690 n=5+5) TimeParse-12 252ns ± 1% 247ns ± 0% -1.91% (p=0.000 n=5+4) TimeFormat-12 277ns ± 1% 267ns ± 0% -3.82% (p=0.008 n=5+5) [Geo mean] 48.8µs 48.3µs -0.93% It has very little effect on binary size and compiler speed. compilebench: Template 230ms ±10% 231ms ± 8% ~ (p=0.546 n=9+9) Unicode 123ms ± 6% 124ms ± 9% ~ (p=0.481 n=10+10) GoTypes 742ms ± 6% 755ms ± 3% ~ (p=0.123 n=10+10) Compiler 3.10s ± 3% 3.08s ± 1% ~ (p=0.631 n=10+10) Fixes #16061. Change-Id: Id99cdc7a182ee10a704fa0f04e8e0d0809b2ac56 Reviewed-on: https://go-review.googlesource.com/29732 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2016-09-23 09:15:51 -04:00
s.tmpused |= regMask(1) << r
}
// Record register choices
if v.Type.IsTuple() {
var outLocs LocPair
if r := outRegs[0]; r != noRegister {
outLocs[0] = &s.registers[r]
}
if r := outRegs[1]; r != noRegister {
outLocs[1] = &s.registers[r]
}
s.f.setHome(v, outLocs)
// Note that subsequent SelectX instructions will do the assignReg calls.
} else if v.Type.IsResults() {
// preallocate outLocs to the right size, which is maxOutIdx+1
outLocs := make(LocResults, maxOutIdx+1, maxOutIdx+1)
for i := 0; i <= maxOutIdx; i++ {
if r := outRegs[i]; r != noRegister {
outLocs[i] = &s.registers[r]
}
}
s.f.setHome(v, outLocs)
} else {
if r := outRegs[0]; r != noRegister {
s.assignReg(r, v, v)
}
}
if tmpReg != noRegister {
// Remember the temp register allocation, if any.
if s.f.tempRegs == nil {
s.f.tempRegs = map[ID]*Register{}
}
s.f.tempRegs[v.ID] = &s.registers[tmpReg]
}
}
// deallocate dead args, if we have not done so
if opcodeTable[v.Op].resultNotInArgs {
s.nospill = 0
s.advanceUses(v) // frees any registers holding args that are no longer live
}
cmd/compile: move value around before kick it out of register When allocating registers, before kicking out the existing value, copy it to a spare register if there is one. So later use of this value can be found in register instead of reload from spill. This is very helpful for instructions of which the input and/or output can only be in specific registers, e.g. DIV on x86, MUL/DIV on MIPS. May also be helpful in general. For "go build -a cmd/go" on AMD64, reduce "spilled value remains" by 1% (not including args, which almost certainly remain). For the code in issue #16061 on AMD64: MaxRem-12 111µs ± 1% 94µs ± 0% -15.38% (p=0.008 n=5+5) Go1 benchmark on AMD64: BinaryTree17-12 2.32s ± 2% 2.30s ± 1% ~ (p=0.421 n=5+5) Fannkuch11-12 2.52s ± 0% 2.44s ± 0% -3.44% (p=0.008 n=5+5) FmtFprintfEmpty-12 39.9ns ± 3% 39.8ns ± 0% ~ (p=0.635 n=5+4) FmtFprintfString-12 114ns ± 1% 113ns ± 1% ~ (p=0.905 n=5+5) FmtFprintfInt-12 102ns ± 6% 98ns ± 1% ~ (p=0.087 n=5+5) FmtFprintfIntInt-12 146ns ± 5% 147ns ± 1% ~ (p=0.238 n=5+5) FmtFprintfPrefixedInt-12 155ns ± 2% 151ns ± 1% -2.58% (p=0.008 n=5+5) FmtFprintfFloat-12 231ns ± 1% 232ns ± 1% ~ (p=0.286 n=5+5) FmtManyArgs-12 657ns ± 1% 649ns ± 0% -1.31% (p=0.008 n=5+5) GobDecode-12 6.35ms ± 0% 6.29ms ± 1% ~ (p=0.056 n=5+5) GobEncode-12 5.38ms ± 1% 5.45ms ± 1% ~ (p=0.056 n=5+5) Gzip-12 209ms ± 0% 209ms ± 1% ~ (p=0.690 n=5+5) Gunzip-12 31.2ms ± 1% 31.1ms ± 1% ~ (p=0.548 n=5+5) HTTPClientServer-12 123µs ± 4% 130µs ± 8% ~ (p=0.151 n=5+5) JSONEncode-12 14.0ms ± 1% 14.0ms ± 1% ~ (p=0.421 n=5+5) JSONDecode-12 41.2ms ± 1% 41.1ms ± 2% ~ (p=0.421 n=5+5) Mandelbrot200-12 3.96ms ± 1% 3.98ms ± 0% ~ (p=0.421 n=5+5) GoParse-12 2.88ms ± 1% 2.88ms ± 1% ~ (p=0.841 n=5+5) RegexpMatchEasy0_32-12 68.0ns ± 3% 66.6ns ± 1% -2.00% (p=0.024 n=5+5) RegexpMatchEasy0_1K-12 728ns ± 8% 682ns ± 1% -6.26% (p=0.008 n=5+5) RegexpMatchEasy1_32-12 66.8ns ± 2% 66.0ns ± 1% ~ (p=0.302 n=5+5) RegexpMatchEasy1_1K-12 291ns ± 2% 288ns ± 1% ~ (p=0.111 n=5+5) RegexpMatchMedium_32-12 103ns ± 2% 100ns ± 0% -2.53% (p=0.016 n=5+4) RegexpMatchMedium_1K-12 31.9µs ± 1% 31.3µs ± 0% -1.75% (p=0.008 n=5+5) RegexpMatchHard_32-12 1.59µs ± 2% 1.59µs ± 1% ~ (p=0.548 n=5+5) RegexpMatchHard_1K-12 48.3µs ± 2% 47.7µs ± 1% ~ (p=0.222 n=5+5) Revcomp-12 340ms ± 1% 338ms ± 1% ~ (p=0.421 n=5+5) Template-12 46.3ms ± 1% 46.5ms ± 1% ~ (p=0.690 n=5+5) TimeParse-12 252ns ± 1% 247ns ± 0% -1.91% (p=0.000 n=5+4) TimeFormat-12 277ns ± 1% 267ns ± 0% -3.82% (p=0.008 n=5+5) [Geo mean] 48.8µs 48.3µs -0.93% It has very little effect on binary size and compiler speed. compilebench: Template 230ms ±10% 231ms ± 8% ~ (p=0.546 n=9+9) Unicode 123ms ± 6% 124ms ± 9% ~ (p=0.481 n=10+10) GoTypes 742ms ± 6% 755ms ± 3% ~ (p=0.123 n=10+10) Compiler 3.10s ± 3% 3.08s ± 1% ~ (p=0.631 n=10+10) Fixes #16061. Change-Id: Id99cdc7a182ee10a704fa0f04e8e0d0809b2ac56 Reviewed-on: https://go-review.googlesource.com/29732 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2016-09-23 09:15:51 -04:00
s.tmpused = 0
// Issue the Value itself.
for i, a := range args {
v.SetArg(i, a) // use register version of arguments
}
b.Values = append(b.Values, v)
s.dropIfUnused(v)
}
cmd/compile: allow multiple SSA block control values Control values are used to choose which successor of a block is jumped to. Typically a control value takes the form of a 'flags' value that represents the result of a comparison. Some architectures however use a variable in a register as a control value. Up until now we have managed with a single control value per block. However some architectures (e.g. s390x and riscv64) have combined compare-and-branch instructions that take two variables in registers as parameters. To generate these instructions we need to support 2 control values per block. This CL allows up to 2 control values to be used in a block in order to support the addition of compare-and-branch instructions. I have implemented s390x compare-and-branch instructions in a different CL. Passes toolstash-check -all. Results of compilebench: name old time/op new time/op delta Template 208ms ± 1% 209ms ± 1% ~ (p=0.289 n=20+20) Unicode 83.7ms ± 1% 83.3ms ± 3% -0.49% (p=0.017 n=18+18) GoTypes 748ms ± 1% 748ms ± 0% ~ (p=0.460 n=20+18) Compiler 3.47s ± 1% 3.48s ± 1% ~ (p=0.070 n=19+18) SSA 11.5s ± 1% 11.7s ± 1% +1.64% (p=0.000 n=19+18) Flate 130ms ± 1% 130ms ± 1% ~ (p=0.588 n=19+20) GoParser 160ms ± 1% 161ms ± 1% ~ (p=0.211 n=20+20) Reflect 465ms ± 1% 467ms ± 1% +0.42% (p=0.007 n=20+20) Tar 184ms ± 1% 185ms ± 2% ~ (p=0.087 n=18+20) XML 253ms ± 1% 253ms ± 1% ~ (p=0.377 n=20+18) LinkCompiler 769ms ± 2% 774ms ± 2% ~ (p=0.070 n=19+19) ExternalLinkCompiler 3.59s ±11% 3.68s ± 6% ~ (p=0.072 n=20+20) LinkWithoutDebugCompiler 446ms ± 5% 454ms ± 3% +1.79% (p=0.002 n=19+20) StdCmd 26.0s ± 2% 26.0s ± 2% ~ (p=0.799 n=20+20) name old user-time/op new user-time/op delta Template 238ms ± 5% 240ms ± 5% ~ (p=0.142 n=20+20) Unicode 105ms ±11% 106ms ±10% ~ (p=0.512 n=20+20) GoTypes 876ms ± 2% 873ms ± 4% ~ (p=0.647 n=20+19) Compiler 4.17s ± 2% 4.19s ± 1% ~ (p=0.093 n=20+18) SSA 13.9s ± 1% 14.1s ± 1% +1.45% (p=0.000 n=18+18) Flate 145ms ±13% 146ms ± 5% ~ (p=0.851 n=20+18) GoParser 185ms ± 5% 188ms ± 7% ~ (p=0.174 n=20+20) Reflect 534ms ± 3% 538ms ± 2% ~ (p=0.105 n=20+18) Tar 215ms ± 4% 211ms ± 9% ~ (p=0.079 n=19+20) XML 295ms ± 6% 295ms ± 5% ~ (p=0.968 n=20+20) LinkCompiler 832ms ± 4% 837ms ± 7% ~ (p=0.707 n=17+20) ExternalLinkCompiler 1.58s ± 8% 1.60s ± 4% ~ (p=0.296 n=20+19) LinkWithoutDebugCompiler 478ms ±12% 489ms ±10% ~ (p=0.429 n=20+20) name old object-bytes new object-bytes delta Template 559kB ± 0% 559kB ± 0% ~ (all equal) Unicode 216kB ± 0% 216kB ± 0% ~ (all equal) GoTypes 2.03MB ± 0% 2.03MB ± 0% ~ (all equal) Compiler 8.07MB ± 0% 8.07MB ± 0% -0.06% (p=0.000 n=20+20) SSA 27.1MB ± 0% 27.3MB ± 0% +0.89% (p=0.000 n=20+20) Flate 343kB ± 0% 343kB ± 0% ~ (all equal) GoParser 441kB ± 0% 441kB ± 0% ~ (all equal) Reflect 1.36MB ± 0% 1.36MB ± 0% ~ (all equal) Tar 487kB ± 0% 487kB ± 0% ~ (all equal) XML 632kB ± 0% 632kB ± 0% ~ (all equal) name old export-bytes new export-bytes delta Template 18.5kB ± 0% 18.5kB ± 0% ~ (all equal) Unicode 7.92kB ± 0% 7.92kB ± 0% ~ (all equal) GoTypes 35.0kB ± 0% 35.0kB ± 0% ~ (all equal) Compiler 109kB ± 0% 110kB ± 0% +0.72% (p=0.000 n=20+20) SSA 137kB ± 0% 138kB ± 0% +0.58% (p=0.000 n=20+20) Flate 4.89kB ± 0% 4.89kB ± 0% ~ (all equal) GoParser 8.49kB ± 0% 8.49kB ± 0% ~ (all equal) Reflect 11.4kB ± 0% 11.4kB ± 0% ~ (all equal) Tar 10.5kB ± 0% 10.5kB ± 0% ~ (all equal) XML 16.7kB ± 0% 16.7kB ± 0% ~ (all equal) name old text-bytes new text-bytes delta HelloSize 761kB ± 0% 761kB ± 0% ~ (all equal) CmdGoSize 10.8MB ± 0% 10.8MB ± 0% ~ (all equal) name old data-bytes new data-bytes delta HelloSize 10.7kB ± 0% 10.7kB ± 0% ~ (all equal) CmdGoSize 312kB ± 0% 312kB ± 0% ~ (all equal) name old bss-bytes new bss-bytes delta HelloSize 122kB ± 0% 122kB ± 0% ~ (all equal) CmdGoSize 146kB ± 0% 146kB ± 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 1.13MB ± 0% 1.13MB ± 0% ~ (all equal) CmdGoSize 15.1MB ± 0% 15.1MB ± 0% ~ (all equal) Change-Id: I3cc2f9829a109543d9a68be4a21775d2d3e9801f Reviewed-on: https://go-review.googlesource.com/c/go/+/196557 Run-TryBot: Michael Munday <mike.munday@ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Keith Randall <khr@golang.org>
2019-08-12 20:19:58 +01:00
// Copy the control values - we need this so we can reduce the
// uses property of these values later.
controls := append(make([]*Value, 0, 2), b.ControlValues()...)
// Load control values into registers.
for i, v := range b.ControlValues() {
if !s.values[v.ID].needReg {
continue
}
if s.f.pass.debug > regDebug {
fmt.Printf(" processing control %s\n", v.LongString())
}
// We assume that a control input can be passed in any
// type-compatible register. If this turns out not to be true,
// we'll need to introduce a regspec for a block's control value.
cmd/compile: allow multiple SSA block control values Control values are used to choose which successor of a block is jumped to. Typically a control value takes the form of a 'flags' value that represents the result of a comparison. Some architectures however use a variable in a register as a control value. Up until now we have managed with a single control value per block. However some architectures (e.g. s390x and riscv64) have combined compare-and-branch instructions that take two variables in registers as parameters. To generate these instructions we need to support 2 control values per block. This CL allows up to 2 control values to be used in a block in order to support the addition of compare-and-branch instructions. I have implemented s390x compare-and-branch instructions in a different CL. Passes toolstash-check -all. Results of compilebench: name old time/op new time/op delta Template 208ms ± 1% 209ms ± 1% ~ (p=0.289 n=20+20) Unicode 83.7ms ± 1% 83.3ms ± 3% -0.49% (p=0.017 n=18+18) GoTypes 748ms ± 1% 748ms ± 0% ~ (p=0.460 n=20+18) Compiler 3.47s ± 1% 3.48s ± 1% ~ (p=0.070 n=19+18) SSA 11.5s ± 1% 11.7s ± 1% +1.64% (p=0.000 n=19+18) Flate 130ms ± 1% 130ms ± 1% ~ (p=0.588 n=19+20) GoParser 160ms ± 1% 161ms ± 1% ~ (p=0.211 n=20+20) Reflect 465ms ± 1% 467ms ± 1% +0.42% (p=0.007 n=20+20) Tar 184ms ± 1% 185ms ± 2% ~ (p=0.087 n=18+20) XML 253ms ± 1% 253ms ± 1% ~ (p=0.377 n=20+18) LinkCompiler 769ms ± 2% 774ms ± 2% ~ (p=0.070 n=19+19) ExternalLinkCompiler 3.59s ±11% 3.68s ± 6% ~ (p=0.072 n=20+20) LinkWithoutDebugCompiler 446ms ± 5% 454ms ± 3% +1.79% (p=0.002 n=19+20) StdCmd 26.0s ± 2% 26.0s ± 2% ~ (p=0.799 n=20+20) name old user-time/op new user-time/op delta Template 238ms ± 5% 240ms ± 5% ~ (p=0.142 n=20+20) Unicode 105ms ±11% 106ms ±10% ~ (p=0.512 n=20+20) GoTypes 876ms ± 2% 873ms ± 4% ~ (p=0.647 n=20+19) Compiler 4.17s ± 2% 4.19s ± 1% ~ (p=0.093 n=20+18) SSA 13.9s ± 1% 14.1s ± 1% +1.45% (p=0.000 n=18+18) Flate 145ms ±13% 146ms ± 5% ~ (p=0.851 n=20+18) GoParser 185ms ± 5% 188ms ± 7% ~ (p=0.174 n=20+20) Reflect 534ms ± 3% 538ms ± 2% ~ (p=0.105 n=20+18) Tar 215ms ± 4% 211ms ± 9% ~ (p=0.079 n=19+20) XML 295ms ± 6% 295ms ± 5% ~ (p=0.968 n=20+20) LinkCompiler 832ms ± 4% 837ms ± 7% ~ (p=0.707 n=17+20) ExternalLinkCompiler 1.58s ± 8% 1.60s ± 4% ~ (p=0.296 n=20+19) LinkWithoutDebugCompiler 478ms ±12% 489ms ±10% ~ (p=0.429 n=20+20) name old object-bytes new object-bytes delta Template 559kB ± 0% 559kB ± 0% ~ (all equal) Unicode 216kB ± 0% 216kB ± 0% ~ (all equal) GoTypes 2.03MB ± 0% 2.03MB ± 0% ~ (all equal) Compiler 8.07MB ± 0% 8.07MB ± 0% -0.06% (p=0.000 n=20+20) SSA 27.1MB ± 0% 27.3MB ± 0% +0.89% (p=0.000 n=20+20) Flate 343kB ± 0% 343kB ± 0% ~ (all equal) GoParser 441kB ± 0% 441kB ± 0% ~ (all equal) Reflect 1.36MB ± 0% 1.36MB ± 0% ~ (all equal) Tar 487kB ± 0% 487kB ± 0% ~ (all equal) XML 632kB ± 0% 632kB ± 0% ~ (all equal) name old export-bytes new export-bytes delta Template 18.5kB ± 0% 18.5kB ± 0% ~ (all equal) Unicode 7.92kB ± 0% 7.92kB ± 0% ~ (all equal) GoTypes 35.0kB ± 0% 35.0kB ± 0% ~ (all equal) Compiler 109kB ± 0% 110kB ± 0% +0.72% (p=0.000 n=20+20) SSA 137kB ± 0% 138kB ± 0% +0.58% (p=0.000 n=20+20) Flate 4.89kB ± 0% 4.89kB ± 0% ~ (all equal) GoParser 8.49kB ± 0% 8.49kB ± 0% ~ (all equal) Reflect 11.4kB ± 0% 11.4kB ± 0% ~ (all equal) Tar 10.5kB ± 0% 10.5kB ± 0% ~ (all equal) XML 16.7kB ± 0% 16.7kB ± 0% ~ (all equal) name old text-bytes new text-bytes delta HelloSize 761kB ± 0% 761kB ± 0% ~ (all equal) CmdGoSize 10.8MB ± 0% 10.8MB ± 0% ~ (all equal) name old data-bytes new data-bytes delta HelloSize 10.7kB ± 0% 10.7kB ± 0% ~ (all equal) CmdGoSize 312kB ± 0% 312kB ± 0% ~ (all equal) name old bss-bytes new bss-bytes delta HelloSize 122kB ± 0% 122kB ± 0% ~ (all equal) CmdGoSize 146kB ± 0% 146kB ± 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 1.13MB ± 0% 1.13MB ± 0% ~ (all equal) CmdGoSize 15.1MB ± 0% 15.1MB ± 0% ~ (all equal) Change-Id: I3cc2f9829a109543d9a68be4a21775d2d3e9801f Reviewed-on: https://go-review.googlesource.com/c/go/+/196557 Run-TryBot: Michael Munday <mike.munday@ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Keith Randall <khr@golang.org>
2019-08-12 20:19:58 +01:00
b.ReplaceControl(i, s.allocValToReg(v, s.compatRegs(v.Type), false, b.Pos))
}
// Reduce the uses of the control values once registers have been loaded.
// This loop is equivalent to the advanceUses method.
for _, v := range controls {
vi := &s.values[v.ID]
if !vi.needReg {
continue
cmd/compile: move value around before kick it out of register When allocating registers, before kicking out the existing value, copy it to a spare register if there is one. So later use of this value can be found in register instead of reload from spill. This is very helpful for instructions of which the input and/or output can only be in specific registers, e.g. DIV on x86, MUL/DIV on MIPS. May also be helpful in general. For "go build -a cmd/go" on AMD64, reduce "spilled value remains" by 1% (not including args, which almost certainly remain). For the code in issue #16061 on AMD64: MaxRem-12 111µs ± 1% 94µs ± 0% -15.38% (p=0.008 n=5+5) Go1 benchmark on AMD64: BinaryTree17-12 2.32s ± 2% 2.30s ± 1% ~ (p=0.421 n=5+5) Fannkuch11-12 2.52s ± 0% 2.44s ± 0% -3.44% (p=0.008 n=5+5) FmtFprintfEmpty-12 39.9ns ± 3% 39.8ns ± 0% ~ (p=0.635 n=5+4) FmtFprintfString-12 114ns ± 1% 113ns ± 1% ~ (p=0.905 n=5+5) FmtFprintfInt-12 102ns ± 6% 98ns ± 1% ~ (p=0.087 n=5+5) FmtFprintfIntInt-12 146ns ± 5% 147ns ± 1% ~ (p=0.238 n=5+5) FmtFprintfPrefixedInt-12 155ns ± 2% 151ns ± 1% -2.58% (p=0.008 n=5+5) FmtFprintfFloat-12 231ns ± 1% 232ns ± 1% ~ (p=0.286 n=5+5) FmtManyArgs-12 657ns ± 1% 649ns ± 0% -1.31% (p=0.008 n=5+5) GobDecode-12 6.35ms ± 0% 6.29ms ± 1% ~ (p=0.056 n=5+5) GobEncode-12 5.38ms ± 1% 5.45ms ± 1% ~ (p=0.056 n=5+5) Gzip-12 209ms ± 0% 209ms ± 1% ~ (p=0.690 n=5+5) Gunzip-12 31.2ms ± 1% 31.1ms ± 1% ~ (p=0.548 n=5+5) HTTPClientServer-12 123µs ± 4% 130µs ± 8% ~ (p=0.151 n=5+5) JSONEncode-12 14.0ms ± 1% 14.0ms ± 1% ~ (p=0.421 n=5+5) JSONDecode-12 41.2ms ± 1% 41.1ms ± 2% ~ (p=0.421 n=5+5) Mandelbrot200-12 3.96ms ± 1% 3.98ms ± 0% ~ (p=0.421 n=5+5) GoParse-12 2.88ms ± 1% 2.88ms ± 1% ~ (p=0.841 n=5+5) RegexpMatchEasy0_32-12 68.0ns ± 3% 66.6ns ± 1% -2.00% (p=0.024 n=5+5) RegexpMatchEasy0_1K-12 728ns ± 8% 682ns ± 1% -6.26% (p=0.008 n=5+5) RegexpMatchEasy1_32-12 66.8ns ± 2% 66.0ns ± 1% ~ (p=0.302 n=5+5) RegexpMatchEasy1_1K-12 291ns ± 2% 288ns ± 1% ~ (p=0.111 n=5+5) RegexpMatchMedium_32-12 103ns ± 2% 100ns ± 0% -2.53% (p=0.016 n=5+4) RegexpMatchMedium_1K-12 31.9µs ± 1% 31.3µs ± 0% -1.75% (p=0.008 n=5+5) RegexpMatchHard_32-12 1.59µs ± 2% 1.59µs ± 1% ~ (p=0.548 n=5+5) RegexpMatchHard_1K-12 48.3µs ± 2% 47.7µs ± 1% ~ (p=0.222 n=5+5) Revcomp-12 340ms ± 1% 338ms ± 1% ~ (p=0.421 n=5+5) Template-12 46.3ms ± 1% 46.5ms ± 1% ~ (p=0.690 n=5+5) TimeParse-12 252ns ± 1% 247ns ± 0% -1.91% (p=0.000 n=5+4) TimeFormat-12 277ns ± 1% 267ns ± 0% -3.82% (p=0.008 n=5+5) [Geo mean] 48.8µs 48.3µs -0.93% It has very little effect on binary size and compiler speed. compilebench: Template 230ms ±10% 231ms ± 8% ~ (p=0.546 n=9+9) Unicode 123ms ± 6% 124ms ± 9% ~ (p=0.481 n=10+10) GoTypes 742ms ± 6% 755ms ± 3% ~ (p=0.123 n=10+10) Compiler 3.10s ± 3% 3.08s ± 1% ~ (p=0.631 n=10+10) Fixes #16061. Change-Id: Id99cdc7a182ee10a704fa0f04e8e0d0809b2ac56 Reviewed-on: https://go-review.googlesource.com/29732 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2016-09-23 09:15:51 -04:00
}
// Remove this use from the uses list.
u := vi.uses
vi.uses = u.next
if u.next == nil {
s.freeRegs(vi.regs) // value is dead
}
u.next = s.freeUseRecords
s.freeUseRecords = u
}
cmd/compile: load some live values into registers before loop If we're about to enter a loop, load values which are live and will soon be used in the loop into registers. name old time/op new time/op delta BinaryTree17-8 2.80s ± 4% 2.62s ± 2% -6.43% (p=0.008 n=5+5) Fannkuch11-8 2.45s ± 2% 2.14s ± 1% -12.43% (p=0.008 n=5+5) FmtFprintfEmpty-8 49.0ns ± 1% 48.4ns ± 1% -1.35% (p=0.032 n=5+5) FmtFprintfString-8 160ns ± 1% 153ns ± 0% -4.63% (p=0.008 n=5+5) FmtFprintfInt-8 152ns ± 0% 150ns ± 0% -1.57% (p=0.000 n=5+4) FmtFprintfIntInt-8 252ns ± 2% 244ns ± 1% -3.02% (p=0.008 n=5+5) FmtFprintfPrefixedInt-8 223ns ± 0% 223ns ± 0% ~ (all samples are equal) FmtFprintfFloat-8 293ns ± 2% 291ns ± 2% ~ (p=0.389 n=5+5) FmtManyArgs-8 956ns ± 0% 936ns ± 0% -2.05% (p=0.008 n=5+5) GobDecode-8 7.18ms ± 0% 7.11ms ± 0% -1.02% (p=0.008 n=5+5) GobEncode-8 6.12ms ± 3% 6.07ms ± 1% ~ (p=0.690 n=5+5) Gzip-8 284ms ± 1% 284ms ± 0% ~ (p=1.000 n=5+5) Gunzip-8 40.8ms ± 1% 40.6ms ± 1% ~ (p=0.310 n=5+5) HTTPClientServer-8 69.8µs ± 1% 72.2µs ± 4% ~ (p=0.056 n=5+5) JSONEncode-8 16.1ms ± 2% 16.2ms ± 1% ~ (p=0.151 n=5+5) JSONDecode-8 54.9ms ± 0% 57.0ms ± 1% +3.79% (p=0.008 n=5+5) Mandelbrot200-8 4.35ms ± 0% 4.39ms ± 0% +0.85% (p=0.008 n=5+5) GoParse-8 3.56ms ± 1% 3.42ms ± 1% -4.03% (p=0.008 n=5+5) RegexpMatchEasy0_32-8 75.6ns ± 1% 75.0ns ± 0% -0.83% (p=0.016 n=5+4) RegexpMatchEasy0_1K-8 250ns ± 0% 252ns ± 1% +0.80% (p=0.016 n=4+5) RegexpMatchEasy1_32-8 75.0ns ± 0% 75.4ns ± 2% ~ (p=0.206 n=5+5) RegexpMatchEasy1_1K-8 401ns ± 0% 398ns ± 1% ~ (p=0.056 n=5+5) RegexpMatchMedium_32-8 119ns ± 0% 118ns ± 0% -0.84% (p=0.008 n=5+5) RegexpMatchMedium_1K-8 36.6µs ± 0% 36.9µs ± 0% +0.91% (p=0.008 n=5+5) RegexpMatchHard_32-8 1.95µs ± 1% 1.92µs ± 0% -1.23% (p=0.032 n=5+5) RegexpMatchHard_1K-8 58.3µs ± 1% 58.1µs ± 1% ~ (p=0.548 n=5+5) Revcomp-8 425ms ± 1% 389ms ± 1% -8.39% (p=0.008 n=5+5) Template-8 65.5ms ± 1% 63.6ms ± 1% -2.86% (p=0.008 n=5+5) TimeParse-8 363ns ± 0% 354ns ± 1% -2.59% (p=0.008 n=5+5) TimeFormat-8 363ns ± 0% 364ns ± 1% ~ (p=0.159 n=5+5) Fixes #14511 Change-Id: I1b79d2545271fa90d5b04712cc25573bdc94f2ce Reviewed-on: https://go-review.googlesource.com/20151 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2016-03-02 15:18:40 -08:00
// If we are approaching a merge point and we are the primary
// predecessor of it, find live values that we use soon after
// the merge point and promote them to registers now.
if len(b.Succs) == 1 {
if s.f.Config.hasGReg && s.regs[s.GReg].v != nil {
s.freeReg(s.GReg) // Spill value in G register before any merge.
}
if s.blockOrder[b.ID] > s.blockOrder[b.Succs[0].b.ID] {
// No point if we've already regalloc'd the destination.
goto badloop
}
cmd/compile: load some live values into registers before loop If we're about to enter a loop, load values which are live and will soon be used in the loop into registers. name old time/op new time/op delta BinaryTree17-8 2.80s ± 4% 2.62s ± 2% -6.43% (p=0.008 n=5+5) Fannkuch11-8 2.45s ± 2% 2.14s ± 1% -12.43% (p=0.008 n=5+5) FmtFprintfEmpty-8 49.0ns ± 1% 48.4ns ± 1% -1.35% (p=0.032 n=5+5) FmtFprintfString-8 160ns ± 1% 153ns ± 0% -4.63% (p=0.008 n=5+5) FmtFprintfInt-8 152ns ± 0% 150ns ± 0% -1.57% (p=0.000 n=5+4) FmtFprintfIntInt-8 252ns ± 2% 244ns ± 1% -3.02% (p=0.008 n=5+5) FmtFprintfPrefixedInt-8 223ns ± 0% 223ns ± 0% ~ (all samples are equal) FmtFprintfFloat-8 293ns ± 2% 291ns ± 2% ~ (p=0.389 n=5+5) FmtManyArgs-8 956ns ± 0% 936ns ± 0% -2.05% (p=0.008 n=5+5) GobDecode-8 7.18ms ± 0% 7.11ms ± 0% -1.02% (p=0.008 n=5+5) GobEncode-8 6.12ms ± 3% 6.07ms ± 1% ~ (p=0.690 n=5+5) Gzip-8 284ms ± 1% 284ms ± 0% ~ (p=1.000 n=5+5) Gunzip-8 40.8ms ± 1% 40.6ms ± 1% ~ (p=0.310 n=5+5) HTTPClientServer-8 69.8µs ± 1% 72.2µs ± 4% ~ (p=0.056 n=5+5) JSONEncode-8 16.1ms ± 2% 16.2ms ± 1% ~ (p=0.151 n=5+5) JSONDecode-8 54.9ms ± 0% 57.0ms ± 1% +3.79% (p=0.008 n=5+5) Mandelbrot200-8 4.35ms ± 0% 4.39ms ± 0% +0.85% (p=0.008 n=5+5) GoParse-8 3.56ms ± 1% 3.42ms ± 1% -4.03% (p=0.008 n=5+5) RegexpMatchEasy0_32-8 75.6ns ± 1% 75.0ns ± 0% -0.83% (p=0.016 n=5+4) RegexpMatchEasy0_1K-8 250ns ± 0% 252ns ± 1% +0.80% (p=0.016 n=4+5) RegexpMatchEasy1_32-8 75.0ns ± 0% 75.4ns ± 2% ~ (p=0.206 n=5+5) RegexpMatchEasy1_1K-8 401ns ± 0% 398ns ± 1% ~ (p=0.056 n=5+5) RegexpMatchMedium_32-8 119ns ± 0% 118ns ± 0% -0.84% (p=0.008 n=5+5) RegexpMatchMedium_1K-8 36.6µs ± 0% 36.9µs ± 0% +0.91% (p=0.008 n=5+5) RegexpMatchHard_32-8 1.95µs ± 1% 1.92µs ± 0% -1.23% (p=0.032 n=5+5) RegexpMatchHard_1K-8 58.3µs ± 1% 58.1µs ± 1% ~ (p=0.548 n=5+5) Revcomp-8 425ms ± 1% 389ms ± 1% -8.39% (p=0.008 n=5+5) Template-8 65.5ms ± 1% 63.6ms ± 1% -2.86% (p=0.008 n=5+5) TimeParse-8 363ns ± 0% 354ns ± 1% -2.59% (p=0.008 n=5+5) TimeFormat-8 363ns ± 0% 364ns ± 1% ~ (p=0.159 n=5+5) Fixes #14511 Change-Id: I1b79d2545271fa90d5b04712cc25573bdc94f2ce Reviewed-on: https://go-review.googlesource.com/20151 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2016-03-02 15:18:40 -08:00
// For this to be worthwhile, the loop must have no calls in it.
top := b.Succs[0].b
loop := s.loopnest.b2l[top.ID]
2017-12-14 13:27:11 -06:00
if loop == nil || loop.header != top || loop.containsUnavoidableCall {
goto badloop
cmd/compile: load some live values into registers before loop If we're about to enter a loop, load values which are live and will soon be used in the loop into registers. name old time/op new time/op delta BinaryTree17-8 2.80s ± 4% 2.62s ± 2% -6.43% (p=0.008 n=5+5) Fannkuch11-8 2.45s ± 2% 2.14s ± 1% -12.43% (p=0.008 n=5+5) FmtFprintfEmpty-8 49.0ns ± 1% 48.4ns ± 1% -1.35% (p=0.032 n=5+5) FmtFprintfString-8 160ns ± 1% 153ns ± 0% -4.63% (p=0.008 n=5+5) FmtFprintfInt-8 152ns ± 0% 150ns ± 0% -1.57% (p=0.000 n=5+4) FmtFprintfIntInt-8 252ns ± 2% 244ns ± 1% -3.02% (p=0.008 n=5+5) FmtFprintfPrefixedInt-8 223ns ± 0% 223ns ± 0% ~ (all samples are equal) FmtFprintfFloat-8 293ns ± 2% 291ns ± 2% ~ (p=0.389 n=5+5) FmtManyArgs-8 956ns ± 0% 936ns ± 0% -2.05% (p=0.008 n=5+5) GobDecode-8 7.18ms ± 0% 7.11ms ± 0% -1.02% (p=0.008 n=5+5) GobEncode-8 6.12ms ± 3% 6.07ms ± 1% ~ (p=0.690 n=5+5) Gzip-8 284ms ± 1% 284ms ± 0% ~ (p=1.000 n=5+5) Gunzip-8 40.8ms ± 1% 40.6ms ± 1% ~ (p=0.310 n=5+5) HTTPClientServer-8 69.8µs ± 1% 72.2µs ± 4% ~ (p=0.056 n=5+5) JSONEncode-8 16.1ms ± 2% 16.2ms ± 1% ~ (p=0.151 n=5+5) JSONDecode-8 54.9ms ± 0% 57.0ms ± 1% +3.79% (p=0.008 n=5+5) Mandelbrot200-8 4.35ms ± 0% 4.39ms ± 0% +0.85% (p=0.008 n=5+5) GoParse-8 3.56ms ± 1% 3.42ms ± 1% -4.03% (p=0.008 n=5+5) RegexpMatchEasy0_32-8 75.6ns ± 1% 75.0ns ± 0% -0.83% (p=0.016 n=5+4) RegexpMatchEasy0_1K-8 250ns ± 0% 252ns ± 1% +0.80% (p=0.016 n=4+5) RegexpMatchEasy1_32-8 75.0ns ± 0% 75.4ns ± 2% ~ (p=0.206 n=5+5) RegexpMatchEasy1_1K-8 401ns ± 0% 398ns ± 1% ~ (p=0.056 n=5+5) RegexpMatchMedium_32-8 119ns ± 0% 118ns ± 0% -0.84% (p=0.008 n=5+5) RegexpMatchMedium_1K-8 36.6µs ± 0% 36.9µs ± 0% +0.91% (p=0.008 n=5+5) RegexpMatchHard_32-8 1.95µs ± 1% 1.92µs ± 0% -1.23% (p=0.032 n=5+5) RegexpMatchHard_1K-8 58.3µs ± 1% 58.1µs ± 1% ~ (p=0.548 n=5+5) Revcomp-8 425ms ± 1% 389ms ± 1% -8.39% (p=0.008 n=5+5) Template-8 65.5ms ± 1% 63.6ms ± 1% -2.86% (p=0.008 n=5+5) TimeParse-8 363ns ± 0% 354ns ± 1% -2.59% (p=0.008 n=5+5) TimeFormat-8 363ns ± 0% 364ns ± 1% ~ (p=0.159 n=5+5) Fixes #14511 Change-Id: I1b79d2545271fa90d5b04712cc25573bdc94f2ce Reviewed-on: https://go-review.googlesource.com/20151 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2016-03-02 15:18:40 -08:00
}
// TODO: sort by distance, pick the closest ones?
for _, live := range s.live[b.ID] {
if live.dist >= unlikelyDistance {
// Don't preload anything live after the loop.
continue
}
vid := live.ID
vi := &s.values[vid]
if vi.regs != 0 {
continue
}
if vi.rematerializeable {
continue
}
cmd/compile: load some live values into registers before loop If we're about to enter a loop, load values which are live and will soon be used in the loop into registers. name old time/op new time/op delta BinaryTree17-8 2.80s ± 4% 2.62s ± 2% -6.43% (p=0.008 n=5+5) Fannkuch11-8 2.45s ± 2% 2.14s ± 1% -12.43% (p=0.008 n=5+5) FmtFprintfEmpty-8 49.0ns ± 1% 48.4ns ± 1% -1.35% (p=0.032 n=5+5) FmtFprintfString-8 160ns ± 1% 153ns ± 0% -4.63% (p=0.008 n=5+5) FmtFprintfInt-8 152ns ± 0% 150ns ± 0% -1.57% (p=0.000 n=5+4) FmtFprintfIntInt-8 252ns ± 2% 244ns ± 1% -3.02% (p=0.008 n=5+5) FmtFprintfPrefixedInt-8 223ns ± 0% 223ns ± 0% ~ (all samples are equal) FmtFprintfFloat-8 293ns ± 2% 291ns ± 2% ~ (p=0.389 n=5+5) FmtManyArgs-8 956ns ± 0% 936ns ± 0% -2.05% (p=0.008 n=5+5) GobDecode-8 7.18ms ± 0% 7.11ms ± 0% -1.02% (p=0.008 n=5+5) GobEncode-8 6.12ms ± 3% 6.07ms ± 1% ~ (p=0.690 n=5+5) Gzip-8 284ms ± 1% 284ms ± 0% ~ (p=1.000 n=5+5) Gunzip-8 40.8ms ± 1% 40.6ms ± 1% ~ (p=0.310 n=5+5) HTTPClientServer-8 69.8µs ± 1% 72.2µs ± 4% ~ (p=0.056 n=5+5) JSONEncode-8 16.1ms ± 2% 16.2ms ± 1% ~ (p=0.151 n=5+5) JSONDecode-8 54.9ms ± 0% 57.0ms ± 1% +3.79% (p=0.008 n=5+5) Mandelbrot200-8 4.35ms ± 0% 4.39ms ± 0% +0.85% (p=0.008 n=5+5) GoParse-8 3.56ms ± 1% 3.42ms ± 1% -4.03% (p=0.008 n=5+5) RegexpMatchEasy0_32-8 75.6ns ± 1% 75.0ns ± 0% -0.83% (p=0.016 n=5+4) RegexpMatchEasy0_1K-8 250ns ± 0% 252ns ± 1% +0.80% (p=0.016 n=4+5) RegexpMatchEasy1_32-8 75.0ns ± 0% 75.4ns ± 2% ~ (p=0.206 n=5+5) RegexpMatchEasy1_1K-8 401ns ± 0% 398ns ± 1% ~ (p=0.056 n=5+5) RegexpMatchMedium_32-8 119ns ± 0% 118ns ± 0% -0.84% (p=0.008 n=5+5) RegexpMatchMedium_1K-8 36.6µs ± 0% 36.9µs ± 0% +0.91% (p=0.008 n=5+5) RegexpMatchHard_32-8 1.95µs ± 1% 1.92µs ± 0% -1.23% (p=0.032 n=5+5) RegexpMatchHard_1K-8 58.3µs ± 1% 58.1µs ± 1% ~ (p=0.548 n=5+5) Revcomp-8 425ms ± 1% 389ms ± 1% -8.39% (p=0.008 n=5+5) Template-8 65.5ms ± 1% 63.6ms ± 1% -2.86% (p=0.008 n=5+5) TimeParse-8 363ns ± 0% 354ns ± 1% -2.59% (p=0.008 n=5+5) TimeFormat-8 363ns ± 0% 364ns ± 1% ~ (p=0.159 n=5+5) Fixes #14511 Change-Id: I1b79d2545271fa90d5b04712cc25573bdc94f2ce Reviewed-on: https://go-review.googlesource.com/20151 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2016-03-02 15:18:40 -08:00
v := s.orig[vid]
m := s.compatRegs(v.Type) &^ s.used
cmd/compile: use desired info when allocating registers for live values When allocting registers for live values, use desired register if available, this is helpful for some cases, such as (*entry).delete, which can save a few of copies. Besides, this patch allows more debugging information to be printed out. Test results of compilecmp on Linux/amd64: name old time/op new time/op delta Template 326729362.060000ns +- 3% 329227238.775510ns +- 4% +0.76% (p=0.038 n=50+49) Unicode 157671860.391304ns +- 6% 156917927.320000ns +- 6% ~ (p=0.291 n=46+50) GoTypes 1065591138.304348ns +- 2% 1063695977.434783ns +- 1% ~ (p=0.208 n=46+46) Compiler 5053424790.760001ns +- 2% 5052729636.551020ns +- 3% ~ (p=0.908 n=50+49) SSA 12392067635.866669ns +- 2% 12319786960.460005ns +- 2% -0.58% (p=0.008 n=45+50) Flate 212609767.340000ns +- 5% 213011228.085106ns +- 5% ~ (p=0.685 n=50+47) GoParser 266870495.100000ns +- 4% 266962314.280000ns +- 3% ~ (p=0.975 n=50+50) Reflect 660164306.551021ns +- 2% 658284470.729167ns +- 2% ~ (p=0.069 n=49+48) Tar 292805895.720000ns +- 4% 292103626.954545ns +- 2% ~ (p=0.321 n=50+44) XML 386294811.700000ns +- 4% 386665088.820000ns +- 4% ~ (p=0.786 n=50+50) LinkCompiler 548495788.659575ns +- 5% 549359489.102041ns +- 4% ~ (p=0.855 n=47+49) ExternalLinkCompiler 1810414270.280000ns +- 2% 1806872224.673470ns +- 2% ~ (p=0.313 n=50+49) LinkWithoutDebugCompiler 340888843.795918ns +- 5% 340341541.100000ns +- 6% ~ (p=0.735 n=49+50) [Geo mean] 664550174.613777ns 664090221.153575ns -0.07% name old user-time/op new user-time/op delta Template 565202800.000000ns +-16% 595351040.000000ns +-16% +5.33% (p=0.001 n=50+50) Unicode 378444740.000000ns +-14% 373825183.673469ns +-17% ~ (p=0.458 n=50+49) GoTypes 2052073341.463415ns +-12% 2059679864.864865ns +- 7% ~ (p=0.381 n=41+37) Compiler 9913371980.000000ns +-20% 9848836720.000002ns +-19% ~ (p=0.781 n=50+50) SSA 25013846224.489799ns +-17% 24571896183.673466ns +-17% ~ (p=0.132 n=49+49) Flate 314422702.127660ns +-17% 314831666.666667ns +-11% ~ (p=0.427 n=47+45) GoParser 419496060.000000ns +- 9% 417403460.000000ns +-11% ~ (p=0.512 n=50+50) Reflect 1233632469.387755ns +-17% 1193061073.170732ns +-13% -3.29% (p=0.030 n=49+41) Tar 509855937.500000ns +-10% 508700740.000000ns +-14% ~ (p=0.890 n=48+50) XML 703511425.531915ns +-12% 694007591.836735ns +-11% ~ (p=0.164 n=47+49) LinkCompiler 993137687.500000ns +- 6% 991914714.285714ns +- 8% ~ (p=0.860 n=48+49) ExternalLinkCompiler 2193851840.000001ns +- 3% 2186672183.673470ns +- 5% ~ (p=0.320 n=50+49) LinkWithoutDebugCompiler 420800875.000000ns +-10% 422062640.000000ns +- 9% ~ (p=0.840 n=48+50) [Geo mean] 1145156131.480097ns 1142033233.550961ns -0.27% name old alloc/op new alloc/op delta Template 36.3MB +- 0% 36.3MB +- 0% ~ (p=0.886 n=50+49) Unicode 30.1MB +- 0% 30.1MB +- 0% ~ (p=0.792 n=50+50) GoTypes 118MB +- 0% 118MB +- 0% ~ (p=1.000 n=47+48) Compiler 562MB +- 0% 562MB +- 0% ~ (p=0.205 n=50+49) SSA 1.42GB +- 0% 1.42GB +- 0% -0.12% (p=0.000 n=50+50) Flate 22.8MB +- 0% 22.8MB +- 0% ~ (p=0.384 n=50+47) GoParser 28.0MB +- 0% 28.0MB +- 0% -0.02% (p=0.013 n=50+50) Reflect 78.0MB +- 0% 78.0MB +- 0% ~ (p=0.384 n=46+48) Tar 34.1MB +- 0% 34.1MB +- 0% ~ (p=0.072 n=50+50) XML 43.1MB +- 0% 43.1MB +- 0% -0.04% (p=0.000 n=49+50) LinkCompiler 98.5MB +- 0% 98.5MB +- 0% +0.01% (p=0.012 n=50+43) ExternalLinkCompiler 89.6MB +- 0% 89.6MB +- 0% ~ (p=0.762 n=50+50) LinkWithoutDebugCompiler 56.9MB +- 0% 56.9MB +- 0% ~ (p=0.268 n=49+48) [Geo mean] 77.7MB 77.7MB -0.01% name old allocs/op new allocs/op delta Template 367k +- 0% 367k +- 0% -0.01% (p=0.002 n=50+49) Unicode 345k +- 0% 345k +- 0% ~ (p=0.981 n=50+50) GoTypes 1.28M +- 0% 1.28M +- 0% -0.00% (p=0.002 n=49+50) Compiler 5.39M +- 0% 5.39M +- 0% -0.00% (p=0.000 n=50+50) SSA 13.9M +- 0% 13.9M +- 0% +0.01% (p=0.000 n=50+50) Flate 230k +- 0% 230k +- 0% ~ (p=0.815 n=50+50) GoParser 292k +- 0% 292k +- 0% -0.01% (p=0.000 n=50+50) Reflect 977k +- 0% 977k +- 0% -0.00% (p=0.035 n=50+50) Tar 343k +- 0% 343k +- 0% -0.01% (p=0.008 n=48+50) XML 418k +- 0% 418k +- 0% -0.01% (p=0.000 n=50+50) LinkCompiler 516k +- 0% 516k +- 0% +0.01% (p=0.002 n=50+48) ExternalLinkCompiler 570k +- 0% 570k +- 0% ~ (p=0.430 n=46+50) LinkWithoutDebugCompiler 169k +- 0% 169k +- 0% ~ (p=0.706 n=49+49) [Geo mean] 672k 672k -0.00% name old maxRSS/op new maxRSS/op delta Template 34.3M +- 5% 34.7M +- 4% +1.24% (p=0.004 n=50+50) Unicode 36.2M +- 5% 36.1M +- 8% ~ (p=0.785 n=50+50) GoTypes 75.7M +- 7% 76.1M +- 6% ~ (p=0.544 n=50+50) Compiler 304M +- 7% 304M +- 7% ~ (p=0.744 n=50+50) SSA 721M +- 6% 723M +- 7% ~ (p=0.724 n=49+50) Flate 26.1M +- 3% 26.1M +- 5% ~ (p=0.649 n=48+49) GoParser 29.3M +- 5% 29.3M +- 4% ~ (p=0.809 n=50+50) Reflect 56.0M +- 6% 56.3M +- 5% ~ (p=0.350 n=50+50) Tar 34.1M +- 3% 33.9M +- 5% ~ (p=0.121 n=49+50) XML 39.6M +- 5% 39.9M +- 4% ~ (p=0.109 n=50+50) LinkCompiler 168M +- 1% 168M +- 1% ~ (p=0.578 n=49+48) ExternalLinkCompiler 179M +- 1% 179M +- 2% ~ (p=0.522 n=46+46) LinkWithoutDebugCompiler 137M +- 3% 137M +- 3% ~ (p=0.463 n=41+50) [Geo mean] 79.3M 79.5M +0.20% name old text-bytes new text-bytes delta HelloSize 812kB +- 0% 811kB +- 0% -0.05% (p=0.000 n=50+50) name old data-bytes new data-bytes delta HelloSize 13.3kB +- 0% 13.3kB +- 0% ~ (all equal) name old bss-bytes new bss-bytes delta HelloSize 206kB +- 0% 206kB +- 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 1.21MB +- 0% 1.21MB +- 0% +0.02% (p=0.000 n=50+50) file before after Δ % addr2line 4052949 4052453 -496 -0.012% api 4948171 4947163 -1008 -0.020% asm 4888889 4888049 -840 -0.017% buildid 2617545 2617673 +128 +0.005% cgo 4521681 4516801 -4880 -0.108% compile 19139091 19137683 -1408 -0.007% cover 4843191 4840359 -2832 -0.058% dist 3473677 3474717 +1040 +0.030% doc 3821592 3821552 -40 -0.001% fix 3220587 3220059 -528 -0.016% link 6587368 6582696 -4672 -0.071% nm 3999858 3999186 -672 -0.017% objdump 4409161 4408217 -944 -0.021% pack 2394038 2393846 -192 -0.008% pprof 13601271 13602487 +1216 +0.009% test2json 2645148 2644604 -544 -0.021% trace 10357878 10356862 -1016 -0.010% vet 6779482 6778706 -776 -0.011% total 106301577 106283113 -18464 -0.017% Change-Id: I63ac6e224e1a4756ddc1bfc4aabbaeb92d7d4273 Reviewed-on: https://go-review.googlesource.com/c/go/+/263599 Run-TryBot: eric fang <eric.fang@arm.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: eric fang <eric.fang@arm.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2020-10-19 03:57:15 +00:00
// Used desired register if available.
outerloop:
for _, e := range desired.entries {
if e.ID != v.ID {
continue
}
for _, r := range e.regs {
if r != noRegister && m>>r&1 != 0 {
m = regMask(1) << r
break outerloop
}
}
}
if m&^desired.avoid != 0 {
m &^= desired.avoid
}
cmd/compile: load some live values into registers before loop If we're about to enter a loop, load values which are live and will soon be used in the loop into registers. name old time/op new time/op delta BinaryTree17-8 2.80s ± 4% 2.62s ± 2% -6.43% (p=0.008 n=5+5) Fannkuch11-8 2.45s ± 2% 2.14s ± 1% -12.43% (p=0.008 n=5+5) FmtFprintfEmpty-8 49.0ns ± 1% 48.4ns ± 1% -1.35% (p=0.032 n=5+5) FmtFprintfString-8 160ns ± 1% 153ns ± 0% -4.63% (p=0.008 n=5+5) FmtFprintfInt-8 152ns ± 0% 150ns ± 0% -1.57% (p=0.000 n=5+4) FmtFprintfIntInt-8 252ns ± 2% 244ns ± 1% -3.02% (p=0.008 n=5+5) FmtFprintfPrefixedInt-8 223ns ± 0% 223ns ± 0% ~ (all samples are equal) FmtFprintfFloat-8 293ns ± 2% 291ns ± 2% ~ (p=0.389 n=5+5) FmtManyArgs-8 956ns ± 0% 936ns ± 0% -2.05% (p=0.008 n=5+5) GobDecode-8 7.18ms ± 0% 7.11ms ± 0% -1.02% (p=0.008 n=5+5) GobEncode-8 6.12ms ± 3% 6.07ms ± 1% ~ (p=0.690 n=5+5) Gzip-8 284ms ± 1% 284ms ± 0% ~ (p=1.000 n=5+5) Gunzip-8 40.8ms ± 1% 40.6ms ± 1% ~ (p=0.310 n=5+5) HTTPClientServer-8 69.8µs ± 1% 72.2µs ± 4% ~ (p=0.056 n=5+5) JSONEncode-8 16.1ms ± 2% 16.2ms ± 1% ~ (p=0.151 n=5+5) JSONDecode-8 54.9ms ± 0% 57.0ms ± 1% +3.79% (p=0.008 n=5+5) Mandelbrot200-8 4.35ms ± 0% 4.39ms ± 0% +0.85% (p=0.008 n=5+5) GoParse-8 3.56ms ± 1% 3.42ms ± 1% -4.03% (p=0.008 n=5+5) RegexpMatchEasy0_32-8 75.6ns ± 1% 75.0ns ± 0% -0.83% (p=0.016 n=5+4) RegexpMatchEasy0_1K-8 250ns ± 0% 252ns ± 1% +0.80% (p=0.016 n=4+5) RegexpMatchEasy1_32-8 75.0ns ± 0% 75.4ns ± 2% ~ (p=0.206 n=5+5) RegexpMatchEasy1_1K-8 401ns ± 0% 398ns ± 1% ~ (p=0.056 n=5+5) RegexpMatchMedium_32-8 119ns ± 0% 118ns ± 0% -0.84% (p=0.008 n=5+5) RegexpMatchMedium_1K-8 36.6µs ± 0% 36.9µs ± 0% +0.91% (p=0.008 n=5+5) RegexpMatchHard_32-8 1.95µs ± 1% 1.92µs ± 0% -1.23% (p=0.032 n=5+5) RegexpMatchHard_1K-8 58.3µs ± 1% 58.1µs ± 1% ~ (p=0.548 n=5+5) Revcomp-8 425ms ± 1% 389ms ± 1% -8.39% (p=0.008 n=5+5) Template-8 65.5ms ± 1% 63.6ms ± 1% -2.86% (p=0.008 n=5+5) TimeParse-8 363ns ± 0% 354ns ± 1% -2.59% (p=0.008 n=5+5) TimeFormat-8 363ns ± 0% 364ns ± 1% ~ (p=0.159 n=5+5) Fixes #14511 Change-Id: I1b79d2545271fa90d5b04712cc25573bdc94f2ce Reviewed-on: https://go-review.googlesource.com/20151 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2016-03-02 15:18:40 -08:00
if m != 0 {
s.allocValToReg(v, m, false, b.Pos)
cmd/compile: load some live values into registers before loop If we're about to enter a loop, load values which are live and will soon be used in the loop into registers. name old time/op new time/op delta BinaryTree17-8 2.80s ± 4% 2.62s ± 2% -6.43% (p=0.008 n=5+5) Fannkuch11-8 2.45s ± 2% 2.14s ± 1% -12.43% (p=0.008 n=5+5) FmtFprintfEmpty-8 49.0ns ± 1% 48.4ns ± 1% -1.35% (p=0.032 n=5+5) FmtFprintfString-8 160ns ± 1% 153ns ± 0% -4.63% (p=0.008 n=5+5) FmtFprintfInt-8 152ns ± 0% 150ns ± 0% -1.57% (p=0.000 n=5+4) FmtFprintfIntInt-8 252ns ± 2% 244ns ± 1% -3.02% (p=0.008 n=5+5) FmtFprintfPrefixedInt-8 223ns ± 0% 223ns ± 0% ~ (all samples are equal) FmtFprintfFloat-8 293ns ± 2% 291ns ± 2% ~ (p=0.389 n=5+5) FmtManyArgs-8 956ns ± 0% 936ns ± 0% -2.05% (p=0.008 n=5+5) GobDecode-8 7.18ms ± 0% 7.11ms ± 0% -1.02% (p=0.008 n=5+5) GobEncode-8 6.12ms ± 3% 6.07ms ± 1% ~ (p=0.690 n=5+5) Gzip-8 284ms ± 1% 284ms ± 0% ~ (p=1.000 n=5+5) Gunzip-8 40.8ms ± 1% 40.6ms ± 1% ~ (p=0.310 n=5+5) HTTPClientServer-8 69.8µs ± 1% 72.2µs ± 4% ~ (p=0.056 n=5+5) JSONEncode-8 16.1ms ± 2% 16.2ms ± 1% ~ (p=0.151 n=5+5) JSONDecode-8 54.9ms ± 0% 57.0ms ± 1% +3.79% (p=0.008 n=5+5) Mandelbrot200-8 4.35ms ± 0% 4.39ms ± 0% +0.85% (p=0.008 n=5+5) GoParse-8 3.56ms ± 1% 3.42ms ± 1% -4.03% (p=0.008 n=5+5) RegexpMatchEasy0_32-8 75.6ns ± 1% 75.0ns ± 0% -0.83% (p=0.016 n=5+4) RegexpMatchEasy0_1K-8 250ns ± 0% 252ns ± 1% +0.80% (p=0.016 n=4+5) RegexpMatchEasy1_32-8 75.0ns ± 0% 75.4ns ± 2% ~ (p=0.206 n=5+5) RegexpMatchEasy1_1K-8 401ns ± 0% 398ns ± 1% ~ (p=0.056 n=5+5) RegexpMatchMedium_32-8 119ns ± 0% 118ns ± 0% -0.84% (p=0.008 n=5+5) RegexpMatchMedium_1K-8 36.6µs ± 0% 36.9µs ± 0% +0.91% (p=0.008 n=5+5) RegexpMatchHard_32-8 1.95µs ± 1% 1.92µs ± 0% -1.23% (p=0.032 n=5+5) RegexpMatchHard_1K-8 58.3µs ± 1% 58.1µs ± 1% ~ (p=0.548 n=5+5) Revcomp-8 425ms ± 1% 389ms ± 1% -8.39% (p=0.008 n=5+5) Template-8 65.5ms ± 1% 63.6ms ± 1% -2.86% (p=0.008 n=5+5) TimeParse-8 363ns ± 0% 354ns ± 1% -2.59% (p=0.008 n=5+5) TimeFormat-8 363ns ± 0% 364ns ± 1% ~ (p=0.159 n=5+5) Fixes #14511 Change-Id: I1b79d2545271fa90d5b04712cc25573bdc94f2ce Reviewed-on: https://go-review.googlesource.com/20151 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2016-03-02 15:18:40 -08:00
}
}
}
badloop:
;
// Save end-of-block register state.
// First count how many, this cuts allocations in half.
k := 0
for r := register(0); r < s.numRegs; r++ {
v := s.regs[r].v
if v == nil {
continue
}
k++
}
regList := make([]endReg, 0, k)
for r := register(0); r < s.numRegs; r++ {
v := s.regs[r].v
if v == nil {
continue
}
regList = append(regList, endReg{r, v, s.regs[r].c})
}
s.endRegs[b.ID] = regList
if checkEnabled {
cmd/compile: improve startRegs calculation In register allocation, we calculate what values are used in and after the current block. If a value is used only after a function call, since registers are clobbered in call, we don't need to mark the value live at the entrance of the block. Before this CL it is considered live, and unnecessary copy or load may be generated when resolving merge edge. Fixes #14761. On AMD64: name old time/op new time/op delta BinaryTree17-12 2.84s ± 1% 2.81s ± 1% -1.06% (p=0.000 n=10+9) Fannkuch11-12 3.61s ± 0% 3.55s ± 1% -1.77% (p=0.000 n=10+9) FmtFprintfEmpty-12 50.4ns ± 4% 50.0ns ± 1% ~ (p=0.785 n=9+8) FmtFprintfString-12 80.0ns ± 3% 78.2ns ± 3% -2.35% (p=0.004 n=10+9) FmtFprintfInt-12 81.3ns ± 4% 81.8ns ± 2% ~ (p=0.159 n=10+10) FmtFprintfIntInt-12 120ns ± 4% 118ns ± 2% ~ (p=0.218 n=10+10) FmtFprintfPrefixedInt-12 152ns ± 3% 155ns ± 2% +2.11% (p=0.026 n=10+10) FmtFprintfFloat-12 240ns ± 1% 238ns ± 1% -0.79% (p=0.005 n=9+9) FmtManyArgs-12 504ns ± 1% 510ns ± 1% +1.14% (p=0.000 n=8+9) GobDecode-12 7.00ms ± 1% 6.99ms ± 0% ~ (p=0.497 n=9+10) GobEncode-12 5.47ms ± 1% 5.48ms ± 1% ~ (p=0.218 n=10+10) Gzip-12 258ms ± 2% 256ms ± 1% -0.96% (p=0.043 n=10+9) Gunzip-12 38.6ms ± 0% 38.3ms ± 0% -0.64% (p=0.000 n=9+8) HTTPClientServer-12 90.4µs ± 3% 87.2µs ±11% ~ (p=0.053 n=9+10) JSONEncode-12 15.6ms ± 0% 15.6ms ± 1% ~ (p=0.077 n=9+9) JSONDecode-12 55.1ms ± 1% 54.6ms ± 1% -0.85% (p=0.010 n=10+9) Mandelbrot200-12 4.49ms ± 0% 4.47ms ± 0% -0.25% (p=0.000 n=10+8) GoParse-12 3.38ms ± 0% 3.37ms ± 1% ~ (p=0.315 n=8+10) RegexpMatchEasy0_32-12 82.5ns ± 4% 82.0ns ± 0% ~ (p=0.164 n=10+8) RegexpMatchEasy0_1K-12 203ns ± 1% 202ns ± 1% -0.85% (p=0.000 n=9+10) RegexpMatchEasy1_32-12 82.3ns ± 1% 81.1ns ± 0% -1.39% (p=0.000 n=10+8) RegexpMatchEasy1_1K-12 357ns ± 1% 357ns ± 1% ~ (p=0.697 n=8+9) RegexpMatchMedium_32-12 125ns ± 2% 126ns ± 2% ~ (p=0.197 n=10+10) RegexpMatchMedium_1K-12 39.6µs ± 3% 39.6µs ± 1% ~ (p=0.971 n=10+10) RegexpMatchHard_32-12 1.99µs ± 2% 1.99µs ± 4% ~ (p=0.891 n=10+9) RegexpMatchHard_1K-12 60.1µs ± 3% 60.4µs ± 3% ~ (p=0.684 n=10+10) Revcomp-12 531ms ± 6% 441ms ± 0% -16.94% (p=0.000 n=10+9) Template-12 58.9ms ± 1% 58.7ms ± 1% ~ (p=0.315 n=10+10) TimeParse-12 319ns ± 1% 320ns ± 4% ~ (p=0.215 n=9+9) TimeFormat-12 345ns ± 0% 333ns ± 1% -3.36% (p=0.000 n=9+10) [Geo mean] 52.2µs 51.6µs -1.13% On ARM64: name old time/op new time/op delta BinaryTree17-8 8.53s ± 0% 8.36s ± 0% -1.89% (p=0.000 n=10+10) Fannkuch11-8 6.15s ± 0% 6.10s ± 0% -0.67% (p=0.000 n=10+10) FmtFprintfEmpty-8 117ns ± 0% 117ns ± 0% ~ (all equal) FmtFprintfString-8 192ns ± 0% 192ns ± 0% ~ (all equal) FmtFprintfInt-8 198ns ± 0% 198ns ± 0% ~ (p=0.211 n=10+10) FmtFprintfIntInt-8 289ns ± 0% 291ns ± 0% +0.59% (p=0.000 n=7+10) FmtFprintfPrefixedInt-8 320ns ± 2% 317ns ± 0% ~ (p=0.431 n=10+8) FmtFprintfFloat-8 538ns ± 0% 538ns ± 0% ~ (all equal) FmtManyArgs-8 1.17µs ± 1% 1.18µs ± 1% ~ (p=0.063 n=10+10) GobDecode-8 17.0ms ± 1% 17.2ms ± 1% +0.83% (p=0.000 n=10+10) GobEncode-8 14.2ms ± 0% 14.1ms ± 1% -0.78% (p=0.001 n=9+10) Gzip-8 806ms ± 0% 797ms ± 0% -1.12% (p=0.000 n=6+9) Gunzip-8 131ms ± 0% 130ms ± 0% -0.51% (p=0.000 n=10+9) HTTPClientServer-8 206µs ± 9% 212µs ± 2% ~ (p=0.829 n=10+8) JSONEncode-8 40.1ms ± 0% 40.1ms ± 0% ~ (p=0.136 n=9+9) JSONDecode-8 157ms ± 0% 151ms ± 0% -3.32% (p=0.000 n=9+9) Mandelbrot200-8 10.1ms ± 0% 10.1ms ± 0% -0.05% (p=0.000 n=9+8) GoParse-8 8.43ms ± 0% 8.43ms ± 0% ~ (p=0.912 n=10+10) RegexpMatchEasy0_32-8 228ns ± 1% 227ns ± 0% -0.26% (p=0.026 n=10+9) RegexpMatchEasy0_1K-8 1.92µs ± 0% 1.63µs ± 0% -15.18% (p=0.001 n=7+7) RegexpMatchEasy1_32-8 258ns ± 1% 250ns ± 0% -2.83% (p=0.000 n=10+10) RegexpMatchEasy1_1K-8 2.39µs ± 0% 2.13µs ± 0% -10.94% (p=0.000 n=9+9) RegexpMatchMedium_32-8 352ns ± 0% 351ns ± 0% -0.29% (p=0.004 n=9+10) RegexpMatchMedium_1K-8 104µs ± 0% 105µs ± 0% +0.58% (p=0.000 n=8+9) RegexpMatchHard_32-8 5.84µs ± 0% 5.82µs ± 0% -0.27% (p=0.000 n=9+10) RegexpMatchHard_1K-8 177µs ± 0% 177µs ± 0% -0.07% (p=0.000 n=9+9) Revcomp-8 1.57s ± 1% 1.50s ± 1% -4.60% (p=0.000 n=9+10) Template-8 157ms ± 1% 153ms ± 1% -2.28% (p=0.000 n=10+9) TimeParse-8 779ns ± 1% 770ns ± 1% -1.18% (p=0.013 n=10+10) TimeFormat-8 823ns ± 2% 826ns ± 1% ~ (p=0.324 n=10+9) [Geo mean] 144µs 142µs -1.45% Reduce cmd/go text size by 0.5%. Change-Id: I9288ff983c4a7cf03fc0cb35b9b1750828013117 Reviewed-on: https://go-review.googlesource.com/38457 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2017-03-22 21:34:12 -04:00
regValLiveSet.clear()
for _, x := range s.live[b.ID] {
cmd/compile: improve startRegs calculation In register allocation, we calculate what values are used in and after the current block. If a value is used only after a function call, since registers are clobbered in call, we don't need to mark the value live at the entrance of the block. Before this CL it is considered live, and unnecessary copy or load may be generated when resolving merge edge. Fixes #14761. On AMD64: name old time/op new time/op delta BinaryTree17-12 2.84s ± 1% 2.81s ± 1% -1.06% (p=0.000 n=10+9) Fannkuch11-12 3.61s ± 0% 3.55s ± 1% -1.77% (p=0.000 n=10+9) FmtFprintfEmpty-12 50.4ns ± 4% 50.0ns ± 1% ~ (p=0.785 n=9+8) FmtFprintfString-12 80.0ns ± 3% 78.2ns ± 3% -2.35% (p=0.004 n=10+9) FmtFprintfInt-12 81.3ns ± 4% 81.8ns ± 2% ~ (p=0.159 n=10+10) FmtFprintfIntInt-12 120ns ± 4% 118ns ± 2% ~ (p=0.218 n=10+10) FmtFprintfPrefixedInt-12 152ns ± 3% 155ns ± 2% +2.11% (p=0.026 n=10+10) FmtFprintfFloat-12 240ns ± 1% 238ns ± 1% -0.79% (p=0.005 n=9+9) FmtManyArgs-12 504ns ± 1% 510ns ± 1% +1.14% (p=0.000 n=8+9) GobDecode-12 7.00ms ± 1% 6.99ms ± 0% ~ (p=0.497 n=9+10) GobEncode-12 5.47ms ± 1% 5.48ms ± 1% ~ (p=0.218 n=10+10) Gzip-12 258ms ± 2% 256ms ± 1% -0.96% (p=0.043 n=10+9) Gunzip-12 38.6ms ± 0% 38.3ms ± 0% -0.64% (p=0.000 n=9+8) HTTPClientServer-12 90.4µs ± 3% 87.2µs ±11% ~ (p=0.053 n=9+10) JSONEncode-12 15.6ms ± 0% 15.6ms ± 1% ~ (p=0.077 n=9+9) JSONDecode-12 55.1ms ± 1% 54.6ms ± 1% -0.85% (p=0.010 n=10+9) Mandelbrot200-12 4.49ms ± 0% 4.47ms ± 0% -0.25% (p=0.000 n=10+8) GoParse-12 3.38ms ± 0% 3.37ms ± 1% ~ (p=0.315 n=8+10) RegexpMatchEasy0_32-12 82.5ns ± 4% 82.0ns ± 0% ~ (p=0.164 n=10+8) RegexpMatchEasy0_1K-12 203ns ± 1% 202ns ± 1% -0.85% (p=0.000 n=9+10) RegexpMatchEasy1_32-12 82.3ns ± 1% 81.1ns ± 0% -1.39% (p=0.000 n=10+8) RegexpMatchEasy1_1K-12 357ns ± 1% 357ns ± 1% ~ (p=0.697 n=8+9) RegexpMatchMedium_32-12 125ns ± 2% 126ns ± 2% ~ (p=0.197 n=10+10) RegexpMatchMedium_1K-12 39.6µs ± 3% 39.6µs ± 1% ~ (p=0.971 n=10+10) RegexpMatchHard_32-12 1.99µs ± 2% 1.99µs ± 4% ~ (p=0.891 n=10+9) RegexpMatchHard_1K-12 60.1µs ± 3% 60.4µs ± 3% ~ (p=0.684 n=10+10) Revcomp-12 531ms ± 6% 441ms ± 0% -16.94% (p=0.000 n=10+9) Template-12 58.9ms ± 1% 58.7ms ± 1% ~ (p=0.315 n=10+10) TimeParse-12 319ns ± 1% 320ns ± 4% ~ (p=0.215 n=9+9) TimeFormat-12 345ns ± 0% 333ns ± 1% -3.36% (p=0.000 n=9+10) [Geo mean] 52.2µs 51.6µs -1.13% On ARM64: name old time/op new time/op delta BinaryTree17-8 8.53s ± 0% 8.36s ± 0% -1.89% (p=0.000 n=10+10) Fannkuch11-8 6.15s ± 0% 6.10s ± 0% -0.67% (p=0.000 n=10+10) FmtFprintfEmpty-8 117ns ± 0% 117ns ± 0% ~ (all equal) FmtFprintfString-8 192ns ± 0% 192ns ± 0% ~ (all equal) FmtFprintfInt-8 198ns ± 0% 198ns ± 0% ~ (p=0.211 n=10+10) FmtFprintfIntInt-8 289ns ± 0% 291ns ± 0% +0.59% (p=0.000 n=7+10) FmtFprintfPrefixedInt-8 320ns ± 2% 317ns ± 0% ~ (p=0.431 n=10+8) FmtFprintfFloat-8 538ns ± 0% 538ns ± 0% ~ (all equal) FmtManyArgs-8 1.17µs ± 1% 1.18µs ± 1% ~ (p=0.063 n=10+10) GobDecode-8 17.0ms ± 1% 17.2ms ± 1% +0.83% (p=0.000 n=10+10) GobEncode-8 14.2ms ± 0% 14.1ms ± 1% -0.78% (p=0.001 n=9+10) Gzip-8 806ms ± 0% 797ms ± 0% -1.12% (p=0.000 n=6+9) Gunzip-8 131ms ± 0% 130ms ± 0% -0.51% (p=0.000 n=10+9) HTTPClientServer-8 206µs ± 9% 212µs ± 2% ~ (p=0.829 n=10+8) JSONEncode-8 40.1ms ± 0% 40.1ms ± 0% ~ (p=0.136 n=9+9) JSONDecode-8 157ms ± 0% 151ms ± 0% -3.32% (p=0.000 n=9+9) Mandelbrot200-8 10.1ms ± 0% 10.1ms ± 0% -0.05% (p=0.000 n=9+8) GoParse-8 8.43ms ± 0% 8.43ms ± 0% ~ (p=0.912 n=10+10) RegexpMatchEasy0_32-8 228ns ± 1% 227ns ± 0% -0.26% (p=0.026 n=10+9) RegexpMatchEasy0_1K-8 1.92µs ± 0% 1.63µs ± 0% -15.18% (p=0.001 n=7+7) RegexpMatchEasy1_32-8 258ns ± 1% 250ns ± 0% -2.83% (p=0.000 n=10+10) RegexpMatchEasy1_1K-8 2.39µs ± 0% 2.13µs ± 0% -10.94% (p=0.000 n=9+9) RegexpMatchMedium_32-8 352ns ± 0% 351ns ± 0% -0.29% (p=0.004 n=9+10) RegexpMatchMedium_1K-8 104µs ± 0% 105µs ± 0% +0.58% (p=0.000 n=8+9) RegexpMatchHard_32-8 5.84µs ± 0% 5.82µs ± 0% -0.27% (p=0.000 n=9+10) RegexpMatchHard_1K-8 177µs ± 0% 177µs ± 0% -0.07% (p=0.000 n=9+9) Revcomp-8 1.57s ± 1% 1.50s ± 1% -4.60% (p=0.000 n=9+10) Template-8 157ms ± 1% 153ms ± 1% -2.28% (p=0.000 n=10+9) TimeParse-8 779ns ± 1% 770ns ± 1% -1.18% (p=0.013 n=10+10) TimeFormat-8 823ns ± 2% 826ns ± 1% ~ (p=0.324 n=10+9) [Geo mean] 144µs 142µs -1.45% Reduce cmd/go text size by 0.5%. Change-Id: I9288ff983c4a7cf03fc0cb35b9b1750828013117 Reviewed-on: https://go-review.googlesource.com/38457 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2017-03-22 21:34:12 -04:00
regValLiveSet.add(x.ID)
}
for r := register(0); r < s.numRegs; r++ {
v := s.regs[r].v
if v == nil {
continue
}
cmd/compile: improve startRegs calculation In register allocation, we calculate what values are used in and after the current block. If a value is used only after a function call, since registers are clobbered in call, we don't need to mark the value live at the entrance of the block. Before this CL it is considered live, and unnecessary copy or load may be generated when resolving merge edge. Fixes #14761. On AMD64: name old time/op new time/op delta BinaryTree17-12 2.84s ± 1% 2.81s ± 1% -1.06% (p=0.000 n=10+9) Fannkuch11-12 3.61s ± 0% 3.55s ± 1% -1.77% (p=0.000 n=10+9) FmtFprintfEmpty-12 50.4ns ± 4% 50.0ns ± 1% ~ (p=0.785 n=9+8) FmtFprintfString-12 80.0ns ± 3% 78.2ns ± 3% -2.35% (p=0.004 n=10+9) FmtFprintfInt-12 81.3ns ± 4% 81.8ns ± 2% ~ (p=0.159 n=10+10) FmtFprintfIntInt-12 120ns ± 4% 118ns ± 2% ~ (p=0.218 n=10+10) FmtFprintfPrefixedInt-12 152ns ± 3% 155ns ± 2% +2.11% (p=0.026 n=10+10) FmtFprintfFloat-12 240ns ± 1% 238ns ± 1% -0.79% (p=0.005 n=9+9) FmtManyArgs-12 504ns ± 1% 510ns ± 1% +1.14% (p=0.000 n=8+9) GobDecode-12 7.00ms ± 1% 6.99ms ± 0% ~ (p=0.497 n=9+10) GobEncode-12 5.47ms ± 1% 5.48ms ± 1% ~ (p=0.218 n=10+10) Gzip-12 258ms ± 2% 256ms ± 1% -0.96% (p=0.043 n=10+9) Gunzip-12 38.6ms ± 0% 38.3ms ± 0% -0.64% (p=0.000 n=9+8) HTTPClientServer-12 90.4µs ± 3% 87.2µs ±11% ~ (p=0.053 n=9+10) JSONEncode-12 15.6ms ± 0% 15.6ms ± 1% ~ (p=0.077 n=9+9) JSONDecode-12 55.1ms ± 1% 54.6ms ± 1% -0.85% (p=0.010 n=10+9) Mandelbrot200-12 4.49ms ± 0% 4.47ms ± 0% -0.25% (p=0.000 n=10+8) GoParse-12 3.38ms ± 0% 3.37ms ± 1% ~ (p=0.315 n=8+10) RegexpMatchEasy0_32-12 82.5ns ± 4% 82.0ns ± 0% ~ (p=0.164 n=10+8) RegexpMatchEasy0_1K-12 203ns ± 1% 202ns ± 1% -0.85% (p=0.000 n=9+10) RegexpMatchEasy1_32-12 82.3ns ± 1% 81.1ns ± 0% -1.39% (p=0.000 n=10+8) RegexpMatchEasy1_1K-12 357ns ± 1% 357ns ± 1% ~ (p=0.697 n=8+9) RegexpMatchMedium_32-12 125ns ± 2% 126ns ± 2% ~ (p=0.197 n=10+10) RegexpMatchMedium_1K-12 39.6µs ± 3% 39.6µs ± 1% ~ (p=0.971 n=10+10) RegexpMatchHard_32-12 1.99µs ± 2% 1.99µs ± 4% ~ (p=0.891 n=10+9) RegexpMatchHard_1K-12 60.1µs ± 3% 60.4µs ± 3% ~ (p=0.684 n=10+10) Revcomp-12 531ms ± 6% 441ms ± 0% -16.94% (p=0.000 n=10+9) Template-12 58.9ms ± 1% 58.7ms ± 1% ~ (p=0.315 n=10+10) TimeParse-12 319ns ± 1% 320ns ± 4% ~ (p=0.215 n=9+9) TimeFormat-12 345ns ± 0% 333ns ± 1% -3.36% (p=0.000 n=9+10) [Geo mean] 52.2µs 51.6µs -1.13% On ARM64: name old time/op new time/op delta BinaryTree17-8 8.53s ± 0% 8.36s ± 0% -1.89% (p=0.000 n=10+10) Fannkuch11-8 6.15s ± 0% 6.10s ± 0% -0.67% (p=0.000 n=10+10) FmtFprintfEmpty-8 117ns ± 0% 117ns ± 0% ~ (all equal) FmtFprintfString-8 192ns ± 0% 192ns ± 0% ~ (all equal) FmtFprintfInt-8 198ns ± 0% 198ns ± 0% ~ (p=0.211 n=10+10) FmtFprintfIntInt-8 289ns ± 0% 291ns ± 0% +0.59% (p=0.000 n=7+10) FmtFprintfPrefixedInt-8 320ns ± 2% 317ns ± 0% ~ (p=0.431 n=10+8) FmtFprintfFloat-8 538ns ± 0% 538ns ± 0% ~ (all equal) FmtManyArgs-8 1.17µs ± 1% 1.18µs ± 1% ~ (p=0.063 n=10+10) GobDecode-8 17.0ms ± 1% 17.2ms ± 1% +0.83% (p=0.000 n=10+10) GobEncode-8 14.2ms ± 0% 14.1ms ± 1% -0.78% (p=0.001 n=9+10) Gzip-8 806ms ± 0% 797ms ± 0% -1.12% (p=0.000 n=6+9) Gunzip-8 131ms ± 0% 130ms ± 0% -0.51% (p=0.000 n=10+9) HTTPClientServer-8 206µs ± 9% 212µs ± 2% ~ (p=0.829 n=10+8) JSONEncode-8 40.1ms ± 0% 40.1ms ± 0% ~ (p=0.136 n=9+9) JSONDecode-8 157ms ± 0% 151ms ± 0% -3.32% (p=0.000 n=9+9) Mandelbrot200-8 10.1ms ± 0% 10.1ms ± 0% -0.05% (p=0.000 n=9+8) GoParse-8 8.43ms ± 0% 8.43ms ± 0% ~ (p=0.912 n=10+10) RegexpMatchEasy0_32-8 228ns ± 1% 227ns ± 0% -0.26% (p=0.026 n=10+9) RegexpMatchEasy0_1K-8 1.92µs ± 0% 1.63µs ± 0% -15.18% (p=0.001 n=7+7) RegexpMatchEasy1_32-8 258ns ± 1% 250ns ± 0% -2.83% (p=0.000 n=10+10) RegexpMatchEasy1_1K-8 2.39µs ± 0% 2.13µs ± 0% -10.94% (p=0.000 n=9+9) RegexpMatchMedium_32-8 352ns ± 0% 351ns ± 0% -0.29% (p=0.004 n=9+10) RegexpMatchMedium_1K-8 104µs ± 0% 105µs ± 0% +0.58% (p=0.000 n=8+9) RegexpMatchHard_32-8 5.84µs ± 0% 5.82µs ± 0% -0.27% (p=0.000 n=9+10) RegexpMatchHard_1K-8 177µs ± 0% 177µs ± 0% -0.07% (p=0.000 n=9+9) Revcomp-8 1.57s ± 1% 1.50s ± 1% -4.60% (p=0.000 n=9+10) Template-8 157ms ± 1% 153ms ± 1% -2.28% (p=0.000 n=10+9) TimeParse-8 779ns ± 1% 770ns ± 1% -1.18% (p=0.013 n=10+10) TimeFormat-8 823ns ± 2% 826ns ± 1% ~ (p=0.324 n=10+9) [Geo mean] 144µs 142µs -1.45% Reduce cmd/go text size by 0.5%. Change-Id: I9288ff983c4a7cf03fc0cb35b9b1750828013117 Reviewed-on: https://go-review.googlesource.com/38457 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2017-03-22 21:34:12 -04:00
if !regValLiveSet.contains(v.ID) {
s.f.Fatalf("val %s is in reg but not live at end of %s", v, b)
}
}
}
// If a value is live at the end of the block and
cmd/compile: put spills in better places Previously we always issued a spill right after the op that was being spilled. This CL pushes spills father away from the generator, hopefully pushing them into unlikely branches. For example: x = ... if unlikely { call ... } ... use x ... Used to compile to x = ... spill x if unlikely { call ... restore x } It now compiles to x = ... if unlikely { spill x call ... restore x } This is particularly useful for code which appends, as the only call is an unlikely call to growslice. It also helps for the spills needed around write barrier calls. The basic algorithm is walk down the dominator tree following a path where the block still dominates all of the restores. We're looking for a block that: 1) dominates all restores 2) has the value being spilled in a register 3) has a loop depth no deeper than the value being spilled The walking-down code is iterative. I was forced to limit it to searching 100 blocks so it doesn't become O(n^2). Maybe one day we'll find a better way. I had to delete most of David's code which pushed spills out of loops. I suspect this CL subsumes most of the cases that his code handled. Generally positive performance improvements, but hard to tell for sure with all the noise. (compilebench times are unchanged.) name old time/op new time/op delta BinaryTree17-12 2.91s ±15% 2.80s ±12% ~ (p=0.063 n=10+10) Fannkuch11-12 3.47s ± 0% 3.30s ± 4% -4.91% (p=0.000 n=9+10) FmtFprintfEmpty-12 48.0ns ± 1% 47.4ns ± 1% -1.32% (p=0.002 n=9+9) FmtFprintfString-12 85.6ns ±11% 79.4ns ± 3% -7.27% (p=0.005 n=10+10) FmtFprintfInt-12 91.8ns ±10% 85.9ns ± 4% ~ (p=0.203 n=10+9) FmtFprintfIntInt-12 135ns ±13% 127ns ± 1% -5.72% (p=0.025 n=10+9) FmtFprintfPrefixedInt-12 167ns ± 1% 168ns ± 2% ~ (p=0.580 n=9+10) FmtFprintfFloat-12 249ns ±11% 230ns ± 1% -7.32% (p=0.000 n=10+10) FmtManyArgs-12 504ns ± 7% 506ns ± 1% ~ (p=0.198 n=9+9) GobDecode-12 6.95ms ± 1% 7.04ms ± 1% +1.37% (p=0.001 n=10+10) GobEncode-12 6.32ms ±13% 6.04ms ± 1% ~ (p=0.063 n=10+10) Gzip-12 233ms ± 1% 235ms ± 0% +1.01% (p=0.000 n=10+9) Gunzip-12 40.1ms ± 1% 39.6ms ± 0% -1.12% (p=0.000 n=10+8) HTTPClientServer-12 227µs ± 9% 221µs ± 5% ~ (p=0.114 n=9+8) JSONEncode-12 16.1ms ± 2% 15.8ms ± 1% -2.09% (p=0.002 n=9+8) JSONDecode-12 61.8ms ±11% 57.9ms ± 1% -6.30% (p=0.000 n=10+9) Mandelbrot200-12 4.30ms ± 3% 4.28ms ± 1% ~ (p=0.203 n=10+8) GoParse-12 3.18ms ± 2% 3.18ms ± 2% ~ (p=0.579 n=10+10) RegexpMatchEasy0_32-12 76.7ns ± 1% 77.5ns ± 1% +0.92% (p=0.002 n=9+8) RegexpMatchEasy0_1K-12 239ns ± 3% 239ns ± 1% ~ (p=0.204 n=10+10) RegexpMatchEasy1_32-12 71.4ns ± 1% 70.6ns ± 0% -1.15% (p=0.000 n=10+9) RegexpMatchEasy1_1K-12 383ns ± 2% 390ns ±10% ~ (p=0.181 n=8+9) RegexpMatchMedium_32-12 114ns ± 0% 113ns ± 1% -0.88% (p=0.000 n=9+8) RegexpMatchMedium_1K-12 36.3µs ± 1% 36.8µs ± 1% +1.59% (p=0.000 n=10+8) RegexpMatchHard_32-12 1.90µs ± 1% 1.90µs ± 1% ~ (p=0.341 n=10+10) RegexpMatchHard_1K-12 59.4µs ±11% 57.8µs ± 1% ~ (p=0.968 n=10+9) Revcomp-12 461ms ± 1% 462ms ± 1% ~ (p=1.000 n=9+9) Template-12 67.5ms ± 1% 66.3ms ± 1% -1.77% (p=0.000 n=10+8) TimeParse-12 314ns ± 3% 309ns ± 0% -1.56% (p=0.000 n=9+8) TimeFormat-12 340ns ± 2% 331ns ± 1% -2.79% (p=0.000 n=10+10) The go binary is 0.2% larger. Not really sure why the size would change. Change-Id: Ia5116e53a3aeb025ef350ffc51c14ae5cc17871c Reviewed-on: https://go-review.googlesource.com/34822 Reviewed-by: David Chase <drchase@google.com>
2017-03-07 14:45:46 -05:00
// isn't in a register, generate a use for the spill location.
// We need to remember this information so that
// the liveness analysis in stackalloc is correct.
for _, e := range s.live[b.ID] {
cmd/compile: put spills in better places Previously we always issued a spill right after the op that was being spilled. This CL pushes spills father away from the generator, hopefully pushing them into unlikely branches. For example: x = ... if unlikely { call ... } ... use x ... Used to compile to x = ... spill x if unlikely { call ... restore x } It now compiles to x = ... if unlikely { spill x call ... restore x } This is particularly useful for code which appends, as the only call is an unlikely call to growslice. It also helps for the spills needed around write barrier calls. The basic algorithm is walk down the dominator tree following a path where the block still dominates all of the restores. We're looking for a block that: 1) dominates all restores 2) has the value being spilled in a register 3) has a loop depth no deeper than the value being spilled The walking-down code is iterative. I was forced to limit it to searching 100 blocks so it doesn't become O(n^2). Maybe one day we'll find a better way. I had to delete most of David's code which pushed spills out of loops. I suspect this CL subsumes most of the cases that his code handled. Generally positive performance improvements, but hard to tell for sure with all the noise. (compilebench times are unchanged.) name old time/op new time/op delta BinaryTree17-12 2.91s ±15% 2.80s ±12% ~ (p=0.063 n=10+10) Fannkuch11-12 3.47s ± 0% 3.30s ± 4% -4.91% (p=0.000 n=9+10) FmtFprintfEmpty-12 48.0ns ± 1% 47.4ns ± 1% -1.32% (p=0.002 n=9+9) FmtFprintfString-12 85.6ns ±11% 79.4ns ± 3% -7.27% (p=0.005 n=10+10) FmtFprintfInt-12 91.8ns ±10% 85.9ns ± 4% ~ (p=0.203 n=10+9) FmtFprintfIntInt-12 135ns ±13% 127ns ± 1% -5.72% (p=0.025 n=10+9) FmtFprintfPrefixedInt-12 167ns ± 1% 168ns ± 2% ~ (p=0.580 n=9+10) FmtFprintfFloat-12 249ns ±11% 230ns ± 1% -7.32% (p=0.000 n=10+10) FmtManyArgs-12 504ns ± 7% 506ns ± 1% ~ (p=0.198 n=9+9) GobDecode-12 6.95ms ± 1% 7.04ms ± 1% +1.37% (p=0.001 n=10+10) GobEncode-12 6.32ms ±13% 6.04ms ± 1% ~ (p=0.063 n=10+10) Gzip-12 233ms ± 1% 235ms ± 0% +1.01% (p=0.000 n=10+9) Gunzip-12 40.1ms ± 1% 39.6ms ± 0% -1.12% (p=0.000 n=10+8) HTTPClientServer-12 227µs ± 9% 221µs ± 5% ~ (p=0.114 n=9+8) JSONEncode-12 16.1ms ± 2% 15.8ms ± 1% -2.09% (p=0.002 n=9+8) JSONDecode-12 61.8ms ±11% 57.9ms ± 1% -6.30% (p=0.000 n=10+9) Mandelbrot200-12 4.30ms ± 3% 4.28ms ± 1% ~ (p=0.203 n=10+8) GoParse-12 3.18ms ± 2% 3.18ms ± 2% ~ (p=0.579 n=10+10) RegexpMatchEasy0_32-12 76.7ns ± 1% 77.5ns ± 1% +0.92% (p=0.002 n=9+8) RegexpMatchEasy0_1K-12 239ns ± 3% 239ns ± 1% ~ (p=0.204 n=10+10) RegexpMatchEasy1_32-12 71.4ns ± 1% 70.6ns ± 0% -1.15% (p=0.000 n=10+9) RegexpMatchEasy1_1K-12 383ns ± 2% 390ns ±10% ~ (p=0.181 n=8+9) RegexpMatchMedium_32-12 114ns ± 0% 113ns ± 1% -0.88% (p=0.000 n=9+8) RegexpMatchMedium_1K-12 36.3µs ± 1% 36.8µs ± 1% +1.59% (p=0.000 n=10+8) RegexpMatchHard_32-12 1.90µs ± 1% 1.90µs ± 1% ~ (p=0.341 n=10+10) RegexpMatchHard_1K-12 59.4µs ±11% 57.8µs ± 1% ~ (p=0.968 n=10+9) Revcomp-12 461ms ± 1% 462ms ± 1% ~ (p=1.000 n=9+9) Template-12 67.5ms ± 1% 66.3ms ± 1% -1.77% (p=0.000 n=10+8) TimeParse-12 314ns ± 3% 309ns ± 0% -1.56% (p=0.000 n=9+8) TimeFormat-12 340ns ± 2% 331ns ± 1% -2.79% (p=0.000 n=10+10) The go binary is 0.2% larger. Not really sure why the size would change. Change-Id: Ia5116e53a3aeb025ef350ffc51c14ae5cc17871c Reviewed-on: https://go-review.googlesource.com/34822 Reviewed-by: David Chase <drchase@google.com>
2017-03-07 14:45:46 -05:00
vi := &s.values[e.ID]
if vi.regs != 0 {
// in a register, we'll use that source for the merge.
continue
}
cmd/compile: put spills in better places Previously we always issued a spill right after the op that was being spilled. This CL pushes spills father away from the generator, hopefully pushing them into unlikely branches. For example: x = ... if unlikely { call ... } ... use x ... Used to compile to x = ... spill x if unlikely { call ... restore x } It now compiles to x = ... if unlikely { spill x call ... restore x } This is particularly useful for code which appends, as the only call is an unlikely call to growslice. It also helps for the spills needed around write barrier calls. The basic algorithm is walk down the dominator tree following a path where the block still dominates all of the restores. We're looking for a block that: 1) dominates all restores 2) has the value being spilled in a register 3) has a loop depth no deeper than the value being spilled The walking-down code is iterative. I was forced to limit it to searching 100 blocks so it doesn't become O(n^2). Maybe one day we'll find a better way. I had to delete most of David's code which pushed spills out of loops. I suspect this CL subsumes most of the cases that his code handled. Generally positive performance improvements, but hard to tell for sure with all the noise. (compilebench times are unchanged.) name old time/op new time/op delta BinaryTree17-12 2.91s ±15% 2.80s ±12% ~ (p=0.063 n=10+10) Fannkuch11-12 3.47s ± 0% 3.30s ± 4% -4.91% (p=0.000 n=9+10) FmtFprintfEmpty-12 48.0ns ± 1% 47.4ns ± 1% -1.32% (p=0.002 n=9+9) FmtFprintfString-12 85.6ns ±11% 79.4ns ± 3% -7.27% (p=0.005 n=10+10) FmtFprintfInt-12 91.8ns ±10% 85.9ns ± 4% ~ (p=0.203 n=10+9) FmtFprintfIntInt-12 135ns ±13% 127ns ± 1% -5.72% (p=0.025 n=10+9) FmtFprintfPrefixedInt-12 167ns ± 1% 168ns ± 2% ~ (p=0.580 n=9+10) FmtFprintfFloat-12 249ns ±11% 230ns ± 1% -7.32% (p=0.000 n=10+10) FmtManyArgs-12 504ns ± 7% 506ns ± 1% ~ (p=0.198 n=9+9) GobDecode-12 6.95ms ± 1% 7.04ms ± 1% +1.37% (p=0.001 n=10+10) GobEncode-12 6.32ms ±13% 6.04ms ± 1% ~ (p=0.063 n=10+10) Gzip-12 233ms ± 1% 235ms ± 0% +1.01% (p=0.000 n=10+9) Gunzip-12 40.1ms ± 1% 39.6ms ± 0% -1.12% (p=0.000 n=10+8) HTTPClientServer-12 227µs ± 9% 221µs ± 5% ~ (p=0.114 n=9+8) JSONEncode-12 16.1ms ± 2% 15.8ms ± 1% -2.09% (p=0.002 n=9+8) JSONDecode-12 61.8ms ±11% 57.9ms ± 1% -6.30% (p=0.000 n=10+9) Mandelbrot200-12 4.30ms ± 3% 4.28ms ± 1% ~ (p=0.203 n=10+8) GoParse-12 3.18ms ± 2% 3.18ms ± 2% ~ (p=0.579 n=10+10) RegexpMatchEasy0_32-12 76.7ns ± 1% 77.5ns ± 1% +0.92% (p=0.002 n=9+8) RegexpMatchEasy0_1K-12 239ns ± 3% 239ns ± 1% ~ (p=0.204 n=10+10) RegexpMatchEasy1_32-12 71.4ns ± 1% 70.6ns ± 0% -1.15% (p=0.000 n=10+9) RegexpMatchEasy1_1K-12 383ns ± 2% 390ns ±10% ~ (p=0.181 n=8+9) RegexpMatchMedium_32-12 114ns ± 0% 113ns ± 1% -0.88% (p=0.000 n=9+8) RegexpMatchMedium_1K-12 36.3µs ± 1% 36.8µs ± 1% +1.59% (p=0.000 n=10+8) RegexpMatchHard_32-12 1.90µs ± 1% 1.90µs ± 1% ~ (p=0.341 n=10+10) RegexpMatchHard_1K-12 59.4µs ±11% 57.8µs ± 1% ~ (p=0.968 n=10+9) Revcomp-12 461ms ± 1% 462ms ± 1% ~ (p=1.000 n=9+9) Template-12 67.5ms ± 1% 66.3ms ± 1% -1.77% (p=0.000 n=10+8) TimeParse-12 314ns ± 3% 309ns ± 0% -1.56% (p=0.000 n=9+8) TimeFormat-12 340ns ± 2% 331ns ± 1% -2.79% (p=0.000 n=10+10) The go binary is 0.2% larger. Not really sure why the size would change. Change-Id: Ia5116e53a3aeb025ef350ffc51c14ae5cc17871c Reviewed-on: https://go-review.googlesource.com/34822 Reviewed-by: David Chase <drchase@google.com>
2017-03-07 14:45:46 -05:00
if vi.rematerializeable {
// we'll rematerialize during the merge.
continue
}
cmd/compile: use desired info when allocating registers for live values When allocting registers for live values, use desired register if available, this is helpful for some cases, such as (*entry).delete, which can save a few of copies. Besides, this patch allows more debugging information to be printed out. Test results of compilecmp on Linux/amd64: name old time/op new time/op delta Template 326729362.060000ns +- 3% 329227238.775510ns +- 4% +0.76% (p=0.038 n=50+49) Unicode 157671860.391304ns +- 6% 156917927.320000ns +- 6% ~ (p=0.291 n=46+50) GoTypes 1065591138.304348ns +- 2% 1063695977.434783ns +- 1% ~ (p=0.208 n=46+46) Compiler 5053424790.760001ns +- 2% 5052729636.551020ns +- 3% ~ (p=0.908 n=50+49) SSA 12392067635.866669ns +- 2% 12319786960.460005ns +- 2% -0.58% (p=0.008 n=45+50) Flate 212609767.340000ns +- 5% 213011228.085106ns +- 5% ~ (p=0.685 n=50+47) GoParser 266870495.100000ns +- 4% 266962314.280000ns +- 3% ~ (p=0.975 n=50+50) Reflect 660164306.551021ns +- 2% 658284470.729167ns +- 2% ~ (p=0.069 n=49+48) Tar 292805895.720000ns +- 4% 292103626.954545ns +- 2% ~ (p=0.321 n=50+44) XML 386294811.700000ns +- 4% 386665088.820000ns +- 4% ~ (p=0.786 n=50+50) LinkCompiler 548495788.659575ns +- 5% 549359489.102041ns +- 4% ~ (p=0.855 n=47+49) ExternalLinkCompiler 1810414270.280000ns +- 2% 1806872224.673470ns +- 2% ~ (p=0.313 n=50+49) LinkWithoutDebugCompiler 340888843.795918ns +- 5% 340341541.100000ns +- 6% ~ (p=0.735 n=49+50) [Geo mean] 664550174.613777ns 664090221.153575ns -0.07% name old user-time/op new user-time/op delta Template 565202800.000000ns +-16% 595351040.000000ns +-16% +5.33% (p=0.001 n=50+50) Unicode 378444740.000000ns +-14% 373825183.673469ns +-17% ~ (p=0.458 n=50+49) GoTypes 2052073341.463415ns +-12% 2059679864.864865ns +- 7% ~ (p=0.381 n=41+37) Compiler 9913371980.000000ns +-20% 9848836720.000002ns +-19% ~ (p=0.781 n=50+50) SSA 25013846224.489799ns +-17% 24571896183.673466ns +-17% ~ (p=0.132 n=49+49) Flate 314422702.127660ns +-17% 314831666.666667ns +-11% ~ (p=0.427 n=47+45) GoParser 419496060.000000ns +- 9% 417403460.000000ns +-11% ~ (p=0.512 n=50+50) Reflect 1233632469.387755ns +-17% 1193061073.170732ns +-13% -3.29% (p=0.030 n=49+41) Tar 509855937.500000ns +-10% 508700740.000000ns +-14% ~ (p=0.890 n=48+50) XML 703511425.531915ns +-12% 694007591.836735ns +-11% ~ (p=0.164 n=47+49) LinkCompiler 993137687.500000ns +- 6% 991914714.285714ns +- 8% ~ (p=0.860 n=48+49) ExternalLinkCompiler 2193851840.000001ns +- 3% 2186672183.673470ns +- 5% ~ (p=0.320 n=50+49) LinkWithoutDebugCompiler 420800875.000000ns +-10% 422062640.000000ns +- 9% ~ (p=0.840 n=48+50) [Geo mean] 1145156131.480097ns 1142033233.550961ns -0.27% name old alloc/op new alloc/op delta Template 36.3MB +- 0% 36.3MB +- 0% ~ (p=0.886 n=50+49) Unicode 30.1MB +- 0% 30.1MB +- 0% ~ (p=0.792 n=50+50) GoTypes 118MB +- 0% 118MB +- 0% ~ (p=1.000 n=47+48) Compiler 562MB +- 0% 562MB +- 0% ~ (p=0.205 n=50+49) SSA 1.42GB +- 0% 1.42GB +- 0% -0.12% (p=0.000 n=50+50) Flate 22.8MB +- 0% 22.8MB +- 0% ~ (p=0.384 n=50+47) GoParser 28.0MB +- 0% 28.0MB +- 0% -0.02% (p=0.013 n=50+50) Reflect 78.0MB +- 0% 78.0MB +- 0% ~ (p=0.384 n=46+48) Tar 34.1MB +- 0% 34.1MB +- 0% ~ (p=0.072 n=50+50) XML 43.1MB +- 0% 43.1MB +- 0% -0.04% (p=0.000 n=49+50) LinkCompiler 98.5MB +- 0% 98.5MB +- 0% +0.01% (p=0.012 n=50+43) ExternalLinkCompiler 89.6MB +- 0% 89.6MB +- 0% ~ (p=0.762 n=50+50) LinkWithoutDebugCompiler 56.9MB +- 0% 56.9MB +- 0% ~ (p=0.268 n=49+48) [Geo mean] 77.7MB 77.7MB -0.01% name old allocs/op new allocs/op delta Template 367k +- 0% 367k +- 0% -0.01% (p=0.002 n=50+49) Unicode 345k +- 0% 345k +- 0% ~ (p=0.981 n=50+50) GoTypes 1.28M +- 0% 1.28M +- 0% -0.00% (p=0.002 n=49+50) Compiler 5.39M +- 0% 5.39M +- 0% -0.00% (p=0.000 n=50+50) SSA 13.9M +- 0% 13.9M +- 0% +0.01% (p=0.000 n=50+50) Flate 230k +- 0% 230k +- 0% ~ (p=0.815 n=50+50) GoParser 292k +- 0% 292k +- 0% -0.01% (p=0.000 n=50+50) Reflect 977k +- 0% 977k +- 0% -0.00% (p=0.035 n=50+50) Tar 343k +- 0% 343k +- 0% -0.01% (p=0.008 n=48+50) XML 418k +- 0% 418k +- 0% -0.01% (p=0.000 n=50+50) LinkCompiler 516k +- 0% 516k +- 0% +0.01% (p=0.002 n=50+48) ExternalLinkCompiler 570k +- 0% 570k +- 0% ~ (p=0.430 n=46+50) LinkWithoutDebugCompiler 169k +- 0% 169k +- 0% ~ (p=0.706 n=49+49) [Geo mean] 672k 672k -0.00% name old maxRSS/op new maxRSS/op delta Template 34.3M +- 5% 34.7M +- 4% +1.24% (p=0.004 n=50+50) Unicode 36.2M +- 5% 36.1M +- 8% ~ (p=0.785 n=50+50) GoTypes 75.7M +- 7% 76.1M +- 6% ~ (p=0.544 n=50+50) Compiler 304M +- 7% 304M +- 7% ~ (p=0.744 n=50+50) SSA 721M +- 6% 723M +- 7% ~ (p=0.724 n=49+50) Flate 26.1M +- 3% 26.1M +- 5% ~ (p=0.649 n=48+49) GoParser 29.3M +- 5% 29.3M +- 4% ~ (p=0.809 n=50+50) Reflect 56.0M +- 6% 56.3M +- 5% ~ (p=0.350 n=50+50) Tar 34.1M +- 3% 33.9M +- 5% ~ (p=0.121 n=49+50) XML 39.6M +- 5% 39.9M +- 4% ~ (p=0.109 n=50+50) LinkCompiler 168M +- 1% 168M +- 1% ~ (p=0.578 n=49+48) ExternalLinkCompiler 179M +- 1% 179M +- 2% ~ (p=0.522 n=46+46) LinkWithoutDebugCompiler 137M +- 3% 137M +- 3% ~ (p=0.463 n=41+50) [Geo mean] 79.3M 79.5M +0.20% name old text-bytes new text-bytes delta HelloSize 812kB +- 0% 811kB +- 0% -0.05% (p=0.000 n=50+50) name old data-bytes new data-bytes delta HelloSize 13.3kB +- 0% 13.3kB +- 0% ~ (all equal) name old bss-bytes new bss-bytes delta HelloSize 206kB +- 0% 206kB +- 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 1.21MB +- 0% 1.21MB +- 0% +0.02% (p=0.000 n=50+50) file before after Δ % addr2line 4052949 4052453 -496 -0.012% api 4948171 4947163 -1008 -0.020% asm 4888889 4888049 -840 -0.017% buildid 2617545 2617673 +128 +0.005% cgo 4521681 4516801 -4880 -0.108% compile 19139091 19137683 -1408 -0.007% cover 4843191 4840359 -2832 -0.058% dist 3473677 3474717 +1040 +0.030% doc 3821592 3821552 -40 -0.001% fix 3220587 3220059 -528 -0.016% link 6587368 6582696 -4672 -0.071% nm 3999858 3999186 -672 -0.017% objdump 4409161 4408217 -944 -0.021% pack 2394038 2393846 -192 -0.008% pprof 13601271 13602487 +1216 +0.009% test2json 2645148 2644604 -544 -0.021% trace 10357878 10356862 -1016 -0.010% vet 6779482 6778706 -776 -0.011% total 106301577 106283113 -18464 -0.017% Change-Id: I63ac6e224e1a4756ddc1bfc4aabbaeb92d7d4273 Reviewed-on: https://go-review.googlesource.com/c/go/+/263599 Run-TryBot: eric fang <eric.fang@arm.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: eric fang <eric.fang@arm.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2020-10-19 03:57:15 +00:00
if s.f.pass.debug > regDebug {
fmt.Printf("live-at-end spill for %s at %s\n", s.orig[e.ID], b)
}
cmd/compile: put spills in better places Previously we always issued a spill right after the op that was being spilled. This CL pushes spills father away from the generator, hopefully pushing them into unlikely branches. For example: x = ... if unlikely { call ... } ... use x ... Used to compile to x = ... spill x if unlikely { call ... restore x } It now compiles to x = ... if unlikely { spill x call ... restore x } This is particularly useful for code which appends, as the only call is an unlikely call to growslice. It also helps for the spills needed around write barrier calls. The basic algorithm is walk down the dominator tree following a path where the block still dominates all of the restores. We're looking for a block that: 1) dominates all restores 2) has the value being spilled in a register 3) has a loop depth no deeper than the value being spilled The walking-down code is iterative. I was forced to limit it to searching 100 blocks so it doesn't become O(n^2). Maybe one day we'll find a better way. I had to delete most of David's code which pushed spills out of loops. I suspect this CL subsumes most of the cases that his code handled. Generally positive performance improvements, but hard to tell for sure with all the noise. (compilebench times are unchanged.) name old time/op new time/op delta BinaryTree17-12 2.91s ±15% 2.80s ±12% ~ (p=0.063 n=10+10) Fannkuch11-12 3.47s ± 0% 3.30s ± 4% -4.91% (p=0.000 n=9+10) FmtFprintfEmpty-12 48.0ns ± 1% 47.4ns ± 1% -1.32% (p=0.002 n=9+9) FmtFprintfString-12 85.6ns ±11% 79.4ns ± 3% -7.27% (p=0.005 n=10+10) FmtFprintfInt-12 91.8ns ±10% 85.9ns ± 4% ~ (p=0.203 n=10+9) FmtFprintfIntInt-12 135ns ±13% 127ns ± 1% -5.72% (p=0.025 n=10+9) FmtFprintfPrefixedInt-12 167ns ± 1% 168ns ± 2% ~ (p=0.580 n=9+10) FmtFprintfFloat-12 249ns ±11% 230ns ± 1% -7.32% (p=0.000 n=10+10) FmtManyArgs-12 504ns ± 7% 506ns ± 1% ~ (p=0.198 n=9+9) GobDecode-12 6.95ms ± 1% 7.04ms ± 1% +1.37% (p=0.001 n=10+10) GobEncode-12 6.32ms ±13% 6.04ms ± 1% ~ (p=0.063 n=10+10) Gzip-12 233ms ± 1% 235ms ± 0% +1.01% (p=0.000 n=10+9) Gunzip-12 40.1ms ± 1% 39.6ms ± 0% -1.12% (p=0.000 n=10+8) HTTPClientServer-12 227µs ± 9% 221µs ± 5% ~ (p=0.114 n=9+8) JSONEncode-12 16.1ms ± 2% 15.8ms ± 1% -2.09% (p=0.002 n=9+8) JSONDecode-12 61.8ms ±11% 57.9ms ± 1% -6.30% (p=0.000 n=10+9) Mandelbrot200-12 4.30ms ± 3% 4.28ms ± 1% ~ (p=0.203 n=10+8) GoParse-12 3.18ms ± 2% 3.18ms ± 2% ~ (p=0.579 n=10+10) RegexpMatchEasy0_32-12 76.7ns ± 1% 77.5ns ± 1% +0.92% (p=0.002 n=9+8) RegexpMatchEasy0_1K-12 239ns ± 3% 239ns ± 1% ~ (p=0.204 n=10+10) RegexpMatchEasy1_32-12 71.4ns ± 1% 70.6ns ± 0% -1.15% (p=0.000 n=10+9) RegexpMatchEasy1_1K-12 383ns ± 2% 390ns ±10% ~ (p=0.181 n=8+9) RegexpMatchMedium_32-12 114ns ± 0% 113ns ± 1% -0.88% (p=0.000 n=9+8) RegexpMatchMedium_1K-12 36.3µs ± 1% 36.8µs ± 1% +1.59% (p=0.000 n=10+8) RegexpMatchHard_32-12 1.90µs ± 1% 1.90µs ± 1% ~ (p=0.341 n=10+10) RegexpMatchHard_1K-12 59.4µs ±11% 57.8µs ± 1% ~ (p=0.968 n=10+9) Revcomp-12 461ms ± 1% 462ms ± 1% ~ (p=1.000 n=9+9) Template-12 67.5ms ± 1% 66.3ms ± 1% -1.77% (p=0.000 n=10+8) TimeParse-12 314ns ± 3% 309ns ± 0% -1.56% (p=0.000 n=9+8) TimeFormat-12 340ns ± 2% 331ns ± 1% -2.79% (p=0.000 n=10+10) The go binary is 0.2% larger. Not really sure why the size would change. Change-Id: Ia5116e53a3aeb025ef350ffc51c14ae5cc17871c Reviewed-on: https://go-review.googlesource.com/34822 Reviewed-by: David Chase <drchase@google.com>
2017-03-07 14:45:46 -05:00
spill := s.makeSpill(s.orig[e.ID], b)
s.spillLive[b.ID] = append(s.spillLive[b.ID], spill.ID)
cmd/compile: put spills in better places Previously we always issued a spill right after the op that was being spilled. This CL pushes spills father away from the generator, hopefully pushing them into unlikely branches. For example: x = ... if unlikely { call ... } ... use x ... Used to compile to x = ... spill x if unlikely { call ... restore x } It now compiles to x = ... if unlikely { spill x call ... restore x } This is particularly useful for code which appends, as the only call is an unlikely call to growslice. It also helps for the spills needed around write barrier calls. The basic algorithm is walk down the dominator tree following a path where the block still dominates all of the restores. We're looking for a block that: 1) dominates all restores 2) has the value being spilled in a register 3) has a loop depth no deeper than the value being spilled The walking-down code is iterative. I was forced to limit it to searching 100 blocks so it doesn't become O(n^2). Maybe one day we'll find a better way. I had to delete most of David's code which pushed spills out of loops. I suspect this CL subsumes most of the cases that his code handled. Generally positive performance improvements, but hard to tell for sure with all the noise. (compilebench times are unchanged.) name old time/op new time/op delta BinaryTree17-12 2.91s ±15% 2.80s ±12% ~ (p=0.063 n=10+10) Fannkuch11-12 3.47s ± 0% 3.30s ± 4% -4.91% (p=0.000 n=9+10) FmtFprintfEmpty-12 48.0ns ± 1% 47.4ns ± 1% -1.32% (p=0.002 n=9+9) FmtFprintfString-12 85.6ns ±11% 79.4ns ± 3% -7.27% (p=0.005 n=10+10) FmtFprintfInt-12 91.8ns ±10% 85.9ns ± 4% ~ (p=0.203 n=10+9) FmtFprintfIntInt-12 135ns ±13% 127ns ± 1% -5.72% (p=0.025 n=10+9) FmtFprintfPrefixedInt-12 167ns ± 1% 168ns ± 2% ~ (p=0.580 n=9+10) FmtFprintfFloat-12 249ns ±11% 230ns ± 1% -7.32% (p=0.000 n=10+10) FmtManyArgs-12 504ns ± 7% 506ns ± 1% ~ (p=0.198 n=9+9) GobDecode-12 6.95ms ± 1% 7.04ms ± 1% +1.37% (p=0.001 n=10+10) GobEncode-12 6.32ms ±13% 6.04ms ± 1% ~ (p=0.063 n=10+10) Gzip-12 233ms ± 1% 235ms ± 0% +1.01% (p=0.000 n=10+9) Gunzip-12 40.1ms ± 1% 39.6ms ± 0% -1.12% (p=0.000 n=10+8) HTTPClientServer-12 227µs ± 9% 221µs ± 5% ~ (p=0.114 n=9+8) JSONEncode-12 16.1ms ± 2% 15.8ms ± 1% -2.09% (p=0.002 n=9+8) JSONDecode-12 61.8ms ±11% 57.9ms ± 1% -6.30% (p=0.000 n=10+9) Mandelbrot200-12 4.30ms ± 3% 4.28ms ± 1% ~ (p=0.203 n=10+8) GoParse-12 3.18ms ± 2% 3.18ms ± 2% ~ (p=0.579 n=10+10) RegexpMatchEasy0_32-12 76.7ns ± 1% 77.5ns ± 1% +0.92% (p=0.002 n=9+8) RegexpMatchEasy0_1K-12 239ns ± 3% 239ns ± 1% ~ (p=0.204 n=10+10) RegexpMatchEasy1_32-12 71.4ns ± 1% 70.6ns ± 0% -1.15% (p=0.000 n=10+9) RegexpMatchEasy1_1K-12 383ns ± 2% 390ns ±10% ~ (p=0.181 n=8+9) RegexpMatchMedium_32-12 114ns ± 0% 113ns ± 1% -0.88% (p=0.000 n=9+8) RegexpMatchMedium_1K-12 36.3µs ± 1% 36.8µs ± 1% +1.59% (p=0.000 n=10+8) RegexpMatchHard_32-12 1.90µs ± 1% 1.90µs ± 1% ~ (p=0.341 n=10+10) RegexpMatchHard_1K-12 59.4µs ±11% 57.8µs ± 1% ~ (p=0.968 n=10+9) Revcomp-12 461ms ± 1% 462ms ± 1% ~ (p=1.000 n=9+9) Template-12 67.5ms ± 1% 66.3ms ± 1% -1.77% (p=0.000 n=10+8) TimeParse-12 314ns ± 3% 309ns ± 0% -1.56% (p=0.000 n=9+8) TimeFormat-12 340ns ± 2% 331ns ± 1% -2.79% (p=0.000 n=10+10) The go binary is 0.2% larger. Not really sure why the size would change. Change-Id: Ia5116e53a3aeb025ef350ffc51c14ae5cc17871c Reviewed-on: https://go-review.googlesource.com/34822 Reviewed-by: David Chase <drchase@google.com>
2017-03-07 14:45:46 -05:00
}
// Clear any final uses.
// All that is left should be the pseudo-uses added for values which
// are live at the end of b.
for _, e := range s.live[b.ID] {
u := s.values[e.ID].uses
if u == nil {
f.Fatalf("live at end, no uses v%d", e.ID)
}
if u.next != nil {
f.Fatalf("live at end, too many uses v%d", e.ID)
}
s.values[e.ID].uses = nil
u.next = s.freeUseRecords
s.freeUseRecords = u
}
cmd/compile/internal/ssa: drop overwritten regalloc basic block input requirements For the following description, consider the following basic block graph: b1 ───┐┌──── b2 ││ ││ ▼▼ b3 For register allocator transitions between basic blocks, there are two key passes (significant paraphrasing): First, each basic block is visited in some predetermined visit order. This is the core visitOrder range loop in regAllocState.regalloc. The specific ordering heuristics aren't important here, except that the order guarantees that when visiting a basic block at least one of its predecessors has already been visited. Upon visiting a basic block, that block sets its expected starting register state (regAllocState.startRegs) based on the ending register state (regAlloc.State.endRegs) of one of its predecessors. (How it chooses which predecessor to use is not important here.) From that starting state, registers are assigned for all values in the block, ultimately resulting in some ending register state. After all blocks have been visited, the shuffle pass (regAllocState.shuffle) ensures that for each edge, endRegs of the predecessor == startRegs of the successor. That is, it makes sure that the startRegs assumptions actually hold true for each edge. It does this by adding moves to the end of the predecessor block to place values in the expected register for the successor block. These may be moves from other registers, or from memory if the value is spilled. Now on to the actual problem: Assume that b1 places some value v1 into register R10, and thus ends with endRegs containing R10 = v1. When b3 is visited, it selects b1 as its model predecessor and sets startRegs with R10 = v1. b2 does not have v1 in R10, so later in the shuffle pass, we will add a move of v1 into R10 to the end of b2 to ensure it is available for b3. This is all perfectly fine and exactly how things should work. Now suppose that b3 does not use v1. It does need to use some other value v2, which is not currently in a register. When assigning v2 to a register, it finds all registers are already in use and it needs to dump a value. Ultimately, it decides to dump v1 from R10 and replace it with v2. This is fine, but it has downstream effects on shuffle in b2. b3's startRegs still state that R10 = v1, so b2 will add a move to R10 even though b3 will unconditionally overwrite it. i.e., the move at the end of b2 is completely useless and can result in code like: // end of b2 MOV n(SP), R10 // R10 = v1 <-- useless // start of b3 MOV m(SP), R10 // R10 = v2 This is precisely what happened in #58298. This CL addresses this problem by dropping registers from startRegs if they are never used in the basic block prior to getting dumped. This allows the shuffle pass to avoid placing those useless values into the register. There is a significant limitation to this CL, which is that it only impacts the immediate predecessors of an overwriting block. We can discuss this by zooming out a bit on the previous graph: b4 ───┐┌──── b5 ││ ││ ▼▼ b1 ───┐┌──── b2 ││ ││ ▼▼ b3 Here we have the same graph, except we can see the two predecessors of b1. Now suppose that rather than b1 assigning R10 = v1 as above, the assignment is done in b4. b1 has startRegs R10 = v1, doesn't use the value at all, and simply passes it through to endRegs R10 = v1. Now the shuffle pass will require both b2 and b5 to add a move to assigned R10 = v1, because that is specified in their successor startRegs. With this CL, b3 drops R10 = v1 from startRegs, but there is no backwards propagation, so b1 still has R10 = v1 in startRegs, and b5 still needs to add a useless move. Extending this CL with such propagation may significantly increase the number of useless moves we can remove, though it will add complexity to maintenance and could potentially impact build performance depending on how efficiently we could implement the propagation (something I haven't considered carefully). As-is, this optimization does not impact much code. In bent .text size geomean is -0.02%. In the container/heap test binary, 18 of ~2500 functions are impacted by this CL. Bent and sweet do not show a noticeable performance impact one way or another, however #58298 does show a case where this can have impact if the useless instructions end up in the hot path of a tight loop. For #58298. Change-Id: I2fcef37c955159d068fa0725f995a1848add8a5f Reviewed-on: https://go-review.googlesource.com/c/go/+/471158 Run-TryBot: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: David Chase <drchase@google.com>
2023-02-21 13:20:49 -05:00
// allocReg may have dropped registers from startRegsMask that
// aren't actually needed in startRegs. Synchronize back to
// startRegs.
//
// This must be done before placing spills, which will look at
// startRegs to decide if a block is a valid block for a spill.
if c := countRegs(s.startRegsMask); c != len(s.startRegs[b.ID]) {
regs := make([]startReg, 0, c)
for _, sr := range s.startRegs[b.ID] {
if s.startRegsMask&(regMask(1)<<sr.r) == 0 {
cmd/compile/internal/ssa: drop overwritten regalloc basic block input requirements For the following description, consider the following basic block graph: b1 ───┐┌──── b2 ││ ││ ▼▼ b3 For register allocator transitions between basic blocks, there are two key passes (significant paraphrasing): First, each basic block is visited in some predetermined visit order. This is the core visitOrder range loop in regAllocState.regalloc. The specific ordering heuristics aren't important here, except that the order guarantees that when visiting a basic block at least one of its predecessors has already been visited. Upon visiting a basic block, that block sets its expected starting register state (regAllocState.startRegs) based on the ending register state (regAlloc.State.endRegs) of one of its predecessors. (How it chooses which predecessor to use is not important here.) From that starting state, registers are assigned for all values in the block, ultimately resulting in some ending register state. After all blocks have been visited, the shuffle pass (regAllocState.shuffle) ensures that for each edge, endRegs of the predecessor == startRegs of the successor. That is, it makes sure that the startRegs assumptions actually hold true for each edge. It does this by adding moves to the end of the predecessor block to place values in the expected register for the successor block. These may be moves from other registers, or from memory if the value is spilled. Now on to the actual problem: Assume that b1 places some value v1 into register R10, and thus ends with endRegs containing R10 = v1. When b3 is visited, it selects b1 as its model predecessor and sets startRegs with R10 = v1. b2 does not have v1 in R10, so later in the shuffle pass, we will add a move of v1 into R10 to the end of b2 to ensure it is available for b3. This is all perfectly fine and exactly how things should work. Now suppose that b3 does not use v1. It does need to use some other value v2, which is not currently in a register. When assigning v2 to a register, it finds all registers are already in use and it needs to dump a value. Ultimately, it decides to dump v1 from R10 and replace it with v2. This is fine, but it has downstream effects on shuffle in b2. b3's startRegs still state that R10 = v1, so b2 will add a move to R10 even though b3 will unconditionally overwrite it. i.e., the move at the end of b2 is completely useless and can result in code like: // end of b2 MOV n(SP), R10 // R10 = v1 <-- useless // start of b3 MOV m(SP), R10 // R10 = v2 This is precisely what happened in #58298. This CL addresses this problem by dropping registers from startRegs if they are never used in the basic block prior to getting dumped. This allows the shuffle pass to avoid placing those useless values into the register. There is a significant limitation to this CL, which is that it only impacts the immediate predecessors of an overwriting block. We can discuss this by zooming out a bit on the previous graph: b4 ───┐┌──── b5 ││ ││ ▼▼ b1 ───┐┌──── b2 ││ ││ ▼▼ b3 Here we have the same graph, except we can see the two predecessors of b1. Now suppose that rather than b1 assigning R10 = v1 as above, the assignment is done in b4. b1 has startRegs R10 = v1, doesn't use the value at all, and simply passes it through to endRegs R10 = v1. Now the shuffle pass will require both b2 and b5 to add a move to assigned R10 = v1, because that is specified in their successor startRegs. With this CL, b3 drops R10 = v1 from startRegs, but there is no backwards propagation, so b1 still has R10 = v1 in startRegs, and b5 still needs to add a useless move. Extending this CL with such propagation may significantly increase the number of useless moves we can remove, though it will add complexity to maintenance and could potentially impact build performance depending on how efficiently we could implement the propagation (something I haven't considered carefully). As-is, this optimization does not impact much code. In bent .text size geomean is -0.02%. In the container/heap test binary, 18 of ~2500 functions are impacted by this CL. Bent and sweet do not show a noticeable performance impact one way or another, however #58298 does show a case where this can have impact if the useless instructions end up in the hot path of a tight loop. For #58298. Change-Id: I2fcef37c955159d068fa0725f995a1848add8a5f Reviewed-on: https://go-review.googlesource.com/c/go/+/471158 Run-TryBot: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: David Chase <drchase@google.com>
2023-02-21 13:20:49 -05:00
continue
}
regs = append(regs, sr)
}
s.startRegs[b.ID] = regs
}
}
cmd/compile: put spills in better places Previously we always issued a spill right after the op that was being spilled. This CL pushes spills father away from the generator, hopefully pushing them into unlikely branches. For example: x = ... if unlikely { call ... } ... use x ... Used to compile to x = ... spill x if unlikely { call ... restore x } It now compiles to x = ... if unlikely { spill x call ... restore x } This is particularly useful for code which appends, as the only call is an unlikely call to growslice. It also helps for the spills needed around write barrier calls. The basic algorithm is walk down the dominator tree following a path where the block still dominates all of the restores. We're looking for a block that: 1) dominates all restores 2) has the value being spilled in a register 3) has a loop depth no deeper than the value being spilled The walking-down code is iterative. I was forced to limit it to searching 100 blocks so it doesn't become O(n^2). Maybe one day we'll find a better way. I had to delete most of David's code which pushed spills out of loops. I suspect this CL subsumes most of the cases that his code handled. Generally positive performance improvements, but hard to tell for sure with all the noise. (compilebench times are unchanged.) name old time/op new time/op delta BinaryTree17-12 2.91s ±15% 2.80s ±12% ~ (p=0.063 n=10+10) Fannkuch11-12 3.47s ± 0% 3.30s ± 4% -4.91% (p=0.000 n=9+10) FmtFprintfEmpty-12 48.0ns ± 1% 47.4ns ± 1% -1.32% (p=0.002 n=9+9) FmtFprintfString-12 85.6ns ±11% 79.4ns ± 3% -7.27% (p=0.005 n=10+10) FmtFprintfInt-12 91.8ns ±10% 85.9ns ± 4% ~ (p=0.203 n=10+9) FmtFprintfIntInt-12 135ns ±13% 127ns ± 1% -5.72% (p=0.025 n=10+9) FmtFprintfPrefixedInt-12 167ns ± 1% 168ns ± 2% ~ (p=0.580 n=9+10) FmtFprintfFloat-12 249ns ±11% 230ns ± 1% -7.32% (p=0.000 n=10+10) FmtManyArgs-12 504ns ± 7% 506ns ± 1% ~ (p=0.198 n=9+9) GobDecode-12 6.95ms ± 1% 7.04ms ± 1% +1.37% (p=0.001 n=10+10) GobEncode-12 6.32ms ±13% 6.04ms ± 1% ~ (p=0.063 n=10+10) Gzip-12 233ms ± 1% 235ms ± 0% +1.01% (p=0.000 n=10+9) Gunzip-12 40.1ms ± 1% 39.6ms ± 0% -1.12% (p=0.000 n=10+8) HTTPClientServer-12 227µs ± 9% 221µs ± 5% ~ (p=0.114 n=9+8) JSONEncode-12 16.1ms ± 2% 15.8ms ± 1% -2.09% (p=0.002 n=9+8) JSONDecode-12 61.8ms ±11% 57.9ms ± 1% -6.30% (p=0.000 n=10+9) Mandelbrot200-12 4.30ms ± 3% 4.28ms ± 1% ~ (p=0.203 n=10+8) GoParse-12 3.18ms ± 2% 3.18ms ± 2% ~ (p=0.579 n=10+10) RegexpMatchEasy0_32-12 76.7ns ± 1% 77.5ns ± 1% +0.92% (p=0.002 n=9+8) RegexpMatchEasy0_1K-12 239ns ± 3% 239ns ± 1% ~ (p=0.204 n=10+10) RegexpMatchEasy1_32-12 71.4ns ± 1% 70.6ns ± 0% -1.15% (p=0.000 n=10+9) RegexpMatchEasy1_1K-12 383ns ± 2% 390ns ±10% ~ (p=0.181 n=8+9) RegexpMatchMedium_32-12 114ns ± 0% 113ns ± 1% -0.88% (p=0.000 n=9+8) RegexpMatchMedium_1K-12 36.3µs ± 1% 36.8µs ± 1% +1.59% (p=0.000 n=10+8) RegexpMatchHard_32-12 1.90µs ± 1% 1.90µs ± 1% ~ (p=0.341 n=10+10) RegexpMatchHard_1K-12 59.4µs ±11% 57.8µs ± 1% ~ (p=0.968 n=10+9) Revcomp-12 461ms ± 1% 462ms ± 1% ~ (p=1.000 n=9+9) Template-12 67.5ms ± 1% 66.3ms ± 1% -1.77% (p=0.000 n=10+8) TimeParse-12 314ns ± 3% 309ns ± 0% -1.56% (p=0.000 n=9+8) TimeFormat-12 340ns ± 2% 331ns ± 1% -2.79% (p=0.000 n=10+10) The go binary is 0.2% larger. Not really sure why the size would change. Change-Id: Ia5116e53a3aeb025ef350ffc51c14ae5cc17871c Reviewed-on: https://go-review.googlesource.com/34822 Reviewed-by: David Chase <drchase@google.com>
2017-03-07 14:45:46 -05:00
// Decide where the spills we generated will go.
s.placeSpills()
// Anything that didn't get a register gets a stack location here.
// (StoreReg, stack-based phis, inputs, ...)
stacklive := stackalloc(s.f, s.spillLive)
// Fix up all merge edges.
s.shuffle(stacklive)
// Erase any copies we never used.
// Also, an unused copy might be the only use of another copy,
// so continue erasing until we reach a fixed point.
for {
progress := false
for c, used := range s.copies {
if !used && c.Uses == 0 {
if s.f.pass.debug > regDebug {
fmt.Printf("delete copied value %s\n", c.LongString())
}
c.resetArgs()
f.freeValue(c)
delete(s.copies, c)
progress = true
cmd/compile: move value around before kick it out of register When allocating registers, before kicking out the existing value, copy it to a spare register if there is one. So later use of this value can be found in register instead of reload from spill. This is very helpful for instructions of which the input and/or output can only be in specific registers, e.g. DIV on x86, MUL/DIV on MIPS. May also be helpful in general. For "go build -a cmd/go" on AMD64, reduce "spilled value remains" by 1% (not including args, which almost certainly remain). For the code in issue #16061 on AMD64: MaxRem-12 111µs ± 1% 94µs ± 0% -15.38% (p=0.008 n=5+5) Go1 benchmark on AMD64: BinaryTree17-12 2.32s ± 2% 2.30s ± 1% ~ (p=0.421 n=5+5) Fannkuch11-12 2.52s ± 0% 2.44s ± 0% -3.44% (p=0.008 n=5+5) FmtFprintfEmpty-12 39.9ns ± 3% 39.8ns ± 0% ~ (p=0.635 n=5+4) FmtFprintfString-12 114ns ± 1% 113ns ± 1% ~ (p=0.905 n=5+5) FmtFprintfInt-12 102ns ± 6% 98ns ± 1% ~ (p=0.087 n=5+5) FmtFprintfIntInt-12 146ns ± 5% 147ns ± 1% ~ (p=0.238 n=5+5) FmtFprintfPrefixedInt-12 155ns ± 2% 151ns ± 1% -2.58% (p=0.008 n=5+5) FmtFprintfFloat-12 231ns ± 1% 232ns ± 1% ~ (p=0.286 n=5+5) FmtManyArgs-12 657ns ± 1% 649ns ± 0% -1.31% (p=0.008 n=5+5) GobDecode-12 6.35ms ± 0% 6.29ms ± 1% ~ (p=0.056 n=5+5) GobEncode-12 5.38ms ± 1% 5.45ms ± 1% ~ (p=0.056 n=5+5) Gzip-12 209ms ± 0% 209ms ± 1% ~ (p=0.690 n=5+5) Gunzip-12 31.2ms ± 1% 31.1ms ± 1% ~ (p=0.548 n=5+5) HTTPClientServer-12 123µs ± 4% 130µs ± 8% ~ (p=0.151 n=5+5) JSONEncode-12 14.0ms ± 1% 14.0ms ± 1% ~ (p=0.421 n=5+5) JSONDecode-12 41.2ms ± 1% 41.1ms ± 2% ~ (p=0.421 n=5+5) Mandelbrot200-12 3.96ms ± 1% 3.98ms ± 0% ~ (p=0.421 n=5+5) GoParse-12 2.88ms ± 1% 2.88ms ± 1% ~ (p=0.841 n=5+5) RegexpMatchEasy0_32-12 68.0ns ± 3% 66.6ns ± 1% -2.00% (p=0.024 n=5+5) RegexpMatchEasy0_1K-12 728ns ± 8% 682ns ± 1% -6.26% (p=0.008 n=5+5) RegexpMatchEasy1_32-12 66.8ns ± 2% 66.0ns ± 1% ~ (p=0.302 n=5+5) RegexpMatchEasy1_1K-12 291ns ± 2% 288ns ± 1% ~ (p=0.111 n=5+5) RegexpMatchMedium_32-12 103ns ± 2% 100ns ± 0% -2.53% (p=0.016 n=5+4) RegexpMatchMedium_1K-12 31.9µs ± 1% 31.3µs ± 0% -1.75% (p=0.008 n=5+5) RegexpMatchHard_32-12 1.59µs ± 2% 1.59µs ± 1% ~ (p=0.548 n=5+5) RegexpMatchHard_1K-12 48.3µs ± 2% 47.7µs ± 1% ~ (p=0.222 n=5+5) Revcomp-12 340ms ± 1% 338ms ± 1% ~ (p=0.421 n=5+5) Template-12 46.3ms ± 1% 46.5ms ± 1% ~ (p=0.690 n=5+5) TimeParse-12 252ns ± 1% 247ns ± 0% -1.91% (p=0.000 n=5+4) TimeFormat-12 277ns ± 1% 267ns ± 0% -3.82% (p=0.008 n=5+5) [Geo mean] 48.8µs 48.3µs -0.93% It has very little effect on binary size and compiler speed. compilebench: Template 230ms ±10% 231ms ± 8% ~ (p=0.546 n=9+9) Unicode 123ms ± 6% 124ms ± 9% ~ (p=0.481 n=10+10) GoTypes 742ms ± 6% 755ms ± 3% ~ (p=0.123 n=10+10) Compiler 3.10s ± 3% 3.08s ± 1% ~ (p=0.631 n=10+10) Fixes #16061. Change-Id: Id99cdc7a182ee10a704fa0f04e8e0d0809b2ac56 Reviewed-on: https://go-review.googlesource.com/29732 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2016-09-23 09:15:51 -04:00
}
}
if !progress {
break
cmd/compile: move value around before kick it out of register When allocating registers, before kicking out the existing value, copy it to a spare register if there is one. So later use of this value can be found in register instead of reload from spill. This is very helpful for instructions of which the input and/or output can only be in specific registers, e.g. DIV on x86, MUL/DIV on MIPS. May also be helpful in general. For "go build -a cmd/go" on AMD64, reduce "spilled value remains" by 1% (not including args, which almost certainly remain). For the code in issue #16061 on AMD64: MaxRem-12 111µs ± 1% 94µs ± 0% -15.38% (p=0.008 n=5+5) Go1 benchmark on AMD64: BinaryTree17-12 2.32s ± 2% 2.30s ± 1% ~ (p=0.421 n=5+5) Fannkuch11-12 2.52s ± 0% 2.44s ± 0% -3.44% (p=0.008 n=5+5) FmtFprintfEmpty-12 39.9ns ± 3% 39.8ns ± 0% ~ (p=0.635 n=5+4) FmtFprintfString-12 114ns ± 1% 113ns ± 1% ~ (p=0.905 n=5+5) FmtFprintfInt-12 102ns ± 6% 98ns ± 1% ~ (p=0.087 n=5+5) FmtFprintfIntInt-12 146ns ± 5% 147ns ± 1% ~ (p=0.238 n=5+5) FmtFprintfPrefixedInt-12 155ns ± 2% 151ns ± 1% -2.58% (p=0.008 n=5+5) FmtFprintfFloat-12 231ns ± 1% 232ns ± 1% ~ (p=0.286 n=5+5) FmtManyArgs-12 657ns ± 1% 649ns ± 0% -1.31% (p=0.008 n=5+5) GobDecode-12 6.35ms ± 0% 6.29ms ± 1% ~ (p=0.056 n=5+5) GobEncode-12 5.38ms ± 1% 5.45ms ± 1% ~ (p=0.056 n=5+5) Gzip-12 209ms ± 0% 209ms ± 1% ~ (p=0.690 n=5+5) Gunzip-12 31.2ms ± 1% 31.1ms ± 1% ~ (p=0.548 n=5+5) HTTPClientServer-12 123µs ± 4% 130µs ± 8% ~ (p=0.151 n=5+5) JSONEncode-12 14.0ms ± 1% 14.0ms ± 1% ~ (p=0.421 n=5+5) JSONDecode-12 41.2ms ± 1% 41.1ms ± 2% ~ (p=0.421 n=5+5) Mandelbrot200-12 3.96ms ± 1% 3.98ms ± 0% ~ (p=0.421 n=5+5) GoParse-12 2.88ms ± 1% 2.88ms ± 1% ~ (p=0.841 n=5+5) RegexpMatchEasy0_32-12 68.0ns ± 3% 66.6ns ± 1% -2.00% (p=0.024 n=5+5) RegexpMatchEasy0_1K-12 728ns ± 8% 682ns ± 1% -6.26% (p=0.008 n=5+5) RegexpMatchEasy1_32-12 66.8ns ± 2% 66.0ns ± 1% ~ (p=0.302 n=5+5) RegexpMatchEasy1_1K-12 291ns ± 2% 288ns ± 1% ~ (p=0.111 n=5+5) RegexpMatchMedium_32-12 103ns ± 2% 100ns ± 0% -2.53% (p=0.016 n=5+4) RegexpMatchMedium_1K-12 31.9µs ± 1% 31.3µs ± 0% -1.75% (p=0.008 n=5+5) RegexpMatchHard_32-12 1.59µs ± 2% 1.59µs ± 1% ~ (p=0.548 n=5+5) RegexpMatchHard_1K-12 48.3µs ± 2% 47.7µs ± 1% ~ (p=0.222 n=5+5) Revcomp-12 340ms ± 1% 338ms ± 1% ~ (p=0.421 n=5+5) Template-12 46.3ms ± 1% 46.5ms ± 1% ~ (p=0.690 n=5+5) TimeParse-12 252ns ± 1% 247ns ± 0% -1.91% (p=0.000 n=5+4) TimeFormat-12 277ns ± 1% 267ns ± 0% -3.82% (p=0.008 n=5+5) [Geo mean] 48.8µs 48.3µs -0.93% It has very little effect on binary size and compiler speed. compilebench: Template 230ms ±10% 231ms ± 8% ~ (p=0.546 n=9+9) Unicode 123ms ± 6% 124ms ± 9% ~ (p=0.481 n=10+10) GoTypes 742ms ± 6% 755ms ± 3% ~ (p=0.123 n=10+10) Compiler 3.10s ± 3% 3.08s ± 1% ~ (p=0.631 n=10+10) Fixes #16061. Change-Id: Id99cdc7a182ee10a704fa0f04e8e0d0809b2ac56 Reviewed-on: https://go-review.googlesource.com/29732 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2016-09-23 09:15:51 -04:00
}
}
for _, b := range s.visitOrder {
cmd/compile: move value around before kick it out of register When allocating registers, before kicking out the existing value, copy it to a spare register if there is one. So later use of this value can be found in register instead of reload from spill. This is very helpful for instructions of which the input and/or output can only be in specific registers, e.g. DIV on x86, MUL/DIV on MIPS. May also be helpful in general. For "go build -a cmd/go" on AMD64, reduce "spilled value remains" by 1% (not including args, which almost certainly remain). For the code in issue #16061 on AMD64: MaxRem-12 111µs ± 1% 94µs ± 0% -15.38% (p=0.008 n=5+5) Go1 benchmark on AMD64: BinaryTree17-12 2.32s ± 2% 2.30s ± 1% ~ (p=0.421 n=5+5) Fannkuch11-12 2.52s ± 0% 2.44s ± 0% -3.44% (p=0.008 n=5+5) FmtFprintfEmpty-12 39.9ns ± 3% 39.8ns ± 0% ~ (p=0.635 n=5+4) FmtFprintfString-12 114ns ± 1% 113ns ± 1% ~ (p=0.905 n=5+5) FmtFprintfInt-12 102ns ± 6% 98ns ± 1% ~ (p=0.087 n=5+5) FmtFprintfIntInt-12 146ns ± 5% 147ns ± 1% ~ (p=0.238 n=5+5) FmtFprintfPrefixedInt-12 155ns ± 2% 151ns ± 1% -2.58% (p=0.008 n=5+5) FmtFprintfFloat-12 231ns ± 1% 232ns ± 1% ~ (p=0.286 n=5+5) FmtManyArgs-12 657ns ± 1% 649ns ± 0% -1.31% (p=0.008 n=5+5) GobDecode-12 6.35ms ± 0% 6.29ms ± 1% ~ (p=0.056 n=5+5) GobEncode-12 5.38ms ± 1% 5.45ms ± 1% ~ (p=0.056 n=5+5) Gzip-12 209ms ± 0% 209ms ± 1% ~ (p=0.690 n=5+5) Gunzip-12 31.2ms ± 1% 31.1ms ± 1% ~ (p=0.548 n=5+5) HTTPClientServer-12 123µs ± 4% 130µs ± 8% ~ (p=0.151 n=5+5) JSONEncode-12 14.0ms ± 1% 14.0ms ± 1% ~ (p=0.421 n=5+5) JSONDecode-12 41.2ms ± 1% 41.1ms ± 2% ~ (p=0.421 n=5+5) Mandelbrot200-12 3.96ms ± 1% 3.98ms ± 0% ~ (p=0.421 n=5+5) GoParse-12 2.88ms ± 1% 2.88ms ± 1% ~ (p=0.841 n=5+5) RegexpMatchEasy0_32-12 68.0ns ± 3% 66.6ns ± 1% -2.00% (p=0.024 n=5+5) RegexpMatchEasy0_1K-12 728ns ± 8% 682ns ± 1% -6.26% (p=0.008 n=5+5) RegexpMatchEasy1_32-12 66.8ns ± 2% 66.0ns ± 1% ~ (p=0.302 n=5+5) RegexpMatchEasy1_1K-12 291ns ± 2% 288ns ± 1% ~ (p=0.111 n=5+5) RegexpMatchMedium_32-12 103ns ± 2% 100ns ± 0% -2.53% (p=0.016 n=5+4) RegexpMatchMedium_1K-12 31.9µs ± 1% 31.3µs ± 0% -1.75% (p=0.008 n=5+5) RegexpMatchHard_32-12 1.59µs ± 2% 1.59µs ± 1% ~ (p=0.548 n=5+5) RegexpMatchHard_1K-12 48.3µs ± 2% 47.7µs ± 1% ~ (p=0.222 n=5+5) Revcomp-12 340ms ± 1% 338ms ± 1% ~ (p=0.421 n=5+5) Template-12 46.3ms ± 1% 46.5ms ± 1% ~ (p=0.690 n=5+5) TimeParse-12 252ns ± 1% 247ns ± 0% -1.91% (p=0.000 n=5+4) TimeFormat-12 277ns ± 1% 267ns ± 0% -3.82% (p=0.008 n=5+5) [Geo mean] 48.8µs 48.3µs -0.93% It has very little effect on binary size and compiler speed. compilebench: Template 230ms ±10% 231ms ± 8% ~ (p=0.546 n=9+9) Unicode 123ms ± 6% 124ms ± 9% ~ (p=0.481 n=10+10) GoTypes 742ms ± 6% 755ms ± 3% ~ (p=0.123 n=10+10) Compiler 3.10s ± 3% 3.08s ± 1% ~ (p=0.631 n=10+10) Fixes #16061. Change-Id: Id99cdc7a182ee10a704fa0f04e8e0d0809b2ac56 Reviewed-on: https://go-review.googlesource.com/29732 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2016-09-23 09:15:51 -04:00
i := 0
for _, v := range b.Values {
if v.Op == OpInvalid {
continue
}
b.Values[i] = v
i++
}
b.Values = b.Values[:i]
}
cmd/compile: put spills in better places Previously we always issued a spill right after the op that was being spilled. This CL pushes spills father away from the generator, hopefully pushing them into unlikely branches. For example: x = ... if unlikely { call ... } ... use x ... Used to compile to x = ... spill x if unlikely { call ... restore x } It now compiles to x = ... if unlikely { spill x call ... restore x } This is particularly useful for code which appends, as the only call is an unlikely call to growslice. It also helps for the spills needed around write barrier calls. The basic algorithm is walk down the dominator tree following a path where the block still dominates all of the restores. We're looking for a block that: 1) dominates all restores 2) has the value being spilled in a register 3) has a loop depth no deeper than the value being spilled The walking-down code is iterative. I was forced to limit it to searching 100 blocks so it doesn't become O(n^2). Maybe one day we'll find a better way. I had to delete most of David's code which pushed spills out of loops. I suspect this CL subsumes most of the cases that his code handled. Generally positive performance improvements, but hard to tell for sure with all the noise. (compilebench times are unchanged.) name old time/op new time/op delta BinaryTree17-12 2.91s ±15% 2.80s ±12% ~ (p=0.063 n=10+10) Fannkuch11-12 3.47s ± 0% 3.30s ± 4% -4.91% (p=0.000 n=9+10) FmtFprintfEmpty-12 48.0ns ± 1% 47.4ns ± 1% -1.32% (p=0.002 n=9+9) FmtFprintfString-12 85.6ns ±11% 79.4ns ± 3% -7.27% (p=0.005 n=10+10) FmtFprintfInt-12 91.8ns ±10% 85.9ns ± 4% ~ (p=0.203 n=10+9) FmtFprintfIntInt-12 135ns ±13% 127ns ± 1% -5.72% (p=0.025 n=10+9) FmtFprintfPrefixedInt-12 167ns ± 1% 168ns ± 2% ~ (p=0.580 n=9+10) FmtFprintfFloat-12 249ns ±11% 230ns ± 1% -7.32% (p=0.000 n=10+10) FmtManyArgs-12 504ns ± 7% 506ns ± 1% ~ (p=0.198 n=9+9) GobDecode-12 6.95ms ± 1% 7.04ms ± 1% +1.37% (p=0.001 n=10+10) GobEncode-12 6.32ms ±13% 6.04ms ± 1% ~ (p=0.063 n=10+10) Gzip-12 233ms ± 1% 235ms ± 0% +1.01% (p=0.000 n=10+9) Gunzip-12 40.1ms ± 1% 39.6ms ± 0% -1.12% (p=0.000 n=10+8) HTTPClientServer-12 227µs ± 9% 221µs ± 5% ~ (p=0.114 n=9+8) JSONEncode-12 16.1ms ± 2% 15.8ms ± 1% -2.09% (p=0.002 n=9+8) JSONDecode-12 61.8ms ±11% 57.9ms ± 1% -6.30% (p=0.000 n=10+9) Mandelbrot200-12 4.30ms ± 3% 4.28ms ± 1% ~ (p=0.203 n=10+8) GoParse-12 3.18ms ± 2% 3.18ms ± 2% ~ (p=0.579 n=10+10) RegexpMatchEasy0_32-12 76.7ns ± 1% 77.5ns ± 1% +0.92% (p=0.002 n=9+8) RegexpMatchEasy0_1K-12 239ns ± 3% 239ns ± 1% ~ (p=0.204 n=10+10) RegexpMatchEasy1_32-12 71.4ns ± 1% 70.6ns ± 0% -1.15% (p=0.000 n=10+9) RegexpMatchEasy1_1K-12 383ns ± 2% 390ns ±10% ~ (p=0.181 n=8+9) RegexpMatchMedium_32-12 114ns ± 0% 113ns ± 1% -0.88% (p=0.000 n=9+8) RegexpMatchMedium_1K-12 36.3µs ± 1% 36.8µs ± 1% +1.59% (p=0.000 n=10+8) RegexpMatchHard_32-12 1.90µs ± 1% 1.90µs ± 1% ~ (p=0.341 n=10+10) RegexpMatchHard_1K-12 59.4µs ±11% 57.8µs ± 1% ~ (p=0.968 n=10+9) Revcomp-12 461ms ± 1% 462ms ± 1% ~ (p=1.000 n=9+9) Template-12 67.5ms ± 1% 66.3ms ± 1% -1.77% (p=0.000 n=10+8) TimeParse-12 314ns ± 3% 309ns ± 0% -1.56% (p=0.000 n=9+8) TimeFormat-12 340ns ± 2% 331ns ± 1% -2.79% (p=0.000 n=10+10) The go binary is 0.2% larger. Not really sure why the size would change. Change-Id: Ia5116e53a3aeb025ef350ffc51c14ae5cc17871c Reviewed-on: https://go-review.googlesource.com/34822 Reviewed-by: David Chase <drchase@google.com>
2017-03-07 14:45:46 -05:00
}
func (s *regAllocState) placeSpills() {
mustBeFirst := func(op Op) bool {
return op.isLoweredGetClosurePtr() || op == OpPhi || op == OpArgIntReg || op == OpArgFloatReg
}
cmd/compile: put spills in better places Previously we always issued a spill right after the op that was being spilled. This CL pushes spills father away from the generator, hopefully pushing them into unlikely branches. For example: x = ... if unlikely { call ... } ... use x ... Used to compile to x = ... spill x if unlikely { call ... restore x } It now compiles to x = ... if unlikely { spill x call ... restore x } This is particularly useful for code which appends, as the only call is an unlikely call to growslice. It also helps for the spills needed around write barrier calls. The basic algorithm is walk down the dominator tree following a path where the block still dominates all of the restores. We're looking for a block that: 1) dominates all restores 2) has the value being spilled in a register 3) has a loop depth no deeper than the value being spilled The walking-down code is iterative. I was forced to limit it to searching 100 blocks so it doesn't become O(n^2). Maybe one day we'll find a better way. I had to delete most of David's code which pushed spills out of loops. I suspect this CL subsumes most of the cases that his code handled. Generally positive performance improvements, but hard to tell for sure with all the noise. (compilebench times are unchanged.) name old time/op new time/op delta BinaryTree17-12 2.91s ±15% 2.80s ±12% ~ (p=0.063 n=10+10) Fannkuch11-12 3.47s ± 0% 3.30s ± 4% -4.91% (p=0.000 n=9+10) FmtFprintfEmpty-12 48.0ns ± 1% 47.4ns ± 1% -1.32% (p=0.002 n=9+9) FmtFprintfString-12 85.6ns ±11% 79.4ns ± 3% -7.27% (p=0.005 n=10+10) FmtFprintfInt-12 91.8ns ±10% 85.9ns ± 4% ~ (p=0.203 n=10+9) FmtFprintfIntInt-12 135ns ±13% 127ns ± 1% -5.72% (p=0.025 n=10+9) FmtFprintfPrefixedInt-12 167ns ± 1% 168ns ± 2% ~ (p=0.580 n=9+10) FmtFprintfFloat-12 249ns ±11% 230ns ± 1% -7.32% (p=0.000 n=10+10) FmtManyArgs-12 504ns ± 7% 506ns ± 1% ~ (p=0.198 n=9+9) GobDecode-12 6.95ms ± 1% 7.04ms ± 1% +1.37% (p=0.001 n=10+10) GobEncode-12 6.32ms ±13% 6.04ms ± 1% ~ (p=0.063 n=10+10) Gzip-12 233ms ± 1% 235ms ± 0% +1.01% (p=0.000 n=10+9) Gunzip-12 40.1ms ± 1% 39.6ms ± 0% -1.12% (p=0.000 n=10+8) HTTPClientServer-12 227µs ± 9% 221µs ± 5% ~ (p=0.114 n=9+8) JSONEncode-12 16.1ms ± 2% 15.8ms ± 1% -2.09% (p=0.002 n=9+8) JSONDecode-12 61.8ms ±11% 57.9ms ± 1% -6.30% (p=0.000 n=10+9) Mandelbrot200-12 4.30ms ± 3% 4.28ms ± 1% ~ (p=0.203 n=10+8) GoParse-12 3.18ms ± 2% 3.18ms ± 2% ~ (p=0.579 n=10+10) RegexpMatchEasy0_32-12 76.7ns ± 1% 77.5ns ± 1% +0.92% (p=0.002 n=9+8) RegexpMatchEasy0_1K-12 239ns ± 3% 239ns ± 1% ~ (p=0.204 n=10+10) RegexpMatchEasy1_32-12 71.4ns ± 1% 70.6ns ± 0% -1.15% (p=0.000 n=10+9) RegexpMatchEasy1_1K-12 383ns ± 2% 390ns ±10% ~ (p=0.181 n=8+9) RegexpMatchMedium_32-12 114ns ± 0% 113ns ± 1% -0.88% (p=0.000 n=9+8) RegexpMatchMedium_1K-12 36.3µs ± 1% 36.8µs ± 1% +1.59% (p=0.000 n=10+8) RegexpMatchHard_32-12 1.90µs ± 1% 1.90µs ± 1% ~ (p=0.341 n=10+10) RegexpMatchHard_1K-12 59.4µs ±11% 57.8µs ± 1% ~ (p=0.968 n=10+9) Revcomp-12 461ms ± 1% 462ms ± 1% ~ (p=1.000 n=9+9) Template-12 67.5ms ± 1% 66.3ms ± 1% -1.77% (p=0.000 n=10+8) TimeParse-12 314ns ± 3% 309ns ± 0% -1.56% (p=0.000 n=9+8) TimeFormat-12 340ns ± 2% 331ns ± 1% -2.79% (p=0.000 n=10+10) The go binary is 0.2% larger. Not really sure why the size would change. Change-Id: Ia5116e53a3aeb025ef350ffc51c14ae5cc17871c Reviewed-on: https://go-review.googlesource.com/34822 Reviewed-by: David Chase <drchase@google.com>
2017-03-07 14:45:46 -05:00
// Start maps block IDs to the list of spills
// that go at the start of the block (but after any phis).
start := map[ID][]*Value{}
// After maps value IDs to the list of spills
// that go immediately after that value ID.
after := map[ID][]*Value{}
for i := range s.values {
vi := s.values[i]
spill := vi.spill
if spill == nil {
continue
}
if spill.Block != nil {
// Some spills are already fully set up,
// like OpArgs and stack-based phis.
continue
}
v := s.orig[i]
// Walk down the dominator tree looking for a good place to
// put the spill of v. At the start "best" is the best place
// we have found so far.
// TODO: find a way to make this O(1) without arbitrary cutoffs.
if v == nil {
panic(fmt.Errorf("nil v, s.orig[%d], vi = %v, spill = %s", i, vi, spill.LongString()))
}
cmd/compile: put spills in better places Previously we always issued a spill right after the op that was being spilled. This CL pushes spills father away from the generator, hopefully pushing them into unlikely branches. For example: x = ... if unlikely { call ... } ... use x ... Used to compile to x = ... spill x if unlikely { call ... restore x } It now compiles to x = ... if unlikely { spill x call ... restore x } This is particularly useful for code which appends, as the only call is an unlikely call to growslice. It also helps for the spills needed around write barrier calls. The basic algorithm is walk down the dominator tree following a path where the block still dominates all of the restores. We're looking for a block that: 1) dominates all restores 2) has the value being spilled in a register 3) has a loop depth no deeper than the value being spilled The walking-down code is iterative. I was forced to limit it to searching 100 blocks so it doesn't become O(n^2). Maybe one day we'll find a better way. I had to delete most of David's code which pushed spills out of loops. I suspect this CL subsumes most of the cases that his code handled. Generally positive performance improvements, but hard to tell for sure with all the noise. (compilebench times are unchanged.) name old time/op new time/op delta BinaryTree17-12 2.91s ±15% 2.80s ±12% ~ (p=0.063 n=10+10) Fannkuch11-12 3.47s ± 0% 3.30s ± 4% -4.91% (p=0.000 n=9+10) FmtFprintfEmpty-12 48.0ns ± 1% 47.4ns ± 1% -1.32% (p=0.002 n=9+9) FmtFprintfString-12 85.6ns ±11% 79.4ns ± 3% -7.27% (p=0.005 n=10+10) FmtFprintfInt-12 91.8ns ±10% 85.9ns ± 4% ~ (p=0.203 n=10+9) FmtFprintfIntInt-12 135ns ±13% 127ns ± 1% -5.72% (p=0.025 n=10+9) FmtFprintfPrefixedInt-12 167ns ± 1% 168ns ± 2% ~ (p=0.580 n=9+10) FmtFprintfFloat-12 249ns ±11% 230ns ± 1% -7.32% (p=0.000 n=10+10) FmtManyArgs-12 504ns ± 7% 506ns ± 1% ~ (p=0.198 n=9+9) GobDecode-12 6.95ms ± 1% 7.04ms ± 1% +1.37% (p=0.001 n=10+10) GobEncode-12 6.32ms ±13% 6.04ms ± 1% ~ (p=0.063 n=10+10) Gzip-12 233ms ± 1% 235ms ± 0% +1.01% (p=0.000 n=10+9) Gunzip-12 40.1ms ± 1% 39.6ms ± 0% -1.12% (p=0.000 n=10+8) HTTPClientServer-12 227µs ± 9% 221µs ± 5% ~ (p=0.114 n=9+8) JSONEncode-12 16.1ms ± 2% 15.8ms ± 1% -2.09% (p=0.002 n=9+8) JSONDecode-12 61.8ms ±11% 57.9ms ± 1% -6.30% (p=0.000 n=10+9) Mandelbrot200-12 4.30ms ± 3% 4.28ms ± 1% ~ (p=0.203 n=10+8) GoParse-12 3.18ms ± 2% 3.18ms ± 2% ~ (p=0.579 n=10+10) RegexpMatchEasy0_32-12 76.7ns ± 1% 77.5ns ± 1% +0.92% (p=0.002 n=9+8) RegexpMatchEasy0_1K-12 239ns ± 3% 239ns ± 1% ~ (p=0.204 n=10+10) RegexpMatchEasy1_32-12 71.4ns ± 1% 70.6ns ± 0% -1.15% (p=0.000 n=10+9) RegexpMatchEasy1_1K-12 383ns ± 2% 390ns ±10% ~ (p=0.181 n=8+9) RegexpMatchMedium_32-12 114ns ± 0% 113ns ± 1% -0.88% (p=0.000 n=9+8) RegexpMatchMedium_1K-12 36.3µs ± 1% 36.8µs ± 1% +1.59% (p=0.000 n=10+8) RegexpMatchHard_32-12 1.90µs ± 1% 1.90µs ± 1% ~ (p=0.341 n=10+10) RegexpMatchHard_1K-12 59.4µs ±11% 57.8µs ± 1% ~ (p=0.968 n=10+9) Revcomp-12 461ms ± 1% 462ms ± 1% ~ (p=1.000 n=9+9) Template-12 67.5ms ± 1% 66.3ms ± 1% -1.77% (p=0.000 n=10+8) TimeParse-12 314ns ± 3% 309ns ± 0% -1.56% (p=0.000 n=9+8) TimeFormat-12 340ns ± 2% 331ns ± 1% -2.79% (p=0.000 n=10+10) The go binary is 0.2% larger. Not really sure why the size would change. Change-Id: Ia5116e53a3aeb025ef350ffc51c14ae5cc17871c Reviewed-on: https://go-review.googlesource.com/34822 Reviewed-by: David Chase <drchase@google.com>
2017-03-07 14:45:46 -05:00
best := v.Block
bestArg := v
var bestDepth int16
if l := s.loopnest.b2l[best.ID]; l != nil {
bestDepth = l.depth
}
b := best
const maxSpillSearch = 100
for i := 0; i < maxSpillSearch; i++ {
// Find the child of b in the dominator tree which
// dominates all restores.
p := b
b = nil
for c := s.sdom.Child(p); c != nil && i < maxSpillSearch; c, i = s.sdom.Sibling(c), i+1 {
if s.sdom[c.ID].entry <= vi.restoreMin && s.sdom[c.ID].exit >= vi.restoreMax {
// c also dominates all restores. Walk down into c.
b = c
break
}
}
if b == nil {
// Ran out of blocks which dominate all restores.
break
}
var depth int16
if l := s.loopnest.b2l[b.ID]; l != nil {
depth = l.depth
}
if depth > bestDepth {
// Don't push the spill into a deeper loop.
continue
}
cmd/compile: put spills in better places Previously we always issued a spill right after the op that was being spilled. This CL pushes spills father away from the generator, hopefully pushing them into unlikely branches. For example: x = ... if unlikely { call ... } ... use x ... Used to compile to x = ... spill x if unlikely { call ... restore x } It now compiles to x = ... if unlikely { spill x call ... restore x } This is particularly useful for code which appends, as the only call is an unlikely call to growslice. It also helps for the spills needed around write barrier calls. The basic algorithm is walk down the dominator tree following a path where the block still dominates all of the restores. We're looking for a block that: 1) dominates all restores 2) has the value being spilled in a register 3) has a loop depth no deeper than the value being spilled The walking-down code is iterative. I was forced to limit it to searching 100 blocks so it doesn't become O(n^2). Maybe one day we'll find a better way. I had to delete most of David's code which pushed spills out of loops. I suspect this CL subsumes most of the cases that his code handled. Generally positive performance improvements, but hard to tell for sure with all the noise. (compilebench times are unchanged.) name old time/op new time/op delta BinaryTree17-12 2.91s ±15% 2.80s ±12% ~ (p=0.063 n=10+10) Fannkuch11-12 3.47s ± 0% 3.30s ± 4% -4.91% (p=0.000 n=9+10) FmtFprintfEmpty-12 48.0ns ± 1% 47.4ns ± 1% -1.32% (p=0.002 n=9+9) FmtFprintfString-12 85.6ns ±11% 79.4ns ± 3% -7.27% (p=0.005 n=10+10) FmtFprintfInt-12 91.8ns ±10% 85.9ns ± 4% ~ (p=0.203 n=10+9) FmtFprintfIntInt-12 135ns ±13% 127ns ± 1% -5.72% (p=0.025 n=10+9) FmtFprintfPrefixedInt-12 167ns ± 1% 168ns ± 2% ~ (p=0.580 n=9+10) FmtFprintfFloat-12 249ns ±11% 230ns ± 1% -7.32% (p=0.000 n=10+10) FmtManyArgs-12 504ns ± 7% 506ns ± 1% ~ (p=0.198 n=9+9) GobDecode-12 6.95ms ± 1% 7.04ms ± 1% +1.37% (p=0.001 n=10+10) GobEncode-12 6.32ms ±13% 6.04ms ± 1% ~ (p=0.063 n=10+10) Gzip-12 233ms ± 1% 235ms ± 0% +1.01% (p=0.000 n=10+9) Gunzip-12 40.1ms ± 1% 39.6ms ± 0% -1.12% (p=0.000 n=10+8) HTTPClientServer-12 227µs ± 9% 221µs ± 5% ~ (p=0.114 n=9+8) JSONEncode-12 16.1ms ± 2% 15.8ms ± 1% -2.09% (p=0.002 n=9+8) JSONDecode-12 61.8ms ±11% 57.9ms ± 1% -6.30% (p=0.000 n=10+9) Mandelbrot200-12 4.30ms ± 3% 4.28ms ± 1% ~ (p=0.203 n=10+8) GoParse-12 3.18ms ± 2% 3.18ms ± 2% ~ (p=0.579 n=10+10) RegexpMatchEasy0_32-12 76.7ns ± 1% 77.5ns ± 1% +0.92% (p=0.002 n=9+8) RegexpMatchEasy0_1K-12 239ns ± 3% 239ns ± 1% ~ (p=0.204 n=10+10) RegexpMatchEasy1_32-12 71.4ns ± 1% 70.6ns ± 0% -1.15% (p=0.000 n=10+9) RegexpMatchEasy1_1K-12 383ns ± 2% 390ns ±10% ~ (p=0.181 n=8+9) RegexpMatchMedium_32-12 114ns ± 0% 113ns ± 1% -0.88% (p=0.000 n=9+8) RegexpMatchMedium_1K-12 36.3µs ± 1% 36.8µs ± 1% +1.59% (p=0.000 n=10+8) RegexpMatchHard_32-12 1.90µs ± 1% 1.90µs ± 1% ~ (p=0.341 n=10+10) RegexpMatchHard_1K-12 59.4µs ±11% 57.8µs ± 1% ~ (p=0.968 n=10+9) Revcomp-12 461ms ± 1% 462ms ± 1% ~ (p=1.000 n=9+9) Template-12 67.5ms ± 1% 66.3ms ± 1% -1.77% (p=0.000 n=10+8) TimeParse-12 314ns ± 3% 309ns ± 0% -1.56% (p=0.000 n=9+8) TimeFormat-12 340ns ± 2% 331ns ± 1% -2.79% (p=0.000 n=10+10) The go binary is 0.2% larger. Not really sure why the size would change. Change-Id: Ia5116e53a3aeb025ef350ffc51c14ae5cc17871c Reviewed-on: https://go-review.googlesource.com/34822 Reviewed-by: David Chase <drchase@google.com>
2017-03-07 14:45:46 -05:00
// If v is in a register at the start of b, we can
// place the spill here (after the phis).
if len(b.Preds) == 1 {
for _, e := range s.endRegs[b.Preds[0].b.ID] {
if e.v == v {
// Found a better spot for the spill.
best = b
bestArg = e.c
bestDepth = depth
break
}
}
} else {
for _, e := range s.startRegs[b.ID] {
if e.v == v {
// Found a better spot for the spill.
best = b
bestArg = e.c
bestDepth = depth
break
}
}
}
}
// Put the spill in the best block we found.
spill.Block = best
spill.AddArg(bestArg)
if best == v.Block && !mustBeFirst(v.Op) {
cmd/compile: put spills in better places Previously we always issued a spill right after the op that was being spilled. This CL pushes spills father away from the generator, hopefully pushing them into unlikely branches. For example: x = ... if unlikely { call ... } ... use x ... Used to compile to x = ... spill x if unlikely { call ... restore x } It now compiles to x = ... if unlikely { spill x call ... restore x } This is particularly useful for code which appends, as the only call is an unlikely call to growslice. It also helps for the spills needed around write barrier calls. The basic algorithm is walk down the dominator tree following a path where the block still dominates all of the restores. We're looking for a block that: 1) dominates all restores 2) has the value being spilled in a register 3) has a loop depth no deeper than the value being spilled The walking-down code is iterative. I was forced to limit it to searching 100 blocks so it doesn't become O(n^2). Maybe one day we'll find a better way. I had to delete most of David's code which pushed spills out of loops. I suspect this CL subsumes most of the cases that his code handled. Generally positive performance improvements, but hard to tell for sure with all the noise. (compilebench times are unchanged.) name old time/op new time/op delta BinaryTree17-12 2.91s ±15% 2.80s ±12% ~ (p=0.063 n=10+10) Fannkuch11-12 3.47s ± 0% 3.30s ± 4% -4.91% (p=0.000 n=9+10) FmtFprintfEmpty-12 48.0ns ± 1% 47.4ns ± 1% -1.32% (p=0.002 n=9+9) FmtFprintfString-12 85.6ns ±11% 79.4ns ± 3% -7.27% (p=0.005 n=10+10) FmtFprintfInt-12 91.8ns ±10% 85.9ns ± 4% ~ (p=0.203 n=10+9) FmtFprintfIntInt-12 135ns ±13% 127ns ± 1% -5.72% (p=0.025 n=10+9) FmtFprintfPrefixedInt-12 167ns ± 1% 168ns ± 2% ~ (p=0.580 n=9+10) FmtFprintfFloat-12 249ns ±11% 230ns ± 1% -7.32% (p=0.000 n=10+10) FmtManyArgs-12 504ns ± 7% 506ns ± 1% ~ (p=0.198 n=9+9) GobDecode-12 6.95ms ± 1% 7.04ms ± 1% +1.37% (p=0.001 n=10+10) GobEncode-12 6.32ms ±13% 6.04ms ± 1% ~ (p=0.063 n=10+10) Gzip-12 233ms ± 1% 235ms ± 0% +1.01% (p=0.000 n=10+9) Gunzip-12 40.1ms ± 1% 39.6ms ± 0% -1.12% (p=0.000 n=10+8) HTTPClientServer-12 227µs ± 9% 221µs ± 5% ~ (p=0.114 n=9+8) JSONEncode-12 16.1ms ± 2% 15.8ms ± 1% -2.09% (p=0.002 n=9+8) JSONDecode-12 61.8ms ±11% 57.9ms ± 1% -6.30% (p=0.000 n=10+9) Mandelbrot200-12 4.30ms ± 3% 4.28ms ± 1% ~ (p=0.203 n=10+8) GoParse-12 3.18ms ± 2% 3.18ms ± 2% ~ (p=0.579 n=10+10) RegexpMatchEasy0_32-12 76.7ns ± 1% 77.5ns ± 1% +0.92% (p=0.002 n=9+8) RegexpMatchEasy0_1K-12 239ns ± 3% 239ns ± 1% ~ (p=0.204 n=10+10) RegexpMatchEasy1_32-12 71.4ns ± 1% 70.6ns ± 0% -1.15% (p=0.000 n=10+9) RegexpMatchEasy1_1K-12 383ns ± 2% 390ns ±10% ~ (p=0.181 n=8+9) RegexpMatchMedium_32-12 114ns ± 0% 113ns ± 1% -0.88% (p=0.000 n=9+8) RegexpMatchMedium_1K-12 36.3µs ± 1% 36.8µs ± 1% +1.59% (p=0.000 n=10+8) RegexpMatchHard_32-12 1.90µs ± 1% 1.90µs ± 1% ~ (p=0.341 n=10+10) RegexpMatchHard_1K-12 59.4µs ±11% 57.8µs ± 1% ~ (p=0.968 n=10+9) Revcomp-12 461ms ± 1% 462ms ± 1% ~ (p=1.000 n=9+9) Template-12 67.5ms ± 1% 66.3ms ± 1% -1.77% (p=0.000 n=10+8) TimeParse-12 314ns ± 3% 309ns ± 0% -1.56% (p=0.000 n=9+8) TimeFormat-12 340ns ± 2% 331ns ± 1% -2.79% (p=0.000 n=10+10) The go binary is 0.2% larger. Not really sure why the size would change. Change-Id: Ia5116e53a3aeb025ef350ffc51c14ae5cc17871c Reviewed-on: https://go-review.googlesource.com/34822 Reviewed-by: David Chase <drchase@google.com>
2017-03-07 14:45:46 -05:00
// Place immediately after v.
after[v.ID] = append(after[v.ID], spill)
} else {
// Place at the start of best block.
start[best.ID] = append(start[best.ID], spill)
}
}
// Insert spill instructions into the block schedules.
var oldSched []*Value
for _, b := range s.visitOrder {
nfirst := 0
cmd/compile: put spills in better places Previously we always issued a spill right after the op that was being spilled. This CL pushes spills father away from the generator, hopefully pushing them into unlikely branches. For example: x = ... if unlikely { call ... } ... use x ... Used to compile to x = ... spill x if unlikely { call ... restore x } It now compiles to x = ... if unlikely { spill x call ... restore x } This is particularly useful for code which appends, as the only call is an unlikely call to growslice. It also helps for the spills needed around write barrier calls. The basic algorithm is walk down the dominator tree following a path where the block still dominates all of the restores. We're looking for a block that: 1) dominates all restores 2) has the value being spilled in a register 3) has a loop depth no deeper than the value being spilled The walking-down code is iterative. I was forced to limit it to searching 100 blocks so it doesn't become O(n^2). Maybe one day we'll find a better way. I had to delete most of David's code which pushed spills out of loops. I suspect this CL subsumes most of the cases that his code handled. Generally positive performance improvements, but hard to tell for sure with all the noise. (compilebench times are unchanged.) name old time/op new time/op delta BinaryTree17-12 2.91s ±15% 2.80s ±12% ~ (p=0.063 n=10+10) Fannkuch11-12 3.47s ± 0% 3.30s ± 4% -4.91% (p=0.000 n=9+10) FmtFprintfEmpty-12 48.0ns ± 1% 47.4ns ± 1% -1.32% (p=0.002 n=9+9) FmtFprintfString-12 85.6ns ±11% 79.4ns ± 3% -7.27% (p=0.005 n=10+10) FmtFprintfInt-12 91.8ns ±10% 85.9ns ± 4% ~ (p=0.203 n=10+9) FmtFprintfIntInt-12 135ns ±13% 127ns ± 1% -5.72% (p=0.025 n=10+9) FmtFprintfPrefixedInt-12 167ns ± 1% 168ns ± 2% ~ (p=0.580 n=9+10) FmtFprintfFloat-12 249ns ±11% 230ns ± 1% -7.32% (p=0.000 n=10+10) FmtManyArgs-12 504ns ± 7% 506ns ± 1% ~ (p=0.198 n=9+9) GobDecode-12 6.95ms ± 1% 7.04ms ± 1% +1.37% (p=0.001 n=10+10) GobEncode-12 6.32ms ±13% 6.04ms ± 1% ~ (p=0.063 n=10+10) Gzip-12 233ms ± 1% 235ms ± 0% +1.01% (p=0.000 n=10+9) Gunzip-12 40.1ms ± 1% 39.6ms ± 0% -1.12% (p=0.000 n=10+8) HTTPClientServer-12 227µs ± 9% 221µs ± 5% ~ (p=0.114 n=9+8) JSONEncode-12 16.1ms ± 2% 15.8ms ± 1% -2.09% (p=0.002 n=9+8) JSONDecode-12 61.8ms ±11% 57.9ms ± 1% -6.30% (p=0.000 n=10+9) Mandelbrot200-12 4.30ms ± 3% 4.28ms ± 1% ~ (p=0.203 n=10+8) GoParse-12 3.18ms ± 2% 3.18ms ± 2% ~ (p=0.579 n=10+10) RegexpMatchEasy0_32-12 76.7ns ± 1% 77.5ns ± 1% +0.92% (p=0.002 n=9+8) RegexpMatchEasy0_1K-12 239ns ± 3% 239ns ± 1% ~ (p=0.204 n=10+10) RegexpMatchEasy1_32-12 71.4ns ± 1% 70.6ns ± 0% -1.15% (p=0.000 n=10+9) RegexpMatchEasy1_1K-12 383ns ± 2% 390ns ±10% ~ (p=0.181 n=8+9) RegexpMatchMedium_32-12 114ns ± 0% 113ns ± 1% -0.88% (p=0.000 n=9+8) RegexpMatchMedium_1K-12 36.3µs ± 1% 36.8µs ± 1% +1.59% (p=0.000 n=10+8) RegexpMatchHard_32-12 1.90µs ± 1% 1.90µs ± 1% ~ (p=0.341 n=10+10) RegexpMatchHard_1K-12 59.4µs ±11% 57.8µs ± 1% ~ (p=0.968 n=10+9) Revcomp-12 461ms ± 1% 462ms ± 1% ~ (p=1.000 n=9+9) Template-12 67.5ms ± 1% 66.3ms ± 1% -1.77% (p=0.000 n=10+8) TimeParse-12 314ns ± 3% 309ns ± 0% -1.56% (p=0.000 n=9+8) TimeFormat-12 340ns ± 2% 331ns ± 1% -2.79% (p=0.000 n=10+10) The go binary is 0.2% larger. Not really sure why the size would change. Change-Id: Ia5116e53a3aeb025ef350ffc51c14ae5cc17871c Reviewed-on: https://go-review.googlesource.com/34822 Reviewed-by: David Chase <drchase@google.com>
2017-03-07 14:45:46 -05:00
for _, v := range b.Values {
if !mustBeFirst(v.Op) {
cmd/compile: put spills in better places Previously we always issued a spill right after the op that was being spilled. This CL pushes spills father away from the generator, hopefully pushing them into unlikely branches. For example: x = ... if unlikely { call ... } ... use x ... Used to compile to x = ... spill x if unlikely { call ... restore x } It now compiles to x = ... if unlikely { spill x call ... restore x } This is particularly useful for code which appends, as the only call is an unlikely call to growslice. It also helps for the spills needed around write barrier calls. The basic algorithm is walk down the dominator tree following a path where the block still dominates all of the restores. We're looking for a block that: 1) dominates all restores 2) has the value being spilled in a register 3) has a loop depth no deeper than the value being spilled The walking-down code is iterative. I was forced to limit it to searching 100 blocks so it doesn't become O(n^2). Maybe one day we'll find a better way. I had to delete most of David's code which pushed spills out of loops. I suspect this CL subsumes most of the cases that his code handled. Generally positive performance improvements, but hard to tell for sure with all the noise. (compilebench times are unchanged.) name old time/op new time/op delta BinaryTree17-12 2.91s ±15% 2.80s ±12% ~ (p=0.063 n=10+10) Fannkuch11-12 3.47s ± 0% 3.30s ± 4% -4.91% (p=0.000 n=9+10) FmtFprintfEmpty-12 48.0ns ± 1% 47.4ns ± 1% -1.32% (p=0.002 n=9+9) FmtFprintfString-12 85.6ns ±11% 79.4ns ± 3% -7.27% (p=0.005 n=10+10) FmtFprintfInt-12 91.8ns ±10% 85.9ns ± 4% ~ (p=0.203 n=10+9) FmtFprintfIntInt-12 135ns ±13% 127ns ± 1% -5.72% (p=0.025 n=10+9) FmtFprintfPrefixedInt-12 167ns ± 1% 168ns ± 2% ~ (p=0.580 n=9+10) FmtFprintfFloat-12 249ns ±11% 230ns ± 1% -7.32% (p=0.000 n=10+10) FmtManyArgs-12 504ns ± 7% 506ns ± 1% ~ (p=0.198 n=9+9) GobDecode-12 6.95ms ± 1% 7.04ms ± 1% +1.37% (p=0.001 n=10+10) GobEncode-12 6.32ms ±13% 6.04ms ± 1% ~ (p=0.063 n=10+10) Gzip-12 233ms ± 1% 235ms ± 0% +1.01% (p=0.000 n=10+9) Gunzip-12 40.1ms ± 1% 39.6ms ± 0% -1.12% (p=0.000 n=10+8) HTTPClientServer-12 227µs ± 9% 221µs ± 5% ~ (p=0.114 n=9+8) JSONEncode-12 16.1ms ± 2% 15.8ms ± 1% -2.09% (p=0.002 n=9+8) JSONDecode-12 61.8ms ±11% 57.9ms ± 1% -6.30% (p=0.000 n=10+9) Mandelbrot200-12 4.30ms ± 3% 4.28ms ± 1% ~ (p=0.203 n=10+8) GoParse-12 3.18ms ± 2% 3.18ms ± 2% ~ (p=0.579 n=10+10) RegexpMatchEasy0_32-12 76.7ns ± 1% 77.5ns ± 1% +0.92% (p=0.002 n=9+8) RegexpMatchEasy0_1K-12 239ns ± 3% 239ns ± 1% ~ (p=0.204 n=10+10) RegexpMatchEasy1_32-12 71.4ns ± 1% 70.6ns ± 0% -1.15% (p=0.000 n=10+9) RegexpMatchEasy1_1K-12 383ns ± 2% 390ns ±10% ~ (p=0.181 n=8+9) RegexpMatchMedium_32-12 114ns ± 0% 113ns ± 1% -0.88% (p=0.000 n=9+8) RegexpMatchMedium_1K-12 36.3µs ± 1% 36.8µs ± 1% +1.59% (p=0.000 n=10+8) RegexpMatchHard_32-12 1.90µs ± 1% 1.90µs ± 1% ~ (p=0.341 n=10+10) RegexpMatchHard_1K-12 59.4µs ±11% 57.8µs ± 1% ~ (p=0.968 n=10+9) Revcomp-12 461ms ± 1% 462ms ± 1% ~ (p=1.000 n=9+9) Template-12 67.5ms ± 1% 66.3ms ± 1% -1.77% (p=0.000 n=10+8) TimeParse-12 314ns ± 3% 309ns ± 0% -1.56% (p=0.000 n=9+8) TimeFormat-12 340ns ± 2% 331ns ± 1% -2.79% (p=0.000 n=10+10) The go binary is 0.2% larger. Not really sure why the size would change. Change-Id: Ia5116e53a3aeb025ef350ffc51c14ae5cc17871c Reviewed-on: https://go-review.googlesource.com/34822 Reviewed-by: David Chase <drchase@google.com>
2017-03-07 14:45:46 -05:00
break
}
nfirst++
cmd/compile: put spills in better places Previously we always issued a spill right after the op that was being spilled. This CL pushes spills father away from the generator, hopefully pushing them into unlikely branches. For example: x = ... if unlikely { call ... } ... use x ... Used to compile to x = ... spill x if unlikely { call ... restore x } It now compiles to x = ... if unlikely { spill x call ... restore x } This is particularly useful for code which appends, as the only call is an unlikely call to growslice. It also helps for the spills needed around write barrier calls. The basic algorithm is walk down the dominator tree following a path where the block still dominates all of the restores. We're looking for a block that: 1) dominates all restores 2) has the value being spilled in a register 3) has a loop depth no deeper than the value being spilled The walking-down code is iterative. I was forced to limit it to searching 100 blocks so it doesn't become O(n^2). Maybe one day we'll find a better way. I had to delete most of David's code which pushed spills out of loops. I suspect this CL subsumes most of the cases that his code handled. Generally positive performance improvements, but hard to tell for sure with all the noise. (compilebench times are unchanged.) name old time/op new time/op delta BinaryTree17-12 2.91s ±15% 2.80s ±12% ~ (p=0.063 n=10+10) Fannkuch11-12 3.47s ± 0% 3.30s ± 4% -4.91% (p=0.000 n=9+10) FmtFprintfEmpty-12 48.0ns ± 1% 47.4ns ± 1% -1.32% (p=0.002 n=9+9) FmtFprintfString-12 85.6ns ±11% 79.4ns ± 3% -7.27% (p=0.005 n=10+10) FmtFprintfInt-12 91.8ns ±10% 85.9ns ± 4% ~ (p=0.203 n=10+9) FmtFprintfIntInt-12 135ns ±13% 127ns ± 1% -5.72% (p=0.025 n=10+9) FmtFprintfPrefixedInt-12 167ns ± 1% 168ns ± 2% ~ (p=0.580 n=9+10) FmtFprintfFloat-12 249ns ±11% 230ns ± 1% -7.32% (p=0.000 n=10+10) FmtManyArgs-12 504ns ± 7% 506ns ± 1% ~ (p=0.198 n=9+9) GobDecode-12 6.95ms ± 1% 7.04ms ± 1% +1.37% (p=0.001 n=10+10) GobEncode-12 6.32ms ±13% 6.04ms ± 1% ~ (p=0.063 n=10+10) Gzip-12 233ms ± 1% 235ms ± 0% +1.01% (p=0.000 n=10+9) Gunzip-12 40.1ms ± 1% 39.6ms ± 0% -1.12% (p=0.000 n=10+8) HTTPClientServer-12 227µs ± 9% 221µs ± 5% ~ (p=0.114 n=9+8) JSONEncode-12 16.1ms ± 2% 15.8ms ± 1% -2.09% (p=0.002 n=9+8) JSONDecode-12 61.8ms ±11% 57.9ms ± 1% -6.30% (p=0.000 n=10+9) Mandelbrot200-12 4.30ms ± 3% 4.28ms ± 1% ~ (p=0.203 n=10+8) GoParse-12 3.18ms ± 2% 3.18ms ± 2% ~ (p=0.579 n=10+10) RegexpMatchEasy0_32-12 76.7ns ± 1% 77.5ns ± 1% +0.92% (p=0.002 n=9+8) RegexpMatchEasy0_1K-12 239ns ± 3% 239ns ± 1% ~ (p=0.204 n=10+10) RegexpMatchEasy1_32-12 71.4ns ± 1% 70.6ns ± 0% -1.15% (p=0.000 n=10+9) RegexpMatchEasy1_1K-12 383ns ± 2% 390ns ±10% ~ (p=0.181 n=8+9) RegexpMatchMedium_32-12 114ns ± 0% 113ns ± 1% -0.88% (p=0.000 n=9+8) RegexpMatchMedium_1K-12 36.3µs ± 1% 36.8µs ± 1% +1.59% (p=0.000 n=10+8) RegexpMatchHard_32-12 1.90µs ± 1% 1.90µs ± 1% ~ (p=0.341 n=10+10) RegexpMatchHard_1K-12 59.4µs ±11% 57.8µs ± 1% ~ (p=0.968 n=10+9) Revcomp-12 461ms ± 1% 462ms ± 1% ~ (p=1.000 n=9+9) Template-12 67.5ms ± 1% 66.3ms ± 1% -1.77% (p=0.000 n=10+8) TimeParse-12 314ns ± 3% 309ns ± 0% -1.56% (p=0.000 n=9+8) TimeFormat-12 340ns ± 2% 331ns ± 1% -2.79% (p=0.000 n=10+10) The go binary is 0.2% larger. Not really sure why the size would change. Change-Id: Ia5116e53a3aeb025ef350ffc51c14ae5cc17871c Reviewed-on: https://go-review.googlesource.com/34822 Reviewed-by: David Chase <drchase@google.com>
2017-03-07 14:45:46 -05:00
}
oldSched = append(oldSched[:0], b.Values[nfirst:]...)
b.Values = b.Values[:nfirst]
b.Values = append(b.Values, start[b.ID]...)
cmd/compile: put spills in better places Previously we always issued a spill right after the op that was being spilled. This CL pushes spills father away from the generator, hopefully pushing them into unlikely branches. For example: x = ... if unlikely { call ... } ... use x ... Used to compile to x = ... spill x if unlikely { call ... restore x } It now compiles to x = ... if unlikely { spill x call ... restore x } This is particularly useful for code which appends, as the only call is an unlikely call to growslice. It also helps for the spills needed around write barrier calls. The basic algorithm is walk down the dominator tree following a path where the block still dominates all of the restores. We're looking for a block that: 1) dominates all restores 2) has the value being spilled in a register 3) has a loop depth no deeper than the value being spilled The walking-down code is iterative. I was forced to limit it to searching 100 blocks so it doesn't become O(n^2). Maybe one day we'll find a better way. I had to delete most of David's code which pushed spills out of loops. I suspect this CL subsumes most of the cases that his code handled. Generally positive performance improvements, but hard to tell for sure with all the noise. (compilebench times are unchanged.) name old time/op new time/op delta BinaryTree17-12 2.91s ±15% 2.80s ±12% ~ (p=0.063 n=10+10) Fannkuch11-12 3.47s ± 0% 3.30s ± 4% -4.91% (p=0.000 n=9+10) FmtFprintfEmpty-12 48.0ns ± 1% 47.4ns ± 1% -1.32% (p=0.002 n=9+9) FmtFprintfString-12 85.6ns ±11% 79.4ns ± 3% -7.27% (p=0.005 n=10+10) FmtFprintfInt-12 91.8ns ±10% 85.9ns ± 4% ~ (p=0.203 n=10+9) FmtFprintfIntInt-12 135ns ±13% 127ns ± 1% -5.72% (p=0.025 n=10+9) FmtFprintfPrefixedInt-12 167ns ± 1% 168ns ± 2% ~ (p=0.580 n=9+10) FmtFprintfFloat-12 249ns ±11% 230ns ± 1% -7.32% (p=0.000 n=10+10) FmtManyArgs-12 504ns ± 7% 506ns ± 1% ~ (p=0.198 n=9+9) GobDecode-12 6.95ms ± 1% 7.04ms ± 1% +1.37% (p=0.001 n=10+10) GobEncode-12 6.32ms ±13% 6.04ms ± 1% ~ (p=0.063 n=10+10) Gzip-12 233ms ± 1% 235ms ± 0% +1.01% (p=0.000 n=10+9) Gunzip-12 40.1ms ± 1% 39.6ms ± 0% -1.12% (p=0.000 n=10+8) HTTPClientServer-12 227µs ± 9% 221µs ± 5% ~ (p=0.114 n=9+8) JSONEncode-12 16.1ms ± 2% 15.8ms ± 1% -2.09% (p=0.002 n=9+8) JSONDecode-12 61.8ms ±11% 57.9ms ± 1% -6.30% (p=0.000 n=10+9) Mandelbrot200-12 4.30ms ± 3% 4.28ms ± 1% ~ (p=0.203 n=10+8) GoParse-12 3.18ms ± 2% 3.18ms ± 2% ~ (p=0.579 n=10+10) RegexpMatchEasy0_32-12 76.7ns ± 1% 77.5ns ± 1% +0.92% (p=0.002 n=9+8) RegexpMatchEasy0_1K-12 239ns ± 3% 239ns ± 1% ~ (p=0.204 n=10+10) RegexpMatchEasy1_32-12 71.4ns ± 1% 70.6ns ± 0% -1.15% (p=0.000 n=10+9) RegexpMatchEasy1_1K-12 383ns ± 2% 390ns ±10% ~ (p=0.181 n=8+9) RegexpMatchMedium_32-12 114ns ± 0% 113ns ± 1% -0.88% (p=0.000 n=9+8) RegexpMatchMedium_1K-12 36.3µs ± 1% 36.8µs ± 1% +1.59% (p=0.000 n=10+8) RegexpMatchHard_32-12 1.90µs ± 1% 1.90µs ± 1% ~ (p=0.341 n=10+10) RegexpMatchHard_1K-12 59.4µs ±11% 57.8µs ± 1% ~ (p=0.968 n=10+9) Revcomp-12 461ms ± 1% 462ms ± 1% ~ (p=1.000 n=9+9) Template-12 67.5ms ± 1% 66.3ms ± 1% -1.77% (p=0.000 n=10+8) TimeParse-12 314ns ± 3% 309ns ± 0% -1.56% (p=0.000 n=9+8) TimeFormat-12 340ns ± 2% 331ns ± 1% -2.79% (p=0.000 n=10+10) The go binary is 0.2% larger. Not really sure why the size would change. Change-Id: Ia5116e53a3aeb025ef350ffc51c14ae5cc17871c Reviewed-on: https://go-review.googlesource.com/34822 Reviewed-by: David Chase <drchase@google.com>
2017-03-07 14:45:46 -05:00
for _, v := range oldSched {
b.Values = append(b.Values, v)
b.Values = append(b.Values, after[v.ID]...)
cmd/compile: put spills in better places Previously we always issued a spill right after the op that was being spilled. This CL pushes spills father away from the generator, hopefully pushing them into unlikely branches. For example: x = ... if unlikely { call ... } ... use x ... Used to compile to x = ... spill x if unlikely { call ... restore x } It now compiles to x = ... if unlikely { spill x call ... restore x } This is particularly useful for code which appends, as the only call is an unlikely call to growslice. It also helps for the spills needed around write barrier calls. The basic algorithm is walk down the dominator tree following a path where the block still dominates all of the restores. We're looking for a block that: 1) dominates all restores 2) has the value being spilled in a register 3) has a loop depth no deeper than the value being spilled The walking-down code is iterative. I was forced to limit it to searching 100 blocks so it doesn't become O(n^2). Maybe one day we'll find a better way. I had to delete most of David's code which pushed spills out of loops. I suspect this CL subsumes most of the cases that his code handled. Generally positive performance improvements, but hard to tell for sure with all the noise. (compilebench times are unchanged.) name old time/op new time/op delta BinaryTree17-12 2.91s ±15% 2.80s ±12% ~ (p=0.063 n=10+10) Fannkuch11-12 3.47s ± 0% 3.30s ± 4% -4.91% (p=0.000 n=9+10) FmtFprintfEmpty-12 48.0ns ± 1% 47.4ns ± 1% -1.32% (p=0.002 n=9+9) FmtFprintfString-12 85.6ns ±11% 79.4ns ± 3% -7.27% (p=0.005 n=10+10) FmtFprintfInt-12 91.8ns ±10% 85.9ns ± 4% ~ (p=0.203 n=10+9) FmtFprintfIntInt-12 135ns ±13% 127ns ± 1% -5.72% (p=0.025 n=10+9) FmtFprintfPrefixedInt-12 167ns ± 1% 168ns ± 2% ~ (p=0.580 n=9+10) FmtFprintfFloat-12 249ns ±11% 230ns ± 1% -7.32% (p=0.000 n=10+10) FmtManyArgs-12 504ns ± 7% 506ns ± 1% ~ (p=0.198 n=9+9) GobDecode-12 6.95ms ± 1% 7.04ms ± 1% +1.37% (p=0.001 n=10+10) GobEncode-12 6.32ms ±13% 6.04ms ± 1% ~ (p=0.063 n=10+10) Gzip-12 233ms ± 1% 235ms ± 0% +1.01% (p=0.000 n=10+9) Gunzip-12 40.1ms ± 1% 39.6ms ± 0% -1.12% (p=0.000 n=10+8) HTTPClientServer-12 227µs ± 9% 221µs ± 5% ~ (p=0.114 n=9+8) JSONEncode-12 16.1ms ± 2% 15.8ms ± 1% -2.09% (p=0.002 n=9+8) JSONDecode-12 61.8ms ±11% 57.9ms ± 1% -6.30% (p=0.000 n=10+9) Mandelbrot200-12 4.30ms ± 3% 4.28ms ± 1% ~ (p=0.203 n=10+8) GoParse-12 3.18ms ± 2% 3.18ms ± 2% ~ (p=0.579 n=10+10) RegexpMatchEasy0_32-12 76.7ns ± 1% 77.5ns ± 1% +0.92% (p=0.002 n=9+8) RegexpMatchEasy0_1K-12 239ns ± 3% 239ns ± 1% ~ (p=0.204 n=10+10) RegexpMatchEasy1_32-12 71.4ns ± 1% 70.6ns ± 0% -1.15% (p=0.000 n=10+9) RegexpMatchEasy1_1K-12 383ns ± 2% 390ns ±10% ~ (p=0.181 n=8+9) RegexpMatchMedium_32-12 114ns ± 0% 113ns ± 1% -0.88% (p=0.000 n=9+8) RegexpMatchMedium_1K-12 36.3µs ± 1% 36.8µs ± 1% +1.59% (p=0.000 n=10+8) RegexpMatchHard_32-12 1.90µs ± 1% 1.90µs ± 1% ~ (p=0.341 n=10+10) RegexpMatchHard_1K-12 59.4µs ±11% 57.8µs ± 1% ~ (p=0.968 n=10+9) Revcomp-12 461ms ± 1% 462ms ± 1% ~ (p=1.000 n=9+9) Template-12 67.5ms ± 1% 66.3ms ± 1% -1.77% (p=0.000 n=10+8) TimeParse-12 314ns ± 3% 309ns ± 0% -1.56% (p=0.000 n=9+8) TimeFormat-12 340ns ± 2% 331ns ± 1% -2.79% (p=0.000 n=10+10) The go binary is 0.2% larger. Not really sure why the size would change. Change-Id: Ia5116e53a3aeb025ef350ffc51c14ae5cc17871c Reviewed-on: https://go-review.googlesource.com/34822 Reviewed-by: David Chase <drchase@google.com>
2017-03-07 14:45:46 -05:00
}
}
}
// shuffle fixes up all the merge edges (those going into blocks of indegree > 1).
func (s *regAllocState) shuffle(stacklive [][]ID) {
var e edgeState
e.s = s
e.cache = map[ID][]*Value{}
e.contents = map[Location]contentRecord{}
if s.f.pass.debug > regDebug {
fmt.Printf("shuffle %s\n", s.f.Name)
fmt.Println(s.f.String())
}
for _, b := range s.visitOrder {
if len(b.Preds) <= 1 {
continue
}
e.b = b
for i, edge := range b.Preds {
p := edge.b
e.p = p
e.setup(i, s.endRegs[p.ID], s.startRegs[b.ID], stacklive[p.ID])
e.process()
}
}
if s.f.pass.debug > regDebug {
fmt.Printf("post shuffle %s\n", s.f.Name)
fmt.Println(s.f.String())
}
}
type edgeState struct {
s *regAllocState
p, b *Block // edge goes from p->b.
// for each pre-regalloc value, a list of equivalent cached values
cache map[ID][]*Value
cachedVals []ID // (superset of) keys of the above map, for deterministic iteration
// map from location to the value it contains
contents map[Location]contentRecord
// desired destination locations
destinations []dstRecord
extra []dstRecord
cmd/compile: prefer to evict a rematerializable register This resolves a long-standing regalloc TODO: If you must evict a register, choose to evict a register containing a rematerializable value, since that value won't need to be spilled. Provides very minor performance and size improvements. name old time/op new time/op delta BinaryTree17-8 2.20s ± 3% 2.18s ± 2% -0.77% (p=0.000 n=45+49) Fannkuch11-8 2.14s ± 2% 2.15s ± 2% +0.73% (p=0.000 n=43+44) FmtFprintfEmpty-8 30.6ns ± 4% 30.2ns ± 3% -1.14% (p=0.000 n=50+48) FmtFprintfString-8 54.5ns ± 6% 53.6ns ± 5% -1.64% (p=0.001 n=50+48) FmtFprintfInt-8 58.0ns ± 7% 57.6ns ± 4% ~ (p=0.220 n=50+50) FmtFprintfIntInt-8 85.3ns ± 2% 84.8ns ± 3% -0.62% (p=0.001 n=44+47) FmtFprintfPrefixedInt-8 93.9ns ± 6% 93.6ns ± 5% ~ (p=0.706 n=50+48) FmtFprintfFloat-8 178ns ± 4% 177ns ± 4% ~ (p=0.107 n=49+50) FmtManyArgs-8 376ns ± 4% 374ns ± 3% -0.58% (p=0.013 n=45+50) GobDecode-8 4.77ms ± 2% 4.76ms ± 3% ~ (p=0.059 n=47+46) GobEncode-8 4.04ms ± 2% 3.99ms ± 3% -1.13% (p=0.000 n=49+49) Gzip-8 177ms ± 2% 180ms ± 3% +1.43% (p=0.000 n=48+48) Gunzip-8 28.5ms ± 6% 28.3ms ± 5% ~ (p=0.104 n=50+49) HTTPClientServer-8 72.1µs ± 1% 72.0µs ± 1% -0.15% (p=0.042 n=48+42) JSONEncode-8 9.81ms ± 5% 10.03ms ± 6% +2.29% (p=0.000 n=50+49) JSONDecode-8 39.2ms ± 3% 39.3ms ± 2% ~ (p=0.095 n=49+49) Mandelbrot200-8 3.48ms ± 2% 3.46ms ± 2% -0.80% (p=0.000 n=47+48) GoParse-8 2.54ms ± 3% 2.51ms ± 3% -1.35% (p=0.000 n=49+49) RegexpMatchEasy0_32-8 66.0ns ± 7% 65.7ns ± 8% ~ (p=0.331 n=50+50) RegexpMatchEasy0_1K-8 155ns ± 4% 154ns ± 4% ~ (p=0.986 n=49+50) RegexpMatchEasy1_32-8 62.6ns ± 8% 62.2ns ± 5% ~ (p=0.395 n=50+49) RegexpMatchEasy1_1K-8 260ns ± 5% 255ns ± 3% -1.92% (p=0.000 n=49+49) RegexpMatchMedium_32-8 92.9ns ± 2% 91.8ns ± 2% -1.25% (p=0.000 n=46+48) RegexpMatchMedium_1K-8 27.7µs ± 3% 27.0µs ± 2% -2.59% (p=0.000 n=49+49) RegexpMatchHard_32-8 1.23µs ± 4% 1.21µs ± 2% -2.16% (p=0.000 n=49+44) RegexpMatchHard_1K-8 36.4µs ± 2% 35.7µs ± 2% -1.87% (p=0.000 n=48+49) Revcomp-8 274ms ± 2% 276ms ± 3% +0.70% (p=0.034 n=45+48) Template-8 45.1ms ± 8% 45.1ms ± 8% ~ (p=0.643 n=50+50) TimeParse-8 223ns ± 2% 223ns ± 2% ~ (p=0.401 n=47+47) TimeFormat-8 245ns ± 2% 246ns ± 3% ~ (p=0.758 n=49+50) [Geo mean] 36.5µs 36.3µs -0.54% name old object-bytes new object-bytes delta Template 480kB ± 0% 480kB ± 0% ~ (all equal) Unicode 214kB ± 0% 214kB ± 0% ~ (all equal) GoTypes 1.54MB ± 0% 1.54MB ± 0% -0.03% (p=0.008 n=5+5) Compiler 5.75MB ± 0% 5.75MB ± 0% ~ (all equal) SSA 14.6MB ± 0% 14.6MB ± 0% -0.01% (p=0.008 n=5+5) Flate 300kB ± 0% 300kB ± 0% -0.01% (p=0.008 n=5+5) GoParser 366kB ± 0% 366kB ± 0% ~ (all equal) Reflect 1.20MB ± 0% 1.20MB ± 0% ~ (all equal) Tar 413kB ± 0% 413kB ± 0% ~ (all equal) XML 529kB ± 0% 528kB ± 0% -0.13% (p=0.008 n=5+5) [Geo mean] 909kB 909kB -0.02% Change-Id: I46d37a55197683a98913f35801dc2b0d609653c8 Reviewed-on: https://go-review.googlesource.com/103240 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2018-03-16 07:15:59 -07:00
usedRegs regMask // registers currently holding something
uniqueRegs regMask // registers holding the only copy of a value
finalRegs regMask // registers holding final target
rematerializeableRegs regMask // registers that hold rematerializeable values
}
type contentRecord struct {
2016-12-15 17:17:01 -08:00
vid ID // pre-regalloc value
c *Value // cached value
final bool // this is a satisfied destination
pos src.XPos // source position of use of the value
}
type dstRecord struct {
loc Location // register or stack slot
vid ID // pre-regalloc value it should contain
splice **Value // place to store reference to the generating instruction
2016-12-15 17:17:01 -08:00
pos src.XPos // source position of use of this location
}
// setup initializes the edge state for shuffling.
func (e *edgeState) setup(idx int, srcReg []endReg, dstReg []startReg, stacklive []ID) {
if e.s.f.pass.debug > regDebug {
fmt.Printf("edge %s->%s\n", e.p, e.b)
}
// Clear state.
clear(e.cache)
e.cachedVals = e.cachedVals[:0]
clear(e.contents)
e.usedRegs = 0
e.uniqueRegs = 0
e.finalRegs = 0
cmd/compile: prefer to evict a rematerializable register This resolves a long-standing regalloc TODO: If you must evict a register, choose to evict a register containing a rematerializable value, since that value won't need to be spilled. Provides very minor performance and size improvements. name old time/op new time/op delta BinaryTree17-8 2.20s ± 3% 2.18s ± 2% -0.77% (p=0.000 n=45+49) Fannkuch11-8 2.14s ± 2% 2.15s ± 2% +0.73% (p=0.000 n=43+44) FmtFprintfEmpty-8 30.6ns ± 4% 30.2ns ± 3% -1.14% (p=0.000 n=50+48) FmtFprintfString-8 54.5ns ± 6% 53.6ns ± 5% -1.64% (p=0.001 n=50+48) FmtFprintfInt-8 58.0ns ± 7% 57.6ns ± 4% ~ (p=0.220 n=50+50) FmtFprintfIntInt-8 85.3ns ± 2% 84.8ns ± 3% -0.62% (p=0.001 n=44+47) FmtFprintfPrefixedInt-8 93.9ns ± 6% 93.6ns ± 5% ~ (p=0.706 n=50+48) FmtFprintfFloat-8 178ns ± 4% 177ns ± 4% ~ (p=0.107 n=49+50) FmtManyArgs-8 376ns ± 4% 374ns ± 3% -0.58% (p=0.013 n=45+50) GobDecode-8 4.77ms ± 2% 4.76ms ± 3% ~ (p=0.059 n=47+46) GobEncode-8 4.04ms ± 2% 3.99ms ± 3% -1.13% (p=0.000 n=49+49) Gzip-8 177ms ± 2% 180ms ± 3% +1.43% (p=0.000 n=48+48) Gunzip-8 28.5ms ± 6% 28.3ms ± 5% ~ (p=0.104 n=50+49) HTTPClientServer-8 72.1µs ± 1% 72.0µs ± 1% -0.15% (p=0.042 n=48+42) JSONEncode-8 9.81ms ± 5% 10.03ms ± 6% +2.29% (p=0.000 n=50+49) JSONDecode-8 39.2ms ± 3% 39.3ms ± 2% ~ (p=0.095 n=49+49) Mandelbrot200-8 3.48ms ± 2% 3.46ms ± 2% -0.80% (p=0.000 n=47+48) GoParse-8 2.54ms ± 3% 2.51ms ± 3% -1.35% (p=0.000 n=49+49) RegexpMatchEasy0_32-8 66.0ns ± 7% 65.7ns ± 8% ~ (p=0.331 n=50+50) RegexpMatchEasy0_1K-8 155ns ± 4% 154ns ± 4% ~ (p=0.986 n=49+50) RegexpMatchEasy1_32-8 62.6ns ± 8% 62.2ns ± 5% ~ (p=0.395 n=50+49) RegexpMatchEasy1_1K-8 260ns ± 5% 255ns ± 3% -1.92% (p=0.000 n=49+49) RegexpMatchMedium_32-8 92.9ns ± 2% 91.8ns ± 2% -1.25% (p=0.000 n=46+48) RegexpMatchMedium_1K-8 27.7µs ± 3% 27.0µs ± 2% -2.59% (p=0.000 n=49+49) RegexpMatchHard_32-8 1.23µs ± 4% 1.21µs ± 2% -2.16% (p=0.000 n=49+44) RegexpMatchHard_1K-8 36.4µs ± 2% 35.7µs ± 2% -1.87% (p=0.000 n=48+49) Revcomp-8 274ms ± 2% 276ms ± 3% +0.70% (p=0.034 n=45+48) Template-8 45.1ms ± 8% 45.1ms ± 8% ~ (p=0.643 n=50+50) TimeParse-8 223ns ± 2% 223ns ± 2% ~ (p=0.401 n=47+47) TimeFormat-8 245ns ± 2% 246ns ± 3% ~ (p=0.758 n=49+50) [Geo mean] 36.5µs 36.3µs -0.54% name old object-bytes new object-bytes delta Template 480kB ± 0% 480kB ± 0% ~ (all equal) Unicode 214kB ± 0% 214kB ± 0% ~ (all equal) GoTypes 1.54MB ± 0% 1.54MB ± 0% -0.03% (p=0.008 n=5+5) Compiler 5.75MB ± 0% 5.75MB ± 0% ~ (all equal) SSA 14.6MB ± 0% 14.6MB ± 0% -0.01% (p=0.008 n=5+5) Flate 300kB ± 0% 300kB ± 0% -0.01% (p=0.008 n=5+5) GoParser 366kB ± 0% 366kB ± 0% ~ (all equal) Reflect 1.20MB ± 0% 1.20MB ± 0% ~ (all equal) Tar 413kB ± 0% 413kB ± 0% ~ (all equal) XML 529kB ± 0% 528kB ± 0% -0.13% (p=0.008 n=5+5) [Geo mean] 909kB 909kB -0.02% Change-Id: I46d37a55197683a98913f35801dc2b0d609653c8 Reviewed-on: https://go-review.googlesource.com/103240 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2018-03-16 07:15:59 -07:00
e.rematerializeableRegs = 0
// Live registers can be sources.
for _, x := range srcReg {
2016-12-15 17:17:01 -08:00
e.set(&e.s.registers[x.r], x.v.ID, x.c, false, src.NoXPos) // don't care the position of the source
}
// So can all of the spill locations.
for _, spillID := range stacklive {
v := e.s.orig[spillID]
spill := e.s.values[v.ID].spill
if !e.s.sdom.IsAncestorEq(spill.Block, e.p) {
cmd/compile: put spills in better places Previously we always issued a spill right after the op that was being spilled. This CL pushes spills father away from the generator, hopefully pushing them into unlikely branches. For example: x = ... if unlikely { call ... } ... use x ... Used to compile to x = ... spill x if unlikely { call ... restore x } It now compiles to x = ... if unlikely { spill x call ... restore x } This is particularly useful for code which appends, as the only call is an unlikely call to growslice. It also helps for the spills needed around write barrier calls. The basic algorithm is walk down the dominator tree following a path where the block still dominates all of the restores. We're looking for a block that: 1) dominates all restores 2) has the value being spilled in a register 3) has a loop depth no deeper than the value being spilled The walking-down code is iterative. I was forced to limit it to searching 100 blocks so it doesn't become O(n^2). Maybe one day we'll find a better way. I had to delete most of David's code which pushed spills out of loops. I suspect this CL subsumes most of the cases that his code handled. Generally positive performance improvements, but hard to tell for sure with all the noise. (compilebench times are unchanged.) name old time/op new time/op delta BinaryTree17-12 2.91s ±15% 2.80s ±12% ~ (p=0.063 n=10+10) Fannkuch11-12 3.47s ± 0% 3.30s ± 4% -4.91% (p=0.000 n=9+10) FmtFprintfEmpty-12 48.0ns ± 1% 47.4ns ± 1% -1.32% (p=0.002 n=9+9) FmtFprintfString-12 85.6ns ±11% 79.4ns ± 3% -7.27% (p=0.005 n=10+10) FmtFprintfInt-12 91.8ns ±10% 85.9ns ± 4% ~ (p=0.203 n=10+9) FmtFprintfIntInt-12 135ns ±13% 127ns ± 1% -5.72% (p=0.025 n=10+9) FmtFprintfPrefixedInt-12 167ns ± 1% 168ns ± 2% ~ (p=0.580 n=9+10) FmtFprintfFloat-12 249ns ±11% 230ns ± 1% -7.32% (p=0.000 n=10+10) FmtManyArgs-12 504ns ± 7% 506ns ± 1% ~ (p=0.198 n=9+9) GobDecode-12 6.95ms ± 1% 7.04ms ± 1% +1.37% (p=0.001 n=10+10) GobEncode-12 6.32ms ±13% 6.04ms ± 1% ~ (p=0.063 n=10+10) Gzip-12 233ms ± 1% 235ms ± 0% +1.01% (p=0.000 n=10+9) Gunzip-12 40.1ms ± 1% 39.6ms ± 0% -1.12% (p=0.000 n=10+8) HTTPClientServer-12 227µs ± 9% 221µs ± 5% ~ (p=0.114 n=9+8) JSONEncode-12 16.1ms ± 2% 15.8ms ± 1% -2.09% (p=0.002 n=9+8) JSONDecode-12 61.8ms ±11% 57.9ms ± 1% -6.30% (p=0.000 n=10+9) Mandelbrot200-12 4.30ms ± 3% 4.28ms ± 1% ~ (p=0.203 n=10+8) GoParse-12 3.18ms ± 2% 3.18ms ± 2% ~ (p=0.579 n=10+10) RegexpMatchEasy0_32-12 76.7ns ± 1% 77.5ns ± 1% +0.92% (p=0.002 n=9+8) RegexpMatchEasy0_1K-12 239ns ± 3% 239ns ± 1% ~ (p=0.204 n=10+10) RegexpMatchEasy1_32-12 71.4ns ± 1% 70.6ns ± 0% -1.15% (p=0.000 n=10+9) RegexpMatchEasy1_1K-12 383ns ± 2% 390ns ±10% ~ (p=0.181 n=8+9) RegexpMatchMedium_32-12 114ns ± 0% 113ns ± 1% -0.88% (p=0.000 n=9+8) RegexpMatchMedium_1K-12 36.3µs ± 1% 36.8µs ± 1% +1.59% (p=0.000 n=10+8) RegexpMatchHard_32-12 1.90µs ± 1% 1.90µs ± 1% ~ (p=0.341 n=10+10) RegexpMatchHard_1K-12 59.4µs ±11% 57.8µs ± 1% ~ (p=0.968 n=10+9) Revcomp-12 461ms ± 1% 462ms ± 1% ~ (p=1.000 n=9+9) Template-12 67.5ms ± 1% 66.3ms ± 1% -1.77% (p=0.000 n=10+8) TimeParse-12 314ns ± 3% 309ns ± 0% -1.56% (p=0.000 n=9+8) TimeFormat-12 340ns ± 2% 331ns ± 1% -2.79% (p=0.000 n=10+10) The go binary is 0.2% larger. Not really sure why the size would change. Change-Id: Ia5116e53a3aeb025ef350ffc51c14ae5cc17871c Reviewed-on: https://go-review.googlesource.com/34822 Reviewed-by: David Chase <drchase@google.com>
2017-03-07 14:45:46 -05:00
// Spills were placed that only dominate the uses found
// during the first regalloc pass. The edge fixup code
// can't use a spill location if the spill doesn't dominate
// the edge.
// We are guaranteed that if the spill doesn't dominate this edge,
// then the value is available in a register (because we called
// makeSpill for every value not in a register at the start
// of an edge).
continue
}
2016-12-15 17:17:01 -08:00
e.set(e.s.f.getHome(spillID), v.ID, spill, false, src.NoXPos) // don't care the position of the source
}
// Figure out all the destinations we need.
dsts := e.destinations[:0]
for _, x := range dstReg {
cmd/compile: put spills in better places Previously we always issued a spill right after the op that was being spilled. This CL pushes spills father away from the generator, hopefully pushing them into unlikely branches. For example: x = ... if unlikely { call ... } ... use x ... Used to compile to x = ... spill x if unlikely { call ... restore x } It now compiles to x = ... if unlikely { spill x call ... restore x } This is particularly useful for code which appends, as the only call is an unlikely call to growslice. It also helps for the spills needed around write barrier calls. The basic algorithm is walk down the dominator tree following a path where the block still dominates all of the restores. We're looking for a block that: 1) dominates all restores 2) has the value being spilled in a register 3) has a loop depth no deeper than the value being spilled The walking-down code is iterative. I was forced to limit it to searching 100 blocks so it doesn't become O(n^2). Maybe one day we'll find a better way. I had to delete most of David's code which pushed spills out of loops. I suspect this CL subsumes most of the cases that his code handled. Generally positive performance improvements, but hard to tell for sure with all the noise. (compilebench times are unchanged.) name old time/op new time/op delta BinaryTree17-12 2.91s ±15% 2.80s ±12% ~ (p=0.063 n=10+10) Fannkuch11-12 3.47s ± 0% 3.30s ± 4% -4.91% (p=0.000 n=9+10) FmtFprintfEmpty-12 48.0ns ± 1% 47.4ns ± 1% -1.32% (p=0.002 n=9+9) FmtFprintfString-12 85.6ns ±11% 79.4ns ± 3% -7.27% (p=0.005 n=10+10) FmtFprintfInt-12 91.8ns ±10% 85.9ns ± 4% ~ (p=0.203 n=10+9) FmtFprintfIntInt-12 135ns ±13% 127ns ± 1% -5.72% (p=0.025 n=10+9) FmtFprintfPrefixedInt-12 167ns ± 1% 168ns ± 2% ~ (p=0.580 n=9+10) FmtFprintfFloat-12 249ns ±11% 230ns ± 1% -7.32% (p=0.000 n=10+10) FmtManyArgs-12 504ns ± 7% 506ns ± 1% ~ (p=0.198 n=9+9) GobDecode-12 6.95ms ± 1% 7.04ms ± 1% +1.37% (p=0.001 n=10+10) GobEncode-12 6.32ms ±13% 6.04ms ± 1% ~ (p=0.063 n=10+10) Gzip-12 233ms ± 1% 235ms ± 0% +1.01% (p=0.000 n=10+9) Gunzip-12 40.1ms ± 1% 39.6ms ± 0% -1.12% (p=0.000 n=10+8) HTTPClientServer-12 227µs ± 9% 221µs ± 5% ~ (p=0.114 n=9+8) JSONEncode-12 16.1ms ± 2% 15.8ms ± 1% -2.09% (p=0.002 n=9+8) JSONDecode-12 61.8ms ±11% 57.9ms ± 1% -6.30% (p=0.000 n=10+9) Mandelbrot200-12 4.30ms ± 3% 4.28ms ± 1% ~ (p=0.203 n=10+8) GoParse-12 3.18ms ± 2% 3.18ms ± 2% ~ (p=0.579 n=10+10) RegexpMatchEasy0_32-12 76.7ns ± 1% 77.5ns ± 1% +0.92% (p=0.002 n=9+8) RegexpMatchEasy0_1K-12 239ns ± 3% 239ns ± 1% ~ (p=0.204 n=10+10) RegexpMatchEasy1_32-12 71.4ns ± 1% 70.6ns ± 0% -1.15% (p=0.000 n=10+9) RegexpMatchEasy1_1K-12 383ns ± 2% 390ns ±10% ~ (p=0.181 n=8+9) RegexpMatchMedium_32-12 114ns ± 0% 113ns ± 1% -0.88% (p=0.000 n=9+8) RegexpMatchMedium_1K-12 36.3µs ± 1% 36.8µs ± 1% +1.59% (p=0.000 n=10+8) RegexpMatchHard_32-12 1.90µs ± 1% 1.90µs ± 1% ~ (p=0.341 n=10+10) RegexpMatchHard_1K-12 59.4µs ±11% 57.8µs ± 1% ~ (p=0.968 n=10+9) Revcomp-12 461ms ± 1% 462ms ± 1% ~ (p=1.000 n=9+9) Template-12 67.5ms ± 1% 66.3ms ± 1% -1.77% (p=0.000 n=10+8) TimeParse-12 314ns ± 3% 309ns ± 0% -1.56% (p=0.000 n=9+8) TimeFormat-12 340ns ± 2% 331ns ± 1% -2.79% (p=0.000 n=10+10) The go binary is 0.2% larger. Not really sure why the size would change. Change-Id: Ia5116e53a3aeb025ef350ffc51c14ae5cc17871c Reviewed-on: https://go-review.googlesource.com/34822 Reviewed-by: David Chase <drchase@google.com>
2017-03-07 14:45:46 -05:00
dsts = append(dsts, dstRecord{&e.s.registers[x.r], x.v.ID, nil, x.pos})
}
// Phis need their args to end up in a specific location.
for _, v := range e.b.Values {
if v.Op != OpPhi {
break
}
loc := e.s.f.getHome(v.ID)
if loc == nil {
continue
}
dsts = append(dsts, dstRecord{loc, v.Args[idx].ID, &v.Args[idx], v.Pos})
}
e.destinations = dsts
if e.s.f.pass.debug > regDebug {
for _, vid := range e.cachedVals {
a := e.cache[vid]
for _, c := range a {
fmt.Printf("src %s: v%d cache=%s\n", e.s.f.getHome(c.ID), vid, c)
}
}
for _, d := range e.destinations {
fmt.Printf("dst %s: v%d\n", d.loc, d.vid)
}
}
}
// process generates code to move all the values to the right destination locations.
func (e *edgeState) process() {
dsts := e.destinations
// Process the destinations until they are all satisfied.
for len(dsts) > 0 {
i := 0
for _, d := range dsts {
if !e.processDest(d.loc, d.vid, d.splice, d.pos) {
// Failed - save for next iteration.
dsts[i] = d
i++
}
}
if i < len(dsts) {
// Made some progress. Go around again.
dsts = dsts[:i]
// Append any extras destinations we generated.
dsts = append(dsts, e.extra...)
e.extra = e.extra[:0]
continue
}
// We made no progress. That means that any
// remaining unsatisfied moves are in simple cycles.
// For example, A -> B -> C -> D -> A.
// A ----> B
// ^ |
// | |
// | v
// D <---- C
// To break the cycle, we pick an unused register, say R,
// and put a copy of B there.
// A ----> B
// ^ |
// | |
// | v
// D <---- C <---- R=copyofB
// When we resume the outer loop, the A->B move can now proceed,
// and eventually the whole cycle completes.
// Copy any cycle location to a temp register. This duplicates
// one of the cycle entries, allowing the just duplicated value
// to be overwritten and the cycle to proceed.
d := dsts[0]
loc := d.loc
vid := e.contents[loc].vid
c := e.contents[loc].c
r := e.findRegFor(c.Type)
if e.s.f.pass.debug > regDebug {
fmt.Printf("breaking cycle with v%d in %s:%s\n", vid, loc, c)
}
[dev.debug] cmd/compile: better DWARF with optimizations on Debuggers use DWARF information to find local variables on the stack and in registers. Prior to this CL, the DWARF information for functions claimed that all variables were on the stack at all times. That's incorrect when optimizations are enabled, and results in debuggers showing data that is out of date or complete gibberish. After this CL, the compiler is capable of representing variable locations more accurately, and attempts to do so. Due to limitations of the SSA backend, it's not possible to be completely correct. There are a number of problems in the current design. One of the easier to understand is that variable names currently must be attached to an SSA value, but not all assignments in the source code actually result in machine code. For example: type myint int var a int b := myint(int) and b := (*uint64)(unsafe.Pointer(a)) don't generate machine code because the underlying representation is the same, so the correct value of b will not be set when the user would expect. Generating the more precise debug information is behind a flag, dwarflocationlists. Because of the issues described above, setting the flag may not make the debugging experience much better, and may actually make it worse in cases where the variable actually is on the stack and the more complicated analysis doesn't realize it. A number of changes are included: - Add a new pseudo-instruction, RegKill, which indicates that the value in the register has been clobbered. - Adjust regalloc to emit RegKills in the right places. Significantly, this means that phis are mixed with StoreReg and RegKills after regalloc. - Track variable decomposition in ssa.LocalSlots. - After the SSA backend is done, analyze the result and build location lists for each LocalSlot. - After assembly is done, update the location lists with the assembled PC offsets, recompose variables, and build DWARF location lists. Emit the list as a new linker symbol, one per function. - In the linker, aggregate the location lists into a .debug_loc section. TODO: - currently disabled for non-X86/AMD64 because there are no data tables. go build -toolexec 'toolstash -cmp' -a std succeeds. With -dwarflocationlists false: before: f02812195637909ff675782c0b46836a8ff01976 after: 06f61e8112a42ac34fb80e0c818b3cdb84a5e7ec benchstat -geomean /tmp/220352263 /tmp/621364410 completed 15 of 15, estimated time remaining 0s (eta 3:52PM) name old time/op new time/op delta Template 199ms ± 3% 198ms ± 2% ~ (p=0.400 n=15+14) Unicode 96.6ms ± 5% 96.4ms ± 5% ~ (p=0.838 n=15+15) GoTypes 653ms ± 2% 647ms ± 2% ~ (p=0.102 n=15+14) Flate 133ms ± 6% 129ms ± 3% -2.62% (p=0.041 n=15+15) GoParser 164ms ± 5% 159ms ± 3% -3.05% (p=0.000 n=15+15) Reflect 428ms ± 4% 422ms ± 3% ~ (p=0.156 n=15+13) Tar 123ms ±10% 124ms ± 8% ~ (p=0.461 n=15+15) XML 228ms ± 3% 224ms ± 3% -1.57% (p=0.045 n=15+15) [Geo mean] 206ms 377ms +82.86% name old user-time/op new user-time/op delta Template 292ms ±10% 301ms ±12% ~ (p=0.189 n=15+15) Unicode 166ms ±37% 158ms ±14% ~ (p=0.418 n=15+14) GoTypes 962ms ± 6% 963ms ± 7% ~ (p=0.976 n=15+15) Flate 207ms ±19% 200ms ±14% ~ (p=0.345 n=14+15) GoParser 246ms ±22% 240ms ±15% ~ (p=0.587 n=15+15) Reflect 611ms ±13% 587ms ±14% ~ (p=0.085 n=15+13) Tar 211ms ±12% 217ms ±14% ~ (p=0.355 n=14+15) XML 335ms ±15% 320ms ±18% ~ (p=0.169 n=15+15) [Geo mean] 317ms 583ms +83.72% name old alloc/op new alloc/op delta Template 40.2MB ± 0% 40.2MB ± 0% -0.15% (p=0.000 n=14+15) Unicode 29.2MB ± 0% 29.3MB ± 0% ~ (p=0.624 n=15+15) GoTypes 114MB ± 0% 114MB ± 0% -0.15% (p=0.000 n=15+14) Flate 25.7MB ± 0% 25.6MB ± 0% -0.18% (p=0.000 n=13+15) GoParser 32.2MB ± 0% 32.2MB ± 0% -0.14% (p=0.003 n=15+15) Reflect 77.8MB ± 0% 77.9MB ± 0% ~ (p=0.061 n=15+15) Tar 27.1MB ± 0% 27.0MB ± 0% -0.11% (p=0.029 n=15+15) XML 42.7MB ± 0% 42.5MB ± 0% -0.29% (p=0.000 n=15+15) [Geo mean] 42.1MB 75.0MB +78.05% name old allocs/op new allocs/op delta Template 402k ± 1% 398k ± 0% -0.91% (p=0.000 n=15+15) Unicode 344k ± 1% 344k ± 0% ~ (p=0.715 n=15+14) GoTypes 1.18M ± 0% 1.17M ± 0% -0.91% (p=0.000 n=15+14) Flate 243k ± 0% 240k ± 1% -1.05% (p=0.000 n=13+15) GoParser 327k ± 1% 324k ± 1% -0.96% (p=0.000 n=15+15) Reflect 984k ± 1% 982k ± 0% ~ (p=0.050 n=15+15) Tar 261k ± 1% 259k ± 1% -0.77% (p=0.000 n=15+15) XML 411k ± 0% 404k ± 1% -1.55% (p=0.000 n=15+15) [Geo mean] 439k 755k +72.01% name old text-bytes new text-bytes delta HelloSize 694kB ± 0% 694kB ± 0% -0.00% (p=0.000 n=15+15) name old data-bytes new data-bytes delta HelloSize 5.55kB ± 0% 5.55kB ± 0% ~ (all equal) name old bss-bytes new bss-bytes delta HelloSize 133kB ± 0% 133kB ± 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 1.04MB ± 0% 1.04MB ± 0% ~ (all equal) Change-Id: I991fc553ef175db46bb23b2128317bbd48de70d8 Reviewed-on: https://go-review.googlesource.com/41770 Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
2017-07-21 18:30:19 -04:00
e.erase(r)
pos := d.pos.WithNotStmt()
if _, isReg := loc.(*Register); isReg {
c = e.p.NewValue1(pos, OpCopy, c.Type, c)
} else {
c = e.p.NewValue1(pos, OpLoadReg, c.Type, c)
}
e.set(r, vid, c, false, pos)
if c.Op == OpLoadReg && e.s.isGReg(register(r.(*Register).num)) {
e.s.f.Fatalf("process.OpLoadReg targeting g: " + c.LongString())
}
}
}
// processDest generates code to put value vid into location loc. Returns true
// if progress was made.
2016-12-15 17:17:01 -08:00
func (e *edgeState) processDest(loc Location, vid ID, splice **Value, pos src.XPos) bool {
pos = pos.WithNotStmt()
occupant := e.contents[loc]
if occupant.vid == vid {
// Value is already in the correct place.
e.contents[loc] = contentRecord{vid, occupant.c, true, pos}
if splice != nil {
(*splice).Uses--
*splice = occupant.c
occupant.c.Uses++
}
// Note: if splice==nil then c will appear dead. This is
// non-SSA formed code, so be careful after this pass not to run
// deadcode elimination.
cmd/compile: move value around before kick it out of register When allocating registers, before kicking out the existing value, copy it to a spare register if there is one. So later use of this value can be found in register instead of reload from spill. This is very helpful for instructions of which the input and/or output can only be in specific registers, e.g. DIV on x86, MUL/DIV on MIPS. May also be helpful in general. For "go build -a cmd/go" on AMD64, reduce "spilled value remains" by 1% (not including args, which almost certainly remain). For the code in issue #16061 on AMD64: MaxRem-12 111µs ± 1% 94µs ± 0% -15.38% (p=0.008 n=5+5) Go1 benchmark on AMD64: BinaryTree17-12 2.32s ± 2% 2.30s ± 1% ~ (p=0.421 n=5+5) Fannkuch11-12 2.52s ± 0% 2.44s ± 0% -3.44% (p=0.008 n=5+5) FmtFprintfEmpty-12 39.9ns ± 3% 39.8ns ± 0% ~ (p=0.635 n=5+4) FmtFprintfString-12 114ns ± 1% 113ns ± 1% ~ (p=0.905 n=5+5) FmtFprintfInt-12 102ns ± 6% 98ns ± 1% ~ (p=0.087 n=5+5) FmtFprintfIntInt-12 146ns ± 5% 147ns ± 1% ~ (p=0.238 n=5+5) FmtFprintfPrefixedInt-12 155ns ± 2% 151ns ± 1% -2.58% (p=0.008 n=5+5) FmtFprintfFloat-12 231ns ± 1% 232ns ± 1% ~ (p=0.286 n=5+5) FmtManyArgs-12 657ns ± 1% 649ns ± 0% -1.31% (p=0.008 n=5+5) GobDecode-12 6.35ms ± 0% 6.29ms ± 1% ~ (p=0.056 n=5+5) GobEncode-12 5.38ms ± 1% 5.45ms ± 1% ~ (p=0.056 n=5+5) Gzip-12 209ms ± 0% 209ms ± 1% ~ (p=0.690 n=5+5) Gunzip-12 31.2ms ± 1% 31.1ms ± 1% ~ (p=0.548 n=5+5) HTTPClientServer-12 123µs ± 4% 130µs ± 8% ~ (p=0.151 n=5+5) JSONEncode-12 14.0ms ± 1% 14.0ms ± 1% ~ (p=0.421 n=5+5) JSONDecode-12 41.2ms ± 1% 41.1ms ± 2% ~ (p=0.421 n=5+5) Mandelbrot200-12 3.96ms ± 1% 3.98ms ± 0% ~ (p=0.421 n=5+5) GoParse-12 2.88ms ± 1% 2.88ms ± 1% ~ (p=0.841 n=5+5) RegexpMatchEasy0_32-12 68.0ns ± 3% 66.6ns ± 1% -2.00% (p=0.024 n=5+5) RegexpMatchEasy0_1K-12 728ns ± 8% 682ns ± 1% -6.26% (p=0.008 n=5+5) RegexpMatchEasy1_32-12 66.8ns ± 2% 66.0ns ± 1% ~ (p=0.302 n=5+5) RegexpMatchEasy1_1K-12 291ns ± 2% 288ns ± 1% ~ (p=0.111 n=5+5) RegexpMatchMedium_32-12 103ns ± 2% 100ns ± 0% -2.53% (p=0.016 n=5+4) RegexpMatchMedium_1K-12 31.9µs ± 1% 31.3µs ± 0% -1.75% (p=0.008 n=5+5) RegexpMatchHard_32-12 1.59µs ± 2% 1.59µs ± 1% ~ (p=0.548 n=5+5) RegexpMatchHard_1K-12 48.3µs ± 2% 47.7µs ± 1% ~ (p=0.222 n=5+5) Revcomp-12 340ms ± 1% 338ms ± 1% ~ (p=0.421 n=5+5) Template-12 46.3ms ± 1% 46.5ms ± 1% ~ (p=0.690 n=5+5) TimeParse-12 252ns ± 1% 247ns ± 0% -1.91% (p=0.000 n=5+4) TimeFormat-12 277ns ± 1% 267ns ± 0% -3.82% (p=0.008 n=5+5) [Geo mean] 48.8µs 48.3µs -0.93% It has very little effect on binary size and compiler speed. compilebench: Template 230ms ±10% 231ms ± 8% ~ (p=0.546 n=9+9) Unicode 123ms ± 6% 124ms ± 9% ~ (p=0.481 n=10+10) GoTypes 742ms ± 6% 755ms ± 3% ~ (p=0.123 n=10+10) Compiler 3.10s ± 3% 3.08s ± 1% ~ (p=0.631 n=10+10) Fixes #16061. Change-Id: Id99cdc7a182ee10a704fa0f04e8e0d0809b2ac56 Reviewed-on: https://go-review.googlesource.com/29732 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2016-09-23 09:15:51 -04:00
if _, ok := e.s.copies[occupant.c]; ok {
// The copy at occupant.c was used to avoid spill.
e.s.copies[occupant.c] = true
}
return true
}
// Check if we're allowed to clobber the destination location.
if len(e.cache[occupant.vid]) == 1 && !e.s.values[occupant.vid].rematerializeable && !opcodeTable[e.s.orig[occupant.vid].Op].fixedReg {
// We can't overwrite the last copy
// of a value that needs to survive.
return false
}
// Copy from a source of v, register preferred.
v := e.s.orig[vid]
var c *Value
var src Location
if e.s.f.pass.debug > regDebug {
fmt.Printf("moving v%d to %s\n", vid, loc)
fmt.Printf("sources of v%d:", vid)
}
if opcodeTable[v.Op].fixedReg {
c = v
src = e.s.f.getHome(v.ID)
} else {
for _, w := range e.cache[vid] {
h := e.s.f.getHome(w.ID)
if e.s.f.pass.debug > regDebug {
fmt.Printf(" %s:%s", h, w)
}
_, isreg := h.(*Register)
if src == nil || isreg {
c = w
src = h
}
}
}
if e.s.f.pass.debug > regDebug {
if src != nil {
fmt.Printf(" [use %s]\n", src)
} else {
fmt.Printf(" [no source]\n")
}
}
_, dstReg := loc.(*Register)
[dev.debug] cmd/compile: better DWARF with optimizations on Debuggers use DWARF information to find local variables on the stack and in registers. Prior to this CL, the DWARF information for functions claimed that all variables were on the stack at all times. That's incorrect when optimizations are enabled, and results in debuggers showing data that is out of date or complete gibberish. After this CL, the compiler is capable of representing variable locations more accurately, and attempts to do so. Due to limitations of the SSA backend, it's not possible to be completely correct. There are a number of problems in the current design. One of the easier to understand is that variable names currently must be attached to an SSA value, but not all assignments in the source code actually result in machine code. For example: type myint int var a int b := myint(int) and b := (*uint64)(unsafe.Pointer(a)) don't generate machine code because the underlying representation is the same, so the correct value of b will not be set when the user would expect. Generating the more precise debug information is behind a flag, dwarflocationlists. Because of the issues described above, setting the flag may not make the debugging experience much better, and may actually make it worse in cases where the variable actually is on the stack and the more complicated analysis doesn't realize it. A number of changes are included: - Add a new pseudo-instruction, RegKill, which indicates that the value in the register has been clobbered. - Adjust regalloc to emit RegKills in the right places. Significantly, this means that phis are mixed with StoreReg and RegKills after regalloc. - Track variable decomposition in ssa.LocalSlots. - After the SSA backend is done, analyze the result and build location lists for each LocalSlot. - After assembly is done, update the location lists with the assembled PC offsets, recompose variables, and build DWARF location lists. Emit the list as a new linker symbol, one per function. - In the linker, aggregate the location lists into a .debug_loc section. TODO: - currently disabled for non-X86/AMD64 because there are no data tables. go build -toolexec 'toolstash -cmp' -a std succeeds. With -dwarflocationlists false: before: f02812195637909ff675782c0b46836a8ff01976 after: 06f61e8112a42ac34fb80e0c818b3cdb84a5e7ec benchstat -geomean /tmp/220352263 /tmp/621364410 completed 15 of 15, estimated time remaining 0s (eta 3:52PM) name old time/op new time/op delta Template 199ms ± 3% 198ms ± 2% ~ (p=0.400 n=15+14) Unicode 96.6ms ± 5% 96.4ms ± 5% ~ (p=0.838 n=15+15) GoTypes 653ms ± 2% 647ms ± 2% ~ (p=0.102 n=15+14) Flate 133ms ± 6% 129ms ± 3% -2.62% (p=0.041 n=15+15) GoParser 164ms ± 5% 159ms ± 3% -3.05% (p=0.000 n=15+15) Reflect 428ms ± 4% 422ms ± 3% ~ (p=0.156 n=15+13) Tar 123ms ±10% 124ms ± 8% ~ (p=0.461 n=15+15) XML 228ms ± 3% 224ms ± 3% -1.57% (p=0.045 n=15+15) [Geo mean] 206ms 377ms +82.86% name old user-time/op new user-time/op delta Template 292ms ±10% 301ms ±12% ~ (p=0.189 n=15+15) Unicode 166ms ±37% 158ms ±14% ~ (p=0.418 n=15+14) GoTypes 962ms ± 6% 963ms ± 7% ~ (p=0.976 n=15+15) Flate 207ms ±19% 200ms ±14% ~ (p=0.345 n=14+15) GoParser 246ms ±22% 240ms ±15% ~ (p=0.587 n=15+15) Reflect 611ms ±13% 587ms ±14% ~ (p=0.085 n=15+13) Tar 211ms ±12% 217ms ±14% ~ (p=0.355 n=14+15) XML 335ms ±15% 320ms ±18% ~ (p=0.169 n=15+15) [Geo mean] 317ms 583ms +83.72% name old alloc/op new alloc/op delta Template 40.2MB ± 0% 40.2MB ± 0% -0.15% (p=0.000 n=14+15) Unicode 29.2MB ± 0% 29.3MB ± 0% ~ (p=0.624 n=15+15) GoTypes 114MB ± 0% 114MB ± 0% -0.15% (p=0.000 n=15+14) Flate 25.7MB ± 0% 25.6MB ± 0% -0.18% (p=0.000 n=13+15) GoParser 32.2MB ± 0% 32.2MB ± 0% -0.14% (p=0.003 n=15+15) Reflect 77.8MB ± 0% 77.9MB ± 0% ~ (p=0.061 n=15+15) Tar 27.1MB ± 0% 27.0MB ± 0% -0.11% (p=0.029 n=15+15) XML 42.7MB ± 0% 42.5MB ± 0% -0.29% (p=0.000 n=15+15) [Geo mean] 42.1MB 75.0MB +78.05% name old allocs/op new allocs/op delta Template 402k ± 1% 398k ± 0% -0.91% (p=0.000 n=15+15) Unicode 344k ± 1% 344k ± 0% ~ (p=0.715 n=15+14) GoTypes 1.18M ± 0% 1.17M ± 0% -0.91% (p=0.000 n=15+14) Flate 243k ± 0% 240k ± 1% -1.05% (p=0.000 n=13+15) GoParser 327k ± 1% 324k ± 1% -0.96% (p=0.000 n=15+15) Reflect 984k ± 1% 982k ± 0% ~ (p=0.050 n=15+15) Tar 261k ± 1% 259k ± 1% -0.77% (p=0.000 n=15+15) XML 411k ± 0% 404k ± 1% -1.55% (p=0.000 n=15+15) [Geo mean] 439k 755k +72.01% name old text-bytes new text-bytes delta HelloSize 694kB ± 0% 694kB ± 0% -0.00% (p=0.000 n=15+15) name old data-bytes new data-bytes delta HelloSize 5.55kB ± 0% 5.55kB ± 0% ~ (all equal) name old bss-bytes new bss-bytes delta HelloSize 133kB ± 0% 133kB ± 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 1.04MB ± 0% 1.04MB ± 0% ~ (all equal) Change-Id: I991fc553ef175db46bb23b2128317bbd48de70d8 Reviewed-on: https://go-review.googlesource.com/41770 Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
2017-07-21 18:30:19 -04:00
// Pre-clobber destination. This avoids the
// following situation:
// - v is currently held in R0 and stacktmp0.
// - We want to copy stacktmp1 to stacktmp0.
// - We choose R0 as the temporary register.
// During the copy, both R0 and stacktmp0 are
// clobbered, losing both copies of v. Oops!
// Erasing the destination early means R0 will not
// be chosen as the temp register, as it will then
// be the last copy of v.
e.erase(loc)
var x *Value
cmd/compile: prefer rematerialization to copying Fixes #24132 name old time/op new time/op delta BinaryTree17-8 2.18s ± 2% 2.15s ± 2% -1.28% (p=0.000 n=25+26) Fannkuch11-8 2.16s ± 3% 2.13s ± 3% -1.54% (p=0.000 n=27+30) FmtFprintfEmpty-8 29.9ns ± 3% 29.6ns ± 3% -1.08% (p=0.001 n=29+26) FmtFprintfString-8 53.6ns ± 2% 54.0ns ± 4% ~ (p=0.193 n=28+29) FmtFprintfInt-8 56.8ns ± 3% 57.0ns ± 3% ~ (p=0.330 n=29+29) FmtFprintfIntInt-8 85.3ns ± 2% 85.8ns ± 3% +0.56% (p=0.042 n=30+29) FmtFprintfPrefixedInt-8 94.1ns ± 5% 99.0ns ± 8% +5.20% (p=0.000 n=27+30) FmtFprintfFloat-8 183ns ± 4% 182ns ± 3% ~ (p=0.619 n=30+26) FmtManyArgs-8 369ns ± 2% 369ns ± 2% ~ (p=0.748 n=27+29) GobDecode-8 4.78ms ± 2% 4.75ms ± 1% ~ (p=0.051 n=28+27) GobEncode-8 4.06ms ± 3% 4.07ms ± 3% ~ (p=0.781 n=29+30) Gzip-8 178ms ± 2% 177ms ± 2% ~ (p=0.171 n=29+30) Gunzip-8 28.2ms ± 7% 28.0ms ± 4% ~ (p=0.155 n=30+30) HTTPClientServer-8 71.5µs ± 3% 71.3µs ± 1% ~ (p=0.913 n=25+27) JSONEncode-8 9.71ms ± 5% 9.86ms ± 4% +1.55% (p=0.015 n=28+30) JSONDecode-8 38.8ms ± 2% 39.3ms ± 2% +1.41% (p=0.000 n=28+29) Mandelbrot200-8 3.47ms ± 6% 3.44ms ± 3% ~ (p=0.183 n=28+28) GoParse-8 2.55ms ± 2% 2.54ms ± 3% -0.58% (p=0.003 n=27+29) RegexpMatchEasy0_32-8 66.0ns ± 5% 65.3ns ± 4% ~ (p=0.124 n=30+30) RegexpMatchEasy0_1K-8 152ns ± 2% 152ns ± 3% ~ (p=0.881 n=30+30) RegexpMatchEasy1_32-8 62.9ns ± 9% 62.7ns ± 7% ~ (p=0.717 n=30+30) RegexpMatchEasy1_1K-8 263ns ± 3% 263ns ± 4% ~ (p=0.909 n=30+29) RegexpMatchMedium_32-8 93.4ns ± 3% 89.3ns ± 2% -4.32% (p=0.000 n=29+29) RegexpMatchMedium_1K-8 27.5µs ± 3% 27.1µs ± 2% -1.46% (p=0.000 n=30+27) RegexpMatchHard_32-8 1.33µs ± 3% 1.31µs ± 3% -1.50% (p=0.000 n=27+28) RegexpMatchHard_1K-8 39.4µs ± 2% 39.1µs ± 2% -0.54% (p=0.027 n=28+28) Revcomp-8 274ms ± 4% 276ms ± 2% +0.67% (p=0.048 n=29+28) Template-8 45.1ms ± 5% 44.6ms ± 7% -1.22% (p=0.029 n=30+29) TimeParse-8 227ns ± 3% 224ns ± 3% -1.25% (p=0.000 n=28+27) TimeFormat-8 248ns ± 3% 245ns ± 3% -1.33% (p=0.002 n=30+29) [Geo mean] 36.6µs 36.5µs -0.32% Change-Id: I24083f0013506b77e2d9da99c40ae2f67803285e Reviewed-on: https://go-review.googlesource.com/101076 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2018-03-15 22:40:23 -07:00
if c == nil || e.s.values[vid].rematerializeable {
if !e.s.values[vid].rematerializeable {
e.s.f.Fatalf("can't find source for %s->%s: %s\n", e.p, e.b, v.LongString())
}
if dstReg {
cmd/compile: assign and preserve statement boundaries. A new pass run after ssa building (before any other optimization) identifies the "first" ssa node for each statement. Other "noise" nodes are tagged as being never appropriate for a statement boundary (e.g., VarKill, VarDef, Phi). Rewrite, deadcode, cse, and nilcheck are modified to move the statement boundaries forward whenever possible if a boundary-tagged ssa value is removed; never-boundary nodes are ignored in this search (some operations involving constants are also tagged as never-boundary and also ignored because they are likely to be moved or removed during optimization). Code generation treats all nodes except those explicitly marked as statement boundaries as "not statement" nodes, and floats statement boundaries to the beginning of each same-line run of instructions found within a basic block. Line number html conversion was modified to make statement boundary nodes a bit more obvious by prepending a "+". The code in fuse.go that glued together the value slices of two blocks produced a result that depended on the former capacities (not lengths) of the two slices. This causes differences in the 386 bootstrap, and also can sometimes put values into an order that does a worse job of preserving statement boundaries when values are removed. Portions of two delve tests that had caught problems were incorporated into ssa/debug_test.go. There are some opportunities to do better with optimized code, but the next-ing is not lying or overly jumpy. Over 4 CLs, compilebench geomean measured binary size increase of 3.5% and compile user time increase of 3.8% (this is after optimization to reuse a sparse map instead of creating multiple maps.) This CL worsens the optimized-debugging experience with Delve; we need to work with the delve team so that they can use the is_stmt marks that we're emitting now. The reference output changes from time to time depending on other changes in the compiler, sometimes better, sometimes worse. This CL now includes a test ensuring that 99+% of the lines in the Go command itself (a handy optimized binary) include is_stmt markers. Change-Id: I359c94e06843f1eb41f9da437bd614885aa9644a Reviewed-on: https://go-review.googlesource.com/102435 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
2018-03-23 22:46:06 -04:00
x = v.copyInto(e.p)
} else {
// Rematerialize into stack slot. Need a free
// register to accomplish this.
r := e.findRegFor(v.Type)
[dev.debug] cmd/compile: better DWARF with optimizations on Debuggers use DWARF information to find local variables on the stack and in registers. Prior to this CL, the DWARF information for functions claimed that all variables were on the stack at all times. That's incorrect when optimizations are enabled, and results in debuggers showing data that is out of date or complete gibberish. After this CL, the compiler is capable of representing variable locations more accurately, and attempts to do so. Due to limitations of the SSA backend, it's not possible to be completely correct. There are a number of problems in the current design. One of the easier to understand is that variable names currently must be attached to an SSA value, but not all assignments in the source code actually result in machine code. For example: type myint int var a int b := myint(int) and b := (*uint64)(unsafe.Pointer(a)) don't generate machine code because the underlying representation is the same, so the correct value of b will not be set when the user would expect. Generating the more precise debug information is behind a flag, dwarflocationlists. Because of the issues described above, setting the flag may not make the debugging experience much better, and may actually make it worse in cases where the variable actually is on the stack and the more complicated analysis doesn't realize it. A number of changes are included: - Add a new pseudo-instruction, RegKill, which indicates that the value in the register has been clobbered. - Adjust regalloc to emit RegKills in the right places. Significantly, this means that phis are mixed with StoreReg and RegKills after regalloc. - Track variable decomposition in ssa.LocalSlots. - After the SSA backend is done, analyze the result and build location lists for each LocalSlot. - After assembly is done, update the location lists with the assembled PC offsets, recompose variables, and build DWARF location lists. Emit the list as a new linker symbol, one per function. - In the linker, aggregate the location lists into a .debug_loc section. TODO: - currently disabled for non-X86/AMD64 because there are no data tables. go build -toolexec 'toolstash -cmp' -a std succeeds. With -dwarflocationlists false: before: f02812195637909ff675782c0b46836a8ff01976 after: 06f61e8112a42ac34fb80e0c818b3cdb84a5e7ec benchstat -geomean /tmp/220352263 /tmp/621364410 completed 15 of 15, estimated time remaining 0s (eta 3:52PM) name old time/op new time/op delta Template 199ms ± 3% 198ms ± 2% ~ (p=0.400 n=15+14) Unicode 96.6ms ± 5% 96.4ms ± 5% ~ (p=0.838 n=15+15) GoTypes 653ms ± 2% 647ms ± 2% ~ (p=0.102 n=15+14) Flate 133ms ± 6% 129ms ± 3% -2.62% (p=0.041 n=15+15) GoParser 164ms ± 5% 159ms ± 3% -3.05% (p=0.000 n=15+15) Reflect 428ms ± 4% 422ms ± 3% ~ (p=0.156 n=15+13) Tar 123ms ±10% 124ms ± 8% ~ (p=0.461 n=15+15) XML 228ms ± 3% 224ms ± 3% -1.57% (p=0.045 n=15+15) [Geo mean] 206ms 377ms +82.86% name old user-time/op new user-time/op delta Template 292ms ±10% 301ms ±12% ~ (p=0.189 n=15+15) Unicode 166ms ±37% 158ms ±14% ~ (p=0.418 n=15+14) GoTypes 962ms ± 6% 963ms ± 7% ~ (p=0.976 n=15+15) Flate 207ms ±19% 200ms ±14% ~ (p=0.345 n=14+15) GoParser 246ms ±22% 240ms ±15% ~ (p=0.587 n=15+15) Reflect 611ms ±13% 587ms ±14% ~ (p=0.085 n=15+13) Tar 211ms ±12% 217ms ±14% ~ (p=0.355 n=14+15) XML 335ms ±15% 320ms ±18% ~ (p=0.169 n=15+15) [Geo mean] 317ms 583ms +83.72% name old alloc/op new alloc/op delta Template 40.2MB ± 0% 40.2MB ± 0% -0.15% (p=0.000 n=14+15) Unicode 29.2MB ± 0% 29.3MB ± 0% ~ (p=0.624 n=15+15) GoTypes 114MB ± 0% 114MB ± 0% -0.15% (p=0.000 n=15+14) Flate 25.7MB ± 0% 25.6MB ± 0% -0.18% (p=0.000 n=13+15) GoParser 32.2MB ± 0% 32.2MB ± 0% -0.14% (p=0.003 n=15+15) Reflect 77.8MB ± 0% 77.9MB ± 0% ~ (p=0.061 n=15+15) Tar 27.1MB ± 0% 27.0MB ± 0% -0.11% (p=0.029 n=15+15) XML 42.7MB ± 0% 42.5MB ± 0% -0.29% (p=0.000 n=15+15) [Geo mean] 42.1MB 75.0MB +78.05% name old allocs/op new allocs/op delta Template 402k ± 1% 398k ± 0% -0.91% (p=0.000 n=15+15) Unicode 344k ± 1% 344k ± 0% ~ (p=0.715 n=15+14) GoTypes 1.18M ± 0% 1.17M ± 0% -0.91% (p=0.000 n=15+14) Flate 243k ± 0% 240k ± 1% -1.05% (p=0.000 n=13+15) GoParser 327k ± 1% 324k ± 1% -0.96% (p=0.000 n=15+15) Reflect 984k ± 1% 982k ± 0% ~ (p=0.050 n=15+15) Tar 261k ± 1% 259k ± 1% -0.77% (p=0.000 n=15+15) XML 411k ± 0% 404k ± 1% -1.55% (p=0.000 n=15+15) [Geo mean] 439k 755k +72.01% name old text-bytes new text-bytes delta HelloSize 694kB ± 0% 694kB ± 0% -0.00% (p=0.000 n=15+15) name old data-bytes new data-bytes delta HelloSize 5.55kB ± 0% 5.55kB ± 0% ~ (all equal) name old bss-bytes new bss-bytes delta HelloSize 133kB ± 0% 133kB ± 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 1.04MB ± 0% 1.04MB ± 0% ~ (all equal) Change-Id: I991fc553ef175db46bb23b2128317bbd48de70d8 Reviewed-on: https://go-review.googlesource.com/41770 Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
2017-07-21 18:30:19 -04:00
e.erase(r)
x = v.copyIntoWithXPos(e.p, pos)
e.set(r, vid, x, false, pos)
// Make sure we spill with the size of the slot, not the
// size of x (which might be wider due to our dropping
// of narrowing conversions).
x = e.p.NewValue1(pos, OpStoreReg, loc.(LocalSlot).Type, x)
}
} else {
// Emit move from src to dst.
_, srcReg := src.(*Register)
if srcReg {
if dstReg {
x = e.p.NewValue1(pos, OpCopy, c.Type, c)
} else {
x = e.p.NewValue1(pos, OpStoreReg, loc.(LocalSlot).Type, c)
}
} else {
if dstReg {
x = e.p.NewValue1(pos, OpLoadReg, c.Type, c)
} else {
// mem->mem. Use temp register.
r := e.findRegFor(c.Type)
[dev.debug] cmd/compile: better DWARF with optimizations on Debuggers use DWARF information to find local variables on the stack and in registers. Prior to this CL, the DWARF information for functions claimed that all variables were on the stack at all times. That's incorrect when optimizations are enabled, and results in debuggers showing data that is out of date or complete gibberish. After this CL, the compiler is capable of representing variable locations more accurately, and attempts to do so. Due to limitations of the SSA backend, it's not possible to be completely correct. There are a number of problems in the current design. One of the easier to understand is that variable names currently must be attached to an SSA value, but not all assignments in the source code actually result in machine code. For example: type myint int var a int b := myint(int) and b := (*uint64)(unsafe.Pointer(a)) don't generate machine code because the underlying representation is the same, so the correct value of b will not be set when the user would expect. Generating the more precise debug information is behind a flag, dwarflocationlists. Because of the issues described above, setting the flag may not make the debugging experience much better, and may actually make it worse in cases where the variable actually is on the stack and the more complicated analysis doesn't realize it. A number of changes are included: - Add a new pseudo-instruction, RegKill, which indicates that the value in the register has been clobbered. - Adjust regalloc to emit RegKills in the right places. Significantly, this means that phis are mixed with StoreReg and RegKills after regalloc. - Track variable decomposition in ssa.LocalSlots. - After the SSA backend is done, analyze the result and build location lists for each LocalSlot. - After assembly is done, update the location lists with the assembled PC offsets, recompose variables, and build DWARF location lists. Emit the list as a new linker symbol, one per function. - In the linker, aggregate the location lists into a .debug_loc section. TODO: - currently disabled for non-X86/AMD64 because there are no data tables. go build -toolexec 'toolstash -cmp' -a std succeeds. With -dwarflocationlists false: before: f02812195637909ff675782c0b46836a8ff01976 after: 06f61e8112a42ac34fb80e0c818b3cdb84a5e7ec benchstat -geomean /tmp/220352263 /tmp/621364410 completed 15 of 15, estimated time remaining 0s (eta 3:52PM) name old time/op new time/op delta Template 199ms ± 3% 198ms ± 2% ~ (p=0.400 n=15+14) Unicode 96.6ms ± 5% 96.4ms ± 5% ~ (p=0.838 n=15+15) GoTypes 653ms ± 2% 647ms ± 2% ~ (p=0.102 n=15+14) Flate 133ms ± 6% 129ms ± 3% -2.62% (p=0.041 n=15+15) GoParser 164ms ± 5% 159ms ± 3% -3.05% (p=0.000 n=15+15) Reflect 428ms ± 4% 422ms ± 3% ~ (p=0.156 n=15+13) Tar 123ms ±10% 124ms ± 8% ~ (p=0.461 n=15+15) XML 228ms ± 3% 224ms ± 3% -1.57% (p=0.045 n=15+15) [Geo mean] 206ms 377ms +82.86% name old user-time/op new user-time/op delta Template 292ms ±10% 301ms ±12% ~ (p=0.189 n=15+15) Unicode 166ms ±37% 158ms ±14% ~ (p=0.418 n=15+14) GoTypes 962ms ± 6% 963ms ± 7% ~ (p=0.976 n=15+15) Flate 207ms ±19% 200ms ±14% ~ (p=0.345 n=14+15) GoParser 246ms ±22% 240ms ±15% ~ (p=0.587 n=15+15) Reflect 611ms ±13% 587ms ±14% ~ (p=0.085 n=15+13) Tar 211ms ±12% 217ms ±14% ~ (p=0.355 n=14+15) XML 335ms ±15% 320ms ±18% ~ (p=0.169 n=15+15) [Geo mean] 317ms 583ms +83.72% name old alloc/op new alloc/op delta Template 40.2MB ± 0% 40.2MB ± 0% -0.15% (p=0.000 n=14+15) Unicode 29.2MB ± 0% 29.3MB ± 0% ~ (p=0.624 n=15+15) GoTypes 114MB ± 0% 114MB ± 0% -0.15% (p=0.000 n=15+14) Flate 25.7MB ± 0% 25.6MB ± 0% -0.18% (p=0.000 n=13+15) GoParser 32.2MB ± 0% 32.2MB ± 0% -0.14% (p=0.003 n=15+15) Reflect 77.8MB ± 0% 77.9MB ± 0% ~ (p=0.061 n=15+15) Tar 27.1MB ± 0% 27.0MB ± 0% -0.11% (p=0.029 n=15+15) XML 42.7MB ± 0% 42.5MB ± 0% -0.29% (p=0.000 n=15+15) [Geo mean] 42.1MB 75.0MB +78.05% name old allocs/op new allocs/op delta Template 402k ± 1% 398k ± 0% -0.91% (p=0.000 n=15+15) Unicode 344k ± 1% 344k ± 0% ~ (p=0.715 n=15+14) GoTypes 1.18M ± 0% 1.17M ± 0% -0.91% (p=0.000 n=15+14) Flate 243k ± 0% 240k ± 1% -1.05% (p=0.000 n=13+15) GoParser 327k ± 1% 324k ± 1% -0.96% (p=0.000 n=15+15) Reflect 984k ± 1% 982k ± 0% ~ (p=0.050 n=15+15) Tar 261k ± 1% 259k ± 1% -0.77% (p=0.000 n=15+15) XML 411k ± 0% 404k ± 1% -1.55% (p=0.000 n=15+15) [Geo mean] 439k 755k +72.01% name old text-bytes new text-bytes delta HelloSize 694kB ± 0% 694kB ± 0% -0.00% (p=0.000 n=15+15) name old data-bytes new data-bytes delta HelloSize 5.55kB ± 0% 5.55kB ± 0% ~ (all equal) name old bss-bytes new bss-bytes delta HelloSize 133kB ± 0% 133kB ± 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 1.04MB ± 0% 1.04MB ± 0% ~ (all equal) Change-Id: I991fc553ef175db46bb23b2128317bbd48de70d8 Reviewed-on: https://go-review.googlesource.com/41770 Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
2017-07-21 18:30:19 -04:00
e.erase(r)
t := e.p.NewValue1(pos, OpLoadReg, c.Type, c)
e.set(r, vid, t, false, pos)
x = e.p.NewValue1(pos, OpStoreReg, loc.(LocalSlot).Type, t)
}
}
}
e.set(loc, vid, x, true, pos)
if x.Op == OpLoadReg && e.s.isGReg(register(loc.(*Register).num)) {
e.s.f.Fatalf("processDest.OpLoadReg targeting g: " + x.LongString())
}
if splice != nil {
(*splice).Uses--
*splice = x
x.Uses++
}
return true
}
// set changes the contents of location loc to hold the given value and its cached representative.
2016-12-15 17:17:01 -08:00
func (e *edgeState) set(loc Location, vid ID, c *Value, final bool, pos src.XPos) {
e.s.f.setHome(c, loc)
e.contents[loc] = contentRecord{vid, c, final, pos}
a := e.cache[vid]
if len(a) == 0 {
e.cachedVals = append(e.cachedVals, vid)
}
a = append(a, c)
e.cache[vid] = a
if r, ok := loc.(*Register); ok {
if e.usedRegs&(regMask(1)<<uint(r.num)) != 0 {
e.s.f.Fatalf("%v is already set (v%d/%v)", r, vid, c)
}
e.usedRegs |= regMask(1) << uint(r.num)
if final {
e.finalRegs |= regMask(1) << uint(r.num)
}
if len(a) == 1 {
e.uniqueRegs |= regMask(1) << uint(r.num)
}
if len(a) == 2 {
if t, ok := e.s.f.getHome(a[0].ID).(*Register); ok {
e.uniqueRegs &^= regMask(1) << uint(t.num)
}
}
cmd/compile: prefer to evict a rematerializable register This resolves a long-standing regalloc TODO: If you must evict a register, choose to evict a register containing a rematerializable value, since that value won't need to be spilled. Provides very minor performance and size improvements. name old time/op new time/op delta BinaryTree17-8 2.20s ± 3% 2.18s ± 2% -0.77% (p=0.000 n=45+49) Fannkuch11-8 2.14s ± 2% 2.15s ± 2% +0.73% (p=0.000 n=43+44) FmtFprintfEmpty-8 30.6ns ± 4% 30.2ns ± 3% -1.14% (p=0.000 n=50+48) FmtFprintfString-8 54.5ns ± 6% 53.6ns ± 5% -1.64% (p=0.001 n=50+48) FmtFprintfInt-8 58.0ns ± 7% 57.6ns ± 4% ~ (p=0.220 n=50+50) FmtFprintfIntInt-8 85.3ns ± 2% 84.8ns ± 3% -0.62% (p=0.001 n=44+47) FmtFprintfPrefixedInt-8 93.9ns ± 6% 93.6ns ± 5% ~ (p=0.706 n=50+48) FmtFprintfFloat-8 178ns ± 4% 177ns ± 4% ~ (p=0.107 n=49+50) FmtManyArgs-8 376ns ± 4% 374ns ± 3% -0.58% (p=0.013 n=45+50) GobDecode-8 4.77ms ± 2% 4.76ms ± 3% ~ (p=0.059 n=47+46) GobEncode-8 4.04ms ± 2% 3.99ms ± 3% -1.13% (p=0.000 n=49+49) Gzip-8 177ms ± 2% 180ms ± 3% +1.43% (p=0.000 n=48+48) Gunzip-8 28.5ms ± 6% 28.3ms ± 5% ~ (p=0.104 n=50+49) HTTPClientServer-8 72.1µs ± 1% 72.0µs ± 1% -0.15% (p=0.042 n=48+42) JSONEncode-8 9.81ms ± 5% 10.03ms ± 6% +2.29% (p=0.000 n=50+49) JSONDecode-8 39.2ms ± 3% 39.3ms ± 2% ~ (p=0.095 n=49+49) Mandelbrot200-8 3.48ms ± 2% 3.46ms ± 2% -0.80% (p=0.000 n=47+48) GoParse-8 2.54ms ± 3% 2.51ms ± 3% -1.35% (p=0.000 n=49+49) RegexpMatchEasy0_32-8 66.0ns ± 7% 65.7ns ± 8% ~ (p=0.331 n=50+50) RegexpMatchEasy0_1K-8 155ns ± 4% 154ns ± 4% ~ (p=0.986 n=49+50) RegexpMatchEasy1_32-8 62.6ns ± 8% 62.2ns ± 5% ~ (p=0.395 n=50+49) RegexpMatchEasy1_1K-8 260ns ± 5% 255ns ± 3% -1.92% (p=0.000 n=49+49) RegexpMatchMedium_32-8 92.9ns ± 2% 91.8ns ± 2% -1.25% (p=0.000 n=46+48) RegexpMatchMedium_1K-8 27.7µs ± 3% 27.0µs ± 2% -2.59% (p=0.000 n=49+49) RegexpMatchHard_32-8 1.23µs ± 4% 1.21µs ± 2% -2.16% (p=0.000 n=49+44) RegexpMatchHard_1K-8 36.4µs ± 2% 35.7µs ± 2% -1.87% (p=0.000 n=48+49) Revcomp-8 274ms ± 2% 276ms ± 3% +0.70% (p=0.034 n=45+48) Template-8 45.1ms ± 8% 45.1ms ± 8% ~ (p=0.643 n=50+50) TimeParse-8 223ns ± 2% 223ns ± 2% ~ (p=0.401 n=47+47) TimeFormat-8 245ns ± 2% 246ns ± 3% ~ (p=0.758 n=49+50) [Geo mean] 36.5µs 36.3µs -0.54% name old object-bytes new object-bytes delta Template 480kB ± 0% 480kB ± 0% ~ (all equal) Unicode 214kB ± 0% 214kB ± 0% ~ (all equal) GoTypes 1.54MB ± 0% 1.54MB ± 0% -0.03% (p=0.008 n=5+5) Compiler 5.75MB ± 0% 5.75MB ± 0% ~ (all equal) SSA 14.6MB ± 0% 14.6MB ± 0% -0.01% (p=0.008 n=5+5) Flate 300kB ± 0% 300kB ± 0% -0.01% (p=0.008 n=5+5) GoParser 366kB ± 0% 366kB ± 0% ~ (all equal) Reflect 1.20MB ± 0% 1.20MB ± 0% ~ (all equal) Tar 413kB ± 0% 413kB ± 0% ~ (all equal) XML 529kB ± 0% 528kB ± 0% -0.13% (p=0.008 n=5+5) [Geo mean] 909kB 909kB -0.02% Change-Id: I46d37a55197683a98913f35801dc2b0d609653c8 Reviewed-on: https://go-review.googlesource.com/103240 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2018-03-16 07:15:59 -07:00
if e.s.values[vid].rematerializeable {
e.rematerializeableRegs |= regMask(1) << uint(r.num)
}
}
if e.s.f.pass.debug > regDebug {
fmt.Printf("%s\n", c.LongString())
fmt.Printf("v%d now available in %s:%s\n", vid, loc, c)
}
}
// erase removes any user of loc.
func (e *edgeState) erase(loc Location) {
cr := e.contents[loc]
if cr.c == nil {
return
}
vid := cr.vid
if cr.final {
// Add a destination to move this value back into place.
// Make sure it gets added to the tail of the destination queue
// so we make progress on other moves first.
e.extra = append(e.extra, dstRecord{loc, cr.vid, nil, cr.pos})
}
// Remove c from the list of cached values.
a := e.cache[vid]
for i, c := range a {
if e.s.f.getHome(c.ID) == loc {
if e.s.f.pass.debug > regDebug {
fmt.Printf("v%d no longer available in %s:%s\n", vid, loc, c)
}
a[i], a = a[len(a)-1], a[:len(a)-1]
break
}
}
e.cache[vid] = a
// Update register masks.
if r, ok := loc.(*Register); ok {
e.usedRegs &^= regMask(1) << uint(r.num)
if cr.final {
e.finalRegs &^= regMask(1) << uint(r.num)
}
cmd/compile: prefer to evict a rematerializable register This resolves a long-standing regalloc TODO: If you must evict a register, choose to evict a register containing a rematerializable value, since that value won't need to be spilled. Provides very minor performance and size improvements. name old time/op new time/op delta BinaryTree17-8 2.20s ± 3% 2.18s ± 2% -0.77% (p=0.000 n=45+49) Fannkuch11-8 2.14s ± 2% 2.15s ± 2% +0.73% (p=0.000 n=43+44) FmtFprintfEmpty-8 30.6ns ± 4% 30.2ns ± 3% -1.14% (p=0.000 n=50+48) FmtFprintfString-8 54.5ns ± 6% 53.6ns ± 5% -1.64% (p=0.001 n=50+48) FmtFprintfInt-8 58.0ns ± 7% 57.6ns ± 4% ~ (p=0.220 n=50+50) FmtFprintfIntInt-8 85.3ns ± 2% 84.8ns ± 3% -0.62% (p=0.001 n=44+47) FmtFprintfPrefixedInt-8 93.9ns ± 6% 93.6ns ± 5% ~ (p=0.706 n=50+48) FmtFprintfFloat-8 178ns ± 4% 177ns ± 4% ~ (p=0.107 n=49+50) FmtManyArgs-8 376ns ± 4% 374ns ± 3% -0.58% (p=0.013 n=45+50) GobDecode-8 4.77ms ± 2% 4.76ms ± 3% ~ (p=0.059 n=47+46) GobEncode-8 4.04ms ± 2% 3.99ms ± 3% -1.13% (p=0.000 n=49+49) Gzip-8 177ms ± 2% 180ms ± 3% +1.43% (p=0.000 n=48+48) Gunzip-8 28.5ms ± 6% 28.3ms ± 5% ~ (p=0.104 n=50+49) HTTPClientServer-8 72.1µs ± 1% 72.0µs ± 1% -0.15% (p=0.042 n=48+42) JSONEncode-8 9.81ms ± 5% 10.03ms ± 6% +2.29% (p=0.000 n=50+49) JSONDecode-8 39.2ms ± 3% 39.3ms ± 2% ~ (p=0.095 n=49+49) Mandelbrot200-8 3.48ms ± 2% 3.46ms ± 2% -0.80% (p=0.000 n=47+48) GoParse-8 2.54ms ± 3% 2.51ms ± 3% -1.35% (p=0.000 n=49+49) RegexpMatchEasy0_32-8 66.0ns ± 7% 65.7ns ± 8% ~ (p=0.331 n=50+50) RegexpMatchEasy0_1K-8 155ns ± 4% 154ns ± 4% ~ (p=0.986 n=49+50) RegexpMatchEasy1_32-8 62.6ns ± 8% 62.2ns ± 5% ~ (p=0.395 n=50+49) RegexpMatchEasy1_1K-8 260ns ± 5% 255ns ± 3% -1.92% (p=0.000 n=49+49) RegexpMatchMedium_32-8 92.9ns ± 2% 91.8ns ± 2% -1.25% (p=0.000 n=46+48) RegexpMatchMedium_1K-8 27.7µs ± 3% 27.0µs ± 2% -2.59% (p=0.000 n=49+49) RegexpMatchHard_32-8 1.23µs ± 4% 1.21µs ± 2% -2.16% (p=0.000 n=49+44) RegexpMatchHard_1K-8 36.4µs ± 2% 35.7µs ± 2% -1.87% (p=0.000 n=48+49) Revcomp-8 274ms ± 2% 276ms ± 3% +0.70% (p=0.034 n=45+48) Template-8 45.1ms ± 8% 45.1ms ± 8% ~ (p=0.643 n=50+50) TimeParse-8 223ns ± 2% 223ns ± 2% ~ (p=0.401 n=47+47) TimeFormat-8 245ns ± 2% 246ns ± 3% ~ (p=0.758 n=49+50) [Geo mean] 36.5µs 36.3µs -0.54% name old object-bytes new object-bytes delta Template 480kB ± 0% 480kB ± 0% ~ (all equal) Unicode 214kB ± 0% 214kB ± 0% ~ (all equal) GoTypes 1.54MB ± 0% 1.54MB ± 0% -0.03% (p=0.008 n=5+5) Compiler 5.75MB ± 0% 5.75MB ± 0% ~ (all equal) SSA 14.6MB ± 0% 14.6MB ± 0% -0.01% (p=0.008 n=5+5) Flate 300kB ± 0% 300kB ± 0% -0.01% (p=0.008 n=5+5) GoParser 366kB ± 0% 366kB ± 0% ~ (all equal) Reflect 1.20MB ± 0% 1.20MB ± 0% ~ (all equal) Tar 413kB ± 0% 413kB ± 0% ~ (all equal) XML 529kB ± 0% 528kB ± 0% -0.13% (p=0.008 n=5+5) [Geo mean] 909kB 909kB -0.02% Change-Id: I46d37a55197683a98913f35801dc2b0d609653c8 Reviewed-on: https://go-review.googlesource.com/103240 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2018-03-16 07:15:59 -07:00
e.rematerializeableRegs &^= regMask(1) << uint(r.num)
}
if len(a) == 1 {
if r, ok := e.s.f.getHome(a[0].ID).(*Register); ok {
e.uniqueRegs |= regMask(1) << uint(r.num)
}
}
}
// findRegFor finds a register we can use to make a temp copy of type typ.
cmd/compile: change ssa.Type into *types.Type When package ssa was created, Type was in package gc. To avoid circular dependencies, we used an interface (ssa.Type) to represent type information in SSA. In the Go 1.9 cycle, gri extricated the Type type from package gc. As a result, we can now use it in package ssa. Now, instead of package types depending on package ssa, it is the other way. This is a more sensible dependency tree, and helps compiler performance a bit. Though this is a big CL, most of the changes are mechanical and uninteresting. Interesting bits: * Add new singleton globals to package types for the special SSA types Memory, Void, Invalid, Flags, and Int128. * Add two new Types, TSSA for the special types, and TTUPLE, for SSA tuple types. ssa.MakeTuple is now types.NewTuple. * Move type comparison result constants CMPlt, CMPeq, and CMPgt to package types. * We had picked the name "types" in our rules for the handy list of types provided by ssa.Config. That conflicted with the types package name, so change it to "typ". * Update the type comparison routine to handle tuples and special types inline. * Teach gc/fmt.go how to print special types. * We can now eliminate ElemTypes in favor of just Elem, and probably also some other duplicated Type methods designed to return ssa.Type instead of *types.Type. * The ssa tests were using their own dummy types, and they were not particularly careful about types in general. Of necessity, this CL switches them to use *types.Type; it does not make them more type-accurate. Unfortunately, using types.Type means initializing a bit of the types universe. This is prime for refactoring and improvement. This shrinks ssa.Value; it now fits in a smaller size class on 64 bit systems. This doesn't have a giant impact, though, since most Values are preallocated in a chunk. name old alloc/op new alloc/op delta Template 37.9MB ± 0% 37.7MB ± 0% -0.57% (p=0.000 n=10+8) Unicode 28.9MB ± 0% 28.7MB ± 0% -0.52% (p=0.000 n=10+10) GoTypes 110MB ± 0% 109MB ± 0% -0.88% (p=0.000 n=10+10) Flate 24.7MB ± 0% 24.6MB ± 0% -0.66% (p=0.000 n=10+10) GoParser 31.1MB ± 0% 30.9MB ± 0% -0.61% (p=0.000 n=10+9) Reflect 73.9MB ± 0% 73.4MB ± 0% -0.62% (p=0.000 n=10+8) Tar 25.8MB ± 0% 25.6MB ± 0% -0.77% (p=0.000 n=9+10) XML 41.2MB ± 0% 40.9MB ± 0% -0.80% (p=0.000 n=10+10) [Geo mean] 40.5MB 40.3MB -0.68% name old allocs/op new allocs/op delta Template 385k ± 0% 386k ± 0% ~ (p=0.356 n=10+9) Unicode 343k ± 1% 344k ± 0% ~ (p=0.481 n=10+10) GoTypes 1.16M ± 0% 1.16M ± 0% -0.16% (p=0.004 n=10+10) Flate 238k ± 1% 238k ± 1% ~ (p=0.853 n=10+10) GoParser 320k ± 0% 320k ± 0% ~ (p=0.720 n=10+9) Reflect 957k ± 0% 957k ± 0% ~ (p=0.460 n=10+8) Tar 252k ± 0% 252k ± 0% ~ (p=0.133 n=9+10) XML 400k ± 0% 400k ± 0% ~ (p=0.796 n=10+10) [Geo mean] 428k 428k -0.01% Removing all the interface calls helps non-trivially with CPU, though. name old time/op new time/op delta Template 178ms ± 4% 173ms ± 3% -2.90% (p=0.000 n=94+96) Unicode 85.0ms ± 4% 83.9ms ± 4% -1.23% (p=0.000 n=96+96) GoTypes 543ms ± 3% 528ms ± 3% -2.73% (p=0.000 n=98+96) Flate 116ms ± 3% 113ms ± 4% -2.34% (p=0.000 n=96+99) GoParser 144ms ± 3% 140ms ± 4% -2.80% (p=0.000 n=99+97) Reflect 344ms ± 3% 334ms ± 4% -3.02% (p=0.000 n=100+99) Tar 106ms ± 5% 103ms ± 4% -3.30% (p=0.000 n=98+94) XML 198ms ± 5% 192ms ± 4% -2.88% (p=0.000 n=92+95) [Geo mean] 178ms 173ms -2.65% name old user-time/op new user-time/op delta Template 229ms ± 5% 224ms ± 5% -2.36% (p=0.000 n=95+99) Unicode 107ms ± 6% 106ms ± 5% -1.13% (p=0.001 n=93+95) GoTypes 696ms ± 4% 679ms ± 4% -2.45% (p=0.000 n=97+99) Flate 137ms ± 4% 134ms ± 5% -2.66% (p=0.000 n=99+96) GoParser 176ms ± 5% 172ms ± 8% -2.27% (p=0.000 n=98+100) Reflect 430ms ± 6% 411ms ± 5% -4.46% (p=0.000 n=100+92) Tar 128ms ±13% 123ms ±13% -4.21% (p=0.000 n=100+100) XML 239ms ± 6% 233ms ± 6% -2.50% (p=0.000 n=95+97) [Geo mean] 220ms 213ms -2.76% Change-Id: I15c7d6268347f8358e75066dfdbd77db24e8d0c1 Reviewed-on: https://go-review.googlesource.com/42145 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2017-04-28 14:12:28 -07:00
func (e *edgeState) findRegFor(typ *types.Type) Location {
// Which registers are possibilities.
types := &e.s.f.Config.Types
m := e.s.compatRegs(typ)
// Pick a register. In priority order:
// 1) an unused register
// 2) a non-unique register not holding a final value
// 3) a non-unique register
cmd/compile: prefer to evict a rematerializable register This resolves a long-standing regalloc TODO: If you must evict a register, choose to evict a register containing a rematerializable value, since that value won't need to be spilled. Provides very minor performance and size improvements. name old time/op new time/op delta BinaryTree17-8 2.20s ± 3% 2.18s ± 2% -0.77% (p=0.000 n=45+49) Fannkuch11-8 2.14s ± 2% 2.15s ± 2% +0.73% (p=0.000 n=43+44) FmtFprintfEmpty-8 30.6ns ± 4% 30.2ns ± 3% -1.14% (p=0.000 n=50+48) FmtFprintfString-8 54.5ns ± 6% 53.6ns ± 5% -1.64% (p=0.001 n=50+48) FmtFprintfInt-8 58.0ns ± 7% 57.6ns ± 4% ~ (p=0.220 n=50+50) FmtFprintfIntInt-8 85.3ns ± 2% 84.8ns ± 3% -0.62% (p=0.001 n=44+47) FmtFprintfPrefixedInt-8 93.9ns ± 6% 93.6ns ± 5% ~ (p=0.706 n=50+48) FmtFprintfFloat-8 178ns ± 4% 177ns ± 4% ~ (p=0.107 n=49+50) FmtManyArgs-8 376ns ± 4% 374ns ± 3% -0.58% (p=0.013 n=45+50) GobDecode-8 4.77ms ± 2% 4.76ms ± 3% ~ (p=0.059 n=47+46) GobEncode-8 4.04ms ± 2% 3.99ms ± 3% -1.13% (p=0.000 n=49+49) Gzip-8 177ms ± 2% 180ms ± 3% +1.43% (p=0.000 n=48+48) Gunzip-8 28.5ms ± 6% 28.3ms ± 5% ~ (p=0.104 n=50+49) HTTPClientServer-8 72.1µs ± 1% 72.0µs ± 1% -0.15% (p=0.042 n=48+42) JSONEncode-8 9.81ms ± 5% 10.03ms ± 6% +2.29% (p=0.000 n=50+49) JSONDecode-8 39.2ms ± 3% 39.3ms ± 2% ~ (p=0.095 n=49+49) Mandelbrot200-8 3.48ms ± 2% 3.46ms ± 2% -0.80% (p=0.000 n=47+48) GoParse-8 2.54ms ± 3% 2.51ms ± 3% -1.35% (p=0.000 n=49+49) RegexpMatchEasy0_32-8 66.0ns ± 7% 65.7ns ± 8% ~ (p=0.331 n=50+50) RegexpMatchEasy0_1K-8 155ns ± 4% 154ns ± 4% ~ (p=0.986 n=49+50) RegexpMatchEasy1_32-8 62.6ns ± 8% 62.2ns ± 5% ~ (p=0.395 n=50+49) RegexpMatchEasy1_1K-8 260ns ± 5% 255ns ± 3% -1.92% (p=0.000 n=49+49) RegexpMatchMedium_32-8 92.9ns ± 2% 91.8ns ± 2% -1.25% (p=0.000 n=46+48) RegexpMatchMedium_1K-8 27.7µs ± 3% 27.0µs ± 2% -2.59% (p=0.000 n=49+49) RegexpMatchHard_32-8 1.23µs ± 4% 1.21µs ± 2% -2.16% (p=0.000 n=49+44) RegexpMatchHard_1K-8 36.4µs ± 2% 35.7µs ± 2% -1.87% (p=0.000 n=48+49) Revcomp-8 274ms ± 2% 276ms ± 3% +0.70% (p=0.034 n=45+48) Template-8 45.1ms ± 8% 45.1ms ± 8% ~ (p=0.643 n=50+50) TimeParse-8 223ns ± 2% 223ns ± 2% ~ (p=0.401 n=47+47) TimeFormat-8 245ns ± 2% 246ns ± 3% ~ (p=0.758 n=49+50) [Geo mean] 36.5µs 36.3µs -0.54% name old object-bytes new object-bytes delta Template 480kB ± 0% 480kB ± 0% ~ (all equal) Unicode 214kB ± 0% 214kB ± 0% ~ (all equal) GoTypes 1.54MB ± 0% 1.54MB ± 0% -0.03% (p=0.008 n=5+5) Compiler 5.75MB ± 0% 5.75MB ± 0% ~ (all equal) SSA 14.6MB ± 0% 14.6MB ± 0% -0.01% (p=0.008 n=5+5) Flate 300kB ± 0% 300kB ± 0% -0.01% (p=0.008 n=5+5) GoParser 366kB ± 0% 366kB ± 0% ~ (all equal) Reflect 1.20MB ± 0% 1.20MB ± 0% ~ (all equal) Tar 413kB ± 0% 413kB ± 0% ~ (all equal) XML 529kB ± 0% 528kB ± 0% -0.13% (p=0.008 n=5+5) [Geo mean] 909kB 909kB -0.02% Change-Id: I46d37a55197683a98913f35801dc2b0d609653c8 Reviewed-on: https://go-review.googlesource.com/103240 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2018-03-16 07:15:59 -07:00
// 4) a register holding a rematerializeable value
x := m &^ e.usedRegs
if x != 0 {
return &e.s.registers[pickReg(x)]
}
x = m &^ e.uniqueRegs &^ e.finalRegs
if x != 0 {
return &e.s.registers[pickReg(x)]
}
x = m &^ e.uniqueRegs
if x != 0 {
return &e.s.registers[pickReg(x)]
}
cmd/compile: prefer to evict a rematerializable register This resolves a long-standing regalloc TODO: If you must evict a register, choose to evict a register containing a rematerializable value, since that value won't need to be spilled. Provides very minor performance and size improvements. name old time/op new time/op delta BinaryTree17-8 2.20s ± 3% 2.18s ± 2% -0.77% (p=0.000 n=45+49) Fannkuch11-8 2.14s ± 2% 2.15s ± 2% +0.73% (p=0.000 n=43+44) FmtFprintfEmpty-8 30.6ns ± 4% 30.2ns ± 3% -1.14% (p=0.000 n=50+48) FmtFprintfString-8 54.5ns ± 6% 53.6ns ± 5% -1.64% (p=0.001 n=50+48) FmtFprintfInt-8 58.0ns ± 7% 57.6ns ± 4% ~ (p=0.220 n=50+50) FmtFprintfIntInt-8 85.3ns ± 2% 84.8ns ± 3% -0.62% (p=0.001 n=44+47) FmtFprintfPrefixedInt-8 93.9ns ± 6% 93.6ns ± 5% ~ (p=0.706 n=50+48) FmtFprintfFloat-8 178ns ± 4% 177ns ± 4% ~ (p=0.107 n=49+50) FmtManyArgs-8 376ns ± 4% 374ns ± 3% -0.58% (p=0.013 n=45+50) GobDecode-8 4.77ms ± 2% 4.76ms ± 3% ~ (p=0.059 n=47+46) GobEncode-8 4.04ms ± 2% 3.99ms ± 3% -1.13% (p=0.000 n=49+49) Gzip-8 177ms ± 2% 180ms ± 3% +1.43% (p=0.000 n=48+48) Gunzip-8 28.5ms ± 6% 28.3ms ± 5% ~ (p=0.104 n=50+49) HTTPClientServer-8 72.1µs ± 1% 72.0µs ± 1% -0.15% (p=0.042 n=48+42) JSONEncode-8 9.81ms ± 5% 10.03ms ± 6% +2.29% (p=0.000 n=50+49) JSONDecode-8 39.2ms ± 3% 39.3ms ± 2% ~ (p=0.095 n=49+49) Mandelbrot200-8 3.48ms ± 2% 3.46ms ± 2% -0.80% (p=0.000 n=47+48) GoParse-8 2.54ms ± 3% 2.51ms ± 3% -1.35% (p=0.000 n=49+49) RegexpMatchEasy0_32-8 66.0ns ± 7% 65.7ns ± 8% ~ (p=0.331 n=50+50) RegexpMatchEasy0_1K-8 155ns ± 4% 154ns ± 4% ~ (p=0.986 n=49+50) RegexpMatchEasy1_32-8 62.6ns ± 8% 62.2ns ± 5% ~ (p=0.395 n=50+49) RegexpMatchEasy1_1K-8 260ns ± 5% 255ns ± 3% -1.92% (p=0.000 n=49+49) RegexpMatchMedium_32-8 92.9ns ± 2% 91.8ns ± 2% -1.25% (p=0.000 n=46+48) RegexpMatchMedium_1K-8 27.7µs ± 3% 27.0µs ± 2% -2.59% (p=0.000 n=49+49) RegexpMatchHard_32-8 1.23µs ± 4% 1.21µs ± 2% -2.16% (p=0.000 n=49+44) RegexpMatchHard_1K-8 36.4µs ± 2% 35.7µs ± 2% -1.87% (p=0.000 n=48+49) Revcomp-8 274ms ± 2% 276ms ± 3% +0.70% (p=0.034 n=45+48) Template-8 45.1ms ± 8% 45.1ms ± 8% ~ (p=0.643 n=50+50) TimeParse-8 223ns ± 2% 223ns ± 2% ~ (p=0.401 n=47+47) TimeFormat-8 245ns ± 2% 246ns ± 3% ~ (p=0.758 n=49+50) [Geo mean] 36.5µs 36.3µs -0.54% name old object-bytes new object-bytes delta Template 480kB ± 0% 480kB ± 0% ~ (all equal) Unicode 214kB ± 0% 214kB ± 0% ~ (all equal) GoTypes 1.54MB ± 0% 1.54MB ± 0% -0.03% (p=0.008 n=5+5) Compiler 5.75MB ± 0% 5.75MB ± 0% ~ (all equal) SSA 14.6MB ± 0% 14.6MB ± 0% -0.01% (p=0.008 n=5+5) Flate 300kB ± 0% 300kB ± 0% -0.01% (p=0.008 n=5+5) GoParser 366kB ± 0% 366kB ± 0% ~ (all equal) Reflect 1.20MB ± 0% 1.20MB ± 0% ~ (all equal) Tar 413kB ± 0% 413kB ± 0% ~ (all equal) XML 529kB ± 0% 528kB ± 0% -0.13% (p=0.008 n=5+5) [Geo mean] 909kB 909kB -0.02% Change-Id: I46d37a55197683a98913f35801dc2b0d609653c8 Reviewed-on: https://go-review.googlesource.com/103240 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2018-03-16 07:15:59 -07:00
x = m & e.rematerializeableRegs
if x != 0 {
return &e.s.registers[pickReg(x)]
}
// No register is available.
// Pick a register to spill.
for _, vid := range e.cachedVals {
a := e.cache[vid]
for _, c := range a {
if r, ok := e.s.f.getHome(c.ID).(*Register); ok && m>>uint(r.num)&1 != 0 {
if !c.rematerializeable() {
x := e.p.NewValue1(c.Pos, OpStoreReg, c.Type, c)
// Allocate a temp location to spill a register to.
// The type of the slot is immaterial - it will not be live across
// any safepoint. Just use a type big enough to hold any register.
t := LocalSlot{N: e.s.f.NewLocal(c.Pos, types.Int64), Type: types.Int64}
// TODO: reuse these slots. They'll need to be erased first.
e.set(t, vid, x, false, c.Pos)
if e.s.f.pass.debug > regDebug {
fmt.Printf(" SPILL %s->%s %s\n", r, t, x.LongString())
}
}
// r will now be overwritten by the caller. At some point
// later, the newly saved value will be moved back to its
// final destination in processDest.
return r
}
}
}
cmd/compile: prefer to evict a rematerializable register This resolves a long-standing regalloc TODO: If you must evict a register, choose to evict a register containing a rematerializable value, since that value won't need to be spilled. Provides very minor performance and size improvements. name old time/op new time/op delta BinaryTree17-8 2.20s ± 3% 2.18s ± 2% -0.77% (p=0.000 n=45+49) Fannkuch11-8 2.14s ± 2% 2.15s ± 2% +0.73% (p=0.000 n=43+44) FmtFprintfEmpty-8 30.6ns ± 4% 30.2ns ± 3% -1.14% (p=0.000 n=50+48) FmtFprintfString-8 54.5ns ± 6% 53.6ns ± 5% -1.64% (p=0.001 n=50+48) FmtFprintfInt-8 58.0ns ± 7% 57.6ns ± 4% ~ (p=0.220 n=50+50) FmtFprintfIntInt-8 85.3ns ± 2% 84.8ns ± 3% -0.62% (p=0.001 n=44+47) FmtFprintfPrefixedInt-8 93.9ns ± 6% 93.6ns ± 5% ~ (p=0.706 n=50+48) FmtFprintfFloat-8 178ns ± 4% 177ns ± 4% ~ (p=0.107 n=49+50) FmtManyArgs-8 376ns ± 4% 374ns ± 3% -0.58% (p=0.013 n=45+50) GobDecode-8 4.77ms ± 2% 4.76ms ± 3% ~ (p=0.059 n=47+46) GobEncode-8 4.04ms ± 2% 3.99ms ± 3% -1.13% (p=0.000 n=49+49) Gzip-8 177ms ± 2% 180ms ± 3% +1.43% (p=0.000 n=48+48) Gunzip-8 28.5ms ± 6% 28.3ms ± 5% ~ (p=0.104 n=50+49) HTTPClientServer-8 72.1µs ± 1% 72.0µs ± 1% -0.15% (p=0.042 n=48+42) JSONEncode-8 9.81ms ± 5% 10.03ms ± 6% +2.29% (p=0.000 n=50+49) JSONDecode-8 39.2ms ± 3% 39.3ms ± 2% ~ (p=0.095 n=49+49) Mandelbrot200-8 3.48ms ± 2% 3.46ms ± 2% -0.80% (p=0.000 n=47+48) GoParse-8 2.54ms ± 3% 2.51ms ± 3% -1.35% (p=0.000 n=49+49) RegexpMatchEasy0_32-8 66.0ns ± 7% 65.7ns ± 8% ~ (p=0.331 n=50+50) RegexpMatchEasy0_1K-8 155ns ± 4% 154ns ± 4% ~ (p=0.986 n=49+50) RegexpMatchEasy1_32-8 62.6ns ± 8% 62.2ns ± 5% ~ (p=0.395 n=50+49) RegexpMatchEasy1_1K-8 260ns ± 5% 255ns ± 3% -1.92% (p=0.000 n=49+49) RegexpMatchMedium_32-8 92.9ns ± 2% 91.8ns ± 2% -1.25% (p=0.000 n=46+48) RegexpMatchMedium_1K-8 27.7µs ± 3% 27.0µs ± 2% -2.59% (p=0.000 n=49+49) RegexpMatchHard_32-8 1.23µs ± 4% 1.21µs ± 2% -2.16% (p=0.000 n=49+44) RegexpMatchHard_1K-8 36.4µs ± 2% 35.7µs ± 2% -1.87% (p=0.000 n=48+49) Revcomp-8 274ms ± 2% 276ms ± 3% +0.70% (p=0.034 n=45+48) Template-8 45.1ms ± 8% 45.1ms ± 8% ~ (p=0.643 n=50+50) TimeParse-8 223ns ± 2% 223ns ± 2% ~ (p=0.401 n=47+47) TimeFormat-8 245ns ± 2% 246ns ± 3% ~ (p=0.758 n=49+50) [Geo mean] 36.5µs 36.3µs -0.54% name old object-bytes new object-bytes delta Template 480kB ± 0% 480kB ± 0% ~ (all equal) Unicode 214kB ± 0% 214kB ± 0% ~ (all equal) GoTypes 1.54MB ± 0% 1.54MB ± 0% -0.03% (p=0.008 n=5+5) Compiler 5.75MB ± 0% 5.75MB ± 0% ~ (all equal) SSA 14.6MB ± 0% 14.6MB ± 0% -0.01% (p=0.008 n=5+5) Flate 300kB ± 0% 300kB ± 0% -0.01% (p=0.008 n=5+5) GoParser 366kB ± 0% 366kB ± 0% ~ (all equal) Reflect 1.20MB ± 0% 1.20MB ± 0% ~ (all equal) Tar 413kB ± 0% 413kB ± 0% ~ (all equal) XML 529kB ± 0% 528kB ± 0% -0.13% (p=0.008 n=5+5) [Geo mean] 909kB 909kB -0.02% Change-Id: I46d37a55197683a98913f35801dc2b0d609653c8 Reviewed-on: https://go-review.googlesource.com/103240 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2018-03-16 07:15:59 -07:00
fmt.Printf("m:%d unique:%d final:%d rematerializable:%d\n", m, e.uniqueRegs, e.finalRegs, e.rematerializeableRegs)
for _, vid := range e.cachedVals {
a := e.cache[vid]
for _, c := range a {
fmt.Printf("v%d: %s %s\n", vid, c, e.s.f.getHome(c.ID))
}
}
e.s.f.Fatalf("can't find empty register on edge %s->%s", e.p, e.b)
return nil
}
// rematerializeable reports whether the register allocator should recompute
// a value instead of spilling/restoring it.
func (v *Value) rematerializeable() bool {
if !opcodeTable[v.Op].rematerializeable {
return false
}
for _, a := range v.Args {
// Fixed-register allocations (SP, SB, etc.) are always available.
// Any other argument of an opcode makes it not rematerializeable.
if !opcodeTable[a.Op].fixedReg {
return false
}
}
return true
}
type liveInfo struct {
2016-12-15 17:17:01 -08:00
ID ID // ID of value
dist int32 // # of instructions before next use
pos src.XPos // source position of next use
}
// computeLive computes a map from block ID to a list of value IDs live at the end
// of that block. Together with the value ID is a count of how many instructions
// to the next use of that value. The resulting map is stored in s.live.
// computeLive also computes the desired register information at the end of each block.
// This desired register information is stored in s.desired.
// TODO: this could be quadratic if lots of variables are live across lots of
// basic blocks. Figure out a way to make this function (or, more precisely, the user
// of this function) require only linear size & time.
func (s *regAllocState) computeLive() {
f := s.f
s.live = make([][]liveInfo, f.NumBlocks())
s.desired = make([]desiredState, f.NumBlocks())
var phis []*Value
live := f.newSparseMapPos(f.NumValues())
defer f.retSparseMapPos(live)
t := f.newSparseMapPos(f.NumValues())
defer f.retSparseMapPos(t)
// Keep track of which value we want in each register.
var desired desiredState
// Instead of iterating over f.Blocks, iterate over their postordering.
// Liveness information flows backward, so starting at the end
// increases the probability that we will stabilize quickly.
// TODO: Do a better job yet. Here's one possibility:
// Calculate the dominator tree and locate all strongly connected components.
// If a value is live in one block of an SCC, it is live in all.
// Walk the dominator tree from end to beginning, just once, treating SCC
// components as single blocks, duplicated calculated liveness information
// out to all of them.
po := f.postorder()
s.loopnest = f.loopnest()
s.loopnest.computeUnavoidableCalls()
for {
changed := false
for _, b := range po {
// Start with known live values at the end of the block.
// Add len(b.Values) to adjust from end-of-block distance
// to beginning-of-block distance.
live.clear()
for _, e := range s.live[b.ID] {
live.set(e.ID, e.dist+int32(len(b.Values)), e.pos)
}
cmd/compile: allow multiple SSA block control values Control values are used to choose which successor of a block is jumped to. Typically a control value takes the form of a 'flags' value that represents the result of a comparison. Some architectures however use a variable in a register as a control value. Up until now we have managed with a single control value per block. However some architectures (e.g. s390x and riscv64) have combined compare-and-branch instructions that take two variables in registers as parameters. To generate these instructions we need to support 2 control values per block. This CL allows up to 2 control values to be used in a block in order to support the addition of compare-and-branch instructions. I have implemented s390x compare-and-branch instructions in a different CL. Passes toolstash-check -all. Results of compilebench: name old time/op new time/op delta Template 208ms ± 1% 209ms ± 1% ~ (p=0.289 n=20+20) Unicode 83.7ms ± 1% 83.3ms ± 3% -0.49% (p=0.017 n=18+18) GoTypes 748ms ± 1% 748ms ± 0% ~ (p=0.460 n=20+18) Compiler 3.47s ± 1% 3.48s ± 1% ~ (p=0.070 n=19+18) SSA 11.5s ± 1% 11.7s ± 1% +1.64% (p=0.000 n=19+18) Flate 130ms ± 1% 130ms ± 1% ~ (p=0.588 n=19+20) GoParser 160ms ± 1% 161ms ± 1% ~ (p=0.211 n=20+20) Reflect 465ms ± 1% 467ms ± 1% +0.42% (p=0.007 n=20+20) Tar 184ms ± 1% 185ms ± 2% ~ (p=0.087 n=18+20) XML 253ms ± 1% 253ms ± 1% ~ (p=0.377 n=20+18) LinkCompiler 769ms ± 2% 774ms ± 2% ~ (p=0.070 n=19+19) ExternalLinkCompiler 3.59s ±11% 3.68s ± 6% ~ (p=0.072 n=20+20) LinkWithoutDebugCompiler 446ms ± 5% 454ms ± 3% +1.79% (p=0.002 n=19+20) StdCmd 26.0s ± 2% 26.0s ± 2% ~ (p=0.799 n=20+20) name old user-time/op new user-time/op delta Template 238ms ± 5% 240ms ± 5% ~ (p=0.142 n=20+20) Unicode 105ms ±11% 106ms ±10% ~ (p=0.512 n=20+20) GoTypes 876ms ± 2% 873ms ± 4% ~ (p=0.647 n=20+19) Compiler 4.17s ± 2% 4.19s ± 1% ~ (p=0.093 n=20+18) SSA 13.9s ± 1% 14.1s ± 1% +1.45% (p=0.000 n=18+18) Flate 145ms ±13% 146ms ± 5% ~ (p=0.851 n=20+18) GoParser 185ms ± 5% 188ms ± 7% ~ (p=0.174 n=20+20) Reflect 534ms ± 3% 538ms ± 2% ~ (p=0.105 n=20+18) Tar 215ms ± 4% 211ms ± 9% ~ (p=0.079 n=19+20) XML 295ms ± 6% 295ms ± 5% ~ (p=0.968 n=20+20) LinkCompiler 832ms ± 4% 837ms ± 7% ~ (p=0.707 n=17+20) ExternalLinkCompiler 1.58s ± 8% 1.60s ± 4% ~ (p=0.296 n=20+19) LinkWithoutDebugCompiler 478ms ±12% 489ms ±10% ~ (p=0.429 n=20+20) name old object-bytes new object-bytes delta Template 559kB ± 0% 559kB ± 0% ~ (all equal) Unicode 216kB ± 0% 216kB ± 0% ~ (all equal) GoTypes 2.03MB ± 0% 2.03MB ± 0% ~ (all equal) Compiler 8.07MB ± 0% 8.07MB ± 0% -0.06% (p=0.000 n=20+20) SSA 27.1MB ± 0% 27.3MB ± 0% +0.89% (p=0.000 n=20+20) Flate 343kB ± 0% 343kB ± 0% ~ (all equal) GoParser 441kB ± 0% 441kB ± 0% ~ (all equal) Reflect 1.36MB ± 0% 1.36MB ± 0% ~ (all equal) Tar 487kB ± 0% 487kB ± 0% ~ (all equal) XML 632kB ± 0% 632kB ± 0% ~ (all equal) name old export-bytes new export-bytes delta Template 18.5kB ± 0% 18.5kB ± 0% ~ (all equal) Unicode 7.92kB ± 0% 7.92kB ± 0% ~ (all equal) GoTypes 35.0kB ± 0% 35.0kB ± 0% ~ (all equal) Compiler 109kB ± 0% 110kB ± 0% +0.72% (p=0.000 n=20+20) SSA 137kB ± 0% 138kB ± 0% +0.58% (p=0.000 n=20+20) Flate 4.89kB ± 0% 4.89kB ± 0% ~ (all equal) GoParser 8.49kB ± 0% 8.49kB ± 0% ~ (all equal) Reflect 11.4kB ± 0% 11.4kB ± 0% ~ (all equal) Tar 10.5kB ± 0% 10.5kB ± 0% ~ (all equal) XML 16.7kB ± 0% 16.7kB ± 0% ~ (all equal) name old text-bytes new text-bytes delta HelloSize 761kB ± 0% 761kB ± 0% ~ (all equal) CmdGoSize 10.8MB ± 0% 10.8MB ± 0% ~ (all equal) name old data-bytes new data-bytes delta HelloSize 10.7kB ± 0% 10.7kB ± 0% ~ (all equal) CmdGoSize 312kB ± 0% 312kB ± 0% ~ (all equal) name old bss-bytes new bss-bytes delta HelloSize 122kB ± 0% 122kB ± 0% ~ (all equal) CmdGoSize 146kB ± 0% 146kB ± 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 1.13MB ± 0% 1.13MB ± 0% ~ (all equal) CmdGoSize 15.1MB ± 0% 15.1MB ± 0% ~ (all equal) Change-Id: I3cc2f9829a109543d9a68be4a21775d2d3e9801f Reviewed-on: https://go-review.googlesource.com/c/go/+/196557 Run-TryBot: Michael Munday <mike.munday@ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Keith Randall <khr@golang.org>
2019-08-12 20:19:58 +01:00
// Mark control values as live
for _, c := range b.ControlValues() {
if s.values[c.ID].needReg {
live.set(c.ID, int32(len(b.Values)), b.Pos)
}
}
// Propagate backwards to the start of the block
// Assumes Values have been scheduled.
phis = phis[:0]
for i := len(b.Values) - 1; i >= 0; i-- {
v := b.Values[i]
live.remove(v.ID)
if v.Op == OpPhi {
// save phi ops for later
phis = append(phis, v)
continue
}
if opcodeTable[v.Op].call {
c := live.contents()
for i := range c {
c[i].val += unlikelyDistance
}
}
for _, a := range v.Args {
if s.values[a.ID].needReg {
live.set(a.ID, int32(i), v.Pos)
}
}
}
// Propagate desired registers backwards.
desired.copy(&s.desired[b.ID])
for i := len(b.Values) - 1; i >= 0; i-- {
v := b.Values[i]
prefs := desired.remove(v.ID)
if v.Op == OpPhi {
// TODO: if v is a phi, save desired register for phi inputs.
// For now, we just drop it and don't propagate
// desired registers back though phi nodes.
continue
}
regspec := s.regspec(v)
// Cancel desired registers if they get clobbered.
desired.clobber(regspec.clobbers)
// Update desired registers if there are any fixed register inputs.
for _, j := range regspec.inputs {
if countRegs(j.regs) != 1 {
continue
}
desired.clobber(j.regs)
desired.add(v.Args[j.idx].ID, pickReg(j.regs))
}
// Set desired register of input 0 if this is a 2-operand instruction.
if opcodeTable[v.Op].resultInArg0 || v.Op == OpAMD64ADDQconst || v.Op == OpAMD64ADDLconst || v.Op == OpSelect0 {
// ADDQconst is added here because we want to treat it as resultInArg0 for
// the purposes of desired registers, even though it is not an absolute requirement.
// This is because we'd rather implement it as ADDQ instead of LEAQ.
// Same for ADDLconst
// Select0 is added here to propagate the desired register to the tuple-generating instruction.
if opcodeTable[v.Op].commutative {
desired.addList(v.Args[1].ID, prefs)
}
desired.addList(v.Args[0].ID, prefs)
}
}
// For each predecessor of b, expand its list of live-at-end values.
// invariant: live contains the values live at the start of b (excluding phi inputs)
for i, e := range b.Preds {
p := e.b
// Compute additional distance for the edge.
// Note: delta must be at least 1 to distinguish the control
// value use from the first user in a successor block.
cmd/compile: load some live values into registers before loop If we're about to enter a loop, load values which are live and will soon be used in the loop into registers. name old time/op new time/op delta BinaryTree17-8 2.80s ± 4% 2.62s ± 2% -6.43% (p=0.008 n=5+5) Fannkuch11-8 2.45s ± 2% 2.14s ± 1% -12.43% (p=0.008 n=5+5) FmtFprintfEmpty-8 49.0ns ± 1% 48.4ns ± 1% -1.35% (p=0.032 n=5+5) FmtFprintfString-8 160ns ± 1% 153ns ± 0% -4.63% (p=0.008 n=5+5) FmtFprintfInt-8 152ns ± 0% 150ns ± 0% -1.57% (p=0.000 n=5+4) FmtFprintfIntInt-8 252ns ± 2% 244ns ± 1% -3.02% (p=0.008 n=5+5) FmtFprintfPrefixedInt-8 223ns ± 0% 223ns ± 0% ~ (all samples are equal) FmtFprintfFloat-8 293ns ± 2% 291ns ± 2% ~ (p=0.389 n=5+5) FmtManyArgs-8 956ns ± 0% 936ns ± 0% -2.05% (p=0.008 n=5+5) GobDecode-8 7.18ms ± 0% 7.11ms ± 0% -1.02% (p=0.008 n=5+5) GobEncode-8 6.12ms ± 3% 6.07ms ± 1% ~ (p=0.690 n=5+5) Gzip-8 284ms ± 1% 284ms ± 0% ~ (p=1.000 n=5+5) Gunzip-8 40.8ms ± 1% 40.6ms ± 1% ~ (p=0.310 n=5+5) HTTPClientServer-8 69.8µs ± 1% 72.2µs ± 4% ~ (p=0.056 n=5+5) JSONEncode-8 16.1ms ± 2% 16.2ms ± 1% ~ (p=0.151 n=5+5) JSONDecode-8 54.9ms ± 0% 57.0ms ± 1% +3.79% (p=0.008 n=5+5) Mandelbrot200-8 4.35ms ± 0% 4.39ms ± 0% +0.85% (p=0.008 n=5+5) GoParse-8 3.56ms ± 1% 3.42ms ± 1% -4.03% (p=0.008 n=5+5) RegexpMatchEasy0_32-8 75.6ns ± 1% 75.0ns ± 0% -0.83% (p=0.016 n=5+4) RegexpMatchEasy0_1K-8 250ns ± 0% 252ns ± 1% +0.80% (p=0.016 n=4+5) RegexpMatchEasy1_32-8 75.0ns ± 0% 75.4ns ± 2% ~ (p=0.206 n=5+5) RegexpMatchEasy1_1K-8 401ns ± 0% 398ns ± 1% ~ (p=0.056 n=5+5) RegexpMatchMedium_32-8 119ns ± 0% 118ns ± 0% -0.84% (p=0.008 n=5+5) RegexpMatchMedium_1K-8 36.6µs ± 0% 36.9µs ± 0% +0.91% (p=0.008 n=5+5) RegexpMatchHard_32-8 1.95µs ± 1% 1.92µs ± 0% -1.23% (p=0.032 n=5+5) RegexpMatchHard_1K-8 58.3µs ± 1% 58.1µs ± 1% ~ (p=0.548 n=5+5) Revcomp-8 425ms ± 1% 389ms ± 1% -8.39% (p=0.008 n=5+5) Template-8 65.5ms ± 1% 63.6ms ± 1% -2.86% (p=0.008 n=5+5) TimeParse-8 363ns ± 0% 354ns ± 1% -2.59% (p=0.008 n=5+5) TimeFormat-8 363ns ± 0% 364ns ± 1% ~ (p=0.159 n=5+5) Fixes #14511 Change-Id: I1b79d2545271fa90d5b04712cc25573bdc94f2ce Reviewed-on: https://go-review.googlesource.com/20151 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2016-03-02 15:18:40 -08:00
delta := int32(normalDistance)
if len(p.Succs) == 2 {
if p.Succs[0].b == b && p.Likely == BranchLikely ||
p.Succs[1].b == b && p.Likely == BranchUnlikely {
cmd/compile: load some live values into registers before loop If we're about to enter a loop, load values which are live and will soon be used in the loop into registers. name old time/op new time/op delta BinaryTree17-8 2.80s ± 4% 2.62s ± 2% -6.43% (p=0.008 n=5+5) Fannkuch11-8 2.45s ± 2% 2.14s ± 1% -12.43% (p=0.008 n=5+5) FmtFprintfEmpty-8 49.0ns ± 1% 48.4ns ± 1% -1.35% (p=0.032 n=5+5) FmtFprintfString-8 160ns ± 1% 153ns ± 0% -4.63% (p=0.008 n=5+5) FmtFprintfInt-8 152ns ± 0% 150ns ± 0% -1.57% (p=0.000 n=5+4) FmtFprintfIntInt-8 252ns ± 2% 244ns ± 1% -3.02% (p=0.008 n=5+5) FmtFprintfPrefixedInt-8 223ns ± 0% 223ns ± 0% ~ (all samples are equal) FmtFprintfFloat-8 293ns ± 2% 291ns ± 2% ~ (p=0.389 n=5+5) FmtManyArgs-8 956ns ± 0% 936ns ± 0% -2.05% (p=0.008 n=5+5) GobDecode-8 7.18ms ± 0% 7.11ms ± 0% -1.02% (p=0.008 n=5+5) GobEncode-8 6.12ms ± 3% 6.07ms ± 1% ~ (p=0.690 n=5+5) Gzip-8 284ms ± 1% 284ms ± 0% ~ (p=1.000 n=5+5) Gunzip-8 40.8ms ± 1% 40.6ms ± 1% ~ (p=0.310 n=5+5) HTTPClientServer-8 69.8µs ± 1% 72.2µs ± 4% ~ (p=0.056 n=5+5) JSONEncode-8 16.1ms ± 2% 16.2ms ± 1% ~ (p=0.151 n=5+5) JSONDecode-8 54.9ms ± 0% 57.0ms ± 1% +3.79% (p=0.008 n=5+5) Mandelbrot200-8 4.35ms ± 0% 4.39ms ± 0% +0.85% (p=0.008 n=5+5) GoParse-8 3.56ms ± 1% 3.42ms ± 1% -4.03% (p=0.008 n=5+5) RegexpMatchEasy0_32-8 75.6ns ± 1% 75.0ns ± 0% -0.83% (p=0.016 n=5+4) RegexpMatchEasy0_1K-8 250ns ± 0% 252ns ± 1% +0.80% (p=0.016 n=4+5) RegexpMatchEasy1_32-8 75.0ns ± 0% 75.4ns ± 2% ~ (p=0.206 n=5+5) RegexpMatchEasy1_1K-8 401ns ± 0% 398ns ± 1% ~ (p=0.056 n=5+5) RegexpMatchMedium_32-8 119ns ± 0% 118ns ± 0% -0.84% (p=0.008 n=5+5) RegexpMatchMedium_1K-8 36.6µs ± 0% 36.9µs ± 0% +0.91% (p=0.008 n=5+5) RegexpMatchHard_32-8 1.95µs ± 1% 1.92µs ± 0% -1.23% (p=0.032 n=5+5) RegexpMatchHard_1K-8 58.3µs ± 1% 58.1µs ± 1% ~ (p=0.548 n=5+5) Revcomp-8 425ms ± 1% 389ms ± 1% -8.39% (p=0.008 n=5+5) Template-8 65.5ms ± 1% 63.6ms ± 1% -2.86% (p=0.008 n=5+5) TimeParse-8 363ns ± 0% 354ns ± 1% -2.59% (p=0.008 n=5+5) TimeFormat-8 363ns ± 0% 364ns ± 1% ~ (p=0.159 n=5+5) Fixes #14511 Change-Id: I1b79d2545271fa90d5b04712cc25573bdc94f2ce Reviewed-on: https://go-review.googlesource.com/20151 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2016-03-02 15:18:40 -08:00
delta = likelyDistance
}
if p.Succs[0].b == b && p.Likely == BranchUnlikely ||
p.Succs[1].b == b && p.Likely == BranchLikely {
cmd/compile: load some live values into registers before loop If we're about to enter a loop, load values which are live and will soon be used in the loop into registers. name old time/op new time/op delta BinaryTree17-8 2.80s ± 4% 2.62s ± 2% -6.43% (p=0.008 n=5+5) Fannkuch11-8 2.45s ± 2% 2.14s ± 1% -12.43% (p=0.008 n=5+5) FmtFprintfEmpty-8 49.0ns ± 1% 48.4ns ± 1% -1.35% (p=0.032 n=5+5) FmtFprintfString-8 160ns ± 1% 153ns ± 0% -4.63% (p=0.008 n=5+5) FmtFprintfInt-8 152ns ± 0% 150ns ± 0% -1.57% (p=0.000 n=5+4) FmtFprintfIntInt-8 252ns ± 2% 244ns ± 1% -3.02% (p=0.008 n=5+5) FmtFprintfPrefixedInt-8 223ns ± 0% 223ns ± 0% ~ (all samples are equal) FmtFprintfFloat-8 293ns ± 2% 291ns ± 2% ~ (p=0.389 n=5+5) FmtManyArgs-8 956ns ± 0% 936ns ± 0% -2.05% (p=0.008 n=5+5) GobDecode-8 7.18ms ± 0% 7.11ms ± 0% -1.02% (p=0.008 n=5+5) GobEncode-8 6.12ms ± 3% 6.07ms ± 1% ~ (p=0.690 n=5+5) Gzip-8 284ms ± 1% 284ms ± 0% ~ (p=1.000 n=5+5) Gunzip-8 40.8ms ± 1% 40.6ms ± 1% ~ (p=0.310 n=5+5) HTTPClientServer-8 69.8µs ± 1% 72.2µs ± 4% ~ (p=0.056 n=5+5) JSONEncode-8 16.1ms ± 2% 16.2ms ± 1% ~ (p=0.151 n=5+5) JSONDecode-8 54.9ms ± 0% 57.0ms ± 1% +3.79% (p=0.008 n=5+5) Mandelbrot200-8 4.35ms ± 0% 4.39ms ± 0% +0.85% (p=0.008 n=5+5) GoParse-8 3.56ms ± 1% 3.42ms ± 1% -4.03% (p=0.008 n=5+5) RegexpMatchEasy0_32-8 75.6ns ± 1% 75.0ns ± 0% -0.83% (p=0.016 n=5+4) RegexpMatchEasy0_1K-8 250ns ± 0% 252ns ± 1% +0.80% (p=0.016 n=4+5) RegexpMatchEasy1_32-8 75.0ns ± 0% 75.4ns ± 2% ~ (p=0.206 n=5+5) RegexpMatchEasy1_1K-8 401ns ± 0% 398ns ± 1% ~ (p=0.056 n=5+5) RegexpMatchMedium_32-8 119ns ± 0% 118ns ± 0% -0.84% (p=0.008 n=5+5) RegexpMatchMedium_1K-8 36.6µs ± 0% 36.9µs ± 0% +0.91% (p=0.008 n=5+5) RegexpMatchHard_32-8 1.95µs ± 1% 1.92µs ± 0% -1.23% (p=0.032 n=5+5) RegexpMatchHard_1K-8 58.3µs ± 1% 58.1µs ± 1% ~ (p=0.548 n=5+5) Revcomp-8 425ms ± 1% 389ms ± 1% -8.39% (p=0.008 n=5+5) Template-8 65.5ms ± 1% 63.6ms ± 1% -2.86% (p=0.008 n=5+5) TimeParse-8 363ns ± 0% 354ns ± 1% -2.59% (p=0.008 n=5+5) TimeFormat-8 363ns ± 0% 364ns ± 1% ~ (p=0.159 n=5+5) Fixes #14511 Change-Id: I1b79d2545271fa90d5b04712cc25573bdc94f2ce Reviewed-on: https://go-review.googlesource.com/20151 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2016-03-02 15:18:40 -08:00
delta = unlikelyDistance
}
}
// Update any desired registers at the end of p.
s.desired[p.ID].merge(&desired)
// Start t off with the previously known live values at the end of p.
t.clear()
for _, e := range s.live[p.ID] {
t.set(e.ID, e.dist, e.pos)
}
update := false
// Add new live values from scanning this block.
for _, e := range live.contents() {
d := e.val + delta
if !t.contains(e.key) || d < t.get(e.key) {
update = true
t.set(e.key, d, e.pos)
}
}
// Also add the correct arg from the saved phi values.
// All phis are at distance delta (we consider them
// simultaneously happening at the start of the block).
for _, v := range phis {
id := v.Args[i].ID
if s.values[id].needReg && (!t.contains(id) || delta < t.get(id)) {
update = true
t.set(id, delta, v.Pos)
}
}
if !update {
continue
}
// The live set has changed, update it.
l := s.live[p.ID][:0]
if cap(l) < t.size() {
l = make([]liveInfo, 0, t.size())
}
for _, e := range t.contents() {
l = append(l, liveInfo{e.key, e.val, e.pos})
}
s.live[p.ID] = l
changed = true
}
}
if !changed {
break
}
}
if f.pass.debug > regDebug {
fmt.Println("live values at end of each block")
for _, b := range f.Blocks {
fmt.Printf(" %s:", b)
for _, x := range s.live[b.ID] {
cmd/compile: use desired info when allocating registers for live values When allocting registers for live values, use desired register if available, this is helpful for some cases, such as (*entry).delete, which can save a few of copies. Besides, this patch allows more debugging information to be printed out. Test results of compilecmp on Linux/amd64: name old time/op new time/op delta Template 326729362.060000ns +- 3% 329227238.775510ns +- 4% +0.76% (p=0.038 n=50+49) Unicode 157671860.391304ns +- 6% 156917927.320000ns +- 6% ~ (p=0.291 n=46+50) GoTypes 1065591138.304348ns +- 2% 1063695977.434783ns +- 1% ~ (p=0.208 n=46+46) Compiler 5053424790.760001ns +- 2% 5052729636.551020ns +- 3% ~ (p=0.908 n=50+49) SSA 12392067635.866669ns +- 2% 12319786960.460005ns +- 2% -0.58% (p=0.008 n=45+50) Flate 212609767.340000ns +- 5% 213011228.085106ns +- 5% ~ (p=0.685 n=50+47) GoParser 266870495.100000ns +- 4% 266962314.280000ns +- 3% ~ (p=0.975 n=50+50) Reflect 660164306.551021ns +- 2% 658284470.729167ns +- 2% ~ (p=0.069 n=49+48) Tar 292805895.720000ns +- 4% 292103626.954545ns +- 2% ~ (p=0.321 n=50+44) XML 386294811.700000ns +- 4% 386665088.820000ns +- 4% ~ (p=0.786 n=50+50) LinkCompiler 548495788.659575ns +- 5% 549359489.102041ns +- 4% ~ (p=0.855 n=47+49) ExternalLinkCompiler 1810414270.280000ns +- 2% 1806872224.673470ns +- 2% ~ (p=0.313 n=50+49) LinkWithoutDebugCompiler 340888843.795918ns +- 5% 340341541.100000ns +- 6% ~ (p=0.735 n=49+50) [Geo mean] 664550174.613777ns 664090221.153575ns -0.07% name old user-time/op new user-time/op delta Template 565202800.000000ns +-16% 595351040.000000ns +-16% +5.33% (p=0.001 n=50+50) Unicode 378444740.000000ns +-14% 373825183.673469ns +-17% ~ (p=0.458 n=50+49) GoTypes 2052073341.463415ns +-12% 2059679864.864865ns +- 7% ~ (p=0.381 n=41+37) Compiler 9913371980.000000ns +-20% 9848836720.000002ns +-19% ~ (p=0.781 n=50+50) SSA 25013846224.489799ns +-17% 24571896183.673466ns +-17% ~ (p=0.132 n=49+49) Flate 314422702.127660ns +-17% 314831666.666667ns +-11% ~ (p=0.427 n=47+45) GoParser 419496060.000000ns +- 9% 417403460.000000ns +-11% ~ (p=0.512 n=50+50) Reflect 1233632469.387755ns +-17% 1193061073.170732ns +-13% -3.29% (p=0.030 n=49+41) Tar 509855937.500000ns +-10% 508700740.000000ns +-14% ~ (p=0.890 n=48+50) XML 703511425.531915ns +-12% 694007591.836735ns +-11% ~ (p=0.164 n=47+49) LinkCompiler 993137687.500000ns +- 6% 991914714.285714ns +- 8% ~ (p=0.860 n=48+49) ExternalLinkCompiler 2193851840.000001ns +- 3% 2186672183.673470ns +- 5% ~ (p=0.320 n=50+49) LinkWithoutDebugCompiler 420800875.000000ns +-10% 422062640.000000ns +- 9% ~ (p=0.840 n=48+50) [Geo mean] 1145156131.480097ns 1142033233.550961ns -0.27% name old alloc/op new alloc/op delta Template 36.3MB +- 0% 36.3MB +- 0% ~ (p=0.886 n=50+49) Unicode 30.1MB +- 0% 30.1MB +- 0% ~ (p=0.792 n=50+50) GoTypes 118MB +- 0% 118MB +- 0% ~ (p=1.000 n=47+48) Compiler 562MB +- 0% 562MB +- 0% ~ (p=0.205 n=50+49) SSA 1.42GB +- 0% 1.42GB +- 0% -0.12% (p=0.000 n=50+50) Flate 22.8MB +- 0% 22.8MB +- 0% ~ (p=0.384 n=50+47) GoParser 28.0MB +- 0% 28.0MB +- 0% -0.02% (p=0.013 n=50+50) Reflect 78.0MB +- 0% 78.0MB +- 0% ~ (p=0.384 n=46+48) Tar 34.1MB +- 0% 34.1MB +- 0% ~ (p=0.072 n=50+50) XML 43.1MB +- 0% 43.1MB +- 0% -0.04% (p=0.000 n=49+50) LinkCompiler 98.5MB +- 0% 98.5MB +- 0% +0.01% (p=0.012 n=50+43) ExternalLinkCompiler 89.6MB +- 0% 89.6MB +- 0% ~ (p=0.762 n=50+50) LinkWithoutDebugCompiler 56.9MB +- 0% 56.9MB +- 0% ~ (p=0.268 n=49+48) [Geo mean] 77.7MB 77.7MB -0.01% name old allocs/op new allocs/op delta Template 367k +- 0% 367k +- 0% -0.01% (p=0.002 n=50+49) Unicode 345k +- 0% 345k +- 0% ~ (p=0.981 n=50+50) GoTypes 1.28M +- 0% 1.28M +- 0% -0.00% (p=0.002 n=49+50) Compiler 5.39M +- 0% 5.39M +- 0% -0.00% (p=0.000 n=50+50) SSA 13.9M +- 0% 13.9M +- 0% +0.01% (p=0.000 n=50+50) Flate 230k +- 0% 230k +- 0% ~ (p=0.815 n=50+50) GoParser 292k +- 0% 292k +- 0% -0.01% (p=0.000 n=50+50) Reflect 977k +- 0% 977k +- 0% -0.00% (p=0.035 n=50+50) Tar 343k +- 0% 343k +- 0% -0.01% (p=0.008 n=48+50) XML 418k +- 0% 418k +- 0% -0.01% (p=0.000 n=50+50) LinkCompiler 516k +- 0% 516k +- 0% +0.01% (p=0.002 n=50+48) ExternalLinkCompiler 570k +- 0% 570k +- 0% ~ (p=0.430 n=46+50) LinkWithoutDebugCompiler 169k +- 0% 169k +- 0% ~ (p=0.706 n=49+49) [Geo mean] 672k 672k -0.00% name old maxRSS/op new maxRSS/op delta Template 34.3M +- 5% 34.7M +- 4% +1.24% (p=0.004 n=50+50) Unicode 36.2M +- 5% 36.1M +- 8% ~ (p=0.785 n=50+50) GoTypes 75.7M +- 7% 76.1M +- 6% ~ (p=0.544 n=50+50) Compiler 304M +- 7% 304M +- 7% ~ (p=0.744 n=50+50) SSA 721M +- 6% 723M +- 7% ~ (p=0.724 n=49+50) Flate 26.1M +- 3% 26.1M +- 5% ~ (p=0.649 n=48+49) GoParser 29.3M +- 5% 29.3M +- 4% ~ (p=0.809 n=50+50) Reflect 56.0M +- 6% 56.3M +- 5% ~ (p=0.350 n=50+50) Tar 34.1M +- 3% 33.9M +- 5% ~ (p=0.121 n=49+50) XML 39.6M +- 5% 39.9M +- 4% ~ (p=0.109 n=50+50) LinkCompiler 168M +- 1% 168M +- 1% ~ (p=0.578 n=49+48) ExternalLinkCompiler 179M +- 1% 179M +- 2% ~ (p=0.522 n=46+46) LinkWithoutDebugCompiler 137M +- 3% 137M +- 3% ~ (p=0.463 n=41+50) [Geo mean] 79.3M 79.5M +0.20% name old text-bytes new text-bytes delta HelloSize 812kB +- 0% 811kB +- 0% -0.05% (p=0.000 n=50+50) name old data-bytes new data-bytes delta HelloSize 13.3kB +- 0% 13.3kB +- 0% ~ (all equal) name old bss-bytes new bss-bytes delta HelloSize 206kB +- 0% 206kB +- 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 1.21MB +- 0% 1.21MB +- 0% +0.02% (p=0.000 n=50+50) file before after Δ % addr2line 4052949 4052453 -496 -0.012% api 4948171 4947163 -1008 -0.020% asm 4888889 4888049 -840 -0.017% buildid 2617545 2617673 +128 +0.005% cgo 4521681 4516801 -4880 -0.108% compile 19139091 19137683 -1408 -0.007% cover 4843191 4840359 -2832 -0.058% dist 3473677 3474717 +1040 +0.030% doc 3821592 3821552 -40 -0.001% fix 3220587 3220059 -528 -0.016% link 6587368 6582696 -4672 -0.071% nm 3999858 3999186 -672 -0.017% objdump 4409161 4408217 -944 -0.021% pack 2394038 2393846 -192 -0.008% pprof 13601271 13602487 +1216 +0.009% test2json 2645148 2644604 -544 -0.021% trace 10357878 10356862 -1016 -0.010% vet 6779482 6778706 -776 -0.011% total 106301577 106283113 -18464 -0.017% Change-Id: I63ac6e224e1a4756ddc1bfc4aabbaeb92d7d4273 Reviewed-on: https://go-review.googlesource.com/c/go/+/263599 Run-TryBot: eric fang <eric.fang@arm.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: eric fang <eric.fang@arm.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2020-10-19 03:57:15 +00:00
fmt.Printf(" v%d(%d)", x.ID, x.dist)
for _, e := range s.desired[b.ID].entries {
if e.ID != x.ID {
continue
}
fmt.Printf("[")
first := true
for _, r := range e.regs {
if r == noRegister {
continue
}
if !first {
fmt.Printf(",")
}
fmt.Print(&s.registers[r])
first = false
}
fmt.Printf("]")
}
}
if avoid := s.desired[b.ID].avoid; avoid != 0 {
fmt.Printf(" avoid=%v", s.RegMaskString(avoid))
}
fmt.Println()
}
}
}
// A desiredState represents desired register assignments.
type desiredState struct {
// Desired assignments will be small, so we just use a list
// of valueID+registers entries.
entries []desiredStateEntry
// Registers that other values want to be in. This value will
// contain at least the union of the regs fields of entries, but
// may contain additional entries for values that were once in
// this data structure but are no longer.
avoid regMask
}
type desiredStateEntry struct {
// (pre-regalloc) value
ID ID
// Registers it would like to be in, in priority order.
// Unused slots are filled with noRegister.
// For opcodes that return tuples, we track desired registers only
// for the first element of the tuple (see desiredSecondReg for
// tracking the desired register for second part of a tuple).
regs [4]register
}
// get returns a list of desired registers for value vid.
func (d *desiredState) get(vid ID) [4]register {
for _, e := range d.entries {
if e.ID == vid {
return e.regs
}
}
return [4]register{noRegister, noRegister, noRegister, noRegister}
}
// add records that we'd like value vid to be in register r.
func (d *desiredState) add(vid ID, r register) {
d.avoid |= regMask(1) << r
for i := range d.entries {
e := &d.entries[i]
if e.ID != vid {
continue
}
if e.regs[0] == r {
// Already known and highest priority
return
}
for j := 1; j < len(e.regs); j++ {
if e.regs[j] == r {
// Move from lower priority to top priority
copy(e.regs[1:], e.regs[:j])
e.regs[0] = r
return
}
}
copy(e.regs[1:], e.regs[:])
e.regs[0] = r
return
}
d.entries = append(d.entries, desiredStateEntry{vid, [4]register{r, noRegister, noRegister, noRegister}})
}
func (d *desiredState) addList(vid ID, regs [4]register) {
// regs is in priority order, so iterate in reverse order.
for i := len(regs) - 1; i >= 0; i-- {
r := regs[i]
if r != noRegister {
d.add(vid, r)
}
}
}
// clobber erases any desired registers in the set m.
func (d *desiredState) clobber(m regMask) {
for i := 0; i < len(d.entries); {
e := &d.entries[i]
j := 0
for _, r := range e.regs {
if r != noRegister && m>>r&1 == 0 {
e.regs[j] = r
j++
}
}
if j == 0 {
// No more desired registers for this value.
d.entries[i] = d.entries[len(d.entries)-1]
d.entries = d.entries[:len(d.entries)-1]
continue
}
for ; j < len(e.regs); j++ {
e.regs[j] = noRegister
}
i++
}
d.avoid &^= m
}
// copy copies a desired state from another desiredState x.
func (d *desiredState) copy(x *desiredState) {
d.entries = append(d.entries[:0], x.entries...)
d.avoid = x.avoid
}
// remove removes the desired registers for vid and returns them.
func (d *desiredState) remove(vid ID) [4]register {
for i := range d.entries {
if d.entries[i].ID == vid {
regs := d.entries[i].regs
d.entries[i] = d.entries[len(d.entries)-1]
d.entries = d.entries[:len(d.entries)-1]
return regs
}
}
return [4]register{noRegister, noRegister, noRegister, noRegister}
}
// merge merges another desired state x into d.
func (d *desiredState) merge(x *desiredState) {
d.avoid |= x.avoid
// There should only be a few desired registers, so
// linear insert is ok.
for _, e := range x.entries {
d.addList(e.ID, e.regs)
}
}
// computeUnavoidableCalls computes the containsUnavoidableCall fields in the loop nest.
func (loopnest *loopnest) computeUnavoidableCalls() {
f := loopnest.f
hasCall := f.Cache.allocBoolSlice(f.NumBlocks())
defer f.Cache.freeBoolSlice(hasCall)
for _, b := range f.Blocks {
if b.containsCall() {
hasCall[b.ID] = true
}
}
found := f.Cache.allocSparseSet(f.NumBlocks())
defer f.Cache.freeSparseSet(found)
// Run dfs to find path through the loop that avoids all calls.
// Such path either escapes the loop or returns back to the header.
// It isn't enough to have exit not dominated by any call, for example:
// ... some loop
// call1 call2
// \ /
// block
// ...
// block is not dominated by any single call, but we don't have call-free path to it.
loopLoop:
for _, l := range loopnest.loops {
found.clear()
tovisit := make([]*Block, 0, 8)
tovisit = append(tovisit, l.header)
for len(tovisit) > 0 {
cur := tovisit[len(tovisit)-1]
tovisit = tovisit[:len(tovisit)-1]
if hasCall[cur.ID] {
continue
}
for _, s := range cur.Succs {
nb := s.Block()
if nb == l.header {
// Found a call-free path around the loop.
continue loopLoop
}
if found.contains(nb.ID) {
// Already found via another path.
continue
}
nl := loopnest.b2l[nb.ID]
if nl == nil || (nl.depth <= l.depth && nl != l) {
// Left the loop.
continue
}
tovisit = append(tovisit, nb)
found.add(nb.ID)
}
}
// No call-free path was found.
l.containsUnavoidableCall = true
}
}
func (b *Block) containsCall() bool {
if b.Kind == BlockDefer {
return true
}
for _, v := range b.Values {
if opcodeTable[v.Op].call {
return true
}
}
return false
}