The LICM algorithm was not robust with respect to address projection
because it identifies a projected address by its SILValue. This should
never be done! Use AccessPath instead.
Fixes regressions caused by rdar://66791257 (Print statement provokes
"Can't unsafeBitCast between types of different sizes" when
optimizations enabled)
It is legal for the optimizer to consider code after a loop always
reachable, but when a loop has no exits, or when the loops exits are
dominated by a conditional statement, we should not consider
conditional statements within the loop as dominating all possible
execution paths through the loop. At least not when there is at least
one path through the loop that contains a "synchronization point",
such as a function that may contain a memory barrier, perform I/O, or
exit the program.
Sadly, we still don't model synchronization points in the optimizer,
so we need to conservatively assume all loops have a synchronization
point and avoid hoisting conditional traps that may never be executed.
Fixes rdar://66791257 (Print statement provokes "Can't unsafeBitCast
between types of different sizes" when optimizations enabled)
Originated in 2014.
Since the dominator tree is passed to the LoopInfo constructor, just save
a pointer to it for use in the verify function. If this is not sufficiently
flexible, we could alternatively change to pass the dominator tree as an
argument to the verify function, but let's try the simpler approach first.
To determine whether it is safe to duplicate the instruction by duplicating the
loop body. Will be used in loop versioning for array and loop unrolling.
This analysis provides the following functionality:
1. An abstraction over all loops and basic blocks called a 'region'. For
a given loop this abstraction is used to represent all immediate child
basic blocks (1) and immediate subloops (2) called child regions.
2. Detection of back edges that were not found by SILLoopInfo. The
heads/tails of such back edges are marked as being areas where unhandled
control flow occurs. This enables irreducible control flow to be handled
by users as appropriate.
3. For each loop in the loop tree an RPO/PO ordering of the loop's
subregions. This enables one to run dataflow on the loop tree using loop
abstractions in a structured, clean manner by processing regions and
depending on whether or not the region was a loop/BB handle it
appropriately.
Some notes:
1. Functions are represented as a top level loop.
2. The analysis is setup to conservatively handle loops with the
following properties:
a. Irreducible Control Flow.
b. Multiple Backedges
In these cases, we use the unknown control flow facility to allow for
users of the analysis to handle the behavior appropriately.
We assume 2.b. since I am going to implement canonicalization of
multiple backedge loops into nested loops.
Also two passes are provided for working with this analysis:
1. LoopRegionViewText - Dump loop regions in a textual format. This is
intended for usage with FileCheck tests.
2. LoopRegionViewCFG - Dump loop regions into a CFG pdf. The dumped CFG
includes the loops, functions, and BBs. It represents
successors/predecessors in the loop region by black arrows and
hierarchical relations in between regions/subregions by red dashed
arrows. It also prints out the contents of BBs and whether or not
unknown control flow occurs.
(1) BBs for which this loop is the inner most parent loop.
(2) Loops for which this loop is the inner most parent loop.
Thanks to Arnold review!
rdar://22238531
Swift SVN r32104
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
