go/src/cmd/compile/internal/gc/fmt.go

1987 lines
44 KiB
Go
Raw Normal View History

// Copyright 2011 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.
package gc
import (
"bytes"
"cmd/compile/internal/types"
"cmd/internal/src"
"fmt"
"io"
"strconv"
"strings"
cmd/compile: use a sync.Pool and string interning when printing types CL 214239 improved type printing, but introduced performance regressions: 3-5% memory increase, 1-2% CPU time increase. There were two primary sources of the memory regression: * allocating a bytes.Buffer for every type to print * always printing to that buffer, even when we could return a constant string This change addresses both of those regressions. The sync.Pool allows buffer re-use. String interning prevents allocation for re-used strings. It addresses some, but not all, of the CPU time regression. Memory performance impact vs master: name old alloc/op new alloc/op delta Template 37.6MB ± 0% 36.3MB ± 0% -3.30% (p=0.008 n=5+5) Unicode 28.7MB ± 0% 28.3MB ± 0% -1.55% (p=0.008 n=5+5) GoTypes 127MB ± 0% 122MB ± 0% -4.38% (p=0.008 n=5+5) Compiler 584MB ± 0% 568MB ± 0% -2.72% (p=0.008 n=5+5) SSA 1.99GB ± 0% 1.95GB ± 0% -1.97% (p=0.008 n=5+5) Flate 23.5MB ± 0% 22.8MB ± 0% -2.84% (p=0.008 n=5+5) GoParser 29.2MB ± 0% 28.0MB ± 0% -4.17% (p=0.008 n=5+5) Reflect 81.9MB ± 0% 78.6MB ± 0% -4.09% (p=0.008 n=5+5) Tar 35.3MB ± 0% 34.1MB ± 0% -3.29% (p=0.008 n=5+5) XML 45.5MB ± 0% 44.3MB ± 0% -2.61% (p=0.008 n=5+5) [Geo mean] 82.4MB 79.9MB -3.09% name old allocs/op new allocs/op delta Template 394k ± 0% 363k ± 0% -7.73% (p=0.008 n=5+5) Unicode 340k ± 0% 329k ± 0% -3.25% (p=0.008 n=5+5) GoTypes 1.41M ± 0% 1.28M ± 0% -9.54% (p=0.008 n=5+5) Compiler 5.77M ± 0% 5.39M ± 0% -6.58% (p=0.008 n=5+5) SSA 19.1M ± 0% 18.1M ± 0% -5.13% (p=0.008 n=5+5) Flate 247k ± 0% 228k ± 0% -7.50% (p=0.008 n=5+5) GoParser 325k ± 0% 295k ± 0% -9.24% (p=0.008 n=5+5) Reflect 1.04M ± 0% 0.95M ± 0% -8.48% (p=0.008 n=5+5) Tar 365k ± 0% 336k ± 0% -7.93% (p=0.008 n=5+5) XML 449k ± 0% 417k ± 0% -7.10% (p=0.008 n=5+5) [Geo mean] 882k 818k -7.26% Memory performance going from 52c4488471ed52085a29e173226b3cbd2bf22b20, which is the commit preceding CL 214239, to this change: name old alloc/op new alloc/op delta Template 36.5MB ± 0% 36.3MB ± 0% -0.37% (p=0.008 n=5+5) Unicode 28.3MB ± 0% 28.3MB ± 0% -0.06% (p=0.008 n=5+5) GoTypes 123MB ± 0% 122MB ± 0% -0.64% (p=0.008 n=5+5) Compiler 571MB ± 0% 568MB ± 0% -0.51% (p=0.008 n=5+5) SSA 1.96GB ± 0% 1.95GB ± 0% -0.13% (p=0.008 n=5+5) Flate 22.8MB ± 0% 22.8MB ± 0% ~ (p=0.421 n=5+5) GoParser 28.1MB ± 0% 28.0MB ± 0% -0.37% (p=0.008 n=5+5) Reflect 78.8MB ± 0% 78.6MB ± 0% -0.32% (p=0.008 n=5+5) Tar 34.3MB ± 0% 34.1MB ± 0% -0.35% (p=0.008 n=5+5) XML 44.3MB ± 0% 44.3MB ± 0% +0.05% (p=0.032 n=5+5) [Geo mean] 80.1MB 79.9MB -0.27% name old allocs/op new allocs/op delta Template 372k ± 0% 363k ± 0% -2.46% (p=0.008 n=5+5) Unicode 333k ± 0% 329k ± 0% -0.97% (p=0.008 n=5+5) GoTypes 1.33M ± 0% 1.28M ± 0% -3.71% (p=0.008 n=5+5) Compiler 5.53M ± 0% 5.39M ± 0% -2.50% (p=0.008 n=5+5) SSA 18.3M ± 0% 18.1M ± 0% -1.22% (p=0.008 n=5+5) Flate 234k ± 0% 228k ± 0% -2.44% (p=0.008 n=5+5) GoParser 305k ± 0% 295k ± 0% -3.23% (p=0.008 n=5+5) Reflect 980k ± 0% 949k ± 0% -3.12% (p=0.008 n=5+5) Tar 345k ± 0% 336k ± 0% -2.69% (p=0.008 n=5+5) XML 425k ± 0% 417k ± 0% -1.72% (p=0.008 n=5+5) [Geo mean] 838k 818k -2.41% Remaining CPU time regression, that is, the change from before CL 214239 to this change: name old time/op new time/op delta Template 208ms ± 2% 209ms ± 1% ~ (p=0.181 n=47+46) Unicode 82.9ms ± 2% 81.9ms ± 2% -1.25% (p=0.000 n=50+48) GoTypes 709ms ± 3% 714ms ± 3% +0.77% (p=0.003 n=48+49) Compiler 3.31s ± 2% 3.32s ± 2% ~ (p=0.271 n=48+48) SSA 10.8s ± 1% 10.9s ± 1% +0.61% (p=0.000 n=46+47) Flate 134ms ± 2% 134ms ± 1% +0.41% (p=0.002 n=48+46) GoParser 166ms ± 2% 167ms ± 2% +0.41% (p=0.010 n=46+48) Reflect 440ms ± 4% 444ms ± 4% +1.05% (p=0.002 n=50+49) Tar 183ms ± 2% 184ms ± 2% ~ (p=0.074 n=45+45) XML 247ms ± 2% 248ms ± 2% +0.67% (p=0.001 n=49+48) [Geo mean] 425ms 427ms +0.34% name old user-time/op new user-time/op delta Template 271ms ± 2% 271ms ± 2% ~ (p=0.654 n=48+48) Unicode 117ms ± 2% 116ms ± 3% ~ (p=0.458 n=47+45) GoTypes 952ms ± 3% 963ms ± 2% +1.11% (p=0.000 n=48+49) Compiler 4.50s ± 5% 4.49s ± 7% ~ (p=0.894 n=50+50) SSA 15.0s ± 2% 15.1s ± 2% +0.46% (p=0.015 n=50+49) Flate 166ms ± 2% 167ms ± 2% +0.40% (p=0.005 n=49+48) GoParser 202ms ± 2% 203ms ± 2% +0.60% (p=0.002 n=49+47) Reflect 583ms ± 3% 588ms ± 3% +0.82% (p=0.001 n=49+46) Tar 223ms ± 2% 224ms ± 2% +0.37% (p=0.046 n=48+46) XML 310ms ± 2% 311ms ± 2% +0.46% (p=0.009 n=50+49) [Geo mean] 554ms 556ms +0.36% Change-Id: I85951a6538373ef4309a2cc366cc1ebaf1f4582d Reviewed-on: https://go-review.googlesource.com/c/go/+/214818 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2020-01-14 05:08:47 -08:00
"sync"
"unicode/utf8"
)
// A FmtFlag value is a set of flags (or 0).
// They control how the Xconv functions format their values.
// See the respective function's documentation for details.
type FmtFlag int
const ( // fmt.Format flag/prec or verb
FmtLeft FmtFlag = 1 << iota // '-'
FmtSharp // '#'
FmtSign // '+'
FmtUnsigned // internal use only (historic: u flag)
FmtShort // verb == 'S' (historic: h flag)
FmtLong // verb == 'L' (historic: l flag)
FmtComma // '.' (== hasPrec) (historic: , flag)
FmtByte // '0' (historic: hh flag)
)
// fmtFlag computes the (internal) FmtFlag
// value given the fmt.State and format verb.
func fmtFlag(s fmt.State, verb rune) FmtFlag {
var flag FmtFlag
if s.Flag('-') {
flag |= FmtLeft
}
if s.Flag('#') {
flag |= FmtSharp
}
if s.Flag('+') {
flag |= FmtSign
}
if s.Flag(' ') {
Fatalf("FmtUnsigned in format string")
}
if _, ok := s.Precision(); ok {
flag |= FmtComma
}
if s.Flag('0') {
flag |= FmtByte
}
switch verb {
case 'S':
flag |= FmtShort
case 'L':
flag |= FmtLong
}
return flag
}
// Format conversions:
// TODO(gri) verify these; eliminate those not used anymore
//
// %v Op Node opcodes
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
// Flags: #: print Go syntax (automatic unless mode == FDbg)
//
// %j *Node Node details
// Flags: 0: suppresses things not relevant until walk
//
// %v *Val Constant values
//
// %v *types.Sym Symbols
// %S unqualified identifier in any mode
// Flags: +,- #: mode (see below)
// 0: in export mode: unqualified identifier if exported, qualified if not
//
// %v *types.Type Types
// %S omit "func" and receiver in function types
// %L definition instead of name.
// Flags: +,- #: mode (see below)
// ' ' (only in -/Sym mode) print type identifiers wit package name instead of prefix.
//
// %v *Node Nodes
// %S (only in +/debug mode) suppress recursion
// %L (only in Error mode) print "foo (type Bar)"
// Flags: +,- #: mode (see below)
//
// %v Nodes Node lists
// Flags: those of *Node
// .: separate items with ',' instead of ';'
// *types.Sym, *types.Type, and *Node types use the flags below to set the format mode
const (
FErr fmtMode = iota
FDbg
FTypeId
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
FTypeIdName // same as FTypeId, but use package name instead of prefix
)
// The mode flags '+', '-', and '#' are sticky; they persist through
// recursions of *Node, *types.Type, and *types.Sym values. The ' ' flag is
// sticky only on *types.Type recursions and only used in %-/*types.Sym mode.
//
// Example: given a *types.Sym: %+v %#v %-v print an identifier properly qualified for debug/export/internal mode
// Useful format combinations:
// TODO(gri): verify these
//
// *Node, Nodes:
// %+v multiline recursive debug dump of *Node/Nodes
// %+S non-recursive debug dump
//
// *Node:
// %#v Go format
// %L "foo (type Bar)" for error messages
//
// *types.Type:
// %#v Go format
// %#L type definition instead of name
// %#S omit "func" and receiver in function signature
//
// %-v type identifiers
// %-S type identifiers without "func" and arg names in type signatures (methodsym)
// %- v type identifiers with package name instead of prefix (typesym, dcommontype, typehash)
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
// update returns the results of applying f to mode.
func (f FmtFlag) update(mode fmtMode) (FmtFlag, fmtMode) {
switch {
case f&FmtSign != 0:
mode = FDbg
case f&FmtSharp != 0:
// ignore (textual export format no longer supported)
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
case f&FmtUnsigned != 0:
mode = FTypeIdName
case f&FmtLeft != 0:
mode = FTypeId
}
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
f &^= FmtSharp | FmtLeft | FmtSign
return f, mode
}
var goopnames = []string{
OADDR: "&",
OADD: "+",
OADDSTR: "+",
OALIGNOF: "unsafe.Alignof",
OANDAND: "&&",
OANDNOT: "&^",
OAND: "&",
OAPPEND: "append",
OAS: "=",
OAS2: "=",
OBREAK: "break",
OCALL: "function call", // not actual syntax
OCAP: "cap",
OCASE: "case",
OCLOSE: "close",
OCOMPLEX: "complex",
cmd/compile: bulk rename This change does a bulk rename of several identifiers in the compiler. See #27167 and https://docs.google.com/document/d/19_ExiylD9MRfeAjKIfEsMU1_RGhuxB9sA0b5Zv7byVI/ for context and for discussion of these particular renames. Commands run to generate this change: gorename -from '"cmd/compile/internal/gc".OPROC' -to OGO gorename -from '"cmd/compile/internal/gc".OCOM' -to OBITNOT gorename -from '"cmd/compile/internal/gc".OMINUS' -to ONEG gorename -from '"cmd/compile/internal/gc".OIND' -to ODEREF gorename -from '"cmd/compile/internal/gc".OARRAYBYTESTR' -to OBYTES2STR gorename -from '"cmd/compile/internal/gc".OARRAYBYTESTRTMP' -to OBYTES2STRTMP gorename -from '"cmd/compile/internal/gc".OARRAYRUNESTR' -to ORUNES2STR gorename -from '"cmd/compile/internal/gc".OSTRARRAYBYTE' -to OSTR2BYTES gorename -from '"cmd/compile/internal/gc".OSTRARRAYBYTETMP' -to OSTR2BYTESTMP gorename -from '"cmd/compile/internal/gc".OSTRARRAYRUNE' -to OSTR2RUNES gorename -from '"cmd/compile/internal/gc".Etop' -to ctxStmt gorename -from '"cmd/compile/internal/gc".Erv' -to ctxExpr gorename -from '"cmd/compile/internal/gc".Ecall' -to ctxCallee gorename -from '"cmd/compile/internal/gc".Efnstruct' -to ctxMultiOK gorename -from '"cmd/compile/internal/gc".Easgn' -to ctxAssign gorename -from '"cmd/compile/internal/gc".Ecomplit' -to ctxCompLit Not altered: parameters and local variables (mostly in typecheck.go) named top, which should probably now be called ctx (and which should probably have a named type). Also not altered: Field called Top in gc.Func. gorename -from '"cmd/compile/internal/gc".Node.Isddd' -to IsDDD gorename -from '"cmd/compile/internal/gc".Node.SetIsddd' -to SetIsDDD gorename -from '"cmd/compile/internal/gc".nodeIsddd' -to nodeIsDDD gorename -from '"cmd/compile/internal/types".Field.Isddd' -to IsDDD gorename -from '"cmd/compile/internal/types".Field.SetIsddd' -to SetIsDDD gorename -from '"cmd/compile/internal/types".fieldIsddd' -to fieldIsDDD Not altered: function gc.hasddd, params and local variables called isddd Also not altered: fmt.go prints nodes using "isddd(%v)". cd cmd/compile/internal/gc; go generate I then manually found impacted comments using exact string match and fixed them up by hand. The comment changes were trivial. Passes toolstash-check. Fixes #27167. If this experiment is deemed a success, we will open a new tracking issue for renames to do at the end of the 1.13 cycles. Change-Id: I2dc541533d2ab0d06cb3d31d65df205ecfb151e8 Reviewed-on: https://go-review.googlesource.com/c/150140 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2018-11-18 08:34:38 -08:00
OBITNOT: "^",
OCONTINUE: "continue",
OCOPY: "copy",
ODELETE: "delete",
ODEFER: "defer",
ODIV: "/",
OEQ: "==",
OFALL: "fallthrough",
OFOR: "for",
OFORUNTIL: "foruntil", // not actual syntax; used to avoid off-end pointer live on backedge.892
OGE: ">=",
OGOTO: "goto",
OGT: ">",
OIF: "if",
OIMAG: "imag",
OINLMARK: "inlmark",
cmd/compile: bulk rename This change does a bulk rename of several identifiers in the compiler. See #27167 and https://docs.google.com/document/d/19_ExiylD9MRfeAjKIfEsMU1_RGhuxB9sA0b5Zv7byVI/ for context and for discussion of these particular renames. Commands run to generate this change: gorename -from '"cmd/compile/internal/gc".OPROC' -to OGO gorename -from '"cmd/compile/internal/gc".OCOM' -to OBITNOT gorename -from '"cmd/compile/internal/gc".OMINUS' -to ONEG gorename -from '"cmd/compile/internal/gc".OIND' -to ODEREF gorename -from '"cmd/compile/internal/gc".OARRAYBYTESTR' -to OBYTES2STR gorename -from '"cmd/compile/internal/gc".OARRAYBYTESTRTMP' -to OBYTES2STRTMP gorename -from '"cmd/compile/internal/gc".OARRAYRUNESTR' -to ORUNES2STR gorename -from '"cmd/compile/internal/gc".OSTRARRAYBYTE' -to OSTR2BYTES gorename -from '"cmd/compile/internal/gc".OSTRARRAYBYTETMP' -to OSTR2BYTESTMP gorename -from '"cmd/compile/internal/gc".OSTRARRAYRUNE' -to OSTR2RUNES gorename -from '"cmd/compile/internal/gc".Etop' -to ctxStmt gorename -from '"cmd/compile/internal/gc".Erv' -to ctxExpr gorename -from '"cmd/compile/internal/gc".Ecall' -to ctxCallee gorename -from '"cmd/compile/internal/gc".Efnstruct' -to ctxMultiOK gorename -from '"cmd/compile/internal/gc".Easgn' -to ctxAssign gorename -from '"cmd/compile/internal/gc".Ecomplit' -to ctxCompLit Not altered: parameters and local variables (mostly in typecheck.go) named top, which should probably now be called ctx (and which should probably have a named type). Also not altered: Field called Top in gc.Func. gorename -from '"cmd/compile/internal/gc".Node.Isddd' -to IsDDD gorename -from '"cmd/compile/internal/gc".Node.SetIsddd' -to SetIsDDD gorename -from '"cmd/compile/internal/gc".nodeIsddd' -to nodeIsDDD gorename -from '"cmd/compile/internal/types".Field.Isddd' -to IsDDD gorename -from '"cmd/compile/internal/types".Field.SetIsddd' -to SetIsDDD gorename -from '"cmd/compile/internal/types".fieldIsddd' -to fieldIsDDD Not altered: function gc.hasddd, params and local variables called isddd Also not altered: fmt.go prints nodes using "isddd(%v)". cd cmd/compile/internal/gc; go generate I then manually found impacted comments using exact string match and fixed them up by hand. The comment changes were trivial. Passes toolstash-check. Fixes #27167. If this experiment is deemed a success, we will open a new tracking issue for renames to do at the end of the 1.13 cycles. Change-Id: I2dc541533d2ab0d06cb3d31d65df205ecfb151e8 Reviewed-on: https://go-review.googlesource.com/c/150140 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2018-11-18 08:34:38 -08:00
ODEREF: "*",
OLEN: "len",
OLE: "<=",
OLSH: "<<",
OLT: "<",
OMAKE: "make",
cmd/compile: bulk rename This change does a bulk rename of several identifiers in the compiler. See #27167 and https://docs.google.com/document/d/19_ExiylD9MRfeAjKIfEsMU1_RGhuxB9sA0b5Zv7byVI/ for context and for discussion of these particular renames. Commands run to generate this change: gorename -from '"cmd/compile/internal/gc".OPROC' -to OGO gorename -from '"cmd/compile/internal/gc".OCOM' -to OBITNOT gorename -from '"cmd/compile/internal/gc".OMINUS' -to ONEG gorename -from '"cmd/compile/internal/gc".OIND' -to ODEREF gorename -from '"cmd/compile/internal/gc".OARRAYBYTESTR' -to OBYTES2STR gorename -from '"cmd/compile/internal/gc".OARRAYBYTESTRTMP' -to OBYTES2STRTMP gorename -from '"cmd/compile/internal/gc".OARRAYRUNESTR' -to ORUNES2STR gorename -from '"cmd/compile/internal/gc".OSTRARRAYBYTE' -to OSTR2BYTES gorename -from '"cmd/compile/internal/gc".OSTRARRAYBYTETMP' -to OSTR2BYTESTMP gorename -from '"cmd/compile/internal/gc".OSTRARRAYRUNE' -to OSTR2RUNES gorename -from '"cmd/compile/internal/gc".Etop' -to ctxStmt gorename -from '"cmd/compile/internal/gc".Erv' -to ctxExpr gorename -from '"cmd/compile/internal/gc".Ecall' -to ctxCallee gorename -from '"cmd/compile/internal/gc".Efnstruct' -to ctxMultiOK gorename -from '"cmd/compile/internal/gc".Easgn' -to ctxAssign gorename -from '"cmd/compile/internal/gc".Ecomplit' -to ctxCompLit Not altered: parameters and local variables (mostly in typecheck.go) named top, which should probably now be called ctx (and which should probably have a named type). Also not altered: Field called Top in gc.Func. gorename -from '"cmd/compile/internal/gc".Node.Isddd' -to IsDDD gorename -from '"cmd/compile/internal/gc".Node.SetIsddd' -to SetIsDDD gorename -from '"cmd/compile/internal/gc".nodeIsddd' -to nodeIsDDD gorename -from '"cmd/compile/internal/types".Field.Isddd' -to IsDDD gorename -from '"cmd/compile/internal/types".Field.SetIsddd' -to SetIsDDD gorename -from '"cmd/compile/internal/types".fieldIsddd' -to fieldIsDDD Not altered: function gc.hasddd, params and local variables called isddd Also not altered: fmt.go prints nodes using "isddd(%v)". cd cmd/compile/internal/gc; go generate I then manually found impacted comments using exact string match and fixed them up by hand. The comment changes were trivial. Passes toolstash-check. Fixes #27167. If this experiment is deemed a success, we will open a new tracking issue for renames to do at the end of the 1.13 cycles. Change-Id: I2dc541533d2ab0d06cb3d31d65df205ecfb151e8 Reviewed-on: https://go-review.googlesource.com/c/150140 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2018-11-18 08:34:38 -08:00
ONEG: "-",
OMOD: "%",
OMUL: "*",
ONEW: "new",
ONE: "!=",
ONOT: "!",
OOFFSETOF: "unsafe.Offsetof",
OOROR: "||",
OOR: "|",
OPANIC: "panic",
OPLUS: "+",
OPRINTN: "println",
OPRINT: "print",
ORANGE: "range",
OREAL: "real",
ORECV: "<-",
ORECOVER: "recover",
ORETURN: "return",
ORSH: ">>",
OSELECT: "select",
OSEND: "<-",
OSIZEOF: "unsafe.Sizeof",
OSUB: "-",
OSWITCH: "switch",
OXOR: "^",
}
func (o Op) GoString() string {
return fmt.Sprintf("%#v", o)
}
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
func (o Op) format(s fmt.State, verb rune, mode fmtMode) {
switch verb {
case 'v':
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
o.oconv(s, fmtFlag(s, verb), mode)
default:
fmt.Fprintf(s, "%%!%c(Op=%d)", verb, int(o))
}
}
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
func (o Op) oconv(s fmt.State, flag FmtFlag, mode fmtMode) {
if flag&FmtSharp != 0 || mode != FDbg {
if int(o) < len(goopnames) && goopnames[o] != "" {
fmt.Fprint(s, goopnames[o])
return
}
}
// 'o.String()' instead of just 'o' to avoid infinite recursion
fmt.Fprint(s, o.String())
}
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
type (
fmtMode int
fmtNodeErr Node
fmtNodeDbg Node
fmtNodeTypeId Node
fmtNodeTypeIdName Node
fmtOpErr Op
fmtOpDbg Op
fmtOpTypeId Op
fmtOpTypeIdName Op
fmtTypeErr types.Type
fmtTypeDbg types.Type
fmtTypeTypeId types.Type
fmtTypeTypeIdName types.Type
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
fmtSymErr types.Sym
fmtSymDbg types.Sym
fmtSymTypeId types.Sym
fmtSymTypeIdName types.Sym
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
fmtNodesErr Nodes
fmtNodesDbg Nodes
fmtNodesTypeId Nodes
fmtNodesTypeIdName Nodes
)
func (n *fmtNodeErr) Format(s fmt.State, verb rune) { (*Node)(n).format(s, verb, FErr) }
func (n *fmtNodeDbg) Format(s fmt.State, verb rune) { (*Node)(n).format(s, verb, FDbg) }
func (n *fmtNodeTypeId) Format(s fmt.State, verb rune) { (*Node)(n).format(s, verb, FTypeId) }
func (n *fmtNodeTypeIdName) Format(s fmt.State, verb rune) { (*Node)(n).format(s, verb, FTypeIdName) }
func (n *Node) Format(s fmt.State, verb rune) { n.format(s, verb, FErr) }
func (o fmtOpErr) Format(s fmt.State, verb rune) { Op(o).format(s, verb, FErr) }
func (o fmtOpDbg) Format(s fmt.State, verb rune) { Op(o).format(s, verb, FDbg) }
func (o fmtOpTypeId) Format(s fmt.State, verb rune) { Op(o).format(s, verb, FTypeId) }
func (o fmtOpTypeIdName) Format(s fmt.State, verb rune) { Op(o).format(s, verb, FTypeIdName) }
func (o Op) Format(s fmt.State, verb rune) { o.format(s, verb, FErr) }
func (t *fmtTypeErr) Format(s fmt.State, verb rune) { typeFormat((*types.Type)(t), s, verb, FErr) }
func (t *fmtTypeDbg) Format(s fmt.State, verb rune) { typeFormat((*types.Type)(t), s, verb, FDbg) }
func (t *fmtTypeTypeId) Format(s fmt.State, verb rune) {
typeFormat((*types.Type)(t), s, verb, FTypeId)
}
func (t *fmtTypeTypeIdName) Format(s fmt.State, verb rune) {
typeFormat((*types.Type)(t), s, verb, FTypeIdName)
}
// func (t *types.Type) Format(s fmt.State, verb rune) // in package types
func (y *fmtSymErr) Format(s fmt.State, verb rune) { symFormat((*types.Sym)(y), s, verb, FErr) }
func (y *fmtSymDbg) Format(s fmt.State, verb rune) { symFormat((*types.Sym)(y), s, verb, FDbg) }
func (y *fmtSymTypeId) Format(s fmt.State, verb rune) { symFormat((*types.Sym)(y), s, verb, FTypeId) }
func (y *fmtSymTypeIdName) Format(s fmt.State, verb rune) {
symFormat((*types.Sym)(y), s, verb, FTypeIdName)
}
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
// func (y *types.Sym) Format(s fmt.State, verb rune) // in package types { y.format(s, verb, FErr) }
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
func (n fmtNodesErr) Format(s fmt.State, verb rune) { (Nodes)(n).format(s, verb, FErr) }
func (n fmtNodesDbg) Format(s fmt.State, verb rune) { (Nodes)(n).format(s, verb, FDbg) }
func (n fmtNodesTypeId) Format(s fmt.State, verb rune) { (Nodes)(n).format(s, verb, FTypeId) }
func (n fmtNodesTypeIdName) Format(s fmt.State, verb rune) { (Nodes)(n).format(s, verb, FTypeIdName) }
func (n Nodes) Format(s fmt.State, verb rune) { n.format(s, verb, FErr) }
func (m fmtMode) Fprintf(s fmt.State, format string, args ...interface{}) {
m.prepareArgs(args)
fmt.Fprintf(s, format, args...)
}
func (m fmtMode) Sprintf(format string, args ...interface{}) string {
m.prepareArgs(args)
return fmt.Sprintf(format, args...)
}
func (m fmtMode) Sprint(args ...interface{}) string {
m.prepareArgs(args)
return fmt.Sprint(args...)
}
func (m fmtMode) prepareArgs(args []interface{}) {
switch m {
case FErr:
for i, arg := range args {
switch arg := arg.(type) {
case Op:
args[i] = fmtOpErr(arg)
case *Node:
args[i] = (*fmtNodeErr)(arg)
case *types.Type:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
args[i] = (*fmtTypeErr)(arg)
case *types.Sym:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
args[i] = (*fmtSymErr)(arg)
case Nodes:
args[i] = fmtNodesErr(arg)
case Val, int32, int64, string, types.EType:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
// OK: printing these types doesn't depend on mode
default:
Fatalf("mode.prepareArgs type %T", arg)
}
}
case FDbg:
for i, arg := range args {
switch arg := arg.(type) {
case Op:
args[i] = fmtOpDbg(arg)
case *Node:
args[i] = (*fmtNodeDbg)(arg)
case *types.Type:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
args[i] = (*fmtTypeDbg)(arg)
case *types.Sym:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
args[i] = (*fmtSymDbg)(arg)
case Nodes:
args[i] = fmtNodesDbg(arg)
case Val, int32, int64, string, types.EType:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
// OK: printing these types doesn't depend on mode
default:
Fatalf("mode.prepareArgs type %T", arg)
}
}
case FTypeId:
for i, arg := range args {
switch arg := arg.(type) {
case Op:
args[i] = fmtOpTypeId(arg)
case *Node:
args[i] = (*fmtNodeTypeId)(arg)
case *types.Type:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
args[i] = (*fmtTypeTypeId)(arg)
case *types.Sym:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
args[i] = (*fmtSymTypeId)(arg)
case Nodes:
args[i] = fmtNodesTypeId(arg)
case Val, int32, int64, string, types.EType:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
// OK: printing these types doesn't depend on mode
default:
Fatalf("mode.prepareArgs type %T", arg)
}
}
case FTypeIdName:
for i, arg := range args {
switch arg := arg.(type) {
case Op:
args[i] = fmtOpTypeIdName(arg)
case *Node:
args[i] = (*fmtNodeTypeIdName)(arg)
case *types.Type:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
args[i] = (*fmtTypeTypeIdName)(arg)
case *types.Sym:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
args[i] = (*fmtSymTypeIdName)(arg)
case Nodes:
args[i] = fmtNodesTypeIdName(arg)
case Val, int32, int64, string, types.EType:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
// OK: printing these types doesn't depend on mode
default:
Fatalf("mode.prepareArgs type %T", arg)
}
}
default:
Fatalf("mode.prepareArgs mode %d", m)
}
}
func (n *Node) format(s fmt.State, verb rune, mode fmtMode) {
switch verb {
case 'v', 'S', 'L':
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
n.nconv(s, fmtFlag(s, verb), mode)
case 'j':
n.jconv(s, fmtFlag(s, verb))
default:
fmt.Fprintf(s, "%%!%c(*Node=%p)", verb, n)
}
}
// *Node details
func (n *Node) jconv(s fmt.State, flag FmtFlag) {
c := flag & FmtShort
// Useful to see which nodes in a Node Dump/dumplist are actually identical
if Debug_dumpptrs != 0 {
fmt.Fprintf(s, " p(%p)", n)
}
if c == 0 && n.Name != nil && n.Name.Vargen != 0 {
fmt.Fprintf(s, " g(%d)", n.Name.Vargen)
}
if Debug_dumpptrs != 0 && c == 0 && n.Name != nil && n.Name.Defn != nil {
// Useful to see where Defn is set and what node it points to
fmt.Fprintf(s, " defn(%p)", n.Name.Defn)
}
if n.Pos.IsKnown() {
pfx := ""
switch n.Pos.IsStmt() {
case src.PosNotStmt:
pfx = "_" // "-" would be confusing
case src.PosIsStmt:
pfx = "+"
}
fmt.Fprintf(s, " l(%s%d)", pfx, n.Pos.Line())
}
if c == 0 && n.Xoffset != BADWIDTH {
fmt.Fprintf(s, " x(%d)", n.Xoffset)
}
cmd/compile: move Node.Class to flags Put it at position zero, since it is fairly hot. This shrinks gc.Node into a smaller size class on 64 bit systems. name old time/op new time/op delta Template 193ms ± 5% 192ms ± 3% ~ (p=0.353 n=94+93) Unicode 86.1ms ± 5% 85.0ms ± 4% -1.23% (p=0.000 n=95+98) GoTypes 546ms ± 3% 544ms ± 4% -0.40% (p=0.007 n=94+97) Compiler 2.56s ± 3% 2.54s ± 3% -0.67% (p=0.000 n=99+97) SSA 5.13s ± 2% 5.10s ± 3% -0.55% (p=0.000 n=94+98) Flate 122ms ± 6% 121ms ± 4% -0.75% (p=0.002 n=97+95) GoParser 144ms ± 5% 144ms ± 4% ~ (p=0.298 n=98+97) Reflect 348ms ± 4% 349ms ± 4% ~ (p=0.350 n=98+97) Tar 105ms ± 5% 104ms ± 5% ~ (p=0.154 n=96+98) XML 200ms ± 5% 198ms ± 4% -0.71% (p=0.015 n=97+98) [Geo mean] 330ms 328ms -0.52% name old user-time/op new user-time/op delta Template 229ms ±11% 224ms ± 7% -2.16% (p=0.001 n=100+87) Unicode 109ms ± 5% 109ms ± 6% ~ (p=0.897 n=96+91) GoTypes 712ms ± 4% 709ms ± 4% ~ (p=0.085 n=96+98) Compiler 3.41s ± 3% 3.36s ± 3% -1.43% (p=0.000 n=98+98) SSA 7.46s ± 3% 7.31s ± 3% -2.02% (p=0.000 n=100+99) Flate 145ms ± 6% 143ms ± 6% -1.11% (p=0.001 n=99+97) GoParser 177ms ± 5% 176ms ± 5% -0.78% (p=0.018 n=95+95) Reflect 432ms ± 7% 435ms ± 9% ~ (p=0.296 n=100+100) Tar 121ms ± 7% 121ms ± 5% ~ (p=0.072 n=100+95) XML 241ms ± 4% 239ms ± 5% ~ (p=0.085 n=97+99) [Geo mean] 413ms 410ms -0.73% name old alloc/op new alloc/op delta Template 38.4MB ± 0% 37.7MB ± 0% -1.85% (p=0.008 n=5+5) Unicode 30.1MB ± 0% 28.8MB ± 0% -4.09% (p=0.008 n=5+5) GoTypes 112MB ± 0% 110MB ± 0% -1.69% (p=0.008 n=5+5) Compiler 470MB ± 0% 461MB ± 0% -1.91% (p=0.008 n=5+5) SSA 1.13GB ± 0% 1.11GB ± 0% -1.70% (p=0.008 n=5+5) Flate 25.0MB ± 0% 24.6MB ± 0% -1.67% (p=0.008 n=5+5) GoParser 31.6MB ± 0% 31.1MB ± 0% -1.66% (p=0.008 n=5+5) Reflect 77.1MB ± 0% 75.8MB ± 0% -1.69% (p=0.008 n=5+5) Tar 26.3MB ± 0% 25.7MB ± 0% -2.06% (p=0.008 n=5+5) XML 41.9MB ± 0% 41.1MB ± 0% -1.93% (p=0.008 n=5+5) [Geo mean] 73.5MB 72.0MB -2.03% name old allocs/op new allocs/op delta Template 383k ± 0% 383k ± 0% ~ (p=0.690 n=5+5) Unicode 343k ± 0% 343k ± 0% ~ (p=0.841 n=5+5) GoTypes 1.16M ± 0% 1.16M ± 0% ~ (p=0.310 n=5+5) Compiler 4.43M ± 0% 4.42M ± 0% -0.17% (p=0.008 n=5+5) SSA 9.85M ± 0% 9.85M ± 0% ~ (p=0.310 n=5+5) Flate 236k ± 0% 236k ± 1% ~ (p=0.841 n=5+5) GoParser 320k ± 0% 320k ± 0% ~ (p=0.421 n=5+5) Reflect 988k ± 0% 987k ± 0% ~ (p=0.690 n=5+5) Tar 252k ± 0% 251k ± 0% ~ (p=0.095 n=5+5) XML 399k ± 0% 399k ± 0% ~ (p=1.000 n=5+5) [Geo mean] 741k 740k -0.07% Change-Id: I9e952b58a98e30a12494304db9ce50d0a85e459c Reviewed-on: https://go-review.googlesource.com/41797 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Marvin Stenger <marvin.stenger94@gmail.com>
2017-04-25 18:14:12 -07:00
if n.Class() != 0 {
fmt.Fprintf(s, " class(%v)", n.Class())
}
cmd/compile: pack bool fields in Node, Name, Func and Type structs to bitsets This reduces compiler memory usage by up to 4% - see compilebench results below. name old time/op new time/op delta Template 245ms ± 4% 241ms ± 2% -1.88% (p=0.029 n=10+10) Unicode 126ms ± 3% 124ms ± 3% ~ (p=0.105 n=10+10) GoTypes 805ms ± 2% 813ms ± 3% ~ (p=0.515 n=8+10) Compiler 3.95s ± 2% 3.83s ± 1% -2.96% (p=0.000 n=9+10) MakeBash 47.4s ± 4% 46.6s ± 1% -1.59% (p=0.028 n=9+10) name old user-ns/op new user-ns/op delta Template 324M ± 5% 326M ± 3% ~ (p=0.935 n=10+10) Unicode 186M ± 5% 178M ±10% ~ (p=0.067 n=9+10) GoTypes 1.08G ± 7% 1.09G ± 4% ~ (p=0.956 n=10+10) Compiler 5.34G ± 4% 5.31G ± 1% ~ (p=0.501 n=10+8) name old alloc/op new alloc/op delta Template 41.0MB ± 0% 39.8MB ± 0% -3.03% (p=0.000 n=10+10) Unicode 32.3MB ± 0% 31.0MB ± 0% -4.13% (p=0.000 n=10+10) GoTypes 119MB ± 0% 116MB ± 0% -2.39% (p=0.000 n=10+10) Compiler 499MB ± 0% 487MB ± 0% -2.48% (p=0.000 n=10+10) name old allocs/op new allocs/op delta Template 380k ± 1% 379k ± 1% ~ (p=0.436 n=10+10) Unicode 324k ± 1% 324k ± 0% ~ (p=0.853 n=10+10) GoTypes 1.15M ± 0% 1.15M ± 0% ~ (p=0.481 n=10+10) Compiler 4.41M ± 0% 4.41M ± 0% -0.12% (p=0.007 n=10+10) name old text-bytes new text-bytes delta HelloSize 623k ± 0% 623k ± 0% ~ (all equal) CmdGoSize 6.64M ± 0% 6.64M ± 0% ~ (all equal) name old data-bytes new data-bytes delta HelloSize 5.81k ± 0% 5.81k ± 0% ~ (all equal) CmdGoSize 238k ± 0% 238k ± 0% ~ (all equal) name old bss-bytes new bss-bytes delta HelloSize 134k ± 0% 134k ± 0% ~ (all equal) CmdGoSize 152k ± 0% 152k ± 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 967k ± 0% 967k ± 0% ~ (all equal) CmdGoSize 10.2M ± 0% 10.2M ± 0% ~ (all equal) Change-Id: I1f40af738254892bd6c8ba2eb43390b175753d52 Reviewed-on: https://go-review.googlesource.com/37445 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2017-02-27 19:56:38 +02:00
if n.Colas() {
fmt.Fprintf(s, " colas(%v)", n.Colas())
}
switch n.Esc {
case EscUnknown:
break
case EscHeap:
fmt.Fprint(s, " esc(h)")
case EscNone:
fmt.Fprint(s, " esc(no)")
case EscNever:
if c == 0 {
fmt.Fprint(s, " esc(N)")
}
default:
fmt.Fprintf(s, " esc(%d)", n.Esc)
}
if e, ok := n.Opt().(*EscLocation); ok && e.loopDepth != 0 {
fmt.Fprintf(s, " ld(%d)", e.loopDepth)
}
if c == 0 && n.Typecheck() != 0 {
fmt.Fprintf(s, " tc(%d)", n.Typecheck())
}
cmd/compile: bulk rename This change does a bulk rename of several identifiers in the compiler. See #27167 and https://docs.google.com/document/d/19_ExiylD9MRfeAjKIfEsMU1_RGhuxB9sA0b5Zv7byVI/ for context and for discussion of these particular renames. Commands run to generate this change: gorename -from '"cmd/compile/internal/gc".OPROC' -to OGO gorename -from '"cmd/compile/internal/gc".OCOM' -to OBITNOT gorename -from '"cmd/compile/internal/gc".OMINUS' -to ONEG gorename -from '"cmd/compile/internal/gc".OIND' -to ODEREF gorename -from '"cmd/compile/internal/gc".OARRAYBYTESTR' -to OBYTES2STR gorename -from '"cmd/compile/internal/gc".OARRAYBYTESTRTMP' -to OBYTES2STRTMP gorename -from '"cmd/compile/internal/gc".OARRAYRUNESTR' -to ORUNES2STR gorename -from '"cmd/compile/internal/gc".OSTRARRAYBYTE' -to OSTR2BYTES gorename -from '"cmd/compile/internal/gc".OSTRARRAYBYTETMP' -to OSTR2BYTESTMP gorename -from '"cmd/compile/internal/gc".OSTRARRAYRUNE' -to OSTR2RUNES gorename -from '"cmd/compile/internal/gc".Etop' -to ctxStmt gorename -from '"cmd/compile/internal/gc".Erv' -to ctxExpr gorename -from '"cmd/compile/internal/gc".Ecall' -to ctxCallee gorename -from '"cmd/compile/internal/gc".Efnstruct' -to ctxMultiOK gorename -from '"cmd/compile/internal/gc".Easgn' -to ctxAssign gorename -from '"cmd/compile/internal/gc".Ecomplit' -to ctxCompLit Not altered: parameters and local variables (mostly in typecheck.go) named top, which should probably now be called ctx (and which should probably have a named type). Also not altered: Field called Top in gc.Func. gorename -from '"cmd/compile/internal/gc".Node.Isddd' -to IsDDD gorename -from '"cmd/compile/internal/gc".Node.SetIsddd' -to SetIsDDD gorename -from '"cmd/compile/internal/gc".nodeIsddd' -to nodeIsDDD gorename -from '"cmd/compile/internal/types".Field.Isddd' -to IsDDD gorename -from '"cmd/compile/internal/types".Field.SetIsddd' -to SetIsDDD gorename -from '"cmd/compile/internal/types".fieldIsddd' -to fieldIsDDD Not altered: function gc.hasddd, params and local variables called isddd Also not altered: fmt.go prints nodes using "isddd(%v)". cd cmd/compile/internal/gc; go generate I then manually found impacted comments using exact string match and fixed them up by hand. The comment changes were trivial. Passes toolstash-check. Fixes #27167. If this experiment is deemed a success, we will open a new tracking issue for renames to do at the end of the 1.13 cycles. Change-Id: I2dc541533d2ab0d06cb3d31d65df205ecfb151e8 Reviewed-on: https://go-review.googlesource.com/c/150140 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2018-11-18 08:34:38 -08:00
if n.IsDDD() {
fmt.Fprintf(s, " isddd(%v)", n.IsDDD())
}
cmd/compile: pack bool fields in Node, Name, Func and Type structs to bitsets This reduces compiler memory usage by up to 4% - see compilebench results below. name old time/op new time/op delta Template 245ms ± 4% 241ms ± 2% -1.88% (p=0.029 n=10+10) Unicode 126ms ± 3% 124ms ± 3% ~ (p=0.105 n=10+10) GoTypes 805ms ± 2% 813ms ± 3% ~ (p=0.515 n=8+10) Compiler 3.95s ± 2% 3.83s ± 1% -2.96% (p=0.000 n=9+10) MakeBash 47.4s ± 4% 46.6s ± 1% -1.59% (p=0.028 n=9+10) name old user-ns/op new user-ns/op delta Template 324M ± 5% 326M ± 3% ~ (p=0.935 n=10+10) Unicode 186M ± 5% 178M ±10% ~ (p=0.067 n=9+10) GoTypes 1.08G ± 7% 1.09G ± 4% ~ (p=0.956 n=10+10) Compiler 5.34G ± 4% 5.31G ± 1% ~ (p=0.501 n=10+8) name old alloc/op new alloc/op delta Template 41.0MB ± 0% 39.8MB ± 0% -3.03% (p=0.000 n=10+10) Unicode 32.3MB ± 0% 31.0MB ± 0% -4.13% (p=0.000 n=10+10) GoTypes 119MB ± 0% 116MB ± 0% -2.39% (p=0.000 n=10+10) Compiler 499MB ± 0% 487MB ± 0% -2.48% (p=0.000 n=10+10) name old allocs/op new allocs/op delta Template 380k ± 1% 379k ± 1% ~ (p=0.436 n=10+10) Unicode 324k ± 1% 324k ± 0% ~ (p=0.853 n=10+10) GoTypes 1.15M ± 0% 1.15M ± 0% ~ (p=0.481 n=10+10) Compiler 4.41M ± 0% 4.41M ± 0% -0.12% (p=0.007 n=10+10) name old text-bytes new text-bytes delta HelloSize 623k ± 0% 623k ± 0% ~ (all equal) CmdGoSize 6.64M ± 0% 6.64M ± 0% ~ (all equal) name old data-bytes new data-bytes delta HelloSize 5.81k ± 0% 5.81k ± 0% ~ (all equal) CmdGoSize 238k ± 0% 238k ± 0% ~ (all equal) name old bss-bytes new bss-bytes delta HelloSize 134k ± 0% 134k ± 0% ~ (all equal) CmdGoSize 152k ± 0% 152k ± 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 967k ± 0% 967k ± 0% ~ (all equal) CmdGoSize 10.2M ± 0% 10.2M ± 0% ~ (all equal) Change-Id: I1f40af738254892bd6c8ba2eb43390b175753d52 Reviewed-on: https://go-review.googlesource.com/37445 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2017-02-27 19:56:38 +02:00
if n.Implicit() {
fmt.Fprintf(s, " implicit(%v)", n.Implicit())
}
if n.Embedded() {
fmt.Fprintf(s, " embedded")
}
if n.Op == ONAME {
if n.Name.Addrtaken() {
fmt.Fprint(s, " addrtaken")
}
if n.Name.Assigned() {
fmt.Fprint(s, " assigned")
}
if n.Name.IsClosureVar() {
fmt.Fprint(s, " closurevar")
}
if n.Name.Captured() {
fmt.Fprint(s, " captured")
}
if n.Name.IsOutputParamHeapAddr() {
fmt.Fprint(s, " outputparamheapaddr")
}
}
cmd/compile: pack bool fields in Node, Name, Func and Type structs to bitsets This reduces compiler memory usage by up to 4% - see compilebench results below. name old time/op new time/op delta Template 245ms ± 4% 241ms ± 2% -1.88% (p=0.029 n=10+10) Unicode 126ms ± 3% 124ms ± 3% ~ (p=0.105 n=10+10) GoTypes 805ms ± 2% 813ms ± 3% ~ (p=0.515 n=8+10) Compiler 3.95s ± 2% 3.83s ± 1% -2.96% (p=0.000 n=9+10) MakeBash 47.4s ± 4% 46.6s ± 1% -1.59% (p=0.028 n=9+10) name old user-ns/op new user-ns/op delta Template 324M ± 5% 326M ± 3% ~ (p=0.935 n=10+10) Unicode 186M ± 5% 178M ±10% ~ (p=0.067 n=9+10) GoTypes 1.08G ± 7% 1.09G ± 4% ~ (p=0.956 n=10+10) Compiler 5.34G ± 4% 5.31G ± 1% ~ (p=0.501 n=10+8) name old alloc/op new alloc/op delta Template 41.0MB ± 0% 39.8MB ± 0% -3.03% (p=0.000 n=10+10) Unicode 32.3MB ± 0% 31.0MB ± 0% -4.13% (p=0.000 n=10+10) GoTypes 119MB ± 0% 116MB ± 0% -2.39% (p=0.000 n=10+10) Compiler 499MB ± 0% 487MB ± 0% -2.48% (p=0.000 n=10+10) name old allocs/op new allocs/op delta Template 380k ± 1% 379k ± 1% ~ (p=0.436 n=10+10) Unicode 324k ± 1% 324k ± 0% ~ (p=0.853 n=10+10) GoTypes 1.15M ± 0% 1.15M ± 0% ~ (p=0.481 n=10+10) Compiler 4.41M ± 0% 4.41M ± 0% -0.12% (p=0.007 n=10+10) name old text-bytes new text-bytes delta HelloSize 623k ± 0% 623k ± 0% ~ (all equal) CmdGoSize 6.64M ± 0% 6.64M ± 0% ~ (all equal) name old data-bytes new data-bytes delta HelloSize 5.81k ± 0% 5.81k ± 0% ~ (all equal) CmdGoSize 238k ± 0% 238k ± 0% ~ (all equal) name old bss-bytes new bss-bytes delta HelloSize 134k ± 0% 134k ± 0% ~ (all equal) CmdGoSize 152k ± 0% 152k ± 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 967k ± 0% 967k ± 0% ~ (all equal) CmdGoSize 10.2M ± 0% 10.2M ± 0% ~ (all equal) Change-Id: I1f40af738254892bd6c8ba2eb43390b175753d52 Reviewed-on: https://go-review.googlesource.com/37445 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2017-02-27 19:56:38 +02:00
if n.Bounded() {
fmt.Fprint(s, " bounded")
}
cmd/compile: pack bool fields in Node, Name, Func and Type structs to bitsets This reduces compiler memory usage by up to 4% - see compilebench results below. name old time/op new time/op delta Template 245ms ± 4% 241ms ± 2% -1.88% (p=0.029 n=10+10) Unicode 126ms ± 3% 124ms ± 3% ~ (p=0.105 n=10+10) GoTypes 805ms ± 2% 813ms ± 3% ~ (p=0.515 n=8+10) Compiler 3.95s ± 2% 3.83s ± 1% -2.96% (p=0.000 n=9+10) MakeBash 47.4s ± 4% 46.6s ± 1% -1.59% (p=0.028 n=9+10) name old user-ns/op new user-ns/op delta Template 324M ± 5% 326M ± 3% ~ (p=0.935 n=10+10) Unicode 186M ± 5% 178M ±10% ~ (p=0.067 n=9+10) GoTypes 1.08G ± 7% 1.09G ± 4% ~ (p=0.956 n=10+10) Compiler 5.34G ± 4% 5.31G ± 1% ~ (p=0.501 n=10+8) name old alloc/op new alloc/op delta Template 41.0MB ± 0% 39.8MB ± 0% -3.03% (p=0.000 n=10+10) Unicode 32.3MB ± 0% 31.0MB ± 0% -4.13% (p=0.000 n=10+10) GoTypes 119MB ± 0% 116MB ± 0% -2.39% (p=0.000 n=10+10) Compiler 499MB ± 0% 487MB ± 0% -2.48% (p=0.000 n=10+10) name old allocs/op new allocs/op delta Template 380k ± 1% 379k ± 1% ~ (p=0.436 n=10+10) Unicode 324k ± 1% 324k ± 0% ~ (p=0.853 n=10+10) GoTypes 1.15M ± 0% 1.15M ± 0% ~ (p=0.481 n=10+10) Compiler 4.41M ± 0% 4.41M ± 0% -0.12% (p=0.007 n=10+10) name old text-bytes new text-bytes delta HelloSize 623k ± 0% 623k ± 0% ~ (all equal) CmdGoSize 6.64M ± 0% 6.64M ± 0% ~ (all equal) name old data-bytes new data-bytes delta HelloSize 5.81k ± 0% 5.81k ± 0% ~ (all equal) CmdGoSize 238k ± 0% 238k ± 0% ~ (all equal) name old bss-bytes new bss-bytes delta HelloSize 134k ± 0% 134k ± 0% ~ (all equal) CmdGoSize 152k ± 0% 152k ± 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 967k ± 0% 967k ± 0% ~ (all equal) CmdGoSize 10.2M ± 0% 10.2M ± 0% ~ (all equal) Change-Id: I1f40af738254892bd6c8ba2eb43390b175753d52 Reviewed-on: https://go-review.googlesource.com/37445 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2017-02-27 19:56:38 +02:00
if n.NonNil() {
fmt.Fprint(s, " nonnil")
}
if c == 0 && n.HasCall() {
fmt.Fprint(s, " hascall")
}
if c == 0 && n.Name != nil && n.Name.Used() {
fmt.Fprint(s, " used")
}
}
func (v Val) Format(s fmt.State, verb rune) {
switch verb {
case 'v':
v.vconv(s, fmtFlag(s, verb))
default:
fmt.Fprintf(s, "%%!%c(Val=%T)", verb, v)
}
}
func (v Val) vconv(s fmt.State, flag FmtFlag) {
switch u := v.U.(type) {
case *Mpint:
if !u.Rune {
if flag&FmtSharp != 0 {
fmt.Fprint(s, u.String())
return
}
fmt.Fprint(s, u.GoString())
return
}
switch x := u.Int64(); {
case ' ' <= x && x < utf8.RuneSelf && x != '\\' && x != '\'':
fmt.Fprintf(s, "'%c'", int(x))
case 0 <= x && x < 1<<16:
fmt.Fprintf(s, "'\\u%04x'", uint(int(x)))
case 0 <= x && x <= utf8.MaxRune:
fmt.Fprintf(s, "'\\U%08x'", uint64(x))
default:
fmt.Fprintf(s, "('\\x00' + %v)", u)
}
case *Mpflt:
if flag&FmtSharp != 0 {
fmt.Fprint(s, u.String())
return
}
fmt.Fprint(s, u.GoString())
return
case *Mpcplx:
if flag&FmtSharp != 0 {
fmt.Fprint(s, u.String())
return
}
fmt.Fprint(s, u.GoString())
return
case string:
fmt.Fprint(s, strconv.Quote(u))
case bool:
fmt.Fprint(s, u)
case *NilVal:
fmt.Fprint(s, "nil")
default:
fmt.Fprintf(s, "<ctype=%d>", v.Ctype())
}
}
/*
s%,%,\n%g
s%\n+%\n%g
s%^[ ]*T%%g
s%,.*%%g
s%.+% [T&] = "&",%g
s%^ ........*\]%&~%g
s%~ %%g
*/
cmd/compile: use a bytes.Buffer to format symbols No significant compiler speed changes, but some minor memory savings. Passes toolstash-check. name old alloc/op new alloc/op delta Template 36.3MB ± 0% 36.2MB ± 0% -0.25% (p=0.008 n=5+5) Unicode 28.3MB ± 0% 28.2MB ± 0% -0.16% (p=0.008 n=5+5) GoTypes 122MB ± 0% 121MB ± 0% -0.39% (p=0.008 n=5+5) Compiler 568MB ± 0% 566MB ± 0% -0.21% (p=0.008 n=5+5) SSA 1.95GB ± 0% 1.95GB ± 0% -0.08% (p=0.008 n=5+5) Flate 22.8MB ± 0% 22.8MB ± 0% -0.21% (p=0.008 n=5+5) GoParser 28.0MB ± 0% 27.9MB ± 0% -0.38% (p=0.008 n=5+5) Reflect 78.6MB ± 0% 78.3MB ± 0% -0.33% (p=0.008 n=5+5) Tar 34.1MB ± 0% 34.1MB ± 0% -0.19% (p=0.008 n=5+5) XML 44.3MB ± 0% 44.2MB ± 0% -0.19% (p=0.008 n=5+5) [Geo mean] 79.9MB 79.7MB -0.24% name old allocs/op new allocs/op delta Template 363k ± 0% 359k ± 0% -1.21% (p=0.008 n=5+5) Unicode 329k ± 0% 326k ± 0% -0.90% (p=0.008 n=5+5) GoTypes 1.28M ± 0% 1.25M ± 0% -2.62% (p=0.008 n=5+5) Compiler 5.39M ± 0% 5.31M ± 0% -1.45% (p=0.008 n=5+5) SSA 18.1M ± 0% 17.9M ± 0% -0.78% (p=0.008 n=5+5) Flate 228k ± 0% 226k ± 0% -0.97% (p=0.008 n=5+5) GoParser 295k ± 0% 288k ± 0% -2.26% (p=0.008 n=5+5) Reflect 949k ± 0% 932k ± 0% -1.74% (p=0.008 n=5+5) Tar 336k ± 0% 332k ± 0% -1.12% (p=0.008 n=5+5) XML 417k ± 0% 413k ± 0% -1.10% (p=0.008 n=5+5) [Geo mean] 818k 806k -1.42% Change-Id: Ibdb94650a761edec17d8eba0abdfb70a8a495da9 Reviewed-on: https://go-review.googlesource.com/c/go/+/222920 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2020-01-14 16:37:42 -08:00
func symfmt(b *bytes.Buffer, s *types.Sym, flag FmtFlag, mode fmtMode) {
if flag&FmtShort == 0 {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
switch mode {
case FErr: // This is for the user
if s.Pkg == builtinpkg || s.Pkg == localpkg {
cmd/compile: use a bytes.Buffer to format symbols No significant compiler speed changes, but some minor memory savings. Passes toolstash-check. name old alloc/op new alloc/op delta Template 36.3MB ± 0% 36.2MB ± 0% -0.25% (p=0.008 n=5+5) Unicode 28.3MB ± 0% 28.2MB ± 0% -0.16% (p=0.008 n=5+5) GoTypes 122MB ± 0% 121MB ± 0% -0.39% (p=0.008 n=5+5) Compiler 568MB ± 0% 566MB ± 0% -0.21% (p=0.008 n=5+5) SSA 1.95GB ± 0% 1.95GB ± 0% -0.08% (p=0.008 n=5+5) Flate 22.8MB ± 0% 22.8MB ± 0% -0.21% (p=0.008 n=5+5) GoParser 28.0MB ± 0% 27.9MB ± 0% -0.38% (p=0.008 n=5+5) Reflect 78.6MB ± 0% 78.3MB ± 0% -0.33% (p=0.008 n=5+5) Tar 34.1MB ± 0% 34.1MB ± 0% -0.19% (p=0.008 n=5+5) XML 44.3MB ± 0% 44.2MB ± 0% -0.19% (p=0.008 n=5+5) [Geo mean] 79.9MB 79.7MB -0.24% name old allocs/op new allocs/op delta Template 363k ± 0% 359k ± 0% -1.21% (p=0.008 n=5+5) Unicode 329k ± 0% 326k ± 0% -0.90% (p=0.008 n=5+5) GoTypes 1.28M ± 0% 1.25M ± 0% -2.62% (p=0.008 n=5+5) Compiler 5.39M ± 0% 5.31M ± 0% -1.45% (p=0.008 n=5+5) SSA 18.1M ± 0% 17.9M ± 0% -0.78% (p=0.008 n=5+5) Flate 228k ± 0% 226k ± 0% -0.97% (p=0.008 n=5+5) GoParser 295k ± 0% 288k ± 0% -2.26% (p=0.008 n=5+5) Reflect 949k ± 0% 932k ± 0% -1.74% (p=0.008 n=5+5) Tar 336k ± 0% 332k ± 0% -1.12% (p=0.008 n=5+5) XML 417k ± 0% 413k ± 0% -1.10% (p=0.008 n=5+5) [Geo mean] 818k 806k -1.42% Change-Id: Ibdb94650a761edec17d8eba0abdfb70a8a495da9 Reviewed-on: https://go-review.googlesource.com/c/go/+/222920 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2020-01-14 16:37:42 -08:00
b.WriteString(s.Name)
return
}
// If the name was used by multiple packages, display the full path,
if s.Pkg.Name != "" && numImport[s.Pkg.Name] > 1 {
cmd/compile: use a bytes.Buffer to format symbols No significant compiler speed changes, but some minor memory savings. Passes toolstash-check. name old alloc/op new alloc/op delta Template 36.3MB ± 0% 36.2MB ± 0% -0.25% (p=0.008 n=5+5) Unicode 28.3MB ± 0% 28.2MB ± 0% -0.16% (p=0.008 n=5+5) GoTypes 122MB ± 0% 121MB ± 0% -0.39% (p=0.008 n=5+5) Compiler 568MB ± 0% 566MB ± 0% -0.21% (p=0.008 n=5+5) SSA 1.95GB ± 0% 1.95GB ± 0% -0.08% (p=0.008 n=5+5) Flate 22.8MB ± 0% 22.8MB ± 0% -0.21% (p=0.008 n=5+5) GoParser 28.0MB ± 0% 27.9MB ± 0% -0.38% (p=0.008 n=5+5) Reflect 78.6MB ± 0% 78.3MB ± 0% -0.33% (p=0.008 n=5+5) Tar 34.1MB ± 0% 34.1MB ± 0% -0.19% (p=0.008 n=5+5) XML 44.3MB ± 0% 44.2MB ± 0% -0.19% (p=0.008 n=5+5) [Geo mean] 79.9MB 79.7MB -0.24% name old allocs/op new allocs/op delta Template 363k ± 0% 359k ± 0% -1.21% (p=0.008 n=5+5) Unicode 329k ± 0% 326k ± 0% -0.90% (p=0.008 n=5+5) GoTypes 1.28M ± 0% 1.25M ± 0% -2.62% (p=0.008 n=5+5) Compiler 5.39M ± 0% 5.31M ± 0% -1.45% (p=0.008 n=5+5) SSA 18.1M ± 0% 17.9M ± 0% -0.78% (p=0.008 n=5+5) Flate 228k ± 0% 226k ± 0% -0.97% (p=0.008 n=5+5) GoParser 295k ± 0% 288k ± 0% -2.26% (p=0.008 n=5+5) Reflect 949k ± 0% 932k ± 0% -1.74% (p=0.008 n=5+5) Tar 336k ± 0% 332k ± 0% -1.12% (p=0.008 n=5+5) XML 417k ± 0% 413k ± 0% -1.10% (p=0.008 n=5+5) [Geo mean] 818k 806k -1.42% Change-Id: Ibdb94650a761edec17d8eba0abdfb70a8a495da9 Reviewed-on: https://go-review.googlesource.com/c/go/+/222920 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2020-01-14 16:37:42 -08:00
fmt.Fprintf(b, "%q.%s", s.Pkg.Path, s.Name)
return
}
cmd/compile: use a bytes.Buffer to format symbols No significant compiler speed changes, but some minor memory savings. Passes toolstash-check. name old alloc/op new alloc/op delta Template 36.3MB ± 0% 36.2MB ± 0% -0.25% (p=0.008 n=5+5) Unicode 28.3MB ± 0% 28.2MB ± 0% -0.16% (p=0.008 n=5+5) GoTypes 122MB ± 0% 121MB ± 0% -0.39% (p=0.008 n=5+5) Compiler 568MB ± 0% 566MB ± 0% -0.21% (p=0.008 n=5+5) SSA 1.95GB ± 0% 1.95GB ± 0% -0.08% (p=0.008 n=5+5) Flate 22.8MB ± 0% 22.8MB ± 0% -0.21% (p=0.008 n=5+5) GoParser 28.0MB ± 0% 27.9MB ± 0% -0.38% (p=0.008 n=5+5) Reflect 78.6MB ± 0% 78.3MB ± 0% -0.33% (p=0.008 n=5+5) Tar 34.1MB ± 0% 34.1MB ± 0% -0.19% (p=0.008 n=5+5) XML 44.3MB ± 0% 44.2MB ± 0% -0.19% (p=0.008 n=5+5) [Geo mean] 79.9MB 79.7MB -0.24% name old allocs/op new allocs/op delta Template 363k ± 0% 359k ± 0% -1.21% (p=0.008 n=5+5) Unicode 329k ± 0% 326k ± 0% -0.90% (p=0.008 n=5+5) GoTypes 1.28M ± 0% 1.25M ± 0% -2.62% (p=0.008 n=5+5) Compiler 5.39M ± 0% 5.31M ± 0% -1.45% (p=0.008 n=5+5) SSA 18.1M ± 0% 17.9M ± 0% -0.78% (p=0.008 n=5+5) Flate 228k ± 0% 226k ± 0% -0.97% (p=0.008 n=5+5) GoParser 295k ± 0% 288k ± 0% -2.26% (p=0.008 n=5+5) Reflect 949k ± 0% 932k ± 0% -1.74% (p=0.008 n=5+5) Tar 336k ± 0% 332k ± 0% -1.12% (p=0.008 n=5+5) XML 417k ± 0% 413k ± 0% -1.10% (p=0.008 n=5+5) [Geo mean] 818k 806k -1.42% Change-Id: Ibdb94650a761edec17d8eba0abdfb70a8a495da9 Reviewed-on: https://go-review.googlesource.com/c/go/+/222920 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2020-01-14 16:37:42 -08:00
b.WriteString(s.Pkg.Name)
b.WriteByte('.')
b.WriteString(s.Name)
return
case FDbg:
cmd/compile: use a bytes.Buffer to format symbols No significant compiler speed changes, but some minor memory savings. Passes toolstash-check. name old alloc/op new alloc/op delta Template 36.3MB ± 0% 36.2MB ± 0% -0.25% (p=0.008 n=5+5) Unicode 28.3MB ± 0% 28.2MB ± 0% -0.16% (p=0.008 n=5+5) GoTypes 122MB ± 0% 121MB ± 0% -0.39% (p=0.008 n=5+5) Compiler 568MB ± 0% 566MB ± 0% -0.21% (p=0.008 n=5+5) SSA 1.95GB ± 0% 1.95GB ± 0% -0.08% (p=0.008 n=5+5) Flate 22.8MB ± 0% 22.8MB ± 0% -0.21% (p=0.008 n=5+5) GoParser 28.0MB ± 0% 27.9MB ± 0% -0.38% (p=0.008 n=5+5) Reflect 78.6MB ± 0% 78.3MB ± 0% -0.33% (p=0.008 n=5+5) Tar 34.1MB ± 0% 34.1MB ± 0% -0.19% (p=0.008 n=5+5) XML 44.3MB ± 0% 44.2MB ± 0% -0.19% (p=0.008 n=5+5) [Geo mean] 79.9MB 79.7MB -0.24% name old allocs/op new allocs/op delta Template 363k ± 0% 359k ± 0% -1.21% (p=0.008 n=5+5) Unicode 329k ± 0% 326k ± 0% -0.90% (p=0.008 n=5+5) GoTypes 1.28M ± 0% 1.25M ± 0% -2.62% (p=0.008 n=5+5) Compiler 5.39M ± 0% 5.31M ± 0% -1.45% (p=0.008 n=5+5) SSA 18.1M ± 0% 17.9M ± 0% -0.78% (p=0.008 n=5+5) Flate 228k ± 0% 226k ± 0% -0.97% (p=0.008 n=5+5) GoParser 295k ± 0% 288k ± 0% -2.26% (p=0.008 n=5+5) Reflect 949k ± 0% 932k ± 0% -1.74% (p=0.008 n=5+5) Tar 336k ± 0% 332k ± 0% -1.12% (p=0.008 n=5+5) XML 417k ± 0% 413k ± 0% -1.10% (p=0.008 n=5+5) [Geo mean] 818k 806k -1.42% Change-Id: Ibdb94650a761edec17d8eba0abdfb70a8a495da9 Reviewed-on: https://go-review.googlesource.com/c/go/+/222920 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2020-01-14 16:37:42 -08:00
b.WriteString(s.Pkg.Name)
b.WriteByte('.')
b.WriteString(s.Name)
return
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
case FTypeIdName:
cmd/compile: use a bytes.Buffer to format symbols No significant compiler speed changes, but some minor memory savings. Passes toolstash-check. name old alloc/op new alloc/op delta Template 36.3MB ± 0% 36.2MB ± 0% -0.25% (p=0.008 n=5+5) Unicode 28.3MB ± 0% 28.2MB ± 0% -0.16% (p=0.008 n=5+5) GoTypes 122MB ± 0% 121MB ± 0% -0.39% (p=0.008 n=5+5) Compiler 568MB ± 0% 566MB ± 0% -0.21% (p=0.008 n=5+5) SSA 1.95GB ± 0% 1.95GB ± 0% -0.08% (p=0.008 n=5+5) Flate 22.8MB ± 0% 22.8MB ± 0% -0.21% (p=0.008 n=5+5) GoParser 28.0MB ± 0% 27.9MB ± 0% -0.38% (p=0.008 n=5+5) Reflect 78.6MB ± 0% 78.3MB ± 0% -0.33% (p=0.008 n=5+5) Tar 34.1MB ± 0% 34.1MB ± 0% -0.19% (p=0.008 n=5+5) XML 44.3MB ± 0% 44.2MB ± 0% -0.19% (p=0.008 n=5+5) [Geo mean] 79.9MB 79.7MB -0.24% name old allocs/op new allocs/op delta Template 363k ± 0% 359k ± 0% -1.21% (p=0.008 n=5+5) Unicode 329k ± 0% 326k ± 0% -0.90% (p=0.008 n=5+5) GoTypes 1.28M ± 0% 1.25M ± 0% -2.62% (p=0.008 n=5+5) Compiler 5.39M ± 0% 5.31M ± 0% -1.45% (p=0.008 n=5+5) SSA 18.1M ± 0% 17.9M ± 0% -0.78% (p=0.008 n=5+5) Flate 228k ± 0% 226k ± 0% -0.97% (p=0.008 n=5+5) GoParser 295k ± 0% 288k ± 0% -2.26% (p=0.008 n=5+5) Reflect 949k ± 0% 932k ± 0% -1.74% (p=0.008 n=5+5) Tar 336k ± 0% 332k ± 0% -1.12% (p=0.008 n=5+5) XML 417k ± 0% 413k ± 0% -1.10% (p=0.008 n=5+5) [Geo mean] 818k 806k -1.42% Change-Id: Ibdb94650a761edec17d8eba0abdfb70a8a495da9 Reviewed-on: https://go-review.googlesource.com/c/go/+/222920 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2020-01-14 16:37:42 -08:00
// dcommontype, typehash
b.WriteString(s.Pkg.Name)
b.WriteByte('.')
b.WriteString(s.Name)
return
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
case FTypeId:
cmd/compile: use a bytes.Buffer to format symbols No significant compiler speed changes, but some minor memory savings. Passes toolstash-check. name old alloc/op new alloc/op delta Template 36.3MB ± 0% 36.2MB ± 0% -0.25% (p=0.008 n=5+5) Unicode 28.3MB ± 0% 28.2MB ± 0% -0.16% (p=0.008 n=5+5) GoTypes 122MB ± 0% 121MB ± 0% -0.39% (p=0.008 n=5+5) Compiler 568MB ± 0% 566MB ± 0% -0.21% (p=0.008 n=5+5) SSA 1.95GB ± 0% 1.95GB ± 0% -0.08% (p=0.008 n=5+5) Flate 22.8MB ± 0% 22.8MB ± 0% -0.21% (p=0.008 n=5+5) GoParser 28.0MB ± 0% 27.9MB ± 0% -0.38% (p=0.008 n=5+5) Reflect 78.6MB ± 0% 78.3MB ± 0% -0.33% (p=0.008 n=5+5) Tar 34.1MB ± 0% 34.1MB ± 0% -0.19% (p=0.008 n=5+5) XML 44.3MB ± 0% 44.2MB ± 0% -0.19% (p=0.008 n=5+5) [Geo mean] 79.9MB 79.7MB -0.24% name old allocs/op new allocs/op delta Template 363k ± 0% 359k ± 0% -1.21% (p=0.008 n=5+5) Unicode 329k ± 0% 326k ± 0% -0.90% (p=0.008 n=5+5) GoTypes 1.28M ± 0% 1.25M ± 0% -2.62% (p=0.008 n=5+5) Compiler 5.39M ± 0% 5.31M ± 0% -1.45% (p=0.008 n=5+5) SSA 18.1M ± 0% 17.9M ± 0% -0.78% (p=0.008 n=5+5) Flate 228k ± 0% 226k ± 0% -0.97% (p=0.008 n=5+5) GoParser 295k ± 0% 288k ± 0% -2.26% (p=0.008 n=5+5) Reflect 949k ± 0% 932k ± 0% -1.74% (p=0.008 n=5+5) Tar 336k ± 0% 332k ± 0% -1.12% (p=0.008 n=5+5) XML 417k ± 0% 413k ± 0% -1.10% (p=0.008 n=5+5) [Geo mean] 818k 806k -1.42% Change-Id: Ibdb94650a761edec17d8eba0abdfb70a8a495da9 Reviewed-on: https://go-review.googlesource.com/c/go/+/222920 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2020-01-14 16:37:42 -08:00
// (methodsym), typesym, weaksym
b.WriteString(s.Pkg.Prefix)
b.WriteByte('.')
b.WriteString(s.Name)
return
}
}
if flag&FmtByte != 0 {
// FmtByte (hh) implies FmtShort (h)
// skip leading "type." in method name
name := s.Name
if i := strings.LastIndex(name, "."); i >= 0 {
name = name[i+1:]
}
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
if mode == FDbg {
cmd/compile: use a bytes.Buffer to format symbols No significant compiler speed changes, but some minor memory savings. Passes toolstash-check. name old alloc/op new alloc/op delta Template 36.3MB ± 0% 36.2MB ± 0% -0.25% (p=0.008 n=5+5) Unicode 28.3MB ± 0% 28.2MB ± 0% -0.16% (p=0.008 n=5+5) GoTypes 122MB ± 0% 121MB ± 0% -0.39% (p=0.008 n=5+5) Compiler 568MB ± 0% 566MB ± 0% -0.21% (p=0.008 n=5+5) SSA 1.95GB ± 0% 1.95GB ± 0% -0.08% (p=0.008 n=5+5) Flate 22.8MB ± 0% 22.8MB ± 0% -0.21% (p=0.008 n=5+5) GoParser 28.0MB ± 0% 27.9MB ± 0% -0.38% (p=0.008 n=5+5) Reflect 78.6MB ± 0% 78.3MB ± 0% -0.33% (p=0.008 n=5+5) Tar 34.1MB ± 0% 34.1MB ± 0% -0.19% (p=0.008 n=5+5) XML 44.3MB ± 0% 44.2MB ± 0% -0.19% (p=0.008 n=5+5) [Geo mean] 79.9MB 79.7MB -0.24% name old allocs/op new allocs/op delta Template 363k ± 0% 359k ± 0% -1.21% (p=0.008 n=5+5) Unicode 329k ± 0% 326k ± 0% -0.90% (p=0.008 n=5+5) GoTypes 1.28M ± 0% 1.25M ± 0% -2.62% (p=0.008 n=5+5) Compiler 5.39M ± 0% 5.31M ± 0% -1.45% (p=0.008 n=5+5) SSA 18.1M ± 0% 17.9M ± 0% -0.78% (p=0.008 n=5+5) Flate 228k ± 0% 226k ± 0% -0.97% (p=0.008 n=5+5) GoParser 295k ± 0% 288k ± 0% -2.26% (p=0.008 n=5+5) Reflect 949k ± 0% 932k ± 0% -1.74% (p=0.008 n=5+5) Tar 336k ± 0% 332k ± 0% -1.12% (p=0.008 n=5+5) XML 417k ± 0% 413k ± 0% -1.10% (p=0.008 n=5+5) [Geo mean] 818k 806k -1.42% Change-Id: Ibdb94650a761edec17d8eba0abdfb70a8a495da9 Reviewed-on: https://go-review.googlesource.com/c/go/+/222920 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2020-01-14 16:37:42 -08:00
fmt.Fprintf(b, "@%q.%s", s.Pkg.Path, name)
return
}
cmd/compile: use a bytes.Buffer to format symbols No significant compiler speed changes, but some minor memory savings. Passes toolstash-check. name old alloc/op new alloc/op delta Template 36.3MB ± 0% 36.2MB ± 0% -0.25% (p=0.008 n=5+5) Unicode 28.3MB ± 0% 28.2MB ± 0% -0.16% (p=0.008 n=5+5) GoTypes 122MB ± 0% 121MB ± 0% -0.39% (p=0.008 n=5+5) Compiler 568MB ± 0% 566MB ± 0% -0.21% (p=0.008 n=5+5) SSA 1.95GB ± 0% 1.95GB ± 0% -0.08% (p=0.008 n=5+5) Flate 22.8MB ± 0% 22.8MB ± 0% -0.21% (p=0.008 n=5+5) GoParser 28.0MB ± 0% 27.9MB ± 0% -0.38% (p=0.008 n=5+5) Reflect 78.6MB ± 0% 78.3MB ± 0% -0.33% (p=0.008 n=5+5) Tar 34.1MB ± 0% 34.1MB ± 0% -0.19% (p=0.008 n=5+5) XML 44.3MB ± 0% 44.2MB ± 0% -0.19% (p=0.008 n=5+5) [Geo mean] 79.9MB 79.7MB -0.24% name old allocs/op new allocs/op delta Template 363k ± 0% 359k ± 0% -1.21% (p=0.008 n=5+5) Unicode 329k ± 0% 326k ± 0% -0.90% (p=0.008 n=5+5) GoTypes 1.28M ± 0% 1.25M ± 0% -2.62% (p=0.008 n=5+5) Compiler 5.39M ± 0% 5.31M ± 0% -1.45% (p=0.008 n=5+5) SSA 18.1M ± 0% 17.9M ± 0% -0.78% (p=0.008 n=5+5) Flate 228k ± 0% 226k ± 0% -0.97% (p=0.008 n=5+5) GoParser 295k ± 0% 288k ± 0% -2.26% (p=0.008 n=5+5) Reflect 949k ± 0% 932k ± 0% -1.74% (p=0.008 n=5+5) Tar 336k ± 0% 332k ± 0% -1.12% (p=0.008 n=5+5) XML 417k ± 0% 413k ± 0% -1.10% (p=0.008 n=5+5) [Geo mean] 818k 806k -1.42% Change-Id: Ibdb94650a761edec17d8eba0abdfb70a8a495da9 Reviewed-on: https://go-review.googlesource.com/c/go/+/222920 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2020-01-14 16:37:42 -08:00
b.WriteString(name)
return
}
cmd/compile: use a bytes.Buffer to format symbols No significant compiler speed changes, but some minor memory savings. Passes toolstash-check. name old alloc/op new alloc/op delta Template 36.3MB ± 0% 36.2MB ± 0% -0.25% (p=0.008 n=5+5) Unicode 28.3MB ± 0% 28.2MB ± 0% -0.16% (p=0.008 n=5+5) GoTypes 122MB ± 0% 121MB ± 0% -0.39% (p=0.008 n=5+5) Compiler 568MB ± 0% 566MB ± 0% -0.21% (p=0.008 n=5+5) SSA 1.95GB ± 0% 1.95GB ± 0% -0.08% (p=0.008 n=5+5) Flate 22.8MB ± 0% 22.8MB ± 0% -0.21% (p=0.008 n=5+5) GoParser 28.0MB ± 0% 27.9MB ± 0% -0.38% (p=0.008 n=5+5) Reflect 78.6MB ± 0% 78.3MB ± 0% -0.33% (p=0.008 n=5+5) Tar 34.1MB ± 0% 34.1MB ± 0% -0.19% (p=0.008 n=5+5) XML 44.3MB ± 0% 44.2MB ± 0% -0.19% (p=0.008 n=5+5) [Geo mean] 79.9MB 79.7MB -0.24% name old allocs/op new allocs/op delta Template 363k ± 0% 359k ± 0% -1.21% (p=0.008 n=5+5) Unicode 329k ± 0% 326k ± 0% -0.90% (p=0.008 n=5+5) GoTypes 1.28M ± 0% 1.25M ± 0% -2.62% (p=0.008 n=5+5) Compiler 5.39M ± 0% 5.31M ± 0% -1.45% (p=0.008 n=5+5) SSA 18.1M ± 0% 17.9M ± 0% -0.78% (p=0.008 n=5+5) Flate 228k ± 0% 226k ± 0% -0.97% (p=0.008 n=5+5) GoParser 295k ± 0% 288k ± 0% -2.26% (p=0.008 n=5+5) Reflect 949k ± 0% 932k ± 0% -1.74% (p=0.008 n=5+5) Tar 336k ± 0% 332k ± 0% -1.12% (p=0.008 n=5+5) XML 417k ± 0% 413k ± 0% -1.10% (p=0.008 n=5+5) [Geo mean] 818k 806k -1.42% Change-Id: Ibdb94650a761edec17d8eba0abdfb70a8a495da9 Reviewed-on: https://go-review.googlesource.com/c/go/+/222920 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2020-01-14 16:37:42 -08:00
b.WriteString(s.Name)
}
var basicnames = []string{
TINT: "int",
TUINT: "uint",
TINT8: "int8",
TUINT8: "uint8",
TINT16: "int16",
TUINT16: "uint16",
TINT32: "int32",
TUINT32: "uint32",
TINT64: "int64",
TUINT64: "uint64",
TUINTPTR: "uintptr",
TFLOAT32: "float32",
TFLOAT64: "float64",
TCOMPLEX64: "complex64",
TCOMPLEX128: "complex128",
TBOOL: "bool",
TANY: "any",
TSTRING: "string",
TNIL: "nil",
TIDEAL: "untyped number",
TBLANK: "blank",
}
cmd/compile: use a bytes.Buffer to format symbols No significant compiler speed changes, but some minor memory savings. Passes toolstash-check. name old alloc/op new alloc/op delta Template 36.3MB ± 0% 36.2MB ± 0% -0.25% (p=0.008 n=5+5) Unicode 28.3MB ± 0% 28.2MB ± 0% -0.16% (p=0.008 n=5+5) GoTypes 122MB ± 0% 121MB ± 0% -0.39% (p=0.008 n=5+5) Compiler 568MB ± 0% 566MB ± 0% -0.21% (p=0.008 n=5+5) SSA 1.95GB ± 0% 1.95GB ± 0% -0.08% (p=0.008 n=5+5) Flate 22.8MB ± 0% 22.8MB ± 0% -0.21% (p=0.008 n=5+5) GoParser 28.0MB ± 0% 27.9MB ± 0% -0.38% (p=0.008 n=5+5) Reflect 78.6MB ± 0% 78.3MB ± 0% -0.33% (p=0.008 n=5+5) Tar 34.1MB ± 0% 34.1MB ± 0% -0.19% (p=0.008 n=5+5) XML 44.3MB ± 0% 44.2MB ± 0% -0.19% (p=0.008 n=5+5) [Geo mean] 79.9MB 79.7MB -0.24% name old allocs/op new allocs/op delta Template 363k ± 0% 359k ± 0% -1.21% (p=0.008 n=5+5) Unicode 329k ± 0% 326k ± 0% -0.90% (p=0.008 n=5+5) GoTypes 1.28M ± 0% 1.25M ± 0% -2.62% (p=0.008 n=5+5) Compiler 5.39M ± 0% 5.31M ± 0% -1.45% (p=0.008 n=5+5) SSA 18.1M ± 0% 17.9M ± 0% -0.78% (p=0.008 n=5+5) Flate 228k ± 0% 226k ± 0% -0.97% (p=0.008 n=5+5) GoParser 295k ± 0% 288k ± 0% -2.26% (p=0.008 n=5+5) Reflect 949k ± 0% 932k ± 0% -1.74% (p=0.008 n=5+5) Tar 336k ± 0% 332k ± 0% -1.12% (p=0.008 n=5+5) XML 417k ± 0% 413k ± 0% -1.10% (p=0.008 n=5+5) [Geo mean] 818k 806k -1.42% Change-Id: Ibdb94650a761edec17d8eba0abdfb70a8a495da9 Reviewed-on: https://go-review.googlesource.com/c/go/+/222920 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2020-01-14 16:37:42 -08:00
var fmtBufferPool = sync.Pool{
cmd/compile: use a sync.Pool and string interning when printing types CL 214239 improved type printing, but introduced performance regressions: 3-5% memory increase, 1-2% CPU time increase. There were two primary sources of the memory regression: * allocating a bytes.Buffer for every type to print * always printing to that buffer, even when we could return a constant string This change addresses both of those regressions. The sync.Pool allows buffer re-use. String interning prevents allocation for re-used strings. It addresses some, but not all, of the CPU time regression. Memory performance impact vs master: name old alloc/op new alloc/op delta Template 37.6MB ± 0% 36.3MB ± 0% -3.30% (p=0.008 n=5+5) Unicode 28.7MB ± 0% 28.3MB ± 0% -1.55% (p=0.008 n=5+5) GoTypes 127MB ± 0% 122MB ± 0% -4.38% (p=0.008 n=5+5) Compiler 584MB ± 0% 568MB ± 0% -2.72% (p=0.008 n=5+5) SSA 1.99GB ± 0% 1.95GB ± 0% -1.97% (p=0.008 n=5+5) Flate 23.5MB ± 0% 22.8MB ± 0% -2.84% (p=0.008 n=5+5) GoParser 29.2MB ± 0% 28.0MB ± 0% -4.17% (p=0.008 n=5+5) Reflect 81.9MB ± 0% 78.6MB ± 0% -4.09% (p=0.008 n=5+5) Tar 35.3MB ± 0% 34.1MB ± 0% -3.29% (p=0.008 n=5+5) XML 45.5MB ± 0% 44.3MB ± 0% -2.61% (p=0.008 n=5+5) [Geo mean] 82.4MB 79.9MB -3.09% name old allocs/op new allocs/op delta Template 394k ± 0% 363k ± 0% -7.73% (p=0.008 n=5+5) Unicode 340k ± 0% 329k ± 0% -3.25% (p=0.008 n=5+5) GoTypes 1.41M ± 0% 1.28M ± 0% -9.54% (p=0.008 n=5+5) Compiler 5.77M ± 0% 5.39M ± 0% -6.58% (p=0.008 n=5+5) SSA 19.1M ± 0% 18.1M ± 0% -5.13% (p=0.008 n=5+5) Flate 247k ± 0% 228k ± 0% -7.50% (p=0.008 n=5+5) GoParser 325k ± 0% 295k ± 0% -9.24% (p=0.008 n=5+5) Reflect 1.04M ± 0% 0.95M ± 0% -8.48% (p=0.008 n=5+5) Tar 365k ± 0% 336k ± 0% -7.93% (p=0.008 n=5+5) XML 449k ± 0% 417k ± 0% -7.10% (p=0.008 n=5+5) [Geo mean] 882k 818k -7.26% Memory performance going from 52c4488471ed52085a29e173226b3cbd2bf22b20, which is the commit preceding CL 214239, to this change: name old alloc/op new alloc/op delta Template 36.5MB ± 0% 36.3MB ± 0% -0.37% (p=0.008 n=5+5) Unicode 28.3MB ± 0% 28.3MB ± 0% -0.06% (p=0.008 n=5+5) GoTypes 123MB ± 0% 122MB ± 0% -0.64% (p=0.008 n=5+5) Compiler 571MB ± 0% 568MB ± 0% -0.51% (p=0.008 n=5+5) SSA 1.96GB ± 0% 1.95GB ± 0% -0.13% (p=0.008 n=5+5) Flate 22.8MB ± 0% 22.8MB ± 0% ~ (p=0.421 n=5+5) GoParser 28.1MB ± 0% 28.0MB ± 0% -0.37% (p=0.008 n=5+5) Reflect 78.8MB ± 0% 78.6MB ± 0% -0.32% (p=0.008 n=5+5) Tar 34.3MB ± 0% 34.1MB ± 0% -0.35% (p=0.008 n=5+5) XML 44.3MB ± 0% 44.3MB ± 0% +0.05% (p=0.032 n=5+5) [Geo mean] 80.1MB 79.9MB -0.27% name old allocs/op new allocs/op delta Template 372k ± 0% 363k ± 0% -2.46% (p=0.008 n=5+5) Unicode 333k ± 0% 329k ± 0% -0.97% (p=0.008 n=5+5) GoTypes 1.33M ± 0% 1.28M ± 0% -3.71% (p=0.008 n=5+5) Compiler 5.53M ± 0% 5.39M ± 0% -2.50% (p=0.008 n=5+5) SSA 18.3M ± 0% 18.1M ± 0% -1.22% (p=0.008 n=5+5) Flate 234k ± 0% 228k ± 0% -2.44% (p=0.008 n=5+5) GoParser 305k ± 0% 295k ± 0% -3.23% (p=0.008 n=5+5) Reflect 980k ± 0% 949k ± 0% -3.12% (p=0.008 n=5+5) Tar 345k ± 0% 336k ± 0% -2.69% (p=0.008 n=5+5) XML 425k ± 0% 417k ± 0% -1.72% (p=0.008 n=5+5) [Geo mean] 838k 818k -2.41% Remaining CPU time regression, that is, the change from before CL 214239 to this change: name old time/op new time/op delta Template 208ms ± 2% 209ms ± 1% ~ (p=0.181 n=47+46) Unicode 82.9ms ± 2% 81.9ms ± 2% -1.25% (p=0.000 n=50+48) GoTypes 709ms ± 3% 714ms ± 3% +0.77% (p=0.003 n=48+49) Compiler 3.31s ± 2% 3.32s ± 2% ~ (p=0.271 n=48+48) SSA 10.8s ± 1% 10.9s ± 1% +0.61% (p=0.000 n=46+47) Flate 134ms ± 2% 134ms ± 1% +0.41% (p=0.002 n=48+46) GoParser 166ms ± 2% 167ms ± 2% +0.41% (p=0.010 n=46+48) Reflect 440ms ± 4% 444ms ± 4% +1.05% (p=0.002 n=50+49) Tar 183ms ± 2% 184ms ± 2% ~ (p=0.074 n=45+45) XML 247ms ± 2% 248ms ± 2% +0.67% (p=0.001 n=49+48) [Geo mean] 425ms 427ms +0.34% name old user-time/op new user-time/op delta Template 271ms ± 2% 271ms ± 2% ~ (p=0.654 n=48+48) Unicode 117ms ± 2% 116ms ± 3% ~ (p=0.458 n=47+45) GoTypes 952ms ± 3% 963ms ± 2% +1.11% (p=0.000 n=48+49) Compiler 4.50s ± 5% 4.49s ± 7% ~ (p=0.894 n=50+50) SSA 15.0s ± 2% 15.1s ± 2% +0.46% (p=0.015 n=50+49) Flate 166ms ± 2% 167ms ± 2% +0.40% (p=0.005 n=49+48) GoParser 202ms ± 2% 203ms ± 2% +0.60% (p=0.002 n=49+47) Reflect 583ms ± 3% 588ms ± 3% +0.82% (p=0.001 n=49+46) Tar 223ms ± 2% 224ms ± 2% +0.37% (p=0.046 n=48+46) XML 310ms ± 2% 311ms ± 2% +0.46% (p=0.009 n=50+49) [Geo mean] 554ms 556ms +0.36% Change-Id: I85951a6538373ef4309a2cc366cc1ebaf1f4582d Reviewed-on: https://go-review.googlesource.com/c/go/+/214818 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2020-01-14 05:08:47 -08:00
New: func() interface{} {
return new(bytes.Buffer)
},
}
func tconv(t *types.Type, flag FmtFlag, mode fmtMode) string {
cmd/compile: use a bytes.Buffer to format symbols No significant compiler speed changes, but some minor memory savings. Passes toolstash-check. name old alloc/op new alloc/op delta Template 36.3MB ± 0% 36.2MB ± 0% -0.25% (p=0.008 n=5+5) Unicode 28.3MB ± 0% 28.2MB ± 0% -0.16% (p=0.008 n=5+5) GoTypes 122MB ± 0% 121MB ± 0% -0.39% (p=0.008 n=5+5) Compiler 568MB ± 0% 566MB ± 0% -0.21% (p=0.008 n=5+5) SSA 1.95GB ± 0% 1.95GB ± 0% -0.08% (p=0.008 n=5+5) Flate 22.8MB ± 0% 22.8MB ± 0% -0.21% (p=0.008 n=5+5) GoParser 28.0MB ± 0% 27.9MB ± 0% -0.38% (p=0.008 n=5+5) Reflect 78.6MB ± 0% 78.3MB ± 0% -0.33% (p=0.008 n=5+5) Tar 34.1MB ± 0% 34.1MB ± 0% -0.19% (p=0.008 n=5+5) XML 44.3MB ± 0% 44.2MB ± 0% -0.19% (p=0.008 n=5+5) [Geo mean] 79.9MB 79.7MB -0.24% name old allocs/op new allocs/op delta Template 363k ± 0% 359k ± 0% -1.21% (p=0.008 n=5+5) Unicode 329k ± 0% 326k ± 0% -0.90% (p=0.008 n=5+5) GoTypes 1.28M ± 0% 1.25M ± 0% -2.62% (p=0.008 n=5+5) Compiler 5.39M ± 0% 5.31M ± 0% -1.45% (p=0.008 n=5+5) SSA 18.1M ± 0% 17.9M ± 0% -0.78% (p=0.008 n=5+5) Flate 228k ± 0% 226k ± 0% -0.97% (p=0.008 n=5+5) GoParser 295k ± 0% 288k ± 0% -2.26% (p=0.008 n=5+5) Reflect 949k ± 0% 932k ± 0% -1.74% (p=0.008 n=5+5) Tar 336k ± 0% 332k ± 0% -1.12% (p=0.008 n=5+5) XML 417k ± 0% 413k ± 0% -1.10% (p=0.008 n=5+5) [Geo mean] 818k 806k -1.42% Change-Id: Ibdb94650a761edec17d8eba0abdfb70a8a495da9 Reviewed-on: https://go-review.googlesource.com/c/go/+/222920 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2020-01-14 16:37:42 -08:00
buf := fmtBufferPool.Get().(*bytes.Buffer)
cmd/compile: use a sync.Pool and string interning when printing types CL 214239 improved type printing, but introduced performance regressions: 3-5% memory increase, 1-2% CPU time increase. There were two primary sources of the memory regression: * allocating a bytes.Buffer for every type to print * always printing to that buffer, even when we could return a constant string This change addresses both of those regressions. The sync.Pool allows buffer re-use. String interning prevents allocation for re-used strings. It addresses some, but not all, of the CPU time regression. Memory performance impact vs master: name old alloc/op new alloc/op delta Template 37.6MB ± 0% 36.3MB ± 0% -3.30% (p=0.008 n=5+5) Unicode 28.7MB ± 0% 28.3MB ± 0% -1.55% (p=0.008 n=5+5) GoTypes 127MB ± 0% 122MB ± 0% -4.38% (p=0.008 n=5+5) Compiler 584MB ± 0% 568MB ± 0% -2.72% (p=0.008 n=5+5) SSA 1.99GB ± 0% 1.95GB ± 0% -1.97% (p=0.008 n=5+5) Flate 23.5MB ± 0% 22.8MB ± 0% -2.84% (p=0.008 n=5+5) GoParser 29.2MB ± 0% 28.0MB ± 0% -4.17% (p=0.008 n=5+5) Reflect 81.9MB ± 0% 78.6MB ± 0% -4.09% (p=0.008 n=5+5) Tar 35.3MB ± 0% 34.1MB ± 0% -3.29% (p=0.008 n=5+5) XML 45.5MB ± 0% 44.3MB ± 0% -2.61% (p=0.008 n=5+5) [Geo mean] 82.4MB 79.9MB -3.09% name old allocs/op new allocs/op delta Template 394k ± 0% 363k ± 0% -7.73% (p=0.008 n=5+5) Unicode 340k ± 0% 329k ± 0% -3.25% (p=0.008 n=5+5) GoTypes 1.41M ± 0% 1.28M ± 0% -9.54% (p=0.008 n=5+5) Compiler 5.77M ± 0% 5.39M ± 0% -6.58% (p=0.008 n=5+5) SSA 19.1M ± 0% 18.1M ± 0% -5.13% (p=0.008 n=5+5) Flate 247k ± 0% 228k ± 0% -7.50% (p=0.008 n=5+5) GoParser 325k ± 0% 295k ± 0% -9.24% (p=0.008 n=5+5) Reflect 1.04M ± 0% 0.95M ± 0% -8.48% (p=0.008 n=5+5) Tar 365k ± 0% 336k ± 0% -7.93% (p=0.008 n=5+5) XML 449k ± 0% 417k ± 0% -7.10% (p=0.008 n=5+5) [Geo mean] 882k 818k -7.26% Memory performance going from 52c4488471ed52085a29e173226b3cbd2bf22b20, which is the commit preceding CL 214239, to this change: name old alloc/op new alloc/op delta Template 36.5MB ± 0% 36.3MB ± 0% -0.37% (p=0.008 n=5+5) Unicode 28.3MB ± 0% 28.3MB ± 0% -0.06% (p=0.008 n=5+5) GoTypes 123MB ± 0% 122MB ± 0% -0.64% (p=0.008 n=5+5) Compiler 571MB ± 0% 568MB ± 0% -0.51% (p=0.008 n=5+5) SSA 1.96GB ± 0% 1.95GB ± 0% -0.13% (p=0.008 n=5+5) Flate 22.8MB ± 0% 22.8MB ± 0% ~ (p=0.421 n=5+5) GoParser 28.1MB ± 0% 28.0MB ± 0% -0.37% (p=0.008 n=5+5) Reflect 78.8MB ± 0% 78.6MB ± 0% -0.32% (p=0.008 n=5+5) Tar 34.3MB ± 0% 34.1MB ± 0% -0.35% (p=0.008 n=5+5) XML 44.3MB ± 0% 44.3MB ± 0% +0.05% (p=0.032 n=5+5) [Geo mean] 80.1MB 79.9MB -0.27% name old allocs/op new allocs/op delta Template 372k ± 0% 363k ± 0% -2.46% (p=0.008 n=5+5) Unicode 333k ± 0% 329k ± 0% -0.97% (p=0.008 n=5+5) GoTypes 1.33M ± 0% 1.28M ± 0% -3.71% (p=0.008 n=5+5) Compiler 5.53M ± 0% 5.39M ± 0% -2.50% (p=0.008 n=5+5) SSA 18.3M ± 0% 18.1M ± 0% -1.22% (p=0.008 n=5+5) Flate 234k ± 0% 228k ± 0% -2.44% (p=0.008 n=5+5) GoParser 305k ± 0% 295k ± 0% -3.23% (p=0.008 n=5+5) Reflect 980k ± 0% 949k ± 0% -3.12% (p=0.008 n=5+5) Tar 345k ± 0% 336k ± 0% -2.69% (p=0.008 n=5+5) XML 425k ± 0% 417k ± 0% -1.72% (p=0.008 n=5+5) [Geo mean] 838k 818k -2.41% Remaining CPU time regression, that is, the change from before CL 214239 to this change: name old time/op new time/op delta Template 208ms ± 2% 209ms ± 1% ~ (p=0.181 n=47+46) Unicode 82.9ms ± 2% 81.9ms ± 2% -1.25% (p=0.000 n=50+48) GoTypes 709ms ± 3% 714ms ± 3% +0.77% (p=0.003 n=48+49) Compiler 3.31s ± 2% 3.32s ± 2% ~ (p=0.271 n=48+48) SSA 10.8s ± 1% 10.9s ± 1% +0.61% (p=0.000 n=46+47) Flate 134ms ± 2% 134ms ± 1% +0.41% (p=0.002 n=48+46) GoParser 166ms ± 2% 167ms ± 2% +0.41% (p=0.010 n=46+48) Reflect 440ms ± 4% 444ms ± 4% +1.05% (p=0.002 n=50+49) Tar 183ms ± 2% 184ms ± 2% ~ (p=0.074 n=45+45) XML 247ms ± 2% 248ms ± 2% +0.67% (p=0.001 n=49+48) [Geo mean] 425ms 427ms +0.34% name old user-time/op new user-time/op delta Template 271ms ± 2% 271ms ± 2% ~ (p=0.654 n=48+48) Unicode 117ms ± 2% 116ms ± 3% ~ (p=0.458 n=47+45) GoTypes 952ms ± 3% 963ms ± 2% +1.11% (p=0.000 n=48+49) Compiler 4.50s ± 5% 4.49s ± 7% ~ (p=0.894 n=50+50) SSA 15.0s ± 2% 15.1s ± 2% +0.46% (p=0.015 n=50+49) Flate 166ms ± 2% 167ms ± 2% +0.40% (p=0.005 n=49+48) GoParser 202ms ± 2% 203ms ± 2% +0.60% (p=0.002 n=49+47) Reflect 583ms ± 3% 588ms ± 3% +0.82% (p=0.001 n=49+46) Tar 223ms ± 2% 224ms ± 2% +0.37% (p=0.046 n=48+46) XML 310ms ± 2% 311ms ± 2% +0.46% (p=0.009 n=50+49) [Geo mean] 554ms 556ms +0.36% Change-Id: I85951a6538373ef4309a2cc366cc1ebaf1f4582d Reviewed-on: https://go-review.googlesource.com/c/go/+/214818 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2020-01-14 05:08:47 -08:00
buf.Reset()
cmd/compile: use a bytes.Buffer to format symbols No significant compiler speed changes, but some minor memory savings. Passes toolstash-check. name old alloc/op new alloc/op delta Template 36.3MB ± 0% 36.2MB ± 0% -0.25% (p=0.008 n=5+5) Unicode 28.3MB ± 0% 28.2MB ± 0% -0.16% (p=0.008 n=5+5) GoTypes 122MB ± 0% 121MB ± 0% -0.39% (p=0.008 n=5+5) Compiler 568MB ± 0% 566MB ± 0% -0.21% (p=0.008 n=5+5) SSA 1.95GB ± 0% 1.95GB ± 0% -0.08% (p=0.008 n=5+5) Flate 22.8MB ± 0% 22.8MB ± 0% -0.21% (p=0.008 n=5+5) GoParser 28.0MB ± 0% 27.9MB ± 0% -0.38% (p=0.008 n=5+5) Reflect 78.6MB ± 0% 78.3MB ± 0% -0.33% (p=0.008 n=5+5) Tar 34.1MB ± 0% 34.1MB ± 0% -0.19% (p=0.008 n=5+5) XML 44.3MB ± 0% 44.2MB ± 0% -0.19% (p=0.008 n=5+5) [Geo mean] 79.9MB 79.7MB -0.24% name old allocs/op new allocs/op delta Template 363k ± 0% 359k ± 0% -1.21% (p=0.008 n=5+5) Unicode 329k ± 0% 326k ± 0% -0.90% (p=0.008 n=5+5) GoTypes 1.28M ± 0% 1.25M ± 0% -2.62% (p=0.008 n=5+5) Compiler 5.39M ± 0% 5.31M ± 0% -1.45% (p=0.008 n=5+5) SSA 18.1M ± 0% 17.9M ± 0% -0.78% (p=0.008 n=5+5) Flate 228k ± 0% 226k ± 0% -0.97% (p=0.008 n=5+5) GoParser 295k ± 0% 288k ± 0% -2.26% (p=0.008 n=5+5) Reflect 949k ± 0% 932k ± 0% -1.74% (p=0.008 n=5+5) Tar 336k ± 0% 332k ± 0% -1.12% (p=0.008 n=5+5) XML 417k ± 0% 413k ± 0% -1.10% (p=0.008 n=5+5) [Geo mean] 818k 806k -1.42% Change-Id: Ibdb94650a761edec17d8eba0abdfb70a8a495da9 Reviewed-on: https://go-review.googlesource.com/c/go/+/222920 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2020-01-14 16:37:42 -08:00
defer fmtBufferPool.Put(buf)
cmd/compile: use a sync.Pool and string interning when printing types CL 214239 improved type printing, but introduced performance regressions: 3-5% memory increase, 1-2% CPU time increase. There were two primary sources of the memory regression: * allocating a bytes.Buffer for every type to print * always printing to that buffer, even when we could return a constant string This change addresses both of those regressions. The sync.Pool allows buffer re-use. String interning prevents allocation for re-used strings. It addresses some, but not all, of the CPU time regression. Memory performance impact vs master: name old alloc/op new alloc/op delta Template 37.6MB ± 0% 36.3MB ± 0% -3.30% (p=0.008 n=5+5) Unicode 28.7MB ± 0% 28.3MB ± 0% -1.55% (p=0.008 n=5+5) GoTypes 127MB ± 0% 122MB ± 0% -4.38% (p=0.008 n=5+5) Compiler 584MB ± 0% 568MB ± 0% -2.72% (p=0.008 n=5+5) SSA 1.99GB ± 0% 1.95GB ± 0% -1.97% (p=0.008 n=5+5) Flate 23.5MB ± 0% 22.8MB ± 0% -2.84% (p=0.008 n=5+5) GoParser 29.2MB ± 0% 28.0MB ± 0% -4.17% (p=0.008 n=5+5) Reflect 81.9MB ± 0% 78.6MB ± 0% -4.09% (p=0.008 n=5+5) Tar 35.3MB ± 0% 34.1MB ± 0% -3.29% (p=0.008 n=5+5) XML 45.5MB ± 0% 44.3MB ± 0% -2.61% (p=0.008 n=5+5) [Geo mean] 82.4MB 79.9MB -3.09% name old allocs/op new allocs/op delta Template 394k ± 0% 363k ± 0% -7.73% (p=0.008 n=5+5) Unicode 340k ± 0% 329k ± 0% -3.25% (p=0.008 n=5+5) GoTypes 1.41M ± 0% 1.28M ± 0% -9.54% (p=0.008 n=5+5) Compiler 5.77M ± 0% 5.39M ± 0% -6.58% (p=0.008 n=5+5) SSA 19.1M ± 0% 18.1M ± 0% -5.13% (p=0.008 n=5+5) Flate 247k ± 0% 228k ± 0% -7.50% (p=0.008 n=5+5) GoParser 325k ± 0% 295k ± 0% -9.24% (p=0.008 n=5+5) Reflect 1.04M ± 0% 0.95M ± 0% -8.48% (p=0.008 n=5+5) Tar 365k ± 0% 336k ± 0% -7.93% (p=0.008 n=5+5) XML 449k ± 0% 417k ± 0% -7.10% (p=0.008 n=5+5) [Geo mean] 882k 818k -7.26% Memory performance going from 52c4488471ed52085a29e173226b3cbd2bf22b20, which is the commit preceding CL 214239, to this change: name old alloc/op new alloc/op delta Template 36.5MB ± 0% 36.3MB ± 0% -0.37% (p=0.008 n=5+5) Unicode 28.3MB ± 0% 28.3MB ± 0% -0.06% (p=0.008 n=5+5) GoTypes 123MB ± 0% 122MB ± 0% -0.64% (p=0.008 n=5+5) Compiler 571MB ± 0% 568MB ± 0% -0.51% (p=0.008 n=5+5) SSA 1.96GB ± 0% 1.95GB ± 0% -0.13% (p=0.008 n=5+5) Flate 22.8MB ± 0% 22.8MB ± 0% ~ (p=0.421 n=5+5) GoParser 28.1MB ± 0% 28.0MB ± 0% -0.37% (p=0.008 n=5+5) Reflect 78.8MB ± 0% 78.6MB ± 0% -0.32% (p=0.008 n=5+5) Tar 34.3MB ± 0% 34.1MB ± 0% -0.35% (p=0.008 n=5+5) XML 44.3MB ± 0% 44.3MB ± 0% +0.05% (p=0.032 n=5+5) [Geo mean] 80.1MB 79.9MB -0.27% name old allocs/op new allocs/op delta Template 372k ± 0% 363k ± 0% -2.46% (p=0.008 n=5+5) Unicode 333k ± 0% 329k ± 0% -0.97% (p=0.008 n=5+5) GoTypes 1.33M ± 0% 1.28M ± 0% -3.71% (p=0.008 n=5+5) Compiler 5.53M ± 0% 5.39M ± 0% -2.50% (p=0.008 n=5+5) SSA 18.3M ± 0% 18.1M ± 0% -1.22% (p=0.008 n=5+5) Flate 234k ± 0% 228k ± 0% -2.44% (p=0.008 n=5+5) GoParser 305k ± 0% 295k ± 0% -3.23% (p=0.008 n=5+5) Reflect 980k ± 0% 949k ± 0% -3.12% (p=0.008 n=5+5) Tar 345k ± 0% 336k ± 0% -2.69% (p=0.008 n=5+5) XML 425k ± 0% 417k ± 0% -1.72% (p=0.008 n=5+5) [Geo mean] 838k 818k -2.41% Remaining CPU time regression, that is, the change from before CL 214239 to this change: name old time/op new time/op delta Template 208ms ± 2% 209ms ± 1% ~ (p=0.181 n=47+46) Unicode 82.9ms ± 2% 81.9ms ± 2% -1.25% (p=0.000 n=50+48) GoTypes 709ms ± 3% 714ms ± 3% +0.77% (p=0.003 n=48+49) Compiler 3.31s ± 2% 3.32s ± 2% ~ (p=0.271 n=48+48) SSA 10.8s ± 1% 10.9s ± 1% +0.61% (p=0.000 n=46+47) Flate 134ms ± 2% 134ms ± 1% +0.41% (p=0.002 n=48+46) GoParser 166ms ± 2% 167ms ± 2% +0.41% (p=0.010 n=46+48) Reflect 440ms ± 4% 444ms ± 4% +1.05% (p=0.002 n=50+49) Tar 183ms ± 2% 184ms ± 2% ~ (p=0.074 n=45+45) XML 247ms ± 2% 248ms ± 2% +0.67% (p=0.001 n=49+48) [Geo mean] 425ms 427ms +0.34% name old user-time/op new user-time/op delta Template 271ms ± 2% 271ms ± 2% ~ (p=0.654 n=48+48) Unicode 117ms ± 2% 116ms ± 3% ~ (p=0.458 n=47+45) GoTypes 952ms ± 3% 963ms ± 2% +1.11% (p=0.000 n=48+49) Compiler 4.50s ± 5% 4.49s ± 7% ~ (p=0.894 n=50+50) SSA 15.0s ± 2% 15.1s ± 2% +0.46% (p=0.015 n=50+49) Flate 166ms ± 2% 167ms ± 2% +0.40% (p=0.005 n=49+48) GoParser 202ms ± 2% 203ms ± 2% +0.60% (p=0.002 n=49+47) Reflect 583ms ± 3% 588ms ± 3% +0.82% (p=0.001 n=49+46) Tar 223ms ± 2% 224ms ± 2% +0.37% (p=0.046 n=48+46) XML 310ms ± 2% 311ms ± 2% +0.46% (p=0.009 n=50+49) [Geo mean] 554ms 556ms +0.36% Change-Id: I85951a6538373ef4309a2cc366cc1ebaf1f4582d Reviewed-on: https://go-review.googlesource.com/c/go/+/214818 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2020-01-14 05:08:47 -08:00
tconv2(buf, t, flag, mode, nil)
return types.InternString(buf.Bytes())
}
// tconv2 writes a string representation of t to b.
// flag and mode control exactly what is printed.
// Any types x that are already in the visited map get printed as @%d where %d=visited[x].
// See #16897 before changing the implementation of tconv.
func tconv2(b *bytes.Buffer, t *types.Type, flag FmtFlag, mode fmtMode, visited map[*types.Type]int) {
if off, ok := visited[t]; ok {
// We've seen this type before, so we're trying to print it recursively.
// Print a reference to it instead.
fmt.Fprintf(b, "@%d", off)
return
}
if t == nil {
b.WriteString("<T>")
return
}
if t.Etype == types.TSSA {
b.WriteString(t.Extra.(string))
return
}
if t.Etype == types.TTUPLE {
b.WriteString(t.FieldType(0).String())
b.WriteByte(',')
b.WriteString(t.FieldType(1).String())
return
}
if t.Etype == types.TRESULTS {
tys := t.Extra.(*types.Results).Types
for i, et := range tys {
if i > 0 {
b.WriteByte(',')
}
b.WriteString(et.String())
}
return
}
flag, mode = flag.update(mode)
if mode == FTypeIdName {
flag |= FmtUnsigned
}
if t == types.Bytetype || t == types.Runetype {
// in %-T mode collapse rune and byte with their originals.
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
switch mode {
case FTypeIdName, FTypeId:
t = types.Types[t.Etype]
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
default:
cmd/compile: use a bytes.Buffer to format symbols No significant compiler speed changes, but some minor memory savings. Passes toolstash-check. name old alloc/op new alloc/op delta Template 36.3MB ± 0% 36.2MB ± 0% -0.25% (p=0.008 n=5+5) Unicode 28.3MB ± 0% 28.2MB ± 0% -0.16% (p=0.008 n=5+5) GoTypes 122MB ± 0% 121MB ± 0% -0.39% (p=0.008 n=5+5) Compiler 568MB ± 0% 566MB ± 0% -0.21% (p=0.008 n=5+5) SSA 1.95GB ± 0% 1.95GB ± 0% -0.08% (p=0.008 n=5+5) Flate 22.8MB ± 0% 22.8MB ± 0% -0.21% (p=0.008 n=5+5) GoParser 28.0MB ± 0% 27.9MB ± 0% -0.38% (p=0.008 n=5+5) Reflect 78.6MB ± 0% 78.3MB ± 0% -0.33% (p=0.008 n=5+5) Tar 34.1MB ± 0% 34.1MB ± 0% -0.19% (p=0.008 n=5+5) XML 44.3MB ± 0% 44.2MB ± 0% -0.19% (p=0.008 n=5+5) [Geo mean] 79.9MB 79.7MB -0.24% name old allocs/op new allocs/op delta Template 363k ± 0% 359k ± 0% -1.21% (p=0.008 n=5+5) Unicode 329k ± 0% 326k ± 0% -0.90% (p=0.008 n=5+5) GoTypes 1.28M ± 0% 1.25M ± 0% -2.62% (p=0.008 n=5+5) Compiler 5.39M ± 0% 5.31M ± 0% -1.45% (p=0.008 n=5+5) SSA 18.1M ± 0% 17.9M ± 0% -0.78% (p=0.008 n=5+5) Flate 228k ± 0% 226k ± 0% -0.97% (p=0.008 n=5+5) GoParser 295k ± 0% 288k ± 0% -2.26% (p=0.008 n=5+5) Reflect 949k ± 0% 932k ± 0% -1.74% (p=0.008 n=5+5) Tar 336k ± 0% 332k ± 0% -1.12% (p=0.008 n=5+5) XML 417k ± 0% 413k ± 0% -1.10% (p=0.008 n=5+5) [Geo mean] 818k 806k -1.42% Change-Id: Ibdb94650a761edec17d8eba0abdfb70a8a495da9 Reviewed-on: https://go-review.googlesource.com/c/go/+/222920 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2020-01-14 16:37:42 -08:00
sconv2(b, t.Sym, FmtShort, mode)
return
}
}
if t == types.Errortype {
b.WriteString("error")
return
}
// Unless the 'L' flag was specified, if the type has a name, just print that name.
if flag&FmtLong == 0 && t.Sym != nil && t != types.Types[t.Etype] {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
switch mode {
case FTypeId, FTypeIdName:
if flag&FmtShort != 0 {
if t.Vargen != 0 {
cmd/compile: use a bytes.Buffer to format symbols No significant compiler speed changes, but some minor memory savings. Passes toolstash-check. name old alloc/op new alloc/op delta Template 36.3MB ± 0% 36.2MB ± 0% -0.25% (p=0.008 n=5+5) Unicode 28.3MB ± 0% 28.2MB ± 0% -0.16% (p=0.008 n=5+5) GoTypes 122MB ± 0% 121MB ± 0% -0.39% (p=0.008 n=5+5) Compiler 568MB ± 0% 566MB ± 0% -0.21% (p=0.008 n=5+5) SSA 1.95GB ± 0% 1.95GB ± 0% -0.08% (p=0.008 n=5+5) Flate 22.8MB ± 0% 22.8MB ± 0% -0.21% (p=0.008 n=5+5) GoParser 28.0MB ± 0% 27.9MB ± 0% -0.38% (p=0.008 n=5+5) Reflect 78.6MB ± 0% 78.3MB ± 0% -0.33% (p=0.008 n=5+5) Tar 34.1MB ± 0% 34.1MB ± 0% -0.19% (p=0.008 n=5+5) XML 44.3MB ± 0% 44.2MB ± 0% -0.19% (p=0.008 n=5+5) [Geo mean] 79.9MB 79.7MB -0.24% name old allocs/op new allocs/op delta Template 363k ± 0% 359k ± 0% -1.21% (p=0.008 n=5+5) Unicode 329k ± 0% 326k ± 0% -0.90% (p=0.008 n=5+5) GoTypes 1.28M ± 0% 1.25M ± 0% -2.62% (p=0.008 n=5+5) Compiler 5.39M ± 0% 5.31M ± 0% -1.45% (p=0.008 n=5+5) SSA 18.1M ± 0% 17.9M ± 0% -0.78% (p=0.008 n=5+5) Flate 228k ± 0% 226k ± 0% -0.97% (p=0.008 n=5+5) GoParser 295k ± 0% 288k ± 0% -2.26% (p=0.008 n=5+5) Reflect 949k ± 0% 932k ± 0% -1.74% (p=0.008 n=5+5) Tar 336k ± 0% 332k ± 0% -1.12% (p=0.008 n=5+5) XML 417k ± 0% 413k ± 0% -1.10% (p=0.008 n=5+5) [Geo mean] 818k 806k -1.42% Change-Id: Ibdb94650a761edec17d8eba0abdfb70a8a495da9 Reviewed-on: https://go-review.googlesource.com/c/go/+/222920 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2020-01-14 16:37:42 -08:00
sconv2(b, t.Sym, FmtShort, mode)
fmt.Fprintf(b, "·%d", t.Vargen)
return
}
cmd/compile: use a bytes.Buffer to format symbols No significant compiler speed changes, but some minor memory savings. Passes toolstash-check. name old alloc/op new alloc/op delta Template 36.3MB ± 0% 36.2MB ± 0% -0.25% (p=0.008 n=5+5) Unicode 28.3MB ± 0% 28.2MB ± 0% -0.16% (p=0.008 n=5+5) GoTypes 122MB ± 0% 121MB ± 0% -0.39% (p=0.008 n=5+5) Compiler 568MB ± 0% 566MB ± 0% -0.21% (p=0.008 n=5+5) SSA 1.95GB ± 0% 1.95GB ± 0% -0.08% (p=0.008 n=5+5) Flate 22.8MB ± 0% 22.8MB ± 0% -0.21% (p=0.008 n=5+5) GoParser 28.0MB ± 0% 27.9MB ± 0% -0.38% (p=0.008 n=5+5) Reflect 78.6MB ± 0% 78.3MB ± 0% -0.33% (p=0.008 n=5+5) Tar 34.1MB ± 0% 34.1MB ± 0% -0.19% (p=0.008 n=5+5) XML 44.3MB ± 0% 44.2MB ± 0% -0.19% (p=0.008 n=5+5) [Geo mean] 79.9MB 79.7MB -0.24% name old allocs/op new allocs/op delta Template 363k ± 0% 359k ± 0% -1.21% (p=0.008 n=5+5) Unicode 329k ± 0% 326k ± 0% -0.90% (p=0.008 n=5+5) GoTypes 1.28M ± 0% 1.25M ± 0% -2.62% (p=0.008 n=5+5) Compiler 5.39M ± 0% 5.31M ± 0% -1.45% (p=0.008 n=5+5) SSA 18.1M ± 0% 17.9M ± 0% -0.78% (p=0.008 n=5+5) Flate 228k ± 0% 226k ± 0% -0.97% (p=0.008 n=5+5) GoParser 295k ± 0% 288k ± 0% -2.26% (p=0.008 n=5+5) Reflect 949k ± 0% 932k ± 0% -1.74% (p=0.008 n=5+5) Tar 336k ± 0% 332k ± 0% -1.12% (p=0.008 n=5+5) XML 417k ± 0% 413k ± 0% -1.10% (p=0.008 n=5+5) [Geo mean] 818k 806k -1.42% Change-Id: Ibdb94650a761edec17d8eba0abdfb70a8a495da9 Reviewed-on: https://go-review.googlesource.com/c/go/+/222920 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2020-01-14 16:37:42 -08:00
sconv2(b, t.Sym, FmtShort, mode)
return
}
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
if mode == FTypeIdName {
cmd/compile: use a bytes.Buffer to format symbols No significant compiler speed changes, but some minor memory savings. Passes toolstash-check. name old alloc/op new alloc/op delta Template 36.3MB ± 0% 36.2MB ± 0% -0.25% (p=0.008 n=5+5) Unicode 28.3MB ± 0% 28.2MB ± 0% -0.16% (p=0.008 n=5+5) GoTypes 122MB ± 0% 121MB ± 0% -0.39% (p=0.008 n=5+5) Compiler 568MB ± 0% 566MB ± 0% -0.21% (p=0.008 n=5+5) SSA 1.95GB ± 0% 1.95GB ± 0% -0.08% (p=0.008 n=5+5) Flate 22.8MB ± 0% 22.8MB ± 0% -0.21% (p=0.008 n=5+5) GoParser 28.0MB ± 0% 27.9MB ± 0% -0.38% (p=0.008 n=5+5) Reflect 78.6MB ± 0% 78.3MB ± 0% -0.33% (p=0.008 n=5+5) Tar 34.1MB ± 0% 34.1MB ± 0% -0.19% (p=0.008 n=5+5) XML 44.3MB ± 0% 44.2MB ± 0% -0.19% (p=0.008 n=5+5) [Geo mean] 79.9MB 79.7MB -0.24% name old allocs/op new allocs/op delta Template 363k ± 0% 359k ± 0% -1.21% (p=0.008 n=5+5) Unicode 329k ± 0% 326k ± 0% -0.90% (p=0.008 n=5+5) GoTypes 1.28M ± 0% 1.25M ± 0% -2.62% (p=0.008 n=5+5) Compiler 5.39M ± 0% 5.31M ± 0% -1.45% (p=0.008 n=5+5) SSA 18.1M ± 0% 17.9M ± 0% -0.78% (p=0.008 n=5+5) Flate 228k ± 0% 226k ± 0% -0.97% (p=0.008 n=5+5) GoParser 295k ± 0% 288k ± 0% -2.26% (p=0.008 n=5+5) Reflect 949k ± 0% 932k ± 0% -1.74% (p=0.008 n=5+5) Tar 336k ± 0% 332k ± 0% -1.12% (p=0.008 n=5+5) XML 417k ± 0% 413k ± 0% -1.10% (p=0.008 n=5+5) [Geo mean] 818k 806k -1.42% Change-Id: Ibdb94650a761edec17d8eba0abdfb70a8a495da9 Reviewed-on: https://go-review.googlesource.com/c/go/+/222920 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2020-01-14 16:37:42 -08:00
sconv2(b, t.Sym, FmtUnsigned, mode)
return
}
if t.Sym.Pkg == localpkg && t.Vargen != 0 {
b.WriteString(mode.Sprintf("%v·%d", t.Sym, t.Vargen))
return
}
}
cmd/compile: use a bytes.Buffer to format symbols No significant compiler speed changes, but some minor memory savings. Passes toolstash-check. name old alloc/op new alloc/op delta Template 36.3MB ± 0% 36.2MB ± 0% -0.25% (p=0.008 n=5+5) Unicode 28.3MB ± 0% 28.2MB ± 0% -0.16% (p=0.008 n=5+5) GoTypes 122MB ± 0% 121MB ± 0% -0.39% (p=0.008 n=5+5) Compiler 568MB ± 0% 566MB ± 0% -0.21% (p=0.008 n=5+5) SSA 1.95GB ± 0% 1.95GB ± 0% -0.08% (p=0.008 n=5+5) Flate 22.8MB ± 0% 22.8MB ± 0% -0.21% (p=0.008 n=5+5) GoParser 28.0MB ± 0% 27.9MB ± 0% -0.38% (p=0.008 n=5+5) Reflect 78.6MB ± 0% 78.3MB ± 0% -0.33% (p=0.008 n=5+5) Tar 34.1MB ± 0% 34.1MB ± 0% -0.19% (p=0.008 n=5+5) XML 44.3MB ± 0% 44.2MB ± 0% -0.19% (p=0.008 n=5+5) [Geo mean] 79.9MB 79.7MB -0.24% name old allocs/op new allocs/op delta Template 363k ± 0% 359k ± 0% -1.21% (p=0.008 n=5+5) Unicode 329k ± 0% 326k ± 0% -0.90% (p=0.008 n=5+5) GoTypes 1.28M ± 0% 1.25M ± 0% -2.62% (p=0.008 n=5+5) Compiler 5.39M ± 0% 5.31M ± 0% -1.45% (p=0.008 n=5+5) SSA 18.1M ± 0% 17.9M ± 0% -0.78% (p=0.008 n=5+5) Flate 228k ± 0% 226k ± 0% -0.97% (p=0.008 n=5+5) GoParser 295k ± 0% 288k ± 0% -2.26% (p=0.008 n=5+5) Reflect 949k ± 0% 932k ± 0% -1.74% (p=0.008 n=5+5) Tar 336k ± 0% 332k ± 0% -1.12% (p=0.008 n=5+5) XML 417k ± 0% 413k ± 0% -1.10% (p=0.008 n=5+5) [Geo mean] 818k 806k -1.42% Change-Id: Ibdb94650a761edec17d8eba0abdfb70a8a495da9 Reviewed-on: https://go-review.googlesource.com/c/go/+/222920 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2020-01-14 16:37:42 -08:00
sconv2(b, t.Sym, 0, mode)
return
}
if int(t.Etype) < len(basicnames) && basicnames[t.Etype] != "" {
var name string
switch t {
case types.UntypedBool:
name = "untyped bool"
case types.UntypedString:
name = "untyped string"
case types.UntypedInt:
name = "untyped int"
case types.UntypedRune:
name = "untyped rune"
case types.UntypedFloat:
name = "untyped float"
case types.UntypedComplex:
name = "untyped complex"
default:
name = basicnames[t.Etype]
}
b.WriteString(name)
return
}
if mode == FDbg {
b.WriteString(t.Etype.String())
b.WriteByte('-')
tconv2(b, t, flag, FErr, visited)
return
}
// At this point, we might call tconv2 recursively. Add the current type to the visited list so we don't
// try to print it recursively.
// We record the offset in the result buffer where the type's text starts. This offset serves as a reference
// point for any later references to the same type.
// Note that we remove the type from the visited map as soon as the recursive call is done.
// This prevents encoding types like map[*int]*int as map[*int]@4. (That encoding would work,
// but I'd like to use the @ notation only when strictly necessary.)
if visited == nil {
visited = map[*types.Type]int{}
}
visited[t] = b.Len()
defer delete(visited, t)
switch t.Etype {
case TPTR:
b.WriteByte('*')
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
switch mode {
case FTypeId, FTypeIdName:
if flag&FmtShort != 0 {
tconv2(b, t.Elem(), FmtShort, mode, visited)
return
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
}
}
tconv2(b, t.Elem(), 0, mode, visited)
case TARRAY:
b.WriteByte('[')
b.WriteString(strconv.FormatInt(t.NumElem(), 10))
b.WriteByte(']')
tconv2(b, t.Elem(), 0, mode, visited)
case TSLICE:
b.WriteString("[]")
tconv2(b, t.Elem(), 0, mode, visited)
case TCHAN:
switch t.ChanDir() {
case types.Crecv:
b.WriteString("<-chan ")
tconv2(b, t.Elem(), 0, mode, visited)
case types.Csend:
b.WriteString("chan<- ")
tconv2(b, t.Elem(), 0, mode, visited)
default:
b.WriteString("chan ")
if t.Elem() != nil && t.Elem().IsChan() && t.Elem().Sym == nil && t.Elem().ChanDir() == types.Crecv {
b.WriteByte('(')
tconv2(b, t.Elem(), 0, mode, visited)
b.WriteByte(')')
} else {
tconv2(b, t.Elem(), 0, mode, visited)
}
}
case TMAP:
b.WriteString("map[")
tconv2(b, t.Key(), 0, mode, visited)
b.WriteByte(']')
tconv2(b, t.Elem(), 0, mode, visited)
case TINTER:
cmd/compile: reduce allocs to c85b77c (pre-fmt.go change) levels Linker and reflect info generation (reflect.go) relies on formatting of types (tconv). The fmt.Format based approach introduces extra allocations, which matter in those cases. Resurrected sconv and tconv code from commit c85b77c (fmt.go only); and adjusted it slightly. The formatter-based approach is still used throughout the rest of the compiler, but reflect.go now uses the tconv method that simply returns the desired string. (The timing data below may not be accurate; I've included it only for comparison with the numbers in issue #16897). name old time/op new time/op delta Template 297ms ± 2% 288ms ± 3% -3.12% (p=0.000 n=27+29) Unicode 155ms ± 5% 150ms ± 5% -3.26% (p=0.000 n=30+30) GoTypes 1.00s ± 3% 0.95s ± 3% -4.51% (p=0.000 n=28+29) name old alloc/op new alloc/op delta Template 46.8MB ± 0% 46.5MB ± 0% -0.65% (p=0.000 n=28+30) Unicode 37.9MB ± 0% 37.8MB ± 0% -0.24% (p=0.000 n=29+30) GoTypes 144MB ± 0% 143MB ± 0% -0.68% (p=0.000 n=30+30) name old allocs/op new allocs/op delta Template 469k ± 0% 446k ± 0% -5.01% (p=0.000 n=29+30) Unicode 375k ± 0% 369k ± 0% -1.62% (p=0.000 n=30+28) GoTypes 1.47M ± 0% 1.37M ± 0% -6.29% (p=0.000 n=30+30) The code for sconv/tconv in fmt.go now closely match the code from c85b77c again; except that the functions are now methods. Removing the use of the bytes.Buffer in tconv and special-caseing interface{} has helped a small amount as well: name old time/op new time/op delta Template 299ms ± 3% 288ms ± 3% -3.83% (p=0.000 n=29+29) Unicode 156ms ± 5% 150ms ± 5% -3.56% (p=0.000 n=30+30) GoTypes 960ms ± 2% 954ms ± 3% -0.58% (p=0.037 n=26+29) name old alloc/op new alloc/op delta Template 46.6MB ± 0% 46.5MB ± 0% -0.22% (p=0.000 n=30+30) Unicode 37.8MB ± 0% 37.8MB ± 0% ~ (p=0.075 n=30+30) GoTypes 143MB ± 0% 143MB ± 0% -0.31% (p=0.000 n=30+30) name old allocs/op new allocs/op delta Template 447k ± 0% 446k ± 0% -0.28% (p=0.000 n=30+30) Unicode 369k ± 0% 369k ± 0% -0.03% (p=0.032 n=30+28) GoTypes 1.38M ± 0% 1.37M ± 0% -0.35% (p=0.000 n=29+30) Comparison between c85b77c and now (see issue #16897): name old time/op new time/op delta Template 307ms ± 4% 288ms ± 3% -6.24% (p=0.000 n=29+29) Unicode 164ms ± 4% 150ms ± 5% -8.20% (p=0.000 n=30+30) GoTypes 1.01s ± 3% 0.95s ± 3% -5.72% (p=0.000 n=30+29) name old alloc/op new alloc/op delta Template 46.8MB ± 0% 46.5MB ± 0% -0.66% (p=0.000 n=29+30) Unicode 37.8MB ± 0% 37.8MB ± 0% -0.13% (p=0.000 n=30+30) GoTypes 143MB ± 0% 143MB ± 0% -0.11% (p=0.000 n=30+30) name old allocs/op new allocs/op delta Template 444k ± 0% 446k ± 0% +0.48% (p=0.000 n=30+30) Unicode 369k ± 0% 369k ± 0% +0.09% (p=0.000 n=30+28) GoTypes 1.35M ± 0% 1.37M ± 0% +1.47% (p=0.000 n=30+30) There's still a small increase (< 1.5%) for GoTypes but pending a complete rewrite of fmt.go, this seems ok again. Fixes #16897. Change-Id: I7e0e56cd1b9f981252eded917f5752259d402354 Reviewed-on: https://go-review.googlesource.com/29087 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2016-09-12 13:44:43 -07:00
if t.IsEmptyInterface() {
b.WriteString("interface {}")
break
cmd/compile: reduce allocs to c85b77c (pre-fmt.go change) levels Linker and reflect info generation (reflect.go) relies on formatting of types (tconv). The fmt.Format based approach introduces extra allocations, which matter in those cases. Resurrected sconv and tconv code from commit c85b77c (fmt.go only); and adjusted it slightly. The formatter-based approach is still used throughout the rest of the compiler, but reflect.go now uses the tconv method that simply returns the desired string. (The timing data below may not be accurate; I've included it only for comparison with the numbers in issue #16897). name old time/op new time/op delta Template 297ms ± 2% 288ms ± 3% -3.12% (p=0.000 n=27+29) Unicode 155ms ± 5% 150ms ± 5% -3.26% (p=0.000 n=30+30) GoTypes 1.00s ± 3% 0.95s ± 3% -4.51% (p=0.000 n=28+29) name old alloc/op new alloc/op delta Template 46.8MB ± 0% 46.5MB ± 0% -0.65% (p=0.000 n=28+30) Unicode 37.9MB ± 0% 37.8MB ± 0% -0.24% (p=0.000 n=29+30) GoTypes 144MB ± 0% 143MB ± 0% -0.68% (p=0.000 n=30+30) name old allocs/op new allocs/op delta Template 469k ± 0% 446k ± 0% -5.01% (p=0.000 n=29+30) Unicode 375k ± 0% 369k ± 0% -1.62% (p=0.000 n=30+28) GoTypes 1.47M ± 0% 1.37M ± 0% -6.29% (p=0.000 n=30+30) The code for sconv/tconv in fmt.go now closely match the code from c85b77c again; except that the functions are now methods. Removing the use of the bytes.Buffer in tconv and special-caseing interface{} has helped a small amount as well: name old time/op new time/op delta Template 299ms ± 3% 288ms ± 3% -3.83% (p=0.000 n=29+29) Unicode 156ms ± 5% 150ms ± 5% -3.56% (p=0.000 n=30+30) GoTypes 960ms ± 2% 954ms ± 3% -0.58% (p=0.037 n=26+29) name old alloc/op new alloc/op delta Template 46.6MB ± 0% 46.5MB ± 0% -0.22% (p=0.000 n=30+30) Unicode 37.8MB ± 0% 37.8MB ± 0% ~ (p=0.075 n=30+30) GoTypes 143MB ± 0% 143MB ± 0% -0.31% (p=0.000 n=30+30) name old allocs/op new allocs/op delta Template 447k ± 0% 446k ± 0% -0.28% (p=0.000 n=30+30) Unicode 369k ± 0% 369k ± 0% -0.03% (p=0.032 n=30+28) GoTypes 1.38M ± 0% 1.37M ± 0% -0.35% (p=0.000 n=29+30) Comparison between c85b77c and now (see issue #16897): name old time/op new time/op delta Template 307ms ± 4% 288ms ± 3% -6.24% (p=0.000 n=29+29) Unicode 164ms ± 4% 150ms ± 5% -8.20% (p=0.000 n=30+30) GoTypes 1.01s ± 3% 0.95s ± 3% -5.72% (p=0.000 n=30+29) name old alloc/op new alloc/op delta Template 46.8MB ± 0% 46.5MB ± 0% -0.66% (p=0.000 n=29+30) Unicode 37.8MB ± 0% 37.8MB ± 0% -0.13% (p=0.000 n=30+30) GoTypes 143MB ± 0% 143MB ± 0% -0.11% (p=0.000 n=30+30) name old allocs/op new allocs/op delta Template 444k ± 0% 446k ± 0% +0.48% (p=0.000 n=30+30) Unicode 369k ± 0% 369k ± 0% +0.09% (p=0.000 n=30+28) GoTypes 1.35M ± 0% 1.37M ± 0% +1.47% (p=0.000 n=30+30) There's still a small increase (< 1.5%) for GoTypes but pending a complete rewrite of fmt.go, this seems ok again. Fixes #16897. Change-Id: I7e0e56cd1b9f981252eded917f5752259d402354 Reviewed-on: https://go-review.googlesource.com/29087 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2016-09-12 13:44:43 -07:00
}
b.WriteString("interface {")
for i, f := range t.Fields().Slice() {
if i != 0 {
b.WriteByte(';')
}
b.WriteByte(' ')
switch {
case f.Sym == nil:
// Check first that a symbol is defined for this type.
// Wrong interface definitions may have types lacking a symbol.
break
case types.IsExported(f.Sym.Name):
cmd/compile: use a bytes.Buffer to format symbols No significant compiler speed changes, but some minor memory savings. Passes toolstash-check. name old alloc/op new alloc/op delta Template 36.3MB ± 0% 36.2MB ± 0% -0.25% (p=0.008 n=5+5) Unicode 28.3MB ± 0% 28.2MB ± 0% -0.16% (p=0.008 n=5+5) GoTypes 122MB ± 0% 121MB ± 0% -0.39% (p=0.008 n=5+5) Compiler 568MB ± 0% 566MB ± 0% -0.21% (p=0.008 n=5+5) SSA 1.95GB ± 0% 1.95GB ± 0% -0.08% (p=0.008 n=5+5) Flate 22.8MB ± 0% 22.8MB ± 0% -0.21% (p=0.008 n=5+5) GoParser 28.0MB ± 0% 27.9MB ± 0% -0.38% (p=0.008 n=5+5) Reflect 78.6MB ± 0% 78.3MB ± 0% -0.33% (p=0.008 n=5+5) Tar 34.1MB ± 0% 34.1MB ± 0% -0.19% (p=0.008 n=5+5) XML 44.3MB ± 0% 44.2MB ± 0% -0.19% (p=0.008 n=5+5) [Geo mean] 79.9MB 79.7MB -0.24% name old allocs/op new allocs/op delta Template 363k ± 0% 359k ± 0% -1.21% (p=0.008 n=5+5) Unicode 329k ± 0% 326k ± 0% -0.90% (p=0.008 n=5+5) GoTypes 1.28M ± 0% 1.25M ± 0% -2.62% (p=0.008 n=5+5) Compiler 5.39M ± 0% 5.31M ± 0% -1.45% (p=0.008 n=5+5) SSA 18.1M ± 0% 17.9M ± 0% -0.78% (p=0.008 n=5+5) Flate 228k ± 0% 226k ± 0% -0.97% (p=0.008 n=5+5) GoParser 295k ± 0% 288k ± 0% -2.26% (p=0.008 n=5+5) Reflect 949k ± 0% 932k ± 0% -1.74% (p=0.008 n=5+5) Tar 336k ± 0% 332k ± 0% -1.12% (p=0.008 n=5+5) XML 417k ± 0% 413k ± 0% -1.10% (p=0.008 n=5+5) [Geo mean] 818k 806k -1.42% Change-Id: Ibdb94650a761edec17d8eba0abdfb70a8a495da9 Reviewed-on: https://go-review.googlesource.com/c/go/+/222920 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2020-01-14 16:37:42 -08:00
sconv2(b, f.Sym, FmtShort, mode)
default:
flag1 := FmtLeft
if flag&FmtUnsigned != 0 {
flag1 = FmtUnsigned
}
cmd/compile: use a bytes.Buffer to format symbols No significant compiler speed changes, but some minor memory savings. Passes toolstash-check. name old alloc/op new alloc/op delta Template 36.3MB ± 0% 36.2MB ± 0% -0.25% (p=0.008 n=5+5) Unicode 28.3MB ± 0% 28.2MB ± 0% -0.16% (p=0.008 n=5+5) GoTypes 122MB ± 0% 121MB ± 0% -0.39% (p=0.008 n=5+5) Compiler 568MB ± 0% 566MB ± 0% -0.21% (p=0.008 n=5+5) SSA 1.95GB ± 0% 1.95GB ± 0% -0.08% (p=0.008 n=5+5) Flate 22.8MB ± 0% 22.8MB ± 0% -0.21% (p=0.008 n=5+5) GoParser 28.0MB ± 0% 27.9MB ± 0% -0.38% (p=0.008 n=5+5) Reflect 78.6MB ± 0% 78.3MB ± 0% -0.33% (p=0.008 n=5+5) Tar 34.1MB ± 0% 34.1MB ± 0% -0.19% (p=0.008 n=5+5) XML 44.3MB ± 0% 44.2MB ± 0% -0.19% (p=0.008 n=5+5) [Geo mean] 79.9MB 79.7MB -0.24% name old allocs/op new allocs/op delta Template 363k ± 0% 359k ± 0% -1.21% (p=0.008 n=5+5) Unicode 329k ± 0% 326k ± 0% -0.90% (p=0.008 n=5+5) GoTypes 1.28M ± 0% 1.25M ± 0% -2.62% (p=0.008 n=5+5) Compiler 5.39M ± 0% 5.31M ± 0% -1.45% (p=0.008 n=5+5) SSA 18.1M ± 0% 17.9M ± 0% -0.78% (p=0.008 n=5+5) Flate 228k ± 0% 226k ± 0% -0.97% (p=0.008 n=5+5) GoParser 295k ± 0% 288k ± 0% -2.26% (p=0.008 n=5+5) Reflect 949k ± 0% 932k ± 0% -1.74% (p=0.008 n=5+5) Tar 336k ± 0% 332k ± 0% -1.12% (p=0.008 n=5+5) XML 417k ± 0% 413k ± 0% -1.10% (p=0.008 n=5+5) [Geo mean] 818k 806k -1.42% Change-Id: Ibdb94650a761edec17d8eba0abdfb70a8a495da9 Reviewed-on: https://go-review.googlesource.com/c/go/+/222920 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2020-01-14 16:37:42 -08:00
sconv2(b, f.Sym, flag1, mode)
}
tconv2(b, f.Type, FmtShort, mode, visited)
}
if t.NumFields() != 0 {
b.WriteByte(' ')
}
b.WriteByte('}')
case TFUNC:
if flag&FmtShort != 0 {
// no leading func
} else {
if t.Recv() != nil {
b.WriteString("method")
tconv2(b, t.Recvs(), 0, mode, visited)
b.WriteByte(' ')
}
b.WriteString("func")
}
tconv2(b, t.Params(), 0, mode, visited)
switch t.NumResults() {
case 0:
// nothing to do
case 1:
b.WriteByte(' ')
tconv2(b, t.Results().Field(0).Type, 0, mode, visited) // struct->field->field's type
default:
b.WriteByte(' ')
tconv2(b, t.Results(), 0, mode, visited)
}
case TSTRUCT:
cmd/compile: shrink gc.Type in half Many of Type's fields are etype-specific. This CL organizes them into their own auxiliary types, duplicating a few fields as necessary, and adds an Extra field to hold them. It also sorts the remaining fields for better struct packing. It also improves documentation for most fields. This reduces the size of Type at the cost of some extra allocations. There's no CPU impact; memory impact below. It also makes the natural structure of Type clearer. Passes toolstash -cmp on all architectures. Ideas for future work in this vein: (1) Width and Align probably only need to be stored for Struct and Array types. The refactoring to accomplish this would hopefully also eliminate TFUNCARGS and TCHANARGS entirely. (2) Maplineno is sparsely used and could probably better be stored in a separate map[*Type]int32, with mapqueue updated to store both a Node and a line number. (3) The Printed field may be removable once the old (non-binary) importer/exported has been removed. (4) StructType's fields field could be changed from *[]*Field to []*Field, which would remove a common allocation. (5) I believe that Type.Nod can be moved to ForwardType. Separate CL. name old alloc/op new alloc/op delta Template 57.9MB ± 0% 55.9MB ± 0% -3.43% (p=0.000 n=50+50) Unicode 38.3MB ± 0% 37.8MB ± 0% -1.39% (p=0.000 n=50+50) GoTypes 185MB ± 0% 180MB ± 0% -2.56% (p=0.000 n=50+50) Compiler 824MB ± 0% 806MB ± 0% -2.19% (p=0.000 n=50+50) name old allocs/op new allocs/op delta Template 486k ± 0% 497k ± 0% +2.25% (p=0.000 n=50+50) Unicode 377k ± 0% 379k ± 0% +0.55% (p=0.000 n=50+50) GoTypes 1.39M ± 0% 1.42M ± 0% +1.63% (p=0.000 n=50+50) Compiler 5.52M ± 0% 5.57M ± 0% +0.84% (p=0.000 n=47+50) Change-Id: I828488eeb74902b013d5ae4cf844de0b6c0dfc87 Reviewed-on: https://go-review.googlesource.com/21611 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2016-04-01 20:11:30 -07:00
if m := t.StructType().Map; m != nil {
mt := m.MapType()
// Format the bucket struct for map[x]y as map.bucket[x]y.
// This avoids a recursive print that generates very long names.
switch t {
case mt.Bucket:
b.WriteString("map.bucket[")
case mt.Hmap:
b.WriteString("map.hdr[")
case mt.Hiter:
b.WriteString("map.iter[")
default:
Fatalf("unknown internal map type")
}
tconv2(b, m.Key(), 0, mode, visited)
b.WriteByte(']')
tconv2(b, m.Elem(), 0, mode, visited)
break
}
if funarg := t.StructType().Funarg; funarg != types.FunargNone {
b.WriteByte('(')
var flag1 FmtFlag
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
switch mode {
case FTypeId, FTypeIdName, FErr:
// no argument names on function signature, and no "noescape"/"nosplit" tags
flag1 = FmtShort
}
for i, f := range t.Fields().Slice() {
if i != 0 {
b.WriteString(", ")
}
fldconv(b, f, flag1, mode, visited, funarg)
}
b.WriteByte(')')
} else {
b.WriteString("struct {")
for i, f := range t.Fields().Slice() {
if i != 0 {
b.WriteByte(';')
}
b.WriteByte(' ')
fldconv(b, f, FmtLong, mode, visited, funarg)
}
if t.NumFields() != 0 {
b.WriteByte(' ')
}
b.WriteByte('}')
}
case TFORW:
b.WriteString("undefined")
if t.Sym != nil {
b.WriteByte(' ')
cmd/compile: use a bytes.Buffer to format symbols No significant compiler speed changes, but some minor memory savings. Passes toolstash-check. name old alloc/op new alloc/op delta Template 36.3MB ± 0% 36.2MB ± 0% -0.25% (p=0.008 n=5+5) Unicode 28.3MB ± 0% 28.2MB ± 0% -0.16% (p=0.008 n=5+5) GoTypes 122MB ± 0% 121MB ± 0% -0.39% (p=0.008 n=5+5) Compiler 568MB ± 0% 566MB ± 0% -0.21% (p=0.008 n=5+5) SSA 1.95GB ± 0% 1.95GB ± 0% -0.08% (p=0.008 n=5+5) Flate 22.8MB ± 0% 22.8MB ± 0% -0.21% (p=0.008 n=5+5) GoParser 28.0MB ± 0% 27.9MB ± 0% -0.38% (p=0.008 n=5+5) Reflect 78.6MB ± 0% 78.3MB ± 0% -0.33% (p=0.008 n=5+5) Tar 34.1MB ± 0% 34.1MB ± 0% -0.19% (p=0.008 n=5+5) XML 44.3MB ± 0% 44.2MB ± 0% -0.19% (p=0.008 n=5+5) [Geo mean] 79.9MB 79.7MB -0.24% name old allocs/op new allocs/op delta Template 363k ± 0% 359k ± 0% -1.21% (p=0.008 n=5+5) Unicode 329k ± 0% 326k ± 0% -0.90% (p=0.008 n=5+5) GoTypes 1.28M ± 0% 1.25M ± 0% -2.62% (p=0.008 n=5+5) Compiler 5.39M ± 0% 5.31M ± 0% -1.45% (p=0.008 n=5+5) SSA 18.1M ± 0% 17.9M ± 0% -0.78% (p=0.008 n=5+5) Flate 228k ± 0% 226k ± 0% -0.97% (p=0.008 n=5+5) GoParser 295k ± 0% 288k ± 0% -2.26% (p=0.008 n=5+5) Reflect 949k ± 0% 932k ± 0% -1.74% (p=0.008 n=5+5) Tar 336k ± 0% 332k ± 0% -1.12% (p=0.008 n=5+5) XML 417k ± 0% 413k ± 0% -1.10% (p=0.008 n=5+5) [Geo mean] 818k 806k -1.42% Change-Id: Ibdb94650a761edec17d8eba0abdfb70a8a495da9 Reviewed-on: https://go-review.googlesource.com/c/go/+/222920 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2020-01-14 16:37:42 -08:00
sconv2(b, t.Sym, 0, mode)
}
case TUNSAFEPTR:
b.WriteString("unsafe.Pointer")
case Txxx:
b.WriteString("Txxx")
default:
// Don't know how to handle - fall back to detailed prints.
b.WriteString(mode.Sprintf("%v <%v>", t.Etype, t.Sym))
}
}
// Statements which may be rendered with a simplestmt as init.
func stmtwithinit(op Op) bool {
switch op {
case OIF, OFOR, OFORUNTIL, OSWITCH:
return true
}
return false
}
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
func (n *Node) stmtfmt(s fmt.State, mode fmtMode) {
// some statements allow for an init, but at most one,
// but we may have an arbitrary number added, eg by typecheck
// and inlining. If it doesn't fit the syntax, emit an enclosing
// block starting with the init statements.
// if we can just say "for" n->ninit; ... then do so
simpleinit := n.Ninit.Len() == 1 && n.Ninit.First().Ninit.Len() == 0 && stmtwithinit(n.Op)
// otherwise, print the inits as separate statements
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
complexinit := n.Ninit.Len() != 0 && !simpleinit && (mode != FErr)
// but if it was for if/for/switch, put in an extra surrounding block to limit the scope
extrablock := complexinit && stmtwithinit(n.Op)
if extrablock {
fmt.Fprint(s, "{")
}
if complexinit {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, " %v; ", n.Ninit)
}
switch n.Op {
case ODCL:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "var %v %v", n.Left.Sym, n.Left.Type)
case ODCLFIELD:
cmd/compile: replace Field.Nname.Pos with Field.Pos For struct fields and methods, Field.Nname was only used to store position information, which means we're allocating an entire ONAME Node+Name+Param structure just for one field. We can optimize away these ONAME allocations by instead adding a Field.Pos field. Unfortunately, we can't get rid of Field.Nname, because it's needed for function parameters, so Field grows a little bit and now has more redundant information in those cases. However, that was already the case (e.g., Field.Sym and Field.Nname.Sym), and it's still a net win for allocations as demonstrated by the benchmarks below. Additionally, by moving the ONAME allocation for function parameters to funcargs, we can avoid allocating them for function parameters that aren't used in corresponding function bodies (e.g., interface methods, function-typed variables, and imported functions/methods without inline bodies). name old time/op new time/op delta Template 254ms ± 6% 251ms ± 6% -1.04% (p=0.000 n=487+488) Unicode 128ms ± 7% 128ms ± 7% ~ (p=0.294 n=482+467) GoTypes 862ms ± 5% 860ms ± 4% ~ (p=0.075 n=488+471) Compiler 3.91s ± 4% 3.90s ± 4% -0.39% (p=0.000 n=468+473) name old user-time/op new user-time/op delta Template 339ms ±14% 336ms ±14% -1.02% (p=0.001 n=498+494) Unicode 176ms ±18% 176ms ±25% ~ (p=0.940 n=491+499) GoTypes 1.13s ± 8% 1.13s ± 9% ~ (p=0.157 n=496+493) Compiler 5.24s ± 6% 5.21s ± 6% -0.57% (p=0.000 n=485+489) name old alloc/op new alloc/op delta Template 38.3MB ± 0% 37.3MB ± 0% -2.58% (p=0.000 n=499+497) Unicode 29.1MB ± 0% 29.1MB ± 0% -0.03% (p=0.000 n=500+493) GoTypes 116MB ± 0% 115MB ± 0% -0.65% (p=0.000 n=498+499) Compiler 492MB ± 0% 487MB ± 0% -1.00% (p=0.000 n=497+498) name old allocs/op new allocs/op delta Template 364k ± 0% 360k ± 0% -1.15% (p=0.000 n=499+499) Unicode 336k ± 0% 336k ± 0% -0.01% (p=0.000 n=500+493) GoTypes 1.16M ± 0% 1.16M ± 0% -0.30% (p=0.000 n=499+499) Compiler 4.54M ± 0% 4.51M ± 0% -0.58% (p=0.000 n=494+495) Passes toolstash-check -gcflags=-dwarf=false. Changes DWARF output because position information is now tracked more precisely for function parameters. Change-Id: Ib8077d70d564cc448c5e4290baceab3a4396d712 Reviewed-on: https://go-review.googlesource.com/108217 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2018-04-18 22:57:10 -07:00
if n.Sym != nil {
mode.Fprintf(s, "%v %v", n.Sym, n.Left)
} else {
cmd/compile: replace Field.Nname.Pos with Field.Pos For struct fields and methods, Field.Nname was only used to store position information, which means we're allocating an entire ONAME Node+Name+Param structure just for one field. We can optimize away these ONAME allocations by instead adding a Field.Pos field. Unfortunately, we can't get rid of Field.Nname, because it's needed for function parameters, so Field grows a little bit and now has more redundant information in those cases. However, that was already the case (e.g., Field.Sym and Field.Nname.Sym), and it's still a net win for allocations as demonstrated by the benchmarks below. Additionally, by moving the ONAME allocation for function parameters to funcargs, we can avoid allocating them for function parameters that aren't used in corresponding function bodies (e.g., interface methods, function-typed variables, and imported functions/methods without inline bodies). name old time/op new time/op delta Template 254ms ± 6% 251ms ± 6% -1.04% (p=0.000 n=487+488) Unicode 128ms ± 7% 128ms ± 7% ~ (p=0.294 n=482+467) GoTypes 862ms ± 5% 860ms ± 4% ~ (p=0.075 n=488+471) Compiler 3.91s ± 4% 3.90s ± 4% -0.39% (p=0.000 n=468+473) name old user-time/op new user-time/op delta Template 339ms ±14% 336ms ±14% -1.02% (p=0.001 n=498+494) Unicode 176ms ±18% 176ms ±25% ~ (p=0.940 n=491+499) GoTypes 1.13s ± 8% 1.13s ± 9% ~ (p=0.157 n=496+493) Compiler 5.24s ± 6% 5.21s ± 6% -0.57% (p=0.000 n=485+489) name old alloc/op new alloc/op delta Template 38.3MB ± 0% 37.3MB ± 0% -2.58% (p=0.000 n=499+497) Unicode 29.1MB ± 0% 29.1MB ± 0% -0.03% (p=0.000 n=500+493) GoTypes 116MB ± 0% 115MB ± 0% -0.65% (p=0.000 n=498+499) Compiler 492MB ± 0% 487MB ± 0% -1.00% (p=0.000 n=497+498) name old allocs/op new allocs/op delta Template 364k ± 0% 360k ± 0% -1.15% (p=0.000 n=499+499) Unicode 336k ± 0% 336k ± 0% -0.01% (p=0.000 n=500+493) GoTypes 1.16M ± 0% 1.16M ± 0% -0.30% (p=0.000 n=499+499) Compiler 4.54M ± 0% 4.51M ± 0% -0.58% (p=0.000 n=494+495) Passes toolstash-check -gcflags=-dwarf=false. Changes DWARF output because position information is now tracked more precisely for function parameters. Change-Id: Ib8077d70d564cc448c5e4290baceab3a4396d712 Reviewed-on: https://go-review.googlesource.com/108217 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2018-04-18 22:57:10 -07:00
mode.Fprintf(s, "%v", n.Left)
}
// Don't export "v = <N>" initializing statements, hope they're always
cmd/compile: export inlined function bodies Completed implementation for exporting inlined functions using the new binary export format. This change passes (export GO_GCFLAGS=-newexport; make all.bash) but for gc's builtin_test.go which we need to adjust before enabling this code by default. For a high-level description of the export format see the comment at the top of bexport.go. Major changes: 1) The export format for the platform independent export data changed: When we export inlined function bodies, additional objects (other functions, types, etc.) that are referred to by the function bodies will need to be exported. While this doesn't affect the platform-independent portion directly, it adds more objects to the exportlist while we are exporting. Instead of trying to sort the objects into groups, just export objects as they appear in the export list. This is slightly less compact (one extra byte per object), but it is simpler and much more flexible. 2) The export format contains now three sections: 1) The plat- form independent objects, 2) the objects pulled in for export via inlined function bodies, and 3) the inlined function bodies. 3) Completed the exporting and importing code for inlined function bodies. The format is completely compiler-specific and easily changeable w/o affecting other tools. There is still quite a bit of room for denser encoding. This can happen at any time in the future. This change contains also the adjustments for go/internal/gcimporter, necessary because of the export format change 1) mentioned above. For #13241. Change-Id: I86bca0bd984b12ccf13d0d30892e6e25f6d04ed5 Reviewed-on: https://go-review.googlesource.com/21172 Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-03-18 17:21:32 -07:00
// preceded by the DCL which will be re-parsed and typechecked to reproduce
// the "v = <N>" again.
case OAS:
cmd/compile: pack bool fields in Node, Name, Func and Type structs to bitsets This reduces compiler memory usage by up to 4% - see compilebench results below. name old time/op new time/op delta Template 245ms ± 4% 241ms ± 2% -1.88% (p=0.029 n=10+10) Unicode 126ms ± 3% 124ms ± 3% ~ (p=0.105 n=10+10) GoTypes 805ms ± 2% 813ms ± 3% ~ (p=0.515 n=8+10) Compiler 3.95s ± 2% 3.83s ± 1% -2.96% (p=0.000 n=9+10) MakeBash 47.4s ± 4% 46.6s ± 1% -1.59% (p=0.028 n=9+10) name old user-ns/op new user-ns/op delta Template 324M ± 5% 326M ± 3% ~ (p=0.935 n=10+10) Unicode 186M ± 5% 178M ±10% ~ (p=0.067 n=9+10) GoTypes 1.08G ± 7% 1.09G ± 4% ~ (p=0.956 n=10+10) Compiler 5.34G ± 4% 5.31G ± 1% ~ (p=0.501 n=10+8) name old alloc/op new alloc/op delta Template 41.0MB ± 0% 39.8MB ± 0% -3.03% (p=0.000 n=10+10) Unicode 32.3MB ± 0% 31.0MB ± 0% -4.13% (p=0.000 n=10+10) GoTypes 119MB ± 0% 116MB ± 0% -2.39% (p=0.000 n=10+10) Compiler 499MB ± 0% 487MB ± 0% -2.48% (p=0.000 n=10+10) name old allocs/op new allocs/op delta Template 380k ± 1% 379k ± 1% ~ (p=0.436 n=10+10) Unicode 324k ± 1% 324k ± 0% ~ (p=0.853 n=10+10) GoTypes 1.15M ± 0% 1.15M ± 0% ~ (p=0.481 n=10+10) Compiler 4.41M ± 0% 4.41M ± 0% -0.12% (p=0.007 n=10+10) name old text-bytes new text-bytes delta HelloSize 623k ± 0% 623k ± 0% ~ (all equal) CmdGoSize 6.64M ± 0% 6.64M ± 0% ~ (all equal) name old data-bytes new data-bytes delta HelloSize 5.81k ± 0% 5.81k ± 0% ~ (all equal) CmdGoSize 238k ± 0% 238k ± 0% ~ (all equal) name old bss-bytes new bss-bytes delta HelloSize 134k ± 0% 134k ± 0% ~ (all equal) CmdGoSize 152k ± 0% 152k ± 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 967k ± 0% 967k ± 0% ~ (all equal) CmdGoSize 10.2M ± 0% 10.2M ± 0% ~ (all equal) Change-Id: I1f40af738254892bd6c8ba2eb43390b175753d52 Reviewed-on: https://go-review.googlesource.com/37445 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2017-02-27 19:56:38 +02:00
if n.Colas() && !complexinit {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "%v := %v", n.Left, n.Right)
} else {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "%v = %v", n.Left, n.Right)
}
case OASOP:
cmd/compile: pack bool fields in Node, Name, Func and Type structs to bitsets This reduces compiler memory usage by up to 4% - see compilebench results below. name old time/op new time/op delta Template 245ms ± 4% 241ms ± 2% -1.88% (p=0.029 n=10+10) Unicode 126ms ± 3% 124ms ± 3% ~ (p=0.105 n=10+10) GoTypes 805ms ± 2% 813ms ± 3% ~ (p=0.515 n=8+10) Compiler 3.95s ± 2% 3.83s ± 1% -2.96% (p=0.000 n=9+10) MakeBash 47.4s ± 4% 46.6s ± 1% -1.59% (p=0.028 n=9+10) name old user-ns/op new user-ns/op delta Template 324M ± 5% 326M ± 3% ~ (p=0.935 n=10+10) Unicode 186M ± 5% 178M ±10% ~ (p=0.067 n=9+10) GoTypes 1.08G ± 7% 1.09G ± 4% ~ (p=0.956 n=10+10) Compiler 5.34G ± 4% 5.31G ± 1% ~ (p=0.501 n=10+8) name old alloc/op new alloc/op delta Template 41.0MB ± 0% 39.8MB ± 0% -3.03% (p=0.000 n=10+10) Unicode 32.3MB ± 0% 31.0MB ± 0% -4.13% (p=0.000 n=10+10) GoTypes 119MB ± 0% 116MB ± 0% -2.39% (p=0.000 n=10+10) Compiler 499MB ± 0% 487MB ± 0% -2.48% (p=0.000 n=10+10) name old allocs/op new allocs/op delta Template 380k ± 1% 379k ± 1% ~ (p=0.436 n=10+10) Unicode 324k ± 1% 324k ± 0% ~ (p=0.853 n=10+10) GoTypes 1.15M ± 0% 1.15M ± 0% ~ (p=0.481 n=10+10) Compiler 4.41M ± 0% 4.41M ± 0% -0.12% (p=0.007 n=10+10) name old text-bytes new text-bytes delta HelloSize 623k ± 0% 623k ± 0% ~ (all equal) CmdGoSize 6.64M ± 0% 6.64M ± 0% ~ (all equal) name old data-bytes new data-bytes delta HelloSize 5.81k ± 0% 5.81k ± 0% ~ (all equal) CmdGoSize 238k ± 0% 238k ± 0% ~ (all equal) name old bss-bytes new bss-bytes delta HelloSize 134k ± 0% 134k ± 0% ~ (all equal) CmdGoSize 152k ± 0% 152k ± 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 967k ± 0% 967k ± 0% ~ (all equal) CmdGoSize 10.2M ± 0% 10.2M ± 0% ~ (all equal) Change-Id: I1f40af738254892bd6c8ba2eb43390b175753d52 Reviewed-on: https://go-review.googlesource.com/37445 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2017-02-27 19:56:38 +02:00
if n.Implicit() {
if n.SubOp() == OADD {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "%v++", n.Left)
} else {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "%v--", n.Left)
}
break
}
mode.Fprintf(s, "%v %#v= %v", n.Left, n.SubOp(), n.Right)
case OAS2:
cmd/compile: pack bool fields in Node, Name, Func and Type structs to bitsets This reduces compiler memory usage by up to 4% - see compilebench results below. name old time/op new time/op delta Template 245ms ± 4% 241ms ± 2% -1.88% (p=0.029 n=10+10) Unicode 126ms ± 3% 124ms ± 3% ~ (p=0.105 n=10+10) GoTypes 805ms ± 2% 813ms ± 3% ~ (p=0.515 n=8+10) Compiler 3.95s ± 2% 3.83s ± 1% -2.96% (p=0.000 n=9+10) MakeBash 47.4s ± 4% 46.6s ± 1% -1.59% (p=0.028 n=9+10) name old user-ns/op new user-ns/op delta Template 324M ± 5% 326M ± 3% ~ (p=0.935 n=10+10) Unicode 186M ± 5% 178M ±10% ~ (p=0.067 n=9+10) GoTypes 1.08G ± 7% 1.09G ± 4% ~ (p=0.956 n=10+10) Compiler 5.34G ± 4% 5.31G ± 1% ~ (p=0.501 n=10+8) name old alloc/op new alloc/op delta Template 41.0MB ± 0% 39.8MB ± 0% -3.03% (p=0.000 n=10+10) Unicode 32.3MB ± 0% 31.0MB ± 0% -4.13% (p=0.000 n=10+10) GoTypes 119MB ± 0% 116MB ± 0% -2.39% (p=0.000 n=10+10) Compiler 499MB ± 0% 487MB ± 0% -2.48% (p=0.000 n=10+10) name old allocs/op new allocs/op delta Template 380k ± 1% 379k ± 1% ~ (p=0.436 n=10+10) Unicode 324k ± 1% 324k ± 0% ~ (p=0.853 n=10+10) GoTypes 1.15M ± 0% 1.15M ± 0% ~ (p=0.481 n=10+10) Compiler 4.41M ± 0% 4.41M ± 0% -0.12% (p=0.007 n=10+10) name old text-bytes new text-bytes delta HelloSize 623k ± 0% 623k ± 0% ~ (all equal) CmdGoSize 6.64M ± 0% 6.64M ± 0% ~ (all equal) name old data-bytes new data-bytes delta HelloSize 5.81k ± 0% 5.81k ± 0% ~ (all equal) CmdGoSize 238k ± 0% 238k ± 0% ~ (all equal) name old bss-bytes new bss-bytes delta HelloSize 134k ± 0% 134k ± 0% ~ (all equal) CmdGoSize 152k ± 0% 152k ± 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 967k ± 0% 967k ± 0% ~ (all equal) CmdGoSize 10.2M ± 0% 10.2M ± 0% ~ (all equal) Change-Id: I1f40af738254892bd6c8ba2eb43390b175753d52 Reviewed-on: https://go-review.googlesource.com/37445 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2017-02-27 19:56:38 +02:00
if n.Colas() && !complexinit {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "%.v := %.v", n.List, n.Rlist)
break
}
fallthrough
case OAS2DOTTYPE, OAS2FUNC, OAS2MAPR, OAS2RECV:
mode.Fprintf(s, "%.v = %v", n.List, n.Right)
case ORETURN:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "return %.v", n.List)
case ORETJMP:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "retjmp %v", n.Sym)
case OINLMARK:
mode.Fprintf(s, "inlmark %d", n.Xoffset)
cmd/compile: bulk rename This change does a bulk rename of several identifiers in the compiler. See #27167 and https://docs.google.com/document/d/19_ExiylD9MRfeAjKIfEsMU1_RGhuxB9sA0b5Zv7byVI/ for context and for discussion of these particular renames. Commands run to generate this change: gorename -from '"cmd/compile/internal/gc".OPROC' -to OGO gorename -from '"cmd/compile/internal/gc".OCOM' -to OBITNOT gorename -from '"cmd/compile/internal/gc".OMINUS' -to ONEG gorename -from '"cmd/compile/internal/gc".OIND' -to ODEREF gorename -from '"cmd/compile/internal/gc".OARRAYBYTESTR' -to OBYTES2STR gorename -from '"cmd/compile/internal/gc".OARRAYBYTESTRTMP' -to OBYTES2STRTMP gorename -from '"cmd/compile/internal/gc".OARRAYRUNESTR' -to ORUNES2STR gorename -from '"cmd/compile/internal/gc".OSTRARRAYBYTE' -to OSTR2BYTES gorename -from '"cmd/compile/internal/gc".OSTRARRAYBYTETMP' -to OSTR2BYTESTMP gorename -from '"cmd/compile/internal/gc".OSTRARRAYRUNE' -to OSTR2RUNES gorename -from '"cmd/compile/internal/gc".Etop' -to ctxStmt gorename -from '"cmd/compile/internal/gc".Erv' -to ctxExpr gorename -from '"cmd/compile/internal/gc".Ecall' -to ctxCallee gorename -from '"cmd/compile/internal/gc".Efnstruct' -to ctxMultiOK gorename -from '"cmd/compile/internal/gc".Easgn' -to ctxAssign gorename -from '"cmd/compile/internal/gc".Ecomplit' -to ctxCompLit Not altered: parameters and local variables (mostly in typecheck.go) named top, which should probably now be called ctx (and which should probably have a named type). Also not altered: Field called Top in gc.Func. gorename -from '"cmd/compile/internal/gc".Node.Isddd' -to IsDDD gorename -from '"cmd/compile/internal/gc".Node.SetIsddd' -to SetIsDDD gorename -from '"cmd/compile/internal/gc".nodeIsddd' -to nodeIsDDD gorename -from '"cmd/compile/internal/types".Field.Isddd' -to IsDDD gorename -from '"cmd/compile/internal/types".Field.SetIsddd' -to SetIsDDD gorename -from '"cmd/compile/internal/types".fieldIsddd' -to fieldIsDDD Not altered: function gc.hasddd, params and local variables called isddd Also not altered: fmt.go prints nodes using "isddd(%v)". cd cmd/compile/internal/gc; go generate I then manually found impacted comments using exact string match and fixed them up by hand. The comment changes were trivial. Passes toolstash-check. Fixes #27167. If this experiment is deemed a success, we will open a new tracking issue for renames to do at the end of the 1.13 cycles. Change-Id: I2dc541533d2ab0d06cb3d31d65df205ecfb151e8 Reviewed-on: https://go-review.googlesource.com/c/150140 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2018-11-18 08:34:38 -08:00
case OGO:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "go %v", n.Left)
case ODEFER:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "defer %v", n.Left)
case OIF:
if simpleinit {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "if %v; %v { %v }", n.Ninit.First(), n.Left, n.Nbody)
} else {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "if %v { %v }", n.Left, n.Nbody)
}
if n.Rlist.Len() != 0 {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, " else { %v }", n.Rlist)
}
case OFOR, OFORUNTIL:
opname := "for"
if n.Op == OFORUNTIL {
opname = "foruntil"
}
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
if mode == FErr { // TODO maybe only if FmtShort, same below
fmt.Fprintf(s, "%s loop", opname)
break
}
fmt.Fprint(s, opname)
if simpleinit {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, " %v;", n.Ninit.First())
} else if n.Right != nil {
fmt.Fprint(s, " ;")
}
if n.Left != nil {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, " %v", n.Left)
}
if n.Right != nil {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "; %v", n.Right)
} else if simpleinit {
fmt.Fprint(s, ";")
}
cmd/compile: don't produce a past-the-end pointer in range loops Currently, range loops over slices and arrays are compiled roughly like: for i, x := range s { b } ⇓ for i, _n, _p := 0, len(s), &s[0]; i < _n; i, _p = i+1, _p + unsafe.Sizeof(s[0]) { b } ⇓ i, _n, _p := 0, len(s), &s[0] goto cond body: { b } i, _p = i+1, _p + unsafe.Sizeof(s[0]) cond: if i < _n { goto body } else { goto end } end: The problem with this lowering is that _p may temporarily point past the end of the allocation the moment before the loop terminates. Right now this isn't a problem because there's never a safe-point during this brief moment. We're about to introduce safe-points everywhere, so this bad pointer is going to be a problem. We could mark the increment as an unsafe block, but this inhibits reordering opportunities and could result in infrequent safe-points if the body is short. Instead, this CL fixes this by changing how we compile range loops to never produce this past-the-end pointer. It changes the lowering to roughly: i, _n, _p := 0, len(s), &s[0] if i < _n { goto body } else { goto end } top: _p += unsafe.Sizeof(s[0]) body: { b } i++ if i < _n { goto top } else { goto end } end: Notably, the increment is split into two parts: we increment the index before checking the condition, but increment the pointer only *after* the condition check has succeeded. The implementation builds on the OFORUNTIL construct that was introduced during the loop preemption experiments, since OFORUNTIL places the increment and condition after the loop body. To support the extra "late increment" step, we further define OFORUNTIL's "List" field to contain the late increment statements. This makes all of this a relatively small change. This depends on the improvements to the prove pass in CL 102603. With the current lowering, bounds-check elimination knows that i < _n in the body because the body block is dominated by the cond block. In the new lowering, deriving this fact requires detecting that i < _n on *both* paths into body and hence is true in body. CL 102603 made prove able to detect this. The code size effect of this is minimal. The cmd/go binary on linux/amd64 increases by 0.17%. Performance-wise, this actually appears to be a net win, though it's mostly noise: name old time/op new time/op delta BinaryTree17-12 2.80s ± 0% 2.61s ± 1% -6.88% (p=0.000 n=20+18) Fannkuch11-12 2.41s ± 0% 2.42s ± 0% +0.05% (p=0.005 n=20+20) FmtFprintfEmpty-12 41.6ns ± 5% 41.4ns ± 6% ~ (p=0.765 n=20+19) FmtFprintfString-12 69.4ns ± 3% 69.3ns ± 1% ~ (p=0.084 n=19+17) FmtFprintfInt-12 76.1ns ± 1% 77.3ns ± 1% +1.57% (p=0.000 n=19+19) FmtFprintfIntInt-12 122ns ± 2% 123ns ± 3% +0.95% (p=0.015 n=20+20) FmtFprintfPrefixedInt-12 153ns ± 2% 151ns ± 3% -1.27% (p=0.013 n=20+20) FmtFprintfFloat-12 215ns ± 0% 216ns ± 0% +0.47% (p=0.000 n=20+16) FmtManyArgs-12 486ns ± 1% 498ns ± 0% +2.40% (p=0.000 n=20+17) GobDecode-12 6.43ms ± 0% 6.50ms ± 0% +1.08% (p=0.000 n=18+19) GobEncode-12 5.43ms ± 1% 5.47ms ± 0% +0.76% (p=0.000 n=20+20) Gzip-12 218ms ± 1% 218ms ± 1% ~ (p=0.883 n=20+20) Gunzip-12 38.8ms ± 0% 38.9ms ± 0% ~ (p=0.644 n=19+19) HTTPClientServer-12 76.2µs ± 1% 76.4µs ± 2% ~ (p=0.218 n=20+20) JSONEncode-12 12.2ms ± 0% 12.3ms ± 1% +0.45% (p=0.000 n=19+19) JSONDecode-12 54.2ms ± 1% 53.3ms ± 0% -1.67% (p=0.000 n=20+20) Mandelbrot200-12 3.71ms ± 0% 3.71ms ± 0% ~ (p=0.143 n=19+20) GoParse-12 3.22ms ± 0% 3.19ms ± 1% -0.72% (p=0.000 n=20+20) RegexpMatchEasy0_32-12 76.7ns ± 1% 75.8ns ± 1% -1.19% (p=0.000 n=20+17) RegexpMatchEasy0_1K-12 245ns ± 1% 243ns ± 0% -0.72% (p=0.000 n=18+17) RegexpMatchEasy1_32-12 71.9ns ± 0% 71.7ns ± 1% -0.39% (p=0.006 n=12+18) RegexpMatchEasy1_1K-12 358ns ± 1% 354ns ± 1% -1.13% (p=0.000 n=20+19) RegexpMatchMedium_32-12 105ns ± 2% 105ns ± 1% -0.63% (p=0.007 n=19+20) RegexpMatchMedium_1K-12 31.9µs ± 1% 31.9µs ± 1% ~ (p=1.000 n=17+17) RegexpMatchHard_32-12 1.51µs ± 1% 1.52µs ± 2% +0.46% (p=0.042 n=18+18) RegexpMatchHard_1K-12 45.3µs ± 1% 45.5µs ± 2% +0.44% (p=0.029 n=18+19) Revcomp-12 388ms ± 1% 385ms ± 0% -0.57% (p=0.000 n=19+18) Template-12 63.0ms ± 1% 63.3ms ± 0% +0.50% (p=0.000 n=19+20) TimeParse-12 309ns ± 1% 307ns ± 0% -0.62% (p=0.000 n=20+20) TimeFormat-12 328ns ± 0% 333ns ± 0% +1.35% (p=0.000 n=19+19) [Geo mean] 47.0µs 46.9µs -0.20% (https://perf.golang.org/search?q=upload:20180326.1) For #10958. For #24543. Change-Id: Icbd52e711fdbe7938a1fea3e6baca1104b53ac3a Reviewed-on: https://go-review.googlesource.com/102604 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: David Chase <drchase@google.com>
2018-03-22 12:04:51 -04:00
if n.Op == OFORUNTIL && n.List.Len() != 0 {
mode.Fprintf(s, "; %v", n.List)
}
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, " { %v }", n.Nbody)
case ORANGE:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
if mode == FErr {
fmt.Fprint(s, "for loop")
break
}
if n.List.Len() == 0 {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "for range %v { %v }", n.Right, n.Nbody)
break
}
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "for %.v = range %v { %v }", n.List, n.Right, n.Nbody)
case OSELECT, OSWITCH:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
if mode == FErr {
mode.Fprintf(s, "%v statement", n.Op)
break
}
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "%#v", n.Op)
if simpleinit {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, " %v;", n.Ninit.First())
}
if n.Left != nil {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, " %v ", n.Left)
}
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, " { %v }", n.List)
case OCASE:
if n.List.Len() != 0 {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "case %.v", n.List)
} else {
fmt.Fprint(s, "default")
}
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, ": %v", n.Nbody)
case OBREAK, OCONTINUE, OGOTO, OFALL:
if n.Sym != nil {
mode.Fprintf(s, "%#v %v", n.Op, n.Sym)
} else {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "%#v", n.Op)
}
case OEMPTY:
break
case OLABEL:
mode.Fprintf(s, "%v: ", n.Sym)
}
if extrablock {
fmt.Fprint(s, "}")
}
}
var opprec = []int{
cmd/compile: optimize make+copy pattern to avoid memclr match: m = make([]T, x); copy(m, s) for pointer free T and x==len(s) rewrite to: m = mallocgc(x*elemsize(T), nil, false); memmove(&m, &s, x*elemsize(T)) otherwise rewrite to: m = makeslicecopy([]T, x, s) This avoids memclear and shading of pointers in the newly created slice before the copy. With this CL "s" is only be allowed to bev a variable and not a more complex expression. This restriction could be lifted in future versions of this optimization when it can be proven that "s" is not referencing "m". Triggers 450 times during make.bash.. Reduces go binary size by ~8 kbyte. name old time/op new time/op delta MakeSliceCopy/mallocmove/Byte 71.1ns ± 1% 65.8ns ± 0% -7.49% (p=0.000 n=10+9) MakeSliceCopy/mallocmove/Int 71.2ns ± 1% 66.0ns ± 0% -7.27% (p=0.000 n=10+8) MakeSliceCopy/mallocmove/Ptr 104ns ± 4% 99ns ± 1% -5.13% (p=0.000 n=10+10) MakeSliceCopy/makecopy/Byte 70.3ns ± 0% 68.0ns ± 0% -3.22% (p=0.000 n=10+9) MakeSliceCopy/makecopy/Int 70.3ns ± 0% 68.5ns ± 1% -2.59% (p=0.000 n=9+10) MakeSliceCopy/makecopy/Ptr 102ns ± 0% 99ns ± 1% -2.97% (p=0.000 n=9+9) MakeSliceCopy/nilappend/Byte 75.4ns ± 0% 74.9ns ± 2% -0.63% (p=0.015 n=9+9) MakeSliceCopy/nilappend/Int 75.6ns ± 0% 76.4ns ± 3% ~ (p=0.245 n=9+10) MakeSliceCopy/nilappend/Ptr 107ns ± 0% 108ns ± 1% +0.93% (p=0.005 n=9+10) Fixes #26252 Change-Id: Iec553dd1fef6ded16197216a472351c8799a8e71 Reviewed-on: https://go-review.googlesource.com/c/go/+/146719 Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: Martin Möhrmann <moehrmann@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-10-23 13:50:07 +02:00
OALIGNOF: 8,
OAPPEND: 8,
OBYTES2STR: 8,
OARRAYLIT: 8,
OSLICELIT: 8,
ORUNES2STR: 8,
OCALLFUNC: 8,
OCALLINTER: 8,
OCALLMETH: 8,
OCALL: 8,
OCAP: 8,
OCLOSE: 8,
OCONVIFACE: 8,
OCONVNOP: 8,
OCONV: 8,
OCOPY: 8,
ODELETE: 8,
OGETG: 8,
OLEN: 8,
OLITERAL: 8,
OMAKESLICE: 8,
OMAKESLICECOPY: 8,
OMAKE: 8,
OMAPLIT: 8,
ONAME: 8,
ONEW: 8,
ONONAME: 8,
OOFFSETOF: 8,
OPACK: 8,
OPANIC: 8,
OPAREN: 8,
OPRINTN: 8,
OPRINT: 8,
ORUNESTR: 8,
OSIZEOF: 8,
OSTR2BYTES: 8,
OSTR2RUNES: 8,
OSTRUCTLIT: 8,
OTARRAY: 8,
OTCHAN: 8,
OTFUNC: 8,
OTINTER: 8,
OTMAP: 8,
OTSTRUCT: 8,
OINDEXMAP: 8,
OINDEX: 8,
OSLICE: 8,
OSLICESTR: 8,
OSLICEARR: 8,
OSLICE3: 8,
OSLICE3ARR: 8,
OSLICEHEADER: 8,
ODOTINTER: 8,
ODOTMETH: 8,
ODOTPTR: 8,
ODOTTYPE2: 8,
ODOTTYPE: 8,
ODOT: 8,
OXDOT: 8,
OCALLPART: 8,
OPLUS: 7,
ONOT: 7,
OBITNOT: 7,
ONEG: 7,
OADDR: 7,
ODEREF: 7,
ORECV: 7,
OMUL: 6,
ODIV: 6,
OMOD: 6,
OLSH: 6,
ORSH: 6,
OAND: 6,
OANDNOT: 6,
OADD: 5,
OSUB: 5,
OOR: 5,
OXOR: 5,
OEQ: 4,
OLT: 4,
OLE: 4,
OGE: 4,
OGT: 4,
ONE: 4,
OSEND: 3,
OANDAND: 2,
OOROR: 1,
// Statements handled by stmtfmt
OAS: -1,
OAS2: -1,
OAS2DOTTYPE: -1,
OAS2FUNC: -1,
OAS2MAPR: -1,
OAS2RECV: -1,
OASOP: -1,
OBREAK: -1,
OCASE: -1,
OCONTINUE: -1,
ODCL: -1,
ODCLFIELD: -1,
ODEFER: -1,
OEMPTY: -1,
OFALL: -1,
OFOR: -1,
OFORUNTIL: -1,
OGOTO: -1,
OIF: -1,
OLABEL: -1,
cmd/compile: bulk rename This change does a bulk rename of several identifiers in the compiler. See #27167 and https://docs.google.com/document/d/19_ExiylD9MRfeAjKIfEsMU1_RGhuxB9sA0b5Zv7byVI/ for context and for discussion of these particular renames. Commands run to generate this change: gorename -from '"cmd/compile/internal/gc".OPROC' -to OGO gorename -from '"cmd/compile/internal/gc".OCOM' -to OBITNOT gorename -from '"cmd/compile/internal/gc".OMINUS' -to ONEG gorename -from '"cmd/compile/internal/gc".OIND' -to ODEREF gorename -from '"cmd/compile/internal/gc".OARRAYBYTESTR' -to OBYTES2STR gorename -from '"cmd/compile/internal/gc".OARRAYBYTESTRTMP' -to OBYTES2STRTMP gorename -from '"cmd/compile/internal/gc".OARRAYRUNESTR' -to ORUNES2STR gorename -from '"cmd/compile/internal/gc".OSTRARRAYBYTE' -to OSTR2BYTES gorename -from '"cmd/compile/internal/gc".OSTRARRAYBYTETMP' -to OSTR2BYTESTMP gorename -from '"cmd/compile/internal/gc".OSTRARRAYRUNE' -to OSTR2RUNES gorename -from '"cmd/compile/internal/gc".Etop' -to ctxStmt gorename -from '"cmd/compile/internal/gc".Erv' -to ctxExpr gorename -from '"cmd/compile/internal/gc".Ecall' -to ctxCallee gorename -from '"cmd/compile/internal/gc".Efnstruct' -to ctxMultiOK gorename -from '"cmd/compile/internal/gc".Easgn' -to ctxAssign gorename -from '"cmd/compile/internal/gc".Ecomplit' -to ctxCompLit Not altered: parameters and local variables (mostly in typecheck.go) named top, which should probably now be called ctx (and which should probably have a named type). Also not altered: Field called Top in gc.Func. gorename -from '"cmd/compile/internal/gc".Node.Isddd' -to IsDDD gorename -from '"cmd/compile/internal/gc".Node.SetIsddd' -to SetIsDDD gorename -from '"cmd/compile/internal/gc".nodeIsddd' -to nodeIsDDD gorename -from '"cmd/compile/internal/types".Field.Isddd' -to IsDDD gorename -from '"cmd/compile/internal/types".Field.SetIsddd' -to SetIsDDD gorename -from '"cmd/compile/internal/types".fieldIsddd' -to fieldIsDDD Not altered: function gc.hasddd, params and local variables called isddd Also not altered: fmt.go prints nodes using "isddd(%v)". cd cmd/compile/internal/gc; go generate I then manually found impacted comments using exact string match and fixed them up by hand. The comment changes were trivial. Passes toolstash-check. Fixes #27167. If this experiment is deemed a success, we will open a new tracking issue for renames to do at the end of the 1.13 cycles. Change-Id: I2dc541533d2ab0d06cb3d31d65df205ecfb151e8 Reviewed-on: https://go-review.googlesource.com/c/150140 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2018-11-18 08:34:38 -08:00
OGO: -1,
ORANGE: -1,
ORETURN: -1,
OSELECT: -1,
OSWITCH: -1,
OEND: 0,
}
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
func (n *Node) exprfmt(s fmt.State, prec int, mode fmtMode) {
cmd/compile: bulk rename This change does a bulk rename of several identifiers in the compiler. See #27167 and https://docs.google.com/document/d/19_ExiylD9MRfeAjKIfEsMU1_RGhuxB9sA0b5Zv7byVI/ for context and for discussion of these particular renames. Commands run to generate this change: gorename -from '"cmd/compile/internal/gc".OPROC' -to OGO gorename -from '"cmd/compile/internal/gc".OCOM' -to OBITNOT gorename -from '"cmd/compile/internal/gc".OMINUS' -to ONEG gorename -from '"cmd/compile/internal/gc".OIND' -to ODEREF gorename -from '"cmd/compile/internal/gc".OARRAYBYTESTR' -to OBYTES2STR gorename -from '"cmd/compile/internal/gc".OARRAYBYTESTRTMP' -to OBYTES2STRTMP gorename -from '"cmd/compile/internal/gc".OARRAYRUNESTR' -to ORUNES2STR gorename -from '"cmd/compile/internal/gc".OSTRARRAYBYTE' -to OSTR2BYTES gorename -from '"cmd/compile/internal/gc".OSTRARRAYBYTETMP' -to OSTR2BYTESTMP gorename -from '"cmd/compile/internal/gc".OSTRARRAYRUNE' -to OSTR2RUNES gorename -from '"cmd/compile/internal/gc".Etop' -to ctxStmt gorename -from '"cmd/compile/internal/gc".Erv' -to ctxExpr gorename -from '"cmd/compile/internal/gc".Ecall' -to ctxCallee gorename -from '"cmd/compile/internal/gc".Efnstruct' -to ctxMultiOK gorename -from '"cmd/compile/internal/gc".Easgn' -to ctxAssign gorename -from '"cmd/compile/internal/gc".Ecomplit' -to ctxCompLit Not altered: parameters and local variables (mostly in typecheck.go) named top, which should probably now be called ctx (and which should probably have a named type). Also not altered: Field called Top in gc.Func. gorename -from '"cmd/compile/internal/gc".Node.Isddd' -to IsDDD gorename -from '"cmd/compile/internal/gc".Node.SetIsddd' -to SetIsDDD gorename -from '"cmd/compile/internal/gc".nodeIsddd' -to nodeIsDDD gorename -from '"cmd/compile/internal/types".Field.Isddd' -to IsDDD gorename -from '"cmd/compile/internal/types".Field.SetIsddd' -to SetIsDDD gorename -from '"cmd/compile/internal/types".fieldIsddd' -to fieldIsDDD Not altered: function gc.hasddd, params and local variables called isddd Also not altered: fmt.go prints nodes using "isddd(%v)". cd cmd/compile/internal/gc; go generate I then manually found impacted comments using exact string match and fixed them up by hand. The comment changes were trivial. Passes toolstash-check. Fixes #27167. If this experiment is deemed a success, we will open a new tracking issue for renames to do at the end of the 1.13 cycles. Change-Id: I2dc541533d2ab0d06cb3d31d65df205ecfb151e8 Reviewed-on: https://go-review.googlesource.com/c/150140 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2018-11-18 08:34:38 -08:00
for n != nil && n.Implicit() && (n.Op == ODEREF || n.Op == OADDR) {
n = n.Left
}
if n == nil {
fmt.Fprint(s, "<N>")
return
}
nprec := opprec[n.Op]
if n.Op == OTYPE && n.Sym != nil {
nprec = 8
}
if prec > nprec {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "(%v)", n)
return
}
switch n.Op {
case OPAREN:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "(%v)", n.Left)
case OLITERAL: // this is a bit of a mess
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
if mode == FErr {
if n.Orig != nil && n.Orig != n {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
n.Orig.exprfmt(s, prec, mode)
return
}
if n.Sym != nil {
fmt.Fprint(s, smodeString(n.Sym, mode))
return
}
}
if n.Val().Ctype() == CTNIL && n.Orig != nil && n.Orig != n {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
n.Orig.exprfmt(s, prec, mode)
return
}
if n.Type != nil && !n.Type.IsUntyped() {
// Need parens when type begins with what might
// be misinterpreted as a unary operator: * or <-.
if n.Type.IsPtr() || (n.Type.IsChan() && n.Type.ChanDir() == types.Crecv) {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "(%v)(%v)", n.Type, n.Val())
return
} else {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "%v(%v)", n.Type, n.Val())
return
}
}
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "%v", n.Val())
// Special case: name used as local variable in export.
// _ becomes ~b%d internally; print as _ for export
case ONAME:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
if mode == FErr && n.Sym != nil && n.Sym.Name[0] == '~' && n.Sym.Name[1] == 'b' {
fmt.Fprint(s, "_")
return
}
fallthrough
case OPACK, ONONAME:
fmt.Fprint(s, smodeString(n.Sym, mode))
case OTYPE:
if n.Type == nil && n.Sym != nil {
fmt.Fprint(s, smodeString(n.Sym, mode))
return
}
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "%v", n.Type)
case OTARRAY:
if n.Left != nil {
mode.Fprintf(s, "[%v]%v", n.Left, n.Right)
return
}
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "[]%v", n.Right) // happens before typecheck
case OTMAP:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "map[%v]%v", n.Left, n.Right)
case OTCHAN:
switch n.TChanDir() {
case types.Crecv:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "<-chan %v", n.Left)
case types.Csend:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "chan<- %v", n.Left)
default:
if n.Left != nil && n.Left.Op == OTCHAN && n.Left.Sym == nil && n.Left.TChanDir() == types.Crecv {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "chan (%v)", n.Left)
} else {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "chan %v", n.Left)
}
}
case OTSTRUCT:
fmt.Fprint(s, "<struct>")
case OTINTER:
fmt.Fprint(s, "<inter>")
case OTFUNC:
fmt.Fprint(s, "<func>")
case OCLOSURE:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
if mode == FErr {
fmt.Fprint(s, "func literal")
return
}
if n.Nbody.Len() != 0 {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "%v { %v }", n.Type, n.Nbody)
return
}
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "%v { %v }", n.Type, n.Func.Closure.Nbody)
case OCOMPLIT:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
if mode == FErr {
cmd/compile: use fixVariadicCall in escape analysis This CL uses fixVariadicCall before escape analyzing function calls. This has a number of benefits, though also some minor obstacles: Most notably, it allows us to remove ODDDARG along with the logic involved in setting it up, manipulating EscHoles, and later copying its escape analysis flags to the actual slice argument. Instead, we uniformly handle all variadic calls the same way. (E.g., issue31573.go is updated because now f() and f(nil...) are handled identically.) It also allows us to simplify handling of builtins and generic function calls. Previously handling of calls was hairy enough to require multiple dispatches on n.Op, whereas now the logic is uniform enough that we can easily handle it with a single dispatch. The downside is handling //go:uintptrescapes is now somewhat clumsy. (It used to be clumsy, but it still is, too.) The proper fix here is probably to stop using escape analysis tags for //go:uintptrescapes and unsafe-uintptr, and have an earlier pass responsible for them. Finally, note that while we now call fixVariadicCall in Escape, we still have to call it in Order, because we don't (yet) run Escape on all compiler-generated functions. In particular, the generated "init" function for initializing package-level variables can contain calls to variadic functions and isn't escape analyzed. Passes toolstash-check -race. Change-Id: I4cdb92a393ac487910aeee58a5cb8c1500eef881 Reviewed-on: https://go-review.googlesource.com/c/go/+/229759 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2020-04-21 19:48:02 -07:00
if n.Implicit() {
mode.Fprintf(s, "... argument")
return
}
if n.Right != nil {
mode.Fprintf(s, "%v{%s}", n.Right, ellipsisIf(n.List.Len() != 0))
return
}
fmt.Fprint(s, "composite literal")
return
}
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "(%v{ %.v })", n.Right, n.List)
case OPTRLIT:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "&%v", n.Left)
case OSTRUCTLIT, OARRAYLIT, OSLICELIT, OMAPLIT:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
if mode == FErr {
mode.Fprintf(s, "%v{%s}", n.Type, ellipsisIf(n.List.Len() != 0))
return
}
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "(%v{ %.v })", n.Type, n.List)
case OKEY:
if n.Left != nil && n.Right != nil {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "%v:%v", n.Left, n.Right)
return
}
if n.Left == nil && n.Right != nil {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, ":%v", n.Right)
return
}
if n.Left != nil && n.Right == nil {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "%v:", n.Left)
return
}
fmt.Fprint(s, ":")
cmd/compile: add OSTRUCTKEY for keyed struct literals Previously, we used OKEY nodes to represent keyed struct literal elements. The field names were represented by an ONAME node, but this is clumsy because it's the only remaining case where ONAME was used to represent a bare identifier and not a variable. This CL introduces a new OSTRUCTKEY node op for use in struct literals. These ops instead store the field name in the node's own Sym field. This is similar in spirit to golang.org/cl/20890. Significant reduction in allocations for struct literal heavy code like package unicode: name old time/op new time/op delta Template 345ms ± 6% 341ms ± 6% ~ (p=0.141 n=29+28) Unicode 200ms ± 9% 184ms ± 7% -7.77% (p=0.000 n=29+30) GoTypes 1.04s ± 3% 1.05s ± 3% ~ (p=0.096 n=30+30) Compiler 4.47s ± 9% 4.49s ± 6% ~ (p=0.890 n=29+29) name old user-ns/op new user-ns/op delta Template 523M ±13% 516M ±17% ~ (p=0.400 n=29+30) Unicode 334M ±27% 314M ±30% ~ (p=0.093 n=30+30) GoTypes 1.53G ±10% 1.52G ±10% ~ (p=0.572 n=30+30) Compiler 6.28G ± 7% 6.34G ±11% ~ (p=0.300 n=30+30) name old alloc/op new alloc/op delta Template 44.5MB ± 0% 44.4MB ± 0% -0.35% (p=0.000 n=27+30) Unicode 39.2MB ± 0% 34.5MB ± 0% -11.79% (p=0.000 n=26+30) GoTypes 125MB ± 0% 125MB ± 0% -0.12% (p=0.000 n=29+30) Compiler 515MB ± 0% 515MB ± 0% -0.10% (p=0.000 n=29+30) name old allocs/op new allocs/op delta Template 426k ± 0% 424k ± 0% -0.39% (p=0.000 n=29+30) Unicode 374k ± 0% 323k ± 0% -13.67% (p=0.000 n=29+30) GoTypes 1.21M ± 0% 1.21M ± 0% -0.14% (p=0.000 n=29+29) Compiler 4.40M ± 0% 4.39M ± 0% -0.13% (p=0.000 n=29+30) Passes toolstash/buildall. Change-Id: Iba4ee765dd1748f67e52fcade1cd75c9f6e13fa9 Reviewed-on: https://go-review.googlesource.com/30974 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2016-10-12 15:48:18 -07:00
case OSTRUCTKEY:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "%v:%v", n.Sym, n.Left)
cmd/compile: add OSTRUCTKEY for keyed struct literals Previously, we used OKEY nodes to represent keyed struct literal elements. The field names were represented by an ONAME node, but this is clumsy because it's the only remaining case where ONAME was used to represent a bare identifier and not a variable. This CL introduces a new OSTRUCTKEY node op for use in struct literals. These ops instead store the field name in the node's own Sym field. This is similar in spirit to golang.org/cl/20890. Significant reduction in allocations for struct literal heavy code like package unicode: name old time/op new time/op delta Template 345ms ± 6% 341ms ± 6% ~ (p=0.141 n=29+28) Unicode 200ms ± 9% 184ms ± 7% -7.77% (p=0.000 n=29+30) GoTypes 1.04s ± 3% 1.05s ± 3% ~ (p=0.096 n=30+30) Compiler 4.47s ± 9% 4.49s ± 6% ~ (p=0.890 n=29+29) name old user-ns/op new user-ns/op delta Template 523M ±13% 516M ±17% ~ (p=0.400 n=29+30) Unicode 334M ±27% 314M ±30% ~ (p=0.093 n=30+30) GoTypes 1.53G ±10% 1.52G ±10% ~ (p=0.572 n=30+30) Compiler 6.28G ± 7% 6.34G ±11% ~ (p=0.300 n=30+30) name old alloc/op new alloc/op delta Template 44.5MB ± 0% 44.4MB ± 0% -0.35% (p=0.000 n=27+30) Unicode 39.2MB ± 0% 34.5MB ± 0% -11.79% (p=0.000 n=26+30) GoTypes 125MB ± 0% 125MB ± 0% -0.12% (p=0.000 n=29+30) Compiler 515MB ± 0% 515MB ± 0% -0.10% (p=0.000 n=29+30) name old allocs/op new allocs/op delta Template 426k ± 0% 424k ± 0% -0.39% (p=0.000 n=29+30) Unicode 374k ± 0% 323k ± 0% -13.67% (p=0.000 n=29+30) GoTypes 1.21M ± 0% 1.21M ± 0% -0.14% (p=0.000 n=29+29) Compiler 4.40M ± 0% 4.39M ± 0% -0.13% (p=0.000 n=29+30) Passes toolstash/buildall. Change-Id: Iba4ee765dd1748f67e52fcade1cd75c9f6e13fa9 Reviewed-on: https://go-review.googlesource.com/30974 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2016-10-12 15:48:18 -07:00
case OCALLPART:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
n.Left.exprfmt(s, nprec, mode)
if n.Right == nil || n.Right.Sym == nil {
fmt.Fprint(s, ".<nil>")
return
}
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, ".%0S", n.Right.Sym)
case OXDOT, ODOT, ODOTPTR, ODOTINTER, ODOTMETH:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
n.Left.exprfmt(s, nprec, mode)
if n.Sym == nil {
fmt.Fprint(s, ".<nil>")
return
}
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, ".%0S", n.Sym)
case ODOTTYPE, ODOTTYPE2:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
n.Left.exprfmt(s, nprec, mode)
if n.Right != nil {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, ".(%v)", n.Right)
return
}
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, ".(%v)", n.Type)
case OINDEX, OINDEXMAP:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
n.Left.exprfmt(s, nprec, mode)
mode.Fprintf(s, "[%v]", n.Right)
case OSLICE, OSLICESTR, OSLICEARR, OSLICE3, OSLICE3ARR:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
n.Left.exprfmt(s, nprec, mode)
fmt.Fprint(s, "[")
low, high, max := n.SliceBounds()
if low != nil {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
fmt.Fprint(s, low.modeString(mode))
}
fmt.Fprint(s, ":")
if high != nil {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
fmt.Fprint(s, high.modeString(mode))
}
if n.Op.IsSlice3() {
fmt.Fprint(s, ":")
if max != nil {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
fmt.Fprint(s, max.modeString(mode))
}
}
fmt.Fprint(s, "]")
case OSLICEHEADER:
if n.List.Len() != 2 {
Fatalf("bad OSLICEHEADER list length %d", n.List.Len())
}
mode.Fprintf(s, "sliceheader{%v,%v,%v}", n.Left, n.List.First(), n.List.Second())
cmd/compile: rewrite f(g()) for multi-value g() during typecheck This is a re-attempt at CL 153841, which caused two regressions: 1. crypto/ecdsa failed to build with -gcflags=-l=4. This was because when "t1, t2, ... := g(); f(t1, t2, ...)" was exported, we were losing the first assignment from the call's Ninit field. 2. net/http/pprof failed to run with -gcflags=-N. This is due to a conflict with CL 159717: as of that CL, package-scope initialization statements are executed within the "init.ializer" function, rather than the "init" function, and the generated temp variables need to be moved accordingly too. [Rest of description is as before.] This CL moves order.go's copyRet logic for rewriting f(g()) into t1, t2, ... := g(); f(t1, t2, ...) earlier into typecheck. This allows the rest of the compiler to stop worrying about multi-value functions appearing outside of OAS2FUNC nodes. This changes compiler behavior in a few observable ways: 1. Typechecking error messages for builtin functions now use general case error messages rather than unnecessarily differing ones. 2. Because f(g()) is rewritten before inlining, saved inline bodies now see the rewritten form too. This could be addressed, but doesn't seem worthwhile. 3. Most notably, this simplifies escape analysis and fixes a memory corruption issue in esc.go. See #29197 for details. Fixes #15992. Fixes #29197. Change-Id: I930b10f7e27af68a0944d6c9bfc8707c3fab27a4 Reviewed-on: https://go-review.googlesource.com/c/go/+/166983 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2018-12-12 11:15:37 -08:00
case OCOMPLEX, OCOPY:
if n.Left != nil {
mode.Fprintf(s, "%#v(%v, %v)", n.Op, n.Left, n.Right)
cmd/compile: rewrite f(g()) for multi-value g() during typecheck This is a re-attempt at CL 153841, which caused two regressions: 1. crypto/ecdsa failed to build with -gcflags=-l=4. This was because when "t1, t2, ... := g(); f(t1, t2, ...)" was exported, we were losing the first assignment from the call's Ninit field. 2. net/http/pprof failed to run with -gcflags=-N. This is due to a conflict with CL 159717: as of that CL, package-scope initialization statements are executed within the "init.ializer" function, rather than the "init" function, and the generated temp variables need to be moved accordingly too. [Rest of description is as before.] This CL moves order.go's copyRet logic for rewriting f(g()) into t1, t2, ... := g(); f(t1, t2, ...) earlier into typecheck. This allows the rest of the compiler to stop worrying about multi-value functions appearing outside of OAS2FUNC nodes. This changes compiler behavior in a few observable ways: 1. Typechecking error messages for builtin functions now use general case error messages rather than unnecessarily differing ones. 2. Because f(g()) is rewritten before inlining, saved inline bodies now see the rewritten form too. This could be addressed, but doesn't seem worthwhile. 3. Most notably, this simplifies escape analysis and fixes a memory corruption issue in esc.go. See #29197 for details. Fixes #15992. Fixes #29197. Change-Id: I930b10f7e27af68a0944d6c9bfc8707c3fab27a4 Reviewed-on: https://go-review.googlesource.com/c/go/+/166983 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2018-12-12 11:15:37 -08:00
} else {
mode.Fprintf(s, "%#v(%.v)", n.Op, n.List)
}
case OCONV,
OCONVIFACE,
OCONVNOP,
cmd/compile: bulk rename This change does a bulk rename of several identifiers in the compiler. See #27167 and https://docs.google.com/document/d/19_ExiylD9MRfeAjKIfEsMU1_RGhuxB9sA0b5Zv7byVI/ for context and for discussion of these particular renames. Commands run to generate this change: gorename -from '"cmd/compile/internal/gc".OPROC' -to OGO gorename -from '"cmd/compile/internal/gc".OCOM' -to OBITNOT gorename -from '"cmd/compile/internal/gc".OMINUS' -to ONEG gorename -from '"cmd/compile/internal/gc".OIND' -to ODEREF gorename -from '"cmd/compile/internal/gc".OARRAYBYTESTR' -to OBYTES2STR gorename -from '"cmd/compile/internal/gc".OARRAYBYTESTRTMP' -to OBYTES2STRTMP gorename -from '"cmd/compile/internal/gc".OARRAYRUNESTR' -to ORUNES2STR gorename -from '"cmd/compile/internal/gc".OSTRARRAYBYTE' -to OSTR2BYTES gorename -from '"cmd/compile/internal/gc".OSTRARRAYBYTETMP' -to OSTR2BYTESTMP gorename -from '"cmd/compile/internal/gc".OSTRARRAYRUNE' -to OSTR2RUNES gorename -from '"cmd/compile/internal/gc".Etop' -to ctxStmt gorename -from '"cmd/compile/internal/gc".Erv' -to ctxExpr gorename -from '"cmd/compile/internal/gc".Ecall' -to ctxCallee gorename -from '"cmd/compile/internal/gc".Efnstruct' -to ctxMultiOK gorename -from '"cmd/compile/internal/gc".Easgn' -to ctxAssign gorename -from '"cmd/compile/internal/gc".Ecomplit' -to ctxCompLit Not altered: parameters and local variables (mostly in typecheck.go) named top, which should probably now be called ctx (and which should probably have a named type). Also not altered: Field called Top in gc.Func. gorename -from '"cmd/compile/internal/gc".Node.Isddd' -to IsDDD gorename -from '"cmd/compile/internal/gc".Node.SetIsddd' -to SetIsDDD gorename -from '"cmd/compile/internal/gc".nodeIsddd' -to nodeIsDDD gorename -from '"cmd/compile/internal/types".Field.Isddd' -to IsDDD gorename -from '"cmd/compile/internal/types".Field.SetIsddd' -to SetIsDDD gorename -from '"cmd/compile/internal/types".fieldIsddd' -to fieldIsDDD Not altered: function gc.hasddd, params and local variables called isddd Also not altered: fmt.go prints nodes using "isddd(%v)". cd cmd/compile/internal/gc; go generate I then manually found impacted comments using exact string match and fixed them up by hand. The comment changes were trivial. Passes toolstash-check. Fixes #27167. If this experiment is deemed a success, we will open a new tracking issue for renames to do at the end of the 1.13 cycles. Change-Id: I2dc541533d2ab0d06cb3d31d65df205ecfb151e8 Reviewed-on: https://go-review.googlesource.com/c/150140 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2018-11-18 08:34:38 -08:00
OBYTES2STR,
ORUNES2STR,
OSTR2BYTES,
OSTR2RUNES,
ORUNESTR:
if n.Type == nil || n.Type.Sym == nil {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "(%v)", n.Type)
} else {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "%v", n.Type)
}
if n.Left != nil {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "(%v)", n.Left)
} else {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "(%.v)", n.List)
}
case OREAL,
OIMAG,
OAPPEND,
OCAP,
OCLOSE,
ODELETE,
OLEN,
OMAKE,
ONEW,
OPANIC,
ORECOVER,
OALIGNOF,
OOFFSETOF,
OSIZEOF,
OPRINT,
OPRINTN:
if n.Left != nil {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "%#v(%v)", n.Op, n.Left)
return
}
cmd/compile: bulk rename This change does a bulk rename of several identifiers in the compiler. See #27167 and https://docs.google.com/document/d/19_ExiylD9MRfeAjKIfEsMU1_RGhuxB9sA0b5Zv7byVI/ for context and for discussion of these particular renames. Commands run to generate this change: gorename -from '"cmd/compile/internal/gc".OPROC' -to OGO gorename -from '"cmd/compile/internal/gc".OCOM' -to OBITNOT gorename -from '"cmd/compile/internal/gc".OMINUS' -to ONEG gorename -from '"cmd/compile/internal/gc".OIND' -to ODEREF gorename -from '"cmd/compile/internal/gc".OARRAYBYTESTR' -to OBYTES2STR gorename -from '"cmd/compile/internal/gc".OARRAYBYTESTRTMP' -to OBYTES2STRTMP gorename -from '"cmd/compile/internal/gc".OARRAYRUNESTR' -to ORUNES2STR gorename -from '"cmd/compile/internal/gc".OSTRARRAYBYTE' -to OSTR2BYTES gorename -from '"cmd/compile/internal/gc".OSTRARRAYBYTETMP' -to OSTR2BYTESTMP gorename -from '"cmd/compile/internal/gc".OSTRARRAYRUNE' -to OSTR2RUNES gorename -from '"cmd/compile/internal/gc".Etop' -to ctxStmt gorename -from '"cmd/compile/internal/gc".Erv' -to ctxExpr gorename -from '"cmd/compile/internal/gc".Ecall' -to ctxCallee gorename -from '"cmd/compile/internal/gc".Efnstruct' -to ctxMultiOK gorename -from '"cmd/compile/internal/gc".Easgn' -to ctxAssign gorename -from '"cmd/compile/internal/gc".Ecomplit' -to ctxCompLit Not altered: parameters and local variables (mostly in typecheck.go) named top, which should probably now be called ctx (and which should probably have a named type). Also not altered: Field called Top in gc.Func. gorename -from '"cmd/compile/internal/gc".Node.Isddd' -to IsDDD gorename -from '"cmd/compile/internal/gc".Node.SetIsddd' -to SetIsDDD gorename -from '"cmd/compile/internal/gc".nodeIsddd' -to nodeIsDDD gorename -from '"cmd/compile/internal/types".Field.Isddd' -to IsDDD gorename -from '"cmd/compile/internal/types".Field.SetIsddd' -to SetIsDDD gorename -from '"cmd/compile/internal/types".fieldIsddd' -to fieldIsDDD Not altered: function gc.hasddd, params and local variables called isddd Also not altered: fmt.go prints nodes using "isddd(%v)". cd cmd/compile/internal/gc; go generate I then manually found impacted comments using exact string match and fixed them up by hand. The comment changes were trivial. Passes toolstash-check. Fixes #27167. If this experiment is deemed a success, we will open a new tracking issue for renames to do at the end of the 1.13 cycles. Change-Id: I2dc541533d2ab0d06cb3d31d65df205ecfb151e8 Reviewed-on: https://go-review.googlesource.com/c/150140 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2018-11-18 08:34:38 -08:00
if n.IsDDD() {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "%#v(%.v...)", n.Op, n.List)
return
}
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "%#v(%.v)", n.Op, n.List)
cmd/internal/gc: inline runtime.getg This more closely restores what the old C runtime did. (In C, g was an 'extern register' with the same effective implementation as in this CL.) On a late 2012 MacBookPro10,2, best of 5 old vs best of 5 new: benchmark old ns/op new ns/op delta BenchmarkBinaryTree17 4981312777 4463426605 -10.40% BenchmarkFannkuch11 3046495712 3006819428 -1.30% BenchmarkFmtFprintfEmpty 89.3 79.8 -10.64% BenchmarkFmtFprintfString 284 262 -7.75% BenchmarkFmtFprintfInt 282 262 -7.09% BenchmarkFmtFprintfIntInt 480 448 -6.67% BenchmarkFmtFprintfPrefixedInt 382 358 -6.28% BenchmarkFmtFprintfFloat 529 486 -8.13% BenchmarkFmtManyArgs 1849 1773 -4.11% BenchmarkGobDecode 12835963 11794385 -8.11% BenchmarkGobEncode 10527170 10288422 -2.27% BenchmarkGzip 436109569 438422516 +0.53% BenchmarkGunzip 110121663 109843648 -0.25% BenchmarkHTTPClientServer 81930 85446 +4.29% BenchmarkJSONEncode 24638574 24280603 -1.45% BenchmarkJSONDecode 93022423 85753546 -7.81% BenchmarkMandelbrot200 4703899 4735407 +0.67% BenchmarkGoParse 5319853 5086843 -4.38% BenchmarkRegexpMatchEasy0_32 151 151 +0.00% BenchmarkRegexpMatchEasy0_1K 452 453 +0.22% BenchmarkRegexpMatchEasy1_32 131 132 +0.76% BenchmarkRegexpMatchEasy1_1K 761 722 -5.12% BenchmarkRegexpMatchMedium_32 228 224 -1.75% BenchmarkRegexpMatchMedium_1K 63751 64296 +0.85% BenchmarkRegexpMatchHard_32 3188 3238 +1.57% BenchmarkRegexpMatchHard_1K 95396 96756 +1.43% BenchmarkRevcomp 661587262 687107364 +3.86% BenchmarkTemplate 108312598 104008540 -3.97% BenchmarkTimeParse 453 459 +1.32% BenchmarkTimeFormat 475 441 -7.16% The garbage benchmark from the benchmarks subrepo gets 2.6% faster as well. Change-Id: I320aeda332db81012688b26ffab23f6581c59cfa Reviewed-on: https://go-review.googlesource.com/8460 Reviewed-by: Rick Hudson <rlh@golang.org> Run-TryBot: Rick Hudson <rlh@golang.org> Reviewed-by: Austin Clements <austin@google.com>
2015-04-03 12:23:28 -04:00
case OCALL, OCALLFUNC, OCALLINTER, OCALLMETH, OGETG:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
n.Left.exprfmt(s, nprec, mode)
cmd/compile: bulk rename This change does a bulk rename of several identifiers in the compiler. See #27167 and https://docs.google.com/document/d/19_ExiylD9MRfeAjKIfEsMU1_RGhuxB9sA0b5Zv7byVI/ for context and for discussion of these particular renames. Commands run to generate this change: gorename -from '"cmd/compile/internal/gc".OPROC' -to OGO gorename -from '"cmd/compile/internal/gc".OCOM' -to OBITNOT gorename -from '"cmd/compile/internal/gc".OMINUS' -to ONEG gorename -from '"cmd/compile/internal/gc".OIND' -to ODEREF gorename -from '"cmd/compile/internal/gc".OARRAYBYTESTR' -to OBYTES2STR gorename -from '"cmd/compile/internal/gc".OARRAYBYTESTRTMP' -to OBYTES2STRTMP gorename -from '"cmd/compile/internal/gc".OARRAYRUNESTR' -to ORUNES2STR gorename -from '"cmd/compile/internal/gc".OSTRARRAYBYTE' -to OSTR2BYTES gorename -from '"cmd/compile/internal/gc".OSTRARRAYBYTETMP' -to OSTR2BYTESTMP gorename -from '"cmd/compile/internal/gc".OSTRARRAYRUNE' -to OSTR2RUNES gorename -from '"cmd/compile/internal/gc".Etop' -to ctxStmt gorename -from '"cmd/compile/internal/gc".Erv' -to ctxExpr gorename -from '"cmd/compile/internal/gc".Ecall' -to ctxCallee gorename -from '"cmd/compile/internal/gc".Efnstruct' -to ctxMultiOK gorename -from '"cmd/compile/internal/gc".Easgn' -to ctxAssign gorename -from '"cmd/compile/internal/gc".Ecomplit' -to ctxCompLit Not altered: parameters and local variables (mostly in typecheck.go) named top, which should probably now be called ctx (and which should probably have a named type). Also not altered: Field called Top in gc.Func. gorename -from '"cmd/compile/internal/gc".Node.Isddd' -to IsDDD gorename -from '"cmd/compile/internal/gc".Node.SetIsddd' -to SetIsDDD gorename -from '"cmd/compile/internal/gc".nodeIsddd' -to nodeIsDDD gorename -from '"cmd/compile/internal/types".Field.Isddd' -to IsDDD gorename -from '"cmd/compile/internal/types".Field.SetIsddd' -to SetIsDDD gorename -from '"cmd/compile/internal/types".fieldIsddd' -to fieldIsDDD Not altered: function gc.hasddd, params and local variables called isddd Also not altered: fmt.go prints nodes using "isddd(%v)". cd cmd/compile/internal/gc; go generate I then manually found impacted comments using exact string match and fixed them up by hand. The comment changes were trivial. Passes toolstash-check. Fixes #27167. If this experiment is deemed a success, we will open a new tracking issue for renames to do at the end of the 1.13 cycles. Change-Id: I2dc541533d2ab0d06cb3d31d65df205ecfb151e8 Reviewed-on: https://go-review.googlesource.com/c/150140 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2018-11-18 08:34:38 -08:00
if n.IsDDD() {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "(%.v...)", n.List)
return
}
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "(%.v)", n.List)
case OMAKEMAP, OMAKECHAN, OMAKESLICE:
if n.List.Len() != 0 { // pre-typecheck
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "make(%v, %.v)", n.Type, n.List)
return
}
if n.Right != nil {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "make(%v, %v, %v)", n.Type, n.Left, n.Right)
return
}
if n.Left != nil && (n.Op == OMAKESLICE || !n.Left.Type.IsUntyped()) {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "make(%v, %v)", n.Type, n.Left)
return
}
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "make(%v)", n.Type)
cmd/compile: optimize make+copy pattern to avoid memclr match: m = make([]T, x); copy(m, s) for pointer free T and x==len(s) rewrite to: m = mallocgc(x*elemsize(T), nil, false); memmove(&m, &s, x*elemsize(T)) otherwise rewrite to: m = makeslicecopy([]T, x, s) This avoids memclear and shading of pointers in the newly created slice before the copy. With this CL "s" is only be allowed to bev a variable and not a more complex expression. This restriction could be lifted in future versions of this optimization when it can be proven that "s" is not referencing "m". Triggers 450 times during make.bash.. Reduces go binary size by ~8 kbyte. name old time/op new time/op delta MakeSliceCopy/mallocmove/Byte 71.1ns ± 1% 65.8ns ± 0% -7.49% (p=0.000 n=10+9) MakeSliceCopy/mallocmove/Int 71.2ns ± 1% 66.0ns ± 0% -7.27% (p=0.000 n=10+8) MakeSliceCopy/mallocmove/Ptr 104ns ± 4% 99ns ± 1% -5.13% (p=0.000 n=10+10) MakeSliceCopy/makecopy/Byte 70.3ns ± 0% 68.0ns ± 0% -3.22% (p=0.000 n=10+9) MakeSliceCopy/makecopy/Int 70.3ns ± 0% 68.5ns ± 1% -2.59% (p=0.000 n=9+10) MakeSliceCopy/makecopy/Ptr 102ns ± 0% 99ns ± 1% -2.97% (p=0.000 n=9+9) MakeSliceCopy/nilappend/Byte 75.4ns ± 0% 74.9ns ± 2% -0.63% (p=0.015 n=9+9) MakeSliceCopy/nilappend/Int 75.6ns ± 0% 76.4ns ± 3% ~ (p=0.245 n=9+10) MakeSliceCopy/nilappend/Ptr 107ns ± 0% 108ns ± 1% +0.93% (p=0.005 n=9+10) Fixes #26252 Change-Id: Iec553dd1fef6ded16197216a472351c8799a8e71 Reviewed-on: https://go-review.googlesource.com/c/go/+/146719 Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: Martin Möhrmann <moehrmann@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-10-23 13:50:07 +02:00
case OMAKESLICECOPY:
mode.Fprintf(s, "makeslicecopy(%v, %v, %v)", n.Type, n.Left, n.Right)
cmd/compile: bulk rename This change does a bulk rename of several identifiers in the compiler. See #27167 and https://docs.google.com/document/d/19_ExiylD9MRfeAjKIfEsMU1_RGhuxB9sA0b5Zv7byVI/ for context and for discussion of these particular renames. Commands run to generate this change: gorename -from '"cmd/compile/internal/gc".OPROC' -to OGO gorename -from '"cmd/compile/internal/gc".OCOM' -to OBITNOT gorename -from '"cmd/compile/internal/gc".OMINUS' -to ONEG gorename -from '"cmd/compile/internal/gc".OIND' -to ODEREF gorename -from '"cmd/compile/internal/gc".OARRAYBYTESTR' -to OBYTES2STR gorename -from '"cmd/compile/internal/gc".OARRAYBYTESTRTMP' -to OBYTES2STRTMP gorename -from '"cmd/compile/internal/gc".OARRAYRUNESTR' -to ORUNES2STR gorename -from '"cmd/compile/internal/gc".OSTRARRAYBYTE' -to OSTR2BYTES gorename -from '"cmd/compile/internal/gc".OSTRARRAYBYTETMP' -to OSTR2BYTESTMP gorename -from '"cmd/compile/internal/gc".OSTRARRAYRUNE' -to OSTR2RUNES gorename -from '"cmd/compile/internal/gc".Etop' -to ctxStmt gorename -from '"cmd/compile/internal/gc".Erv' -to ctxExpr gorename -from '"cmd/compile/internal/gc".Ecall' -to ctxCallee gorename -from '"cmd/compile/internal/gc".Efnstruct' -to ctxMultiOK gorename -from '"cmd/compile/internal/gc".Easgn' -to ctxAssign gorename -from '"cmd/compile/internal/gc".Ecomplit' -to ctxCompLit Not altered: parameters and local variables (mostly in typecheck.go) named top, which should probably now be called ctx (and which should probably have a named type). Also not altered: Field called Top in gc.Func. gorename -from '"cmd/compile/internal/gc".Node.Isddd' -to IsDDD gorename -from '"cmd/compile/internal/gc".Node.SetIsddd' -to SetIsDDD gorename -from '"cmd/compile/internal/gc".nodeIsddd' -to nodeIsDDD gorename -from '"cmd/compile/internal/types".Field.Isddd' -to IsDDD gorename -from '"cmd/compile/internal/types".Field.SetIsddd' -to SetIsDDD gorename -from '"cmd/compile/internal/types".fieldIsddd' -to fieldIsDDD Not altered: function gc.hasddd, params and local variables called isddd Also not altered: fmt.go prints nodes using "isddd(%v)". cd cmd/compile/internal/gc; go generate I then manually found impacted comments using exact string match and fixed them up by hand. The comment changes were trivial. Passes toolstash-check. Fixes #27167. If this experiment is deemed a success, we will open a new tracking issue for renames to do at the end of the 1.13 cycles. Change-Id: I2dc541533d2ab0d06cb3d31d65df205ecfb151e8 Reviewed-on: https://go-review.googlesource.com/c/150140 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2018-11-18 08:34:38 -08:00
case OPLUS, ONEG, OADDR, OBITNOT, ODEREF, ONOT, ORECV:
// Unary
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "%#v", n.Op)
if n.Left != nil && n.Left.Op == n.Op {
fmt.Fprint(s, " ")
}
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
n.Left.exprfmt(s, nprec+1, mode)
// Binary
case OADD,
OAND,
OANDAND,
OANDNOT,
ODIV,
OEQ,
OGE,
OGT,
OLE,
OLT,
OLSH,
OMOD,
OMUL,
ONE,
OOR,
OOROR,
ORSH,
OSEND,
OSUB,
OXOR:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
n.Left.exprfmt(s, nprec, mode)
mode.Fprintf(s, " %#v ", n.Op)
n.Right.exprfmt(s, nprec+1, mode)
case OADDSTR:
for i, n1 := range n.List.Slice() {
if i != 0 {
fmt.Fprint(s, " + ")
}
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
n1.exprfmt(s, nprec, mode)
}
case ODDD:
mode.Fprintf(s, "...")
default:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "<node %v>", n.Op)
}
}
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
func (n *Node) nodefmt(s fmt.State, flag FmtFlag, mode fmtMode) {
t := n.Type
// We almost always want the original.
// TODO(gri) Why the special case for OLITERAL?
if n.Op != OLITERAL && n.Orig != nil {
n = n.Orig
}
if flag&FmtLong != 0 && t != nil {
if t.Etype == TNIL {
fmt.Fprint(s, "nil")
cmd/compile: rewrite f(g()) for multi-value g() during typecheck This is a re-attempt at CL 153841, which caused two regressions: 1. crypto/ecdsa failed to build with -gcflags=-l=4. This was because when "t1, t2, ... := g(); f(t1, t2, ...)" was exported, we were losing the first assignment from the call's Ninit field. 2. net/http/pprof failed to run with -gcflags=-N. This is due to a conflict with CL 159717: as of that CL, package-scope initialization statements are executed within the "init.ializer" function, rather than the "init" function, and the generated temp variables need to be moved accordingly too. [Rest of description is as before.] This CL moves order.go's copyRet logic for rewriting f(g()) into t1, t2, ... := g(); f(t1, t2, ...) earlier into typecheck. This allows the rest of the compiler to stop worrying about multi-value functions appearing outside of OAS2FUNC nodes. This changes compiler behavior in a few observable ways: 1. Typechecking error messages for builtin functions now use general case error messages rather than unnecessarily differing ones. 2. Because f(g()) is rewritten before inlining, saved inline bodies now see the rewritten form too. This could be addressed, but doesn't seem worthwhile. 3. Most notably, this simplifies escape analysis and fixes a memory corruption issue in esc.go. See #29197 for details. Fixes #15992. Fixes #29197. Change-Id: I930b10f7e27af68a0944d6c9bfc8707c3fab27a4 Reviewed-on: https://go-review.googlesource.com/c/go/+/166983 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2018-12-12 11:15:37 -08:00
} else if n.Op == ONAME && n.Name.AutoTemp() {
mode.Fprintf(s, "%v value", t)
} else {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "%v (type %v)", n, t)
}
return
}
// TODO inlining produces expressions with ninits. we can't print these yet.
if opprec[n.Op] < 0 {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
n.stmtfmt(s, mode)
return
}
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
n.exprfmt(s, 0, mode)
}
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
func (n *Node) nodedump(s fmt.State, flag FmtFlag, mode fmtMode) {
recur := flag&FmtShort == 0
if recur {
indent(s)
if dumpdepth > 40 {
fmt.Fprint(s, "...")
return
}
if n.Ninit.Len() != 0 {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "%v-init%v", n.Op, n.Ninit)
indent(s)
}
}
switch n.Op {
default:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "%v%j", n.Op, n)
case OLITERAL:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "%v-%v%j", n.Op, n.Val(), n)
case ONAME, ONONAME:
if n.Sym != nil {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "%v-%v%j", n.Op, n.Sym, n)
} else {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "%v%j", n.Op, n)
}
if recur && n.Type == nil && n.Name != nil && n.Name.Param != nil && n.Name.Param.Ntype != nil {
indent(s)
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "%v-ntype%v", n.Op, n.Name.Param.Ntype)
}
case OASOP:
mode.Fprintf(s, "%v-%v%j", n.Op, n.SubOp(), n)
case OTYPE:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "%v %v%j type=%v", n.Op, n.Sym, n, n.Type)
if recur && n.Type == nil && n.Name != nil && n.Name.Param != nil && n.Name.Param.Ntype != nil {
indent(s)
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "%v-ntype%v", n.Op, n.Name.Param.Ntype)
}
}
if n.Op == OCLOSURE && n.Func.Closure != nil && n.Func.Closure.Func.Nname.Sym != nil {
mode.Fprintf(s, " fnName %v", n.Func.Closure.Func.Nname.Sym)
}
if n.Sym != nil && n.Op != ONAME {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, " %v", n.Sym)
}
if n.Type != nil {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, " %v", n.Type)
}
if recur {
if n.Left != nil {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "%v", n.Left)
}
if n.Right != nil {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "%v", n.Right)
}
if n.Func != nil && n.Func.Closure != nil && n.Func.Closure.Nbody.Len() != 0 {
indent(s)
// The function associated with a closure
mode.Fprintf(s, "%v-clofunc%v", n.Op, n.Func.Closure)
}
if n.Func != nil && n.Func.Dcl != nil && len(n.Func.Dcl) != 0 {
indent(s)
// The dcls for a func or closure
mode.Fprintf(s, "%v-dcl%v", n.Op, asNodes(n.Func.Dcl))
}
if n.List.Len() != 0 {
indent(s)
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "%v-list%v", n.Op, n.List)
}
if n.Rlist.Len() != 0 {
indent(s)
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "%v-rlist%v", n.Op, n.Rlist)
}
if n.Nbody.Len() != 0 {
indent(s)
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
mode.Fprintf(s, "%v-body%v", n.Op, n.Nbody)
}
}
}
// "%S" suppresses qualifying with package
func symFormat(s *types.Sym, f fmt.State, verb rune, mode fmtMode) {
switch verb {
case 'v', 'S':
fmt.Fprint(f, sconv(s, fmtFlag(f, verb), mode))
cmd/compile: make internal objects directly print to printer Internal objects that satisfy the Printable interface can print directly to a printer w/o going through the conversion to a string first. Made printer.f understand and special-case %v so that Printable objects use the printer directly. This is work in progress and we may end up doing something else eventually (perhaps using fmt.Formatter) - or even undo these changes if this exploration doesn't get us to a significantly better place. Allocations numbers relative to commit c85b77c (still up, but reduced from most recent change): name old time/op new time/op delta Template 307ms ± 4% 315ms ± 4% +2.55% (p=0.000 n=29+29) Unicode 164ms ± 4% 165ms ± 4% ~ (p=0.057 n=30+30) GoTypes 1.01s ± 3% 1.03s ± 3% +1.72% (p=0.000 n=30+30) Compiler 5.49s ± 1% 5.62s ± 2% +2.31% (p=0.000 n=30+28) name old user-ns/op new user-ns/op delta Template 397M ± 3% 406M ± 6% +2.21% (p=0.000 n=28+30) Unicode 225M ± 4% 226M ± 3% ~ (p=0.230 n=29+30) GoTypes 1.31G ± 3% 1.34G ± 5% +2.79% (p=0.000 n=30+30) Compiler 7.39G ± 2% 7.50G ± 2% +1.43% (p=0.000 n=30+29) name old alloc/op new alloc/op delta Template 46.8MB ± 0% 47.5MB ± 0% +1.48% (p=0.000 n=29+28) Unicode 37.8MB ± 0% 38.1MB ± 0% +0.64% (p=0.000 n=30+28) GoTypes 143MB ± 0% 145MB ± 0% +1.72% (p=0.000 n=30+30) Compiler 683MB ± 0% 706MB ± 0% +3.31% (p=0.000 n=30+29) name old allocs/op new allocs/op delta Template 444k ± 0% 481k ± 0% +8.38% (p=0.000 n=30+30) Unicode 369k ± 0% 379k ± 0% +2.74% (p=0.000 n=30+30) GoTypes 1.35M ± 0% 1.50M ± 0% +10.78% (p=0.000 n=30+30) Compiler 5.66M ± 0% 6.25M ± 0% +10.31% (p=0.000 n=29+29) For #16897. Change-Id: I37f95ab60508018ee6d29a98d238482b60e3e4b5 Reviewed-on: https://go-review.googlesource.com/28072 Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2016-08-29 17:56:15 -07:00
default:
fmt.Fprintf(f, "%%!%c(*types.Sym=%p)", verb, s)
}
}
cmd/compile: make internal objects directly print to printer Internal objects that satisfy the Printable interface can print directly to a printer w/o going through the conversion to a string first. Made printer.f understand and special-case %v so that Printable objects use the printer directly. This is work in progress and we may end up doing something else eventually (perhaps using fmt.Formatter) - or even undo these changes if this exploration doesn't get us to a significantly better place. Allocations numbers relative to commit c85b77c (still up, but reduced from most recent change): name old time/op new time/op delta Template 307ms ± 4% 315ms ± 4% +2.55% (p=0.000 n=29+29) Unicode 164ms ± 4% 165ms ± 4% ~ (p=0.057 n=30+30) GoTypes 1.01s ± 3% 1.03s ± 3% +1.72% (p=0.000 n=30+30) Compiler 5.49s ± 1% 5.62s ± 2% +2.31% (p=0.000 n=30+28) name old user-ns/op new user-ns/op delta Template 397M ± 3% 406M ± 6% +2.21% (p=0.000 n=28+30) Unicode 225M ± 4% 226M ± 3% ~ (p=0.230 n=29+30) GoTypes 1.31G ± 3% 1.34G ± 5% +2.79% (p=0.000 n=30+30) Compiler 7.39G ± 2% 7.50G ± 2% +1.43% (p=0.000 n=30+29) name old alloc/op new alloc/op delta Template 46.8MB ± 0% 47.5MB ± 0% +1.48% (p=0.000 n=29+28) Unicode 37.8MB ± 0% 38.1MB ± 0% +0.64% (p=0.000 n=30+28) GoTypes 143MB ± 0% 145MB ± 0% +1.72% (p=0.000 n=30+30) Compiler 683MB ± 0% 706MB ± 0% +3.31% (p=0.000 n=30+29) name old allocs/op new allocs/op delta Template 444k ± 0% 481k ± 0% +8.38% (p=0.000 n=30+30) Unicode 369k ± 0% 379k ± 0% +2.74% (p=0.000 n=30+30) GoTypes 1.35M ± 0% 1.50M ± 0% +10.78% (p=0.000 n=30+30) Compiler 5.66M ± 0% 6.25M ± 0% +10.31% (p=0.000 n=29+29) For #16897. Change-Id: I37f95ab60508018ee6d29a98d238482b60e3e4b5 Reviewed-on: https://go-review.googlesource.com/28072 Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2016-08-29 17:56:15 -07:00
func smodeString(s *types.Sym, mode fmtMode) string { return sconv(s, 0, mode) }
// See #16897 before changing the implementation of sconv.
func sconv(s *types.Sym, flag FmtFlag, mode fmtMode) string {
if flag&FmtLong != 0 {
panic("linksymfmt")
}
if s == nil {
cmd/compile: reduce allocs to c85b77c (pre-fmt.go change) levels Linker and reflect info generation (reflect.go) relies on formatting of types (tconv). The fmt.Format based approach introduces extra allocations, which matter in those cases. Resurrected sconv and tconv code from commit c85b77c (fmt.go only); and adjusted it slightly. The formatter-based approach is still used throughout the rest of the compiler, but reflect.go now uses the tconv method that simply returns the desired string. (The timing data below may not be accurate; I've included it only for comparison with the numbers in issue #16897). name old time/op new time/op delta Template 297ms ± 2% 288ms ± 3% -3.12% (p=0.000 n=27+29) Unicode 155ms ± 5% 150ms ± 5% -3.26% (p=0.000 n=30+30) GoTypes 1.00s ± 3% 0.95s ± 3% -4.51% (p=0.000 n=28+29) name old alloc/op new alloc/op delta Template 46.8MB ± 0% 46.5MB ± 0% -0.65% (p=0.000 n=28+30) Unicode 37.9MB ± 0% 37.8MB ± 0% -0.24% (p=0.000 n=29+30) GoTypes 144MB ± 0% 143MB ± 0% -0.68% (p=0.000 n=30+30) name old allocs/op new allocs/op delta Template 469k ± 0% 446k ± 0% -5.01% (p=0.000 n=29+30) Unicode 375k ± 0% 369k ± 0% -1.62% (p=0.000 n=30+28) GoTypes 1.47M ± 0% 1.37M ± 0% -6.29% (p=0.000 n=30+30) The code for sconv/tconv in fmt.go now closely match the code from c85b77c again; except that the functions are now methods. Removing the use of the bytes.Buffer in tconv and special-caseing interface{} has helped a small amount as well: name old time/op new time/op delta Template 299ms ± 3% 288ms ± 3% -3.83% (p=0.000 n=29+29) Unicode 156ms ± 5% 150ms ± 5% -3.56% (p=0.000 n=30+30) GoTypes 960ms ± 2% 954ms ± 3% -0.58% (p=0.037 n=26+29) name old alloc/op new alloc/op delta Template 46.6MB ± 0% 46.5MB ± 0% -0.22% (p=0.000 n=30+30) Unicode 37.8MB ± 0% 37.8MB ± 0% ~ (p=0.075 n=30+30) GoTypes 143MB ± 0% 143MB ± 0% -0.31% (p=0.000 n=30+30) name old allocs/op new allocs/op delta Template 447k ± 0% 446k ± 0% -0.28% (p=0.000 n=30+30) Unicode 369k ± 0% 369k ± 0% -0.03% (p=0.032 n=30+28) GoTypes 1.38M ± 0% 1.37M ± 0% -0.35% (p=0.000 n=29+30) Comparison between c85b77c and now (see issue #16897): name old time/op new time/op delta Template 307ms ± 4% 288ms ± 3% -6.24% (p=0.000 n=29+29) Unicode 164ms ± 4% 150ms ± 5% -8.20% (p=0.000 n=30+30) GoTypes 1.01s ± 3% 0.95s ± 3% -5.72% (p=0.000 n=30+29) name old alloc/op new alloc/op delta Template 46.8MB ± 0% 46.5MB ± 0% -0.66% (p=0.000 n=29+30) Unicode 37.8MB ± 0% 37.8MB ± 0% -0.13% (p=0.000 n=30+30) GoTypes 143MB ± 0% 143MB ± 0% -0.11% (p=0.000 n=30+30) name old allocs/op new allocs/op delta Template 444k ± 0% 446k ± 0% +0.48% (p=0.000 n=30+30) Unicode 369k ± 0% 369k ± 0% +0.09% (p=0.000 n=30+28) GoTypes 1.35M ± 0% 1.37M ± 0% +1.47% (p=0.000 n=30+30) There's still a small increase (< 1.5%) for GoTypes but pending a complete rewrite of fmt.go, this seems ok again. Fixes #16897. Change-Id: I7e0e56cd1b9f981252eded917f5752259d402354 Reviewed-on: https://go-review.googlesource.com/29087 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2016-09-12 13:44:43 -07:00
return "<S>"
}
if s.Name == "_" {
cmd/compile: reduce allocs to c85b77c (pre-fmt.go change) levels Linker and reflect info generation (reflect.go) relies on formatting of types (tconv). The fmt.Format based approach introduces extra allocations, which matter in those cases. Resurrected sconv and tconv code from commit c85b77c (fmt.go only); and adjusted it slightly. The formatter-based approach is still used throughout the rest of the compiler, but reflect.go now uses the tconv method that simply returns the desired string. (The timing data below may not be accurate; I've included it only for comparison with the numbers in issue #16897). name old time/op new time/op delta Template 297ms ± 2% 288ms ± 3% -3.12% (p=0.000 n=27+29) Unicode 155ms ± 5% 150ms ± 5% -3.26% (p=0.000 n=30+30) GoTypes 1.00s ± 3% 0.95s ± 3% -4.51% (p=0.000 n=28+29) name old alloc/op new alloc/op delta Template 46.8MB ± 0% 46.5MB ± 0% -0.65% (p=0.000 n=28+30) Unicode 37.9MB ± 0% 37.8MB ± 0% -0.24% (p=0.000 n=29+30) GoTypes 144MB ± 0% 143MB ± 0% -0.68% (p=0.000 n=30+30) name old allocs/op new allocs/op delta Template 469k ± 0% 446k ± 0% -5.01% (p=0.000 n=29+30) Unicode 375k ± 0% 369k ± 0% -1.62% (p=0.000 n=30+28) GoTypes 1.47M ± 0% 1.37M ± 0% -6.29% (p=0.000 n=30+30) The code for sconv/tconv in fmt.go now closely match the code from c85b77c again; except that the functions are now methods. Removing the use of the bytes.Buffer in tconv and special-caseing interface{} has helped a small amount as well: name old time/op new time/op delta Template 299ms ± 3% 288ms ± 3% -3.83% (p=0.000 n=29+29) Unicode 156ms ± 5% 150ms ± 5% -3.56% (p=0.000 n=30+30) GoTypes 960ms ± 2% 954ms ± 3% -0.58% (p=0.037 n=26+29) name old alloc/op new alloc/op delta Template 46.6MB ± 0% 46.5MB ± 0% -0.22% (p=0.000 n=30+30) Unicode 37.8MB ± 0% 37.8MB ± 0% ~ (p=0.075 n=30+30) GoTypes 143MB ± 0% 143MB ± 0% -0.31% (p=0.000 n=30+30) name old allocs/op new allocs/op delta Template 447k ± 0% 446k ± 0% -0.28% (p=0.000 n=30+30) Unicode 369k ± 0% 369k ± 0% -0.03% (p=0.032 n=30+28) GoTypes 1.38M ± 0% 1.37M ± 0% -0.35% (p=0.000 n=29+30) Comparison between c85b77c and now (see issue #16897): name old time/op new time/op delta Template 307ms ± 4% 288ms ± 3% -6.24% (p=0.000 n=29+29) Unicode 164ms ± 4% 150ms ± 5% -8.20% (p=0.000 n=30+30) GoTypes 1.01s ± 3% 0.95s ± 3% -5.72% (p=0.000 n=30+29) name old alloc/op new alloc/op delta Template 46.8MB ± 0% 46.5MB ± 0% -0.66% (p=0.000 n=29+30) Unicode 37.8MB ± 0% 37.8MB ± 0% -0.13% (p=0.000 n=30+30) GoTypes 143MB ± 0% 143MB ± 0% -0.11% (p=0.000 n=30+30) name old allocs/op new allocs/op delta Template 444k ± 0% 446k ± 0% +0.48% (p=0.000 n=30+30) Unicode 369k ± 0% 369k ± 0% +0.09% (p=0.000 n=30+28) GoTypes 1.35M ± 0% 1.37M ± 0% +1.47% (p=0.000 n=30+30) There's still a small increase (< 1.5%) for GoTypes but pending a complete rewrite of fmt.go, this seems ok again. Fixes #16897. Change-Id: I7e0e56cd1b9f981252eded917f5752259d402354 Reviewed-on: https://go-review.googlesource.com/29087 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2016-09-12 13:44:43 -07:00
return "_"
}
cmd/compile: use a bytes.Buffer to format symbols No significant compiler speed changes, but some minor memory savings. Passes toolstash-check. name old alloc/op new alloc/op delta Template 36.3MB ± 0% 36.2MB ± 0% -0.25% (p=0.008 n=5+5) Unicode 28.3MB ± 0% 28.2MB ± 0% -0.16% (p=0.008 n=5+5) GoTypes 122MB ± 0% 121MB ± 0% -0.39% (p=0.008 n=5+5) Compiler 568MB ± 0% 566MB ± 0% -0.21% (p=0.008 n=5+5) SSA 1.95GB ± 0% 1.95GB ± 0% -0.08% (p=0.008 n=5+5) Flate 22.8MB ± 0% 22.8MB ± 0% -0.21% (p=0.008 n=5+5) GoParser 28.0MB ± 0% 27.9MB ± 0% -0.38% (p=0.008 n=5+5) Reflect 78.6MB ± 0% 78.3MB ± 0% -0.33% (p=0.008 n=5+5) Tar 34.1MB ± 0% 34.1MB ± 0% -0.19% (p=0.008 n=5+5) XML 44.3MB ± 0% 44.2MB ± 0% -0.19% (p=0.008 n=5+5) [Geo mean] 79.9MB 79.7MB -0.24% name old allocs/op new allocs/op delta Template 363k ± 0% 359k ± 0% -1.21% (p=0.008 n=5+5) Unicode 329k ± 0% 326k ± 0% -0.90% (p=0.008 n=5+5) GoTypes 1.28M ± 0% 1.25M ± 0% -2.62% (p=0.008 n=5+5) Compiler 5.39M ± 0% 5.31M ± 0% -1.45% (p=0.008 n=5+5) SSA 18.1M ± 0% 17.9M ± 0% -0.78% (p=0.008 n=5+5) Flate 228k ± 0% 226k ± 0% -0.97% (p=0.008 n=5+5) GoParser 295k ± 0% 288k ± 0% -2.26% (p=0.008 n=5+5) Reflect 949k ± 0% 932k ± 0% -1.74% (p=0.008 n=5+5) Tar 336k ± 0% 332k ± 0% -1.12% (p=0.008 n=5+5) XML 417k ± 0% 413k ± 0% -1.10% (p=0.008 n=5+5) [Geo mean] 818k 806k -1.42% Change-Id: Ibdb94650a761edec17d8eba0abdfb70a8a495da9 Reviewed-on: https://go-review.googlesource.com/c/go/+/222920 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2020-01-14 16:37:42 -08:00
buf := fmtBufferPool.Get().(*bytes.Buffer)
buf.Reset()
defer fmtBufferPool.Put(buf)
flag, mode = flag.update(mode)
symfmt(buf, s, flag, mode)
return types.InternString(buf.Bytes())
}
func sconv2(b *bytes.Buffer, s *types.Sym, flag FmtFlag, mode fmtMode) {
if flag&FmtLong != 0 {
panic("linksymfmt")
}
if s == nil {
b.WriteString("<S>")
return
}
if s.Name == "_" {
b.WriteString("_")
return
}
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
flag, mode = flag.update(mode)
cmd/compile: use a bytes.Buffer to format symbols No significant compiler speed changes, but some minor memory savings. Passes toolstash-check. name old alloc/op new alloc/op delta Template 36.3MB ± 0% 36.2MB ± 0% -0.25% (p=0.008 n=5+5) Unicode 28.3MB ± 0% 28.2MB ± 0% -0.16% (p=0.008 n=5+5) GoTypes 122MB ± 0% 121MB ± 0% -0.39% (p=0.008 n=5+5) Compiler 568MB ± 0% 566MB ± 0% -0.21% (p=0.008 n=5+5) SSA 1.95GB ± 0% 1.95GB ± 0% -0.08% (p=0.008 n=5+5) Flate 22.8MB ± 0% 22.8MB ± 0% -0.21% (p=0.008 n=5+5) GoParser 28.0MB ± 0% 27.9MB ± 0% -0.38% (p=0.008 n=5+5) Reflect 78.6MB ± 0% 78.3MB ± 0% -0.33% (p=0.008 n=5+5) Tar 34.1MB ± 0% 34.1MB ± 0% -0.19% (p=0.008 n=5+5) XML 44.3MB ± 0% 44.2MB ± 0% -0.19% (p=0.008 n=5+5) [Geo mean] 79.9MB 79.7MB -0.24% name old allocs/op new allocs/op delta Template 363k ± 0% 359k ± 0% -1.21% (p=0.008 n=5+5) Unicode 329k ± 0% 326k ± 0% -0.90% (p=0.008 n=5+5) GoTypes 1.28M ± 0% 1.25M ± 0% -2.62% (p=0.008 n=5+5) Compiler 5.39M ± 0% 5.31M ± 0% -1.45% (p=0.008 n=5+5) SSA 18.1M ± 0% 17.9M ± 0% -0.78% (p=0.008 n=5+5) Flate 228k ± 0% 226k ± 0% -0.97% (p=0.008 n=5+5) GoParser 295k ± 0% 288k ± 0% -2.26% (p=0.008 n=5+5) Reflect 949k ± 0% 932k ± 0% -1.74% (p=0.008 n=5+5) Tar 336k ± 0% 332k ± 0% -1.12% (p=0.008 n=5+5) XML 417k ± 0% 413k ± 0% -1.10% (p=0.008 n=5+5) [Geo mean] 818k 806k -1.42% Change-Id: Ibdb94650a761edec17d8eba0abdfb70a8a495da9 Reviewed-on: https://go-review.googlesource.com/c/go/+/222920 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2020-01-14 16:37:42 -08:00
symfmt(b, s, flag, mode)
}
func fldconv(b *bytes.Buffer, f *types.Field, flag FmtFlag, mode fmtMode, visited map[*types.Type]int, funarg types.Funarg) {
if f == nil {
b.WriteString("<T>")
return
}
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
flag, mode = flag.update(mode)
if mode == FTypeIdName {
flag |= FmtUnsigned
}
var name string
if flag&FmtShort == 0 {
s := f.Sym
cmd/compile: replace Field.Nname.Pos with Field.Pos For struct fields and methods, Field.Nname was only used to store position information, which means we're allocating an entire ONAME Node+Name+Param structure just for one field. We can optimize away these ONAME allocations by instead adding a Field.Pos field. Unfortunately, we can't get rid of Field.Nname, because it's needed for function parameters, so Field grows a little bit and now has more redundant information in those cases. However, that was already the case (e.g., Field.Sym and Field.Nname.Sym), and it's still a net win for allocations as demonstrated by the benchmarks below. Additionally, by moving the ONAME allocation for function parameters to funcargs, we can avoid allocating them for function parameters that aren't used in corresponding function bodies (e.g., interface methods, function-typed variables, and imported functions/methods without inline bodies). name old time/op new time/op delta Template 254ms ± 6% 251ms ± 6% -1.04% (p=0.000 n=487+488) Unicode 128ms ± 7% 128ms ± 7% ~ (p=0.294 n=482+467) GoTypes 862ms ± 5% 860ms ± 4% ~ (p=0.075 n=488+471) Compiler 3.91s ± 4% 3.90s ± 4% -0.39% (p=0.000 n=468+473) name old user-time/op new user-time/op delta Template 339ms ±14% 336ms ±14% -1.02% (p=0.001 n=498+494) Unicode 176ms ±18% 176ms ±25% ~ (p=0.940 n=491+499) GoTypes 1.13s ± 8% 1.13s ± 9% ~ (p=0.157 n=496+493) Compiler 5.24s ± 6% 5.21s ± 6% -0.57% (p=0.000 n=485+489) name old alloc/op new alloc/op delta Template 38.3MB ± 0% 37.3MB ± 0% -2.58% (p=0.000 n=499+497) Unicode 29.1MB ± 0% 29.1MB ± 0% -0.03% (p=0.000 n=500+493) GoTypes 116MB ± 0% 115MB ± 0% -0.65% (p=0.000 n=498+499) Compiler 492MB ± 0% 487MB ± 0% -1.00% (p=0.000 n=497+498) name old allocs/op new allocs/op delta Template 364k ± 0% 360k ± 0% -1.15% (p=0.000 n=499+499) Unicode 336k ± 0% 336k ± 0% -0.01% (p=0.000 n=500+493) GoTypes 1.16M ± 0% 1.16M ± 0% -0.30% (p=0.000 n=499+499) Compiler 4.54M ± 0% 4.51M ± 0% -0.58% (p=0.000 n=494+495) Passes toolstash-check -gcflags=-dwarf=false. Changes DWARF output because position information is now tracked more precisely for function parameters. Change-Id: Ib8077d70d564cc448c5e4290baceab3a4396d712 Reviewed-on: https://go-review.googlesource.com/108217 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2018-04-18 22:57:10 -07:00
// Take the name from the original.
if mode == FErr {
s = origSym(s)
}
if s != nil && f.Embedded == 0 {
if funarg != types.FunargNone {
name = asNode(f.Nname).modeString(mode)
} else if flag&FmtLong != 0 {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
name = mode.Sprintf("%0S", s)
if !types.IsExported(name) && flag&FmtUnsigned == 0 {
name = smodeString(s, mode) // qualify non-exported names (used on structs, not on funarg)
}
} else {
name = smodeString(s, mode)
}
}
}
if name != "" {
b.WriteString(name)
b.WriteString(" ")
}
cmd/compile: bulk rename This change does a bulk rename of several identifiers in the compiler. See #27167 and https://docs.google.com/document/d/19_ExiylD9MRfeAjKIfEsMU1_RGhuxB9sA0b5Zv7byVI/ for context and for discussion of these particular renames. Commands run to generate this change: gorename -from '"cmd/compile/internal/gc".OPROC' -to OGO gorename -from '"cmd/compile/internal/gc".OCOM' -to OBITNOT gorename -from '"cmd/compile/internal/gc".OMINUS' -to ONEG gorename -from '"cmd/compile/internal/gc".OIND' -to ODEREF gorename -from '"cmd/compile/internal/gc".OARRAYBYTESTR' -to OBYTES2STR gorename -from '"cmd/compile/internal/gc".OARRAYBYTESTRTMP' -to OBYTES2STRTMP gorename -from '"cmd/compile/internal/gc".OARRAYRUNESTR' -to ORUNES2STR gorename -from '"cmd/compile/internal/gc".OSTRARRAYBYTE' -to OSTR2BYTES gorename -from '"cmd/compile/internal/gc".OSTRARRAYBYTETMP' -to OSTR2BYTESTMP gorename -from '"cmd/compile/internal/gc".OSTRARRAYRUNE' -to OSTR2RUNES gorename -from '"cmd/compile/internal/gc".Etop' -to ctxStmt gorename -from '"cmd/compile/internal/gc".Erv' -to ctxExpr gorename -from '"cmd/compile/internal/gc".Ecall' -to ctxCallee gorename -from '"cmd/compile/internal/gc".Efnstruct' -to ctxMultiOK gorename -from '"cmd/compile/internal/gc".Easgn' -to ctxAssign gorename -from '"cmd/compile/internal/gc".Ecomplit' -to ctxCompLit Not altered: parameters and local variables (mostly in typecheck.go) named top, which should probably now be called ctx (and which should probably have a named type). Also not altered: Field called Top in gc.Func. gorename -from '"cmd/compile/internal/gc".Node.Isddd' -to IsDDD gorename -from '"cmd/compile/internal/gc".Node.SetIsddd' -to SetIsDDD gorename -from '"cmd/compile/internal/gc".nodeIsddd' -to nodeIsDDD gorename -from '"cmd/compile/internal/types".Field.Isddd' -to IsDDD gorename -from '"cmd/compile/internal/types".Field.SetIsddd' -to SetIsDDD gorename -from '"cmd/compile/internal/types".fieldIsddd' -to fieldIsDDD Not altered: function gc.hasddd, params and local variables called isddd Also not altered: fmt.go prints nodes using "isddd(%v)". cd cmd/compile/internal/gc; go generate I then manually found impacted comments using exact string match and fixed them up by hand. The comment changes were trivial. Passes toolstash-check. Fixes #27167. If this experiment is deemed a success, we will open a new tracking issue for renames to do at the end of the 1.13 cycles. Change-Id: I2dc541533d2ab0d06cb3d31d65df205ecfb151e8 Reviewed-on: https://go-review.googlesource.com/c/150140 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2018-11-18 08:34:38 -08:00
if f.IsDDD() {
var et *types.Type
if f.Type != nil {
et = f.Type.Elem()
}
b.WriteString("...")
tconv2(b, et, 0, mode, visited)
} else {
tconv2(b, f.Type, 0, mode, visited)
}
if flag&FmtShort == 0 && funarg == types.FunargNone && f.Note != "" {
b.WriteString(" ")
b.WriteString(strconv.Quote(f.Note))
}
}
// "%L" print definition, not name
// "%S" omit 'func' and receiver from function types, short type names
func typeFormat(t *types.Type, s fmt.State, verb rune, mode fmtMode) {
switch verb {
case 'v', 'S', 'L':
fmt.Fprint(s, tconv(t, fmtFlag(s, verb), mode))
default:
fmt.Fprintf(s, "%%!%c(*Type=%p)", verb, t)
}
}
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
func (n *Node) String() string { return fmt.Sprint(n) }
func (n *Node) modeString(mode fmtMode) string { return mode.Sprint(n) }
// "%L" suffix with "(type %T)" where possible
// "%+S" in debug mode, don't recurse, no multiline output
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
func (n *Node) nconv(s fmt.State, flag FmtFlag, mode fmtMode) {
if n == nil {
fmt.Fprint(s, "<N>")
return
}
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
flag, mode = flag.update(mode)
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
switch mode {
case FErr:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
n.nodefmt(s, flag, mode)
case FDbg:
dumpdepth++
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
n.nodedump(s, flag, mode)
dumpdepth--
default:
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
Fatalf("unhandled %%N mode: %d", mode)
}
}
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
func (l Nodes) format(s fmt.State, verb rune, mode fmtMode) {
switch verb {
case 'v':
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
l.hconv(s, fmtFlag(s, verb), mode)
cmd/compile: make internal objects directly print to printer Internal objects that satisfy the Printable interface can print directly to a printer w/o going through the conversion to a string first. Made printer.f understand and special-case %v so that Printable objects use the printer directly. This is work in progress and we may end up doing something else eventually (perhaps using fmt.Formatter) - or even undo these changes if this exploration doesn't get us to a significantly better place. Allocations numbers relative to commit c85b77c (still up, but reduced from most recent change): name old time/op new time/op delta Template 307ms ± 4% 315ms ± 4% +2.55% (p=0.000 n=29+29) Unicode 164ms ± 4% 165ms ± 4% ~ (p=0.057 n=30+30) GoTypes 1.01s ± 3% 1.03s ± 3% +1.72% (p=0.000 n=30+30) Compiler 5.49s ± 1% 5.62s ± 2% +2.31% (p=0.000 n=30+28) name old user-ns/op new user-ns/op delta Template 397M ± 3% 406M ± 6% +2.21% (p=0.000 n=28+30) Unicode 225M ± 4% 226M ± 3% ~ (p=0.230 n=29+30) GoTypes 1.31G ± 3% 1.34G ± 5% +2.79% (p=0.000 n=30+30) Compiler 7.39G ± 2% 7.50G ± 2% +1.43% (p=0.000 n=30+29) name old alloc/op new alloc/op delta Template 46.8MB ± 0% 47.5MB ± 0% +1.48% (p=0.000 n=29+28) Unicode 37.8MB ± 0% 38.1MB ± 0% +0.64% (p=0.000 n=30+28) GoTypes 143MB ± 0% 145MB ± 0% +1.72% (p=0.000 n=30+30) Compiler 683MB ± 0% 706MB ± 0% +3.31% (p=0.000 n=30+29) name old allocs/op new allocs/op delta Template 444k ± 0% 481k ± 0% +8.38% (p=0.000 n=30+30) Unicode 369k ± 0% 379k ± 0% +2.74% (p=0.000 n=30+30) GoTypes 1.35M ± 0% 1.50M ± 0% +10.78% (p=0.000 n=30+30) Compiler 5.66M ± 0% 6.25M ± 0% +10.31% (p=0.000 n=29+29) For #16897. Change-Id: I37f95ab60508018ee6d29a98d238482b60e3e4b5 Reviewed-on: https://go-review.googlesource.com/28072 Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2016-08-29 17:56:15 -07:00
default:
fmt.Fprintf(s, "%%!%c(Nodes)", verb)
}
}
cmd/compile: make internal objects directly print to printer Internal objects that satisfy the Printable interface can print directly to a printer w/o going through the conversion to a string first. Made printer.f understand and special-case %v so that Printable objects use the printer directly. This is work in progress and we may end up doing something else eventually (perhaps using fmt.Formatter) - or even undo these changes if this exploration doesn't get us to a significantly better place. Allocations numbers relative to commit c85b77c (still up, but reduced from most recent change): name old time/op new time/op delta Template 307ms ± 4% 315ms ± 4% +2.55% (p=0.000 n=29+29) Unicode 164ms ± 4% 165ms ± 4% ~ (p=0.057 n=30+30) GoTypes 1.01s ± 3% 1.03s ± 3% +1.72% (p=0.000 n=30+30) Compiler 5.49s ± 1% 5.62s ± 2% +2.31% (p=0.000 n=30+28) name old user-ns/op new user-ns/op delta Template 397M ± 3% 406M ± 6% +2.21% (p=0.000 n=28+30) Unicode 225M ± 4% 226M ± 3% ~ (p=0.230 n=29+30) GoTypes 1.31G ± 3% 1.34G ± 5% +2.79% (p=0.000 n=30+30) Compiler 7.39G ± 2% 7.50G ± 2% +1.43% (p=0.000 n=30+29) name old alloc/op new alloc/op delta Template 46.8MB ± 0% 47.5MB ± 0% +1.48% (p=0.000 n=29+28) Unicode 37.8MB ± 0% 38.1MB ± 0% +0.64% (p=0.000 n=30+28) GoTypes 143MB ± 0% 145MB ± 0% +1.72% (p=0.000 n=30+30) Compiler 683MB ± 0% 706MB ± 0% +3.31% (p=0.000 n=30+29) name old allocs/op new allocs/op delta Template 444k ± 0% 481k ± 0% +8.38% (p=0.000 n=30+30) Unicode 369k ± 0% 379k ± 0% +2.74% (p=0.000 n=30+30) GoTypes 1.35M ± 0% 1.50M ± 0% +10.78% (p=0.000 n=30+30) Compiler 5.66M ± 0% 6.25M ± 0% +10.31% (p=0.000 n=29+29) For #16897. Change-Id: I37f95ab60508018ee6d29a98d238482b60e3e4b5 Reviewed-on: https://go-review.googlesource.com/28072 Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2016-08-29 17:56:15 -07:00
func (n Nodes) String() string {
return fmt.Sprint(n)
}
// Flags: all those of %N plus '.': separate with comma's instead of semicolons.
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
func (l Nodes) hconv(s fmt.State, flag FmtFlag, mode fmtMode) {
if l.Len() == 0 && mode == FDbg {
fmt.Fprint(s, "<nil>")
return
}
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
flag, mode = flag.update(mode)
sep := "; "
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
if mode == FDbg {
sep = "\n"
} else if flag&FmtComma != 0 {
sep = ", "
}
for i, n := range l.Slice() {
cmd/compile: eliminate fmtmode and fmtpkgpfx globals The fmtmode and fmtpkgpfx globals stand in the way of making the compiler more concurrent (#15756). This CL removes them. The natural way to eliminate a global is to explicitly thread it as a parameter through all function calls. However, most of the functions in gc/fmt.go get called indirectly, by way of fmt format strings, so there's nowhere natural to add a parameter. Since there are only a few fmtmode modes, use named types to distinguish between modes. For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId are all gc.Node, but they print in different modes. Varying the type allows us to thread mode through fmt. Handle fmtpkgpfx by converting it to a printing mode, FTypeIdName, and using the same type-based approach. To avoid a loss of readability and danger of bugs from introducing conversions at all call sites, instead add a helper that systematically modifies the args. The only remaining gc/fmt.go global is dumpdepth. Since that is used for debugging only, it that can be handled with a global mutex, or some similarly basic, if inefficient, protection. Passes toolstash -cmp. No compiler performance impact. For future reference, other options for threading state that were considered and rejected: * Wrapping values in structs, such as: type fmtNode struct { n *Node mode fmtMode } This reduces the proliferation of types, and supports easily adding extra local parameters. However, putting such a struct into an interface{} allocates. This is unacceptable in this particular area of code. * Passing state via precision, such as: fmt.Fprintf("%*v", mode, n) where mode is the state encoded as an integer. This avoids extra allocations, but it is out of keeping with the intended semantics of precision, and is less readable. * Modify the fmt package to support setting/getting context via fmt.State. Unavailable due to Go 1 compatibility, and probably the wrong solution anyway. * Give up on package fmt. This would be a huge readability regression and cause high code churn. * Attempt a de-novo rewrite that circumvents these problems. Too high a risk of bugs, with insufficient reward for the effort, particularly since long term plans call for elimination of gc.Node. Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1 Reviewed-on: https://go-review.googlesource.com/38147 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-11-07 16:14:32 -08:00
fmt.Fprint(s, n.modeString(mode))
if i+1 < l.Len() {
fmt.Fprint(s, sep)
}
}
}
func dumplist(s string, l Nodes) {
fmt.Printf("%s%+v\n", s, l)
}
func fdumplist(w io.Writer, s string, l Nodes) {
fmt.Fprintf(w, "%s%+v\n", s, l)
}
func Dump(s string, n *Node) {
fmt.Printf("%s [%p]%+v\n", s, n, n)
}
// TODO(gri) make variable local somehow
var dumpdepth int
// indent prints indentation to s.
func indent(s fmt.State) {
fmt.Fprint(s, "\n")
for i := 0; i < dumpdepth; i++ {
fmt.Fprint(s, ". ")
}
}
func ellipsisIf(b bool) string {
if b {
return "..."
}
return ""
}