In go.dev/cl/421821, I included a hack to force OCONVNOP back to
OCONVIFACE for conversions involving shape types and non-empty
interfaces. The comment correctly noted that this was only needed for
conversions between non-identical types, but the code was conservative
and applied to even conversions between identical types.
This CL adds an extra bool to record whether the conversion is between
identical types, so we can keep OCONVNOP instead of forcing back to
OCONVIFACE. This has a small improvement to generated code, because we
no longer need a convI2I call (as demonstrated by codegen/ifaces.go).
But more usefully, this is relevant to pruning unnecessary itab slots
in runtime dictionaries (next CL).
Change-Id: I94f89e961cd26629b925037fea58d283140766ff
Reviewed-on: https://go-review.googlesource.com/c/go/+/427678
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In go.dev/cl/419674 I added a mechanism to the inliner to allow
inlining to fail gracefully when a function body is missing, but I
missed we already have a mechanism for that: typecheck.HaveInlineBody.
This CL makes it overridable so that unified IR can plug in its
appropriate logic, like it does with the logic for building the
ir.InlinedCallExpr node.
While here, rename inline.NewInline to inline.InlineCall, because the
name "NewInline" is now a misnomer since we initialize it to oldInline
(now named oldInlineCall).
Change-Id: I4e65618d3725919f69e6f43cf409699d20fb797c
Reviewed-on: https://go-review.googlesource.com/c/go/+/427234
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Shape-based stenciling in unified IR is done by converting type argument
to its underlying type. So it agressively check that type argument is
not a TFORW. However, for recursive instantiated type argument, it may
still be a TFORW when shapifying happens. Thus the assertion failed,
causing the compiler crashing.
To fix it, just allow fully instantiated type when shapifying.
Fixes#54512Fixes#54722
Change-Id: I527e3fd696388c8a37454e738f0324f0c2ec16cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/426335
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
When inlining function calls, we rewrite the position information on
all of the nodes to keep track of the inlining context. This is
necessary so that at runtime, we can synthesize additional stack
frames so that the inlining is transparent to the user.
However, for function literals, we *don't* want to apply this
rewriting to the underlying function. Because within the function
literal (when it's not itself inlined), the inlining context (if any)
will have already be available at the caller PC instead.
Unified IR was already getting this right in the case of user-written
statements within the function literal, which is what the unit test
for #46234 tested. However, it was still using inline-adjusted
positions for the function declaration and its parameters, which
occasionally end up getting used for generated code (e.g., loading
captured values from the closure record).
I've manually verified that this fixes the hang in
https://go.dev/play/p/avQ0qgRzOgt, and spot-checked the
-d=pctab=pctoinline output for kube-apiserver and kubelet and they
seem better.
However, I'm still working on a more robust test for this (hence
"Updates" not "Fixes") and internal assertions to verify that we're
emitting correct inline trees. In particular, there are still other
cases (even in the non-unified frontend) where we're producing
corrupt (but at least acyclic) inline trees.
Updates #54625.
Change-Id: Iacfd2e1eb06ae8dc299c0679f377461d3d46c15a
Reviewed-on: https://go-review.googlesource.com/c/go/+/425395
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
In CL 424734, I implemented pointer shaping for unified IR. Evidently
though, we didn't have any test cases that check that uses of
pointer-shaped expressions were handled correctly.
In the reported test case, the struct field "children items[*node[T]]"
gets shaped to "children items[go.shape.*uint8]" (underlying type
"[]go.shape.*uint8"); and so the expression "n.children[i]" has type
"go.shape.*uint8" and the ".items" field selection expression fails.
The fix implemented in this CL is that any expression of derived type
now gets an explicit "reshape" operation applied to it, to ensure it
has the appropriate type for its context. E.g., the "n.children[i]"
OINDEX expression above gets "reshaped" from "go.shape.*uint8" to
"*node[go.shape.int]", allowing the field selection to succeed.
This CL also adds a "-d=reshape" compiler debugging flag, because I
anticipate debugging reshaping operations will be something to come up
again in the future.
Fixes#54535.
Change-Id: Id847bd8f51300d2491d679505ee4d2e974ca972a
Reviewed-on: https://go-review.googlesource.com/c/go/+/424936
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: hopehook <hopehook@qq.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
To disambiguate local types, we append a "·N" suffix to their name and
then trim it off again when producing their runtime type descriptors.
However, if a local type is generic, then we were further appending
the type arguments after this suffix, and the code in types/fmt.go
responsible for trimming didn't know to handle this.
We could extend the types/fmt.go code to look for the "·N" suffix
elsewhere in the type name, but this is risky because it could
legitimately (albeit unlikely) appear in struct field tags.
Instead, the most robust solution is to just change the mangling logic
to keep the "·N" suffix at the end, where types/fmt.go can easily and
reliably trim it.
Note: the "·N" suffix is still visible within the type arguments
list (e.g., the "·3" suffixes in nested.out), because we currently use
the link strings in the type arguments list.
Fixes#54456.
Change-Id: Ie9beaf7e5330982f539bff57b8d48868a3674a37
Reviewed-on: https://go-review.googlesource.com/c/go/+/424901
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Than McIntosh <thanm@google.com>
For local variables of derived type, Delve relies on ir.Name.DictIndex
being set to the type's rtype index within the function's dictionary.
This CL implements that functionality within unified IR.
Manually double checked that Delve behaves correctly, at least as far
as I can tell from casual use. Specifically, I confirmed that running
the test program from TestDictIndex, stepping into testfn, and then
running `print mapvar` prints `map[int]main.CustomInt []`, which
matches the behavior under GOEXPERIMENT=nounified. (Also compare that
when ir.Name.DictIndex is *not* set by unified IR, `print mapvar`
instead prints `map[int]go.shape.int []`.)
Fixes#54514.
Change-Id: I90d443945895abfba04dc018f15e00217930091c
Reviewed-on: https://go-review.googlesource.com/c/go/+/424735
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL implements pointer shaping in unified IR, corresponding to the
existing pointer shaping implemented in the non-unified frontend.
For example, if `func F[T any]` is instantiated as both `F[*int]` and
`F[*string]`, we'll now generate a single `F[go.shape.*uint8]` shaped
function that can be used by both.
Fixes#54513.
Change-Id: I2cef5ae411919e6dc5bcb3cac912abecb4cd5218
Reviewed-on: https://go-review.googlesource.com/c/go/+/424734
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
This CL switches unified IR to use shape-based stenciling with runtime
dictionaries, like the existing non-unified frontend. Specifically,
when instantiating generic functions and types `X[T]`, we now also
instantiated shaped variants `X[shapify(T)]` that can be shared by
`T`'s with common underlying types.
For example, for generic function `F`, `F[int](args...)` will be
rewritten to `F[go.shape.int](&.dict.F[int], args...)`.
For generic type `T` with method `M` and value `t` of type `T[int]`,
`t.M(args...)` will be rewritten to `T[go.shape.int].M(t,
&.dict.T[int], args...)`.
Two notable distinctions from the non-unified frontend:
1. For simplicity, currently shaping is limited to simply converting
type arguments to their underlying type. Subsequent CLs will implement
more aggressive shaping.
2. For generic types, a single dictionary is generated to be shared by
all methods, rather than separate dictionaries for each method. I
originally went with this design because I have an idea of changing
interface calls to pass the itab pointer via the closure
register (which should have zero overhead), and then the interface
wrappers for generic methods could use the *runtime.itab to find the
runtime dictionary that corresponds to the dynamic type. This would
allow emitting fewer method wrappers.
However, this choice does have the consequence that currently even if
a method is unused and its code is pruned by the linker, it may have
produced runtime dictionary entries that need to be kept alive anyway.
I'm open to changing this to generate per-method dictionaries, though
this would require changing the unified IR export data format; so it
would be best to make this decision before Go 1.20.
The other option is making the linker smarter about pruning unneeded
dictionary entries, like how it already prunes itab entries. For
example, the runtime dictionary for `T[int]` could have a `R_DICTTYPE`
meta-relocation against symbol `.dicttype.T[go.shape.int]` that
declares it's a dictionary associated with that type; and then each
method on `T[go.shape.T]` could have `R_DICTUSE` meta-relocations
against `.dicttype.T[go.shape.T]+offset` indicating which fields
within dictionaries of that type need to be preserved.
Change-Id: I369580b1d93d19640a4b5ecada4f6231adcce3fd
Reviewed-on: https://go-review.googlesource.com/c/go/+/421821
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL adds a helper expression code for receiver addressing; i.e.,
the implicit addressing, dereferencing, and field selections involved
in changing the `x` in `x.M()` into an appropriate expression to pass
as an argument to the method.
Change-Id: I9be933e2a38c8f94f6a85d95b54f34164e5efb0a
Reviewed-on: https://go-review.googlesource.com/c/go/+/421820
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Unified IR uses static dictionaries for some itabs and function/method
expressions, and they're roughly the right idea. But at the same time,
they're actually somewhat brittle and I need to reorganize some ideas
anyway to get shaped-based stenciling working. So this CL just rips
them out entirely.
Note: the code for emitting runtime dictionaries with *runtime._type
symbols is still present, and continues to demonstrate that basic
runtime dictionary handling is working.
Change-Id: I44eb1c7974fb397909ad5db12987659e7505c2ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/421819
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL separates out the handling of selector expressions for field
values, method values, and method expressions. Again part of
refactoring to make it possible to access runtime dictionaries where
needed.
No behavioral change; just duplicating and then streamlining the
existing code paths.
Change-Id: I53b2a344f4bdba2c9f37ef370dc9a091a3941021
Reviewed-on: https://go-review.googlesource.com/c/go/+/421818
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
This CL changes unified IR to explicitly handle function
instantiations within expression handling, rather than leaving it to
the underlying object reading logic.
Change-Id: I009a56013fbe9fbc4dabf80eea98993d34af4272
Reviewed-on: https://go-review.googlesource.com/c/go/+/421817
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
Same as CL 418475, but for Unified IR.
Updates #53888Fixes#54337
Change-Id: I31d5a7af04d8e3902ed25db85009d46ea4c38dbe
Reviewed-on: https://go-review.googlesource.com/c/go/+/422040
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Than McIntosh <thanm@google.com>
This CL switches unified IR to start using runtime dictionaries,
rather than pure stenciling. In particular, for each instantiated
function `F[T]`, it now:
1. Generates a global variable `F[T]-dict` of type `[N]uintptr`, with
all of the `*runtime._type` values needed by `F[T]`.
2. Generates a function `F[T]-shaped`, with an extra
`.dict *[N]uintptr` parameter and indexing into that parameter for
derived types. (N.B., this function is not yet actually using shape
types.)
3. Changes `F[T]` to instead be a wrapper function that calls
`F[T]-shaped` passing `&F[T]-dict` as the `.dict` parameter.
This is done in one pass to make sure the overall wiring is all
working (especially, function literals and inlining).
Subsequent CLs will write more information into `F[T]-dict` and update
`F[T]-shaped` to use it instead of relying on `T`-derived information
itself. Once that's done, `F[T]-shaped` can be changed to
`F[shapify(T)]` (e.g., `F[go.shape.int]`) and deduplicated.
Change-Id: I0e802a4d9934794e01a6bfc367820af893335155
Reviewed-on: https://go-review.googlesource.com/c/go/+/420416
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
An important optimization in the existing export data format is the
pruning of unreachable inline bodies. That is, when re-exporting
transitively imported types, omitting the inline bodies for methods
that can't actually be needed due to importing that package.
The existing logic (implemented in typecheck/crawler.go) is fairly
sophisticated, but also relies on actually expanding inline bodies in
the process, which is undesirable. However, including all inline
bodies is also prohibitive for testing GOEXPERIMENT=unified against
very large Go code bases that impose size limits on build action
inputs.
As a short-term solution, this CL implements a simple heuristic for
GOEXPERIMENT=unified: include the inline bodies for all
locally-declared functions/methods, and for any imported
functions/methods that were inlined into this package.
Change-Id: I686964a0cd9262b77d3d5587f89cfbcfe8b2e521
Reviewed-on: https://go-review.googlesource.com/c/go/+/419675
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Type switches are the only context where exprType was used and `nilOK`
was true. It'll simplify subsequent dictionary work somewhat if
exprType doesn't need to worry about `nil`, so extract this logic and
move it into switchStmt instead.
Change-Id: I3d810f465173f5bb2e2dee7bbc7843fff6a62ee5
Reviewed-on: https://go-review.googlesource.com/c/go/+/419474
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
This CL changes convRTTI into a serialization method too, like the
previous CL's rtype method. And again, currently this just builds on
the existing type serialization logic, but will eventually be changed
to use dictionary lookups where appropriate.
Change-Id: I551aef8ade24b08dc6206f06ace86d91e665f5c1
Reviewed-on: https://go-review.googlesource.com/c/go/+/419457
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
This CL adds `rtype` methods for unified IR for writing/reading types
that need to have their *runtime._type value available.
For now, this just builds on the existing type writing/reading
mechanics and calling reflectdata.TypePtrAt; but longer term, reading
of derived types can be changed to use dictionary lookups instead.
Change-Id: I6f803b84546fa7df2877a8a3bcbf2623e4b03449
Reviewed-on: https://go-review.googlesource.com/c/go/+/419456
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
This CL changes method expressions that use derived-type receiver
parameters to use dictionary lookups.
Change-Id: Iacd09b6d77a2d3000438ec8bc9b5af2a0b068aa7
Reviewed-on: https://go-review.googlesource.com/c/go/+/419455
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Comparisons between interface-typed and non-interface-typed
expressions no longer happen within Unified IR since CL 415577, so
this code path is no longer needed.
Change-Id: I075dfd1e6c34799f32766ed052eab0710bc6cbd5
Reviewed-on: https://go-review.googlesource.com/c/go/+/419454
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The previous CL largely removed the need for worrying about mixed
tag/case comparisons in switch statements by ensuring they're always
converted to a common type, except for one annoying case: switch
statements with an implicit `true` tag, and case values of interface
type (which must be empty interface, because `bool`'s method set is
empty).
It would be simpler to have writer.go desugar the implicit `true`
itself, because we already handle explicit `true` correctly. But the
existing code already works fine, and I don't want to add further
complexity to writer.go until dictionaries and stenciling is done.
Change-Id: Ia8d44c425b1be7fc578cd570d15a7560fe9d2674
Reviewed-on: https://go-review.googlesource.com/c/go/+/418102
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Currently, uses of "nil" are handling as references to cmd/compile's
own untyped "nil" object, and then we rely on implicitly converting
that to its appropriate type. But there are cases where this can
subtly go wrong (e.g., the switch test case added in the previous CL).
Instead, explicitly handling "nil" expressions so that we can
construct them directly with the appropriate type, as computed already
by types2.
Change-Id: I587f044f60f24e87525dde6d7dad6c58f14478de
Reviewed-on: https://go-review.googlesource.com/c/go/+/418100
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
In a select statement, `case i = <-c: ...` may require an implicit
conversion of the received value to i's type, but walk does not expect
a conversion here. Instead, typecheck actually discards the
conversion (resulting in ill-typed IR), and then relies on it being
reinserted later when walk desugars the assignment.
However, that might lose the explicit RTTI operands we've set for
conversions to interface type, so explicitly introduce a temporary
variable and rewrite as `case tmp := <-c: i = tmp; ...`, which is
semantically equivalent and allows the `i = tmp` assignment to
maintain the explicit RTTI without confusing the rest of the compiler
frontend.
Change-Id: Ie6c4dc9b19437e83970cd3ce83420813b8a47dc4
Reviewed-on: https://go-review.googlesource.com/c/go/+/418098
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This CL updates Unified IR to set the TypeWord and SrcRType fields on
interface conversions, which will be necessary for dictionary support
shortly.
Change-Id: I9486b417f514ba4ec2ee8036194aa9ae3ad0ad93
Reviewed-on: https://go-review.googlesource.com/c/go/+/415575
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Unified IR tries to avoid depending on base.Pos, so we should prefer
explicit position arguments wherever possible.
Change-Id: I7163b1b8c5244fe7c2a7989e6a3f459a21a23e81
Reviewed-on: https://go-review.googlesource.com/c/go/+/418096
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Rather than requiring users to recompile the compiler and all tools to
enable/disable sync markers, this CL adds a flag word into the Unified
IR file format to allow indicating whether they're enabled or not.
This in turn requires bumping the file format version.
Thanks to drchase@ for benchmarks showing this isn't as expensive as I
feared it would be.
Change-Id: I99afa0ee0b6ef5f30ed8ca840805ff9fd46b1857
Reviewed-on: https://go-review.googlesource.com/c/go/+/417097
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL changes GOEXPERIMENT=unified to insert implicit conversions
for multi-valued expressions.
Unfortunately, IR doesn't have strong, first-class support for
multi-valued expressions, so this CL takes the approach of spilling
them to temporary variables, which can then be implicitly converted.
This is the same approach taken by walk, but doing it this early does
introduce some minor complications:
1. For select case clauses with comma-ok assignments (e.g., `case x,
ok := <-ch:`), the compiler middle end wants to see the OAS2RECV
assignment is the CommClause.Comm statement. So when constructing
select statements, we need to massage this around a little.
2. The extra temporary variables and assignments skew the existing
inlining heuristics. As mentioned, the temporaries/assignments will
eventually be added (and often optimized away again) anyway, but now
they're visible to the inliner. So this CL also kludges the inlining
heuristics in this case to keep things comparable.
Change-Id: I3e3ea756ad92472ebe28bae3963be61ed7684a75
Reviewed-on: https://go-review.googlesource.com/c/go/+/415244
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Pull all multi-value expression handling logic into a new multiExpr
helper method.
Change-Id: I78ec2dfc523abcfa3368a1064df7045aade8e468
Reviewed-on: https://go-review.googlesource.com/c/go/+/415243
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
CL 410342 removed package height, but still needs to keep writing out 0
for iexport for compatibility with existing importers. With Unified IR,
we don't have to, so get rid of the package height completely.
Change-Id: I84a285cbaddd7bb0833d45a24a6818231b4d2b71
Reviewed-on: https://go-review.googlesource.com/c/go/+/411014
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
This CL adds support for implicit conversions to the unified IR export
data format, and starts inserting them in a few low-hanging
places (send statements, index expressions).
Subsequentl CLs will handle the remaining trickier cases.
Change-Id: Iaea9d1c5df8432b61bd82578ab2ef02adaf26367
Reviewed-on: https://go-review.googlesource.com/c/go/+/413396
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
For f(g()) calls where g() is multi-valued, we may need to insert
implicit conversions to convert g()'s result values to f()'s parameter
types. This CL refactors code slightly so this will be easier to
handle.
Change-Id: I3a432220dcb62daecf9a66030e8fa1f097e95f95
Reviewed-on: https://go-review.googlesource.com/c/go/+/413362
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
For (value) switch statements, we may generate OEQ comparisons between
values of interface and concrete type, which in turn may require
access to the concrete type's RType.
To plumb this through, this CL adds CaseClause.RTypes to hold the
rtype values, updates the GOEXPERIMENT=unified frontend to set it, and
updates walk to plumb rtypes through into generated OEQ nodes.
Change-Id: I6f1de2a1167ce54f5770147498a0a591efb3f012
Reviewed-on: https://go-review.googlesource.com/c/go/+/413361
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
OMAPLIT gets lowered into a bunch of OINDEXMAP operations, which in
general may require a *runtime._type argument. This CL adds
CompLitExpr.RType, updates the GOEXPERIMENT=unified frontend to start
setting it, and updates walk to propagate it through to any generated
OINDEXMAP operations.
Change-Id: I278e7e8e615ea6d01f65a5eba6d6fc8e00045735
Reviewed-on: https://go-review.googlesource.com/c/go/+/413360
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL switches the GOEXPERIMENT=unified frontend to set RType fields
in the simpler cases, and to make it fatal if they're missing.
Subsequent CLs will handle the remaining more complex cases (e.g.,
expressions from later desugaring, and implicit conversions to
interface type).
Change-Id: If6257dcb3916905afd9b8371ea64b85f108ebbfb
Reviewed-on: https://go-review.googlesource.com/c/go/+/413359
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: David Chase <drchase@google.com>
This adds more documentation throughout the core Unified IR logic and
removes their UNREVIEWED notices.
Updates #48194.
Change-Id: Iddd30edaee1c6ea8a05a5a7e013480e02be00d29
Reviewed-on: https://go-review.googlesource.com/c/go/+/411917
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
There are two places currently where we rely on type expressions as
generic expressions: the first argument to "make" and "new", and the
selectable operand within a method expression.
This CL makes that code responsible for handling the type expressions
directly. Longer term, this will be relevant to appropriately handling
derived types, because it will provide additional context about how
the derived type is to be used.
Change-Id: I9d7dcf9d32dada032ff411cd103b9df413c298a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/410101
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
CL 410343 changes Unified IR to visit LHS before RHS/X in assign/for
statement. Thus, it needs to set base.Pos before processing assignee
expression, so invalid type can be reported with correct position.
Updates #53058
Change-Id: Ic9f60cbf35c8bd71cb391e806396572c37811af7
Reviewed-on: https://go-review.googlesource.com/c/go/+/410794
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
For error reported during type size calculation, base.Pos needs to be
set, otherwise, the compiler will treat them as the same error and only
report once. Old typechecker and irgen all set base.Pos before
processing types, this CL do the same thing for unified IR.
Updates #53058
Change-Id: I686984ffe4aca3e8b14d2103018c8d3c7d71fb02
Reviewed-on: https://go-review.googlesource.com/c/go/+/410345
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Unified IR used to visit RHS/X before LHS in assign/for statements for
satisfying toolstash in quirksmode.
After CL 385998, unified IR quirks mode was gone, the constraint to
visit RHS/X first is no longer necessary.
Change-Id: I1c3825168b67fb094928f5aa21748a3c81b118ce
Reviewed-on: https://go-review.googlesource.com/c/go/+/410343
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Unified IR uses to generate wrappers after the global inlining pass, so
it needs to apply inlining for the wrappers itself. However, inlining
may reveal new method value nodes which have not been seen yet, thus
unified IR never generates wrappers for them.
To fix it, just visiting the wrapper function body once more time after
inlining, and generate wrappers for any new method value nodes.
Fixes#52128
Change-Id: I78631c4faa0b00357d4f84704d3525fd38a52cd7
Reviewed-on: https://go-review.googlesource.com/c/go/+/410344
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
After CL 410654, symbols are now sorted by package path, package height
is not necessary anymore.
Updates #51734
Change-Id: I976edd2e574dda68eb5c76cf95645b9dce051393
Reviewed-on: https://go-review.googlesource.com/c/go/+/410342
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Blanks can only appear on the LHS of an assignment. Instead of
handling them as an arbitrary expression, handle them as part of
assignee expression lists.
Change-Id: Iaeb0a5c471ffa1abd2bbbd9c95f7876533e5a607
Reviewed-on: https://go-review.googlesource.com/c/go/+/410100
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Previously, {writer,reader}.expr would allow for nil
expressions (i.e., no expression at all, not a "nil" identifier). But
only a few contexts allow this, and it simplifies some logic if we can
assume the expression is non-nil.
So this CL introduces optExpr as a wrapper method for handling nil
expressions specially.
Change-Id: I438bae7a3191126f7790ec0bf5b77320fe855514
Reviewed-on: https://go-review.googlesource.com/c/go/+/410099
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Element indices are very common in the pkgbits API, so introduce a new
defined type to help make that clearer.
Change-Id: I8f9493e2335601c740eb403d1fdcd11183122907
Reviewed-on: https://go-review.googlesource.com/c/go/+/407435
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Rename DynamicType's "X" field to "RType".
Split DynamicTypeAssertExpr's "T" field into "RType" and "ITab", the
same as DynamicType, updating all uses accordingly.
Change-Id: I8cec8171349c93234a10ac50708f800dee6fb1d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/405334
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
