Closures have their own ONAMEs for captured variables, which their
function bodies refer to. So during inlining, we need to account for
this and ensure the references still work.
The previous inlining handled this by actually declaring the variables
and then either copying the original value or creating a pointer to
them, as appropriate for variables captured by value or by reference.
But this is needlessly complicated. When inlining the function body,
we need to rewrite all variable references anyway. We can just detect
closure variables and change them to directly point to the enclosing
function's version of this variable. No need for copying or further
indirection.
Does not pass toolstash -cmp. Presumably because we're able to
generate better code in some circumstances.
Change-Id: I8f0ccf7b098f39b8cd33f3bcefb875c8132d2c62
Reviewed-on: https://go-review.googlesource.com/c/go/+/280996
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
After using the IR visitor code for a bit, it seems clear that a
simple boolean result type is adequate for tree traversals. This CL
updates ir.DoChildren to use the same calling convention as ir.Any,
and updates mknode.go to generate code accordingly.
There were only two places where the error-based DoChildren API was
used within the compiler:
1. Within typechecking, marking statements that contain "break". This
code never returns errors anyway, so it's trivially updated to return
false instead.
2. Within inlining, the "hairy visitor" actually does make use of
returning errors. However, it threads through a reference to the
hairyVisitor anyway, where it would be trivial to store any needed
information instead. For the purpose of this CL, we provide
"errChildren" and "errList" helper functions that provide the previous
error-based semantics on top of the new bool-based API.
Passes toolstash -cmp.
Change-Id: I4bac9a697b4dbfb5f66eeac37d4a2ced2073d7d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/280675
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Change-Id: I2732aefe95a21c23d73a907d5596fcb1626d6dd7
Reviewed-on: https://go-review.googlesource.com/c/go/+/275697
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Switch the source of truth to the new addrtaken bit. Remove the old one.
Change-Id: Ie53679ab14cfcd34b55e912e7ecb962a22db7db3
Reviewed-on: https://go-review.googlesource.com/c/go/+/275696
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
This CL computes a second parallel addrtaken bit that we check
against the old way of doing it. A subsequent CL will rip out the
typechecker code and just use the new way.
Change-Id: I62b7342c44f694144844695386f80088bbd40bf4
Reviewed-on: https://go-review.googlesource.com/c/go/+/275695
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
These three expression nodes all represent the same syntax, and so
they're represented the same within types2. And also they're not
handled that meaningfully differently throughout the rest of the
compiler to merit unique representations.
Method expressions are somewhat unique today that they're very
frequently turned into plain function names. But eventually that can
be handled by a post-typecheck desugaring phase that reduces the
number of redundant AST forms.
Passes toolstash -cmp.
Change-Id: I20df91bbd0d885c1f18ec67feb61ae1558670719
Reviewed-on: https://go-review.googlesource.com/c/go/+/280636
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
ODOTMETH is unique among SelectorExpr expressions, in that Sel gets
mangled so that it no longer has the original identifier that was
selected (e.g., just "Foo"), but instead the qualified symbol name for
the selected method (e.g., "pkg.Type.Foo"). This is rarely useful, and
instead results in a lot of compiler code needing to worry about
undoing this change.
This CL changes ODOTMETH to leave the original symbol in place. The
handful of code locations where the mangled symbol name is actually
wanted are updated to use ir.MethodExprName(n).Sym() or (equivalently)
ir.MethodExprName(n).Func.Sym() instead.
Historically, the compiler backend has mistakenly used types.Syms
where it should have used ir.Name/ir.Funcs. And this change in
particular may risk breaking something, as the SelectorExpr.Sel will
no longer point at a symbol that uniquely identifies the called
method. However, I expect CL 280294 (desugar OCALLMETH into OCALLFUNC)
to have substantially reduced this risk, as ODOTMETH expressions are
now replaced entirely earlier in the compiler.
Passes toolstash -cmp.
Change-Id: If3c9c3b7df78ea969f135840574cf89e1d263876
Reviewed-on: https://go-review.googlesource.com/c/go/+/280436
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 devirtualization code was only in inl.go because it reused some of
the same helper functions as inlining (notably staticValue), but that
code all ended up in package ir instead anyway. Beyond that minor
commonality, it's entirely separate from inlining.
It's definitely on the small side, but consistent with the new
micropass-as-a-package approach we're trying.
[git-generate]
cd src/cmd/compile/internal/inline
rf '
mv Devirtualize Func
mv devirtualizeCall Call
mv Func Call devirtualize.go
mv devirtualize.go cmd/compile/internal/devirtualize
'
Change-Id: Iff7b9fe486856660a8107d5391c54b7e8d238706
Reviewed-on: https://go-review.googlesource.com/c/go/+/280212
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>
