delta/go-git.git/src/cmd/compile/internal/inline, branch dev.cmdgo

[dev.typeparams] cmd/compile: set Func.ClosureCalled in escape analysis

2021-07-04T00:19:26+00:00

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 
Trust: Matthew Dempsky 
TryBot-Result: Go Bot 
Reviewed-by: Cuong Manh Le

[dev.typeparams] cmd/compile: flatten OINLCALL in walk

2021-07-03T17:45:52+00:00

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 
TryBot-Result: Go Bot 
Reviewed-by: Cuong Manh Le 
Trust: Matthew Dempsky

[dev.typeparams] cmd/compile: rename OCALLPART to OMETHVALUE

2021-06-27T09:38:35+00:00

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 
Run-TryBot: Cuong Manh Le 
TryBot-Result: Go Bot 
Reviewed-by: Matthew Dempsky

[dev.typeparams] cmd/compile: rewrite method calls during typecheck

2021-06-26T08:39:47+00:00

CL 330671 move rewriting method call to method expression to escape
analysis. This CL move the rewriting up further, into typecheck. It
helps simplify the code for dowstream passes, as they now only have to
deal with OCALLFUNC.

There're two notes:

 - For -G=3, we can't rewrite d.M() where d is an instantiated receiver
   in transformCall, but let irgen.stencil to rewrite it.

 - Escape analysis still have to check for rewriting method calls, as
   the devirtualization pass can still generate OCALLMETH.

Does not pass toolstash, since when the export data now contains method
expression calls instead of method calls.

Change-Id: I77465ef04d50dc4efedddca7eb55b3fc9483db0e
Reviewed-on: https://go-review.googlesource.com/c/go/+/330831
Trust: Cuong Manh Le 
Run-TryBot: Cuong Manh Le 
TryBot-Result: Go Bot 
Reviewed-by: Matthew Dempsky

[dev.typeparams] cmd/compile: simplify NewClosureFunc

2021-06-12T15:17:14+00:00

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 
Run-TryBot: Matthew Dempsky 
Reviewed-by: Cuong Manh Le 
TryBot-Result: Go Bot

[dev.typeparams] cmd/compile: refactor closure construction

2021-06-12T13:53:19+00:00

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 
Run-TryBot: Matthew Dempsky 
TryBot-Result: Go Bot 
Reviewed-by: Cuong Manh Le

[dev.typeparams] cmd/compile: refactor export writing

2021-06-05T23:29:09+00:00

This CL reorganizes export writing in preparation for unified IR:

1. It moves dumpexport into noder as noder.WriteExports so that it can
be extended to include unified IR's export data.

2. Adds an "extensions" flag to typecheck.WriteExports to control
whether the compiler-only extension data (e.g., function bodies and
linker symbol info) is included in the exports.

3. It moves the gc.exporter type into typecheck and renames it to
"crawler". The type originated as the implementation of
the (pre-iexport) binary exporter, but since the removal of bexport
it's been relegated to simply crawling the exported functions/bodies
graph to identify which inline bodies need to be included.

4. It changes inline.Inline_Flood into the method crawler.markInlBody.
Inline_Flood doesn't actually have anything to do with the rest of
inlining; its current name and location are just historical quirks.

Passes toolstash -cmp.

Change-Id: I6445e2de9d3ce500a3aded5a8e20b09f46d23dbc
Reviewed-on: https://go-review.googlesource.com/c/go/+/325212
Run-TryBot: Matthew Dempsky 
Trust: Matthew Dempsky 
Trust: Robert Griesemer 
Reviewed-by: Robert Griesemer

[dev.typeparams] cmd/compile/internal/inline: refactor mkinlcall

2021-05-27T23:40:56+00:00

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 
Trust: Dan Scales 
Run-TryBot: Matthew Dempsky 
TryBot-Result: Go Bot 
Reviewed-by: Dan Scales

[dev.typeparams] cmd/compile: inlining tweaks for toolstash

2021-05-26T23:50:54+00:00

This CL makes to minor changes motivated by making it easier to make
large-scale changes to the inliner while satisfying toolstash -cmp:

1. When creating inlining variables, make sure to preserve the
AutoTemp flag. This is necessary so that temporary variables
introduced by rewriting f(g()) calls during typecheck stay autotemp
after inlining and are (correctly) omitted from DWARF debugging
information.

2. When sorting variables for stack frame layout, use a stable
sort. This ensures that layout is insensitive to whether deadcode
elimination happens before or after inlining.

Change-Id: I672e752a873c7e16749b9873fd6573607e074309
Reviewed-on: https://go-review.googlesource.com/c/go/+/323011
Trust: Matthew Dempsky 
Trust: Dan Scales 
Run-TryBot: Matthew Dempsky 
TryBot-Result: Go Bot 
Reviewed-by: Dan Scales

[dev.typeparams] cmd/compile: simplify inlining variadic calls

2021-05-26T23:50:45+00:00

We already have and use FixVariadicCall to normalize non-dotted calls
to variadic functions elsewhere in the compiler to simplify rewriting
of function calls. This CL updates inl.go to use it too.

A couple tests need to be updated to (correctly) expect diagnostics
about "... argument" instead of a slice literal. This is because
inl.go previously failed to set Implicit on the slice literal node.

Change-Id: I76bd79b95ae1f16e3b26ff7e9e1c468f538fd1f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/323009
Trust: Matthew Dempsky 
Trust: Dan Scales 
Run-TryBot: Matthew Dempsky 
TryBot-Result: Go Bot 
Reviewed-by: Dan Scales