[PATCH] D99434: [TSAN] Honor failure memory orders in AtomicCAS

[Bruno Cardoso Lopes via Phabricator via llvm-commits]

bruno updated this revision to Diff 344174.
bruno added a comment.

Thank you @dvyukov for another round of reviews! A have more questions for you.

Yes, fmo can be `seq_cst`. Take `mo == mo_release` and `fmo == mo_seq_cst`, we'd be acquiring the mutex with `write_lock`, which is fine under success. However, during failure, I don't see another solution besides `s->mtx.Unlock()` before honoring and calling `GetOrCreateAndLock` again to obtain the lock with `write_lock = false`. Since you said in a previous review that it would be too expensive to lock again, what do you suggest as an alternative? I wonder whether my concern is even legit (?) given that the `mo == mo_release` and `fmo == mo_seq_cst` in the testcase works regardless of this lock/unlock dance.

It's also the case that the current added testcase takes ~20s on a fast linux machine, which seems way over the bar, I haven't tried to make it better yet, but (at least) diminishing the mo/fmo combinations should help, other ideas?

In the meantime, I've updated the patch with that approach.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D99434/new/

https://reviews.llvm.org/D99434

Files:
  compiler-rt/lib/tsan/rtl/tsan_interface_atomic.cpp
  compiler-rt/test/tsan/compare_exchange.cpp
  llvm/test/Instrumentation/ThreadSanitizer/atomic.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D99434.344174.patch
Type: text/x-patch
Size: 20859 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210510/68b10b28/attachment.bin>