| Age | Commit message (Collapse) | Author |
|---|
|
The checkptr instrumentation is currently inserted before slice
operation has validated that n <= Big. So instead of panic, checkptr
have false positive throws.
To fix this, just insert the checkptr instrumentation after the bound
checking during SSA generation.
Fixes #46938
Change-Id: I9dbf84441c711842ccc883f3654ca8766ac696d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/343972
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>
|
|
When starting a closure that needs a dictionary, copy the closure
variable to a local variable. This lets child closures capture that
dictionary variable correctly.
This is a better fix for #47684, which does not cause problems
like #47723.
Fixes #47723
Update #47684
Change-Id: Ib5d9ffc68a5142e28daa7d0d75683e7a35508540
Reviewed-on: https://go-review.googlesource.com/c/go/+/343871
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>
|
|
Change-Id: I88a3e69e232bf94296fe97621c5d395fc1296bbb
GitHub-Last-Rev: f1cc29dc287eb02881fead0b815e1b45e23adfa4
GitHub-Pull-Request: golang/go#47482
Reviewed-on: https://go-review.googlesource.com/c/go/+/338751
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
|
|
Currently, for hidden closures, we always push them to compile queue
during typechecking. If the hidden closure is discarded from the outer
function body during deadcode, any desugaring phase after deadcode won't
be applied to the closure. Thus, some un-expected OPs are passed to
downstream passes, which they can't handle, the compiler goes boom!
To fix this, we keep track of discarded hidden closures during deadcode
pass, and won't compile them then.
Fixes #47712
Change-Id: I078717d5d1f4f2fa39cbaf610cfffbb042e70ceb
Reviewed-on: https://go-review.googlesource.com/c/go/+/342350
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>
|
|
Capturing dictionary closure variables is ok.
Fixes #47684
Change-Id: I049c87117915e0c5a172b9665bfac2f91064b2d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/342050
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 has been a part of the node dumping since the very beginning, but
this makes diffing -W output pretty annoying. -d=dumpptrs already prints
these out if needed.
Change-Id: I9524a7f7b44ec780ae42a8a2a9588f11ab3950f9
Reviewed-on: https://go-review.googlesource.com/c/go/+/340253
Reviewed-by: Dan Scales <danscales@google.com>
Reviewed-by: 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>
|
|
Add a new dynamicType node, which is used as a case entry when
the type being switched to is generic.
Change-Id: Ice77c6f224b8fdd3ff574fdf4a8ea5f6c7ddbe75
Reviewed-on: https://go-review.googlesource.com/c/go/+/339429
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
|
|
Introduce new dynamic dottype operations which take a dynamic
instead of static type to convert to.
Change-Id: I5824a1fea056fe811b1226ce059e1e8da1baa335
Reviewed-on: https://go-review.googlesource.com/c/go/+/337609
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 operation computes just the data field needed to put its argument
into an interface. Used by generics because we produce the type field
of an interface using dictionaries (instead of statically).
With this operation defined, we can now assert that shape types
are never marked as used in interfaces (the only previous use
was IDATA(CONVIFACE(t))).
Change-Id: Idb1eb5f3b238285cb99413d382599c0621b7681a
Reviewed-on: https://go-review.googlesource.com/c/go/+/337109
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>
|
|
Removed a case in transformCall() where we were setting a type on n,
which isn't needed, since noder2 already set the type of n. More
importantly, we are losing information, since the type of the results
may be a shape type, but the actual type of call is the known type
from types2, which may be a concrete type (in this case Zero[MyInt]).
That concrete type will then be used correctly if the concrete result is
converted to an interface.
If we are inlining the call to Zero[MyInt], we need to add an implicit
CONVNOP operation, since we are going to use the result variable
directly, which has a shape type. So, add an implicit CONVNOP to
remember that the known type is the concrete type.
Also cleaned up 14.go a bit, so it is more understandable. Renamed type
T to AnyInt, since T is used elsewhere as a type parameter. Reformatted
Zero function and added a comment.
Change-Id: Id917a2e054e0bbae9bd302232853fa8741d49b64
Reviewed-on: https://go-review.googlesource.com/c/go/+/336430
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
|
|
Call SetPos() in g.expr() so it is available for any new nodes.
Print out the actual type for a composite literal in exprFmt() if
available, else use Ntype if available. Seems generally useful, since
the type name is always more useful than just 'composite literal'.
Fixes a bunch of cases that are excluded in run.go for -G=3.
Change-Id: I40b9bba88027ea4f36d419e3989e7f14891bea04
Reviewed-on: https://go-review.googlesource.com/c/go/+/334609
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.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>
|
|
Unneeded after the previous CL changed inlining to leave OINLCALL
nodes in place.
Change-Id: I9af09a86a21caa51a1117b3de17d7312dd702600
Reviewed-on: https://go-review.googlesource.com/c/go/+/332650
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>
|
|
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>
|
|
Added new struct instInfo for information about an instantiation (of a
generic function/method with gcshapes or concrete types). We use this to
remember the dictionary param node, the nodes where sub-dictionaries
need to be used, etc. The instInfo map replaces the Stencil map in
Package.
Added code to access sub-dictionary entries at the appropriate call
sites. We are currently still calculating the corresponding main
dictionary, even when we really only need a sub-dictionary. I'll clean
that up in a follow-up CL.
Added code to deal with "generic" closures (closures that reference some
generic variables/types). We decided that closures will share the same
dictionary as the containing function (accessing the dictionary via a
closure variable). So, the getGfInfo function now traverses all the
nodes of each closure in a function that it is analyzing, so that a
function's dictionary has all the entries needed for all its closures as
well. Also, the instInfo of a closure is largely shared with its
containing function. A good test for generic closures already exists
with orderedmap.go.
Other improvements:
- Only create sub-dictionary entries when the function/method
call/value or closure actually has type params in it. Added new test
file subdict.go with an example where a generic method has an
instantiated method call that does not depend not have type params.
Change-Id: I691b9dc024a89d2305fcf1d8ba8540e53c9d103f
Reviewed-on: https://go-review.googlesource.com/c/go/+/331516
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
|
|
Go spec call them "method values", not "partial calls". Note that
we use "OMETHVALUE" (as opposed to "OMETHODVALUE") to be consistent
with "OMETHEXPR".
Change-Id: I1efd985d4b567a1b4b20aeb603eb82db579edbd5
Reviewed-on: https://go-review.googlesource.com/c/go/+/330837
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>
|
|
dictionaries
This is code in progress to generate the two main other types of entries
in dictionaries:
- all types in the instantiated function derived from the type
arguments (which are currently concrete, but will eventually be
gcshapes)
- pointers (i.e. mainly the unique name) to all needed sub-dictionaries
In order to generate these entries, we now generate cached information
gfInfo about generic functions/methods that can be used for creating the
instantiated dictionaries. We use the type substituter to compute the
right type args for instantiated sub-dictionaries.
If infoPrintMode is changed to true, the code prints out all the
information gathered about generic functions, and also the entries in
all the dictionaries that are instantiated. The debug mode also prints
out the locations where we need main dictionaries in non-instantiated
functions.
Other changes:
- Moved the dictionary generation back to stencil.go from reflect.go,
since we need to do extra analysis for the new dictionary entries. In
the process, made getInstantiation generate both the function
instantiation and the associated dictionary.
- Put in small change for now in reflect.go, so that we don't try
generate separate dictionaries for Value[T].get and the
auto-generated (*Value[T]).get. The auto-generated wrapper shouldn't really
need a dictionary.
- Detected, but not handling yet, a new case which needs
dictionaries - closures that have function params or captured
variables whose types are derived from type arguments.
- Added new tests in dictionaryCapture for use of method
value/expressions in generic functions and for mutually recursive
generic functions.
Change-Id: If0cbde8805a9f673a23f5ec798769c85c9c5359b
Reviewed-on: https://go-review.googlesource.com/c/go/+/327311
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
|
|
This CL moves two bits of related code from order.go to escape
analysis:
1. The recognition of "unsafe uintptr" arguments passed to
syscall-like functions.
2. The wrapping of go/defer function calls in parameter-free function
literals.
As with previous CLs, it would be nice to push this logic even further
forward, but for now escape analysis seems most pragmatic.
A couple side benefits:
1. It allows getting rid of the uintptrEscapesHack kludge.
2. When inserting wrappers, we can move some expressions into the
wrapper and escape analyze them better. For example, the test
expectation changes are all due to slice literals in go/defer calls
where the slice is now constructed at the call site, and can now be
stack allocated.
Change-Id: I73679bcad7fa8d61d2fc52d4cea0dc5ff0de8c0c
Reviewed-on: https://go-review.googlesource.com/c/go/+/330330
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 ORECOVER is a single operation that both (1) calculates
the (logical) caller frame pointer and (2) calls runtime.gorecover.
This is normally fine, but it's inconvenient for regabi, which wants
to wrap "defer recover()" into "defer func() { recover() }" and
needs (1) and (2) to happen at different times.
The current solution is to apply walkRecover early to split it into
the two steps, but calling it during order is a minor layering
violation. It works well today because the order and walk phases are
closely related anyway and walkRecover is relatively simple, but it
won't work for go/defer wrapping earlier into the frontend.
This CL adds a new, lower-level ORECOVERFP primitive, which represents
just part (2); and OGETCALLER{PC,SP} primitives, which provide a way
to compute (1) in the frontend too.
OGETCALLERPC isn't needed/used today, but it seems worth including for
completeness. Maybe it will be useful at some point for intrinsifying
runtime.getcaller{pc,sp}, like we already do for runtime.getg.
Change-Id: Iaa8ae51e09306c45c147b6759a5b7c24dcc317ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/330192
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>
|
|
This CLs adds new frontend ops that will be used in the next CL. Split
out separately so generated code is less distracting in the main CL.
Change-Id: I66125e0ec2217bfa05f7b0ea0bc99ada13f563f7
Reviewed-on: https://go-review.googlesource.com/c/go/+/330191
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
|
This flag is only needed to prevent the directClosureCall optimization
in walkCall, when called for walkGoDefer. But walkGoDefer don't need
to call walkCall: at this point in the compile, the call expression
isn't a real call anymore.
Instead, we just need to walkExpr on the function expression.
Change-Id: I8a5176cfe1bff53700cbd21ed1b479ebd9a839ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/330271
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>
|
|
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>
|
|
This CL removes the special escape analysis tags added to support
//go:uintptrescapes and calls to external functions. Instead, these
are kept as function pragmas.
This CL by itself isn't very interesting, but I expect will help with
subsequent cleanups I have planned here.
Change-Id: Ifb960289a27e0a6295ce2d2f5ec233cac590522b
Reviewed-on: https://go-review.googlesource.com/c/go/+/329969
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
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>
|
|
I initially made NewClosureFunc take an "outerfn *Func" parameter
because I was planning on having it handle closure naming, until
remembering that naming needs to wait until typecheck for noder.
We don't actually need the *Func yet, just to know whether it's
non-nil. So change the parameter to a bool, which simplifies callers a
little.
Change-Id: Ie83ee4a1ed0571ac6d3879ffd8474c6c3c1a9ff9
Reviewed-on: https://go-review.googlesource.com/c/go/+/327450
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>
|
|
typecheck.tcClosure is complicated with many code flows because all of
its callers setup the closure funcs in slightly different ways. E.g.,
it's non-obvious who's responsible for setting the underlying func's
Sym or adding it to target.Decls, or how to write new code that
constructs a closure without interfering with existing code.
This CL refactors everything to use three common functions in package
ir: NewClosureFunc (which handle creating the Func, Name, and
ClosureExpr and wiring them together), NameClosure (which generates
and assigns its unique Sym), and UseClosure (which handles adding the
Func to target.Decls).
Most IR builders can actually name the closure right away, but the
legacy noder+typecheck path may not yet know the name of the enclosing
function. In particular, for methods declared with aliased receiver
parameters, we need to wait until after typechecking top-level
declarations to know the method's true name. So they're left anonymous
until typecheck.
UseClosure does relatively little work today, but it serves as a
useful spot to check that the code setting up closures got it right.
It may also eventually serve as an optimization point for early
lifting of trivial closures, which may or may not ultimately be
beneficial.
Change-Id: I7da1e93c70d268f575b12d6aaeb2336eb910a6f1
Reviewed-on: https://go-review.googlesource.com/c/go/+/327051
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 adds a variant of ir.TypeNode that allows specifying position
information. This shouldn't normally be needed/used, but it's
occasionally helpful for writing code that passes toolstash -cmp.
Change-Id: I2be5da0339fd1ec2bee01d6c5310bd2ef58c46b4
Reviewed-on: https://go-review.googlesource.com/c/go/+/327049
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
|
|
When constructing struct literals, importers need a way to specify
precisely which field to initialize without worrying about visibility
or those fields being blank. (A blank field doesn't actually need to
be initialized, but the expression needs to be evaluated still, and
with the right order-of-operations.)
This CL changes StructKeyExpr's Field field to point directly to the
corresponding types.Field, rather than merely holding a copy of its
Sym and Offset. This is akin to past changes to add
SelectorExpr.Selection.
Change-Id: I95b72b1788f73206fcebc22b456cf6b1186db6a7
Reviewed-on: https://go-review.googlesource.com/c/go/+/325031
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
|
|
runtime
When compiling runtime, we don't allow closures to escape,
because we don't want (implicit) allocations to occur when it is
not okay to allocate (e.g. in the allocator itself). However, for
go statement, it already allocates a new goroutine anyway. It is
okay to allocate the closure. Allow it.
Also include the closure's name when reporting error.
Updates #40724.
Change-Id: Id7574ed17cc27709609a059c4eaa67ba1c4436dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/325109
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
|
|
This CL refactors mkinlcall by extracting the core InlinedCallExpr
construction code into a new "oldInline" function, and adds a new
"NewInline" hook point that can be overriden with a new inliner
implementation that only needs to worry about the details of
constructing the InlinedCallExpr.
It also moves the delayretvars optimization check into CanInline, so
it's performed just once per inlinable function rather than once for
each inlined call.
Finally, it skips printing the function body about to be inlined (and
updates the couple of regress tests that expected this output). We
already report the inline body as it was saved, and this diagnostic is
only applicable to the current inliner, which clones existing function
body instances. In the unified IR inliner, we'll directly construct
inline bodies from the serialized representation.
Change-Id: Ibdbe617da83c07665dcbda402cc8d4d4431dde2f
Reviewed-on: https://go-review.googlesource.com/c/go/+/323290
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>
|
|
This CL adds ir.RawOrigExpr, which can be used to represent arbitrary
constant expressions without needing to build and carry around an
entire IR representation of the original expression. It also allows
distinguishing how the constant was originally written by the
user (e.g., "0xff" vs "255").
This CL then also updates irgen to make use of this functionality for
expressions that were constant folded by types2.
Change-Id: I41e04e228e715ae2735c357b75633a2d08ee7021
Reviewed-on: https://go-review.googlesource.com/c/go/+/323210
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>
Reviewed-by: Dan Scales <danscales@google.com>
|
|
When dumping node positions, include column position and the full
inlining tree. These details are helpful for diagnosing "toolstash
-cmp" failures due to subtly changing positions.
Change-Id: I953292d6c01899fd98e2f315bafaa123c4d98ffd
Reviewed-on: https://go-review.googlesource.com/c/go/+/321089
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>
|
|
This CL just adds some additional details to existing Fatalf messages
that make them more useful for identifying what went wrong.
Change-Id: Icba0d943ccfb1b810a1ede0977cc8cf22b2afde5
Reviewed-on: https://go-review.googlesource.com/c/go/+/320612
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>
|
|
We were handling the case where an OFUNCINST node was used as a function
value, but not the case when an OFUNCINST node was used as a method
value. In the case of a method value, we need to create a new selector
expression that references the newly stenciled method.
To make this work, also needed small fix to noder2 code to properly set the
Sel of a method SelectorExpr (should be just the base method name, not
the full method name including the type string). This has to be correct,
so that the function created by MethodValueWrapper() can be typechecked
successfully.
Fixes #45817
Change-Id: I7343e8a0d35fc46b44dfe4d45b77997ba6c8733e
Reviewed-on: https://go-review.googlesource.com/c/go/+/319589
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
|
|
This is only changes to comments, so should be fine to go into 1.17.
Change-Id: I01e28dc76b03fb3ca846d976f8ac84bc2acb2ea2
Reviewed-on: https://go-review.googlesource.com/c/go/+/318009
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
|
|
Updates #19367.
Updates #40481.
Change-Id: Iabd2afdd0d520e5d68fd9e6dedd013335a4b3886
Reviewed-on: https://go-review.googlesource.com/c/go/+/312214
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>
Reviewed-by: Keith Randall <khr@golang.org>
|
|
Change-Id: I8fc77e29cb44fef264a62ff00452b9fcf6e30be8
GitHub-Last-Rev: 414cda8ce6e64fb53d3d1ec01caa7e33c0219236
GitHub-Pull-Request: golang/go#45842
Reviewed-on: https://go-review.googlesource.com/c/go/+/314990
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
|
|
As discussion in CL 313289, Name.Defn is also be set for variables
declared in type switch, or name function.
Change-Id: I3deb3d79fca269356e4432b77df7c7720a523674
Reviewed-on: https://go-review.googlesource.com/c/go/+/313889
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
|
|
It is not used anywhere.
Change-Id: I2b8d64902e16893ab5e1b84943f6d865c6e9c7bd
Reviewed-on: https://go-review.googlesource.com/c/go/+/311950
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>
|
|
After Russquake, all the Node ops now have different structure, update
comment to reflect that.
Change-Id: I43f859783cda457528ae4d2da9857f2cc0438b62
Reviewed-on: https://go-review.googlesource.com/c/go/+/311949
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>
|
|
Panic if the slice is too short.
Updates #395
Change-Id: I90f4bff2da5d8f3148ba06d2482084f32b25c29a
Reviewed-on: https://go-review.googlesource.com/c/go/+/301650
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
|
|
Add in some missing global assignment ops to the list of globals ops
that should be traversed to look for generic function instantiations.
The most common other one for global assigments (and the relevant one
for this bug) is OAS2FUNC, but also look at global assigments with
OAS2DOTTYPE, OAS2MAPR, OAS2RECV, and OASOP.
Bonus small fix: get rid of -G=3 case in ir.IsAddressable. Now that we
don't call the old typechecker from noder2, we don't need this -G-3
check anymore.
Fixes #45547.
Change-Id: I75fecec55ea0d6f62e1c2294d4d77447ed9be6ae
Reviewed-on: https://go-review.googlesource.com/c/go/+/310210
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
Changed RParams in types.Type to be a pointer to a slice, rather than a
slice itself, in order to reduce it from three words to one words, since
the large majority of types will not be generic or instantiated from a
generic type.
Additional cleanup: remove operation OTYPEINST, which we don't have need
of, since all type instantiations are either handled by types2 or happen
automatically during some form of stenciling.
Both of these are useful cleanups before the Go 1.17 freeze.
Change-Id: I61ad56b3c698b30d2cb5a2cdd12263202c54f49c
Reviewed-on: https://go-review.googlesource.com/c/go/+/308770
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
|
|
This CL restructures how we track function ABIs and generate ABI
wrappers in the compiler and adds import/export of ABIs across package
boundaries.
Currently, we start by tracking definition and referencing ABIs in two
global maps and eventually move some of this information into the
LSyms for functions. This complicates a lot of the existing code for
handling wrappers and makes it particularly hard to export ABI
information across packages. This change is built around instead
recording this information on the ir.Func.
First, this change replaces the global ABI def/ref maps with a type,
which makes the data flow and lifetime of this information clear in
gc.Main. These are populated during flag parsing.
Then, early in the front-end, we loop over all ir.Funcs to 1. attach
ABI def/ref information to the ir.Funcs and 2. create new ir.Funcs for
ABI wrappers. Step 1 is slightly subtle because the information is
keyed by linker symbol names, so we can't simply look things up in the
compiler's regular symbol table.
By generating ABI wrappers early in the front-end, we decouple this
step from LSym creation, which makes LSym creation much simpler (like
it was before ABI wrappers). In particular, LSyms for wrappers are now
created at the same time as all other functions instead of by
makeABIWrapper, which means we're back to the simpler, old situation
where InitLSym was the only thing responsible for constructing
function LSyms. Hence, we can restore the check that InitLSym is
called exactly once per function.
Attaching the ABI information to the ir.Func has several follow-on
benefits:
1. It's now easy to include in the export info. This enables direct
cross-package cross-ABI calls, which are important for the performance
of calling various hot assembly functions (e.g., internal/bytealg.*).
This was really the point of this whole change.
2. Since all Funcs, including wrappers, now record their definition
ABI, callTargetLSym no longer needs to distinguish wrappers from
non-wrappers, so it's now nearly trivial (it would be completely
trivial except that it has to work around a handful of cases where
ir.Name.Func is nil).
The simplification of callTargetLSym has one desirable but potentially
surprising side-effect: the compiler will now generate direct calls to
the definition ABI even when ABI wrappers are turned off. This is
almost completely unnoticeable except that cmd/internal/obj/wasm looks
for the call from runtime.deferreturn (defined in Go) to
runtime.jmpdefer (defined in assembly) to compile is specially. That
now looks like a direct call to ABI0 rather than going through the
ABIInternal alias.
While we're in here, we also set up the structures to support more
than just ABI0 and ABIInternal and add various additional consistency
checks all around.
Performance-wise, this reduces the overhead induced by wrappers from
1.24% geomean (on Sweet) to 0.52% geomean, and reduces the number of
benchmarks impacts >2% from 5 to 3. It has no impact on compiler speed.
Impact of wrappers before this change:
name old time/op new time/op delta
BiogoIgor 15.8s ± 2% 15.8s ± 1% ~ (p=0.863 n=25+25)
BiogoKrishna 18.3s ± 6% 18.1s ± 7% -1.39% (p=0.015 n=25+25)
BleveIndexBatch100 5.88s ± 3% 6.04s ± 6% +2.72% (p=0.000 n=25+25)
BleveQuery 6.42s ± 1% 6.76s ± 1% +5.31% (p=0.000 n=24+24)
CompileTemplate 245ms ± 3% 250ms ± 6% ~ (p=0.068 n=22+25)
CompileUnicode 93.6ms ± 2% 93.9ms ± 5% ~ (p=0.958 n=22+25)
CompileGoTypes 1.60s ± 2% 1.59s ± 2% ~ (p=0.115 n=24+24)
CompileCompiler 104ms ± 4% 104ms ± 3% ~ (p=0.453 n=22+25)
CompileSSA 11.0s ± 2% 11.0s ± 1% ~ (p=0.789 n=24+25)
CompileFlate 153ms ± 2% 153ms ± 1% ~ (p=0.055 n=21+20)
CompileGoParser 229ms ± 2% 230ms ± 2% ~ (p=0.305 n=21+22)
CompileReflect 585ms ± 5% 582ms ± 3% ~ (p=0.365 n=25+25)
CompileTar 211ms ± 1% 211ms ± 3% ~ (p=0.592 n=20+22)
CompileXML 282ms ± 3% 281ms ± 2% ~ (p=0.937 n=22+23)
CompileStdCmd 13.7s ± 3% 13.6s ± 2% ~ (p=0.700 n=25+25)
FoglemanFauxGLRenderRotateBoat 8.67s ± 1% 8.78s ± 1% +1.30% (p=0.000 n=25+25)
FoglemanPathTraceRenderGopherIter1 20.5s ± 2% 20.9s ± 2% +1.85% (p=0.000 n=25+25)
GopherLuaKNucleotide 30.1s ± 2% 31.1s ± 2% +3.38% (p=0.000 n=25+25)
MarkdownRenderXHTML 246ms ± 5% 250ms ± 1% +1.42% (p=0.002 n=25+23)
Tile38WithinCircle100kmRequest 828µs ± 6% 885µs ± 6% +6.85% (p=0.000 n=23+25)
Tile38IntersectsCircle100kmRequest 1.04ms ± 5% 1.10ms ± 7% +5.63% (p=0.000 n=25+25)
Tile38KNearestLimit100Request 974µs ± 4% 972µs ± 4% ~ (p=0.356 n=25+24)
[Geo mean] 588ms 595ms +1.24%
(https://perf.golang.org/search?q=upload:20210328.5)
And after this change:
name old time/op new time/op delta
BiogoIgor 15.9s ± 1% 15.8s ± 1% -0.48% (p=0.008 n=22+25)
BiogoKrishna 18.4s ± 6% 17.8s ± 6% -3.55% (p=0.008 n=25+25)
BleveIndexBatch100 5.86s ± 3% 5.97s ± 4% +1.88% (p=0.001 n=25+25)
BleveQuery 6.42s ± 1% 6.75s ± 1% +5.14% (p=0.000 n=25+25)
CompileTemplate 246ms ± 5% 245ms ± 2% ~ (p=0.472 n=23+23)
CompileUnicode 93.7ms ± 3% 93.5ms ± 2% ~ (p=0.813 n=22+23)
CompileGoTypes 1.60s ± 2% 1.60s ± 2% ~ (p=0.108 n=25+23)
CompileCompiler 104ms ± 3% 104ms ± 2% ~ (p=0.845 n=23+23)
CompileSSA 11.0s ± 2% 11.0s ± 2% ~ (p=0.525 n=25+25)
CompileFlate 152ms ± 1% 153ms ± 2% ~ (p=0.408 n=22+22)
CompileGoParser 230ms ± 1% 230ms ± 1% ~ (p=0.363 n=21+23)
CompileReflect 582ms ± 3% 584ms ± 4% ~ (p=0.658 n=25+25)
CompileTar 212ms ± 2% 211ms ± 2% ~ (p=0.315 n=23+24)
CompileXML 282ms ± 1% 282ms ± 1% ~ (p=0.991 n=23+22)
CompileStdCmd 13.6s ± 2% 13.6s ± 2% ~ (p=0.699 n=25+24)
FoglemanFauxGLRenderRotateBoat 8.66s ± 1% 8.69s ± 1% +0.28% (p=0.002 n=25+24)
FoglemanPathTraceRenderGopherIter1 20.5s ± 3% 20.5s ± 2% ~ (p=0.407 n=25+25)
GopherLuaKNucleotide 30.1s ± 2% 31.2s ± 2% +3.82% (p=0.000 n=25+25)
MarkdownRenderXHTML 246ms ± 3% 245ms ± 1% ~ (p=0.478 n=23+22)
Tile38WithinCircle100kmRequest 820µs ± 4% 856µs ± 5% +4.39% (p=0.000 n=24+25)
Tile38IntersectsCircle100kmRequest 1.05ms ± 6% 1.07ms ± 6% +1.91% (p=0.014 n=25+25)
Tile38KNearestLimit100Request 970µs ± 4% 970µs ± 3% ~ (p=0.819 n=22+24)
[Geo mean] 588ms 591ms +0.52%
(https://perf.golang.org/search?q=upload:20210328.6)
For #40724.
Change-Id: I1c374e32d4bbc88efed062a1b360017d3642140d
Reviewed-on: https://go-review.googlesource.com/c/go/+/305274
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
|
|
ir.Name.Func is non-nil for *almost* all function names. This CL fixes
a few more major cases that leave it nil, though there are still a few
cases left: interface method values, and algorithms generated by
eqFor, hashfor, and hashmem.
We'll need this for mapping from ir.Names to function ABIs shortly.
The remaining cases would be nice to fix, but they're all guaranteed
to be ABIInternal, so we can at least work around them.
For #40724.
Change-Id: Ifcfa781c78899ccea0bf155d80f8cfc27f30351e
Reviewed-on: https://go-review.googlesource.com/c/go/+/305271
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
|
|
CL 64811 removed dcopy. Update the comment in types.Sym.
The Russquake moved iexport.go. Update the path to it.
WRAPPER is now also used by ABI wrappers, so update the comment since
it's now more general than method wrappers.
Change-Id: Ie0df61dcef7168f6720838cd5c9a66adf546a44f
Reviewed-on: https://go-review.googlesource.com/c/go/+/305269
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
|
|
Adds code to the compiler's "order" phase to rewrite go and defer
statements to always be argument-less. E.g.
defer f(x,y) => x1, y1 := x, y
defer func() { f(x1, y1) }
This transformation is not beneficial on its own, but it helps
simplify runtime defer handling for the new register ABI (when
invoking deferred functions on the panic path, the runtime doesn't
need to manage the complexity of determining which args to pass in
register vs memory).
This feature is currently enabled by default if GOEXPERIMENT=regabi or
GOEXPERIMENT=regabidefer is in effect.
Included in this CL are some workarounds in the runtime to insure that
"go" statement targets in the runtime are argument-less already (since
wrapping them can potentially introduce heap-allocated closures, which
are currently not allowed). The expectation is that these workarounds
will be temporary, and can go away once we either A) change the rules
about heap-allocated closures, or B) implement some other scheme for
handling go statements.
Change-Id: I01060d79a6b140c6f0838d6e6813f807ccdca319
Reviewed-on: https://go-review.googlesource.com/c/go/+/298669
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
|
|
For additions, compares, and slices, create transform functions that do
just the transformations for those nodes by the typecheck package (given
that the code has been fully typechecked by types2). For nodes that have
no args with typeparams, we call these transform functions directly in
noder2. But for nodes that have args with typeparams, we have to delay
and call the tranform functions during stenciling, since we don't know
the specific types involved.
We indicate that a node still needs transformation by setting Typecheck
to a new value 3. This value means the current type of the node has been
set (via types2), but the node may still need transformation.
Had to export typcheck.IsCmp and typecheck.Assignop from the typecheck
package.
Added new tests list2.go (required delaying compare typecheck/transform
because of != compare in checkList) and adder.go (requires delaying add
typecheck/transform, since it can do addition for numbers or strings).
There are several more transformation functions needed for expressions
(indexing, calls, etc.) and several more complicated ones needed for
statements (mainly various kinds of assignments).
Change-Id: I7d89d13a4108308ea0304a4b815ab60b40c59b0a
Reviewed-on: https://go-review.googlesource.com/c/go/+/303091
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
Repair of CL 300749.
ALSO:
found evidence that stack maps for bodyless methods are wrong.
gofmt in test/abi
removed never-executed code in types/size.go
Updates #44816.
Updates #40724.
Change-Id: Ifeb5fee60f60e7c7b58ee0457f58a3265d6cf3f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/302071
Trust: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
|
|
This reverts commit 8ed438c077d82c4b4662c327dbbdb3c64e7547ca, CL 300749.
Reason for revert: Looks like it crashes on link-register architectures
Change-Id: I0c261df58900008cada3359889d2a87508158447
Reviewed-on: https://go-review.googlesource.com/c/go/+/302053
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
|
