[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
// UNREVIEWED
|
|
|
|
|
|
|
|
|
|
// Copyright 2021 The Go Authors. All rights reserved.
|
|
|
|
|
// Use of this source code is governed by a BSD-style
|
|
|
|
|
// license that can be found in the LICENSE file.
|
|
|
|
|
|
|
|
|
|
package noder
|
|
|
|
|
|
|
|
|
|
import (
|
|
|
|
|
"bytes"
|
|
|
|
|
"fmt"
|
|
|
|
|
"go/constant"
|
2021-09-08 15:59:11 -07:00
|
|
|
"internal/buildcfg"
|
2022-02-14 09:41:19 -08:00
|
|
|
"internal/pkgbits"
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
"strings"
|
|
|
|
|
|
|
|
|
|
"cmd/compile/internal/base"
|
|
|
|
|
"cmd/compile/internal/deadcode"
|
|
|
|
|
"cmd/compile/internal/dwarfgen"
|
2021-07-03 04:53:25 -07:00
|
|
|
"cmd/compile/internal/inline"
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
"cmd/compile/internal/ir"
|
2021-06-23 21:33:24 -07:00
|
|
|
"cmd/compile/internal/reflectdata"
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
"cmd/compile/internal/typecheck"
|
|
|
|
|
"cmd/compile/internal/types"
|
|
|
|
|
"cmd/internal/obj"
|
|
|
|
|
"cmd/internal/src"
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
type pkgReader struct {
|
2022-02-14 09:41:19 -08:00
|
|
|
pkgbits.PkgDecoder
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
posBases []*src.PosBase
|
|
|
|
|
pkgs []*types.Pkg
|
|
|
|
|
typs []*types.Type
|
|
|
|
|
|
|
|
|
|
// offset for rewriting the given index into the output,
|
|
|
|
|
// but bitwise inverted so we can detect if we're missing the entry or not.
|
|
|
|
|
newindex []int
|
|
|
|
|
}
|
|
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
func newPkgReader(pr pkgbits.PkgDecoder) *pkgReader {
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
return &pkgReader{
|
2022-02-14 09:41:19 -08:00
|
|
|
PkgDecoder: pr,
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
posBases: make([]*src.PosBase, pr.NumElems(pkgbits.RelocPosBase)),
|
|
|
|
|
pkgs: make([]*types.Pkg, pr.NumElems(pkgbits.RelocPkg)),
|
|
|
|
|
typs: make([]*types.Type, pr.NumElems(pkgbits.RelocType)),
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
newindex: make([]int, pr.TotalElems()),
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
type pkgReaderIndex struct {
|
2021-06-28 22:41:50 -07:00
|
|
|
pr *pkgReader
|
|
|
|
|
idx int
|
|
|
|
|
dict *readerDict
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
func (pri pkgReaderIndex) asReader(k pkgbits.RelocKind, marker pkgbits.SyncMarker) *reader {
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
r := pri.pr.newReader(k, pri.idx, marker)
|
2021-06-28 22:41:50 -07:00
|
|
|
r.dict = pri.dict
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
return r
|
|
|
|
|
}
|
|
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
func (pr *pkgReader) newReader(k pkgbits.RelocKind, idx int, marker pkgbits.SyncMarker) *reader {
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
return &reader{
|
2022-02-14 09:41:19 -08:00
|
|
|
Decoder: pr.NewDecoder(k, idx, marker),
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
p: pr,
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
type reader struct {
|
2022-02-14 09:41:19 -08:00
|
|
|
pkgbits.Decoder
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
p *pkgReader
|
|
|
|
|
|
2021-06-28 22:41:50 -07:00
|
|
|
dict *readerDict
|
|
|
|
|
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
// TODO(mdempsky): The state below is all specific to reading
|
|
|
|
|
// function bodies. It probably makes sense to split it out
|
|
|
|
|
// separately so that it doesn't take up space in every reader
|
|
|
|
|
// instance.
|
|
|
|
|
|
[dev.typeparams] cmd/compile: simplify variable capturing in unified IR
While initially building out unified IR, I didn't have any indexing
scheme. Everything was written out in order. Consequently, if I wanted
to write A before B, I had to compute A before B.
One particular example of this is handling closure variables: the
reader needs the list of closure variables before it can start reading
the function body, so I had to write them out first, and so I had to
compute them first in a separate, dedicated pass.
However, that constraint went away a while ago. For example, it's now
possible to replace the two-pass closure variable capture with a
single pass. We just write out the function body earlier, but then
wait to write out its index.
I anticipate this approach will make it easier to implement
dictionaries: rather than needing a separate pass to correctly
recognize and handle all of the generics cases, we can just hook into
the existing logic.
Change-Id: Iab1e07f9202cd5d2b6864eef10116960456214df
Reviewed-on: https://go-review.googlesource.com/c/go/+/330851
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>
2021-06-25 01:54:50 -07:00
|
|
|
curfn *ir.Func
|
|
|
|
|
locals []*ir.Name
|
|
|
|
|
closureVars []*ir.Name
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
funarghack bool
|
|
|
|
|
|
|
|
|
|
// scopeVars is a stack tracking the number of variables declared in
|
|
|
|
|
// the current function at the moment each open scope was opened.
|
|
|
|
|
scopeVars []int
|
|
|
|
|
marker dwarfgen.ScopeMarker
|
|
|
|
|
lastCloseScopePos src.XPos
|
|
|
|
|
|
|
|
|
|
// === details for handling inline body expansion ===
|
|
|
|
|
|
|
|
|
|
// If we're reading in a function body because of inlining, this is
|
|
|
|
|
// the call that we're inlining for.
|
|
|
|
|
inlCaller *ir.Func
|
|
|
|
|
inlCall *ir.CallExpr
|
|
|
|
|
inlFunc *ir.Func
|
|
|
|
|
inlTreeIndex int
|
|
|
|
|
inlPosBases map[*src.PosBase]*src.PosBase
|
|
|
|
|
|
|
|
|
|
delayResults bool
|
|
|
|
|
|
|
|
|
|
// Label to return to.
|
|
|
|
|
retlabel *types.Sym
|
|
|
|
|
|
|
|
|
|
inlvars, retvars ir.Nodes
|
|
|
|
|
}
|
|
|
|
|
|
2021-06-28 22:41:50 -07:00
|
|
|
type readerDict struct {
|
|
|
|
|
// targs holds the implicit and explicit type arguments in use for
|
|
|
|
|
// reading the current object. For example:
|
|
|
|
|
//
|
|
|
|
|
// func F[T any]() {
|
|
|
|
|
// type X[U any] struct { t T; u U }
|
|
|
|
|
// var _ X[string]
|
|
|
|
|
// }
|
|
|
|
|
//
|
|
|
|
|
// var _ = F[int]
|
|
|
|
|
//
|
|
|
|
|
// While instantiating F[int], we need to in turn instantiate
|
|
|
|
|
// X[string]. [int] and [string] are explicit type arguments for F
|
|
|
|
|
// and X, respectively; but [int] is also the implicit type
|
|
|
|
|
// arguments for X.
|
|
|
|
|
//
|
|
|
|
|
// (As an analogy to function literals, explicits are the function
|
|
|
|
|
// literal's formal parameters, while implicits are variables
|
|
|
|
|
// captured by the function literal.)
|
|
|
|
|
targs []*types.Type
|
|
|
|
|
|
|
|
|
|
// implicits counts how many of types within targs are implicit type
|
|
|
|
|
// arguments; the rest are explicit.
|
|
|
|
|
implicits int
|
|
|
|
|
|
2021-07-13 09:09:32 -07:00
|
|
|
derived []derivedInfo // reloc index of the derived type's descriptor
|
|
|
|
|
derivedTypes []*types.Type // slice of previously computed derived types
|
|
|
|
|
|
|
|
|
|
funcs []objInfo
|
|
|
|
|
funcsObj []ir.Node
|
2022-03-07 03:35:14 -08:00
|
|
|
|
|
|
|
|
itabs []itabInfo2
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
type itabInfo2 struct {
|
|
|
|
|
typ *types.Type
|
|
|
|
|
lsym *obj.LSym
|
2021-06-28 22:41:50 -07:00
|
|
|
}
|
|
|
|
|
|
2021-09-01 11:53:36 -07:00
|
|
|
func setType(n ir.Node, typ *types.Type) {
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
n.SetType(typ)
|
|
|
|
|
n.SetTypecheck(1)
|
|
|
|
|
|
|
|
|
|
if name, ok := n.(*ir.Name); ok {
|
|
|
|
|
name.Ntype = ir.TypeNode(name.Type())
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-09-01 11:53:36 -07:00
|
|
|
func setValue(name *ir.Name, val constant.Value) {
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
name.SetVal(val)
|
|
|
|
|
name.Defn = nil
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// @@@ Positions
|
|
|
|
|
|
|
|
|
|
func (r *reader) pos() src.XPos {
|
|
|
|
|
return base.Ctxt.PosTable.XPos(r.pos0())
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) pos0() src.Pos {
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncPos)
|
|
|
|
|
if !r.Bool() {
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
return src.NoPos
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
posBase := r.posBase()
|
2022-02-14 09:41:19 -08:00
|
|
|
line := r.Uint()
|
|
|
|
|
col := r.Uint()
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
return src.MakePos(posBase, line, col)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) posBase() *src.PosBase {
|
2022-02-14 09:41:19 -08:00
|
|
|
return r.inlPosBase(r.p.posBaseIdx(r.Reloc(pkgbits.RelocPosBase)))
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (pr *pkgReader) posBaseIdx(idx int) *src.PosBase {
|
|
|
|
|
if b := pr.posBases[idx]; b != nil {
|
|
|
|
|
return b
|
|
|
|
|
}
|
|
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
r := pr.newReader(pkgbits.RelocPosBase, idx, pkgbits.SyncPosBase)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
var b *src.PosBase
|
|
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
absFilename := r.String()
|
2021-09-08 15:59:11 -07:00
|
|
|
filename := absFilename
|
|
|
|
|
|
|
|
|
|
// For build artifact stability, the export data format only
|
|
|
|
|
// contains the "absolute" filename as returned by objabi.AbsFile.
|
|
|
|
|
// However, some tests (e.g., test/run.go's asmcheck tests) expect
|
|
|
|
|
// to see the full, original filename printed out. Re-expanding
|
|
|
|
|
// "$GOROOT" to buildcfg.GOROOT is a close-enough approximation to
|
|
|
|
|
// satisfy this.
|
|
|
|
|
//
|
|
|
|
|
// TODO(mdempsky): De-duplicate this logic with similar logic in
|
|
|
|
|
// cmd/link/internal/ld's expandGoroot. However, this will probably
|
|
|
|
|
// require being more consistent about when we use native vs UNIX
|
|
|
|
|
// file paths.
|
|
|
|
|
const dollarGOROOT = "$GOROOT"
|
2022-03-15 16:31:02 -04:00
|
|
|
if buildcfg.GOROOT != "" && strings.HasPrefix(filename, dollarGOROOT) {
|
2021-09-08 15:59:11 -07:00
|
|
|
filename = buildcfg.GOROOT + filename[len(dollarGOROOT):]
|
|
|
|
|
}
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
if r.Bool() {
|
2021-09-08 15:59:11 -07:00
|
|
|
b = src.NewFileBase(filename, absFilename)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
} else {
|
|
|
|
|
pos := r.pos0()
|
2022-02-14 09:41:19 -08:00
|
|
|
line := r.Uint()
|
|
|
|
|
col := r.Uint()
|
2021-09-08 15:59:11 -07:00
|
|
|
b = src.NewLinePragmaBase(pos, filename, absFilename, line, col)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pr.posBases[idx] = b
|
|
|
|
|
return b
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) inlPosBase(oldBase *src.PosBase) *src.PosBase {
|
|
|
|
|
if r.inlCall == nil {
|
|
|
|
|
return oldBase
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if newBase, ok := r.inlPosBases[oldBase]; ok {
|
|
|
|
|
return newBase
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
newBase := src.NewInliningBase(oldBase, r.inlTreeIndex)
|
|
|
|
|
r.inlPosBases[oldBase] = newBase
|
|
|
|
|
return newBase
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) updatePos(xpos src.XPos) src.XPos {
|
|
|
|
|
pos := base.Ctxt.PosTable.Pos(xpos)
|
|
|
|
|
pos.SetBase(r.inlPosBase(pos.Base()))
|
|
|
|
|
return base.Ctxt.PosTable.XPos(pos)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) origPos(xpos src.XPos) src.XPos {
|
|
|
|
|
if r.inlCall == nil {
|
|
|
|
|
return xpos
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pos := base.Ctxt.PosTable.Pos(xpos)
|
|
|
|
|
for old, new := range r.inlPosBases {
|
|
|
|
|
if pos.Base() == new {
|
|
|
|
|
pos.SetBase(old)
|
|
|
|
|
return base.Ctxt.PosTable.XPos(pos)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
base.FatalfAt(xpos, "pos base missing from inlPosBases")
|
|
|
|
|
panic("unreachable")
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// @@@ Packages
|
|
|
|
|
|
|
|
|
|
func (r *reader) pkg() *types.Pkg {
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncPkg)
|
|
|
|
|
return r.p.pkgIdx(r.Reloc(pkgbits.RelocPkg))
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (pr *pkgReader) pkgIdx(idx int) *types.Pkg {
|
|
|
|
|
if pkg := pr.pkgs[idx]; pkg != nil {
|
|
|
|
|
return pkg
|
|
|
|
|
}
|
|
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
pkg := pr.newReader(pkgbits.RelocPkg, idx, pkgbits.SyncPkgDef).doPkg()
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
pr.pkgs[idx] = pkg
|
|
|
|
|
return pkg
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) doPkg() *types.Pkg {
|
2022-02-14 09:41:19 -08:00
|
|
|
path := r.String()
|
2022-04-29 10:47:57 -07:00
|
|
|
switch path {
|
|
|
|
|
case "":
|
2022-02-14 09:41:19 -08:00
|
|
|
path = r.p.PkgPath()
|
2022-04-29 10:47:57 -07:00
|
|
|
case "builtin":
|
|
|
|
|
return types.BuiltinPkg
|
|
|
|
|
case "unsafe":
|
|
|
|
|
return types.UnsafePkg
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
name := r.String()
|
|
|
|
|
height := r.Len()
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
pkg := types.NewPkg(path, "")
|
|
|
|
|
|
|
|
|
|
if pkg.Name == "" {
|
|
|
|
|
pkg.Name = name
|
|
|
|
|
} else {
|
|
|
|
|
assert(pkg.Name == name)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if pkg.Height == 0 {
|
|
|
|
|
pkg.Height = height
|
|
|
|
|
} else {
|
|
|
|
|
assert(pkg.Height == height)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return pkg
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// @@@ Types
|
|
|
|
|
|
|
|
|
|
func (r *reader) typ() *types.Type {
|
2021-08-30 01:01:20 -07:00
|
|
|
return r.typWrapped(true)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// typWrapped is like typ, but allows suppressing generation of
|
|
|
|
|
// unnecessary wrappers as a compile-time optimization.
|
|
|
|
|
func (r *reader) typWrapped(wrapped bool) *types.Type {
|
|
|
|
|
return r.p.typIdx(r.typInfo(), r.dict, wrapped)
|
2021-07-13 09:09:32 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) typInfo() typeInfo {
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncType)
|
|
|
|
|
if r.Bool() {
|
|
|
|
|
return typeInfo{idx: r.Len(), derived: true}
|
2021-06-28 22:41:50 -07:00
|
|
|
}
|
2022-02-14 09:41:19 -08:00
|
|
|
return typeInfo{idx: r.Reloc(pkgbits.RelocType), derived: false}
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
|
2021-08-30 01:01:20 -07:00
|
|
|
func (pr *pkgReader) typIdx(info typeInfo, dict *readerDict, wrapped bool) *types.Type {
|
2021-07-13 09:09:32 -07:00
|
|
|
idx := info.idx
|
2021-06-28 22:41:50 -07:00
|
|
|
var where **types.Type
|
2021-07-13 09:09:32 -07:00
|
|
|
if info.derived {
|
|
|
|
|
where = &dict.derivedTypes[idx]
|
|
|
|
|
idx = dict.derived[idx].idx
|
2021-06-28 22:41:50 -07:00
|
|
|
} else {
|
|
|
|
|
where = &pr.typs[idx]
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if typ := *where; typ != nil {
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
return typ
|
|
|
|
|
}
|
|
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
r := pr.newReader(pkgbits.RelocType, idx, pkgbits.SyncTypeIdx)
|
2021-06-28 22:41:50 -07:00
|
|
|
r.dict = dict
|
|
|
|
|
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
typ := r.doTyp()
|
|
|
|
|
assert(typ != nil)
|
|
|
|
|
|
2021-06-20 02:06:45 +07:00
|
|
|
// For recursive type declarations involving interfaces and aliases,
|
|
|
|
|
// above r.doTyp() call may have already set pr.typs[idx], so just
|
|
|
|
|
// double check and return the type.
|
|
|
|
|
//
|
|
|
|
|
// Example:
|
|
|
|
|
//
|
|
|
|
|
// type F = func(I)
|
|
|
|
|
//
|
|
|
|
|
// type I interface {
|
|
|
|
|
// m(F)
|
|
|
|
|
// }
|
|
|
|
|
//
|
|
|
|
|
// The writer writes data types in following index order:
|
|
|
|
|
//
|
|
|
|
|
// 0: func(I)
|
|
|
|
|
// 1: I
|
|
|
|
|
// 2: interface{m(func(I))}
|
|
|
|
|
//
|
|
|
|
|
// The reader resolves it in following index order:
|
|
|
|
|
//
|
|
|
|
|
// 0 -> 1 -> 2 -> 0 -> 1
|
|
|
|
|
//
|
|
|
|
|
// and can divide in logically 2 steps:
|
|
|
|
|
//
|
|
|
|
|
// - 0 -> 1 : first time the reader reach type I,
|
|
|
|
|
// it creates new named type with symbol I.
|
|
|
|
|
//
|
|
|
|
|
// - 2 -> 0 -> 1: the reader ends up reaching symbol I again,
|
|
|
|
|
// now the symbol I was setup in above step, so
|
|
|
|
|
// the reader just return the named type.
|
|
|
|
|
//
|
|
|
|
|
// Now, the functions called return, the pr.typs looks like below:
|
|
|
|
|
//
|
|
|
|
|
// - 0 -> 1 -> 2 -> 0 : [<T> I <T>]
|
|
|
|
|
// - 0 -> 1 -> 2 : [func(I) I <T>]
|
|
|
|
|
// - 0 -> 1 : [func(I) I interface { "".m(func("".I)) }]
|
|
|
|
|
//
|
|
|
|
|
// The idx 1, corresponding with type I was resolved successfully
|
|
|
|
|
// after r.doTyp() call.
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
2021-06-28 22:41:50 -07:00
|
|
|
if prev := *where; prev != nil {
|
|
|
|
|
return prev
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
|
2021-08-30 01:01:20 -07:00
|
|
|
if wrapped {
|
|
|
|
|
// Only cache if we're adding wrappers, so that other callers that
|
|
|
|
|
// find a cached type know it was wrapped.
|
|
|
|
|
*where = typ
|
|
|
|
|
|
|
|
|
|
r.needWrapper(typ)
|
|
|
|
|
}
|
2021-06-28 22:41:50 -07:00
|
|
|
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
if !typ.IsUntyped() {
|
|
|
|
|
types.CheckSize(typ)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return typ
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) doTyp() *types.Type {
|
2022-02-14 09:41:19 -08:00
|
|
|
switch tag := pkgbits.CodeType(r.Code(pkgbits.SyncType)); tag {
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
default:
|
|
|
|
|
panic(fmt.Sprintf("unexpected type: %v", tag))
|
|
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
case pkgbits.TypeBasic:
|
|
|
|
|
return *basics[r.Len()]
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
case pkgbits.TypeNamed:
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
obj := r.obj()
|
|
|
|
|
assert(obj.Op() == ir.OTYPE)
|
|
|
|
|
return obj.Type()
|
|
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
case pkgbits.TypeTypeParam:
|
|
|
|
|
return r.dict.targs[r.Len()]
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
case pkgbits.TypeArray:
|
|
|
|
|
len := int64(r.Uint64())
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
return types.NewArray(r.typ(), len)
|
2022-02-14 09:41:19 -08:00
|
|
|
case pkgbits.TypeChan:
|
|
|
|
|
dir := dirs[r.Len()]
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
return types.NewChan(r.typ(), dir)
|
2022-02-14 09:41:19 -08:00
|
|
|
case pkgbits.TypeMap:
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
return types.NewMap(r.typ(), r.typ())
|
2022-02-14 09:41:19 -08:00
|
|
|
case pkgbits.TypePointer:
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
return types.NewPtr(r.typ())
|
2022-02-14 09:41:19 -08:00
|
|
|
case pkgbits.TypeSignature:
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
return r.signature(types.LocalPkg, nil)
|
2022-02-14 09:41:19 -08:00
|
|
|
case pkgbits.TypeSlice:
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
return types.NewSlice(r.typ())
|
2022-02-14 09:41:19 -08:00
|
|
|
case pkgbits.TypeStruct:
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
return r.structType()
|
2022-02-14 09:41:19 -08:00
|
|
|
case pkgbits.TypeInterface:
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
return r.interfaceType()
|
2022-04-04 14:07:36 +07:00
|
|
|
case pkgbits.TypeUnion:
|
|
|
|
|
return r.unionType()
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2022-04-04 14:07:36 +07:00
|
|
|
func (r *reader) unionType() *types.Type {
|
|
|
|
|
terms := make([]*types.Type, r.Len())
|
|
|
|
|
tildes := make([]bool, len(terms))
|
|
|
|
|
for i := range terms {
|
|
|
|
|
tildes[i] = r.Bool()
|
|
|
|
|
terms[i] = r.typ()
|
|
|
|
|
}
|
|
|
|
|
return types.NewUnion(terms, tildes)
|
|
|
|
|
}
|
|
|
|
|
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
func (r *reader) interfaceType() *types.Type {
|
|
|
|
|
tpkg := types.LocalPkg // TODO(mdempsky): Remove after iexport is gone.
|
|
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
nmethods, nembeddeds := r.Len(), r.Len()
|
2022-02-01 17:41:46 -08:00
|
|
|
implicit := nmethods == 0 && nembeddeds == 1 && r.Bool()
|
|
|
|
|
assert(!implicit) // implicit interfaces only appear in constraints
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
fields := make([]*types.Field, nmethods+nembeddeds)
|
|
|
|
|
methods, embeddeds := fields[:nmethods], fields[nmethods:]
|
|
|
|
|
|
|
|
|
|
for i := range methods {
|
|
|
|
|
pos := r.pos()
|
|
|
|
|
pkg, sym := r.selector()
|
|
|
|
|
tpkg = pkg
|
2021-08-26 13:17:56 -07:00
|
|
|
mtyp := r.signature(pkg, types.FakeRecv())
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
methods[i] = types.NewField(pos, sym, mtyp)
|
|
|
|
|
}
|
|
|
|
|
for i := range embeddeds {
|
|
|
|
|
embeddeds[i] = types.NewField(src.NoXPos, nil, r.typ())
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if len(fields) == 0 {
|
|
|
|
|
return types.Types[types.TINTER] // empty interface
|
|
|
|
|
}
|
2021-10-19 18:40:27 -04:00
|
|
|
return types.NewInterface(tpkg, fields, false)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) structType() *types.Type {
|
|
|
|
|
tpkg := types.LocalPkg // TODO(mdempsky): Remove after iexport is gone.
|
2022-02-14 09:41:19 -08:00
|
|
|
fields := make([]*types.Field, r.Len())
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
for i := range fields {
|
|
|
|
|
pos := r.pos()
|
|
|
|
|
pkg, sym := r.selector()
|
|
|
|
|
tpkg = pkg
|
|
|
|
|
ftyp := r.typ()
|
2022-02-14 09:41:19 -08:00
|
|
|
tag := r.String()
|
|
|
|
|
embedded := r.Bool()
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
f := types.NewField(pos, sym, ftyp)
|
|
|
|
|
f.Note = tag
|
|
|
|
|
if embedded {
|
|
|
|
|
f.Embedded = 1
|
|
|
|
|
}
|
|
|
|
|
fields[i] = f
|
|
|
|
|
}
|
2021-08-30 01:01:20 -07:00
|
|
|
return types.NewStruct(tpkg, fields)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) signature(tpkg *types.Pkg, recv *types.Field) *types.Type {
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncSignature)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
params := r.params(&tpkg)
|
|
|
|
|
results := r.params(&tpkg)
|
2022-02-14 09:41:19 -08:00
|
|
|
if r.Bool() { // variadic
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
params[len(params)-1].SetIsDDD(true)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return types.NewSignature(tpkg, recv, nil, params, results)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) params(tpkg **types.Pkg) []*types.Field {
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncParams)
|
|
|
|
|
fields := make([]*types.Field, r.Len())
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
for i := range fields {
|
|
|
|
|
*tpkg, fields[i] = r.param()
|
|
|
|
|
}
|
|
|
|
|
return fields
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) param() (*types.Pkg, *types.Field) {
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncParam)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
pos := r.pos()
|
|
|
|
|
pkg, sym := r.localIdent()
|
|
|
|
|
typ := r.typ()
|
|
|
|
|
|
|
|
|
|
return pkg, types.NewField(pos, sym, typ)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// @@@ Objects
|
|
|
|
|
|
|
|
|
|
var objReader = map[*types.Sym]pkgReaderIndex{}
|
|
|
|
|
|
|
|
|
|
func (r *reader) obj() ir.Node {
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncObject)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
if r.Bool() {
|
|
|
|
|
idx := r.Len()
|
2021-07-13 09:09:32 -07:00
|
|
|
obj := r.dict.funcsObj[idx]
|
|
|
|
|
if obj == nil {
|
|
|
|
|
fn := r.dict.funcs[idx]
|
|
|
|
|
targs := make([]*types.Type, len(fn.explicits))
|
|
|
|
|
for i, targ := range fn.explicits {
|
2021-08-30 01:01:20 -07:00
|
|
|
targs[i] = r.p.typIdx(targ, r.dict, true)
|
2021-07-13 09:09:32 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
obj = r.p.objIdx(fn.idx, nil, targs)
|
|
|
|
|
assert(r.dict.funcsObj[idx] == nil)
|
|
|
|
|
r.dict.funcsObj[idx] = obj
|
|
|
|
|
}
|
|
|
|
|
return obj
|
|
|
|
|
}
|
|
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
idx := r.Reloc(pkgbits.RelocObj)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
explicits := make([]*types.Type, r.Len())
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
for i := range explicits {
|
|
|
|
|
explicits[i] = r.typ()
|
|
|
|
|
}
|
|
|
|
|
|
2021-06-28 22:41:50 -07:00
|
|
|
var implicits []*types.Type
|
|
|
|
|
if r.dict != nil {
|
|
|
|
|
implicits = r.dict.targs
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return r.p.objIdx(idx, implicits, explicits)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (pr *pkgReader) objIdx(idx int, implicits, explicits []*types.Type) ir.Node {
|
2022-02-14 09:41:19 -08:00
|
|
|
rname := pr.newReader(pkgbits.RelocName, idx, pkgbits.SyncObject1)
|
2021-07-20 16:52:37 -07:00
|
|
|
_, sym := rname.qualifiedIdent()
|
2022-02-14 09:41:19 -08:00
|
|
|
tag := pkgbits.CodeObj(rname.Code(pkgbits.SyncCodeObj))
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
if tag == pkgbits.ObjStub {
|
2021-07-13 13:25:16 -07:00
|
|
|
assert(!sym.IsBlank())
|
|
|
|
|
switch sym.Pkg {
|
2021-08-26 13:17:56 -07:00
|
|
|
case types.BuiltinPkg, types.UnsafePkg:
|
2021-07-13 13:25:16 -07:00
|
|
|
return sym.Def.(ir.Node)
|
|
|
|
|
}
|
|
|
|
|
if pri, ok := objReader[sym]; ok {
|
|
|
|
|
return pri.pr.objIdx(pri.idx, nil, explicits)
|
|
|
|
|
}
|
|
|
|
|
base.Fatalf("unresolved stub: %v", sym)
|
|
|
|
|
}
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
2021-07-20 16:52:37 -07:00
|
|
|
dict := pr.objDictIdx(sym, idx, implicits, explicits)
|
|
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
r := pr.newReader(pkgbits.RelocObj, idx, pkgbits.SyncObject1)
|
|
|
|
|
rext := pr.newReader(pkgbits.RelocObjExt, idx, pkgbits.SyncObject1)
|
2021-07-20 16:52:37 -07:00
|
|
|
|
|
|
|
|
r.dict = dict
|
2021-09-07 17:24:50 -07:00
|
|
|
rext.dict = dict
|
2021-06-28 22:41:50 -07:00
|
|
|
|
2021-07-13 13:25:16 -07:00
|
|
|
sym = r.mangle(sym)
|
|
|
|
|
if !sym.IsBlank() && sym.Def != nil {
|
|
|
|
|
return sym.Def.(*ir.Name)
|
|
|
|
|
}
|
|
|
|
|
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
do := func(op ir.Op, hasTParams bool) *ir.Name {
|
|
|
|
|
pos := r.pos()
|
|
|
|
|
if hasTParams {
|
|
|
|
|
r.typeParamNames()
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
name := ir.NewDeclNameAt(pos, op, sym)
|
|
|
|
|
name.Class = ir.PEXTERN // may be overridden later
|
|
|
|
|
if !sym.IsBlank() {
|
|
|
|
|
if sym.Def != nil {
|
|
|
|
|
base.FatalfAt(name.Pos(), "already have a definition for %v", name)
|
|
|
|
|
}
|
|
|
|
|
assert(sym.Def == nil)
|
|
|
|
|
sym.Def = name
|
|
|
|
|
}
|
|
|
|
|
return name
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
switch tag {
|
|
|
|
|
default:
|
|
|
|
|
panic("unexpected object")
|
|
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
case pkgbits.ObjAlias:
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
name := do(ir.OTYPE, false)
|
2021-09-01 11:53:36 -07:00
|
|
|
setType(name, r.typ())
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
name.SetAlias(true)
|
|
|
|
|
return name
|
|
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
case pkgbits.ObjConst:
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
name := do(ir.OLITERAL, false)
|
2021-09-07 13:23:08 -07:00
|
|
|
typ := r.typ()
|
2022-02-14 09:41:19 -08:00
|
|
|
val := FixValue(typ, r.Value())
|
2021-09-01 11:53:36 -07:00
|
|
|
setType(name, typ)
|
|
|
|
|
setValue(name, val)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
return name
|
|
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
case pkgbits.ObjFunc:
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
if sym.Name == "init" {
|
2022-05-04 16:27:53 +00:00
|
|
|
sym = renameinit()
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
name := do(ir.ONAME, true)
|
2021-09-01 11:53:36 -07:00
|
|
|
setType(name, r.signature(sym.Pkg, nil))
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
name.Func = ir.NewFunc(r.pos())
|
|
|
|
|
name.Func.Nname = name
|
|
|
|
|
|
2022-03-08 14:59:32 -08:00
|
|
|
if r.hasTypeParams() {
|
|
|
|
|
name.Func.SetDupok(true)
|
|
|
|
|
}
|
|
|
|
|
|
2021-09-07 17:24:50 -07:00
|
|
|
rext.funcExt(name)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
return name
|
|
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
case pkgbits.ObjType:
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
name := do(ir.OTYPE, true)
|
|
|
|
|
typ := types.NewNamed(name)
|
2021-09-01 11:53:36 -07:00
|
|
|
setType(name, typ)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
// Important: We need to do this before SetUnderlying.
|
2021-09-07 17:24:50 -07:00
|
|
|
rext.typeExt(name)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
// We need to defer CheckSize until we've called SetUnderlying to
|
|
|
|
|
// handle recursive types.
|
|
|
|
|
types.DeferCheckSize()
|
2021-08-30 01:01:20 -07:00
|
|
|
typ.SetUnderlying(r.typWrapped(false))
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
types.ResumeCheckSize()
|
|
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
methods := make([]*types.Field, r.Len())
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
for i := range methods {
|
2021-09-07 17:24:50 -07:00
|
|
|
methods[i] = r.method(rext)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
if len(methods) != 0 {
|
|
|
|
|
typ.Methods().Set(methods)
|
|
|
|
|
}
|
|
|
|
|
|
2021-08-30 01:01:20 -07:00
|
|
|
r.needWrapper(typ)
|
2021-06-23 21:33:24 -07:00
|
|
|
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
return name
|
|
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
case pkgbits.ObjVar:
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
name := do(ir.ONAME, false)
|
2021-09-01 11:53:36 -07:00
|
|
|
setType(name, r.typ())
|
2021-09-07 17:24:50 -07:00
|
|
|
rext.varExt(name)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
return name
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) mangle(sym *types.Sym) *types.Sym {
|
2021-06-20 14:33:51 +07:00
|
|
|
if !r.hasTypeParams() {
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
return sym
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
var buf bytes.Buffer
|
|
|
|
|
buf.WriteString(sym.Name)
|
|
|
|
|
buf.WriteByte('[')
|
2021-06-28 22:41:50 -07:00
|
|
|
for i, targ := range r.dict.targs {
|
|
|
|
|
if i > 0 {
|
|
|
|
|
if i == r.dict.implicits {
|
|
|
|
|
buf.WriteByte(';')
|
|
|
|
|
} else {
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
buf.WriteByte(',')
|
|
|
|
|
}
|
|
|
|
|
}
|
2021-06-28 22:41:50 -07:00
|
|
|
buf.WriteString(targ.LinkString())
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
buf.WriteByte(']')
|
|
|
|
|
return sym.Pkg.Lookup(buf.String())
|
|
|
|
|
}
|
|
|
|
|
|
2021-07-20 16:52:37 -07:00
|
|
|
func (pr *pkgReader) objDictIdx(sym *types.Sym, idx int, implicits, explicits []*types.Type) *readerDict {
|
2022-02-14 09:41:19 -08:00
|
|
|
r := pr.newReader(pkgbits.RelocObjDict, idx, pkgbits.SyncObject1)
|
2021-07-20 16:52:37 -07:00
|
|
|
|
|
|
|
|
var dict readerDict
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
nimplicits := r.Len()
|
|
|
|
|
nexplicits := r.Len()
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
2021-06-28 22:41:50 -07:00
|
|
|
if nimplicits > len(implicits) || nexplicits != len(explicits) {
|
|
|
|
|
base.Fatalf("%v has %v+%v params, but instantiated with %v+%v args", sym, nimplicits, nexplicits, len(implicits), len(explicits))
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
|
2021-07-20 16:52:37 -07:00
|
|
|
dict.targs = append(implicits[:nimplicits:nimplicits], explicits...)
|
|
|
|
|
dict.implicits = nimplicits
|
2021-06-28 22:41:50 -07:00
|
|
|
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
// For stenciling, we can just skip over the type parameters.
|
2021-07-20 16:52:37 -07:00
|
|
|
for range dict.targs[dict.implicits:] {
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
// Skip past bounds without actually evaluating them.
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncType)
|
|
|
|
|
if r.Bool() {
|
|
|
|
|
r.Len()
|
2021-06-28 22:41:50 -07:00
|
|
|
} else {
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Reloc(pkgbits.RelocType)
|
2021-06-28 22:41:50 -07:00
|
|
|
}
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
2021-07-20 16:52:37 -07:00
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
dict.derived = make([]derivedInfo, r.Len())
|
2021-07-20 16:52:37 -07:00
|
|
|
dict.derivedTypes = make([]*types.Type, len(dict.derived))
|
|
|
|
|
for i := range dict.derived {
|
2022-02-14 09:41:19 -08:00
|
|
|
dict.derived[i] = derivedInfo{r.Reloc(pkgbits.RelocType), r.Bool()}
|
2021-07-20 16:52:37 -07:00
|
|
|
}
|
|
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
dict.funcs = make([]objInfo, r.Len())
|
2021-07-20 16:52:37 -07:00
|
|
|
dict.funcsObj = make([]ir.Node, len(dict.funcs))
|
|
|
|
|
for i := range dict.funcs {
|
2022-02-14 09:41:19 -08:00
|
|
|
objIdx := r.Reloc(pkgbits.RelocObj)
|
|
|
|
|
targs := make([]typeInfo, r.Len())
|
2021-07-20 16:52:37 -07:00
|
|
|
for j := range targs {
|
|
|
|
|
targs[j] = r.typInfo()
|
|
|
|
|
}
|
|
|
|
|
dict.funcs[i] = objInfo{idx: objIdx, explicits: targs}
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-07 03:35:14 -08:00
|
|
|
dict.itabs = make([]itabInfo2, r.Len())
|
|
|
|
|
for i := range dict.itabs {
|
|
|
|
|
typ := pr.typIdx(typeInfo{idx: r.Len(), derived: true}, &dict, true)
|
|
|
|
|
ifaceInfo := r.typInfo()
|
|
|
|
|
|
|
|
|
|
var lsym *obj.LSym
|
|
|
|
|
if typ.IsInterface() {
|
|
|
|
|
lsym = reflectdata.TypeLinksym(typ)
|
|
|
|
|
} else {
|
|
|
|
|
iface := pr.typIdx(ifaceInfo, &dict, true)
|
|
|
|
|
lsym = reflectdata.ITabLsym(typ, iface)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
dict.itabs[i] = itabInfo2{typ: typ, lsym: lsym}
|
|
|
|
|
}
|
|
|
|
|
|
2021-07-20 16:52:37 -07:00
|
|
|
return &dict
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) typeParamNames() {
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncTypeParamNames)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
2021-06-28 22:41:50 -07:00
|
|
|
for range r.dict.targs[r.dict.implicits:] {
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
r.pos()
|
|
|
|
|
r.localIdent()
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-09-07 17:24:50 -07:00
|
|
|
func (r *reader) method(rext *reader) *types.Field {
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncMethod)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
pos := r.pos()
|
|
|
|
|
pkg, sym := r.selector()
|
|
|
|
|
r.typeParamNames()
|
|
|
|
|
_, recv := r.param()
|
|
|
|
|
typ := r.signature(pkg, recv)
|
|
|
|
|
|
|
|
|
|
fnsym := sym
|
|
|
|
|
fnsym = ir.MethodSym(recv.Type, fnsym)
|
|
|
|
|
name := ir.NewNameAt(pos, fnsym)
|
2021-09-01 11:53:36 -07:00
|
|
|
setType(name, typ)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
name.Func = ir.NewFunc(r.pos())
|
|
|
|
|
name.Func.Nname = name
|
|
|
|
|
|
2022-03-08 14:59:32 -08:00
|
|
|
if r.hasTypeParams() {
|
|
|
|
|
name.Func.SetDupok(true)
|
|
|
|
|
}
|
|
|
|
|
|
2021-09-07 17:24:50 -07:00
|
|
|
rext.funcExt(name)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
meth := types.NewField(name.Func.Pos(), sym, typ)
|
|
|
|
|
meth.Nname = name
|
2021-07-02 16:59:01 -07:00
|
|
|
meth.SetNointerface(name.Func.Pragma&ir.Nointerface != 0)
|
|
|
|
|
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
return meth
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) qualifiedIdent() (pkg *types.Pkg, sym *types.Sym) {
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncSym)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
pkg = r.pkg()
|
2022-02-14 09:41:19 -08:00
|
|
|
if name := r.String(); name != "" {
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
sym = pkg.Lookup(name)
|
|
|
|
|
}
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) localIdent() (pkg *types.Pkg, sym *types.Sym) {
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncLocalIdent)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
pkg = r.pkg()
|
2022-02-14 09:41:19 -08:00
|
|
|
if name := r.String(); name != "" {
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
sym = pkg.Lookup(name)
|
|
|
|
|
}
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) selector() (origPkg *types.Pkg, sym *types.Sym) {
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncSelector)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
origPkg = r.pkg()
|
2022-02-14 09:41:19 -08:00
|
|
|
name := r.String()
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
pkg := origPkg
|
|
|
|
|
if types.IsExported(name) {
|
|
|
|
|
pkg = types.LocalPkg
|
|
|
|
|
}
|
|
|
|
|
sym = pkg.Lookup(name)
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
|
2021-06-20 14:33:51 +07:00
|
|
|
func (r *reader) hasTypeParams() bool {
|
2021-07-20 16:52:37 -07:00
|
|
|
return r.dict.hasTypeParams()
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (dict *readerDict) hasTypeParams() bool {
|
|
|
|
|
return dict != nil && len(dict.targs) != 0
|
2021-06-20 14:33:51 +07:00
|
|
|
}
|
|
|
|
|
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
// @@@ Compiler extensions
|
|
|
|
|
|
|
|
|
|
func (r *reader) funcExt(name *ir.Name) {
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncFuncExt)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
name.Class = 0 // so MarkFunc doesn't complain
|
|
|
|
|
ir.MarkFunc(name)
|
|
|
|
|
|
|
|
|
|
fn := name.Func
|
|
|
|
|
|
|
|
|
|
// XXX: Workaround because linker doesn't know how to copy Pos.
|
|
|
|
|
if !fn.Pos().IsKnown() {
|
|
|
|
|
fn.SetPos(name.Pos())
|
|
|
|
|
}
|
|
|
|
|
|
2021-06-20 22:17:19 +07:00
|
|
|
// Normally, we only compile local functions, which saves redundant compilation work.
|
|
|
|
|
// n.Defn is not nil for local functions, and is nil for imported function. But for
|
|
|
|
|
// generic functions, we might have an instantiation that no other package has seen before.
|
|
|
|
|
// So we need to be conservative and compile it again.
|
|
|
|
|
//
|
|
|
|
|
// That's why name.Defn is set here, so ir.VisitFuncsBottomUp can analyze function.
|
|
|
|
|
// TODO(mdempsky,cuonglm): find a cleaner way to handle this.
|
2021-06-20 14:33:51 +07:00
|
|
|
if name.Sym().Pkg == types.LocalPkg || r.hasTypeParams() {
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
name.Defn = fn
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
fn.Pragma = r.pragmaFlag()
|
|
|
|
|
r.linkname(name)
|
|
|
|
|
|
2021-06-30 19:20:28 -07:00
|
|
|
typecheck.Func(fn)
|
|
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
if r.Bool() {
|
|
|
|
|
fn.ABI = obj.ABI(r.Uint64())
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
// Escape analysis.
|
|
|
|
|
for _, fs := range &types.RecvsParams {
|
|
|
|
|
for _, f := range fs(name.Type()).FieldSlice() {
|
2022-02-14 09:41:19 -08:00
|
|
|
f.Note = r.String()
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
if r.Bool() {
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
fn.Inl = &ir.Inline{
|
2022-02-14 09:41:19 -08:00
|
|
|
Cost: int32(r.Len()),
|
|
|
|
|
CanDelayResults: r.Bool(),
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
2021-06-28 22:41:50 -07:00
|
|
|
r.addBody(name.Func)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
} else {
|
2021-06-28 22:41:50 -07:00
|
|
|
r.addBody(name.Func)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncEOF)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) typeExt(name *ir.Name) {
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncTypeExt)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
typ := name.Type()
|
|
|
|
|
|
2021-06-20 14:33:51 +07:00
|
|
|
if r.hasTypeParams() {
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
// Set "RParams" (really type arguments here, not parameters) so
|
|
|
|
|
// this type is treated as "fully instantiated". This ensures the
|
|
|
|
|
// type descriptor is written out as DUPOK and method wrappers are
|
|
|
|
|
// generated even for imported types.
|
|
|
|
|
var targs []*types.Type
|
2021-06-28 22:41:50 -07:00
|
|
|
targs = append(targs, r.dict.targs...)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
typ.SetRParams(targs)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
name.SetPragma(r.pragmaFlag())
|
|
|
|
|
if name.Pragma()&ir.NotInHeap != 0 {
|
|
|
|
|
typ.SetNotInHeap(true)
|
|
|
|
|
}
|
|
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
typecheck.SetBaseTypeIndex(typ, r.Int64(), r.Int64())
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) varExt(name *ir.Name) {
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncVarExt)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
r.linkname(name)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) linkname(name *ir.Name) {
|
|
|
|
|
assert(name.Op() == ir.ONAME)
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncLinkname)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
if idx := r.Int64(); idx >= 0 {
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
lsym := name.Linksym()
|
|
|
|
|
lsym.SymIdx = int32(idx)
|
|
|
|
|
lsym.Set(obj.AttrIndexed, true)
|
|
|
|
|
} else {
|
2022-02-14 09:41:19 -08:00
|
|
|
name.Sym().Linkname = r.String()
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) pragmaFlag() ir.PragmaFlag {
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncPragma)
|
|
|
|
|
return ir.PragmaFlag(r.Int())
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// @@@ Function bodies
|
|
|
|
|
|
|
|
|
|
// bodyReader tracks where the serialized IR for a function's body can
|
|
|
|
|
// be found.
|
|
|
|
|
var bodyReader = map[*ir.Func]pkgReaderIndex{}
|
|
|
|
|
|
|
|
|
|
// todoBodies holds the list of function bodies that still need to be
|
|
|
|
|
// constructed.
|
|
|
|
|
var todoBodies []*ir.Func
|
|
|
|
|
|
2021-06-28 22:41:50 -07:00
|
|
|
func (r *reader) addBody(fn *ir.Func) {
|
2022-02-14 09:41:19 -08:00
|
|
|
pri := pkgReaderIndex{r.p, r.Reloc(pkgbits.RelocBody), r.dict}
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
bodyReader[fn] = pri
|
|
|
|
|
|
2021-09-01 12:42:35 -07:00
|
|
|
if fn.Nname.Defn == nil {
|
|
|
|
|
// Don't read in function body for imported functions.
|
|
|
|
|
// See comment in funcExt.
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-06 20:11:21 -08:00
|
|
|
if r.curfn == nil {
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
todoBodies = append(todoBodies, fn)
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pri.funcBody(fn)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (pri pkgReaderIndex) funcBody(fn *ir.Func) {
|
2022-02-14 09:41:19 -08:00
|
|
|
r := pri.asReader(pkgbits.RelocBody, pkgbits.SyncFuncBody)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
r.funcBody(fn)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) funcBody(fn *ir.Func) {
|
|
|
|
|
r.curfn = fn
|
[dev.typeparams] cmd/compile: simplify variable capturing in unified IR
While initially building out unified IR, I didn't have any indexing
scheme. Everything was written out in order. Consequently, if I wanted
to write A before B, I had to compute A before B.
One particular example of this is handling closure variables: the
reader needs the list of closure variables before it can start reading
the function body, so I had to write them out first, and so I had to
compute them first in a separate, dedicated pass.
However, that constraint went away a while ago. For example, it's now
possible to replace the two-pass closure variable capture with a
single pass. We just write out the function body earlier, but then
wait to write out its index.
I anticipate this approach will make it easier to implement
dictionaries: rather than needing a separate pass to correctly
recognize and handle all of the generics cases, we can just hook into
the existing logic.
Change-Id: Iab1e07f9202cd5d2b6864eef10116960456214df
Reviewed-on: https://go-review.googlesource.com/c/go/+/330851
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>
2021-06-25 01:54:50 -07:00
|
|
|
r.closureVars = fn.ClosureVars
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
2021-07-01 15:23:41 -07:00
|
|
|
ir.WithFunc(fn, func() {
|
|
|
|
|
r.funcargs(fn)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
if !r.Bool() {
|
2021-07-01 15:23:41 -07:00
|
|
|
return
|
|
|
|
|
}
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
body := r.stmts()
|
|
|
|
|
if body == nil {
|
2022-02-11 11:55:27 -08:00
|
|
|
body = []ir.Node{typecheck.Stmt(ir.NewBlockStmt(src.NoXPos, nil))}
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
fn.Body = body
|
|
|
|
|
fn.Endlineno = r.pos()
|
2021-07-01 15:23:41 -07:00
|
|
|
})
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
r.marker.WriteTo(fn)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) funcargs(fn *ir.Func) {
|
|
|
|
|
sig := fn.Nname.Type()
|
|
|
|
|
|
|
|
|
|
if recv := sig.Recv(); recv != nil {
|
|
|
|
|
r.funcarg(recv, recv.Sym, ir.PPARAM)
|
|
|
|
|
}
|
|
|
|
|
for _, param := range sig.Params().FieldSlice() {
|
|
|
|
|
r.funcarg(param, param.Sym, ir.PPARAM)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
for i, param := range sig.Results().FieldSlice() {
|
|
|
|
|
sym := types.OrigSym(param.Sym)
|
|
|
|
|
|
|
|
|
|
if sym == nil || sym.IsBlank() {
|
|
|
|
|
prefix := "~r"
|
|
|
|
|
if r.inlCall != nil {
|
|
|
|
|
prefix = "~R"
|
|
|
|
|
} else if sym != nil {
|
|
|
|
|
prefix = "~b"
|
|
|
|
|
}
|
|
|
|
|
sym = typecheck.LookupNum(prefix, i)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
r.funcarg(param, sym, ir.PPARAMOUT)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) funcarg(param *types.Field, sym *types.Sym, ctxt ir.Class) {
|
|
|
|
|
if sym == nil {
|
|
|
|
|
assert(ctxt == ir.PPARAM)
|
|
|
|
|
if r.inlCall != nil {
|
|
|
|
|
r.inlvars.Append(ir.BlankNode)
|
|
|
|
|
}
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
name := ir.NewNameAt(r.updatePos(param.Pos), sym)
|
2021-09-01 11:53:36 -07:00
|
|
|
setType(name, param.Type)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
r.addLocal(name, ctxt)
|
|
|
|
|
|
|
|
|
|
if r.inlCall == nil {
|
|
|
|
|
if !r.funarghack {
|
|
|
|
|
param.Sym = sym
|
|
|
|
|
param.Nname = name
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
if ctxt == ir.PPARAMOUT {
|
|
|
|
|
r.retvars.Append(name)
|
|
|
|
|
} else {
|
|
|
|
|
r.inlvars.Append(name)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) addLocal(name *ir.Name, ctxt ir.Class) {
|
|
|
|
|
assert(ctxt == ir.PAUTO || ctxt == ir.PPARAM || ctxt == ir.PPARAMOUT)
|
|
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncAddLocal)
|
|
|
|
|
if pkgbits.EnableSync {
|
|
|
|
|
want := r.Int()
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
if have := len(r.locals); have != want {
|
|
|
|
|
base.FatalfAt(name.Pos(), "locals table has desynced")
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
name.SetUsed(true)
|
|
|
|
|
r.locals = append(r.locals, name)
|
|
|
|
|
|
|
|
|
|
// TODO(mdempsky): Move earlier.
|
|
|
|
|
if ir.IsBlank(name) {
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if r.inlCall != nil {
|
|
|
|
|
if ctxt == ir.PAUTO {
|
|
|
|
|
name.SetInlLocal(true)
|
|
|
|
|
} else {
|
|
|
|
|
name.SetInlFormal(true)
|
|
|
|
|
ctxt = ir.PAUTO
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// TODO(mdempsky): Rethink this hack.
|
|
|
|
|
if strings.HasPrefix(name.Sym().Name, "~") || base.Flag.GenDwarfInl == 0 {
|
|
|
|
|
name.SetPos(r.inlCall.Pos())
|
|
|
|
|
name.SetInlFormal(false)
|
|
|
|
|
name.SetInlLocal(false)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
name.Class = ctxt
|
|
|
|
|
name.Curfn = r.curfn
|
|
|
|
|
|
|
|
|
|
r.curfn.Dcl = append(r.curfn.Dcl, name)
|
|
|
|
|
|
|
|
|
|
if ctxt == ir.PAUTO {
|
|
|
|
|
name.SetFrameOffset(0)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) useLocal() *ir.Name {
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncUseObjLocal)
|
|
|
|
|
if r.Bool() {
|
|
|
|
|
return r.locals[r.Len()]
|
[dev.typeparams] cmd/compile: simplify variable capturing in unified IR
While initially building out unified IR, I didn't have any indexing
scheme. Everything was written out in order. Consequently, if I wanted
to write A before B, I had to compute A before B.
One particular example of this is handling closure variables: the
reader needs the list of closure variables before it can start reading
the function body, so I had to write them out first, and so I had to
compute them first in a separate, dedicated pass.
However, that constraint went away a while ago. For example, it's now
possible to replace the two-pass closure variable capture with a
single pass. We just write out the function body earlier, but then
wait to write out its index.
I anticipate this approach will make it easier to implement
dictionaries: rather than needing a separate pass to correctly
recognize and handle all of the generics cases, we can just hook into
the existing logic.
Change-Id: Iab1e07f9202cd5d2b6864eef10116960456214df
Reviewed-on: https://go-review.googlesource.com/c/go/+/330851
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>
2021-06-25 01:54:50 -07:00
|
|
|
}
|
2022-02-14 09:41:19 -08:00
|
|
|
return r.closureVars[r.Len()]
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) openScope() {
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncOpenScope)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
pos := r.pos()
|
|
|
|
|
|
|
|
|
|
if base.Flag.Dwarf {
|
|
|
|
|
r.scopeVars = append(r.scopeVars, len(r.curfn.Dcl))
|
|
|
|
|
r.marker.Push(pos)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) closeScope() {
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncCloseScope)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
r.lastCloseScopePos = r.pos()
|
|
|
|
|
|
|
|
|
|
r.closeAnotherScope()
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// closeAnotherScope is like closeScope, but it reuses the same mark
|
|
|
|
|
// position as the last closeScope call. This is useful for "for" and
|
|
|
|
|
// "if" statements, as their implicit blocks always end at the same
|
|
|
|
|
// position as an explicit block.
|
|
|
|
|
func (r *reader) closeAnotherScope() {
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncCloseAnotherScope)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
if base.Flag.Dwarf {
|
|
|
|
|
scopeVars := r.scopeVars[len(r.scopeVars)-1]
|
|
|
|
|
r.scopeVars = r.scopeVars[:len(r.scopeVars)-1]
|
|
|
|
|
|
2021-07-01 15:23:41 -07:00
|
|
|
// Quirkish: noder decides which scopes to keep before
|
|
|
|
|
// typechecking, whereas incremental typechecking during IR
|
|
|
|
|
// construction can result in new autotemps being allocated. To
|
|
|
|
|
// produce identical output, we ignore autotemps here for the
|
|
|
|
|
// purpose of deciding whether to retract the scope.
|
|
|
|
|
//
|
|
|
|
|
// This is important for net/http/fcgi, because it contains:
|
|
|
|
|
//
|
|
|
|
|
// var body io.ReadCloser
|
|
|
|
|
// if len(content) > 0 {
|
|
|
|
|
// body, req.pw = io.Pipe()
|
|
|
|
|
// } else { … }
|
|
|
|
|
//
|
|
|
|
|
// Notably, io.Pipe is inlinable, and inlining it introduces a ~R0
|
|
|
|
|
// variable at the call site.
|
|
|
|
|
//
|
|
|
|
|
// Noder does not preserve the scope where the io.Pipe() call
|
|
|
|
|
// resides, because it doesn't contain any declared variables in
|
|
|
|
|
// source. So the ~R0 variable ends up being assigned to the
|
|
|
|
|
// enclosing scope instead.
|
|
|
|
|
//
|
|
|
|
|
// However, typechecking this assignment also introduces
|
|
|
|
|
// autotemps, because io.Pipe's results need conversion before
|
|
|
|
|
// they can be assigned to their respective destination variables.
|
|
|
|
|
//
|
|
|
|
|
// TODO(mdempsky): We should probably just keep all scopes, and
|
|
|
|
|
// let dwarfgen take care of pruning them instead.
|
|
|
|
|
retract := true
|
|
|
|
|
for _, n := range r.curfn.Dcl[scopeVars:] {
|
|
|
|
|
if !n.AutoTemp() {
|
|
|
|
|
retract = false
|
|
|
|
|
break
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if retract {
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
// no variables were declared in this scope, so we can retract it.
|
|
|
|
|
r.marker.Unpush()
|
|
|
|
|
} else {
|
|
|
|
|
r.marker.Pop(r.lastCloseScopePos)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// @@@ Statements
|
|
|
|
|
|
|
|
|
|
func (r *reader) stmt() ir.Node {
|
|
|
|
|
switch stmts := r.stmts(); len(stmts) {
|
|
|
|
|
case 0:
|
|
|
|
|
return nil
|
|
|
|
|
case 1:
|
|
|
|
|
return stmts[0]
|
|
|
|
|
default:
|
|
|
|
|
return ir.NewBlockStmt(stmts[0].Pos(), stmts)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) stmts() []ir.Node {
|
2021-07-01 15:23:41 -07:00
|
|
|
assert(ir.CurFunc == r.curfn)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
var res ir.Nodes
|
|
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncStmts)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
for {
|
2022-02-14 09:41:19 -08:00
|
|
|
tag := codeStmt(r.Code(pkgbits.SyncStmt1))
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
if tag == stmtEnd {
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncStmtsEnd)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
return res
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if n := r.stmt1(tag, &res); n != nil {
|
2021-07-01 15:23:41 -07:00
|
|
|
res.Append(typecheck.Stmt(n))
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) stmt1(tag codeStmt, out *ir.Nodes) ir.Node {
|
|
|
|
|
var label *types.Sym
|
|
|
|
|
if n := len(*out); n > 0 {
|
|
|
|
|
if ls, ok := (*out)[n-1].(*ir.LabelStmt); ok {
|
|
|
|
|
label = ls.Label
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
switch tag {
|
|
|
|
|
default:
|
|
|
|
|
panic("unexpected statement")
|
|
|
|
|
|
|
|
|
|
case stmtAssign:
|
|
|
|
|
pos := r.pos()
|
[dev.typeparams] cmd/compile: simplify variable capturing in unified IR
While initially building out unified IR, I didn't have any indexing
scheme. Everything was written out in order. Consequently, if I wanted
to write A before B, I had to compute A before B.
One particular example of this is handling closure variables: the
reader needs the list of closure variables before it can start reading
the function body, so I had to write them out first, and so I had to
compute them first in a separate, dedicated pass.
However, that constraint went away a while ago. For example, it's now
possible to replace the two-pass closure variable capture with a
single pass. We just write out the function body earlier, but then
wait to write out its index.
I anticipate this approach will make it easier to implement
dictionaries: rather than needing a separate pass to correctly
recognize and handle all of the generics cases, we can just hook into
the existing logic.
Change-Id: Iab1e07f9202cd5d2b6864eef10116960456214df
Reviewed-on: https://go-review.googlesource.com/c/go/+/330851
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>
2021-06-25 01:54:50 -07:00
|
|
|
|
|
|
|
|
// TODO(mdempsky): After quirks mode is gone, swap these
|
|
|
|
|
// statements so we visit LHS before RHS again.
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
rhs := r.exprList()
|
[dev.typeparams] cmd/compile: simplify variable capturing in unified IR
While initially building out unified IR, I didn't have any indexing
scheme. Everything was written out in order. Consequently, if I wanted
to write A before B, I had to compute A before B.
One particular example of this is handling closure variables: the
reader needs the list of closure variables before it can start reading
the function body, so I had to write them out first, and so I had to
compute them first in a separate, dedicated pass.
However, that constraint went away a while ago. For example, it's now
possible to replace the two-pass closure variable capture with a
single pass. We just write out the function body earlier, but then
wait to write out its index.
I anticipate this approach will make it easier to implement
dictionaries: rather than needing a separate pass to correctly
recognize and handle all of the generics cases, we can just hook into
the existing logic.
Change-Id: Iab1e07f9202cd5d2b6864eef10116960456214df
Reviewed-on: https://go-review.googlesource.com/c/go/+/330851
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>
2021-06-25 01:54:50 -07:00
|
|
|
names, lhs := r.assignList()
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
if len(rhs) == 0 {
|
|
|
|
|
for _, name := range names {
|
|
|
|
|
as := ir.NewAssignStmt(pos, name, nil)
|
|
|
|
|
as.PtrInit().Append(ir.NewDecl(pos, ir.ODCL, name))
|
2021-07-01 15:23:41 -07:00
|
|
|
out.Append(typecheck.Stmt(as))
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if len(lhs) == 1 && len(rhs) == 1 {
|
|
|
|
|
n := ir.NewAssignStmt(pos, lhs[0], rhs[0])
|
|
|
|
|
n.Def = r.initDefn(n, names)
|
|
|
|
|
return n
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
n := ir.NewAssignListStmt(pos, ir.OAS2, lhs, rhs)
|
|
|
|
|
n.Def = r.initDefn(n, names)
|
|
|
|
|
return n
|
|
|
|
|
|
|
|
|
|
case stmtAssignOp:
|
|
|
|
|
op := r.op()
|
|
|
|
|
lhs := r.expr()
|
|
|
|
|
pos := r.pos()
|
|
|
|
|
rhs := r.expr()
|
|
|
|
|
return ir.NewAssignOpStmt(pos, op, lhs, rhs)
|
|
|
|
|
|
|
|
|
|
case stmtIncDec:
|
|
|
|
|
op := r.op()
|
|
|
|
|
lhs := r.expr()
|
|
|
|
|
pos := r.pos()
|
|
|
|
|
n := ir.NewAssignOpStmt(pos, op, lhs, ir.NewBasicLit(pos, one))
|
|
|
|
|
n.IncDec = true
|
|
|
|
|
return n
|
|
|
|
|
|
|
|
|
|
case stmtBlock:
|
|
|
|
|
out.Append(r.blockStmt()...)
|
|
|
|
|
return nil
|
|
|
|
|
|
|
|
|
|
case stmtBranch:
|
|
|
|
|
pos := r.pos()
|
|
|
|
|
op := r.op()
|
|
|
|
|
sym := r.optLabel()
|
|
|
|
|
return ir.NewBranchStmt(pos, op, sym)
|
|
|
|
|
|
|
|
|
|
case stmtCall:
|
|
|
|
|
pos := r.pos()
|
|
|
|
|
op := r.op()
|
|
|
|
|
call := r.expr()
|
|
|
|
|
return ir.NewGoDeferStmt(pos, op, call)
|
|
|
|
|
|
|
|
|
|
case stmtExpr:
|
|
|
|
|
return r.expr()
|
|
|
|
|
|
|
|
|
|
case stmtFor:
|
|
|
|
|
return r.forStmt(label)
|
|
|
|
|
|
|
|
|
|
case stmtIf:
|
|
|
|
|
return r.ifStmt()
|
|
|
|
|
|
|
|
|
|
case stmtLabel:
|
|
|
|
|
pos := r.pos()
|
|
|
|
|
sym := r.label()
|
|
|
|
|
return ir.NewLabelStmt(pos, sym)
|
|
|
|
|
|
|
|
|
|
case stmtReturn:
|
|
|
|
|
pos := r.pos()
|
|
|
|
|
results := r.exprList()
|
|
|
|
|
return ir.NewReturnStmt(pos, results)
|
|
|
|
|
|
|
|
|
|
case stmtSelect:
|
|
|
|
|
return r.selectStmt(label)
|
|
|
|
|
|
|
|
|
|
case stmtSend:
|
|
|
|
|
pos := r.pos()
|
|
|
|
|
ch := r.expr()
|
|
|
|
|
value := r.expr()
|
|
|
|
|
return ir.NewSendStmt(pos, ch, value)
|
|
|
|
|
|
|
|
|
|
case stmtSwitch:
|
|
|
|
|
return r.switchStmt(label)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) assignList() ([]*ir.Name, []ir.Node) {
|
2022-02-14 09:41:19 -08:00
|
|
|
lhs := make([]ir.Node, r.Len())
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
var names []*ir.Name
|
|
|
|
|
|
|
|
|
|
for i := range lhs {
|
2022-02-14 09:41:19 -08:00
|
|
|
if r.Bool() {
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
pos := r.pos()
|
|
|
|
|
_, sym := r.localIdent()
|
|
|
|
|
typ := r.typ()
|
|
|
|
|
|
|
|
|
|
name := ir.NewNameAt(pos, sym)
|
|
|
|
|
lhs[i] = name
|
|
|
|
|
names = append(names, name)
|
2021-09-01 11:53:36 -07:00
|
|
|
setType(name, typ)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
r.addLocal(name, ir.PAUTO)
|
|
|
|
|
continue
|
|
|
|
|
}
|
|
|
|
|
|
2021-07-09 19:47:45 -07:00
|
|
|
lhs[i] = r.expr()
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return names, lhs
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) blockStmt() []ir.Node {
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncBlockStmt)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
r.openScope()
|
|
|
|
|
stmts := r.stmts()
|
|
|
|
|
r.closeScope()
|
|
|
|
|
return stmts
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) forStmt(label *types.Sym) ir.Node {
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncForStmt)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
r.openScope()
|
|
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
if r.Bool() {
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
pos := r.pos()
|
[dev.typeparams] cmd/compile: simplify variable capturing in unified IR
While initially building out unified IR, I didn't have any indexing
scheme. Everything was written out in order. Consequently, if I wanted
to write A before B, I had to compute A before B.
One particular example of this is handling closure variables: the
reader needs the list of closure variables before it can start reading
the function body, so I had to write them out first, and so I had to
compute them first in a separate, dedicated pass.
However, that constraint went away a while ago. For example, it's now
possible to replace the two-pass closure variable capture with a
single pass. We just write out the function body earlier, but then
wait to write out its index.
I anticipate this approach will make it easier to implement
dictionaries: rather than needing a separate pass to correctly
recognize and handle all of the generics cases, we can just hook into
the existing logic.
Change-Id: Iab1e07f9202cd5d2b6864eef10116960456214df
Reviewed-on: https://go-review.googlesource.com/c/go/+/330851
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>
2021-06-25 01:54:50 -07:00
|
|
|
|
|
|
|
|
// TODO(mdempsky): After quirks mode is gone, swap these
|
|
|
|
|
// statements so we read LHS before X again.
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
x := r.expr()
|
[dev.typeparams] cmd/compile: simplify variable capturing in unified IR
While initially building out unified IR, I didn't have any indexing
scheme. Everything was written out in order. Consequently, if I wanted
to write A before B, I had to compute A before B.
One particular example of this is handling closure variables: the
reader needs the list of closure variables before it can start reading
the function body, so I had to write them out first, and so I had to
compute them first in a separate, dedicated pass.
However, that constraint went away a while ago. For example, it's now
possible to replace the two-pass closure variable capture with a
single pass. We just write out the function body earlier, but then
wait to write out its index.
I anticipate this approach will make it easier to implement
dictionaries: rather than needing a separate pass to correctly
recognize and handle all of the generics cases, we can just hook into
the existing logic.
Change-Id: Iab1e07f9202cd5d2b6864eef10116960456214df
Reviewed-on: https://go-review.googlesource.com/c/go/+/330851
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>
2021-06-25 01:54:50 -07:00
|
|
|
names, lhs := r.assignList()
|
|
|
|
|
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
body := r.blockStmt()
|
|
|
|
|
r.closeAnotherScope()
|
|
|
|
|
|
|
|
|
|
rang := ir.NewRangeStmt(pos, nil, nil, x, body)
|
|
|
|
|
if len(lhs) >= 1 {
|
|
|
|
|
rang.Key = lhs[0]
|
|
|
|
|
if len(lhs) >= 2 {
|
|
|
|
|
rang.Value = lhs[1]
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
rang.Def = r.initDefn(rang, names)
|
|
|
|
|
rang.Label = label
|
|
|
|
|
return rang
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pos := r.pos()
|
|
|
|
|
init := r.stmt()
|
|
|
|
|
cond := r.expr()
|
|
|
|
|
post := r.stmt()
|
|
|
|
|
body := r.blockStmt()
|
|
|
|
|
r.closeAnotherScope()
|
|
|
|
|
|
|
|
|
|
stmt := ir.NewForStmt(pos, init, cond, post, body)
|
|
|
|
|
stmt.Label = label
|
|
|
|
|
return stmt
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) ifStmt() ir.Node {
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncIfStmt)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
r.openScope()
|
|
|
|
|
pos := r.pos()
|
|
|
|
|
init := r.stmts()
|
|
|
|
|
cond := r.expr()
|
|
|
|
|
then := r.blockStmt()
|
|
|
|
|
els := r.stmts()
|
|
|
|
|
n := ir.NewIfStmt(pos, cond, then, els)
|
|
|
|
|
n.SetInit(init)
|
|
|
|
|
r.closeAnotherScope()
|
|
|
|
|
return n
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) selectStmt(label *types.Sym) ir.Node {
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncSelectStmt)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
pos := r.pos()
|
2022-02-14 09:41:19 -08:00
|
|
|
clauses := make([]*ir.CommClause, r.Len())
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
for i := range clauses {
|
|
|
|
|
if i > 0 {
|
|
|
|
|
r.closeScope()
|
|
|
|
|
}
|
|
|
|
|
r.openScope()
|
|
|
|
|
|
|
|
|
|
pos := r.pos()
|
|
|
|
|
comm := r.stmt()
|
|
|
|
|
body := r.stmts()
|
|
|
|
|
|
|
|
|
|
clauses[i] = ir.NewCommStmt(pos, comm, body)
|
|
|
|
|
}
|
|
|
|
|
if len(clauses) > 0 {
|
|
|
|
|
r.closeScope()
|
|
|
|
|
}
|
|
|
|
|
n := ir.NewSelectStmt(pos, clauses)
|
|
|
|
|
n.Label = label
|
|
|
|
|
return n
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) switchStmt(label *types.Sym) ir.Node {
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncSwitchStmt)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
r.openScope()
|
|
|
|
|
pos := r.pos()
|
|
|
|
|
init := r.stmt()
|
2021-07-09 17:47:15 -07:00
|
|
|
|
|
|
|
|
var tag ir.Node
|
2022-03-06 23:47:27 -08:00
|
|
|
var ident *ir.Ident
|
|
|
|
|
var iface *types.Type
|
2022-02-14 09:41:19 -08:00
|
|
|
if r.Bool() {
|
2021-07-09 17:47:15 -07:00
|
|
|
pos := r.pos()
|
2022-02-14 09:41:19 -08:00
|
|
|
if r.Bool() {
|
2021-07-09 17:47:15 -07:00
|
|
|
pos := r.pos()
|
2022-02-14 09:41:19 -08:00
|
|
|
sym := typecheck.Lookup(r.String())
|
2021-07-09 17:47:15 -07:00
|
|
|
ident = ir.NewIdent(pos, sym)
|
|
|
|
|
}
|
|
|
|
|
x := r.expr()
|
2022-03-06 23:47:27 -08:00
|
|
|
iface = x.Type()
|
2021-07-09 17:47:15 -07:00
|
|
|
tag = ir.NewTypeSwitchGuard(pos, ident, x)
|
|
|
|
|
} else {
|
|
|
|
|
tag = r.expr()
|
|
|
|
|
}
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
clauses := make([]*ir.CaseClause, r.Len())
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
for i := range clauses {
|
|
|
|
|
if i > 0 {
|
|
|
|
|
r.closeScope()
|
|
|
|
|
}
|
|
|
|
|
r.openScope()
|
|
|
|
|
|
|
|
|
|
pos := r.pos()
|
2022-03-06 23:47:27 -08:00
|
|
|
var cases []ir.Node
|
|
|
|
|
if iface != nil {
|
|
|
|
|
cases = make([]ir.Node, r.Len())
|
|
|
|
|
if len(cases) == 0 {
|
|
|
|
|
cases = nil // TODO(mdempsky): Unclear if this matters.
|
|
|
|
|
}
|
|
|
|
|
for i := range cases {
|
2022-03-07 03:35:14 -08:00
|
|
|
cases[i] = r.exprType(true)
|
2022-03-06 23:47:27 -08:00
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
cases = r.exprList()
|
|
|
|
|
}
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
clause := ir.NewCaseStmt(pos, cases, nil)
|
2022-03-06 23:47:27 -08:00
|
|
|
|
|
|
|
|
if ident != nil {
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
pos := r.pos()
|
|
|
|
|
typ := r.typ()
|
|
|
|
|
|
2022-03-06 23:47:27 -08:00
|
|
|
name := ir.NewNameAt(pos, ident.Sym())
|
2021-09-01 11:53:36 -07:00
|
|
|
setType(name, typ)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
r.addLocal(name, ir.PAUTO)
|
|
|
|
|
clause.Var = name
|
2022-03-06 23:47:27 -08:00
|
|
|
name.Defn = tag
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
clause.Body = r.stmts()
|
|
|
|
|
clauses[i] = clause
|
|
|
|
|
}
|
|
|
|
|
if len(clauses) > 0 {
|
|
|
|
|
r.closeScope()
|
|
|
|
|
}
|
|
|
|
|
r.closeScope()
|
|
|
|
|
|
|
|
|
|
n := ir.NewSwitchStmt(pos, tag, clauses)
|
|
|
|
|
n.Label = label
|
|
|
|
|
if init != nil {
|
|
|
|
|
n.SetInit([]ir.Node{init})
|
|
|
|
|
}
|
|
|
|
|
return n
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) label() *types.Sym {
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncLabel)
|
|
|
|
|
name := r.String()
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
if r.inlCall != nil {
|
|
|
|
|
name = fmt.Sprintf("~%s·%d", name, inlgen)
|
|
|
|
|
}
|
|
|
|
|
return typecheck.Lookup(name)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) optLabel() *types.Sym {
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncOptLabel)
|
|
|
|
|
if r.Bool() {
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
return r.label()
|
|
|
|
|
}
|
|
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// initDefn marks the given names as declared by defn and populates
|
|
|
|
|
// its Init field with ODCL nodes. It then reports whether any names
|
|
|
|
|
// were so declared, which can be used to initialize defn.Def.
|
|
|
|
|
func (r *reader) initDefn(defn ir.InitNode, names []*ir.Name) bool {
|
|
|
|
|
if len(names) == 0 {
|
|
|
|
|
return false
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
init := make([]ir.Node, len(names))
|
|
|
|
|
for i, name := range names {
|
|
|
|
|
name.Defn = defn
|
|
|
|
|
init[i] = ir.NewDecl(name.Pos(), ir.ODCL, name)
|
|
|
|
|
}
|
|
|
|
|
defn.SetInit(init)
|
|
|
|
|
return true
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// @@@ Expressions
|
|
|
|
|
|
2021-07-09 17:47:15 -07:00
|
|
|
// expr reads and returns a typechecked expression.
|
2021-07-09 19:47:45 -07:00
|
|
|
func (r *reader) expr() (res ir.Node) {
|
|
|
|
|
defer func() {
|
|
|
|
|
if res != nil && res.Typecheck() == 0 {
|
|
|
|
|
base.FatalfAt(res.Pos(), "%v missed typecheck", res)
|
|
|
|
|
}
|
|
|
|
|
}()
|
2021-07-09 17:47:15 -07:00
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
switch tag := codeExpr(r.Code(pkgbits.SyncExpr)); tag {
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
default:
|
|
|
|
|
panic("unhandled expression")
|
|
|
|
|
|
|
|
|
|
case exprNone:
|
|
|
|
|
return nil
|
|
|
|
|
|
|
|
|
|
case exprBlank:
|
2021-07-09 19:47:45 -07:00
|
|
|
// blank only allowed in LHS of assignments
|
|
|
|
|
// TODO(mdempsky): Handle directly in assignList instead?
|
|
|
|
|
return typecheck.AssignExpr(ir.BlankNode)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
case exprLocal:
|
2021-07-09 19:47:45 -07:00
|
|
|
return typecheck.Expr(r.useLocal())
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
case exprName:
|
2021-07-09 19:47:45 -07:00
|
|
|
// Callee instead of Expr allows builtins
|
|
|
|
|
// TODO(mdempsky): Handle builtins directly in exprCall, like method calls?
|
|
|
|
|
return typecheck.Callee(r.obj())
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
case exprType:
|
2022-03-07 03:35:14 -08:00
|
|
|
return r.exprType(false)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
case exprConst:
|
|
|
|
|
pos := r.pos()
|
2021-09-07 13:23:08 -07:00
|
|
|
typ := r.typ()
|
2022-02-14 09:41:19 -08:00
|
|
|
val := FixValue(typ, r.Value())
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
op := r.op()
|
2022-02-14 09:41:19 -08:00
|
|
|
orig := r.String()
|
2021-07-09 19:47:45 -07:00
|
|
|
return typecheck.Expr(OrigConst(pos, typ, val, op, orig))
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
case exprCompLit:
|
|
|
|
|
return r.compLit()
|
|
|
|
|
|
|
|
|
|
case exprFuncLit:
|
|
|
|
|
return r.funcLit()
|
|
|
|
|
|
|
|
|
|
case exprSelector:
|
|
|
|
|
x := r.expr()
|
|
|
|
|
pos := r.pos()
|
|
|
|
|
_, sym := r.selector()
|
2022-03-06 23:47:27 -08:00
|
|
|
|
|
|
|
|
// Method expression with derived receiver type.
|
|
|
|
|
if x.Op() == ir.ODYNAMICTYPE {
|
|
|
|
|
// TODO(mdempsky): Handle with runtime dictionary lookup.
|
|
|
|
|
n := ir.TypeNode(x.Type())
|
|
|
|
|
n.SetTypecheck(1)
|
|
|
|
|
x = n
|
|
|
|
|
}
|
|
|
|
|
|
2021-08-30 01:01:20 -07:00
|
|
|
n := typecheck.Expr(ir.NewSelectorExpr(pos, ir.OXDOT, x, sym)).(*ir.SelectorExpr)
|
|
|
|
|
if n.Op() == ir.OMETHVALUE {
|
|
|
|
|
wrapper := methodValueWrapper{
|
|
|
|
|
rcvr: n.X.Type(),
|
|
|
|
|
method: n.Selection,
|
|
|
|
|
}
|
|
|
|
|
if r.importedDef() {
|
|
|
|
|
haveMethodValueWrappers = append(haveMethodValueWrappers, wrapper)
|
|
|
|
|
} else {
|
|
|
|
|
needMethodValueWrappers = append(needMethodValueWrappers, wrapper)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return n
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
case exprIndex:
|
|
|
|
|
x := r.expr()
|
|
|
|
|
pos := r.pos()
|
|
|
|
|
index := r.expr()
|
2021-07-09 19:47:45 -07:00
|
|
|
return typecheck.Expr(ir.NewIndexExpr(pos, x, index))
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
case exprSlice:
|
|
|
|
|
x := r.expr()
|
|
|
|
|
pos := r.pos()
|
|
|
|
|
var index [3]ir.Node
|
|
|
|
|
for i := range index {
|
|
|
|
|
index[i] = r.expr()
|
|
|
|
|
}
|
|
|
|
|
op := ir.OSLICE
|
|
|
|
|
if index[2] != nil {
|
|
|
|
|
op = ir.OSLICE3
|
|
|
|
|
}
|
2021-07-09 19:47:45 -07:00
|
|
|
return typecheck.Expr(ir.NewSliceExpr(pos, op, x, index[0], index[1], index[2]))
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
case exprAssert:
|
|
|
|
|
x := r.expr()
|
|
|
|
|
pos := r.pos()
|
2022-03-07 03:35:14 -08:00
|
|
|
typ := r.exprType(false)
|
2022-03-06 23:47:27 -08:00
|
|
|
|
|
|
|
|
if typ, ok := typ.(*ir.DynamicType); ok && typ.Op() == ir.ODYNAMICTYPE {
|
|
|
|
|
return typed(typ.Type(), ir.NewDynamicTypeAssertExpr(pos, ir.ODYNAMICDOTTYPE, x, typ.X))
|
|
|
|
|
}
|
|
|
|
|
return typecheck.Expr(ir.NewTypeAssertExpr(pos, x, typ.(ir.Ntype)))
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
case exprUnaryOp:
|
|
|
|
|
op := r.op()
|
|
|
|
|
pos := r.pos()
|
|
|
|
|
x := r.expr()
|
|
|
|
|
|
|
|
|
|
switch op {
|
|
|
|
|
case ir.OADDR:
|
2021-07-09 19:47:45 -07:00
|
|
|
return typecheck.Expr(typecheck.NodAddrAt(pos, x))
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
case ir.ODEREF:
|
2021-07-09 19:47:45 -07:00
|
|
|
return typecheck.Expr(ir.NewStarExpr(pos, x))
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
2021-07-09 19:47:45 -07:00
|
|
|
return typecheck.Expr(ir.NewUnaryExpr(pos, op, x))
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
case exprBinaryOp:
|
|
|
|
|
op := r.op()
|
|
|
|
|
x := r.expr()
|
|
|
|
|
pos := r.pos()
|
|
|
|
|
y := r.expr()
|
|
|
|
|
|
|
|
|
|
switch op {
|
|
|
|
|
case ir.OANDAND, ir.OOROR:
|
2021-07-09 19:47:45 -07:00
|
|
|
return typecheck.Expr(ir.NewLogicalExpr(pos, op, x, y))
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
2021-07-09 19:47:45 -07:00
|
|
|
return typecheck.Expr(ir.NewBinaryExpr(pos, op, x, y))
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
case exprCall:
|
2021-07-09 19:47:45 -07:00
|
|
|
fun := r.expr()
|
2022-02-14 09:41:19 -08:00
|
|
|
if r.Bool() { // method call
|
2021-07-09 19:47:45 -07:00
|
|
|
pos := r.pos()
|
|
|
|
|
_, sym := r.selector()
|
|
|
|
|
fun = typecheck.Callee(ir.NewSelectorExpr(pos, ir.OXDOT, fun, sym))
|
|
|
|
|
}
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
pos := r.pos()
|
|
|
|
|
args := r.exprs()
|
2022-02-14 09:41:19 -08:00
|
|
|
dots := r.Bool()
|
2021-07-03 11:55:31 -07:00
|
|
|
return typecheck.Call(pos, fun, args, dots)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
2021-07-09 17:47:15 -07:00
|
|
|
case exprConvert:
|
|
|
|
|
typ := r.typ()
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
pos := r.pos()
|
|
|
|
|
x := r.expr()
|
2022-03-15 22:25:36 -07:00
|
|
|
|
|
|
|
|
// TODO(mdempsky): Stop constructing expressions of untyped type.
|
|
|
|
|
x = typecheck.DefaultLit(x, typ)
|
|
|
|
|
|
|
|
|
|
if op, why := typecheck.Convertop(x.Op() == ir.OLITERAL, x.Type(), typ); op == ir.OXXX {
|
|
|
|
|
// types2 ensured that x is convertable to typ under standard Go
|
|
|
|
|
// semantics, but cmd/compile also disallows some conversions
|
|
|
|
|
// involving //go:notinheap.
|
|
|
|
|
//
|
|
|
|
|
// TODO(mdempsky): This can be removed after #46731 is implemented.
|
|
|
|
|
base.ErrorfAt(pos, "cannot convert %L to type %v%v", x, typ, why)
|
|
|
|
|
base.ErrorExit() // harsh, but prevents constructing invalid IR
|
|
|
|
|
}
|
|
|
|
|
|
2021-07-09 19:47:45 -07:00
|
|
|
return typecheck.Expr(ir.NewConvExpr(pos, ir.OCONV, typ, x))
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) compLit() ir.Node {
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncCompLit)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
pos := r.pos()
|
2021-07-09 19:47:45 -07:00
|
|
|
typ0 := r.typ()
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
2021-07-09 19:47:45 -07:00
|
|
|
typ := typ0
|
|
|
|
|
if typ.IsPtr() {
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
typ = typ.Elem()
|
|
|
|
|
}
|
|
|
|
|
if typ.Kind() == types.TFORW {
|
|
|
|
|
base.FatalfAt(pos, "unresolved composite literal type: %v", typ)
|
|
|
|
|
}
|
|
|
|
|
isStruct := typ.Kind() == types.TSTRUCT
|
|
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
elems := make([]ir.Node, r.Len())
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
for i := range elems {
|
|
|
|
|
elemp := &elems[i]
|
|
|
|
|
|
|
|
|
|
if isStruct {
|
2022-02-14 09:41:19 -08:00
|
|
|
sk := ir.NewStructKeyExpr(r.pos(), typ.Field(r.Len()), nil)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
*elemp, elemp = sk, &sk.Value
|
2022-02-14 09:41:19 -08:00
|
|
|
} else if r.Bool() {
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
kv := ir.NewKeyExpr(r.pos(), r.expr(), nil)
|
|
|
|
|
*elemp, elemp = kv, &kv.Value
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
*elemp = wrapName(r.pos(), r.expr())
|
|
|
|
|
}
|
|
|
|
|
|
2021-07-09 19:47:45 -07:00
|
|
|
lit := typecheck.Expr(ir.NewCompLitExpr(pos, ir.OCOMPLIT, ir.TypeNode(typ), elems))
|
|
|
|
|
if typ0.IsPtr() {
|
|
|
|
|
lit = typecheck.Expr(typecheck.NodAddrAt(pos, lit))
|
|
|
|
|
lit.SetType(typ0)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
return lit
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func wrapName(pos src.XPos, x ir.Node) ir.Node {
|
|
|
|
|
// These nodes do not carry line numbers.
|
|
|
|
|
// Introduce a wrapper node to give them the correct line.
|
|
|
|
|
switch ir.Orig(x).Op() {
|
|
|
|
|
case ir.OTYPE, ir.OLITERAL:
|
|
|
|
|
if x.Sym() == nil {
|
|
|
|
|
break
|
|
|
|
|
}
|
|
|
|
|
fallthrough
|
2022-02-28 15:31:35 -08:00
|
|
|
case ir.ONAME, ir.ONONAME, ir.ONIL:
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
p := ir.NewParenExpr(pos, x)
|
|
|
|
|
p.SetImplicit(true)
|
|
|
|
|
return p
|
|
|
|
|
}
|
|
|
|
|
return x
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) funcLit() ir.Node {
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncFuncLit)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
pos := r.pos()
|
|
|
|
|
xtype2 := r.signature(types.LocalPkg, nil)
|
|
|
|
|
|
|
|
|
|
opos := pos
|
|
|
|
|
|
|
|
|
|
fn := ir.NewClosureFunc(opos, r.curfn != nil)
|
2021-07-01 15:23:41 -07:00
|
|
|
clo := fn.OClosure
|
|
|
|
|
ir.NameClosure(clo, r.curfn)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
2021-09-01 11:53:36 -07:00
|
|
|
setType(fn.Nname, xtype2)
|
2021-07-01 15:23:41 -07:00
|
|
|
typecheck.Func(fn)
|
2021-09-01 11:53:36 -07:00
|
|
|
setType(clo, fn.Type())
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
fn.ClosureVars = make([]*ir.Name, 0, r.Len())
|
2021-06-22 18:10:59 -07:00
|
|
|
for len(fn.ClosureVars) < cap(fn.ClosureVars) {
|
2021-07-02 16:29:42 -07:00
|
|
|
ir.NewClosureVar(r.pos(), fn, r.useLocal())
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
|
2021-06-28 22:41:50 -07:00
|
|
|
r.addBody(fn)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
2021-07-01 15:23:41 -07:00
|
|
|
// TODO(mdempsky): Remove hard-coding of typecheck.Target.
|
|
|
|
|
return ir.UseClosure(clo, typecheck.Target)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) exprList() []ir.Node {
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncExprList)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
return r.exprs()
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) exprs() []ir.Node {
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncExprs)
|
|
|
|
|
nodes := make([]ir.Node, r.Len())
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
if len(nodes) == 0 {
|
|
|
|
|
return nil // TODO(mdempsky): Unclear if this matters.
|
|
|
|
|
}
|
|
|
|
|
for i := range nodes {
|
|
|
|
|
nodes[i] = r.expr()
|
|
|
|
|
}
|
|
|
|
|
return nodes
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-07 03:35:14 -08:00
|
|
|
func (r *reader) exprType(nilOK bool) ir.Node {
|
2022-03-06 23:47:27 -08:00
|
|
|
r.Sync(pkgbits.SyncExprType)
|
|
|
|
|
|
|
|
|
|
if nilOK && r.Bool() {
|
|
|
|
|
return typecheck.Expr(types.BuiltinPkg.Lookup("nil").Def.(*ir.NilExpr))
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pos := r.pos()
|
|
|
|
|
|
2022-03-07 03:35:14 -08:00
|
|
|
var typ *types.Type
|
|
|
|
|
var lsym *obj.LSym
|
2022-03-06 23:47:27 -08:00
|
|
|
|
2022-03-07 03:35:14 -08:00
|
|
|
if r.Bool() {
|
|
|
|
|
itab := r.dict.itabs[r.Len()]
|
|
|
|
|
typ, lsym = itab.typ, itab.lsym
|
|
|
|
|
} else {
|
|
|
|
|
info := r.typInfo()
|
|
|
|
|
typ = r.p.typIdx(info, r.dict, true)
|
2022-03-06 23:47:27 -08:00
|
|
|
|
2022-03-07 03:35:14 -08:00
|
|
|
if !info.derived {
|
|
|
|
|
// TODO(mdempsky): ir.TypeNode should probably return a typecheck'd node.
|
|
|
|
|
n := ir.TypeNode(typ)
|
|
|
|
|
n.SetTypecheck(1)
|
|
|
|
|
return n
|
2022-03-06 23:47:27 -08:00
|
|
|
}
|
|
|
|
|
|
2022-03-07 03:35:14 -08:00
|
|
|
lsym = reflectdata.TypeLinksym(typ)
|
2022-03-06 23:47:27 -08:00
|
|
|
}
|
|
|
|
|
|
2022-03-07 03:35:14 -08:00
|
|
|
ptr := typecheck.Expr(typecheck.NodAddr(ir.NewLinksymExpr(pos, lsym, types.Types[types.TUINT8])))
|
|
|
|
|
return typed(typ, ir.NewDynamicType(pos, ptr))
|
2022-03-06 23:47:27 -08:00
|
|
|
}
|
|
|
|
|
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
func (r *reader) op() ir.Op {
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncOp)
|
|
|
|
|
return ir.Op(r.Len())
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// @@@ Package initialization
|
|
|
|
|
|
|
|
|
|
func (r *reader) pkgInit(self *types.Pkg, target *ir.Package) {
|
2022-02-14 09:41:19 -08:00
|
|
|
cgoPragmas := make([][]string, r.Len())
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
for i := range cgoPragmas {
|
2022-02-14 09:41:19 -08:00
|
|
|
cgoPragmas[i] = r.Strings()
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
target.CgoPragmas = cgoPragmas
|
|
|
|
|
|
|
|
|
|
r.pkgDecls(target)
|
|
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncEOF)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) pkgDecls(target *ir.Package) {
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncDecls)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
for {
|
2022-02-14 09:41:19 -08:00
|
|
|
switch code := codeDecl(r.Code(pkgbits.SyncDecl)); code {
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
default:
|
|
|
|
|
panic(fmt.Sprintf("unhandled decl: %v", code))
|
|
|
|
|
|
|
|
|
|
case declEnd:
|
|
|
|
|
return
|
|
|
|
|
|
|
|
|
|
case declFunc:
|
|
|
|
|
names := r.pkgObjs(target)
|
|
|
|
|
assert(len(names) == 1)
|
|
|
|
|
target.Decls = append(target.Decls, names[0].Func)
|
|
|
|
|
|
|
|
|
|
case declMethod:
|
|
|
|
|
typ := r.typ()
|
|
|
|
|
_, sym := r.selector()
|
|
|
|
|
|
|
|
|
|
method := typecheck.Lookdot1(nil, sym, typ, typ.Methods(), 0)
|
|
|
|
|
target.Decls = append(target.Decls, method.Nname.(*ir.Name).Func)
|
|
|
|
|
|
|
|
|
|
case declVar:
|
|
|
|
|
pos := r.pos()
|
|
|
|
|
names := r.pkgObjs(target)
|
|
|
|
|
values := r.exprList()
|
|
|
|
|
|
|
|
|
|
if len(names) > 1 && len(values) == 1 {
|
|
|
|
|
as := ir.NewAssignListStmt(pos, ir.OAS2, nil, values)
|
|
|
|
|
for _, name := range names {
|
|
|
|
|
as.Lhs.Append(name)
|
|
|
|
|
name.Defn = as
|
|
|
|
|
}
|
|
|
|
|
target.Decls = append(target.Decls, as)
|
|
|
|
|
} else {
|
|
|
|
|
for i, name := range names {
|
|
|
|
|
as := ir.NewAssignStmt(pos, name, nil)
|
|
|
|
|
if i < len(values) {
|
|
|
|
|
as.Y = values[i]
|
|
|
|
|
}
|
|
|
|
|
name.Defn = as
|
|
|
|
|
target.Decls = append(target.Decls, as)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
if n := r.Len(); n > 0 {
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
assert(len(names) == 1)
|
|
|
|
|
embeds := make([]ir.Embed, n)
|
|
|
|
|
for i := range embeds {
|
2022-02-14 09:41:19 -08:00
|
|
|
embeds[i] = ir.Embed{Pos: r.pos(), Patterns: r.Strings()}
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
names[0].Embed = &embeds
|
|
|
|
|
target.Embeds = append(target.Embeds, names[0])
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
case declOther:
|
|
|
|
|
r.pkgObjs(target)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) pkgObjs(target *ir.Package) []*ir.Name {
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncDeclNames)
|
|
|
|
|
nodes := make([]*ir.Name, r.Len())
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
for i := range nodes {
|
2022-02-14 09:41:19 -08:00
|
|
|
r.Sync(pkgbits.SyncDeclName)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
name := r.obj().(*ir.Name)
|
|
|
|
|
nodes[i] = name
|
|
|
|
|
|
|
|
|
|
sym := name.Sym()
|
|
|
|
|
if sym.IsBlank() {
|
|
|
|
|
continue
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
switch name.Class {
|
|
|
|
|
default:
|
|
|
|
|
base.FatalfAt(name.Pos(), "unexpected class: %v", name.Class)
|
|
|
|
|
|
|
|
|
|
case ir.PEXTERN:
|
|
|
|
|
target.Externs = append(target.Externs, name)
|
|
|
|
|
|
|
|
|
|
case ir.PFUNC:
|
|
|
|
|
assert(name.Type().Recv() == nil)
|
|
|
|
|
|
|
|
|
|
// TODO(mdempsky): Cleaner way to recognize init?
|
|
|
|
|
if strings.HasPrefix(sym.Name, "init.") {
|
|
|
|
|
target.Inits = append(target.Inits, name.Func)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if types.IsExported(sym.Name) {
|
|
|
|
|
assert(!sym.OnExportList())
|
|
|
|
|
target.Exports = append(target.Exports, name)
|
|
|
|
|
sym.SetOnExportList(true)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if base.Flag.AsmHdr != "" {
|
|
|
|
|
assert(!sym.Asm())
|
|
|
|
|
target.Asms = append(target.Asms, name)
|
|
|
|
|
sym.SetAsm(true)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return nodes
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// @@@ Inlining
|
|
|
|
|
|
|
|
|
|
var inlgen = 0
|
|
|
|
|
|
|
|
|
|
func InlineCall(call *ir.CallExpr, fn *ir.Func, inlIndex int) *ir.InlinedCallExpr {
|
|
|
|
|
// TODO(mdempsky): Turn callerfn into an explicit parameter.
|
|
|
|
|
callerfn := ir.CurFunc
|
|
|
|
|
|
|
|
|
|
pri, ok := bodyReader[fn]
|
|
|
|
|
if !ok {
|
|
|
|
|
base.FatalfAt(call.Pos(), "missing function body for call to %v", fn)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if fn.Inl.Body == nil {
|
|
|
|
|
expandInline(fn, pri)
|
|
|
|
|
}
|
|
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
r := pri.asReader(pkgbits.RelocBody, pkgbits.SyncFuncBody)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
// TODO(mdempsky): This still feels clumsy. Can we do better?
|
|
|
|
|
tmpfn := ir.NewFunc(fn.Pos())
|
|
|
|
|
tmpfn.Nname = ir.NewNameAt(fn.Nname.Pos(), callerfn.Sym())
|
|
|
|
|
tmpfn.Closgen = callerfn.Closgen
|
|
|
|
|
defer func() { callerfn.Closgen = tmpfn.Closgen }()
|
|
|
|
|
|
2021-09-01 11:53:36 -07:00
|
|
|
setType(tmpfn.Nname, fn.Type())
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
r.curfn = tmpfn
|
|
|
|
|
|
2021-07-01 15:23:41 -07:00
|
|
|
r.inlCaller = callerfn
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
r.inlCall = call
|
|
|
|
|
r.inlFunc = fn
|
|
|
|
|
r.inlTreeIndex = inlIndex
|
|
|
|
|
r.inlPosBases = make(map[*src.PosBase]*src.PosBase)
|
|
|
|
|
|
[dev.typeparams] cmd/compile: simplify variable capturing in unified IR
While initially building out unified IR, I didn't have any indexing
scheme. Everything was written out in order. Consequently, if I wanted
to write A before B, I had to compute A before B.
One particular example of this is handling closure variables: the
reader needs the list of closure variables before it can start reading
the function body, so I had to write them out first, and so I had to
compute them first in a separate, dedicated pass.
However, that constraint went away a while ago. For example, it's now
possible to replace the two-pass closure variable capture with a
single pass. We just write out the function body earlier, but then
wait to write out its index.
I anticipate this approach will make it easier to implement
dictionaries: rather than needing a separate pass to correctly
recognize and handle all of the generics cases, we can just hook into
the existing logic.
Change-Id: Iab1e07f9202cd5d2b6864eef10116960456214df
Reviewed-on: https://go-review.googlesource.com/c/go/+/330851
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>
2021-06-25 01:54:50 -07:00
|
|
|
r.closureVars = make([]*ir.Name, len(r.inlFunc.ClosureVars))
|
|
|
|
|
for i, cv := range r.inlFunc.ClosureVars {
|
|
|
|
|
r.closureVars[i] = cv.Outer
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
r.funcargs(fn)
|
|
|
|
|
|
2022-02-14 09:41:19 -08:00
|
|
|
assert(r.Bool()) // have body
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
r.delayResults = fn.Inl.CanDelayResults
|
|
|
|
|
|
|
|
|
|
r.retlabel = typecheck.AutoLabel(".i")
|
|
|
|
|
inlgen++
|
|
|
|
|
|
|
|
|
|
init := ir.TakeInit(call)
|
|
|
|
|
|
|
|
|
|
// For normal function calls, the function callee expression
|
2021-07-03 04:53:25 -07:00
|
|
|
// may contain side effects. Make sure to preserve these,
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
// if necessary (#42703).
|
|
|
|
|
if call.Op() == ir.OCALLFUNC {
|
2021-07-03 04:53:25 -07:00
|
|
|
inline.CalleeEffects(&init, call.X)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
var args ir.Nodes
|
|
|
|
|
if call.Op() == ir.OCALLMETH {
|
2021-06-25 22:24:29 +07:00
|
|
|
base.FatalfAt(call.Pos(), "OCALLMETH missed by typecheck")
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
}
|
|
|
|
|
args.Append(call.Args...)
|
|
|
|
|
|
|
|
|
|
// Create assignment to declare and initialize inlvars.
|
|
|
|
|
as2 := ir.NewAssignListStmt(call.Pos(), ir.OAS2, r.inlvars, args)
|
|
|
|
|
as2.Def = true
|
|
|
|
|
var as2init ir.Nodes
|
|
|
|
|
for _, name := range r.inlvars {
|
|
|
|
|
if ir.IsBlank(name) {
|
|
|
|
|
continue
|
|
|
|
|
}
|
|
|
|
|
// TODO(mdempsky): Use inlined position of name.Pos() instead?
|
|
|
|
|
name := name.(*ir.Name)
|
|
|
|
|
as2init.Append(ir.NewDecl(call.Pos(), ir.ODCL, name))
|
|
|
|
|
name.Defn = as2
|
|
|
|
|
}
|
|
|
|
|
as2.SetInit(as2init)
|
|
|
|
|
init.Append(typecheck.Stmt(as2))
|
|
|
|
|
|
|
|
|
|
if !r.delayResults {
|
|
|
|
|
// If not delaying retvars, declare and zero initialize the
|
|
|
|
|
// result variables now.
|
|
|
|
|
for _, name := range r.retvars {
|
|
|
|
|
// TODO(mdempsky): Use inlined position of name.Pos() instead?
|
|
|
|
|
name := name.(*ir.Name)
|
|
|
|
|
init.Append(ir.NewDecl(call.Pos(), ir.ODCL, name))
|
|
|
|
|
ras := ir.NewAssignStmt(call.Pos(), name, nil)
|
|
|
|
|
init.Append(typecheck.Stmt(ras))
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Add an inline mark just before the inlined body.
|
|
|
|
|
// This mark is inline in the code so that it's a reasonable spot
|
|
|
|
|
// to put a breakpoint. Not sure if that's really necessary or not
|
|
|
|
|
// (in which case it could go at the end of the function instead).
|
|
|
|
|
// Note issue 28603.
|
|
|
|
|
init.Append(ir.NewInlineMarkStmt(call.Pos().WithIsStmt(), int64(r.inlTreeIndex)))
|
|
|
|
|
|
|
|
|
|
nparams := len(r.curfn.Dcl)
|
|
|
|
|
|
2021-07-01 15:23:41 -07:00
|
|
|
ir.WithFunc(r.curfn, func() {
|
|
|
|
|
r.curfn.Body = r.stmts()
|
|
|
|
|
r.curfn.Endlineno = r.pos()
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
2022-03-06 20:11:21 -08:00
|
|
|
// TODO(mdempsky): This shouldn't be necessary. Inlining might
|
|
|
|
|
// read in new function/method declarations, which could
|
|
|
|
|
// potentially be recursively inlined themselves; but we shouldn't
|
|
|
|
|
// need to read in the non-inlined bodies for the declarations
|
|
|
|
|
// themselves. But currently it's an easy fix to #50552.
|
|
|
|
|
readBodies(typecheck.Target)
|
|
|
|
|
|
2021-07-01 15:23:41 -07:00
|
|
|
deadcode.Func(r.curfn)
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
2021-07-01 15:23:41 -07:00
|
|
|
// Replace any "return" statements within the function body.
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
var edit func(ir.Node) ir.Node
|
|
|
|
|
edit = func(n ir.Node) ir.Node {
|
|
|
|
|
if ret, ok := n.(*ir.ReturnStmt); ok {
|
|
|
|
|
n = typecheck.Stmt(r.inlReturn(ret))
|
|
|
|
|
}
|
|
|
|
|
ir.EditChildren(n, edit)
|
|
|
|
|
return n
|
|
|
|
|
}
|
|
|
|
|
edit(r.curfn)
|
2021-07-01 15:23:41 -07:00
|
|
|
})
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
body := ir.Nodes(r.curfn.Body)
|
|
|
|
|
|
|
|
|
|
// Quirkish: We need to eagerly prune variables added during
|
|
|
|
|
// inlining, but removed by deadcode.FuncBody above. Unused
|
|
|
|
|
// variables will get removed during stack frame layout anyway, but
|
|
|
|
|
// len(fn.Dcl) ends up influencing things like autotmp naming.
|
|
|
|
|
|
|
|
|
|
used := usedLocals(body)
|
|
|
|
|
|
|
|
|
|
for i, name := range r.curfn.Dcl {
|
|
|
|
|
if i < nparams || used.Has(name) {
|
|
|
|
|
name.Curfn = callerfn
|
|
|
|
|
callerfn.Dcl = append(callerfn.Dcl, name)
|
|
|
|
|
|
|
|
|
|
// Quirkish. TODO(mdempsky): Document why.
|
|
|
|
|
if name.AutoTemp() {
|
|
|
|
|
name.SetEsc(ir.EscUnknown)
|
|
|
|
|
|
|
|
|
|
if base.Flag.GenDwarfInl != 0 {
|
|
|
|
|
name.SetInlLocal(true)
|
|
|
|
|
} else {
|
|
|
|
|
name.SetPos(r.inlCall.Pos())
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
body.Append(ir.NewLabelStmt(call.Pos(), r.retlabel))
|
|
|
|
|
|
|
|
|
|
res := ir.NewInlinedCallExpr(call.Pos(), body, append([]ir.Node(nil), r.retvars...))
|
|
|
|
|
res.SetInit(init)
|
|
|
|
|
res.SetType(call.Type())
|
|
|
|
|
res.SetTypecheck(1)
|
|
|
|
|
|
|
|
|
|
// Inlining shouldn't add any functions to todoBodies.
|
|
|
|
|
assert(len(todoBodies) == 0)
|
|
|
|
|
|
|
|
|
|
return res
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// inlReturn returns a statement that can substitute for the given
|
|
|
|
|
// return statement when inlining.
|
|
|
|
|
func (r *reader) inlReturn(ret *ir.ReturnStmt) *ir.BlockStmt {
|
|
|
|
|
pos := r.inlCall.Pos()
|
|
|
|
|
|
|
|
|
|
block := ir.TakeInit(ret)
|
|
|
|
|
|
|
|
|
|
if results := ret.Results; len(results) != 0 {
|
|
|
|
|
assert(len(r.retvars) == len(results))
|
|
|
|
|
|
|
|
|
|
as2 := ir.NewAssignListStmt(pos, ir.OAS2, append([]ir.Node(nil), r.retvars...), ret.Results)
|
|
|
|
|
|
|
|
|
|
if r.delayResults {
|
|
|
|
|
for _, name := range r.retvars {
|
|
|
|
|
// TODO(mdempsky): Use inlined position of name.Pos() instead?
|
|
|
|
|
name := name.(*ir.Name)
|
|
|
|
|
block.Append(ir.NewDecl(pos, ir.ODCL, name))
|
|
|
|
|
name.Defn = as2
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
block.Append(as2)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
block.Append(ir.NewBranchStmt(pos, ir.OGOTO, r.retlabel))
|
|
|
|
|
return ir.NewBlockStmt(pos, block)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// expandInline reads in an extra copy of IR to populate
|
|
|
|
|
// fn.Inl.{Dcl,Body}.
|
|
|
|
|
func expandInline(fn *ir.Func, pri pkgReaderIndex) {
|
2021-06-23 14:39:44 +07:00
|
|
|
// TODO(mdempsky): Remove this function. It's currently needed by
|
|
|
|
|
// dwarfgen/dwarf.go:preInliningDcls, which requires fn.Inl.Dcl to
|
|
|
|
|
// create abstract function DIEs. But we should be able to provide it
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
// with the same information some other way.
|
|
|
|
|
|
|
|
|
|
fndcls := len(fn.Dcl)
|
|
|
|
|
topdcls := len(typecheck.Target.Decls)
|
|
|
|
|
|
|
|
|
|
tmpfn := ir.NewFunc(fn.Pos())
|
|
|
|
|
tmpfn.Nname = ir.NewNameAt(fn.Nname.Pos(), fn.Sym())
|
|
|
|
|
tmpfn.ClosureVars = fn.ClosureVars
|
|
|
|
|
|
|
|
|
|
{
|
2022-02-14 09:41:19 -08:00
|
|
|
r := pri.asReader(pkgbits.RelocBody, pkgbits.SyncFuncBody)
|
2021-09-01 11:53:36 -07:00
|
|
|
setType(tmpfn.Nname, fn.Type())
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
// Don't change parameter's Sym/Nname fields.
|
|
|
|
|
r.funarghack = true
|
|
|
|
|
|
|
|
|
|
r.funcBody(tmpfn)
|
|
|
|
|
|
2021-07-01 15:23:41 -07:00
|
|
|
ir.WithFunc(tmpfn, func() {
|
|
|
|
|
deadcode.Func(tmpfn)
|
|
|
|
|
})
|
|
|
|
|
}
|
[dev.typeparams] cmd/compile: unified IR construction
This CL adds a new unified IR construction mode to the frontend. It's
purely additive, and all files include "UNREVIEWED" at the top, like
how types2 was initially imported. The next CL adds a -d=unified flag
to actually enable unified IR mode.
See below for more details, but some highlights:
1. It adds ~6kloc (excluding enum listings and stringer output), but I
estimate it will allow removing ~14kloc (see CL 324670, including its
commit message);
2. When enabled by default, it passes more tests than -G=3 does (see
CL 325213 and CL 324673);
3. Without requiring any new code, it supports inlining of more code
than the current inliner (see CL 324574; contrast CL 283112 and CL
266203, which added support for inlining function literals and type
switches, respectively);
4. Aside from dictionaries (which I intend to add still), its support
for generics is more complete (e.g., it fully supports local types,
including local generic types within generic functions and
instantiating generic types with local types; see
test/typeparam/nested.go);
5. It supports lazy loading of types and objects for types2 type
checking;
6. It supports re-exporting of types, objects, and inline bodies
without needing to parse them into IR;
7. The new export data format has extensive support for debugging with
"sync" markers, so mistakes during development are easier to catch;
8. When compiling with -d=inlfuncswithclosures=0, it enables "quirks
mode" where it generates output that passes toolstash -cmp.
--
The new unified IR pipeline combines noding, stenciling, inlining, and
import/export into a single, shared code path. Previously, IR trees
went through multiple phases of copying during compilation:
1. "Noding": the syntax AST is copied into the initial IR form. To
support generics, there's now also "irgen", which implements the same
idea, but takes advantage of types2 type-checking results to more
directly construct IR.
2. "Stenciling": generic IR forms are copied into instantiated IR
forms, substituting type parameters as appropriate.
3. "Inlining": the inliner made backup copies of inlinable functions,
and then copied them again when inlining into a call site, with some
modifications (e.g., updating position information, rewriting variable
references, changing "return" statements into "goto").
4. "Importing/exporting": the exporter wrote out the IR as saved by
the inliner, and then the importer read it back as to be used by the
inliner again. Normal functions are imported/exported "desugared",
while generic functions are imported/exported in source form.
These passes are all conceptually the same thing: make a copy of a
function body, maybe with some minor changes/substitutions. However,
they're all completely separate implementations that frequently run
into the same issues because IR has many nuanced corner cases.
For example, inlining currently doesn't support local defined types,
"range" loops, or labeled "for"/"switch" statements, because these
require special handling around Sym references. We've recently
extended the inliner to support new features like inlining type
switches and function literals, and they've had issues. The exporter
only knows how to export from IR form, so when re-exporting inlinable
functions (e.g., methods on imported types that are exposed via
exported APIs), these functions may need to be imported as IR for the
sole purpose of being immediately exported back out again.
By unifying all of these modes of copying into a single code path that
cleanly separates concerns, we eliminate many of these possible
issues. Some recent examples:
1. Issues #45743 and #46472 were issues where type switches were
mishandled by inlining and stenciling, respectively; but neither of
these affected unified IR, because it constructs type switches using
the exact same code as for normal functions.
2. CL 325409 fixes an issue in stenciling with implicit conversion of
values of type-parameter type to variables of interface type, but this
issue did not affect unified IR.
Change-Id: I5a05991fe16d68bb0f712503e034cb9f2d19e296
Reviewed-on: https://go-review.googlesource.com/c/go/+/324573
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>
2021-05-13 20:23:13 -07:00
|
|
|
|
|
|
|
|
used := usedLocals(tmpfn.Body)
|
|
|
|
|
|
|
|
|
|
for _, name := range tmpfn.Dcl {
|
|
|
|
|
if name.Class != ir.PAUTO || used.Has(name) {
|
|
|
|
|
name.Curfn = fn
|
|
|
|
|
fn.Inl.Dcl = append(fn.Inl.Dcl, name)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
fn.Inl.Body = tmpfn.Body
|
|
|
|
|
|
|
|
|
|
// Double check that we didn't change fn.Dcl by accident.
|
|
|
|
|
assert(fndcls == len(fn.Dcl))
|
|
|
|
|
|
|
|
|
|
// typecheck.Stmts may have added function literals to
|
|
|
|
|
// typecheck.Target.Decls. Remove them again so we don't risk trying
|
|
|
|
|
// to compile them multiple times.
|
|
|
|
|
typecheck.Target.Decls = typecheck.Target.Decls[:topdcls]
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// usedLocals returns a set of local variables that are used within body.
|
|
|
|
|
func usedLocals(body []ir.Node) ir.NameSet {
|
|
|
|
|
var used ir.NameSet
|
|
|
|
|
ir.VisitList(body, func(n ir.Node) {
|
|
|
|
|
if n, ok := n.(*ir.Name); ok && n.Op() == ir.ONAME && n.Class == ir.PAUTO {
|
|
|
|
|
used.Add(n)
|
|
|
|
|
}
|
|
|
|
|
})
|
|
|
|
|
return used
|
|
|
|
|
}
|
2021-06-23 21:33:24 -07:00
|
|
|
|
|
|
|
|
// @@@ Method wrappers
|
|
|
|
|
|
|
|
|
|
// needWrapperTypes lists types for which we may need to generate
|
|
|
|
|
// method wrappers.
|
|
|
|
|
var needWrapperTypes []*types.Type
|
|
|
|
|
|
2021-08-02 23:56:13 -07:00
|
|
|
// haveWrapperTypes lists types for which we know we already have
|
|
|
|
|
// method wrappers, because we found the type in an imported package.
|
|
|
|
|
var haveWrapperTypes []*types.Type
|
2021-06-23 21:33:24 -07:00
|
|
|
|
2021-08-30 01:01:20 -07:00
|
|
|
// needMethodValueWrappers lists methods for which we may need to
|
|
|
|
|
// generate method value wrappers.
|
|
|
|
|
var needMethodValueWrappers []methodValueWrapper
|
|
|
|
|
|
|
|
|
|
// haveMethodValueWrappers lists methods for which we know we already
|
|
|
|
|
// have method value wrappers, because we found it in an imported
|
|
|
|
|
// package.
|
|
|
|
|
var haveMethodValueWrappers []methodValueWrapper
|
|
|
|
|
|
|
|
|
|
type methodValueWrapper struct {
|
|
|
|
|
rcvr *types.Type
|
|
|
|
|
method *types.Field
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (r *reader) needWrapper(typ *types.Type) {
|
2021-06-23 21:33:24 -07:00
|
|
|
if typ.IsPtr() {
|
2021-08-30 01:01:20 -07:00
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// If a type was found in an imported package, then we can assume
|
|
|
|
|
// that package (or one of its transitive dependencies) already
|
|
|
|
|
// generated method wrappers for it.
|
|
|
|
|
if r.importedDef() {
|
|
|
|
|
haveWrapperTypes = append(haveWrapperTypes, typ)
|
|
|
|
|
} else {
|
|
|
|
|
needWrapperTypes = append(needWrapperTypes, typ)
|
2021-06-23 21:33:24 -07:00
|
|
|
}
|
2021-08-30 01:01:20 -07:00
|
|
|
}
|
2021-06-23 21:33:24 -07:00
|
|
|
|
2021-08-30 01:01:20 -07:00
|
|
|
func (r *reader) importedDef() bool {
|
2021-08-02 23:56:13 -07:00
|
|
|
// If a type was found in an imported package, then we can assume
|
|
|
|
|
// that package (or one of its transitive dependencies) already
|
|
|
|
|
// generated method wrappers for it.
|
|
|
|
|
//
|
|
|
|
|
// Exception: If we're instantiating an imported generic type or
|
|
|
|
|
// function, we might be instantiating it with type arguments not
|
|
|
|
|
// previously seen before.
|
|
|
|
|
//
|
|
|
|
|
// TODO(mdempsky): Distinguish when a generic function or type was
|
|
|
|
|
// instantiated in an imported package so that we can add types to
|
|
|
|
|
// haveWrapperTypes instead.
|
2021-08-30 01:01:20 -07:00
|
|
|
return r.p != localPkgReader && !r.hasTypeParams()
|
2021-06-23 21:33:24 -07:00
|
|
|
}
|
|
|
|
|
|
2021-09-01 11:53:36 -07:00
|
|
|
func MakeWrappers(target *ir.Package) {
|
2022-02-11 11:55:27 -08:00
|
|
|
// Only unified IR emits its own wrappers.
|
|
|
|
|
if base.Debug.Unified == 0 {
|
2021-09-01 11:53:36 -07:00
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
|
2021-06-23 21:33:24 -07:00
|
|
|
// always generate a wrapper for error.Error (#29304)
|
2021-09-01 11:53:36 -07:00
|
|
|
needWrapperTypes = append(needWrapperTypes, types.ErrorType)
|
2021-06-23 21:33:24 -07:00
|
|
|
|
|
|
|
|
seen := make(map[string]*types.Type)
|
|
|
|
|
|
2021-08-02 23:56:13 -07:00
|
|
|
for _, typ := range haveWrapperTypes {
|
2021-09-01 11:53:36 -07:00
|
|
|
wrapType(typ, target, seen, false)
|
2021-08-02 23:56:13 -07:00
|
|
|
}
|
|
|
|
|
haveWrapperTypes = nil
|
|
|
|
|
|
|
|
|
|
for _, typ := range needWrapperTypes {
|
2021-09-01 11:53:36 -07:00
|
|
|
wrapType(typ, target, seen, true)
|
2021-08-02 23:56:13 -07:00
|
|
|
}
|
2021-06-23 21:33:24 -07:00
|
|
|
needWrapperTypes = nil
|
2021-08-30 01:01:20 -07:00
|
|
|
|
|
|
|
|
for _, wrapper := range haveMethodValueWrappers {
|
2021-09-01 11:53:36 -07:00
|
|
|
wrapMethodValue(wrapper.rcvr, wrapper.method, target, false)
|
2021-08-30 01:01:20 -07:00
|
|
|
}
|
|
|
|
|
haveMethodValueWrappers = nil
|
|
|
|
|
|
|
|
|
|
for _, wrapper := range needMethodValueWrappers {
|
2021-09-01 11:53:36 -07:00
|
|
|
wrapMethodValue(wrapper.rcvr, wrapper.method, target, true)
|
2021-08-30 01:01:20 -07:00
|
|
|
}
|
|
|
|
|
needMethodValueWrappers = nil
|
2021-06-23 21:33:24 -07:00
|
|
|
}
|
|
|
|
|
|
2021-09-01 11:53:36 -07:00
|
|
|
func wrapType(typ *types.Type, target *ir.Package, seen map[string]*types.Type, needed bool) {
|
2021-08-30 01:01:20 -07:00
|
|
|
key := typ.LinkString()
|
|
|
|
|
if prev := seen[key]; prev != nil {
|
|
|
|
|
if !types.Identical(typ, prev) {
|
|
|
|
|
base.Fatalf("collision: types %v and %v have link string %q", typ, prev, key)
|
|
|
|
|
}
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
seen[key] = typ
|
|
|
|
|
|
|
|
|
|
if !needed {
|
|
|
|
|
// Only called to add to 'seen'.
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
|
2021-06-23 21:33:24 -07:00
|
|
|
if !typ.IsInterface() {
|
|
|
|
|
typecheck.CalcMethods(typ)
|
|
|
|
|
}
|
|
|
|
|
for _, meth := range typ.AllMethods().Slice() {
|
|
|
|
|
if meth.Sym.IsBlank() || !meth.IsMethod() {
|
|
|
|
|
base.FatalfAt(meth.Pos, "invalid method: %v", meth)
|
|
|
|
|
}
|
|
|
|
|
|
2021-09-01 11:53:36 -07:00
|
|
|
methodWrapper(0, typ, meth, target)
|
2021-06-23 21:33:24 -07:00
|
|
|
|
|
|
|
|
// For non-interface types, we also want *T wrappers.
|
|
|
|
|
if !typ.IsInterface() {
|
2021-09-01 11:53:36 -07:00
|
|
|
methodWrapper(1, typ, meth, target)
|
2021-06-23 21:33:24 -07:00
|
|
|
|
|
|
|
|
// For not-in-heap types, *T is a scalar, not pointer shaped,
|
|
|
|
|
// so the interface wrappers use **T.
|
|
|
|
|
if typ.NotInHeap() {
|
2021-09-01 11:53:36 -07:00
|
|
|
methodWrapper(2, typ, meth, target)
|
2021-06-23 21:33:24 -07:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-09-01 11:53:36 -07:00
|
|
|
func methodWrapper(derefs int, tbase *types.Type, method *types.Field, target *ir.Package) {
|
2021-06-23 21:33:24 -07:00
|
|
|
wrapper := tbase
|
|
|
|
|
for i := 0; i < derefs; i++ {
|
|
|
|
|
wrapper = types.NewPtr(wrapper)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
sym := ir.MethodSym(wrapper, method.Sym)
|
2021-08-30 01:01:20 -07:00
|
|
|
base.Assertf(!sym.Siggen(), "already generated wrapper %v", sym)
|
2021-06-23 21:33:24 -07:00
|
|
|
sym.SetSiggen(true)
|
|
|
|
|
|
|
|
|
|
wrappee := method.Type.Recv().Type
|
|
|
|
|
if types.Identical(wrapper, wrappee) ||
|
|
|
|
|
!types.IsMethodApplicable(wrapper, method) ||
|
|
|
|
|
!reflectdata.NeedEmit(tbase) {
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// TODO(mdempsky): Use method.Pos instead?
|
|
|
|
|
pos := base.AutogeneratedPos
|
|
|
|
|
|
2021-09-01 11:53:36 -07:00
|
|
|
fn := newWrapperFunc(pos, sym, wrapper, method)
|
2021-06-26 12:44:53 -07:00
|
|
|
|
|
|
|
|
var recv ir.Node = fn.Nname.Type().Recv().Nname.(*ir.Name)
|
|
|
|
|
|
|
|
|
|
// For simple *T wrappers around T methods, panicwrap produces a
|
|
|
|
|
// nicer panic message.
|
|
|
|
|
if wrapper.IsPtr() && types.Identical(wrapper.Elem(), wrappee) {
|
|
|
|
|
cond := ir.NewBinaryExpr(pos, ir.OEQ, recv, types.BuiltinPkg.Lookup("nil").Def.(ir.Node))
|
|
|
|
|
then := []ir.Node{ir.NewCallExpr(pos, ir.OCALL, typecheck.LookupRuntime("panicwrap"), nil)}
|
|
|
|
|
fn.Body.Append(ir.NewIfStmt(pos, cond, then, nil))
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// typecheck will add one implicit deref, if necessary,
|
|
|
|
|
// but not-in-heap types require more for their **T wrappers.
|
|
|
|
|
for i := 1; i < derefs; i++ {
|
|
|
|
|
recv = Implicit(ir.NewStarExpr(pos, recv))
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
addTailCall(pos, fn, recv, method)
|
2021-06-30 19:20:28 -07:00
|
|
|
|
2021-09-01 11:53:36 -07:00
|
|
|
finishWrapperFunc(fn, target)
|
2021-06-26 12:44:53 -07:00
|
|
|
}
|
|
|
|
|
|
2021-09-01 11:53:36 -07:00
|
|
|
func wrapMethodValue(recvType *types.Type, method *types.Field, target *ir.Package, needed bool) {
|
2021-06-26 12:44:53 -07:00
|
|
|
sym := ir.MethodSymSuffix(recvType, method.Sym, "-fm")
|
2021-08-30 01:01:20 -07:00
|
|
|
if sym.Uniq() {
|
|
|
|
|
return
|
|
|
|
|
}
|
2021-06-26 12:44:53 -07:00
|
|
|
sym.SetUniq(true)
|
|
|
|
|
|
|
|
|
|
// TODO(mdempsky): Use method.Pos instead?
|
|
|
|
|
pos := base.AutogeneratedPos
|
|
|
|
|
|
2021-09-01 11:53:36 -07:00
|
|
|
fn := newWrapperFunc(pos, sym, nil, method)
|
2021-08-03 10:37:33 -07:00
|
|
|
sym.Def = fn.Nname
|
2021-06-26 12:44:53 -07:00
|
|
|
|
|
|
|
|
// Declare and initialize variable holding receiver.
|
2021-07-02 16:29:42 -07:00
|
|
|
recv := ir.NewHiddenParam(pos, fn, typecheck.Lookup(".this"), recvType)
|
2021-06-26 12:44:53 -07:00
|
|
|
|
2021-08-30 01:01:20 -07:00
|
|
|
if !needed {
|
2021-08-02 23:56:13 -07:00
|
|
|
typecheck.Func(fn)
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
|
2021-06-26 12:44:53 -07:00
|
|
|
addTailCall(pos, fn, recv, method)
|
2021-06-30 19:20:28 -07:00
|
|
|
|
2021-09-01 11:53:36 -07:00
|
|
|
finishWrapperFunc(fn, target)
|
2021-06-26 12:44:53 -07:00
|
|
|
}
|
|
|
|
|
|
2021-09-01 11:53:36 -07:00
|
|
|
func newWrapperFunc(pos src.XPos, sym *types.Sym, wrapper *types.Type, method *types.Field) *ir.Func {
|
2021-06-23 21:33:24 -07:00
|
|
|
fn := ir.NewFunc(pos)
|
2021-06-26 12:44:53 -07:00
|
|
|
fn.SetDupok(true) // TODO(mdempsky): Leave unset for local, non-generic wrappers?
|
2021-06-23 21:33:24 -07:00
|
|
|
|
2021-06-26 12:44:53 -07:00
|
|
|
name := ir.NewNameAt(pos, sym)
|
|
|
|
|
ir.MarkFunc(name)
|
|
|
|
|
name.Func = fn
|
|
|
|
|
name.Defn = fn
|
|
|
|
|
fn.Nname = name
|
2021-06-23 21:33:24 -07:00
|
|
|
|
2021-06-26 12:44:53 -07:00
|
|
|
sig := newWrapperType(wrapper, method)
|
2021-09-01 11:53:36 -07:00
|
|
|
setType(name, sig)
|
2021-06-23 21:33:24 -07:00
|
|
|
|
|
|
|
|
// TODO(mdempsky): De-duplicate with similar logic in funcargs.
|
2021-06-26 12:44:53 -07:00
|
|
|
defParams := func(class ir.Class, params *types.Type) {
|
|
|
|
|
for _, param := range params.FieldSlice() {
|
2021-06-23 21:33:24 -07:00
|
|
|
name := ir.NewNameAt(param.Pos, param.Sym)
|
|
|
|
|
name.Class = class
|
2021-09-01 11:53:36 -07:00
|
|
|
setType(name, param.Type)
|
2021-06-23 21:33:24 -07:00
|
|
|
|
|
|
|
|
name.Curfn = fn
|
|
|
|
|
fn.Dcl = append(fn.Dcl, name)
|
|
|
|
|
|
|
|
|
|
param.Nname = name
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-06-26 12:44:53 -07:00
|
|
|
defParams(ir.PPARAM, sig.Recvs())
|
|
|
|
|
defParams(ir.PPARAM, sig.Params())
|
|
|
|
|
defParams(ir.PPARAMOUT, sig.Results())
|
2021-06-23 21:33:24 -07:00
|
|
|
|
2021-06-26 12:44:53 -07:00
|
|
|
return fn
|
2021-06-23 21:33:24 -07:00
|
|
|
}
|
|
|
|
|
|
2021-09-01 11:53:36 -07:00
|
|
|
func finishWrapperFunc(fn *ir.Func, target *ir.Package) {
|
2021-06-30 19:20:28 -07:00
|
|
|
typecheck.Func(fn)
|
|
|
|
|
|
|
|
|
|
ir.WithFunc(fn, func() {
|
|
|
|
|
typecheck.Stmts(fn.Body)
|
|
|
|
|
})
|
|
|
|
|
|
2021-09-01 11:53:36 -07:00
|
|
|
// We generate wrappers after the global inlining pass,
|
|
|
|
|
// so we're responsible for applying inlining ourselves here.
|
|
|
|
|
inline.InlineCalls(fn)
|
|
|
|
|
|
2021-06-30 19:20:28 -07:00
|
|
|
target.Decls = append(target.Decls, fn)
|
|
|
|
|
}
|
|
|
|
|
|
2021-06-23 21:33:24 -07:00
|
|
|
// newWrapperType returns a copy of the given signature type, but with
|
2021-06-26 12:44:53 -07:00
|
|
|
// the receiver parameter type substituted with recvType.
|
|
|
|
|
// If recvType is nil, newWrapperType returns a signature
|
|
|
|
|
// without a receiver parameter.
|
|
|
|
|
func newWrapperType(recvType *types.Type, method *types.Field) *types.Type {
|
2021-06-23 21:33:24 -07:00
|
|
|
clone := func(params []*types.Field) []*types.Field {
|
|
|
|
|
res := make([]*types.Field, len(params))
|
|
|
|
|
for i, param := range params {
|
|
|
|
|
sym := param.Sym
|
|
|
|
|
if sym == nil || sym.Name == "_" {
|
|
|
|
|
sym = typecheck.LookupNum(".anon", i)
|
|
|
|
|
}
|
|
|
|
|
res[i] = types.NewField(param.Pos, sym, param.Type)
|
|
|
|
|
res[i].SetIsDDD(param.IsDDD())
|
|
|
|
|
}
|
|
|
|
|
return res
|
|
|
|
|
}
|
|
|
|
|
|
2021-06-26 12:44:53 -07:00
|
|
|
sig := method.Type
|
|
|
|
|
|
|
|
|
|
var recv *types.Field
|
|
|
|
|
if recvType != nil {
|
|
|
|
|
recv = types.NewField(sig.Recv().Pos, typecheck.Lookup(".this"), recvType)
|
|
|
|
|
}
|
2021-06-23 21:33:24 -07:00
|
|
|
params := clone(sig.Params().FieldSlice())
|
|
|
|
|
results := clone(sig.Results().FieldSlice())
|
|
|
|
|
|
|
|
|
|
return types.NewSignature(types.NoPkg, recv, nil, params, results)
|
|
|
|
|
}
|
|
|
|
|
|
2021-06-26 12:44:53 -07:00
|
|
|
func addTailCall(pos src.XPos, fn *ir.Func, recv ir.Node, method *types.Field) {
|
|
|
|
|
sig := fn.Nname.Type()
|
|
|
|
|
args := make([]ir.Node, sig.NumParams())
|
|
|
|
|
for i, param := range sig.Params().FieldSlice() {
|
|
|
|
|
args[i] = param.Nname.(*ir.Name)
|
|
|
|
|
}
|
|
|
|
|
|
2021-06-23 21:33:24 -07:00
|
|
|
// TODO(mdempsky): Support creating OTAILCALL, when possible. See reflectdata.methodWrapper.
|
|
|
|
|
// Not urgent though, because tail calls are currently incompatible with regabi anyway.
|
|
|
|
|
|
2021-06-26 12:44:53 -07:00
|
|
|
fn.SetWrapper(true) // TODO(mdempsky): Leave unset for tail calls?
|
|
|
|
|
|
2021-07-03 11:55:31 -07:00
|
|
|
dot := ir.NewSelectorExpr(pos, ir.OXDOT, recv, method.Sym)
|
|
|
|
|
call := typecheck.Call(pos, dot, args, method.Type.IsVariadic()).(*ir.CallExpr)
|
2021-06-23 21:33:24 -07:00
|
|
|
|
|
|
|
|
if method.Type.NumResults() == 0 {
|
2021-06-26 12:44:53 -07:00
|
|
|
fn.Body.Append(call)
|
|
|
|
|
return
|
2021-06-23 21:33:24 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ret := ir.NewReturnStmt(pos, nil)
|
|
|
|
|
ret.Results = []ir.Node{call}
|
2021-06-26 12:44:53 -07:00
|
|
|
fn.Body.Append(ret)
|
2021-06-23 21:33:24 -07:00
|
|
|
}
|