We ignore casts when generating projection paths for alias analysis. When
comparing two paths, we say no alias when accessing different fields of
the same Decl Context.
Swift SVN r20353
Also stripCasts in findAddressProjectionPathBetweenValues.
We can now move "load of an invariant field" out of the loop even though we
have "store to a different field" in the loop.
Performance:
O3 -----
Phonebook 4367 3866 -11.4724%
Ofast ------
NBody 1623 1292 -20.3943%
EditDistance 3043 2589 -14.9195%
Swift SVN r20327
This always wrapped a single GenericTypeParamDecl *, and provided no benefit
over just using the decl directly.
No (intended) functionality change.
Swift SVN r19628
Teach IRGen to honor the linkage of SILWitnessTables, and teach SILGen to emit witness tables and protocol witness thunks for external definitions with shared linkage. Fixes <rdar://problem/16264703>.
Swift SVN r14908
We should also remove it from IRGen's Explosion API; IRGen
should always use maximal explosion, and SILGen will tell us
whether or not we need to put that in memory somewhere.
But that can be a later commit.
Swift SVN r14242
Instead for vardecls, we use the index of the field in the structdecl itself as
a stable ordering of vardecls.
I validated that the indeterminism was gone by running the failing test 1000
times in a row. Doug and I were hitting the indeterminism with well less than
100 iterations before, so I feel the number of iterations is sufficient.
Swift SVN r13859
type, so we emit them. Add mangler (and demangler) support for these.
Enhance our testcase to check to make sure that stores within these
specifiers are direct, they don't cause recursive infinite loops.
John, I picked w/W for the mangling letters, let me know if this is ok.
Swift SVN r13050
This method looks recursively through the operand chain of the given SILValue
until it finds a non-object projection instruction. It then returns that value.
An object projection instruction is one of:
1. struct_extract.
2. tuple_extract.
Swift SVN r12918
An address projection instruction is one of the following instructions:
1. struct_element_addr.
2. tuple_element_addr.
3. ref_element_addr.
This method takes in the given SILValue and continually searches up its
operand chain until it finds a non address projection, non-cast
value (where cast is defined as in SILValue::stripCasts()). The found
SILValue is then returned.
Swift SVN r12909
This method takes in a SILValue and returns the SILValue created by continually
moving up the operand chain of the SILValue until a non-cast instruction is hit.
The non-cast instruction is then returned.
Swift SVN r12906
This mimics what we do for ConstructorDecls, and all of the callers
already DTRT here. Fixes the first half of <rdar://problem/15883734>.
Swift SVN r12811
with two kinds, and some more specific predicates that clients can use.
The notion of 'computed or not' isn't specific enough for how properties
are accessed. We already have problems with ObjC properties that are
stored but usually accessed through getters and setters, and a bool here
isn't helping matters.
NFC.
Swift SVN r12593
When we're using Objective-C's memory allocation, emit .cxx_construct
methods whenever we have instance variables with in-class
initializers. Presently, these methods are just empty stubs.
Swift SVN r12211
The Objective-C runtime executes the .cxx_destruct method after the
last -dealloc has executed when destroying an object, allowing the
instance variables to remain live even after the subclass's
destructor/-dealloc has executed, which is important for memory
safety. This fixes the majority of <rdar://problem/15136592>.
Note that IRGenModule::getAddrOfIVarDestroyer() contains an egregious
hack to find the ivar destructor SIL function via a linear
search. We need a better way to find SIL functions that we know exist,
because LinkEntity does not suffice.
Swift SVN r12206
Because Objective-C doesn't have the notion of a destroying
destructor, this is a matter of cleanliness rather than
correctness. Still, it's better not to lie.
Swift SVN r12160
SILDeclRef was previously storing the ClassDecl for this case, because
semantic analysis didn't guarantee that a DestructorDecl was always
present. It is now, and this representation makes more sense.
Swift SVN r12122
In general, this forces SILGen and IRGen code that's grabbing
a declaration to state whether it's doing so to define it.
Change SIL serialization to serialize the linkage of functions
and global variables, which means also serializing declarations.
Change the deserializer to use this stored linkage, even when
only deserializing a declaration, and to call a callback to
inform the client that it has deserialized a new entity.
Take advantage of that callback in the linking pass to alter
the deserialized linkage as appropriate for the fact that we
imported the declaration. This computation should really take
advantage of the relationship between modules, but currently
it does not.
Swift SVN r12090
Currently SILType's method definitions are strewn in various files in
lib/SIL/*.cpp. This patch just adds a new file SILType.cpp that centralizes
many of those definitions.
*NOTE* Any method which uses declarations inside of a specific *.cpp file I left
alone (there were 3). If we want to, we can perhaps create a new header to share
the interface in between the two. I wanted this change to be as incremental as
possible so I left that undone.
Swift SVN r11890
