The old invalidation lattice was incorrect because changes to control flow could cause changes to the
call graph, so we've decided to change the way passes invalidate analysis. In the new scheme, the lattice
is replaced with a list of traits that passes preserve or invalidate. The current traits are Calls and Branches.
Now, passes report which traits they preserve, which is the opposite of the previous implementation where
passes needed to report what they invalidate.
Node: I tried to limit the changes in this commit to mechanical changes to ease the review. I will cleanup some
of the code in a following commit.
Swift SVN r26449
The code used ssa value inquality to disqualify aliasing. This is not strong
enough. Use AliasAnalysis instead.
This is a correctness fix.
Unfortunately, I measured the following regressions at -O:
TEST``````````````````````````Speedup(minbefore/minafter)
ArrayOfGenericPOD`````````````0.73871
ArrayOfPOD````````````````````0.701107
CaptureProp```````````````````0.886796
Dictionary2```````````````````0.907991
Dictionary3```````````````````0.86035
LevenshteinDistance```````````0.714346
QuickSort`````````````````````0.942924
RC4```````````````````````````0.742609
SwiftStructuresInsertionSort``0.942875
TwoSum````````````````````````0.956233
I measured the following regressions at -Onone:
TEST```````````````````````Speedup(minbefore/minafter)
RIPEMD`````````````````````0.955413
SwiftStructuresBubbleSort``0.943074
I measured the following regressions at -Ounchecked:
TEST```````````Speedup(minbefore/minafter)
RC4````````````0.757648
StringBuilder``0.956013
SuperChars`````0.954549
rdar://19362910
Swift SVN r24247
LSValue, LSStore, and LSLoad are structs that are meant to be able to
allow for load store opts to use the same logic for performing load
store opts from one load, store and covering sets of loads, stores.
This changes LoadStoreOpts to use these data structures when it is not
considering covering stores.
Swift SVN r24183
store forward while performing the load store forwarding. This can cause
us to dereference an empty SILValue.
The forwarding feasability code in LoadStoreOpts is separated into an
analysis and a action part. The action part assumes that SILValues
returned are never null. This violates a normal error handling pattern
with SILValues. We should introduce some notion of a SILValue that can
not be null. Until then, this patch fixes the crasher.
<rdar://problem/19369189>
Swift SVN r24169
I want to cleanup some code paths in SILCombine and LoadStoreOpts to use
generic create{Addr,Value}Projection methods which create the
appropriate projection instruction for a Projection method. Also this
will allow me to start to hide more of the internal state of Projection.
Swift SVN r23366
This changes the Projection API so that you pass in an instruction and get back
an optional depending on what theinstruction was. This is much cleaner than
always needing to do a switch.
This commit also cleans up the naming in Projection so that we always use the
term "value projection" for struct_extract, tuple_extract, and
unchecked_enum_data instead of the term "extract". This lines up better with the
name we use for the *_addr instructions, "address projection" and avoids
ambiguity since unchecked_enum_data does not have the word "extract" in it.
Additionally by adding in the failable initializers, my centralization of the
initialization logic enables me to ensure that isAddrProjection and
isValueProjection stay in sync with the various constructors via asserts. This
should prevent future bugs if we add additional notions of "projection".
Swift SVN r23356
This will help the ARC optimizer given future function sig optimization work and
is in general good since this has been a hole in our load store forwarding for a
while.
rdar://18831605
Swift SVN r23102
without a valid SILDebugScope. An assertion in IRGenSIL prevents future
optimizations from regressing in this regard.
Introducing SILBuilderWithScope and SILBuilderwithPostprocess to ease the
transition.
This patch is large, but mostly mechanical.
<rdar://problem/18494573> Swift: Debugger is not stopping at the set breakpoint
Swift SVN r22978
Really we want to only cast between equally sized types. SIL does not really
have a concept of types of the same size so this solution is a workaround
(temporary) for acutal code in the standard library which casts a pointer of an
UTF16 type to a pointer of an UTF8 type.
rdar://18118602
Swift SVN r21470
We use a DenseMap to map an address to a list of reaching StoreInsts,
one for each predecessor. The map is passed as function arguments instead
of a member in LSBBForwarder since it is only used during one invocation
of optimizing a basic block.
We can now remove all loads in rdar://17613168 and enable dead object
elimination. There is one issue though, one of the loads is loop invariant
and is moved outside by LICM, but we need to run LoadStoreOpt and DeadObjectElim
afterwards to actually remove the dead object.
Performance for rdar://17613168 (with added passes after LICM):
-Ounchecked: 13.8s to 0.199s
-O: 15.4s to 2s
Swift SVN r20922
To help adding BBArguments to merge in multiple stores, we separate
the feasibility check so we can check the feasibility before creating
BBArguments.
Swift SVN r20904
There is no need to clear the state before merging in the states of
the predecessors. In the case of a self loop, we need the previous
state of the basic block, otherwise, the state will be initialized to
the state of the first predecessor.
Swift SVN r20766
When BB is its own predecessor, we can't do the following
state[BB] = state[first pred of BB]
state[BB].merge(state[other predecessors])
--> here we are merging in the updated state[BB]
Instead we should do
state[BB].merge(state[predecessors other than BB])
Swift SVN r20114
This is not run by default unless one passes in the flag -Xllvm -enable-global-load-store-opts.
Also in order to make sure in the face of multi-bbs dead store elimination is
still correct, we use the post order dominator tree to determine if the dead
store is post dominated by the store that is causing it to be dead.
With this pass enabled, we see a 3.5% decrease in overall time in the precommit
bench and the following tests increase in speed by > 5%:
2Sum: 8.9%
Rectangles: 7.35%
Ackermann: 6.43%
StringBuilder: 6.16%
EditDistance: 5.71%
StringWalk: 5.58%
That means that 30% of our benchmarks increased in speed by > 5%. Many of the
other benchmarks increased in speed significantly but not as drmatically.
The only benchmark that regressed is SmallPt which I am looking into.
rdar://17680758
Swift SVN r20009
The code does the right thing, but the assert should be checking that
the load we're about to replace has the same type as the value we're
replacing it with.
This was exposed by changes to inline generic code.
Swift SVN r19921
This commit enables support in the optimizer for promoting the following
unchecked_addr_cast kinds to object bit casts:
1. (Trivial => Trivial) yields a trivial bit cast.
2. (Non-Trivial => Trivial) yields a trivial bit cast.
3. (Non-Trivial => Non-Trivial) yields a ref bit cast.
We do not promote conversions in between trivial and non-trivial types
since a trivial bit cast must have a trivial output and if we allowed
for ref bit casts in between the two, we would be breaking the rule that
ref bit casts do not change the reference semantics of its input, output
types. Technically, we could lower trivial => trivial as a ref cast and
then simplify later but that is unnecessary currently.
<rdar://problem/17373087>
Swift SVN r19784
This is tested by an assertion in IRGen. After Beta3, this code is going
to go away and be replaced by just always promoting the cast. Then the
IRGen assertion will be replaced by propagating undef. The assertion in
the stdlib will still fire in that case since the assertion is based on
the tops not the given value implying that we will not lose any
correctness.
Swift SVN r19272
Both have the same form of, (Address, Value, Load). For the store->load I pass in
(SI->getDest(), SI->getSrc(), LI) and for the load->load I pass in
(OldLI->getOperand(), OldLI, LI).
This also for free lets our load deduplication support forwarding from casts.
Swift SVN r19133
I also refactored findExtractPathBetweenValues to be able to be used for both
partial load duplication and forwarding stores to partial loads.
Swift SVN r19132
