aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Transforms/Utils/LoopUtils.cpp
diff options
context:
space:
mode:
authorLogikable <seanluchen@google.com>2024-06-04 11:19:34 -0700
committerGitHub <noreply@github.com>2024-06-04 11:19:34 -0700
commitb62b7a42bbee4a3bbf9094808f460fdc9c119bd7 (patch)
treeae7b8de7f273aa9c104993845ff80c95d1d0e160 /llvm/lib/Transforms/Utils/LoopUtils.cpp
parentc1654c38e8b82a075613fd60f19a179b1c7df2a2 (diff)
downloadllvm-b62b7a42bbee4a3bbf9094808f460fdc9c119bd7.zip
llvm-b62b7a42bbee4a3bbf9094808f460fdc9c119bd7.tar.gz
llvm-b62b7a42bbee4a3bbf9094808f460fdc9c119bd7.tar.bz2
[compiler-rt][builtins] Switch libatomic locks to pthread_mutex_t (#94374)
When an uninstrumented libatomic is used with a TSan instrumented memcpy, TSan may report a data race in circumstances where writes are arguably safe. This occurs because __atomic_compare_exchange won't be instrumented in an uninstrumented libatomic, so TSan doesn't know that the subsequent memcpy is race-free. On the other hand, pthread_mutex_(un)lock will be intercepted by TSan, meaning an uninstrumented libatomic will not report this false-positive. pthread_mutexes also may try a number of different strategies to acquire the lock, which may bound the amount of time a thread has to wait for a lock during contention. While pthread_mutex_lock has a larger overhead (due to the function call and some dispatching), a dispatch to libatomic already predicates a lack of performance guarantees.
Diffstat (limited to 'llvm/lib/Transforms/Utils/LoopUtils.cpp')
0 files changed, 0 insertions, 0 deletions