Make it a std::vector that reserves enough space based on the number of
functions in the initial bottom-up ordering.
This is the first step in making it possible for function passes to
notify the pass manager of new functions to process.
This check should not trigger, at least with the current definition of what a convert_function may do.
But still it's a good idea to make the check to be on the safe side.
Make it a bit more clear that we're alternating between collecting (and
then running) function passes, and running module passes. Removes some
duplication that was present.
Reapplies 9d4d3c8 with fixes for bisecting pass execution.
This reverts commit 9d4d3c8055.
I forgot to finish up changes required to make -Xllvm
-sil-opt-pass-count continue working the way it did, so I'll back that
out until I have those changes as well.
Make it a bit more clear that we're alternating between collecting (and
then running) function passes, and running module passes. Removes some
duplication that was present.
I need this for loop-arc since I need to be able to analyze all "loop-exits"
when I just have the parent loop region. We are already computing this
information and throwing it away, so there should be no compile time impact.
This just runs a transform range on getSuccessor()'s ArrayRef<SILSuccessor> so
one does not need to always call Successor.getBB() when iterating over successor
blocks. Instead the transform range does that call for you.
I also updated some loops to use this new SILBasicBlock method to make sure that
the code is tested out by tests that are already in tree. All these places
should be functionally the same albeit a bit cleaner.
This enables array value propagation in array literal loops like:
for e in [2,3,4] {
r += e
}
Allowing us to completely get rid of the array.
rdar://19958821
SR-203
This reverts commit 82ff59c0b9.
Original commit message:
This allows us to compile the function:
func valueArray() -> Int{
var a = [1,2,3]
var r = a[0] + a[1] + a[2]
return r
}
Down to just a return of the value 6. And should eventually allow us to remove
the overhead of vararg calls.
rdar://19958821
Debug variable info may be attached to debug_value, debug_value_addr,
alloc_box, and alloc_stack instructions.
In order to write textual SIL -> SIL testcases that exercise the handling
of debug information by SIL passes, we need to make a couple of additions
to the textual SIL language. In memory, the debug information attached to
SIL instructions references information from the AST. If we want to create
debug info from parsing a textual .sil file, these bits need to be made
explicit.
Performance Notes: This is memory neutral for compilations from Swift
source code, because the variable name is still stored in the AST. For
compilations from textual source the variable name is stored in tail-
allocated memory following the SIL instruction that introduces the
variable.
<rdar://problem/22707128>
Use ClassHierarchyAnalysis to check if a given method is effectively final, i.e. cannot be overridden.
This replaces the old approach based on using isKnownFinal, which was weaker because it didn't use the ClassHierarchyAnalysis.
It is now able to cover some new cases where the instance is a parameter of a function. If it can be proven that the static type of instance cannot be derived, then it's static type is also a dynamic type of the instance.
The new functionality is not directly triggered in the current setup, because isKnownFinalMethod is currently invoked before it and subsumes this cases. But getInstanceWithExactDynamicType got this functionality anyways to be self-contained, so that it can be used in other contexts, where it is not invoked after isKnownFinalMethod.
