aboutsummaryrefslogtreecommitdiff
path: root/src/cmd/compile/internal/types/sym.go
AgeCommit message (Collapse)Author
2021-06-03[dev.typeparams] cmd/compile: allow nil Syms in Sym.LessMatthew Dempsky
Allows sorting interfaces that contain embedded anonymous types. Fixes #46556. Change-Id: If19afa1d62432323b2e98957087867afbf3f9097 Reviewed-on: https://go-review.googlesource.com/c/go/+/324812 Trust: Matthew Dempsky <mdempsky@google.com> Trust: Dan Scales <danscales@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dan Scales <danscales@google.com>
2021-05-07cmd/compile: improving the documentation of various fields and functionsDan Scales
This is only changes to comments, so should be fine to go into 1.17. Change-Id: I01e28dc76b03fb3ca846d976f8ac84bc2acb2ea2 Reviewed-on: https://go-review.googlesource.com/c/go/+/318009 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2021-03-29cmd/compile: restructure ABI wrapper generation, export ABIAustin Clements
This CL restructures how we track function ABIs and generate ABI wrappers in the compiler and adds import/export of ABIs across package boundaries. Currently, we start by tracking definition and referencing ABIs in two global maps and eventually move some of this information into the LSyms for functions. This complicates a lot of the existing code for handling wrappers and makes it particularly hard to export ABI information across packages. This change is built around instead recording this information on the ir.Func. First, this change replaces the global ABI def/ref maps with a type, which makes the data flow and lifetime of this information clear in gc.Main. These are populated during flag parsing. Then, early in the front-end, we loop over all ir.Funcs to 1. attach ABI def/ref information to the ir.Funcs and 2. create new ir.Funcs for ABI wrappers. Step 1 is slightly subtle because the information is keyed by linker symbol names, so we can't simply look things up in the compiler's regular symbol table. By generating ABI wrappers early in the front-end, we decouple this step from LSym creation, which makes LSym creation much simpler (like it was before ABI wrappers). In particular, LSyms for wrappers are now created at the same time as all other functions instead of by makeABIWrapper, which means we're back to the simpler, old situation where InitLSym was the only thing responsible for constructing function LSyms. Hence, we can restore the check that InitLSym is called exactly once per function. Attaching the ABI information to the ir.Func has several follow-on benefits: 1. It's now easy to include in the export info. This enables direct cross-package cross-ABI calls, which are important for the performance of calling various hot assembly functions (e.g., internal/bytealg.*). This was really the point of this whole change. 2. Since all Funcs, including wrappers, now record their definition ABI, callTargetLSym no longer needs to distinguish wrappers from non-wrappers, so it's now nearly trivial (it would be completely trivial except that it has to work around a handful of cases where ir.Name.Func is nil). The simplification of callTargetLSym has one desirable but potentially surprising side-effect: the compiler will now generate direct calls to the definition ABI even when ABI wrappers are turned off. This is almost completely unnoticeable except that cmd/internal/obj/wasm looks for the call from runtime.deferreturn (defined in Go) to runtime.jmpdefer (defined in assembly) to compile is specially. That now looks like a direct call to ABI0 rather than going through the ABIInternal alias. While we're in here, we also set up the structures to support more than just ABI0 and ABIInternal and add various additional consistency checks all around. Performance-wise, this reduces the overhead induced by wrappers from 1.24% geomean (on Sweet) to 0.52% geomean, and reduces the number of benchmarks impacts >2% from 5 to 3. It has no impact on compiler speed. Impact of wrappers before this change: name old time/op new time/op delta BiogoIgor 15.8s ± 2% 15.8s ± 1% ~ (p=0.863 n=25+25) BiogoKrishna 18.3s ± 6% 18.1s ± 7% -1.39% (p=0.015 n=25+25) BleveIndexBatch100 5.88s ± 3% 6.04s ± 6% +2.72% (p=0.000 n=25+25) BleveQuery 6.42s ± 1% 6.76s ± 1% +5.31% (p=0.000 n=24+24) CompileTemplate 245ms ± 3% 250ms ± 6% ~ (p=0.068 n=22+25) CompileUnicode 93.6ms ± 2% 93.9ms ± 5% ~ (p=0.958 n=22+25) CompileGoTypes 1.60s ± 2% 1.59s ± 2% ~ (p=0.115 n=24+24) CompileCompiler 104ms ± 4% 104ms ± 3% ~ (p=0.453 n=22+25) CompileSSA 11.0s ± 2% 11.0s ± 1% ~ (p=0.789 n=24+25) CompileFlate 153ms ± 2% 153ms ± 1% ~ (p=0.055 n=21+20) CompileGoParser 229ms ± 2% 230ms ± 2% ~ (p=0.305 n=21+22) CompileReflect 585ms ± 5% 582ms ± 3% ~ (p=0.365 n=25+25) CompileTar 211ms ± 1% 211ms ± 3% ~ (p=0.592 n=20+22) CompileXML 282ms ± 3% 281ms ± 2% ~ (p=0.937 n=22+23) CompileStdCmd 13.7s ± 3% 13.6s ± 2% ~ (p=0.700 n=25+25) FoglemanFauxGLRenderRotateBoat 8.67s ± 1% 8.78s ± 1% +1.30% (p=0.000 n=25+25) FoglemanPathTraceRenderGopherIter1 20.5s ± 2% 20.9s ± 2% +1.85% (p=0.000 n=25+25) GopherLuaKNucleotide 30.1s ± 2% 31.1s ± 2% +3.38% (p=0.000 n=25+25) MarkdownRenderXHTML 246ms ± 5% 250ms ± 1% +1.42% (p=0.002 n=25+23) Tile38WithinCircle100kmRequest 828µs ± 6% 885µs ± 6% +6.85% (p=0.000 n=23+25) Tile38IntersectsCircle100kmRequest 1.04ms ± 5% 1.10ms ± 7% +5.63% (p=0.000 n=25+25) Tile38KNearestLimit100Request 974µs ± 4% 972µs ± 4% ~ (p=0.356 n=25+24) [Geo mean] 588ms 595ms +1.24% (https://perf.golang.org/search?q=upload:20210328.5) And after this change: name old time/op new time/op delta BiogoIgor 15.9s ± 1% 15.8s ± 1% -0.48% (p=0.008 n=22+25) BiogoKrishna 18.4s ± 6% 17.8s ± 6% -3.55% (p=0.008 n=25+25) BleveIndexBatch100 5.86s ± 3% 5.97s ± 4% +1.88% (p=0.001 n=25+25) BleveQuery 6.42s ± 1% 6.75s ± 1% +5.14% (p=0.000 n=25+25) CompileTemplate 246ms ± 5% 245ms ± 2% ~ (p=0.472 n=23+23) CompileUnicode 93.7ms ± 3% 93.5ms ± 2% ~ (p=0.813 n=22+23) CompileGoTypes 1.60s ± 2% 1.60s ± 2% ~ (p=0.108 n=25+23) CompileCompiler 104ms ± 3% 104ms ± 2% ~ (p=0.845 n=23+23) CompileSSA 11.0s ± 2% 11.0s ± 2% ~ (p=0.525 n=25+25) CompileFlate 152ms ± 1% 153ms ± 2% ~ (p=0.408 n=22+22) CompileGoParser 230ms ± 1% 230ms ± 1% ~ (p=0.363 n=21+23) CompileReflect 582ms ± 3% 584ms ± 4% ~ (p=0.658 n=25+25) CompileTar 212ms ± 2% 211ms ± 2% ~ (p=0.315 n=23+24) CompileXML 282ms ± 1% 282ms ± 1% ~ (p=0.991 n=23+22) CompileStdCmd 13.6s ± 2% 13.6s ± 2% ~ (p=0.699 n=25+24) FoglemanFauxGLRenderRotateBoat 8.66s ± 1% 8.69s ± 1% +0.28% (p=0.002 n=25+24) FoglemanPathTraceRenderGopherIter1 20.5s ± 3% 20.5s ± 2% ~ (p=0.407 n=25+25) GopherLuaKNucleotide 30.1s ± 2% 31.2s ± 2% +3.82% (p=0.000 n=25+25) MarkdownRenderXHTML 246ms ± 3% 245ms ± 1% ~ (p=0.478 n=23+22) Tile38WithinCircle100kmRequest 820µs ± 4% 856µs ± 5% +4.39% (p=0.000 n=24+25) Tile38IntersectsCircle100kmRequest 1.05ms ± 6% 1.07ms ± 6% +1.91% (p=0.014 n=25+25) Tile38KNearestLimit100Request 970µs ± 4% 970µs ± 3% ~ (p=0.819 n=22+24) [Geo mean] 588ms 591ms +0.52% (https://perf.golang.org/search?q=upload:20210328.6) For #40724. Change-Id: I1c374e32d4bbc88efed062a1b360017d3642140d Reviewed-on: https://go-review.googlesource.com/c/go/+/305274 Trust: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Cherry Zhang <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org>
2021-03-29cmd/compile: update a few stale commentsAustin Clements
CL 64811 removed dcopy. Update the comment in types.Sym. The Russquake moved iexport.go. Update the path to it. WRAPPER is now also used by ABI wrappers, so update the comment since it's now more general than method wrappers. Change-Id: Ie0df61dcef7168f6720838cd5c9a66adf546a44f Reviewed-on: https://go-review.googlesource.com/c/go/+/305269 Trust: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2021-01-19[dev.regabi] cmd/compile: refactor Linksym creationMatthew Dempsky
Currently there's a lot of logic within package types for creating Linksyms. This CL pulls it out into base, where it can be more easily reused by other compiler code that shouldn't need to depend on package types. Package base probably isn't the best place for this, but it's convenient because it's a package that types already depends on. It's also where the Ctxt object lives, which these functions depend upon. Passes toolstash -cmp w/ -gcflags=all=-abiwrap. Change-Id: I50d8b7e4596955205036969eab24d7dab053b363 Reviewed-on: https://go-review.googlesource.com/c/go/+/284231 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> Trust: Matthew Dempsky <mdempsky@google.com>
2020-12-29[dev.regabi] cmd/compile: add Linksym helpersMatthew Dempsky
Syms are meant to be just interned (pkg, name) tuples, and are a purely abstract, Go-language concept. As such, associating them with linker symbols (a low-level, implementation-oriented detail) is inappropriate. There's still work to be done before linker symbols can be directly attached to their appropriate, higher-level objects instead. But in the mean-time, we can at least add helper functions and discourage folks from using Sym.Linksym directly. The next CL will mechanically rewrite code to use these helpers where possible. Passes toolstash -cmp. Change-Id: I413bd1c80bce056304f9a7343526bd153f2b9c7d Reviewed-on: https://go-review.googlesource.com/c/go/+/280639 Trust: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2020-12-29[dev.regabi] cmd/compile: remove Sym.ImportdefMatthew Dempsky
Evidently it hasn't been needed since circa 2018, when we removed the binary export data format. Change-Id: I4e4c788d6b6233340fb0de0a56d035c31d96f761 Reviewed-on: https://go-review.googlesource.com/c/go/+/280634 Trust: Matthew Dempsky <mdempsky@google.com> Trust: Dan Scales <danscales@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dan Scales <danscales@google.com>
2020-12-22[dev.regabi] cmd/compile,cmd/link: initial support for ABI wrappersThan McIntosh
Add compiler support for emitting ABI wrappers by creating real IR as opposed to introducing ABI aliases. At the moment these are "no-op" wrappers in the sense that they make a simple call (using the existing ABI) to their target. The assumption here is that once late call expansion can handle both ABI0 and the "new" ABIInternal (register version), it can expand the call to do the right thing. Note that the runtime contains functions that do not strictly follow the rules of the current Go ABI0; this has been handled in most cases by treating these as ABIInternal instead (these changes have been made in previous patches). Generation of ABI wrappers (as opposed to ABI aliases) is currently gated by GOEXPERIMENT=regabi -- wrapper generation is on by default if GOEXPERIMENT=regabi is set and off otherwise (but can be turned on using "-gcflags=all=-abiwrap -ldflags=-abiwrap"). Wrapper generation currently only workd on AMD64; explicitly enabling wrapper for other architectures (via the command line) is not supported. Also in this patch are a few other command line options for debugging (tracing and/or limiting wrapper creation). These will presumably go away at some point. Updates #27539, #40724. Change-Id: I1ee3226fc15a3c32ca2087b8ef8e41dbe6df4a75 Reviewed-on: https://go-review.googlesource.com/c/go/+/270863 Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com> Trust: Than McIntosh <thanm@google.com>
2020-12-15[dev.regabi] cmd/compile: use ir.Ident for imported identifiersMatthew Dempsky
This CL substantially reworks how imported declarations are handled, and fixes a number of issues with dot imports. In particular: 1. It eliminates the stub ir.Name declarations that are created upfront during import-declaration processing, allowing this to be deferred to when the declarations are actually needed. (Eventually, this can be deferred even further so we never have to create ir.Names w/ ONONAME, but this CL is already invasive/subtle enough.) 2. During noding, we now use ir.Idents to represent uses of imported declarations, including of dot-imported declarations. 3. Unused dot imports are now reported after type checking, so that we can correctly distinguish whether composite literal keys are a simple identifier (struct literals) or expressions (array/slice/map literals) and whether it might be a use of a dot-imported declaration. 4. It changes the "redeclared" error messages to report the previous position information in the same style as other compiler error messages that reference other source lines. Passes buildall w/ toolstash -cmp. Fixes #6428. Fixes #43164. Fixes #43167. Updates #42990. Change-Id: I40a0a780ec40daf5700fbc3cfeeb7300e1055981 Reviewed-on: https://go-review.googlesource.com/c/go/+/277713 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org> Trust: Matthew Dempsky <mdempsky@google.com>
2020-12-07[dev.regabi] cmd/compile: narrow interface between ir and typesRuss Cox
Narrow the interface between package ir and package types to make it easier to clean up the type formatting code all in one place. Also introduce ir.BlankSym for use by OrigSym, so that later OrigSym can move to package types without needing to reference a variable of type ir.Node. Passes buildall w/ toolstash -cmp. Change-Id: I39fa419a1c8fb3318203e31cacc8d06399deeff9 Reviewed-on: https://go-review.googlesource.com/c/go/+/275776 Trust: Russ Cox <rsc@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2020-12-01[dev.regabi] cmd/compile: first pass at abstracting TypeMatthew Dempsky
Passes toolstash/buildall. [git-generate] cd src/cmd/compile/internal/ssa rf ' ex . ../ir ../gc { import "cmd/compile/internal/types" var t *types.Type t.Etype -> t.Kind() t.Sym -> t.GetSym() t.Orig -> t.Underlying() } ' cd ../types rf ' mv EType Kind mv IRNode Object mv Type.Etype Type.kind mv Type.Sym Type.sym mv Type.Orig Type.underlying mv Type.Cache Type.cache mv Type.GetSym Type.Sym mv Bytetype ByteType mv Runetype RuneType mv Errortype ErrorType ' cd ../gc sed -i 's/Bytetype/ByteType/; s/Runetype/RuneType/' mkbuiltin.go git codereview gofmt go install cmd/compile/internal/... go test cmd/compile -u || go test cmd/compile Change-Id: Ibecb2d7100d3318a49238eb4a78d70acb49eedca Reviewed-on: https://go-review.googlesource.com/c/go/+/274437 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Russ Cox <rsc@golang.org> Trust: Matthew Dempsky <mdempsky@google.com>
2020-11-30[dev.regabi] cmd/compile: cleanup label handlingRuss Cox
- The use of a label's Name.Defn to point at the named for/select/switch means that any rewrite of the for/select/switch must overwrite the original or else the pointer will dangle. Remove that pointer by adding the label name directly to the for/select/switch representation instead. - The only uses of a label's Sym.Label were ephemeral values during markbreak and escape analysis. Use a map for each. Although in general we are not going to replace all computed fields with maps (too slow), the one in markbreak is only for labeled for/select/switch, and the one in escape is for all labels, but even so, labels are fairly rare. In theory this cleanup should make it easy to allow labeled for/select/switch in inlined bodies, but this CL does not attempt that. It's only concerned with cleanup to enable a new Node representation. Passes buildall w/ toolstash -cmp. Change-Id: I7e36ee98d2ea40dbae94e6722d585f007b7afcfa Reviewed-on: https://go-review.googlesource.com/c/go/+/274086 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2020-11-25[dev.regabi] cmd/compile: convert types.Node (a pointer) to types.IRNode (an ↵Russ Cox
interface) The pointer hack was nice and saved a word, but it's untenable in a world where nodes are themselves interfaces with different underlying types. Bite the bullet and use an interface to hold the Node when in types.Sym and types.Type. This has the nice benefit of removing AsTypesNode entirely. AsNode is still useful because of its nil handling. Change-Id: I298cba9ff788b956ee287283bec78010e8b601e5 Reviewed-on: https://go-review.googlesource.com/c/go/+/272933 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2019-10-03[dev.link] cmd/compile: fix data race on LSym.PkgCherry Zhang
LSym may be created concurrently. Reading/writing LSym.Pkg may cause data race (see https://build.golang.org/log/f0351c5cc7bf4c92e3aa5e78e294c2d009ebf118). Fix this by setting LSym.Pkg only when holding the lock. Change-Id: Ib3160ecf47c4ca530b09369e0e8284db6597cfd0 Reviewed-on: https://go-review.googlesource.com/c/go/+/198492 Reviewed-by: Than McIntosh <thanm@google.com>
2019-10-02[dev.link] cmd/compile, cmd/asm: assign index to symbolsCherry Zhang
We are planning to use indices for symbol references, instead of symbol names. Here we assign indices to symbols defined in the package being compiled, and propagate the indices to the dependent packages in the export data. A symbol is referenced by a tuple, (package index, symbol index). Normally, for a given symbol, this index is unique, and the symbol index is globally consistent (but with exceptions, see below). The package index is local to a compilation. For example, when compiling the fmt package, fmt.Println gets assigned index 25, then all packages that reference fmt.Println will refer it as (X, 25) with some X. X is the index for the fmt package, which may differ in different compilations. There are some symbols that do not have clear package affiliation, such as dupOK symbols and linknamed symbols. We cannot give them globally consistent indices. We categorize them as non-package symbols, assign them with package index 1 and a symbol index that is only meaningful locally. Currently nothing will consume the indices. All this is behind a flag, -newobj. The flag needs to be set for all builds (-gcflags=all=-newobj -asmflags=all=-newobj), or none. Change-Id: I18e489c531e9a9fbc668519af92c6116b7308cab Reviewed-on: https://go-review.googlesource.com/c/go/+/196029 Reviewed-by: Than McIntosh <thanm@google.com>
2019-09-03cmd/compile,runtime: generate hash functions only for types which are map keysKeith Randall
Right now we generate hash functions for all types, just in case they are used as map keys. That's a lot of wasted effort and binary size for types which will never be used as a map key. Instead, generate hash functions only for types that we know are map keys. Just doing that is a bit too simple, since maps with an interface type as a key might have to hash any concrete key type that implements that interface. So for that case, implement hashing of such types at runtime (instead of with generated code). It will be slower, but only for maps with interface types as keys, and maybe only a bit slower as the aeshash time probably dominates the dispatch time. Reorg where we keep the equals and hash functions. Move the hash function from the key type to the map type, saving a field in every non-map type. That leaves only one function in the alg structure, so get rid of that and just keep the equal function in the type descriptor itself. cmd/go now has 10 generated hash functions, instead of 504. Makes cmd/go 1.0% smaller. Update #6853. Speed on non-interface keys is unchanged. Speed on interface keys is ~20% slower: name old time/op new time/op delta MapInterfaceString-8 23.0ns ±21% 27.6ns ±14% +20.01% (p=0.002 n=10+10) MapInterfacePtr-8 19.4ns ±16% 23.7ns ± 7% +22.48% (p=0.000 n=10+8) Change-Id: I7c2e42292a46b5d4e288aaec4029bdbb01089263 Reviewed-on: https://go-review.googlesource.com/c/go/+/191198 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Martin Möhrmann <moehrmann@google.com>
2019-05-21cmd/compile: clarify the difference between types.Sym and obj.LSymLE Manh Cuong
Both types.Sym and obj.LSym have the field Name, and that field is widely used in compiler source. It can lead to confusion that when to use which one. So, adding documentation for clarifying the difference between them, eliminate the confusion, or at least, make the code which use them clearer for the reader. See https://github.com/golang/go/issues/31252#issuecomment-481929174 Change-Id: I31f7fc6e4de4cf68f67ab2e3a385a7f451c796f5 Reviewed-on: https://go-review.googlesource.com/c/go/+/175019 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2019-01-11cmd/compile: separate data and function LSymsAustin Clements
Currently, obj.Ctxt's symbol table does not distinguish between ABI0 and ABIInternal symbols. This is *almost* okay, since a given symbol name in the final object file is only going to belong to one ABI or the other, but it requires that the compiler mark a Sym as being a function symbol before it retrieves its LSym. If it retrieves the LSym first, that LSym will be created as ABI0, and later marking the Sym as a function symbol won't change the LSym's ABI. Marking a Sym as a function symbol before looking up its LSym sounds easy, except Syms have a dual purpose: they are used just as interned strings (every function, variable, parameter, etc with the same textual name shares a Sym), and *also* to store state for whatever package global has that name. As a result, it's easy to slip up and look up an LSym when a Sym is serving as the name of a local variable, and then later mark it as a function when it's serving as the global with the name. In general, we were careful to avoid this, but #29610 demonstrates one case where we messed up. Because of on-demand importing from indexed export data, it's possible to compile a method wrapper for a type imported from another package before importing an init function from that package. If the argument of the method is named "init", the "init" LSym will be created as a data symbol when compiling the wrapper, before it gets marked as a function symbol. To fix this, we separate obj.Ctxt's symbol tables for ABI0 and ABIInternal symbols. This way, the compiler will simply get a different LSym once the Sym takes on its package-global meaning as a function. This fixes the above ordering issue, and means we no longer need to go out of our way to create the "init" function early and mark it as a function symbol. Fixes #29610. Updates #27539. Change-Id: Id9458b40017893d46ef9e4a3f9b47fc49e1ce8df Reviewed-on: https://go-review.googlesource.com/c/157017 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2018-11-12cmd/compile, cmd/link: separate stable and internal ABIsAustin Clements
This implements compiler and linker support for separating the function calling ABI into two ABIs: a stable and an internal ABI. At the moment, the two ABIs are identical, but we'll be able to evolve the internal ABI without breaking existing assembly code that depends on the stable ABI for calling to and from Go. The Go compiler generates internal ABI symbols for all Go functions. It uses the symabis information produced by the assembler to create ABI wrappers whenever it encounters a body-less Go function that's defined in assembly or a Go function that's referenced from assembly. Since the two ABIs are currently identical, for the moment this is implemented using "ABI alias" symbols, which are just forwarding references to the native ABI symbol for a function. This way there's no actual code involved in the ABI wrapper, which is good because we're not deriving any benefit from it right now. Once the ABIs diverge, we can eliminate ABI aliases. The linker represents these different ABIs internally as different versions of the same symbol. This way, the linker keeps us honest, since every symbol definition and reference also specifies its version. The linker is responsible for resolving ABI aliases. Fixes #27539. Change-Id: I197c52ec9f8fc435db8f7a4259029b20f6d65e95 Reviewed-on: https://go-review.googlesource.com/c/147160 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2018-11-12cmd/compile: mark function SymsAustin Clements
In order to mark the obj.LSyms produced by the compiler with the correct ABI, we need to know which types.Syms refer to function symbols. This CL adds a flag to types.Syms to mark symbols for functions, and sets this flag everywhere we create a PFUNC-class node, and in the one place where we directly create function symbols without always wrapping them in a PFUNC node (methodSym). We'll use this information to construct obj.LSyms with correct ABI information. For #27539. Change-Id: Ie3ac8bf3da013e449e78f6ca85546a055f275463 Reviewed-on: https://go-review.googlesource.com/c/147158 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2018-11-01cmd/compile: document Sym flagsAustin Clements
Change-Id: Id14b417095628c7a1dc7a8e47bc28cfa392b5262 Reviewed-on: https://go-review.googlesource.com/c/146498 Reviewed-by: Robert Griesemer <gri@golang.org>
2018-04-10cmd/compile: sort method sets using package heightMatthew Dempsky
Also, when statically building itabs, compare *types.Sym instead of name alone so that method sets with duplicate non-exported methods are handled correctly. Fixes #24693. Change-Id: I2db8a3d6e80991a71fef5586a15134b6de116269 Reviewed-on: https://go-review.googlesource.com/105039 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2018-04-09cmd/compile: refactor symbol sorting logicMatthew Dempsky
This used to be duplicated in methcmp and siglt, because Sig used its own representation for Syms. Instead, just use Syms, and add a (*Sym).Less method that both methcmp and siglt can use. Also, prune some impossible cases purportedly related to blank methods: the Go spec disallows blank methods in interface method sets, and addmethod drops blank methods without actually recording them in the type's method set. Passes toolstash-check. Updates #24693. Change-Id: I24e981659b68504d71518160486989a82505f513 Reviewed-on: https://go-review.googlesource.com/105936 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-09cmd/compile: rename gc.exportname to types.IsExportedMatthew Dempsky
gofmt -r 'exportname(s) -> types.IsExported(s)' Passes toolstash-check. Change-Id: I6b428bd039c135be66d8b81c325d4e08bae69f24 Reviewed-on: https://go-review.googlesource.com/105938 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-02cmd/compile: simplify exportsym flags and logicMatthew Dempsky
We used to have three Sym flags for dealing with export/reexport: Export, Package, and Exported. Export and Package were used to distinguish whether a symbol is exported or package-scope (i.e., mutually exclusive), except that for local declarations Export served double-duty as tracking whether the symbol had been added to exportlist. Meanwhile, imported declarations that needed reexporting could be added to exportlist multiple times, necessitating a flag to track whether they'd already been written out by exporter. Simplify all of these into a single OnExportList flag so that we can ensure symbols on exportlist are present exactly once. Merge reexportsym into exportsym so there's a single place where we append to exportlist. Code that used to set Exported to prevent a symbol from being exported can now just set OnExportList before calling declare to prevent it from even appearing on exportlist. Lastly, drop the IsAlias check in exportsym: we call exportsym too early for local symbols to detect if they're an alias, and we never reexport aliases. Passes toolstash-check. Change-Id: Icdea3719105dc169fcd7651606589cd08b0a80ff Reviewed-on: https://go-review.googlesource.com/103865 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2017-09-20cmd/compile/internal/types: simplify dclstackMatthew Dempsky
We used to backup symbol declarations using complete Syms, but this was unnecessary: very few of Sym's fields were actually needed. Also, to restore a symbol, we had to re-Lookup the Sym in its Pkg. By introducing a new dedicated dsym type for this purpose, we can address both of these deficiencies. Passes toolstash-check. Change-Id: I39f3d672b301f84a3a62b9b34b4b2770cb25df79 Reviewed-on: https://go-review.googlesource.com/64811 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2017-05-22cmd/compile: report correct position in redeclaration errorsRobert Griesemer
When restoring syms, we must also restore the original Lastlineno. Bug introduced with https://golang.org/cl/41390/. Fixes #20415. Change-Id: Ie81d36279d717e330951b52f42dcee4b0025b9f0 Reviewed-on: https://go-review.googlesource.com/43811 Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2017-04-23cmd/compile: remove types.Sym.lsymJosh Bleecher Snyder
It was just a cache, and the CL series yesterday removed 40% of the calls to types.Linksym in make.bash. Testing atop CL 40693 (backend concurrency) indicates that removing it is actually a very minor performance improvement. Passes toolstash-check. Change-Id: I97c2973036964acdd11b3cb842bc31f33ae60389 Reviewed-on: https://go-review.googlesource.com/41492 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2017-04-21cmd/compile/internal/types: remove unused lineno arguments for PushDcl/MarkDclRobert Griesemer
More steps towards simpler symbol handling: - Pushdcl's incoming pos argument, saved in a newly pushed *Sym, was always immediately overwritten by the Lastlineno value of the saved *Sym. - Markdcl's incoming pos argument, saved in the stack mark *Sym, was not restored when the stack mark was popped. - Popdcl always maintained the most recent Lastlineno for a *Sym given by package and name, making it unnecessary to save Lastlineno in the first place. Removed Lastlineno from the set of fields that need saving, and simplified Popdcl. Change-Id: Ie93da1fbd780dcafc2703044e781c0c6298df569 Reviewed-on: https://go-review.googlesource.com/41390 Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2017-04-21cmd/compile: unexport types.Sym.LSymJosh Bleecher Snyder
Response to code review feedback on CL 40693. Remove the final reference to it from package gc, and manually unexport. Passes toolstash-check. Change-Id: I7fc48edd43263d8f7c56b47aeb7573408463dc22 Reviewed-on: https://go-review.googlesource.com/41303 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2017-04-21cmd/compile: move Linksym, linksymname, and isblanksym to types packageJosh Bleecher Snyder
Response to code review feedback on CL 40693. This CL was prepared by: (1) manually adding new implementations and the Ctxt var to package types (2) running eg with template: func before(s *types.Sym) *obj.LSym { return gc.Linksym(s) } func after(s *types.Sym) *obj.LSym { return s.Linksym() } (3) running gofmt -r: gofmt -r 'isblanksym(a) -> a.IsBlank()' (4) manually removing old implementations from package gc Passes toolstash-check. Change-Id: I39c35def7cae5bcbcc7c77253e5d2b066b981dea Reviewed-on: https://go-review.googlesource.com/41302 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2017-04-19cmd/compile/internal/types: remove Sym.Link fieldRobert Griesemer
The dclstack is now a proper stack and thus we can implement it using a slice rather than a linked list. Change-Id: I200e85621ff76c111bdeb7eb382fd82da438f3ba Reviewed-on: https://go-review.googlesource.com/41135 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2017-04-07cmd/compile: factor out Pkg, Sym, and Type into package typesRobert Griesemer
- created new package cmd/compile/internal/types - moved Pkg, Sym, Type to new package - to break cycles, for now we need the (ugly) types/utils.go file which contains a handful of functions that must be installed early by the gc frontend - to break cycles, for now we need two functions to convert between *gc.Node and *types.Node (the latter is a dummy type) - adjusted the gc's code to use the new package and the conversion functions as needed - made several Pkg, Sym, and Type methods functions as needed - renamed constructors typ, typPtr, typArray, etc. to types.New, types.NewPtr, types.NewArray, etc. Passes toolstash-check -all. Change-Id: I8adfa5e85c731645d0a7fd2030375ed6ebf54b72 Reviewed-on: https://go-review.googlesource.com/39855 Reviewed-by: Matthew Dempsky <mdempsky@google.com>