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

469 lines
10 KiB
Go
Raw Normal View History

// Copyright 2009 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 (
"cmd/compile/internal/types"
"cmd/internal/bio"
"cmd/internal/obj"
"cmd/internal/objabi"
"crypto/sha256"
"fmt"
"io"
"strconv"
)
// architecture-independent object file output
const (
ArhdrSize = 60
)
func formathdr(arhdr []byte, name string, size int64) {
copy(arhdr[:], fmt.Sprintf("%-16s%-12d%-6d%-6d%-8o%-10d`\n", name, 0, 0, 0, 0644, size))
}
cmd/compile: add -linkobj flag to allow writing object file in two parts This flag is experimental and the semantics may change even after Go 1.7 is released. There are no changes to code not using the flag. The first part is for reading by future compiles. The second part is for reading by the final link step. Splitting the file this way allows distributed build systems to ship the compile-input part only to compile steps and the linker-input part only to linker steps. The first part is basically just the export data, and the second part is basically everything else. The overall files still have the same broad structure, so that existing tools will work with both halves. It's just that various pieces are empty in the two halves. This also copies the two bits of data the linker needed from export data into the object header proper, so that the linker doesn't need any export data at all. That eliminates a TODO that was left for switching to the binary export data. (Now the linker doesn't need to know about the switch.) The default is still to write out a combined output file. Nothing changes unless you pass -linkobj to the compiler. There is no support in the go command for -linkobj, since the go command doesn't copy objects around. The expectation is that other build systems (like bazel, say) might take advantage of this. The header adjustment and the option for the split output was intended as part of the zip archives, but the zip archives have been cut from Go 1.7. Doing this to the current archives both unblocks one step in the switch to binary export data and enables alternate build systems to experiment with the new flag using the Go 1.7 release. Change-Id: I8b6eab25b8a22b0a266ba0ac6d31e594f3d117f3 Reviewed-on: https://go-review.googlesource.com/22500 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-04-26 21:50:59 -04:00
// These modes say which kind of object file to generate.
// The default use of the toolchain is to set both bits,
// generating a combined compiler+linker object, one that
// serves to describe the package to both the compiler and the linker.
// In fact the compiler and linker read nearly disjoint sections of
// that file, though, so in a distributed build setting it can be more
// efficient to split the output into two files, supplying the compiler
// object only to future compilations and the linker object only to
// future links.
//
// By default a combined object is written, but if -linkobj is specified
// on the command line then the default -o output is a compiler object
// and the -linkobj output is a linker object.
const (
modeCompilerObj = 1 << iota
modeLinkerObj
)
func dumpobj() {
if !dolinkobj {
dumpobj1(outfile, modeCompilerObj)
return
}
cmd/compile: add -linkobj flag to allow writing object file in two parts This flag is experimental and the semantics may change even after Go 1.7 is released. There are no changes to code not using the flag. The first part is for reading by future compiles. The second part is for reading by the final link step. Splitting the file this way allows distributed build systems to ship the compile-input part only to compile steps and the linker-input part only to linker steps. The first part is basically just the export data, and the second part is basically everything else. The overall files still have the same broad structure, so that existing tools will work with both halves. It's just that various pieces are empty in the two halves. This also copies the two bits of data the linker needed from export data into the object header proper, so that the linker doesn't need any export data at all. That eliminates a TODO that was left for switching to the binary export data. (Now the linker doesn't need to know about the switch.) The default is still to write out a combined output file. Nothing changes unless you pass -linkobj to the compiler. There is no support in the go command for -linkobj, since the go command doesn't copy objects around. The expectation is that other build systems (like bazel, say) might take advantage of this. The header adjustment and the option for the split output was intended as part of the zip archives, but the zip archives have been cut from Go 1.7. Doing this to the current archives both unblocks one step in the switch to binary export data and enables alternate build systems to experiment with the new flag using the Go 1.7 release. Change-Id: I8b6eab25b8a22b0a266ba0ac6d31e594f3d117f3 Reviewed-on: https://go-review.googlesource.com/22500 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-04-26 21:50:59 -04:00
if linkobj == "" {
dumpobj1(outfile, modeCompilerObj|modeLinkerObj)
return
cmd/compile: add -linkobj flag to allow writing object file in two parts This flag is experimental and the semantics may change even after Go 1.7 is released. There are no changes to code not using the flag. The first part is for reading by future compiles. The second part is for reading by the final link step. Splitting the file this way allows distributed build systems to ship the compile-input part only to compile steps and the linker-input part only to linker steps. The first part is basically just the export data, and the second part is basically everything else. The overall files still have the same broad structure, so that existing tools will work with both halves. It's just that various pieces are empty in the two halves. This also copies the two bits of data the linker needed from export data into the object header proper, so that the linker doesn't need any export data at all. That eliminates a TODO that was left for switching to the binary export data. (Now the linker doesn't need to know about the switch.) The default is still to write out a combined output file. Nothing changes unless you pass -linkobj to the compiler. There is no support in the go command for -linkobj, since the go command doesn't copy objects around. The expectation is that other build systems (like bazel, say) might take advantage of this. The header adjustment and the option for the split output was intended as part of the zip archives, but the zip archives have been cut from Go 1.7. Doing this to the current archives both unblocks one step in the switch to binary export data and enables alternate build systems to experiment with the new flag using the Go 1.7 release. Change-Id: I8b6eab25b8a22b0a266ba0ac6d31e594f3d117f3 Reviewed-on: https://go-review.googlesource.com/22500 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-04-26 21:50:59 -04:00
}
dumpobj1(outfile, modeCompilerObj)
dumpobj1(linkobj, modeLinkerObj)
cmd/compile: add -linkobj flag to allow writing object file in two parts This flag is experimental and the semantics may change even after Go 1.7 is released. There are no changes to code not using the flag. The first part is for reading by future compiles. The second part is for reading by the final link step. Splitting the file this way allows distributed build systems to ship the compile-input part only to compile steps and the linker-input part only to linker steps. The first part is basically just the export data, and the second part is basically everything else. The overall files still have the same broad structure, so that existing tools will work with both halves. It's just that various pieces are empty in the two halves. This also copies the two bits of data the linker needed from export data into the object header proper, so that the linker doesn't need any export data at all. That eliminates a TODO that was left for switching to the binary export data. (Now the linker doesn't need to know about the switch.) The default is still to write out a combined output file. Nothing changes unless you pass -linkobj to the compiler. There is no support in the go command for -linkobj, since the go command doesn't copy objects around. The expectation is that other build systems (like bazel, say) might take advantage of this. The header adjustment and the option for the split output was intended as part of the zip archives, but the zip archives have been cut from Go 1.7. Doing this to the current archives both unblocks one step in the switch to binary export data and enables alternate build systems to experiment with the new flag using the Go 1.7 release. Change-Id: I8b6eab25b8a22b0a266ba0ac6d31e594f3d117f3 Reviewed-on: https://go-review.googlesource.com/22500 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-04-26 21:50:59 -04:00
}
func dumpobj1(outfile string, mode int) {
var err error
bout, err = bio.Create(outfile)
if err != nil {
flusherrors()
fmt.Printf("can't create %s: %v\n", outfile, err)
errorexit()
}
startobj := int64(0)
var arhdr [ArhdrSize]byte
if writearchive {
bout.WriteString("!<arch>\n")
arhdr = [ArhdrSize]byte{}
bout.Write(arhdr[:])
startobj = bout.Offset()
}
cmd/compile: add -linkobj flag to allow writing object file in two parts This flag is experimental and the semantics may change even after Go 1.7 is released. There are no changes to code not using the flag. The first part is for reading by future compiles. The second part is for reading by the final link step. Splitting the file this way allows distributed build systems to ship the compile-input part only to compile steps and the linker-input part only to linker steps. The first part is basically just the export data, and the second part is basically everything else. The overall files still have the same broad structure, so that existing tools will work with both halves. It's just that various pieces are empty in the two halves. This also copies the two bits of data the linker needed from export data into the object header proper, so that the linker doesn't need any export data at all. That eliminates a TODO that was left for switching to the binary export data. (Now the linker doesn't need to know about the switch.) The default is still to write out a combined output file. Nothing changes unless you pass -linkobj to the compiler. There is no support in the go command for -linkobj, since the go command doesn't copy objects around. The expectation is that other build systems (like bazel, say) might take advantage of this. The header adjustment and the option for the split output was intended as part of the zip archives, but the zip archives have been cut from Go 1.7. Doing this to the current archives both unblocks one step in the switch to binary export data and enables alternate build systems to experiment with the new flag using the Go 1.7 release. Change-Id: I8b6eab25b8a22b0a266ba0ac6d31e594f3d117f3 Reviewed-on: https://go-review.googlesource.com/22500 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-04-26 21:50:59 -04:00
printheader := func() {
fmt.Fprintf(bout, "go object %s %s %s %s\n", objabi.GOOS, objabi.GOARCH, objabi.Version, objabi.Expstring())
cmd/compile: add -linkobj flag to allow writing object file in two parts This flag is experimental and the semantics may change even after Go 1.7 is released. There are no changes to code not using the flag. The first part is for reading by future compiles. The second part is for reading by the final link step. Splitting the file this way allows distributed build systems to ship the compile-input part only to compile steps and the linker-input part only to linker steps. The first part is basically just the export data, and the second part is basically everything else. The overall files still have the same broad structure, so that existing tools will work with both halves. It's just that various pieces are empty in the two halves. This also copies the two bits of data the linker needed from export data into the object header proper, so that the linker doesn't need any export data at all. That eliminates a TODO that was left for switching to the binary export data. (Now the linker doesn't need to know about the switch.) The default is still to write out a combined output file. Nothing changes unless you pass -linkobj to the compiler. There is no support in the go command for -linkobj, since the go command doesn't copy objects around. The expectation is that other build systems (like bazel, say) might take advantage of this. The header adjustment and the option for the split output was intended as part of the zip archives, but the zip archives have been cut from Go 1.7. Doing this to the current archives both unblocks one step in the switch to binary export data and enables alternate build systems to experiment with the new flag using the Go 1.7 release. Change-Id: I8b6eab25b8a22b0a266ba0ac6d31e594f3d117f3 Reviewed-on: https://go-review.googlesource.com/22500 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-04-26 21:50:59 -04:00
if buildid != "" {
fmt.Fprintf(bout, "build id %q\n", buildid)
}
if localpkg.Name == "main" {
fmt.Fprintf(bout, "main\n")
}
if safemode {
fmt.Fprintf(bout, "safe\n")
} else {
fmt.Fprintf(bout, "----\n") // room for some other tool to write "safe"
}
fmt.Fprintf(bout, "\n") // header ends with blank line
}
printheader()
if mode&modeCompilerObj != 0 {
dumpexport()
}
if writearchive {
bout.Flush()
size := bout.Offset() - startobj
if size&1 != 0 {
bout.WriteByte(0)
}
bout.Seek(startobj-ArhdrSize, 0)
formathdr(arhdr[:], "__.PKGDEF", size)
bout.Write(arhdr[:])
bout.Flush()
bout.Seek(startobj+size+(size&1), 0)
cmd/compile: add -linkobj flag to allow writing object file in two parts This flag is experimental and the semantics may change even after Go 1.7 is released. There are no changes to code not using the flag. The first part is for reading by future compiles. The second part is for reading by the final link step. Splitting the file this way allows distributed build systems to ship the compile-input part only to compile steps and the linker-input part only to linker steps. The first part is basically just the export data, and the second part is basically everything else. The overall files still have the same broad structure, so that existing tools will work with both halves. It's just that various pieces are empty in the two halves. This also copies the two bits of data the linker needed from export data into the object header proper, so that the linker doesn't need any export data at all. That eliminates a TODO that was left for switching to the binary export data. (Now the linker doesn't need to know about the switch.) The default is still to write out a combined output file. Nothing changes unless you pass -linkobj to the compiler. There is no support in the go command for -linkobj, since the go command doesn't copy objects around. The expectation is that other build systems (like bazel, say) might take advantage of this. The header adjustment and the option for the split output was intended as part of the zip archives, but the zip archives have been cut from Go 1.7. Doing this to the current archives both unblocks one step in the switch to binary export data and enables alternate build systems to experiment with the new flag using the Go 1.7 release. Change-Id: I8b6eab25b8a22b0a266ba0ac6d31e594f3d117f3 Reviewed-on: https://go-review.googlesource.com/22500 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-04-26 21:50:59 -04:00
}
if mode&modeLinkerObj == 0 {
bout.Close()
return
}
if writearchive {
// start object file
arhdr = [ArhdrSize]byte{}
bout.Write(arhdr[:])
startobj = bout.Offset()
cmd/compile: add -linkobj flag to allow writing object file in two parts This flag is experimental and the semantics may change even after Go 1.7 is released. There are no changes to code not using the flag. The first part is for reading by future compiles. The second part is for reading by the final link step. Splitting the file this way allows distributed build systems to ship the compile-input part only to compile steps and the linker-input part only to linker steps. The first part is basically just the export data, and the second part is basically everything else. The overall files still have the same broad structure, so that existing tools will work with both halves. It's just that various pieces are empty in the two halves. This also copies the two bits of data the linker needed from export data into the object header proper, so that the linker doesn't need any export data at all. That eliminates a TODO that was left for switching to the binary export data. (Now the linker doesn't need to know about the switch.) The default is still to write out a combined output file. Nothing changes unless you pass -linkobj to the compiler. There is no support in the go command for -linkobj, since the go command doesn't copy objects around. The expectation is that other build systems (like bazel, say) might take advantage of this. The header adjustment and the option for the split output was intended as part of the zip archives, but the zip archives have been cut from Go 1.7. Doing this to the current archives both unblocks one step in the switch to binary export data and enables alternate build systems to experiment with the new flag using the Go 1.7 release. Change-Id: I8b6eab25b8a22b0a266ba0ac6d31e594f3d117f3 Reviewed-on: https://go-review.googlesource.com/22500 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2016-04-26 21:50:59 -04:00
printheader()
}
if pragcgobuf != "" {
if writearchive {
// write empty export section; must be before cgo section
fmt.Fprintf(bout, "\n$$\n\n$$\n\n")
}
fmt.Fprintf(bout, "\n$$ // cgo\n")
fmt.Fprintf(bout, "%s\n$$\n\n", pragcgobuf)
}
fmt.Fprintf(bout, "\n!\n")
externs := len(externdcl)
dumpglobls()
dumpptabs()
dumptypestructs()
// Dump extra globals.
tmp := externdcl
if externdcl != nil {
externdcl = externdcl[externs:]
}
dumpglobls()
externdcl = tmp
if zerosize > 0 {
zero := mappkg.Lookup("zero")
ggloblsym(zero, int32(zerosize), obj.DUPOK|obj.RODATA)
}
cmd/internal/obj: rework gclocals handling The compiler handled gcargs and gclocals LSyms unusually. It generated placeholder symbols (makefuncdatasym), filled them in, and then renamed them for content-addressability. This is an important binary size optimization; the same locals information occurs over and over. This CL continues to treat these LSyms unusually, but in a slightly more explicit way, and importantly for concurrent compilation, in a way that does not require concurrent modification of Ctxt.Hash. Instead of creating gcargs and gclocals in the usual way, by creating a types.Sym and then an obj.LSym, we add them directly to obj.FuncInfo, initialize them in obj.InitTextSym, and deduplicate and add them to ctxt.Data at the end. Then the backend's job is simply to fill them in and rename them appropriately. Updates #15756 name old alloc/op new alloc/op delta Template 38.8MB ± 0% 38.7MB ± 0% -0.22% (p=0.016 n=5+5) Unicode 29.8MB ± 0% 29.8MB ± 0% ~ (p=0.690 n=5+5) GoTypes 113MB ± 0% 113MB ± 0% -0.24% (p=0.008 n=5+5) SSA 1.25GB ± 0% 1.24GB ± 0% -0.39% (p=0.008 n=5+5) Flate 25.3MB ± 0% 25.2MB ± 0% -0.43% (p=0.008 n=5+5) GoParser 31.7MB ± 0% 31.7MB ± 0% -0.22% (p=0.008 n=5+5) Reflect 78.2MB ± 0% 77.6MB ± 0% -0.80% (p=0.008 n=5+5) Tar 26.6MB ± 0% 26.3MB ± 0% -0.85% (p=0.008 n=5+5) XML 42.4MB ± 0% 41.9MB ± 0% -1.04% (p=0.008 n=5+5) name old allocs/op new allocs/op delta Template 378k ± 0% 377k ± 1% ~ (p=0.151 n=5+5) Unicode 321k ± 1% 321k ± 0% ~ (p=0.841 n=5+5) GoTypes 1.14M ± 0% 1.14M ± 0% -0.47% (p=0.016 n=5+5) SSA 9.71M ± 0% 9.67M ± 0% -0.33% (p=0.008 n=5+5) Flate 233k ± 1% 232k ± 1% ~ (p=0.151 n=5+5) GoParser 316k ± 0% 315k ± 0% -0.49% (p=0.016 n=5+5) Reflect 979k ± 0% 972k ± 0% -0.75% (p=0.008 n=5+5) Tar 250k ± 0% 247k ± 1% -0.92% (p=0.008 n=5+5) XML 392k ± 1% 389k ± 0% -0.67% (p=0.008 n=5+5) Change-Id: Idc36186ca9d2f8214b5f7720bbc27b6bb22fdc48 Reviewed-on: https://go-review.googlesource.com/40697 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2017-04-14 06:35:53 -07:00
addGCLocals()
obj.WriteObjFile(Ctxt, bout.Writer)
if writearchive {
bout.Flush()
size := bout.Offset() - startobj
if size&1 != 0 {
bout.WriteByte(0)
}
bout.Seek(startobj-ArhdrSize, 0)
formathdr(arhdr[:], "_go_.o", size)
bout.Write(arhdr[:])
}
bout.Close()
}
func dumpptabs() {
if !Ctxt.Flag_dynlink || localpkg.Name != "main" {
return
}
for _, exportn := range exportlist {
s := exportn.Sym
n := asNode(s.Def)
if n == nil {
continue
}
if n.Op != ONAME {
continue
}
if !exportname(s.Name) {
continue
}
if s.Pkg.Name != "main" {
continue
}
if n.Type.Etype == TFUNC && n.Class == PFUNC {
// function
ptabs = append(ptabs, ptabEntry{s: s, t: asNode(s.Def).Type})
} else {
// variable
ptabs = append(ptabs, ptabEntry{s: s, t: types.NewPtr(asNode(s.Def).Type)})
}
}
}
func dumpglobls() {
// add globals
for _, n := range externdcl {
if n.Op != ONAME {
continue
}
if n.Type == nil {
Fatalf("external %v nil type\n", n)
}
if n.Class == PFUNC {
continue
}
if n.Sym.Pkg != localpkg {
continue
}
dowidth(n.Type)
ggloblnod(n)
}
for _, s := range funcsyms {
sf := s.Pkg.Lookup(funcsymname(s))
dsymptr(sf, 0, s, 0)
ggloblsym(sf, int32(Widthptr), obj.DUPOK|obj.RODATA)
}
// Do not reprocess funcsyms on next dumpglobls call.
funcsyms = nil
}
cmd/internal/obj: rework gclocals handling The compiler handled gcargs and gclocals LSyms unusually. It generated placeholder symbols (makefuncdatasym), filled them in, and then renamed them for content-addressability. This is an important binary size optimization; the same locals information occurs over and over. This CL continues to treat these LSyms unusually, but in a slightly more explicit way, and importantly for concurrent compilation, in a way that does not require concurrent modification of Ctxt.Hash. Instead of creating gcargs and gclocals in the usual way, by creating a types.Sym and then an obj.LSym, we add them directly to obj.FuncInfo, initialize them in obj.InitTextSym, and deduplicate and add them to ctxt.Data at the end. Then the backend's job is simply to fill them in and rename them appropriately. Updates #15756 name old alloc/op new alloc/op delta Template 38.8MB ± 0% 38.7MB ± 0% -0.22% (p=0.016 n=5+5) Unicode 29.8MB ± 0% 29.8MB ± 0% ~ (p=0.690 n=5+5) GoTypes 113MB ± 0% 113MB ± 0% -0.24% (p=0.008 n=5+5) SSA 1.25GB ± 0% 1.24GB ± 0% -0.39% (p=0.008 n=5+5) Flate 25.3MB ± 0% 25.2MB ± 0% -0.43% (p=0.008 n=5+5) GoParser 31.7MB ± 0% 31.7MB ± 0% -0.22% (p=0.008 n=5+5) Reflect 78.2MB ± 0% 77.6MB ± 0% -0.80% (p=0.008 n=5+5) Tar 26.6MB ± 0% 26.3MB ± 0% -0.85% (p=0.008 n=5+5) XML 42.4MB ± 0% 41.9MB ± 0% -1.04% (p=0.008 n=5+5) name old allocs/op new allocs/op delta Template 378k ± 0% 377k ± 1% ~ (p=0.151 n=5+5) Unicode 321k ± 1% 321k ± 0% ~ (p=0.841 n=5+5) GoTypes 1.14M ± 0% 1.14M ± 0% -0.47% (p=0.016 n=5+5) SSA 9.71M ± 0% 9.67M ± 0% -0.33% (p=0.008 n=5+5) Flate 233k ± 1% 232k ± 1% ~ (p=0.151 n=5+5) GoParser 316k ± 0% 315k ± 0% -0.49% (p=0.016 n=5+5) Reflect 979k ± 0% 972k ± 0% -0.75% (p=0.008 n=5+5) Tar 250k ± 0% 247k ± 1% -0.92% (p=0.008 n=5+5) XML 392k ± 1% 389k ± 0% -0.67% (p=0.008 n=5+5) Change-Id: Idc36186ca9d2f8214b5f7720bbc27b6bb22fdc48 Reviewed-on: https://go-review.googlesource.com/40697 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2017-04-14 06:35:53 -07:00
// addGCLocals adds gcargs and gclocals symbols to Ctxt.Data.
// It takes care not to add any duplicates.
// Though the object file format handles duplicates efficiently,
// storing only a single copy of the data,
// failure to remove these duplicates adds a few percent to object file size.
func addGCLocals() {
seen := make(map[string]bool)
for _, s := range Ctxt.Text {
if s.Func == nil {
cmd/internal/obj: rework gclocals handling The compiler handled gcargs and gclocals LSyms unusually. It generated placeholder symbols (makefuncdatasym), filled them in, and then renamed them for content-addressability. This is an important binary size optimization; the same locals information occurs over and over. This CL continues to treat these LSyms unusually, but in a slightly more explicit way, and importantly for concurrent compilation, in a way that does not require concurrent modification of Ctxt.Hash. Instead of creating gcargs and gclocals in the usual way, by creating a types.Sym and then an obj.LSym, we add them directly to obj.FuncInfo, initialize them in obj.InitTextSym, and deduplicate and add them to ctxt.Data at the end. Then the backend's job is simply to fill them in and rename them appropriately. Updates #15756 name old alloc/op new alloc/op delta Template 38.8MB ± 0% 38.7MB ± 0% -0.22% (p=0.016 n=5+5) Unicode 29.8MB ± 0% 29.8MB ± 0% ~ (p=0.690 n=5+5) GoTypes 113MB ± 0% 113MB ± 0% -0.24% (p=0.008 n=5+5) SSA 1.25GB ± 0% 1.24GB ± 0% -0.39% (p=0.008 n=5+5) Flate 25.3MB ± 0% 25.2MB ± 0% -0.43% (p=0.008 n=5+5) GoParser 31.7MB ± 0% 31.7MB ± 0% -0.22% (p=0.008 n=5+5) Reflect 78.2MB ± 0% 77.6MB ± 0% -0.80% (p=0.008 n=5+5) Tar 26.6MB ± 0% 26.3MB ± 0% -0.85% (p=0.008 n=5+5) XML 42.4MB ± 0% 41.9MB ± 0% -1.04% (p=0.008 n=5+5) name old allocs/op new allocs/op delta Template 378k ± 0% 377k ± 1% ~ (p=0.151 n=5+5) Unicode 321k ± 1% 321k ± 0% ~ (p=0.841 n=5+5) GoTypes 1.14M ± 0% 1.14M ± 0% -0.47% (p=0.016 n=5+5) SSA 9.71M ± 0% 9.67M ± 0% -0.33% (p=0.008 n=5+5) Flate 233k ± 1% 232k ± 1% ~ (p=0.151 n=5+5) GoParser 316k ± 0% 315k ± 0% -0.49% (p=0.016 n=5+5) Reflect 979k ± 0% 972k ± 0% -0.75% (p=0.008 n=5+5) Tar 250k ± 0% 247k ± 1% -0.92% (p=0.008 n=5+5) XML 392k ± 1% 389k ± 0% -0.67% (p=0.008 n=5+5) Change-Id: Idc36186ca9d2f8214b5f7720bbc27b6bb22fdc48 Reviewed-on: https://go-review.googlesource.com/40697 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2017-04-14 06:35:53 -07:00
continue
}
for _, gcsym := range []*obj.LSym{&s.Func.GCArgs, &s.Func.GCLocals} {
cmd/internal/obj: rework gclocals handling The compiler handled gcargs and gclocals LSyms unusually. It generated placeholder symbols (makefuncdatasym), filled them in, and then renamed them for content-addressability. This is an important binary size optimization; the same locals information occurs over and over. This CL continues to treat these LSyms unusually, but in a slightly more explicit way, and importantly for concurrent compilation, in a way that does not require concurrent modification of Ctxt.Hash. Instead of creating gcargs and gclocals in the usual way, by creating a types.Sym and then an obj.LSym, we add them directly to obj.FuncInfo, initialize them in obj.InitTextSym, and deduplicate and add them to ctxt.Data at the end. Then the backend's job is simply to fill them in and rename them appropriately. Updates #15756 name old alloc/op new alloc/op delta Template 38.8MB ± 0% 38.7MB ± 0% -0.22% (p=0.016 n=5+5) Unicode 29.8MB ± 0% 29.8MB ± 0% ~ (p=0.690 n=5+5) GoTypes 113MB ± 0% 113MB ± 0% -0.24% (p=0.008 n=5+5) SSA 1.25GB ± 0% 1.24GB ± 0% -0.39% (p=0.008 n=5+5) Flate 25.3MB ± 0% 25.2MB ± 0% -0.43% (p=0.008 n=5+5) GoParser 31.7MB ± 0% 31.7MB ± 0% -0.22% (p=0.008 n=5+5) Reflect 78.2MB ± 0% 77.6MB ± 0% -0.80% (p=0.008 n=5+5) Tar 26.6MB ± 0% 26.3MB ± 0% -0.85% (p=0.008 n=5+5) XML 42.4MB ± 0% 41.9MB ± 0% -1.04% (p=0.008 n=5+5) name old allocs/op new allocs/op delta Template 378k ± 0% 377k ± 1% ~ (p=0.151 n=5+5) Unicode 321k ± 1% 321k ± 0% ~ (p=0.841 n=5+5) GoTypes 1.14M ± 0% 1.14M ± 0% -0.47% (p=0.016 n=5+5) SSA 9.71M ± 0% 9.67M ± 0% -0.33% (p=0.008 n=5+5) Flate 233k ± 1% 232k ± 1% ~ (p=0.151 n=5+5) GoParser 316k ± 0% 315k ± 0% -0.49% (p=0.016 n=5+5) Reflect 979k ± 0% 972k ± 0% -0.75% (p=0.008 n=5+5) Tar 250k ± 0% 247k ± 1% -0.92% (p=0.008 n=5+5) XML 392k ± 1% 389k ± 0% -0.67% (p=0.008 n=5+5) Change-Id: Idc36186ca9d2f8214b5f7720bbc27b6bb22fdc48 Reviewed-on: https://go-review.googlesource.com/40697 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2017-04-14 06:35:53 -07:00
if seen[gcsym.Name] {
continue
}
Ctxt.Data = append(Ctxt.Data, gcsym)
seen[gcsym.Name] = true
}
}
}
func linksymname(s *types.Sym) string {
if isblanksym(s) {
return "_"
}
if s.Linkname != "" {
return s.Linkname
}
return s.Pkg.Prefix + "." + s.Name
}
func Linksym(s *types.Sym) *obj.LSym {
if s == nil {
return nil
}
if s.Lsym == nil {
s.Lsym = Ctxt.Lookup(linksymname(s))
}
return s.Lsym
}
func duintxx(s *types.Sym, off int, v uint64, wid int) int {
return duintxxLSym(Linksym(s), off, v, wid)
}
func duintxxLSym(s *obj.LSym, off int, v uint64, wid int) int {
if s.Type == 0 {
// TODO(josharian): Do this in obj.prepwrite instead.
s.Type = objabi.SDATA
}
if off&(wid-1) != 0 {
Fatalf("duintxxLSym: misaligned: v=%d wid=%d off=%d", v, wid, off)
}
s.WriteInt(Ctxt, int64(off), wid, int64(v))
return off + wid
}
func duint8(s *types.Sym, off int, v uint8) int {
return duintxx(s, off, uint64(v), 1)
}
func duint16(s *types.Sym, off int, v uint16) int {
return duintxx(s, off, uint64(v), 2)
}
func duint32(s *types.Sym, off int, v uint32) int {
return duintxx(s, off, uint64(v), 4)
}
func duintptr(s *types.Sym, off int, v uint64) int {
return duintxx(s, off, v, Widthptr)
}
cmd/internal/obj: rework gclocals handling The compiler handled gcargs and gclocals LSyms unusually. It generated placeholder symbols (makefuncdatasym), filled them in, and then renamed them for content-addressability. This is an important binary size optimization; the same locals information occurs over and over. This CL continues to treat these LSyms unusually, but in a slightly more explicit way, and importantly for concurrent compilation, in a way that does not require concurrent modification of Ctxt.Hash. Instead of creating gcargs and gclocals in the usual way, by creating a types.Sym and then an obj.LSym, we add them directly to obj.FuncInfo, initialize them in obj.InitTextSym, and deduplicate and add them to ctxt.Data at the end. Then the backend's job is simply to fill them in and rename them appropriately. Updates #15756 name old alloc/op new alloc/op delta Template 38.8MB ± 0% 38.7MB ± 0% -0.22% (p=0.016 n=5+5) Unicode 29.8MB ± 0% 29.8MB ± 0% ~ (p=0.690 n=5+5) GoTypes 113MB ± 0% 113MB ± 0% -0.24% (p=0.008 n=5+5) SSA 1.25GB ± 0% 1.24GB ± 0% -0.39% (p=0.008 n=5+5) Flate 25.3MB ± 0% 25.2MB ± 0% -0.43% (p=0.008 n=5+5) GoParser 31.7MB ± 0% 31.7MB ± 0% -0.22% (p=0.008 n=5+5) Reflect 78.2MB ± 0% 77.6MB ± 0% -0.80% (p=0.008 n=5+5) Tar 26.6MB ± 0% 26.3MB ± 0% -0.85% (p=0.008 n=5+5) XML 42.4MB ± 0% 41.9MB ± 0% -1.04% (p=0.008 n=5+5) name old allocs/op new allocs/op delta Template 378k ± 0% 377k ± 1% ~ (p=0.151 n=5+5) Unicode 321k ± 1% 321k ± 0% ~ (p=0.841 n=5+5) GoTypes 1.14M ± 0% 1.14M ± 0% -0.47% (p=0.016 n=5+5) SSA 9.71M ± 0% 9.67M ± 0% -0.33% (p=0.008 n=5+5) Flate 233k ± 1% 232k ± 1% ~ (p=0.151 n=5+5) GoParser 316k ± 0% 315k ± 0% -0.49% (p=0.016 n=5+5) Reflect 979k ± 0% 972k ± 0% -0.75% (p=0.008 n=5+5) Tar 250k ± 0% 247k ± 1% -0.92% (p=0.008 n=5+5) XML 392k ± 1% 389k ± 0% -0.67% (p=0.008 n=5+5) Change-Id: Idc36186ca9d2f8214b5f7720bbc27b6bb22fdc48 Reviewed-on: https://go-review.googlesource.com/40697 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2017-04-14 06:35:53 -07:00
func duint8LSym(s *obj.LSym, off int, v uint8) int {
return duintxxLSym(s, off, uint64(v), 1)
}
func duint32LSym(s *obj.LSym, off int, v uint32) int {
return duintxxLSym(s, off, uint64(v), 4)
}
func dbvecLSym(s *obj.LSym, off int, bv bvec) int {
// Runtime reads the bitmaps as byte arrays. Oblige.
for j := 0; int32(j) < bv.n; j += 8 {
word := bv.b[j/32]
cmd/internal/obj: rework gclocals handling The compiler handled gcargs and gclocals LSyms unusually. It generated placeholder symbols (makefuncdatasym), filled them in, and then renamed them for content-addressability. This is an important binary size optimization; the same locals information occurs over and over. This CL continues to treat these LSyms unusually, but in a slightly more explicit way, and importantly for concurrent compilation, in a way that does not require concurrent modification of Ctxt.Hash. Instead of creating gcargs and gclocals in the usual way, by creating a types.Sym and then an obj.LSym, we add them directly to obj.FuncInfo, initialize them in obj.InitTextSym, and deduplicate and add them to ctxt.Data at the end. Then the backend's job is simply to fill them in and rename them appropriately. Updates #15756 name old alloc/op new alloc/op delta Template 38.8MB ± 0% 38.7MB ± 0% -0.22% (p=0.016 n=5+5) Unicode 29.8MB ± 0% 29.8MB ± 0% ~ (p=0.690 n=5+5) GoTypes 113MB ± 0% 113MB ± 0% -0.24% (p=0.008 n=5+5) SSA 1.25GB ± 0% 1.24GB ± 0% -0.39% (p=0.008 n=5+5) Flate 25.3MB ± 0% 25.2MB ± 0% -0.43% (p=0.008 n=5+5) GoParser 31.7MB ± 0% 31.7MB ± 0% -0.22% (p=0.008 n=5+5) Reflect 78.2MB ± 0% 77.6MB ± 0% -0.80% (p=0.008 n=5+5) Tar 26.6MB ± 0% 26.3MB ± 0% -0.85% (p=0.008 n=5+5) XML 42.4MB ± 0% 41.9MB ± 0% -1.04% (p=0.008 n=5+5) name old allocs/op new allocs/op delta Template 378k ± 0% 377k ± 1% ~ (p=0.151 n=5+5) Unicode 321k ± 1% 321k ± 0% ~ (p=0.841 n=5+5) GoTypes 1.14M ± 0% 1.14M ± 0% -0.47% (p=0.016 n=5+5) SSA 9.71M ± 0% 9.67M ± 0% -0.33% (p=0.008 n=5+5) Flate 233k ± 1% 232k ± 1% ~ (p=0.151 n=5+5) GoParser 316k ± 0% 315k ± 0% -0.49% (p=0.016 n=5+5) Reflect 979k ± 0% 972k ± 0% -0.75% (p=0.008 n=5+5) Tar 250k ± 0% 247k ± 1% -0.92% (p=0.008 n=5+5) XML 392k ± 1% 389k ± 0% -0.67% (p=0.008 n=5+5) Change-Id: Idc36186ca9d2f8214b5f7720bbc27b6bb22fdc48 Reviewed-on: https://go-review.googlesource.com/40697 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2017-04-14 06:35:53 -07:00
off = duint8LSym(s, off, uint8(word>>(uint(j)%32)))
}
return off
}
func stringsym(s string) (data *obj.LSym) {
var symname string
if len(s) > 100 {
// Huge strings are hashed to avoid long names in object files.
// Indulge in some paranoia by writing the length of s, too,
// as protection against length extension attacks.
h := sha256.New()
io.WriteString(h, s)
symname = fmt.Sprintf(".gostring.%d.%x", len(s), h.Sum(nil))
} else {
// Small strings get named directly by their contents.
symname = strconv.Quote(s)
}
const prefix = "go.string."
symdataname := prefix + symname
symdata := Ctxt.Lookup(symdataname)
if !symdata.SeenGlobl() {
// string data
off := dsnameLSym(symdata, 0, s)
ggloblLSym(symdata, int32(off), obj.DUPOK|obj.RODATA|obj.LOCAL)
}
return symdata
}
var slicebytes_gen int
func slicebytes(nam *Node, s string, len int) {
slicebytes_gen++
symname := fmt.Sprintf(".gobytes.%d", slicebytes_gen)
sym := localpkg.Lookup(symname)
sym.Def = asTypesNode(newname(sym))
off := dsname(sym, 0, s)
ggloblsym(sym, int32(off), obj.NOPTR|obj.LOCAL)
if nam.Op != ONAME {
Fatalf("slicebytes %v", nam)
}
off = int(nam.Xoffset)
off = dsymptr(nam.Sym, off, sym, 0)
off = duintxx(nam.Sym, off, uint64(len), Widthint)
duintxx(nam.Sym, off, uint64(len), Widthint)
}
func dsname(s *types.Sym, off int, t string) int {
return dsnameLSym(Linksym(s), off, t)
}
func dsnameLSym(s *obj.LSym, off int, t string) int {
s.WriteString(Ctxt, int64(off), len(t), t)
return off + len(t)
}
func dsymptr(s *types.Sym, off int, x *types.Sym, xoff int) int {
return dsymptrLSym(Linksym(s), off, Linksym(x), xoff)
}
func dsymptrLSym(s *obj.LSym, off int, x *obj.LSym, xoff int) int {
off = int(Rnd(int64(off), int64(Widthptr)))
s.WriteAddr(Ctxt, int64(off), Widthptr, x, int64(xoff))
off += Widthptr
return off
}
func dsymptrOffLSym(s *obj.LSym, off int, x *obj.LSym, xoff int) int {
s.WriteOff(Ctxt, int64(off), x, int64(xoff))
off += 4
return off
}
func dsymptrWeakOffLSym(s *obj.LSym, off int, x *obj.LSym) int {
s.WriteWeakOff(Ctxt, int64(off), x, 0)
off += 4
return off
}
func gdata(nam *Node, nr *Node, wid int) {
cmd/compile: write some static data directly Instead of generating ADATA instructions for static data, write that static data directly into the linker sym. This is considerably more efficient. The assembler still generates ADATA instructions, so the ADATA machinery cannot be dismantled yet. (Future work.) Skipping ADATA has a significant impact compiling the unicode package, which has lots of static data. name old time/op new time/op delta Unicode 227ms ±10% 192ms ± 4% -15.61% (p=0.000 n=29+30) name old alloc/op new alloc/op delta Unicode 51.0MB ± 0% 45.8MB ± 0% -10.29% (p=0.000 n=30+30) name old allocs/op new allocs/op delta Unicode 610k ± 0% 578k ± 0% -5.29% (p=0.000 n=30+30) This does not pass toolstash -cmp, because this changes the order in which some relocations get added, and thus it changes the output from the compiler. It is not worth the execution time to sort the relocs in the normal case. However, compiling with -S -v generates identical output if (1) you suppress printing of ADATA progs in flushplist and (2) you suppress printing of cpu timing. It is reasonable to suppress printing the ADATA progs, since the data itself is dumped later. I am therefore fairly confident that all changes are superficial and non-functional. Fixes #14786, although there's more to do in general. Change-Id: I8dfabe7b423b31a30e516cfdf005b62a2e9ccd82 Reviewed-on: https://go-review.googlesource.com/20645 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2016-03-13 12:16:43 -07:00
if nam.Op != ONAME {
Fatalf("gdata nam op %v", nam.Op)
cmd/compile: write some static data directly Instead of generating ADATA instructions for static data, write that static data directly into the linker sym. This is considerably more efficient. The assembler still generates ADATA instructions, so the ADATA machinery cannot be dismantled yet. (Future work.) Skipping ADATA has a significant impact compiling the unicode package, which has lots of static data. name old time/op new time/op delta Unicode 227ms ±10% 192ms ± 4% -15.61% (p=0.000 n=29+30) name old alloc/op new alloc/op delta Unicode 51.0MB ± 0% 45.8MB ± 0% -10.29% (p=0.000 n=30+30) name old allocs/op new allocs/op delta Unicode 610k ± 0% 578k ± 0% -5.29% (p=0.000 n=30+30) This does not pass toolstash -cmp, because this changes the order in which some relocations get added, and thus it changes the output from the compiler. It is not worth the execution time to sort the relocs in the normal case. However, compiling with -S -v generates identical output if (1) you suppress printing of ADATA progs in flushplist and (2) you suppress printing of cpu timing. It is reasonable to suppress printing the ADATA progs, since the data itself is dumped later. I am therefore fairly confident that all changes are superficial and non-functional. Fixes #14786, although there's more to do in general. Change-Id: I8dfabe7b423b31a30e516cfdf005b62a2e9ccd82 Reviewed-on: https://go-review.googlesource.com/20645 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2016-03-13 12:16:43 -07:00
}
if nam.Sym == nil {
Fatalf("gdata nil nam sym")
}
s := Linksym(nam.Sym)
cmd/compile: write some static data directly Instead of generating ADATA instructions for static data, write that static data directly into the linker sym. This is considerably more efficient. The assembler still generates ADATA instructions, so the ADATA machinery cannot be dismantled yet. (Future work.) Skipping ADATA has a significant impact compiling the unicode package, which has lots of static data. name old time/op new time/op delta Unicode 227ms ±10% 192ms ± 4% -15.61% (p=0.000 n=29+30) name old alloc/op new alloc/op delta Unicode 51.0MB ± 0% 45.8MB ± 0% -10.29% (p=0.000 n=30+30) name old allocs/op new allocs/op delta Unicode 610k ± 0% 578k ± 0% -5.29% (p=0.000 n=30+30) This does not pass toolstash -cmp, because this changes the order in which some relocations get added, and thus it changes the output from the compiler. It is not worth the execution time to sort the relocs in the normal case. However, compiling with -S -v generates identical output if (1) you suppress printing of ADATA progs in flushplist and (2) you suppress printing of cpu timing. It is reasonable to suppress printing the ADATA progs, since the data itself is dumped later. I am therefore fairly confident that all changes are superficial and non-functional. Fixes #14786, although there's more to do in general. Change-Id: I8dfabe7b423b31a30e516cfdf005b62a2e9ccd82 Reviewed-on: https://go-review.googlesource.com/20645 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2016-03-13 12:16:43 -07:00
switch nr.Op {
case OLITERAL:
switch u := nr.Val().U.(type) {
case bool:
i := int64(obj.Bool2int(u))
s.WriteInt(Ctxt, nam.Xoffset, wid, i)
cmd/compile: write some static data directly Instead of generating ADATA instructions for static data, write that static data directly into the linker sym. This is considerably more efficient. The assembler still generates ADATA instructions, so the ADATA machinery cannot be dismantled yet. (Future work.) Skipping ADATA has a significant impact compiling the unicode package, which has lots of static data. name old time/op new time/op delta Unicode 227ms ±10% 192ms ± 4% -15.61% (p=0.000 n=29+30) name old alloc/op new alloc/op delta Unicode 51.0MB ± 0% 45.8MB ± 0% -10.29% (p=0.000 n=30+30) name old allocs/op new allocs/op delta Unicode 610k ± 0% 578k ± 0% -5.29% (p=0.000 n=30+30) This does not pass toolstash -cmp, because this changes the order in which some relocations get added, and thus it changes the output from the compiler. It is not worth the execution time to sort the relocs in the normal case. However, compiling with -S -v generates identical output if (1) you suppress printing of ADATA progs in flushplist and (2) you suppress printing of cpu timing. It is reasonable to suppress printing the ADATA progs, since the data itself is dumped later. I am therefore fairly confident that all changes are superficial and non-functional. Fixes #14786, although there's more to do in general. Change-Id: I8dfabe7b423b31a30e516cfdf005b62a2e9ccd82 Reviewed-on: https://go-review.googlesource.com/20645 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2016-03-13 12:16:43 -07:00
case *Mpint:
s.WriteInt(Ctxt, nam.Xoffset, wid, u.Int64())
case *Mpflt:
f := u.Float64()
cmd/compile: write some static data directly Instead of generating ADATA instructions for static data, write that static data directly into the linker sym. This is considerably more efficient. The assembler still generates ADATA instructions, so the ADATA machinery cannot be dismantled yet. (Future work.) Skipping ADATA has a significant impact compiling the unicode package, which has lots of static data. name old time/op new time/op delta Unicode 227ms ±10% 192ms ± 4% -15.61% (p=0.000 n=29+30) name old alloc/op new alloc/op delta Unicode 51.0MB ± 0% 45.8MB ± 0% -10.29% (p=0.000 n=30+30) name old allocs/op new allocs/op delta Unicode 610k ± 0% 578k ± 0% -5.29% (p=0.000 n=30+30) This does not pass toolstash -cmp, because this changes the order in which some relocations get added, and thus it changes the output from the compiler. It is not worth the execution time to sort the relocs in the normal case. However, compiling with -S -v generates identical output if (1) you suppress printing of ADATA progs in flushplist and (2) you suppress printing of cpu timing. It is reasonable to suppress printing the ADATA progs, since the data itself is dumped later. I am therefore fairly confident that all changes are superficial and non-functional. Fixes #14786, although there's more to do in general. Change-Id: I8dfabe7b423b31a30e516cfdf005b62a2e9ccd82 Reviewed-on: https://go-review.googlesource.com/20645 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2016-03-13 12:16:43 -07:00
switch nam.Type.Etype {
case TFLOAT32:
s.WriteFloat32(Ctxt, nam.Xoffset, float32(f))
case TFLOAT64:
s.WriteFloat64(Ctxt, nam.Xoffset, f)
}
case *Mpcplx:
r := u.Real.Float64()
i := u.Imag.Float64()
switch nam.Type.Etype {
case TCOMPLEX64:
s.WriteFloat32(Ctxt, nam.Xoffset, float32(r))
s.WriteFloat32(Ctxt, nam.Xoffset+4, float32(i))
case TCOMPLEX128:
s.WriteFloat64(Ctxt, nam.Xoffset, r)
s.WriteFloat64(Ctxt, nam.Xoffset+8, i)
}
case string:
symdata := stringsym(u)
s.WriteAddr(Ctxt, nam.Xoffset, Widthptr, symdata, 0)
s.WriteInt(Ctxt, nam.Xoffset+int64(Widthptr), Widthint, int64(len(u)))
cmd/compile: write some static data directly Instead of generating ADATA instructions for static data, write that static data directly into the linker sym. This is considerably more efficient. The assembler still generates ADATA instructions, so the ADATA machinery cannot be dismantled yet. (Future work.) Skipping ADATA has a significant impact compiling the unicode package, which has lots of static data. name old time/op new time/op delta Unicode 227ms ±10% 192ms ± 4% -15.61% (p=0.000 n=29+30) name old alloc/op new alloc/op delta Unicode 51.0MB ± 0% 45.8MB ± 0% -10.29% (p=0.000 n=30+30) name old allocs/op new allocs/op delta Unicode 610k ± 0% 578k ± 0% -5.29% (p=0.000 n=30+30) This does not pass toolstash -cmp, because this changes the order in which some relocations get added, and thus it changes the output from the compiler. It is not worth the execution time to sort the relocs in the normal case. However, compiling with -S -v generates identical output if (1) you suppress printing of ADATA progs in flushplist and (2) you suppress printing of cpu timing. It is reasonable to suppress printing the ADATA progs, since the data itself is dumped later. I am therefore fairly confident that all changes are superficial and non-functional. Fixes #14786, although there's more to do in general. Change-Id: I8dfabe7b423b31a30e516cfdf005b62a2e9ccd82 Reviewed-on: https://go-review.googlesource.com/20645 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2016-03-13 12:16:43 -07:00
default:
Fatalf("gdata unhandled OLITERAL %v", nr)
}
cmd/compile: write some static data directly Instead of generating ADATA instructions for static data, write that static data directly into the linker sym. This is considerably more efficient. The assembler still generates ADATA instructions, so the ADATA machinery cannot be dismantled yet. (Future work.) Skipping ADATA has a significant impact compiling the unicode package, which has lots of static data. name old time/op new time/op delta Unicode 227ms ±10% 192ms ± 4% -15.61% (p=0.000 n=29+30) name old alloc/op new alloc/op delta Unicode 51.0MB ± 0% 45.8MB ± 0% -10.29% (p=0.000 n=30+30) name old allocs/op new allocs/op delta Unicode 610k ± 0% 578k ± 0% -5.29% (p=0.000 n=30+30) This does not pass toolstash -cmp, because this changes the order in which some relocations get added, and thus it changes the output from the compiler. It is not worth the execution time to sort the relocs in the normal case. However, compiling with -S -v generates identical output if (1) you suppress printing of ADATA progs in flushplist and (2) you suppress printing of cpu timing. It is reasonable to suppress printing the ADATA progs, since the data itself is dumped later. I am therefore fairly confident that all changes are superficial and non-functional. Fixes #14786, although there's more to do in general. Change-Id: I8dfabe7b423b31a30e516cfdf005b62a2e9ccd82 Reviewed-on: https://go-review.googlesource.com/20645 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2016-03-13 12:16:43 -07:00
case OADDR:
if nr.Left.Op != ONAME {
Fatalf("gdata ADDR left op %v", nr.Left.Op)
cmd/compile: write some static data directly Instead of generating ADATA instructions for static data, write that static data directly into the linker sym. This is considerably more efficient. The assembler still generates ADATA instructions, so the ADATA machinery cannot be dismantled yet. (Future work.) Skipping ADATA has a significant impact compiling the unicode package, which has lots of static data. name old time/op new time/op delta Unicode 227ms ±10% 192ms ± 4% -15.61% (p=0.000 n=29+30) name old alloc/op new alloc/op delta Unicode 51.0MB ± 0% 45.8MB ± 0% -10.29% (p=0.000 n=30+30) name old allocs/op new allocs/op delta Unicode 610k ± 0% 578k ± 0% -5.29% (p=0.000 n=30+30) This does not pass toolstash -cmp, because this changes the order in which some relocations get added, and thus it changes the output from the compiler. It is not worth the execution time to sort the relocs in the normal case. However, compiling with -S -v generates identical output if (1) you suppress printing of ADATA progs in flushplist and (2) you suppress printing of cpu timing. It is reasonable to suppress printing the ADATA progs, since the data itself is dumped later. I am therefore fairly confident that all changes are superficial and non-functional. Fixes #14786, although there's more to do in general. Change-Id: I8dfabe7b423b31a30e516cfdf005b62a2e9ccd82 Reviewed-on: https://go-review.googlesource.com/20645 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2016-03-13 12:16:43 -07:00
}
to := nr.Left
s.WriteAddr(Ctxt, nam.Xoffset, wid, Linksym(to.Sym), to.Xoffset)
cmd/compile: write some static data directly Instead of generating ADATA instructions for static data, write that static data directly into the linker sym. This is considerably more efficient. The assembler still generates ADATA instructions, so the ADATA machinery cannot be dismantled yet. (Future work.) Skipping ADATA has a significant impact compiling the unicode package, which has lots of static data. name old time/op new time/op delta Unicode 227ms ±10% 192ms ± 4% -15.61% (p=0.000 n=29+30) name old alloc/op new alloc/op delta Unicode 51.0MB ± 0% 45.8MB ± 0% -10.29% (p=0.000 n=30+30) name old allocs/op new allocs/op delta Unicode 610k ± 0% 578k ± 0% -5.29% (p=0.000 n=30+30) This does not pass toolstash -cmp, because this changes the order in which some relocations get added, and thus it changes the output from the compiler. It is not worth the execution time to sort the relocs in the normal case. However, compiling with -S -v generates identical output if (1) you suppress printing of ADATA progs in flushplist and (2) you suppress printing of cpu timing. It is reasonable to suppress printing the ADATA progs, since the data itself is dumped later. I am therefore fairly confident that all changes are superficial and non-functional. Fixes #14786, although there's more to do in general. Change-Id: I8dfabe7b423b31a30e516cfdf005b62a2e9ccd82 Reviewed-on: https://go-review.googlesource.com/20645 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2016-03-13 12:16:43 -07:00
case ONAME:
if nr.Class != PFUNC {
Fatalf("gdata NAME not PFUNC %d", nr.Class)
}
s.WriteAddr(Ctxt, nam.Xoffset, wid, Linksym(funcsym(nr.Sym)), nr.Xoffset)
cmd/compile: write some static data directly Instead of generating ADATA instructions for static data, write that static data directly into the linker sym. This is considerably more efficient. The assembler still generates ADATA instructions, so the ADATA machinery cannot be dismantled yet. (Future work.) Skipping ADATA has a significant impact compiling the unicode package, which has lots of static data. name old time/op new time/op delta Unicode 227ms ±10% 192ms ± 4% -15.61% (p=0.000 n=29+30) name old alloc/op new alloc/op delta Unicode 51.0MB ± 0% 45.8MB ± 0% -10.29% (p=0.000 n=30+30) name old allocs/op new allocs/op delta Unicode 610k ± 0% 578k ± 0% -5.29% (p=0.000 n=30+30) This does not pass toolstash -cmp, because this changes the order in which some relocations get added, and thus it changes the output from the compiler. It is not worth the execution time to sort the relocs in the normal case. However, compiling with -S -v generates identical output if (1) you suppress printing of ADATA progs in flushplist and (2) you suppress printing of cpu timing. It is reasonable to suppress printing the ADATA progs, since the data itself is dumped later. I am therefore fairly confident that all changes are superficial and non-functional. Fixes #14786, although there's more to do in general. Change-Id: I8dfabe7b423b31a30e516cfdf005b62a2e9ccd82 Reviewed-on: https://go-review.googlesource.com/20645 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2016-03-13 12:16:43 -07:00
default:
Fatalf("gdata unhandled op %v %v\n", nr, nr.Op)
cmd/compile: write some static data directly Instead of generating ADATA instructions for static data, write that static data directly into the linker sym. This is considerably more efficient. The assembler still generates ADATA instructions, so the ADATA machinery cannot be dismantled yet. (Future work.) Skipping ADATA has a significant impact compiling the unicode package, which has lots of static data. name old time/op new time/op delta Unicode 227ms ±10% 192ms ± 4% -15.61% (p=0.000 n=29+30) name old alloc/op new alloc/op delta Unicode 51.0MB ± 0% 45.8MB ± 0% -10.29% (p=0.000 n=30+30) name old allocs/op new allocs/op delta Unicode 610k ± 0% 578k ± 0% -5.29% (p=0.000 n=30+30) This does not pass toolstash -cmp, because this changes the order in which some relocations get added, and thus it changes the output from the compiler. It is not worth the execution time to sort the relocs in the normal case. However, compiling with -S -v generates identical output if (1) you suppress printing of ADATA progs in flushplist and (2) you suppress printing of cpu timing. It is reasonable to suppress printing the ADATA progs, since the data itself is dumped later. I am therefore fairly confident that all changes are superficial and non-functional. Fixes #14786, although there's more to do in general. Change-Id: I8dfabe7b423b31a30e516cfdf005b62a2e9ccd82 Reviewed-on: https://go-review.googlesource.com/20645 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2016-03-13 12:16:43 -07:00
}
}