sema is emitting each step of a conversion independently. Also, as a driveby,
fix an optimizer crash in the "(ref_to_raw_pointer (ref_to_object_pointer x))
to (ref_to_raw_pointer x)" peephole when the ref_to_object_pointer had other
uses (noticed by inspection).
Swift SVN r14603
We need to run the entire pass manager pipe to expose this bug. I did not want
to include a big SIL file because it would be more code that we will need to
update if we change SIL.
Swift SVN r14531
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
This class allows you to deal with tuple and nominal projections in a way that
is agnostic of either of them.
Expect some incoming utilities based off of this for dealing with what I call
'aggregate type trees'.
Swift SVN r13735
Now the pass does not need to know about the pass manager. We also don't have
runOnFunction or runOnModule anymore because the trnasformation knows
which module it is processing. The Pass itself knows how to invalidate the
analysis, based on the injected pass manager that is internal to the
transformation.
Now our DCE transformation looks like this:
class DCE : public SILModuleTransform {
void run() {
performSILDeadCodeElimination(getModule());
invalidateAnalysis(SILAnalysis::InvalidationKind::All);
}
};
Swift SVN r13598
were attempting to create destroy values for arguments that were not apart of
the partial apply itself in the case where the partial apply had more than 1
argument left uncurried.
Swift SVN r13448
This patch canonicalizes projections of load to loads of gep so that passes like
the ARC optimizer and the load/store optimization in SILCodeMotion have a
canonical pattern to look for. As an example, often times in the stdlib one
will see something like this:
(retain (struct_extract (load)))
and,
(release (load (struct_element_addr)))
It does not matter which one we pick, just that we pick one.
Swift SVN r13324
I am unhappy about this but otherwise since we are just "consuming" the other
pointers, we do not properly get the other points on the SILCombine worklist
since SimplifyInstruction does not have a manner of communicating that.
I kept around the method stub in SimplifyInstruction.cpp since in the next
commit I am going to put a round trip optimization for ref_to_raw_pointer
there.
Swift SVN r12835
The case this is optimization is:
strong_release %0
strong_retain %0
This case occurs due to the strong_release's matching retain being in a
different basic block from the increment/decrement and the same for the
strong_retain.
At some point way in the future, when we get a true global ARC optimizer, this
will no longer be necessary.
But until that point, there is no reason why we can not remove such a pair.
Swift SVN r12655
Do the same for the tuple_extract optimization.
After turning this off I am starting to see a bunch of code like this:
%69 = load %1#1 : $*Array<T> // users: %77, %70
%70 = struct_extract %69 : $Array<T>, #owner // user: %73
%71 = struct_element_addr %1#1 : $*Array<T>, #owner // user: %72
%72 = load %71 : $*Builtin.ObjectPointer // user: %74
strong_retain %70 : $Builtin.ObjectPointer // id: %73
strong_release %72 : $Builtin.ObjectPointer // id: %74
dealloc_stack %1#0 : $*@local_storage Array<T> // id: %75
strong_release %2 : $Builtin.ObjectPointer // id: %76
return %69 : $Array<T> // id: %77
Which confuses the ARC optimizer (notice the struct_extract vs
struct_element_addr).
I imagine we will want to canonicalize this case in a different way (maybe an
inverse peephole that would turn in this case the struct_element_addr + load ->
load + struct_extract?).
Swift SVN r12305
I have seen this a few times in the stdlib in methods like:
_TFCSs21DictionaryBufferOwnercUSs8Hashable___fMGS_Q_Q0__FT15minimumCapacitySi_GS_Q_Q0__
Swift SVN r12273
Our debugTraps still capture values in a closure even when we comment them out. Adding this pattern
that removes unused partial_apply instructions removes all of these debugTraps.
This accelerates our RC4 benchmark by 4.5X (we are now only 180x the speed of CPP).
Swift SVN r12202
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
This occurs frequently in the standard library (especially with enums) and there
is no reason not to eliminate it in SILCombine if we can since we will be
eliminating it earlier (potentially opening up more optimizations).
Swift SVN r12074
init_existential instruction. However, in some cases the protocol is initialized
using copy_addr. This patch adds support for analyzing the copy_addr in search
for the init_existential instruction. The same rules must apply: both
instructions must not be captured, etc.
With this change we devirtualize 287 calls in stdlib. We are left with only 26 project_existential instructions in stdlib.
I don't have a testcase outside the stdlib right now.
Swift SVN r11897
1. When optimizing the class_method in search of a static type we now skip downcasts and upcasts.
2. Metatype are also considered static classes.
3. Search the entire class hierarchy.
Swift SVN r11842
