aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Frontend/CompilerInvocation.cpp
diff options
context:
space:
mode:
authorNikita Popov <nikita.ppv@gmail.com>2021-07-21 22:34:28 +0200
committerNikita Popov <nikita.ppv@gmail.com>2021-07-26 15:01:00 +0200
commitffb3277b0036909a8e622d5758a1e2850eabfd19 (patch)
tree66859d9e07c79923bd9d3705742a98304ed07ac7 /clang/lib/Frontend/CompilerInvocation.cpp
parente484e1ae03325823c469684d7d1532f2aadbe98d (diff)
downloadllvm-ffb3277b0036909a8e622d5758a1e2850eabfd19.zip
llvm-ffb3277b0036909a8e622d5758a1e2850eabfd19.tar.gz
llvm-ffb3277b0036909a8e622d5758a1e2850eabfd19.tar.bz2
[SimplifyCFG] Improve store speculation check
isSafeToSpeculateStore() looks for a preceding store to the same location to make sure that introducing a new store of the same value is safe. It currently bails on intervening mayHaveSideEffect() instructions. However, I believe just checking mayWriteToMemory() is sufficient there -- we just need to make sure that we know which value was stored, we don't care if we can unwind in the meantime. While looking into this, I started having some doubts about the correctness of the transform with regard to thread safety. While we don't try to hoist non-simple stores, I believe we also need to make sure that the preceding store is simple as well. Otherwise we could introduce a spurious non-atomic write after an atomic write -- under our memory model this would result in a subsequent undef atomic read, even if the second write stores the same value as the first. Example: https://alive2.llvm.org/ce/z/q_3YAL Differential Revision: https://reviews.llvm.org/D106742
Diffstat (limited to 'clang/lib/Frontend/CompilerInvocation.cpp')
0 files changed, 0 insertions, 0 deletions