Stowage/go
2
0
Fork 0
mirror of https://github.com/golang/go.git synced 2025-12-08 06:10:04 +00:00
Code Issues Projects Releases Packages Wiki Activity
go/src/cmd/compile/internal/ssa/config.go

86 lines
2.5 KiB
Go
Raw Normal View History

[dev.ssa] cmd/internal/gc: convert standard IR into SSA. Hook into the current compiler to convert the existing IR (after walk) into SSA. Any function ending in "_ssa" will take this path. The resulting assembly is printed and then discarded. Use gc.Type directly in ssa instead of a wrapper for go types. It makes the IR->SSA rewrite a lot simpler. Only a few opcodes are implemented in this change. It is enough to compile simple examples like func f(p *int) int { return *p } func g(a []int, i int) int { return a[i] } Change-Id: I5e18841b752a83ca0519aa1b2d36ef02ce1de6f9 Reviewed-on: https://go-review.googlesource.com/8971 Reviewed-by: Alan Donovan <adonovan@google.com>
2015-04-15 15:51:25 -07:00
// Copyright 2015 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
package ssa
type Config struct {
[dev.ssa] cmd/compile: move most types outside SSA The only types that remain in the ssa package are special compiler-only types. Change-Id: If957abf128ec0778910d67666c297f97f183b7ee Reviewed-on: https://go-review.googlesource.com/12933 Reviewed-by: Keith Randall <khr@golang.org>
2015-07-30 11:03:05 -07:00
arch string // "amd64", etc.
IntSize int64 // 4 or 8
PtrSize int64 // 4 or 8
[dev.ssa] cmd/internal/ssa: add string operations Add ops to load, store, select ptr & len, and build constant strings. A few other minor cleanups. Change-Id: I6f0f7419d641b119b613ed44561cd308a466051c Reviewed-on: https://go-review.googlesource.com/10449 Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
2015-05-27 14:52:22 -07:00
lowerBlock func(*Block) bool // lowering function
lowerValue func(*Value, *Config) bool // lowering function
fe Frontend // callbacks into compiler frontend
[dev.ssa] cmd/internal/gc: convert standard IR into SSA. Hook into the current compiler to convert the existing IR (after walk) into SSA. Any function ending in "_ssa" will take this path. The resulting assembly is printed and then discarded. Use gc.Type directly in ssa instead of a wrapper for go types. It makes the IR->SSA rewrite a lot simpler. Only a few opcodes are implemented in this change. It is enough to compile simple examples like func f(p *int) int { return *p } func g(a []int, i int) int { return a[i] } Change-Id: I5e18841b752a83ca0519aa1b2d36ef02ce1de6f9 Reviewed-on: https://go-review.googlesource.com/8971 Reviewed-by: Alan Donovan <adonovan@google.com>
2015-04-15 15:51:25 -07:00
// TODO: more stuff. Compiler flags of interest, ...
}
[dev.ssa] cmd/compile: move most types outside SSA The only types that remain in the ssa package are special compiler-only types. Change-Id: If957abf128ec0778910d67666c297f97f183b7ee Reviewed-on: https://go-review.googlesource.com/12933 Reviewed-by: Keith Randall <khr@golang.org>
2015-07-30 11:03:05 -07:00
type TypeSource interface {
TypeBool() Type
TypeInt8() Type
TypeInt16() Type
TypeInt32() Type
TypeInt64() Type
TypeUInt8() Type
TypeUInt16() Type
TypeUInt32() Type
TypeUInt64() Type
TypeInt() Type
TypeUintptr() Type
TypeString() Type
TypeBytePtr() Type // TODO: use unsafe.Pointer instead?
}
[dev.ssa] cmd/internal/ssa: add string operations Add ops to load, store, select ptr & len, and build constant strings. A few other minor cleanups. Change-Id: I6f0f7419d641b119b613ed44561cd308a466051c Reviewed-on: https://go-review.googlesource.com/10449 Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
2015-05-27 14:52:22 -07:00
type Frontend interface {
[dev.ssa] cmd/compile: move most types outside SSA The only types that remain in the ssa package are special compiler-only types. Change-Id: If957abf128ec0778910d67666c297f97f183b7ee Reviewed-on: https://go-review.googlesource.com/12933 Reviewed-by: Keith Randall <khr@golang.org>
2015-07-30 11:03:05 -07:00
TypeSource
[dev.ssa] cmd/compile: use string contents instead of offset from string header This generates more efficient code. Before: 0x003a 00058 (rr.go:7) LEAQ go.string.hdr."="(SB), BX 0x0041 00065 (rr.go:7) LEAQ 16(BX), BP 0x0045 00069 (rr.go:7) MOVQ BP, 16(SP) After: 0x003a 00058 (rr.go:7) LEAQ go.string."="(SB), BX 0x0041 00065 (rr.go:7) MOVQ BX, 16(SP) It also matches the existing backend and is more robust to other changes, such as CL 11698, which I believe broke the current code. This CL fixes the encoding/base64 tests, as run with: GOGC=off GOSSAPKG=base64 go test -a encoding/base64 Change-Id: I3c475bed1dd3335cc14e13309e11d23f0ed32c17 Reviewed-on: https://go-review.googlesource.com/12654 Reviewed-by: Keith Randall <khr@golang.org>
2015-07-24 11:28:12 -07:00
// StringData returns a symbol pointing to the given string's contents.
StringData(string) interface{} // returns *gc.Sym
[dev.ssa] cmd/compile/ssa: separate logging, work in progress, and fatal errors The SSA implementation logs for three purposes: * debug logging * fatal errors * unimplemented features Separating these three uses lets us attempt an SSA implementation for all functions, not just _ssa functions. This turns the entire standard library into a compilation test, and makes it easy to figure out things like "how much coverage does SSA have now" and "what should we do next to get more coverage?". Functions called _ssa are still special. They log profusely by default and the output of the SSA implementation is used. For all other functions, logging is off, and the implementation is built and discarded, due to lack of support for the runtime. While we're here, fix a few minor bugs and add some extra Unimplementeds to allow all.bash to pass. As of now, SSA handles 20.79% of the functions in the standard library (689 of 3314). The top missing features are: 10.03% 2597 SSA unimplemented: zero for type error not implemented 7.79% 2016 SSA unimplemented: addr: bad op DOTPTR 7.33% 1898 SSA unimplemented: unhandled expr EQ 6.10% 1579 SSA unimplemented: unhandled expr OROR 4.91% 1271 SSA unimplemented: unhandled expr NE 4.49% 1163 SSA unimplemented: unhandled expr LROT 4.00% 1036 SSA unimplemented: unhandled expr LEN 3.56% 923 SSA unimplemented: unhandled stmt CALLFUNC 2.37% 615 SSA unimplemented: zero for type []byte not implemented 1.90% 492 SSA unimplemented: unhandled stmt CALLMETH 1.74% 450 SSA unimplemented: unhandled expr CALLINTER 1.74% 450 SSA unimplemented: unhandled expr DOT 1.71% 444 SSA unimplemented: unhandled expr ANDAND 1.65% 426 SSA unimplemented: unhandled expr CLOSUREVAR 1.54% 400 SSA unimplemented: unhandled expr CALLMETH 1.51% 390 SSA unimplemented: unhandled stmt SWITCH 1.47% 380 SSA unimplemented: unhandled expr CONV 1.33% 345 SSA unimplemented: addr: bad op * 1.30% 336 SSA unimplemented: unhandled OLITERAL 6 Change-Id: I4ca07951e276714dc13c31de28640aead17a1be7 Reviewed-on: https://go-review.googlesource.com/11160 Reviewed-by: Keith Randall <khr@golang.org>
2015-06-12 11:01:13 -07:00
// Log logs a message from the compiler.
[dev.ssa] cmd/compile/ssa: add -f suffix to logging methods Requested in CL 11380. Change-Id: Icf0d23fb8d383c76272401e363cc9b2169d11403 Reviewed-on: https://go-review.googlesource.com/11450 Reviewed-by: Alan Donovan <adonovan@google.com>
2015-06-24 14:03:39 -07:00
Logf(string, ...interface{})
[dev.ssa] cmd/compile/ssa: separate logging, work in progress, and fatal errors The SSA implementation logs for three purposes: * debug logging * fatal errors * unimplemented features Separating these three uses lets us attempt an SSA implementation for all functions, not just _ssa functions. This turns the entire standard library into a compilation test, and makes it easy to figure out things like "how much coverage does SSA have now" and "what should we do next to get more coverage?". Functions called _ssa are still special. They log profusely by default and the output of the SSA implementation is used. For all other functions, logging is off, and the implementation is built and discarded, due to lack of support for the runtime. While we're here, fix a few minor bugs and add some extra Unimplementeds to allow all.bash to pass. As of now, SSA handles 20.79% of the functions in the standard library (689 of 3314). The top missing features are: 10.03% 2597 SSA unimplemented: zero for type error not implemented 7.79% 2016 SSA unimplemented: addr: bad op DOTPTR 7.33% 1898 SSA unimplemented: unhandled expr EQ 6.10% 1579 SSA unimplemented: unhandled expr OROR 4.91% 1271 SSA unimplemented: unhandled expr NE 4.49% 1163 SSA unimplemented: unhandled expr LROT 4.00% 1036 SSA unimplemented: unhandled expr LEN 3.56% 923 SSA unimplemented: unhandled stmt CALLFUNC 2.37% 615 SSA unimplemented: zero for type []byte not implemented 1.90% 492 SSA unimplemented: unhandled stmt CALLMETH 1.74% 450 SSA unimplemented: unhandled expr CALLINTER 1.74% 450 SSA unimplemented: unhandled expr DOT 1.71% 444 SSA unimplemented: unhandled expr ANDAND 1.65% 426 SSA unimplemented: unhandled expr CLOSUREVAR 1.54% 400 SSA unimplemented: unhandled expr CALLMETH 1.51% 390 SSA unimplemented: unhandled stmt SWITCH 1.47% 380 SSA unimplemented: unhandled expr CONV 1.33% 345 SSA unimplemented: addr: bad op * 1.30% 336 SSA unimplemented: unhandled OLITERAL 6 Change-Id: I4ca07951e276714dc13c31de28640aead17a1be7 Reviewed-on: https://go-review.googlesource.com/11160 Reviewed-by: Keith Randall <khr@golang.org>
2015-06-12 11:01:13 -07:00
// Fatal reports a compiler error and exits.
[dev.ssa] cmd/compile/ssa: add -f suffix to logging methods Requested in CL 11380. Change-Id: Icf0d23fb8d383c76272401e363cc9b2169d11403 Reviewed-on: https://go-review.googlesource.com/11450 Reviewed-by: Alan Donovan <adonovan@google.com>
2015-06-24 14:03:39 -07:00
Fatalf(string, ...interface{})
[dev.ssa] cmd/compile/ssa: separate logging, work in progress, and fatal errors The SSA implementation logs for three purposes: * debug logging * fatal errors * unimplemented features Separating these three uses lets us attempt an SSA implementation for all functions, not just _ssa functions. This turns the entire standard library into a compilation test, and makes it easy to figure out things like "how much coverage does SSA have now" and "what should we do next to get more coverage?". Functions called _ssa are still special. They log profusely by default and the output of the SSA implementation is used. For all other functions, logging is off, and the implementation is built and discarded, due to lack of support for the runtime. While we're here, fix a few minor bugs and add some extra Unimplementeds to allow all.bash to pass. As of now, SSA handles 20.79% of the functions in the standard library (689 of 3314). The top missing features are: 10.03% 2597 SSA unimplemented: zero for type error not implemented 7.79% 2016 SSA unimplemented: addr: bad op DOTPTR 7.33% 1898 SSA unimplemented: unhandled expr EQ 6.10% 1579 SSA unimplemented: unhandled expr OROR 4.91% 1271 SSA unimplemented: unhandled expr NE 4.49% 1163 SSA unimplemented: unhandled expr LROT 4.00% 1036 SSA unimplemented: unhandled expr LEN 3.56% 923 SSA unimplemented: unhandled stmt CALLFUNC 2.37% 615 SSA unimplemented: zero for type []byte not implemented 1.90% 492 SSA unimplemented: unhandled stmt CALLMETH 1.74% 450 SSA unimplemented: unhandled expr CALLINTER 1.74% 450 SSA unimplemented: unhandled expr DOT 1.71% 444 SSA unimplemented: unhandled expr ANDAND 1.65% 426 SSA unimplemented: unhandled expr CLOSUREVAR 1.54% 400 SSA unimplemented: unhandled expr CALLMETH 1.51% 390 SSA unimplemented: unhandled stmt SWITCH 1.47% 380 SSA unimplemented: unhandled expr CONV 1.33% 345 SSA unimplemented: addr: bad op * 1.30% 336 SSA unimplemented: unhandled OLITERAL 6 Change-Id: I4ca07951e276714dc13c31de28640aead17a1be7 Reviewed-on: https://go-review.googlesource.com/11160 Reviewed-by: Keith Randall <khr@golang.org>
2015-06-12 11:01:13 -07:00
// Unimplemented reports that the function cannot be compiled.
// It will be removed once SSA work is complete.
[dev.ssa] cmd/compile/ssa: add -f suffix to logging methods Requested in CL 11380. Change-Id: Icf0d23fb8d383c76272401e363cc9b2169d11403 Reviewed-on: https://go-review.googlesource.com/11450 Reviewed-by: Alan Donovan <adonovan@google.com>
2015-06-24 14:03:39 -07:00
Unimplementedf(msg string, args ...interface{})
[dev.ssa] cmd/internal/ssa: add string operations Add ops to load, store, select ptr & len, and build constant strings. A few other minor cleanups. Change-Id: I6f0f7419d641b119b613ed44561cd308a466051c Reviewed-on: https://go-review.googlesource.com/10449 Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
2015-05-27 14:52:22 -07:00
}
[dev.ssa] cmd/internal/gc: convert standard IR into SSA. Hook into the current compiler to convert the existing IR (after walk) into SSA. Any function ending in "_ssa" will take this path. The resulting assembly is printed and then discarded. Use gc.Type directly in ssa instead of a wrapper for go types. It makes the IR->SSA rewrite a lot simpler. Only a few opcodes are implemented in this change. It is enough to compile simple examples like func f(p *int) int { return *p } func g(a []int, i int) int { return a[i] } Change-Id: I5e18841b752a83ca0519aa1b2d36ef02ce1de6f9 Reviewed-on: https://go-review.googlesource.com/8971 Reviewed-by: Alan Donovan <adonovan@google.com>
2015-04-15 15:51:25 -07:00
// NewConfig returns a new configuration object for the given architecture.
[dev.ssa] cmd/internal/ssa: add string operations Add ops to load, store, select ptr & len, and build constant strings. A few other minor cleanups. Change-Id: I6f0f7419d641b119b613ed44561cd308a466051c Reviewed-on: https://go-review.googlesource.com/10449 Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
2015-05-27 14:52:22 -07:00
func NewConfig(arch string, fe Frontend) *Config {
c := &Config{arch: arch, fe: fe}
[dev.ssa] cmd/internal/gc: convert standard IR into SSA. Hook into the current compiler to convert the existing IR (after walk) into SSA. Any function ending in "_ssa" will take this path. The resulting assembly is printed and then discarded. Use gc.Type directly in ssa instead of a wrapper for go types. It makes the IR->SSA rewrite a lot simpler. Only a few opcodes are implemented in this change. It is enough to compile simple examples like func f(p *int) int { return *p } func g(a []int, i int) int { return a[i] } Change-Id: I5e18841b752a83ca0519aa1b2d36ef02ce1de6f9 Reviewed-on: https://go-review.googlesource.com/8971 Reviewed-by: Alan Donovan <adonovan@google.com>
2015-04-15 15:51:25 -07:00
switch arch {
case "amd64":
[dev.ssa] cmd/compile/internal/ssa: redo how sign extension is handled For integer types less than a machine register, we have to decide what the invariants are for the high bits of the register. We used to set the high bits to the correct extension (sign or zero, as determined by the type) of the low bits. This CL makes the compiler ignore the high bits of the register altogether (they are junk). On this plus side, this means ops that generate subword results don't have to worry about correctly extending them. On the minus side, ops that consume subword arguments have to deal with the input registers not being correctly extended. For x86, this tradeoff is probably worth it. Almost all opcodes have versions that use only the correct subword piece of their inputs. (The one big exception is array indexing.) Not many opcodes can correctly sign extend on output. For other architectures, the tradeoff is probably not so clear, as they don't have many subword-safe opcodes (e.g. 16-bit compare, ignoring the high 16/48 bits). Fortunately we can decide whether we do this per-architecture. For the machine-independent opcodes, we pretend that the "register" size is equal to the type width, so sign extension is immaterial. Opcodes that care about the signedness of the input (e.g. compare, right shift) have two different variants. Change-Id: I465484c5734545ee697afe83bc8bf4b53bd9df8d Reviewed-on: https://go-review.googlesource.com/12600 Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
2015-07-23 14:35:02 -07:00
c.IntSize = 8
[dev.ssa] cmd/compile/internal/ssa: use width and sign specific opcodes Bake the bit width and signedness into opcodes. Pro: Rewrite rules become easier. Less chance for confusion. Con: Lots more opcodes. Let me know what you think. I'm leaning towards this, but I could be convinced otherwise if people think this is too ugly. Update #11467 Change-Id: Icf1b894268cdf73515877bb123839800d97b9df9 Reviewed-on: https://go-review.googlesource.com/12362 Reviewed-by: Alan Donovan <adonovan@google.com> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
2015-07-19 15:48:20 -07:00
c.PtrSize = 8
[dev.ssa] cmd/compile/internal/ssa: autogenerate opcodes Revamp autogeneration. Get rid of gogenerate commands, they are more trouble than they are worth. (If the code won't compile, gogenerate doesn't work.) Generate opcode enums & tables. This means we only have to specify opcodes in one place instead of two. Add arch prefixes to opcodes so they will be globally unique. Change-Id: I175d0a89b701b2377bbe699f3756731b7c9f5a9f Reviewed-on: https://go-review.googlesource.com/10812 Reviewed-by: Alan Donovan <adonovan@google.com>
2015-06-06 16:03:33 -07:00
c.lowerBlock = rewriteBlockAMD64
c.lowerValue = rewriteValueAMD64
[dev.ssa] cmd/internal/gc: convert standard IR into SSA. Hook into the current compiler to convert the existing IR (after walk) into SSA. Any function ending in "_ssa" will take this path. The resulting assembly is printed and then discarded. Use gc.Type directly in ssa instead of a wrapper for go types. It makes the IR->SSA rewrite a lot simpler. Only a few opcodes are implemented in this change. It is enough to compile simple examples like func f(p *int) int { return *p } func g(a []int, i int) int { return a[i] } Change-Id: I5e18841b752a83ca0519aa1b2d36ef02ce1de6f9 Reviewed-on: https://go-review.googlesource.com/8971 Reviewed-by: Alan Donovan <adonovan@google.com>
2015-04-15 15:51:25 -07:00
case "386":
[dev.ssa] cmd/compile/internal/ssa: redo how sign extension is handled For integer types less than a machine register, we have to decide what the invariants are for the high bits of the register. We used to set the high bits to the correct extension (sign or zero, as determined by the type) of the low bits. This CL makes the compiler ignore the high bits of the register altogether (they are junk). On this plus side, this means ops that generate subword results don't have to worry about correctly extending them. On the minus side, ops that consume subword arguments have to deal with the input registers not being correctly extended. For x86, this tradeoff is probably worth it. Almost all opcodes have versions that use only the correct subword piece of their inputs. (The one big exception is array indexing.) Not many opcodes can correctly sign extend on output. For other architectures, the tradeoff is probably not so clear, as they don't have many subword-safe opcodes (e.g. 16-bit compare, ignoring the high 16/48 bits). Fortunately we can decide whether we do this per-architecture. For the machine-independent opcodes, we pretend that the "register" size is equal to the type width, so sign extension is immaterial. Opcodes that care about the signedness of the input (e.g. compare, right shift) have two different variants. Change-Id: I465484c5734545ee697afe83bc8bf4b53bd9df8d Reviewed-on: https://go-review.googlesource.com/12600 Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
2015-07-23 14:35:02 -07:00
c.IntSize = 4
[dev.ssa] cmd/compile/internal/ssa: use width and sign specific opcodes Bake the bit width and signedness into opcodes. Pro: Rewrite rules become easier. Less chance for confusion. Con: Lots more opcodes. Let me know what you think. I'm leaning towards this, but I could be convinced otherwise if people think this is too ugly. Update #11467 Change-Id: Icf1b894268cdf73515877bb123839800d97b9df9 Reviewed-on: https://go-review.googlesource.com/12362 Reviewed-by: Alan Donovan <adonovan@google.com> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
2015-07-19 15:48:20 -07:00
c.PtrSize = 4
[dev.ssa] cmd/compile/internal/ssa: autogenerate opcodes Revamp autogeneration. Get rid of gogenerate commands, they are more trouble than they are worth. (If the code won't compile, gogenerate doesn't work.) Generate opcode enums & tables. This means we only have to specify opcodes in one place instead of two. Add arch prefixes to opcodes so they will be globally unique. Change-Id: I175d0a89b701b2377bbe699f3756731b7c9f5a9f Reviewed-on: https://go-review.googlesource.com/10812 Reviewed-by: Alan Donovan <adonovan@google.com>
2015-06-06 16:03:33 -07:00
c.lowerBlock = rewriteBlockAMD64
c.lowerValue = rewriteValueAMD64 // TODO(khr): full 32-bit support
[dev.ssa] cmd/internal/gc: convert standard IR into SSA. Hook into the current compiler to convert the existing IR (after walk) into SSA. Any function ending in "_ssa" will take this path. The resulting assembly is printed and then discarded. Use gc.Type directly in ssa instead of a wrapper for go types. It makes the IR->SSA rewrite a lot simpler. Only a few opcodes are implemented in this change. It is enough to compile simple examples like func f(p *int) int { return *p } func g(a []int, i int) int { return a[i] } Change-Id: I5e18841b752a83ca0519aa1b2d36ef02ce1de6f9 Reviewed-on: https://go-review.googlesource.com/8971 Reviewed-by: Alan Donovan <adonovan@google.com>
2015-04-15 15:51:25 -07:00
default:
[dev.ssa] cmd/compile/ssa: add -f suffix to logging methods Requested in CL 11380. Change-Id: Icf0d23fb8d383c76272401e363cc9b2169d11403 Reviewed-on: https://go-review.googlesource.com/11450 Reviewed-by: Alan Donovan <adonovan@google.com>
2015-06-24 14:03:39 -07:00
fe.Unimplementedf("arch %s not implemented", arch)
[dev.ssa] cmd/internal/gc: convert standard IR into SSA. Hook into the current compiler to convert the existing IR (after walk) into SSA. Any function ending in "_ssa" will take this path. The resulting assembly is printed and then discarded. Use gc.Type directly in ssa instead of a wrapper for go types. It makes the IR->SSA rewrite a lot simpler. Only a few opcodes are implemented in this change. It is enough to compile simple examples like func f(p *int) int { return *p } func g(a []int, i int) int { return a[i] } Change-Id: I5e18841b752a83ca0519aa1b2d36ef02ce1de6f9 Reviewed-on: https://go-review.googlesource.com/8971 Reviewed-by: Alan Donovan <adonovan@google.com>
2015-04-15 15:51:25 -07:00
}
return c
}
[dev.ssa] cmd/compile: add GOSSAFUNC and GOSSAPKG These temporary environment variables make it possible to enable using SSA-generated code for a particular function or package without having to rebuild the compiler. This makes it possible to start bulk testing SSA generated code. First, bump up the default stack size (_StackMin in runtime/stack2.go) to something large like 32768, because without stackmaps we can't grow stacks. Then run something like: for pkg in `go list std` do GOGC=off GOSSAPKG=`basename $pkg` go test -a $pkg done When a test fails, you can re-run those tests, selectively enabling one function after another, until you find the one that is causing trouble. Doing this right now yields some interesting results: * There are several packages for which we generate some code and whose tests pass. Yay! * We can generate code for encoding/base64, but tests there fail, so there's a bug to fix. * Attempting to build the runtime yields a panic during codegen: panic: interface conversion: ssa.Location is nil, not *ssa.LocalSlot * The top unimplemented codegen items are (simplified): 59 genValue not implemented: REPMOVSB 18 genValue not implemented: REPSTOSQ 14 genValue not implemented: SUBQ 9 branch not implemented: If v -> b b. Control: XORQconst <bool> [1] 8 genValue not implemented: MOVQstoreidx8 4 branch not implemented: If v -> b b. Control: SETG <bool> 3 branch not implemented: If v -> b b. Control: SETLE <bool> 2 load flags not implemented: LoadReg8 <flags> 2 genValue not implemented: InvertFlags <flags> 1 store flags not implemented: StoreReg8 <flags> 1 branch not implemented: If v -> b b. Control: SETGE <bool> Change-Id: Ib64809ac0c917e25bcae27829ae634c70d290c7f Reviewed-on: https://go-review.googlesource.com/12547 Reviewed-by: Keith Randall <khr@golang.org>
2015-07-22 13:13:53 -07:00
func (c *Config) Frontend() Frontend { return c.fe }
[dev.ssa] cmd/internal/gc: convert standard IR into SSA. Hook into the current compiler to convert the existing IR (after walk) into SSA. Any function ending in "_ssa" will take this path. The resulting assembly is printed and then discarded. Use gc.Type directly in ssa instead of a wrapper for go types. It makes the IR->SSA rewrite a lot simpler. Only a few opcodes are implemented in this change. It is enough to compile simple examples like func f(p *int) int { return *p } func g(a []int, i int) int { return a[i] } Change-Id: I5e18841b752a83ca0519aa1b2d36ef02ce1de6f9 Reviewed-on: https://go-review.googlesource.com/8971 Reviewed-by: Alan Donovan <adonovan@google.com>
2015-04-15 15:51:25 -07:00
// NewFunc returns a new, empty function object
func (c *Config) NewFunc() *Func {
// TODO(khr): should this function take name, type, etc. as arguments?
return &Func{Config: c}
}
[dev.ssa] cmd/compile/ssa: add -f suffix to logging methods Requested in CL 11380. Change-Id: Icf0d23fb8d383c76272401e363cc9b2169d11403 Reviewed-on: https://go-review.googlesource.com/11450 Reviewed-by: Alan Donovan <adonovan@google.com>
2015-06-24 14:03:39 -07:00
func (c *Config) Logf(msg string, args ...interface{}) { c.fe.Logf(msg, args...) }
func (c *Config) Fatalf(msg string, args ...interface{}) { c.fe.Fatalf(msg, args...) }
func (c *Config) Unimplementedf(msg string, args ...interface{}) { c.fe.Unimplementedf(msg, args...) }
[dev.ssa] cmd/compile/ssa: separate logging, work in progress, and fatal errors The SSA implementation logs for three purposes: * debug logging * fatal errors * unimplemented features Separating these three uses lets us attempt an SSA implementation for all functions, not just _ssa functions. This turns the entire standard library into a compilation test, and makes it easy to figure out things like "how much coverage does SSA have now" and "what should we do next to get more coverage?". Functions called _ssa are still special. They log profusely by default and the output of the SSA implementation is used. For all other functions, logging is off, and the implementation is built and discarded, due to lack of support for the runtime. While we're here, fix a few minor bugs and add some extra Unimplementeds to allow all.bash to pass. As of now, SSA handles 20.79% of the functions in the standard library (689 of 3314). The top missing features are: 10.03% 2597 SSA unimplemented: zero for type error not implemented 7.79% 2016 SSA unimplemented: addr: bad op DOTPTR 7.33% 1898 SSA unimplemented: unhandled expr EQ 6.10% 1579 SSA unimplemented: unhandled expr OROR 4.91% 1271 SSA unimplemented: unhandled expr NE 4.49% 1163 SSA unimplemented: unhandled expr LROT 4.00% 1036 SSA unimplemented: unhandled expr LEN 3.56% 923 SSA unimplemented: unhandled stmt CALLFUNC 2.37% 615 SSA unimplemented: zero for type []byte not implemented 1.90% 492 SSA unimplemented: unhandled stmt CALLMETH 1.74% 450 SSA unimplemented: unhandled expr CALLINTER 1.74% 450 SSA unimplemented: unhandled expr DOT 1.71% 444 SSA unimplemented: unhandled expr ANDAND 1.65% 426 SSA unimplemented: unhandled expr CLOSUREVAR 1.54% 400 SSA unimplemented: unhandled expr CALLMETH 1.51% 390 SSA unimplemented: unhandled stmt SWITCH 1.47% 380 SSA unimplemented: unhandled expr CONV 1.33% 345 SSA unimplemented: addr: bad op * 1.30% 336 SSA unimplemented: unhandled OLITERAL 6 Change-Id: I4ca07951e276714dc13c31de28640aead17a1be7 Reviewed-on: https://go-review.googlesource.com/11160 Reviewed-by: Keith Randall <khr@golang.org>
2015-06-12 11:01:13 -07:00
[dev.ssa] cmd/internal/gc: convert standard IR into SSA. Hook into the current compiler to convert the existing IR (after walk) into SSA. Any function ending in "_ssa" will take this path. The resulting assembly is printed and then discarded. Use gc.Type directly in ssa instead of a wrapper for go types. It makes the IR->SSA rewrite a lot simpler. Only a few opcodes are implemented in this change. It is enough to compile simple examples like func f(p *int) int { return *p } func g(a []int, i int) int { return a[i] } Change-Id: I5e18841b752a83ca0519aa1b2d36ef02ce1de6f9 Reviewed-on: https://go-review.googlesource.com/8971 Reviewed-by: Alan Donovan <adonovan@google.com>
2015-04-15 15:51:25 -07:00
// TODO(khr): do we really need a separate Config, or can we just
// store all its fields inside a Func?
Reference in a new issue Copy permalink