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
When we clone the exiting block such edges become critical and we don't like
critical non cond_br edges (updating SSA needs to put arguments somewhere and
such).
radar://20114457
Swift SVN r25982
Cloning the loop is going to invalidate the loop tree. Be conservative and
recompute it.
No test case. I did not run into an error but also don't want to in the future.
Swift SVN r25733
O speedup (before/after):
ClassArrayGetter`7.4
Rectangles```````1.9
InsertionSort````0.9
Chars````````````0.92
I looked at the Chars and InsertionSort regressions and did not see something
actionable. It looked like noise.
rdar://17955309
Swift SVN r25699
In nested loops the projection operations to get to the array are only
conditionally executed (they reside in the preheader of the inner loop).
So LICM will not hoist them. Instead, recognize them and hoist them on demand.
rdar://19957962
Swift SVN r25620
Array.init does not have a self argument (it returns the newly created array
@owned). Passes using the ArraySemantic::getSelf() interface must handle it
specially.
rdar://19724033
Swift SVN r25013
We can still hoist in many cases if all operations in the loop are 'safe' wrt.
hoisting.
'Safe' array operations are
* all array semantic functions (as long as one array type cannot contain
another).
* stores to array elements
* any instruction that does not have side effects.
* any retain must be matched by a release before we hit a make_unique.
rdar://19668784
Swift SVN r24960
We know that a native swift array that does not need an element type check is
not going to change to an nsarray, or to an array that needs an element type
check. This allows us to specialize array code.
The array semantic calls 'array.props.isCocoa/needsElementTypeCheck' returns
said array properties for a read.
func f(a : A[AClass]) {
for i in 0..a.count {
let b = a.props.isCocoa()
.. += _getElement(a, i, b)
}
}
==>
func f(a : A[AClass]) {
let b2 = a.props.isCocoa()
if (!b2) {
for i in 0..a.count {
.. += _getElement(a, i, false)
}
} else {
for i in 0..a.count {
let b = a.props.isCocoa
.. += _getElement(a, i, b)
}
}
}
The stdlib will be changed to use array.props calls in a future commit.
rdar://17955309
Swift SVN r23689
This follows the model of dominance info and allows me to create reachability
methods on SILBasicBlock without creating dependencies from swiftSIL to
swiftSILAnalysis.
Swift SVN r21866
Arnold noticed during review that ArrayUserSet was not properly
updated after previous rounds of cleanup.
This also removes some innefficiency by eliminating a few hash maps.
I want to make sure this is in good shape before reusing the analysis
for immutable array properties.
Swift SVN r21608
