Till now there was no way in SIL to explicitly express a dependency of an instruction on any opened archetypes used by it. This was a cause of many errors and correctness issues. In many cases the code was moved around without taking into account these dependencies, which resulted in breaking the invariant that any uses of an opened archetype should be dominated by the definition of this archetype.
This patch does the following:
- Map opened archetypes to the instructions defining them, i.e. to open_existential instructions.
- Introduce a helper class SILOpenedArchetypesTracker for creating and maintaining such mappings.
- Introduce a helper class SILOpenedArchetypesState for providing a read-only API for looking up available opened archetypes.
- Each SIL instruction which uses an opened archetype as a type gets an additional opened archetype operand representing a dependency of the instruction on this archetype. These opened archetypes operands are an in-memory representation. They are not serialized. Instead, they are re-constructed when reading binary or textual SIL files.
- SILVerifier was extended to conduct more thorough checks related to the usage of opened archetypes.
Till now there was no way in SIL to explicitly express a dependency of an instruction on any opened archetypes used by it. This was a cause of many errors and correctness issues. In many cases the code was moved around without taking into account these dependencies, which resulted in breaking the invariant that any uses of an opened archetype should be dominated by the definition of this archetype.
This patch does the following:
- Map opened archetypes to the instructions defining them, i.e. to open_existential instructions.
- Introduce a helper class SILOpenedArchetypesTracker for creating and maintaining such mappings.
- Introduce a helper class SILOpenedArchetypesState for providing a read-only API for looking up available opened archetypes.
- Each SIL instruction which uses an opened archetype as a type gets an additional opened archetype operand representing a dependency of the instruction on this archetype. These opened archetypes operands are an in-memory representation. They are not serialized. Instead, they are re-constructed when reading binary or textual SIL files.
- SILVerifier was extended to conduct more thorough checks related to the usage of opened archetypes.
Till now there was no way in SIL to explicitly express a dependency of an instruction on any opened archetypes used by it. This was a cause of many errors and correctness issues. In many cases the code was moved around without taking into account these dependencies, which resulted in breaking the invariant that any uses of an opened archetype should be dominated by the definition of this archetype.
This patch does the following:
- Map opened archetypes to the instructions defining them, i.e. to open_existential instructions.
- Introduce a helper class SILOpenedArchetypesTracker for creating and maintaining such mappings.
- Introduce a helper class SILOpenedArchetypesState for providing a read-only API for looking up available opened archetypes.
- Each SIL instruction which uses an opened archetype as a type gets an additional opened archetype operand representing a dependency of the instruction on this archetype. These opened archetypes operands are an in-memory representation. They are not serialized. Instead, they are re-constructed when reading binary or textual SIL files.
- SILVerifier was extended to conduct more thorough checks related to the usage of opened archetypes.
TypeAlignments.h predates this whole mess; it was used for types with
stronger alignment in PointerLikeTypeTraits than the old default of
"2 by fiat and assumption". All remaining forward-declared types are
AST types, so fold them into TypeAlignments.h.
(The one exception is SILTypeList.h, but that's already gone on master.)
To avoid future ODR issues, explicitly include TypeAlignments.h into
every header that defines a type it forward-declares.
I wish we could use partial specialization to provide PointerLikeTypeTraits
for all derived classes of Decl, TypeBase, etc, but that's not something
you can do in C++ if you don't control the traits class.
SILValue.h/.cpp just defines the SIL base classes. Referring to specific instructions is a (small) kind of layering violation.
Also I want to keep SILValue small so that it is really just a type alias of ValueBase*.
NFC.
As there are no instructions left which produce multiple result values, this is a NFC regarding the generated SIL and generated code.
Although this commit is large, most changes are straightforward adoptions to the changes in the ValueBase and SILValue classes.
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
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
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
As part of this, re-arrange the argument order so that
generic arguments come before the context, which comes
before the error result. Be more consistent about always
adding a context parameter on thick functions, even
when it's unused. Pull out the witness-method Self
argument so that it appears last after the error
argument.
Swift SVN r26667
Currently, the pass just calls a local version of that function. After OzU, I
will enable the full pass (which is currently disabled behind a flag).
Swift SVN r21894
Now that the ARC optimizer does not rely on stripCasts I also added
unchecked_trivial_bit_cast to stripCasts.
This and r21164 give the following speedups > 10%:
Ary 55.95%
MatMul 36.71%
Ary2 34.97%
Richard 32.08%
PrimeNum 15.87%
<rdar://problem/17456455>
Swift SVN r21240
This mostly falls out from the metatype cast infrastructure, but we need to generalize some Sema and SILGen code to accept AnyMetatypeType. Concrete-to-existential metatypes will need more runtime checking that isn't implemented, so raise a 'not implemented' error on those for now.
Swift SVN r17798
This should eliminate pointless operations that get added to our inline
cost itinerary.
rdar://15567647
rdar://16762768
rdar://16832529
Swift SVN r17644
We want to generally treat blocks as heap objects until proven stack-able by escape analysis, like we do generally with other heap entities. The only place we should be exposed to stack blocks is when they're passed as arguments, so handle this by copy_block'ing any block arguments we get in the function prolog. Optimization can eliminate them when analysis shows the block doesn't escape or is already on the heap.
Swift SVN r16096
