aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Basic/Module.cpp
diff options
context:
space:
mode:
authorVedant Kumar <vsk@apple.com>2020-01-28 17:03:39 -0800
committerVedant Kumar <vsk@apple.com>2020-01-28 17:18:01 -0800
commit8359511c62b727e360f93d9f5dab5893548227c8 (patch)
treeae5cd374798ac40a2fc22bbd3535e4800c9cd757 /clang/lib/Basic/Module.cpp
parent2d92336db0087ad295401865d7749d4d1cfe4846 (diff)
downloadllvm-8359511c62b727e360f93d9f5dab5893548227c8.zip
llvm-8359511c62b727e360f93d9f5dab5893548227c8.tar.gz
llvm-8359511c62b727e360f93d9f5dab5893548227c8.tar.bz2
[CodeExtractor] Remove stale llvm.assume calls from extracted region
During extraction, stale llvm.assume handles may be retained in the original function. The setup is: 1) CodeExtractor unregisters assumptions in the blocks that are to be extracted. 2) Extraction happens. There are now two functions: f1 and f1.extracted. 3) Leftover assumptions in f1 (/not/ removed as they were not in the set of blocks to be extracted) now have affected-value llvm.assume handles in f1.extracted. When assumptions for a value used in f1 are looked up, ValueTracking can assert as some of the handles are in the wrong function. To fix this, simply erase the llvm.assume calls in the extracted function. Alternatives include flushing the assumption cache in the original function, or walking all values used in the original function to prune stale affected-value handles. Both seem more expensive. Testing: check-llvm, LNT run with -mllvm -hot-cold-split enabled rdar://58460728
Diffstat (limited to 'clang/lib/Basic/Module.cpp')
0 files changed, 0 insertions, 0 deletions