SILGen: Kill "scalar" PreparedArguments #23650
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
VarargExpansionExpr shows up in call argument lists in synthesized initializers and modify accessors when we need to forward arguments to a call taking varargs. Previously we would say that the type of VarargExpansionExpr is $T when its subexpression type is [$T]. matchCallArguments() would then 'collect' the single VarargExpansionExpr into a variadic argument list with a single element, and build an ArgumentShuffleExpr for the argument list. In turn, SILGen would peephole vararg emission of a variadic argument list with a single entry that happens to be a VarargExpansionExpr, by returning the subexpression's value, which happened to be an array of the right element type, instead of building a new array containing the elements of the variadic argument list. This was all too complicated. Instead, let's say that the type of a VarargExpansionExpr is [$T], except that when it appears in a TupleExpr, the variadic bit of the corresponding element is set. Then, matchCallArguments() needs to support a case where both the parameter and argument list have a matching vararg element. In this case, instead of collecting multiple arguments into a single variadic argument list, we treat the variadic argument like an ordinary parameter, bypassing construction of the ArgumentShuffleExpr altogether. Finally, SILGen now needs to be able to emit a VarargExpansionExpr in ordinary rvalue position, since it now appears as a child of a TupleExpr; it can do this by simply emitting the sub-expression to produce an array value.
This is equivalent to the trivial case of an ArrayExpr with the Array.init(arrayLiteral: T...) initializer; it will be used by CSApply to build vararg arrays.
… an ArgumentSource
This introduces a bit of repetition for now, but I'm going to factor it out a different way later.
…uments This eliminates another place where we built "scalar" PreparedArguments.
…fleExpr For anything else, we can decompose the argument list on the spot. Note that builtins that are implemented as EarlyEmitters now take a the argument list as a PreparedArguments instead of a single Expr. Since the PreparedArguments can still be a scalar with an ArgumentShuffleExpr, we have to jump through some hoops to turn it into a list of argument Exprs. This will all go away soon.
They still exist when an ArgumentShuffleExpr is decomposed, but that's about to go away.
slavapestov
force-pushed
the
kill-scalar-prepared-arguments
branch
from
2b0ff1f to
1417647
Compare
|
@swift-ci Please test |
|
@swift-ci Please test source compatibility |
|
Build failed |
|
@swift-ci Please smoke test macOS |
|
This broke the MSVC build (#23670) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The PreparedArguments abstraction could be used in two ways: you could either build it from a decomposed argument list with one expression per argument, or build a "scalar" one with a single expression for all the arguments.
This PR removes the "scalar" case, except when the expression is an ArgumentShuffleExpr. That's not a problem because my next PR will completely remove ArgumentShuffleExpr.