The benchmarks don't permit clear-cut apples-to-apples
comparisons since they depend on the very source code
they are testing. But they do give an indication of
the approximate performance - as a sanity test.
Using 3 different code bases makes it apparent that
there's some difference in performance per code base;
i.e., the lines/s speed varies pretty strongly. This
may be due to setup costs, or other issues. We should
investigate eventually.
R=adonovan
CC=golang-dev
https://golang.org/cl/30650043
Cause: emitExtract requires a type for each component of the
receive tuple; blank supplies no such type.
Solution: remove type parameter for emitExtract as it is no
longer needed: since rev b75cc03b4a56 it is always identical
to the tuple.Type().At(index).
+ tests.
Fixesgolang/go#6806.
R=gri, gri
CC=axwalk, golang-dev
https://golang.org/cl/30410043
This removes about 5% of φ-nodes in one large program
and eliminates many zero-value constants.
(This does cause some Idents to no longer map to an ssa.Value.
This is observable in the oracle, whose tests are here updated.)
R=gri, gri
CC=golang-dev
https://golang.org/cl/26980043
Add explicit options to Corpus to control search indexing of documentation, Go source code, and full-text.
R=bradfitz, r
CC=golang-dev
https://golang.org/cl/24190043
Users should be familiar with the sizes of all other types.
Currently we assume amd64 (as do other parts of the oracle,
e.g. go/build tags). Will parameterize later.
R=crawshaw
CC=golang-dev, gri
https://golang.org/cl/29710043
Also: Use defer to make sure scopes are always closed
even in case of early exits via bailout (and don't cause
an imbalanced scope error in debug mode).
R=adonovan, gri
CC=golang-dev
https://golang.org/cl/29300043
- consolidate them in (expr|type)string[_test].go
- support for printing all ast.Expr
- fix printing of type: chan (<-chan int) (parentheses)
- more consistent names, comments, and exports
R=adonovan
CC=golang-dev
https://golang.org/cl/28680043
Tests will still pass because it's marked as known broken,
but it will log the unexpected for now.
R=golang-dev, crawshaw
CC=golang-dev
https://golang.org/cl/27330043
Details:
- use relative (non-qualified) names in more places
- Member interface now has Package(), RelString() methods.
- (*Function).DumpTo: add "# Package: " header.
- Added sanity checks for String functions.
R=gri, gri
CC=golang-dev
https://golang.org/cl/26380043
These are variants of Type.String(), Object.String() that
accept a 'from *Package' argument. If provided, package
qualification is omitted when printing named types belonging
to that package.
This is useful for UIs where a package is implied by context
e.g. ssadump disassembly, oracle output.
+ Test.
R=gri, gri, gordon.klaus
CC=golang-dev
https://golang.org/cl/22190048
The previous code introduced spurious loop-carried
dependencies for variables local to a loop body (for example).
The SSA renaming pass now treats an Alloc instruction like a
Store of the zero value.
Also:
- added regression test
- improved log messages
- made the Store/Load/Alloc cases look more similar.
R=gri, gri
CC=golang-dev
https://golang.org/cl/26750043
- fixed a couple of TODOs
- various cleanups along the way
- adjusted clients
Once submitted, clients of go/types that don't explicitly
specify Config.Import will need to add the extra import:
import _ "code.google.com/p/go.tools/go/gcimporter"
to install the default (gc) importer in go/types.
R=adonovan, gri
CC=golang-dev
https://golang.org/cl/26390043
Also, only examine functions defined in *_test.go files.
Added tests for empty and nonempty behaviour of CreateTestMainPackage.
(Required some surgery to interp_test.)
R=gri, gri
CC=golang-dev
https://golang.org/cl/25570044
Depending on the context, printing only the package name can
be ambiguous or even incorrect since it is valid only within
the environment of a given file's import specs.
(The standard library packages are mostly unique in their last
segment, but this is not the case for proprietary repos.)
R=gri, gri
CC=golang-dev
https://golang.org/cl/26300043
This check is currently done in go/parser as well but
eventually can be removed from there (after Go 1.2).
R=adonovan
CC=golang-dev
https://golang.org/cl/22240045
Performance increase is much smaller than expected;
need to investigate. Possibly, repeatedly (for each
line) accessing file sets from multiple goroutines
(in the scanner) is a bottle neck; or perhaps i/o.
R=adonovan
CC=golang-dev
https://golang.org/cl/23090043
