when working with autoreleased result conventions, and stop
emitting autorelease_return and strong_retain_autoreleased in
SILGen.
The previous representation, in which strong_retain_autoreleased
was divorced from the call site, allowed it to "wander off" and
be cloned. This would at best would break the optimization, but
it could also lead to broken IR due to some heroic but perhaps
misguided efforts in IRGen to produce the exact required code
pattern despite the representational flaws.
The SIL pattern for an autoreleased result now looks exactly
like the pattern for an owned result in both the caller and
the callee. This should be fine as long as interprocedural
optimizations are conservative about convention mismatches.
Optimizations that don't wish to be conservative here should
treat a convention mismatch as an autorelease (if the callee
has an autoreleased result) or a retain (if the formal type
of the call has an autoreleased result).
Fixes rdar://23810212, which is an IRGen miscompile after the
optimizer cloned a strong_retain_autoreleased. There's no
point in adding this test case because the new SIL pattern
inherently prevents this transformation by construction.
The 'autorelease_return' and 'strong_retain_autoreleased'
instructions are now dead, and I will remove them in a
follow-up commit.
Modeling nonescaping captures as @inout parameters is wrong, because captures are allowed to share state, unlike 'inout' parameters, which are allowed to assume to some degree that there are no aliases during the parameter's scope. To model this, introduce a new @inout_aliasable parameter convention to indicate an indirect parameter that can be written to, not only by the current function, but by well-typed, well-synchronized aliasing accesses too. (This is unrelated to our discussions of adding a "type-unsafe-aliasable" annotation to pointer_to_address to allow for safe pointer punning.)
This triggered on the PerfTestSuite but there weren't any tests for it.
Add a simple test, but probably its still wrong, eg opaque-to-opaque
tuple conversions.
A better fix would be to have transforms support conversions where
only one side is a tuple in transformTuple().
Take apart exploded one-element tuples and be more careful with
passing around tuple abstraction patterns.
Also, now we can remove the inputSubstType parameter from
emitOrigToSubstValue() and emitSubstToOrigValue(), making the
signatures of these functions nice and simple once again.
Fixes <rdar://problem/19506347> and <rdar://problem/22502450>.
Kill the two Transform subclasses, OrigToSubst and SubstToOrig. Instead,
Transform::transform() and other functions take an abstraction pattern
for both the input and the output value.
This simplifies the code in preparation for resilience expansion thunks.
Probably SILGenPoly.cpp should be named SILGenThunk.cpp, but I'm saving
that for if I ever extract the duplication between bridging thunks and
re-abstraction thunks.
This improves support for promoting to and generating
unchecked_ref_cast so we no longer need unchecked_ref_bit_cast, which
will just go away in the next commit.
Swift SVN r32597
Right now, re-abstraction thunks are set up to convert values
as follows, where L is type lowering:
- OrigToSubst: L(origType, substType) -> L(substType)
- SubstToOrig: L(substType) -> L(origType, substType)
This assumes there's no AST-level type conversion, because
when we visit a type in contravariant position, we flip the
direction of the transform but we're still converting *to*
substType -- which will now equal to the type of the input,
not the type of the expected result!
This caused several problems:
- VTable thunk generation had a bunch of special logic to
compute a substOverrideType, and wrap the thunk result
in an optional, duplicating work done in the transform
- Witness thunk generation similarly had to handle the case
of upcasting to a base class to call the witness, and
casting the result of materializeForSet back to the right
type for properties defined on the base.
Now the materializeForSet cast sequence is a bit longer,
we unpack the returned tuple and do a convert_function
on the function, then pack it again -- before we would
unchecked_ref_cast the tuple, which is technically
incorrect since the tuple is not a ref, but IRGen didn't
seem to care...
To handle the conversions correctly, we add a third AST type
parameter to a transform, named inputType. Now, transforms
perform these conversions:
- OrigToSubst: L(origType, inputType) -> L(substType)
- SubstToOrig: L(inputType) -> L(origType, substType)
When we flip the direction of the transform while visiting
types in contravariant position, we also swap substType with
inputType.
Note that this is similar to how bridging thunks work, for
the same reason -- bridging thunks convert between AST types.
This is mostly just a nice cleanup that fixes some obscure
corner cases for now, but this functionality will be used
in a subsequent patch.
Swift SVN r31486
Also make it more accurate by lowering optional payload types, but
nothing depends on this right now.
Apologies for the recent stream of unrelated-looking NFCs -- the goal
here is to make a big upcoming patch easier to review.
Swift SVN r31480
- Generalize::transformFunction() had a couple of little optimizations
for emitting convert_function or thin_to_thick_function instead of
a thunk, if possible -- move this into code shared by all
transforms
- Nuke Generalize since it doesn't do anything special anymore
Swift SVN r31423
There are three implementations of this in SIL so far:
- in emitGeneralizedFunctionValue()
- in emitVTableMethod()
- in the SILVerifier
I haven't touched the latter yet, though.
Swift SVN r31422
the type-checker. The strategy for now is to just use this
for protocol witness thunk emission, where it is required
when generating a materializeForSet for storage that is
either implemented in a protocol extension or requires
reabstraction to the requirement's pattern.
Eventually, this should be generalized to the point that
we can use it for all materializeForSet emission, which
I don't think will take much. However, that's not really
the sort of instability we want to embrace for the current
release.
WIP towards rdar://21836671; currently disabled, so NFC.
Swift SVN r31072
Actually invoking such an override on an instance of the derived type
still doesn't work, unless you cast to the base type first. Fixing this
requires emitting a new vtable entry for the new signature and is
tracked in <rdar://problem/21435542>.
Fixes <rdar://problem/21364764>.
Swift SVN r29935
This patch attempts to fix rdar://problem/21452981, which Joe worked on
in r29572, but reverted because that patch had other changes that broke
stuff.
Swift SVN r29934
These still show up if you have a witness with a default argument, which the AST still represents as a single-element tuple, matched against a non-tuple orig type in the witness signature. Handle this by allowing getTupleElementType(0) on non-tuple AbstractionPatterns to work, and tweaking the parallel translation code to drill through single-element tuples and line up the contained scalars properly. Fixes rdar://problem/21452981. (Still left broken is the obnoxious single-element-tuple-of-tuple case, rdar://problem/21496105.)
Now with less Xcode autosave breakage.
Swift SVN r29572
These still show up if you have a witness with a default argument, which the AST still represents as a single-element tuple, matched against a non-tuple orig type in the witness signature. Handle this by allowing getTupleElementType(0) on non-tuple AbstractionPatterns to work, and tweaking the parallel translation code to drill through single-element tuples and line up the contained scalars properly. Fixes rdar://problem/21452981. (Still left broken is the obnoxious single-element-tuple-of-tuple case, rdar://problem/21496105.)
Swift SVN r29561
When a derived class specializes its base class, e.g. 'class Derived: Base<Int>', the natural abstraction levels of its methods may differ from the original base class's more abstract methods. Handle this by using the reabstraction machinery to thunk values when necessary. Merge the existing optionality thunking support into the reabstraction code, where witness thunking and similar convention adjustments may also be able to use it, if we desire. Fixes rdar://problem/19760292.
Swift SVN r28505
The translation code already handles translating in_guaranteed arguments
correctly. The assert was just too conservative.
<rdar://problem/20522878>
Swift SVN r27307
The only caveat is that:
1. We do not properly recognize when we have a let binding and we
perform a guaranteed dynamic call. In such a case, we add an extra
retain, release pair around the call. In order to get that case I will
need to refactor some code in Callee. I want to make this change, but
not at the expense of getting the rest of this work in.
2. Some of the protocol witness thunks generated have unnecessary
retains or releases in a similar manner.
But this is a good first step.
I am going to send a large follow up email with all of the relevant results, so
I can let the bots chew on this a little bit.
rdar://19933044
Swift SVN r27241
These aren't really orthogonal concerns--you'll never have a @thick @cc(objc_method), or an @objc_block @cc(witness_method)--and we have gross decision trees all over the codebase that try to hopscotch between the subset of combinations that make sense. Stop the madness by eliminating AbstractCC and folding its states into SILFunctionTypeRepresentation. This cleans up a ton of code across the compiler.
I couldn't quite eliminate AbstractCC's information from AST function types, since SIL type lowering transiently created AnyFunctionTypes with AbstractCCs set, even though these never occur at the source level. To accommodate type lowering, allow AnyFunctionType::ExtInfo to carry a SILFunctionTypeRepresentation, and arrange for the overlapping representations to share raw values.
In order to avoid disturbing test output, AST and SILFunctionTypes are still printed and parsed using the existing @thin/@thick/@objc_block and @cc() attributes, which is kind of gross, but lets me stage in the real source-breaking change separately.
Swift SVN r27095
The set of attributes that make sense at the AST level is increasingly divergent from those at the SIL level, so it doesn't really make sense for these to be the same. It'll also help prevent us from accidental unwanted propagation of attributes from the AST to SIL, which has caused bugs in the past. For staging purposes, start off with SILFunctionType's versions exactly the same as the FunctionType versions, which necessitates some ugly glue code but minimizes the potential disruption.
Swift SVN r27022
This is necessary for correctly dealing with non-standard
ownership conventions in secondary positions, and it should
also help with non-injective type imports (like BOOL/_Bool).
But right now we aren't doing much with it.
Swift SVN r26954
Previously some parts of the compiler referred to them as "fields",
and most referred to them as "elements". Use the more generic 'elements'
nomenclature because that's what we refer to other things in the compiler
(e.g. the elements of a bracestmt).
At the same time, make the API better by providing "getElement" consistently
and using it, instead of getElements()[i].
NFC.
Swift SVN r26894
We no longer need or use it since we can always refer to the same bit on
the applied function when deciding whether to inline during mandatory
inlining.
Resolves rdar://problem/19478366.
Swift SVN r26534
The deallocating parameter convention is a new convention put on a
non-trivial parameter if the caller function guarantees to the callee
that the parameter has the deallocating bit set in its object header.
This means that retains and releases do not need to be emitted on these
parameters even though they are non-trivial. This helps to solve a bug
in +0 self and makes it trivial for the optimizer to perform
optimizations based on this property.
It is not emitted yet by SILGen and will only be put on the self
argument of Deallocator functions.
Swift SVN r26179
If we have a C function pointer conversion, generate a thunk using the same logic we use for ObjC method thunks, and emit a pointer to that thunk as the C function pointer value. (This works for nongeneric, nonmember functions; generics will additionally need to apply generic parameters within the thunks. Static functions would need to gather the metatype as well.)
Swift SVN r25653
