This CL adds a few new helper functions for constructing and
initializing temporary variables during walk.
Passes toolstash -cmp.
Change-Id: I54965d992cd8dfef7cb7dc92a17c88372e52a0d6
Reviewed-on: https://go-review.googlesource.com/c/go/+/284224
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>
After CL 284220, we now only need to detect expressions that contain
function calls in the arguments list of further function calls. So we
can simplify Node.HasCall/fncall/etc a lot.
Instead of incrementally tracking whether an expression contains
function calls all throughout walk, simply check once at the point of
using an expression as a function call argument. Since any expression
checked here will itself become a function call argument, it won't be
checked again because we'll short circuit at the enclosing function
call.
Also, restructure the recursive walk code to use mayCall, and trim
down the list of acceptable expressions. It should be okay to be
stricter, since we'll now only see function call arguments and after
they've already been walked.
It's possible I was overly aggressive removing Ops here. But if so,
we'll get an ICE, and it'll be easy to re-add them. I think this is
better than the alternative of accidentally allowing expressions
through that risk silently clobbering the stack.
Passes toolstash -cmp.
Change-Id: I585ef35dcccd9f4018e4bf2c3f9ccb1514a826f3
Reviewed-on: https://go-review.googlesource.com/c/go/+/284223
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>
Went in a semi-automated way through the clearest renames of functions,
and updated comments and error messages where it made sense.
Change-Id: Ied8e152b562b705da7f52f715991a77dab60da35
Reviewed-on: https://go-review.googlesource.com/c/go/+/284216
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
After CL 283233, SSA can now handle new(typ) without the frontend to
generate the type address, so we can remove ONEWOBJ in favor of ONEW
only.
This is also not save for toolstash, the same reason with CL 284115.
Change-Id: Ie03ea36b3b6f95fc7ce080376c6f7afc402d51a3
Reviewed-on: https://go-review.googlesource.com/c/go/+/284117
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>
CL 283233 added reflectType method to ssagen.state, which we can use to
setup type address in the SSA backend in favor of the frontend. However,
this will change the order of symbols generation, so not safe for toolstash.
Change-Id: Ib6932ec42a9d28c3fd7a1c055596e75494c29843
Reviewed-on: https://go-review.googlesource.com/c/go/+/284115
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>
Currently, there's an awkward issue with walk pass. When walking the AST
tree, the compiler generate code for runtime functions (using mkcall* variants),
add/modify the AST tree and walk new generated tree again. This causes the
double walking on some CallExpr, which is relying on checking Rargs to prevent
that. But checking Rargs has its own issue as well.
For functions that does not have arguments, this check is failed, and we
still double walk the CallExpr node.
This CL change the way that compiler detects double walking, by using
separated field instead of relying on Rargs. In perfect world, we should make
the compiler walks the AST tree just once, but it's not safe to do that at
this moment.
Passes toolstash -cmp.
Change-Id: Ifdd1e0f98940ddb1f574af2da2ac7f005b5fcadd
Reviewed-on: https://go-review.googlesource.com/c/go/+/283672
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>
We used to transform directly called closures in a separate pass
before walk, because we couldn't guarantee whether we'd see the
closure call or the closure itself first. As of the last CL, this
ordering is always guaranteed, so we can rewrite calls and the closure
at the same time.
Change-Id: Ia6f4d504c24795e41500108589b53395d301123b
Reviewed-on: https://go-review.googlesource.com/c/go/+/283315
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
This CL reorders function compilation to ensure that functions are
always compiled before any enclosed function literals. The primary
goal of this is to reduce the risk of race conditions that arise due
to compilation of function literals needing to inspect data from their
closure variables. However, a pleasant side effect is that it allows
skipping the redundant, separate compilation of function literals that
were inlined into their enclosing function.
Change-Id: I03ee96212988cb578c2452162b7e99cc5e92918f
Reviewed-on: https://go-review.googlesource.com/c/go/+/282892
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
After the previous CLs, all closure reads are handled during SSA
construction.
Change-Id: Iad67b01fa2d3798f50ea647be7ccf8195f189c27
Reviewed-on: https://go-review.googlesource.com/c/go/+/281512
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>
Currently, during walk we rewrite PAUTOHEAP uses into derefs of their
corresponding Heapaddr, but we can easily do this instead during SSA
construction. This does involve updating two test cases:
* nilptr3.go
This file had a test that we emit a "removed nil check" diagnostic for
the implicit dereference from accessing a PAUTOHEAP variable. This CL
removes this diagnostic, since it's not really useful to end users:
from the user's point of view, there's no pointer anyway, so they
needn't care about whether we check for nil or not. That's a purely
internal detail. And with the PAUTOHEAP dereference handled during SSA
construction, we can more robustly ensure this happens, rather than
relying on setting a flag in walk and hoping that SSA sees it.
* issue20780.go
Previously, when PAUTOHEAPs were dereferenced during walk, it had a
consequence that when they're passed as a function call argument, they
would first get copied to the stack before being copied to their
actual destination. Moving the dereferencing to SSA had a side-effect
of eliminating this unnecessary temporary, and copying directly to the
destination parameter.
The test is updated to instead call "g(h(), h())" where h() returns a
large value, as the first result will always need to be spilled
somewhere will calling the second function. Maybe eventually we're
smart enough to realize it can be spilled to the heap, but we don't do
that today.
Because I'm concerned that the direct copy-to-parameter optimization
could interfere with race-detector instrumentation (e.g., maybe the
copies were previously necessary to ensure they're not clobbered by
inserted raceread calls?), I've also added issue20780b.go to exercise
this in a few different ways.
Change-Id: I720598cb32b17518bc10a03e555620c0f25fd28d
Reviewed-on: https://go-review.googlesource.com/c/go/+/281293
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
These aren't part of the Node interface anymore, so no need to keep
them around.
Passes toolstash -cmp.
[git-generate]
cd src/cmd/compile/internal/ir
: Fix one off case that causes trouble for rf.
sed -i -e 's/n.SetClass(ir.PAUTO)/n.Class_ = ir.PAUTO/' ../ssa/export_test.go
pkgs=$(go list . ../...)
rf '
ex '"$(echo $pkgs)"' {
var n *Name
var c Class
n.Class() -> n.Class_
n.SetClass(c) -> n.Class_ = c
}
rm Name.Class
rm Name.SetClass
mv Name.Class_ Name.Class
'
Change-Id: Ifb304bf4691a8c455456aabd8aa77178d4a49500
Reviewed-on: https://go-review.googlesource.com/c/go/+/281294
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>
Just "=". It's cleaner.
Passes toolstash -cmp.
[git-generate]
cd src/cmd/compile/internal/ir
pkgs=$(go list . ../...)
rf '
ex '"$(echo $pkgs)"' {
var l Nodes
var p *Nodes
p.Set(l) -> *p = l
}
ex '"$(echo $pkgs)"' {
var n InitNode
var l Nodes
*n.PtrInit() = l -> n.SetInit(l)
}
rm Nodes.Set
'
Change-Id: Ic97219792243667146a02776553942ae1189ff7d
Reviewed-on: https://go-review.googlesource.com/c/go/+/281002
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 separates out PtrInit and SetInit into a new InitNode
extension interface, and adds a new TakeInit helper function for
taking and clearing the Init list (if any) from a Node.
This allows removing miniNode.SetInit and miniNode.PtrInit, which in
turn allow getting rid of immutableEmptyNodes, and will allow
simplification of the Nodes API.
It would be nice to get rid of the default Init method too, but
there's way more code that expects to be able to call that at the
moment, so that'll have to wait.
Passes toolstash -cmp.
Change-Id: Ia8c18fab9555b774376f7f43eeecfde4f07b5946
Reviewed-on: https://go-review.googlesource.com/c/go/+/281001
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>
We can easily compute this on demand.
Passes toolstash -cmp.
Change-Id: I433d8adb2b1615ae05b2764e69904369a59542c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/280994
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>
Syms are meant to be just interned (pkg, name) tuples, and are a
purely abstract, Go-language concept. As such, associating them with
linker symbols (a low-level, implementation-oriented detail) is
inappropriate.
There's still work to be done before linker symbols can be directly
attached to their appropriate, higher-level objects instead. But in
the mean-time, we can at least add helper functions and discourage
folks from using Sym.Linksym directly. The next CL will mechanically
rewrite code to use these helpers where possible.
Passes toolstash -cmp.
Change-Id: I413bd1c80bce056304f9a7343526bd153f2b9c7d
Reviewed-on: https://go-review.googlesource.com/c/go/+/280639
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>
Previously, ODOTTYPE/ODOTTYPE2 were forced to reuse some available
Node fields for storing pointers to runtime type descriptors. This
resulted in awkward field types for TypeAssertExpr and AddrExpr.
This CL gives TypeAssertExpr proper fields for the runtime type
descriptors, and also tightens the field types as
possible/appropriate.
Passes toolstash -cmp.
Change-Id: I521ee7a1462affc5459de33a0de6c68a7d6416ba
Reviewed-on: https://go-review.googlesource.com/c/go/+/280637
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>
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>
A subsequent CL will change FuncName to lazily create the ONAME nodes,
which isn't currently safe to do during SSA construction, because that
phase is concurrent.
Passes toolstash -cmp.
Change-Id: Ic24acc1d1160ad93b70ced3baa468f750e689ea6
Reviewed-on: https://go-review.googlesource.com/c/go/+/280435
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 cleans up a few minor points in walkExpr:
1. We don't actually care about computing the type-size of all
expressions that are walked. We care about computing the type-size of
all expressions that are *returned* by walk, as these are the
expressions that will actually be seen by the back end.
2. There's no need to call typecheck.EvalConst anymore. EvalConst used
to be responsible for doing additional constant folding during walk;
but for a while a now, it has done only as much constant folding as is
required during type checking (because doing further constant folding
led to too many issues with Go spec compliance). Instead, more
aggressive constant folding is handled entirely by SSA.
3. The code for detecting string constants and generating their
symbols can be simplified somewhat.
Passes toolstash -cmp.
Change-Id: I464ef5bceb8a97689c8f55435369a3402a5ebc55
Reviewed-on: https://go-review.googlesource.com/c/go/+/280434
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>
Now that the previous CL ensures we always set SelectorExpr.Selection,
we can replace the SelectorExpr.Offset field with a helper method that
simply returns SelectorExpr.Selection.Offset.
Passes toolstash -cmp.
Change-Id: Id0f22b8b1980397b668f6860d27cb197b90ff52a
Reviewed-on: https://go-review.googlesource.com/c/go/+/280433
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>
During walkCall, there's a half-hearted attempt at rewriting OCALLMETH
expressions into regular function calls by moving the receiver
argument into n.Args with the rest of the arguments. But the way it
does this leaves the AST in an inconsistent state (an ODOTMETH node
with no X expression), and leaves a lot of duplicate work for the rest
of the backend to deal with.
By simply rewriting OCALLMETH expressions into proper OCALLFUNC
expressions, we eliminate a ton of unnecessary code duplication during
SSA construction and avoid creation of invalid method-typed variables.
Passes toolstash -cmp.
Change-Id: I4d5c5f90a79f8994059b2d0ae472182e08096c0a
Reviewed-on: https://go-review.googlesource.com/c/go/+/280294
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
ir.IsAssignable does not include map index expression, so it should be
named ir.IsAddressable instead.
[git-generate]
cd src/cmd/compile/internal/ir
rf '
mv IsAssignable IsAddressable
'
Change-Id: Ief6188e7b784ba9592d7b0cbec33b5f70d78f638
Reviewed-on: https://go-review.googlesource.com/c/go/+/279436
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>
