diff options
author | Logikable <seanluchen@google.com> | 2024-06-04 11:19:34 -0700 |
---|---|---|
committer | GitHub <noreply@github.com> | 2024-06-04 11:19:34 -0700 |
commit | b62b7a42bbee4a3bbf9094808f460fdc9c119bd7 (patch) | |
tree | ae7b8de7f273aa9c104993845ff80c95d1d0e160 /llvm/lib/Transforms/Utils/LoopUtils.cpp | |
parent | c1654c38e8b82a075613fd60f19a179b1c7df2a2 (diff) | |
download | llvm-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