forked from OSchip/llvm-project
2e0fe3e65b
iteration. The lazy formation of RefSCCs isn't really the most important part of the laziness here -- that has to do with walking the functions themselves -- and isn't essential to maintain. Originally, there were incremental update algorithms that relied on updates happening predominantly near the most recent RefSCC formed, but those have been replaced with ones that have much tighter general case bounds at this point. We do still perform asserts that only scale well due to this incrementality, but those are easy to place behind EXPENSIVE_CHECKS. Removing this simplifies the entire analysis by having a single up-front step that builds all of the RefSCCs in a direct Tarjan walk. We can even easily replace this with other or better algorithms at will and with much less confusion now that there is no iterator-based incremental logic involved. This removes a lot of complexity from LCG. Another advantage of moving in this direction is that it simplifies testing the system substantially as we no longer have to worry about observing and mutating the graph half-way through the RefSCC formation. We still need a somewhat special iterator for RefSCCs because we want the iterator to remain stable in the face of graph updates. However, this now merely involves relative indexing to the current RefSCC's position in the sequence which isn't too hard. Differential Revision: https://reviews.llvm.org/D29381 llvm-svn: 294227 |
||
|---|---|---|
| .. | ||
| ADT | ||
| Analysis | ||
| AsmParser | ||
| Bitcode | ||
| CodeGen | ||
| DebugInfo | ||
| ExecutionEngine | ||
| IR | ||
| LineEditor | ||
| Linker | ||
| MC | ||
| MI | ||
| Object | ||
| ObjectYAML | ||
| Option | ||
| ProfileData | ||
| Support | ||
| Target | ||
| Transforms | ||
| CMakeLists.txt | ||