Unless we can prove that the input and output are layout identical we must use either trivial_bit_cast or bitwise_cast.
This changes the lowering to be more conservative for:
- Builtin.reinterpretCast
- address_to_pointer -> pointer_to_address
This also makes LoadStoreOpts more conservative in:
- forwardAddrToUncheckedCastToLd
In order to commit this without massive performance regressions, I added SILType::canBitCastAsSingleRef. When this is true for both sides
of a bitwise case, we can convert it to a RefBitCast, which has RC identity.
Swift SVN r30172
This flag is required for performing the propagation of global and static "let" values into their uses.
Let variables have now a [let] attribute in the SIL textual form.
Swift SVN r30153
These are contexts where we have enough information to bridge /back/
properly; that is, where we can distinguish CBool, ObjCBool, and
DarwinBoolean. In cases where we can't, we keep the three separate;
only CBool is really the same type as Bool.
This also affects current import behavior for ObjCBool, which was previously
incorrectly conflated with CBool in certain cases.
More rdar://problem/19013551
Swift SVN r30051
I am going to use this functionality while performing refactoring of Projection,
ProjectionTree to make it easier to perform partial dead code elimination and
owned -> guaranteed optimization at the same time.
Swift SVN r30000
This enables dead argument elimination to be paired with @owned -> @guaranteed
optimization. It has the additional advantage of allowing us to potentially
eliminate additional retains, releases since the fact that the use is dead
implies that the lifetime of the value no longer needs to be live across the
function call.
Since dead argument elimination can be composed with @owned -> @guaranteed, I
had to modify the mangler, remangler, demangler, to be able to handle a mangling
that combines the two.
I just saw noise in the perf test suite.
rdar://21114206
Swift SVN r29966
The isDependentType() query is woefully misunderstood. Some places
seem to want it to mean "a generic type parameter of dependent member
type", which corresponds to what is effectively a type parameter in
the language, while others want it to mean "contains a type parameter
anywhere in the type". Tease out these two meanings in
isTypeParameter() and hasTypeParameter(), respectively, and sort out
the callers.
Swift SVN r29945
The callback (which is used for creating CG nodes) was lost when deserializing the functions of a vtable.
Fixes rdar://problem/21609902
Swift SVN r29838
This means that we will not explode things like:
struct A { var b: B }
struct B { var c: C }
struct C { var leaf: LeafType }
This does not add anything since all of the types are layout
compatible.
In terms of effect on dylib size, there is a small reduction (i.e. < 1%) over
all dylibs. The only really significant change is to Foundation which shrinks by
3%.
rdar://21114206
Swift SVN r29780
The usage in ConstantPropagation required checking if a branch was passed to the
erase action since in Constant Propagation we want to only invalidate
ProgramFlow if possible. I already fixed this part in r29604. In this commit, I
cleaned up the code by adding/using a "PreserveKindBuilder" that a pass can use
to conveniently accumulate invalidations. This part of the change is just a
refactoring.
In the case of SimplifyCFG we always invalidate everything, we do not need to do
any special checking beyond making sure that a non-null value is passed back
from the cast optimizer. From my investigations in the cast optimizer, it
appears that this always occurs currently. But just in case some future code is
added that allows for a nullptr to come back after it has made modifications, I
added code that ensures that we properly set MadeChange if we modify any
instructions. Since this currently can not happen, I can not write a test for it
that is meaningful.
In the case of SILCombine, we do not perform transformations that invalidate the
CFG, so the current method of using SILCombine's RAUW and inst erase hooks
handle the situation correctly.
Swift SVN r29778
Due to inreased use of llvm::make_range in LLVM headers and ADL for
types defined in the swift namespace, some of the LLVM headers started
to trigger ambiguity errors between llvm::make_range and
swift::make_range.
Swift SVN r29700
If a SILDeclRef references a decl that isn't explicit in the source code and can't be referenced externally, then we only need to emit it if it's referenced in the current TU. Partially addresses rdar://problem/21444126, though we still eagerly generate witness tables for generated conformances, which still pull in a bunch of noise.
Swift SVN r29536
We need a SIL level unsafe cast that supports arbitrary usage of
UnsafePointer, generalizes Builtin.reinterpretCast, and has the same
semantics on generic vs. nongeneric code. In other words, we need to
be able to promote the cast of an address type to the cast of an
object type without changing semantics, and that cast needs to support
types that are not layout identical.
This patch introduces an unchecked_bitwise_cast instruction for that
purpose. It is different from unsafe_addr_cast, which has been our
fall-back "unknown" cast in the past. With unchecked_bitwise_cast we
cannot assume layout or RC identity. The cast implies a store and
reload of the value to obtain the low order bytes. I know that
bit_cast is just an abbreviation for bitwise_cast, but we use
"bitcast" throught to imply copying a same sized value. No one could
come up with a better name for copying an objects low bytes via:
@addr = alloca $wideTy
store @addr, $wideTy
load @addr, $narrowTy
Followup patches will optimize unchecked_bitwise_cast into more
semantically useful unchecked casts when enough type information is
present. This way, the optimizer will rarely need to be taught about
the bitwise case.
Swift SVN r29510
Still no implementation yet; we'll need to renovate how boxes work a bit to make them projectable (and renovate SILGen to generate typed boxes for the insn to be useful).
Swift SVN r29490
This new method eliminates repeated code sequences that all create an
unchecked_trivial_bit_cast if the result type is trivial or
unchecked_ref_bit_cast otherwise.
NFC.
Swift SVN r29486
This reverts commit r29475 because it conflicts with reverting r29474,
and it looks like that commit is breaking the build of the SpriteKit
overlay.
Swift SVN r29481
Still no implementation yet; we'll need to renovate how boxes work a bit to make them projectable (and renovate SILGen to generate typed boxes for the insn to be useful).
Swift SVN r29475
We know if the analysis fails by calling the canForward method instead of using
the failable static initializers. I am worried about unnecessary copies resulting
from the failable initializers.
Swift SVN r29466
SILGen is used to passing in lowered types without getting their object types specifically, and the object type may not be a legal SIL type for address-only types. Fixes rdar://problem/21408736.
Swift SVN r29436
SILFunctionType of the method instead of its formal type.
Gives more accurate information to the @encoding, makes
foreign error conventions work implicitly, and allows
IRGen's Swift-to-Clang to avoid duplicating arbitrary
amounts of the bridging logic from SILGen.
Some finagling was required in order to avoid calling
getConstantFunctionType from within other kinds of
lowering, which might have re-entered a generic context.
Also required fixing a bug with the type lowering of
optional DynamicSelfTypes where we would end up with
a substituted type in the lowered type.
Also, for some reason, our @encoding for -dealloc
methods was pretending that there was a formal parameter.
There didn't seem to be any justification for this,
and it's not like Clang does that. Fixed.
This commit reapplies r29266 with a conservative build fix
that disables ObjC property descriptors for @objc properties
that lack a getter. That should only be possible in SIL
files, because @objc should force accessors to be synthesized.
Arguably, Sema shouldn't be marking things implicitly @objc
in SIL files, but I'll leave that decision open for now.
Swift SVN r29272
SILFunctionType of the method instead of its formal type.
Gives more accurate information to the @encoding, makes
foreign error conventions work implicitly, and allows
IRGen's Swift-to-Clang to avoid duplicating arbitrary
amounts of the bridging logic from SILGen.
Some finagling was required in order to avoid calling
getConstantFunctionType from within other kinds of
lowering, which might have re-entered a generic context.
Also required fixing a bug with the type lowering of
optional DynamicSelfTypes where we would end up with
a substituted type in the lowered type.
Also, for some reason, our @encoding for -dealloc
methods was pretending that there was a formal parameter.
There didn't seem to be any justification for this,
and it's not like Clang does that. Fixed.
Swift SVN r29266
The old SIL-based approach failed to recognize function arguments of
SIL-inlined functions as arguments.
Post-Xcode 7 it would be better to lower this information during SILGen
and emit a debug_value for every function argument so we don't need
to reconstruct them after all the SIL optimizations.
rdar://problem/21109015
Swift SVN r29180
Moved the lightweight access path helper into a ProjectionIndex utility.
Added support to it and the kitchen-sink Projection utility.
Add a ProjectionIndex utility that supports IndexAddr and does only what it needs to do.
While I'm at it, add IndexAddr support to Projection and
ProjectionPath so that other passes can make use of it.
Unfortunately, LoadStore optimization is still not strong enough to
benefit, so I don't have a test case yet.
Note that we have to be very careful now not to assume that when one
projection path is a subsequence of another it must address an
containing region of memory. The implicit index_addr #0 is not part of
the projection path!
Swift SVN r29167
Factor the code to compute an override's vtable type out of SILGen's emitVTableMethod into a method on TypeLowering, and use it to verify the type of class_method instructions. This catches rdar://problem/20874966 at SILGen time instead of letting the devirtualizer barf on it.
Swift SVN r29158
checked_cast_br promises to maintain RC identity, but a cast from an ErrorType-conforming class to NSError may change the RC identity by bridging. Make sure that potential class-to-NSError casts go through the indirect cast entry points for now. The runtime implementation still needs to be fixed to handle the class-to-NSError case, but this is part of rdar://problem/21116814.
Swift SVN r29089
Re-enable function argument explosion during function signature
optimization in the case where there are between one and three live leaf
elements of the projection tree for the argument.
Three is an arbitrary limit, which we can consider tuning later, or
replacing with a better heuristic.
There are many limitations in what we can do at the SIL level to make a
good choice for this transformation, and this is just an attempt to keep
the transformation firing in some limited use cases where it is
relatively likely to be worthwhile rather than disabling it entirely.
I attempted to re-enable most of the test case that was disabled in
r29047.
This appears to eliminate or at least greatly reduce the regression
measured in the CaptureProp benchmark from the change in r29047.
Swift SVN r29062
And also adapt a whole set of SIL passes so that they can deal with (the not deleted) debug_value instructions.
This was required to prevent perforamnce and code size regressions.
Now the generated code is (almost) the same as before.
The effect of this change is that we keep debug_value/debug_value_addr also in optimized code (more or less).
Fixes rdar://problem/18709125.
Swift SVN r28872
It was defined as the const version of use_iterator, which was wrong (e.g. you can't increment it).
Actually we don't need it at all: use_begin/use_end can be const and return the non-const iterator,
because a value is not the container of its uses.
Swift SVN r28870
LoopRoatate (and maybe other optimization) depend on the predecessor order.
Now it looks like we don't have any other non-determinisms in the compiler.
Compiling PerfTests_* produces exactly the same code on multiple compilations.
rdar://problem/20992687
Swift SVN r28706
Fixes nondeterminism in SIL serialization that fortunately seemed to not
affect anything. Or maybe it did and some random crashes will go away now.
Swift SVN r28577
A somewhat more natural solution would be to replace the
normal successor with an edge to an unreachable block,
but that would require adding blocks during the iteration.
Add a small amount of SIL infrastructure for asking a
pred_iterator exactly which edge out of a terminator it
represents.
Swift SVN r28514
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
