| Age | Commit message (Collapse) | Author |
|---|
|
This moves the package types setup code from package typecheck into
package types itself. This is a prereq for making types.Type more
opaque, because some unit tests depend on being able to init the basic
universal types.
A few notable details of this CL:
1. Creating the builtin types requires being able to create the
ir.Name/ir.OTYPE that represents it, but package types can't depend on
package ir. So we add a callback function to handle creating the
ir.Name.
2. This CL moves ir.Pkgs.Unsafe to types.UnsafePkg. Package unsafe is
part of the language, not like the other ir.Pkgs packages that are
purely implementation details.
3. This CL also moves typecheck.FakeRecv to types.FakeRecv, addressing
an outstanding TODO.
Change-Id: I64de04ce82fbcd1bb59f547e2eea3cda52d89429
Reviewed-on: https://go-review.googlesource.com/c/go/+/345474
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
With types2, some syntax.PosBases need to be constructed from export
data, which must only contain "trimmed" filenames (i.e., that they've
already been made absolute and undergone -trimpath processing).
However, it's not safe to apply trimming to a filename multiple times,
and in general we can't distinguish trimmed from untrimmed filenames.
This CL resolves this by adding a PosBase.Trimmed boolean so we can
distinguish whether the associated filename has been trimmed yet. This
is a bit hacky, but is the least bad solution I've come up with so
far.
This unblocks enabling -G=3 by default.
Change-Id: I7383becfb704680a36f7603e3246af38b21f100b
Reviewed-on: https://go-review.googlesource.com/c/go/+/343731
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
Currently, unified IR takes a simple approach of generating method
wrappers for every anonymous type that it sees. This is correct, but
spends a lot of time in code generation and bloats the object files
with duplicate method wrappers that the linker discards.
This CL changes it to distinguish anonymous types that were found in
imported packages vs the local package. The simple win here is that
now we stop emitting wrappers for imported types; but by keeping track
of them and marking them as "have" instead of "need", we can avoid
emitting wrappers for types that appear in both the local package and
imported packages.
This can be improved further, but this is a simple first step that
prevents large protobuf projects from blowing up build cache limits.
Change-Id: Ia65e8981cb1f067eca2bd072b9bbb77c27b95207
Reviewed-on: https://go-review.googlesource.com/c/go/+/339411
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>
|
|
The code for generating method value wrappers is weird that it sets
sym.Def to the generated ir.Func, whereas normally sym.Def points to
ir.Name.
While here, change methodValueWrapper to return the ir.Name too, since
that's what the caller wants.
Change-Id: I3da5320ca0bf4d32d7b420345454f19075d19a26
Reviewed-on: https://go-review.googlesource.com/c/go/+/339410
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.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>
|
|
This CL changes fixedbugs/issue30862.go into a "runindir" test so that
it can use '-goexperiment fieldtrack' and test that //go:nointerface
works with cmd/compile. In particular, this revealed that -G=3 and
unified IR did not handle it correctly.
This CL also fixes unified IR's support for //go:nointerface and adds
a test that checks that //go:nointerface, promoted methods, and
generics all interact as expected.
Updates #47045.
Change-Id: Ib8acff8ae18bf124520d00c98e8915699cba2abd
Reviewed-on: https://go-review.googlesource.com/c/go/+/332611
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
This CL makes two changes:
1. It moves object symbols and code tags into a new "relocName"
relocation, which should eventually allow getting rid of objStub.
2. It moves the type parameter data into the relocObjDict relocation,
so everything related to writing out dictionaries is contained there.
Change-Id: If0f7ff7d9384e8664957c3180bf6f20e97bcff6e
Reviewed-on: https://go-review.googlesource.com/c/go/+/336051
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>
|
|
unified IR
Records whether a derived type is needed at run-time as well as
instantiated functions that rely on derived types (and thus need
sub-dictionaries).
Change-Id: I2f2036976bfce5b3b4372fba88b4116dafa7e6b7
Reviewed-on: https://go-review.googlesource.com/c/go/+/334349
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>
|
|
There's no point in reading the object dictionary for a stub
declaration. Only the package that contains the full object definition
will contain an object dictionary.
Change-Id: I458b77d20745105bf46190ef552312bdb5ca4d06
Reviewed-on: https://go-review.googlesource.com/c/go/+/334409
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>
|
|
This CL pushes the typecheck.Expr calls further down to the IR
construction points. It turns out we don't really care about
typecheck.AssignExpr, because it's only used to distinguish whether
ir.BlankNode is allowed. We can avoid that issue by just skipping the
call to typecheck.Expr for blank nodes.
Similarly, for typecheck.Callee, only two details matter: (1) don't
report errors for builtin functions (which aren't allowed outside of
callee contexts); and (2) method-value selector expressions need to
have Op ODOTMETH/ODOTINTER rather than OMETHVALUE. The first can be
handled by simply skipping typecheck on Names (as with ir.BlankNode,
we don't need to typecheck these). The second currently requires
adding a 'callee bool' parameter to disambiguate the context.
The other option would be for exprCall to reset the fun's Op from
OMETHVALUE to OXDOT and let typecheck handle it a second time. But I
anticipate needing to add extra logic in the exprSelector case which
would be harder to undo, so this seems somewhat better.
Change-Id: I1a8dfb6af04265ab466fd7f4cb6ee8b479e92282
Reviewed-on: https://go-review.googlesource.com/c/go/+/333769
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Matthew Dempsky <mdempsky@google.com>
|
|
CL 332469 changed the unified IR reader to incrementally typecheck
each statement as they're read/constructed. This CL goes further to
incrementally typecheck each expression.
While here, this CL reorganizes a few things to make this go more
smoothly. In particular, it renames expr to expr0 and adds a new expr
wrapper that applies typecheck.Expr; gets rid of exprTypeSwitchguard
by moving that logic into switchStmt; and splits exprConvert out from
exprCall, which simplifies the logic for typechecking the calleee
expression somewhat.
Change-Id: I6289de9388dc94a947971f4b7213aafeb2faa5dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/333730
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
|
|
Historically, it's been tedious to create and typecheck ir.OCALL
nodes, except by handing them off entirely to typecheck. This is
because typecheck needed context on whether the call is an expression
or statement, and to set flags like Func.ClosureCalled and
CallExpr.Use.
However, those flags have now been removed entirely by recent CLs, so
we can instead just provide a better typecheck.Call function for
constructing and typechecking arbitrary call nodes. Notably, this
simplifies things for unified IR, which can now incrementally
typecheck call expressions as it goes without worrying about context.
Change-Id: Icbdc55c3bd8be84a242323bc45006f9dec09fdcd
Reviewed-on: https://go-review.googlesource.com/c/go/+/332692
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
|
|
The Func.ClosureCalled flag is an optimization used by escape analysis
to detect closures that were directly called, so we know we have
visibility of the result flows. It's not needed by any other phases of
the compiler, so we might as well calculate it within escape analysis
too.
This saves some trouble during IR construction and trying to maintain
the ClosureCalled flag through inlining and copying.
Passes toolstash -cmp.
Change-Id: Ic53cecb7ac439745c0dfba2cd202b9cc40f1e47c
Reviewed-on: https://go-review.googlesource.com/c/go/+/332691
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
|
|
Inlining replaces inlined calls with OINLCALL nodes, and then somewhat
clumsily tries to rewrite these in place without messing up
order-of-evaluation rules.
But handling these rules cleanly is much easier to do during order,
and escape analysis is the only major pass between inlining and
order. It's simpler to teach escape analysis how to analyze OINLCALL
nodes than to try to hide them from escape analysis.
Does not pass toolstash -cmp, but seems to just be line number
changes.
Change-Id: I1986cea39793e3e1ed5e887ba29d46364c6c532e
Reviewed-on: https://go-review.googlesource.com/c/go/+/332649
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Matthew Dempsky <mdempsky@google.com>
|
|
This CL formalizes the closure-var trick used for method-value
wrappers to be reusable for defining other functions that take hidden
parameters via the closure-context register. In particular, it:
1. Adds a new ir.NewHiddenParam function for creating hidden
parameters.
2. Changes ir.NewClosureVar to copy Type/Typecheck from the closure
variable, so that callers can needing to manually copy these.
3. Updates existing code accordingly (i.e., method-value wrappers to
start using ir.NewHiddenParam, and closure builders to stop copying
types).
Longer term, I anticipate using this to pass dictionaries to stenciled
functions within unified IR.
Change-Id: I9da3ffdb2a26d15c6e89a21b4e080686d6dc872c
Reviewed-on: https://go-review.googlesource.com/c/go/+/332612
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>
|
|
This CL changes unified IR to incrementally typecheck the IR as it's
constructed. This is significant, because it means reader can now use
typecheck.Expr to typecheck sub-expressions when it's needed. This
should be helpful for construction and insertion of dictionaries.
This CL does introduce two quirks outside of unified IR itself,
which simplify preserving binary output:
1. Top-level declarations are sorted after they're constructed, to
avoid worrying about the order that closures are added.
2. Zero-padding autotmp_N variable names. Interleaving typechecking
means autotmp variables are sometimes named differently (since their
naming depends on the number of variables declared so far), and this
ensures that code that sorts variables by names doesn't suddenly sort
autotmp_8/autotmp_9 differently than it would have sorted
autotmp_9/autotmp_10.
While at it, this CL also updated reader to use ir.WithFunc instead of
manually setting and restoring ir.CurFunc. There's now only one
remaining direct use of ir.CurFunc.
Change-Id: I6233b4c059596e471c53166f94750917d710462f
Reviewed-on: https://go-review.googlesource.com/c/go/+/332469
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>
|
|
This CL is a first step towards incremental typechecking during IR
construction within unified IR. Namely, all top-level declarations are
now typechecked as they're constructed, except for assignments (which
aren't really declarations anyway).
Change-Id: I65763a7659bf2e0f5e89dfe9e709d60e0fa4c631
Reviewed-on: https://go-review.googlesource.com/c/go/+/332097
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>
|
|
This CL updates the unified IR export data serialization to explicitly
and separately record the derived types used by a declaration. The
readers currently just use this data to construct types/IR the same as
before, but eventually we can use it for emitting GC-shape
dictionaries.
Change-Id: I7d67ad9b3f1fbe69664bf19e056bc94f73507220
Reviewed-on: https://go-review.googlesource.com/c/go/+/331829
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Matthew Dempsky <mdempsky@google.com>
|
|
Method value wrappers will need dictionary support too, so bring them
under the unified IR umbrella as well.
Change-Id: Iec36bb04efdf59843d1b00f55d2c44bc841fa2ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/331190
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Matthew Dempsky <mdempsky@google.com>
|
|
CL 330671 move rewriting method call to method expression to escape
analysis. This CL move the rewriting up further, into typecheck. It
helps simplify the code for dowstream passes, as they now only have to
deal with OCALLFUNC.
There're two notes:
- For -G=3, we can't rewrite d.M() where d is an instantiated receiver
in transformCall, but let irgen.stencil to rewrite it.
- Escape analysis still have to check for rewriting method calls, as
the devirtualization pass can still generate OCALLMETH.
Does not pass toolstash, since when the export data now contains method
expression calls instead of method calls.
Change-Id: I77465ef04d50dc4efedddca7eb55b3fc9483db0e
Reviewed-on: https://go-review.googlesource.com/c/go/+/330831
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
|
|
{Link,Name}String
The original names "ShortString" and "LongString" refer back to the
fmt verbs used to request their formatting styles. However, I always
get confused working with them, in particular because (1) the
"ShortString" description, which uses package-path qualification, is
actually generally longer than the "LongString" description, which
uses package-name qualification; and (2) the documentation mentions
how they're often used, but doesn't actually describe why they're safe
for those purposes.
This CL renames them to "LinkString" and "NameString", respectively,
based on their primary use cases. It also attempts to more completely
describe the strings they return and how they can be used correctly.
Change-Id: I9158ae3eafa8ac53da31a78c7a6d929dc0199afe
Reviewed-on: https://go-review.googlesource.com/c/go/+/330910
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
While initially building out unified IR, I didn't have any indexing
scheme. Everything was written out in order. Consequently, if I wanted
to write A before B, I had to compute A before B.
One particular example of this is handling closure variables: the
reader needs the list of closure variables before it can start reading
the function body, so I had to write them out first, and so I had to
compute them first in a separate, dedicated pass.
However, that constraint went away a while ago. For example, it's now
possible to replace the two-pass closure variable capture with a
single pass. We just write out the function body earlier, but then
wait to write out its index.
I anticipate this approach will make it easier to implement
dictionaries: rather than needing a separate pass to correctly
recognize and handle all of the generics cases, we can just hook into
the existing logic.
Change-Id: Iab1e07f9202cd5d2b6864eef10116960456214df
Reviewed-on: https://go-review.googlesource.com/c/go/+/330851
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>
|
|
This CL extends unified IR to handle creating wrapper methods. There's
relatively little about this code that's actually specific to unified
IR, but rewriting this logic allows a few benefits:
1. It decouples unified IR from reflectdata.methodWrapper, so the
latter code can evolve freely for -G=3's needs. This will also allow
the new code to evolve to unified IR's wrapper needs, which I
anticipate will operate slightly differently.
2. It provided an opportunity to revisit a lot of the code and
simplify/update it to current style. E.g., in the process, I
discovered #46903, which unified IR now gets correctly. (I have not
yet attempted to fix reflectdata.methodWrapper.)
3. It gives a convenient way for unified IR to ensure all of the
wrapper methods it needs are generated correctly.
For now, the wrapper generation is specific to non-quirks mode.
Change-Id: I5798de6b141f29e8eb6a5c563e7049627ff2868a
Reviewed-on: https://go-review.googlesource.com/c/go/+/330569
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>
|
|
CL 329571 fold the checking has type params logic, but did not realize
that the instance in typIdx can be folded, too.
Change-Id: I4682af3779535af6a6e843972cada12ba1bae6ae
Reviewed-on: https://go-review.googlesource.com/c/go/+/330389
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
|
|
Change-Id: Ica9817675b4eb929a000640f9ae873b75fc5a2e3
Reviewed-on: https://go-review.googlesource.com/c/go/+/330290
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
|
|
CaptureName currently does a few things: checks if a variable needs to
be captured at all; checks if the variable has already been captured;
and creates and saves a new variable. This full suite of functionality
is useful for noder and irgen, but unified IR and other backend code
only has a need for the last feature.
This CL refactors CaptureName a little bit and extracts out
NewClosureVar as a function usable for callers that don't need the
extra features of CaptureName.
Change-Id: I8a67c6375e44babe53344bf78e335535c57f9607
Reviewed-on: https://go-review.googlesource.com/c/go/+/330193
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.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>
|
|
Change-Id: I1a7d669879af57a1c1f48ce63ff0d214b694e680
Reviewed-on: https://go-review.googlesource.com/c/go/+/329572
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
|
|
separate method
So making it less verbose and clearer to the reader what that check means.
Change-Id: I41587aab399e63600356c5cecec64978048bed36
Reviewed-on: https://go-review.googlesource.com/c/go/+/329571
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
|
|
Change-Id: Ib9357c21bb010abf0d5fd17c3bee3197854c3a8a
Reviewed-on: https://go-review.googlesource.com/c/go/+/329570
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
|
|
This CL extends the unified export data format's existing sync
mechanism to save writer stacks, controlled by the -d=syncframes debug
flag. This allows readers to provide more details when reporting
desync errors, which should simplify development of the data format
and the various reader/writer implementations.
For example, CL 328051 updated reader and writer, but missed making a
similar change to the linker (fix in CL 328054). Re-reviewing the CL
in isolation after the failure, it was not immediately obvious what
was going wrong. But the pair of stack traces below identifies exactly
what happened: it should have updated linker.relocFuncExt to write out
the new sync marker too.
```
data sync error: package "internal/abi", section 6, index 4, offset 536
found UseReloc, written at:
/home/mdempsky/wd/go/src/cmd/compile/internal/noder/encoder.go:221: (*encoder).reloc +0x44
/home/mdempsky/wd/go/src/cmd/compile/internal/noder/linker.go:214: (*linker).relocFuncExt +0x580
/home/mdempsky/wd/go/src/cmd/compile/internal/noder/linker.go:233: (*linker).relocTypeExt +0x234
/home/mdempsky/wd/go/src/cmd/compile/internal/noder/linker.go:161: (*linker).relocObj +0x2198
/home/mdempsky/wd/go/src/cmd/compile/internal/noder/linker.go:64: (*linker).relocIdx +0x196
expected ImplicitTypes, reading at:
/home/mdempsky/wd/go/src/cmd/compile/internal/noder/reader.go:796: (*reader).implicitTypes +0x36
/home/mdempsky/wd/go/src/cmd/compile/internal/noder/reader.go:810: (*reader).addBody +0x81
/home/mdempsky/wd/go/src/cmd/compile/internal/noder/reader.go:727: (*reader).funcExt +0x542
/home/mdempsky/wd/go/src/cmd/compile/internal/noder/reader.go:651: (*reader).method +0x324
/home/mdempsky/wd/go/src/cmd/compile/internal/noder/reader.go:557: (*pkgReader).objIdx +0x2704
```
Change-Id: I911193edd2a965f81b7459f15fb613a773584685
Reviewed-on: https://go-review.googlesource.com/c/go/+/328909
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
The logic for handling them must keep in sync between reader/writer, so
factoring them out from addBody make it's easier to refer later.
Change-Id: I26447065867d79f4f47cc678a398b9e7bf5d2403
Reviewed-on: https://go-review.googlesource.com/c/go/+/328051
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
|
|
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
|
