diff options
author | Nikita Popov <nikita.ppv@gmail.com> | 2021-07-21 22:34:28 +0200 |
---|---|---|
committer | Nikita Popov <nikita.ppv@gmail.com> | 2021-07-26 15:01:00 +0200 |
commit | ffb3277b0036909a8e622d5758a1e2850eabfd19 (patch) | |
tree | 66859d9e07c79923bd9d3705742a98304ed07ac7 /clang/lib/Frontend/CompilerInvocation.cpp | |
parent | e484e1ae03325823c469684d7d1532f2aadbe98d (diff) | |
download | llvm-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