forked from OSchip/llvm-project
b559535a3a
Summary: When an SCC got split due to inlining, we have two mechanisms for reprocessing the updated SCC, first is UR.UpdatedC that repeatedly rerun the new, current SCC; second is a worklist for all newly split SCCs. We can avoid rerun of the same SCC when the SCC is set to be processed by both mechanisms *back to back*. In pathological cases, such redundant rerun could cause exponential size growth due to inlining along cycles, even when there's no SCC mutation and hence convergence is not a problem. Note that it's ok to have SCC updated and rerun immediately, and also in the work list if we have actually moved an SCC to be topologically "below" the current one due to merging. In that case, we will need to revisit the current SCC after those moved SCCs. For that reason, the redundant avoidance here only targets back to back rerun of the same SCC - the case described by the now removed FIXME comment. Reviewers: chandlerc, wmi Subscribers: llvm-commits, hoy Tags: #llvm Differential Revision: https://reviews.llvm.org/D80589 |
||
---|---|---|
.. | ||
ADT | ||
Analysis | ||
AsmParser | ||
BinaryFormat | ||
Bitcode | ||
Bitstream | ||
CodeGen | ||
DebugInfo | ||
Demangle | ||
ExecutionEngine | ||
Frontend | ||
FuzzMutate | ||
IR | ||
LineEditor | ||
Linker | ||
MC | ||
MI | ||
Object | ||
ObjectYAML | ||
Option | ||
Passes | ||
ProfileData | ||
Remarks | ||
Support | ||
TableGen | ||
Target | ||
TextAPI | ||
Transforms | ||
XRay | ||
tools | ||
CMakeLists.txt | ||
unittest.cfg.in |