aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Transforms/Utils/BasicBlockUtils.cpp
diff options
context:
space:
mode:
authorAaron Puchert <aaron.puchert@sap.com>2021-04-06 22:29:44 +0200
committerAaron Puchert <aaron.puchert@sap.com>2021-04-06 22:29:48 +0200
commitdfec26b186d2f0c80f2b70901b7cc5747f5b377c (patch)
tree462f5a3e29e11f40528079e035518c3788c7c1ab /llvm/lib/Transforms/Utils/BasicBlockUtils.cpp
parent4bf8985f4fb1411831505a4b38265eb517783dc7 (diff)
downloadllvm-dfec26b186d2f0c80f2b70901b7cc5747f5b377c.zip
llvm-dfec26b186d2f0c80f2b70901b7cc5747f5b377c.tar.gz
llvm-dfec26b186d2f0c80f2b70901b7cc5747f5b377c.tar.bz2
Thread safety analysis: Don't warn about managed locks on join points
We already did so for scoped locks acquired in the constructor, this change extends the treatment to deferred locks and scoped unlocking, so locks acquired outside of the constructor. Obviously this makes things more consistent. Originally I thought this was a bad idea, because obviously it introduces false negatives when it comes to double locking, but these are typically easily found in tests, and the primary goal of the Thread safety analysis is not to find double locks but race conditions. Since the scoped lock will release the mutex anyway when the scope ends, the inconsistent state is just temporary and probably fine. Reviewed By: delesley Differential Revision: https://reviews.llvm.org/D98747
Diffstat (limited to 'llvm/lib/Transforms/Utils/BasicBlockUtils.cpp')
0 files changed, 0 insertions, 0 deletions