[PATCH] D17833: [tsan] Add support for pointer typed atomic stores, loads, and cmpxchg

Anna Zaks via llvm-commits llvm-commits at lists.llvm.org
Fri Mar 4 11:50:07 PST 2016


zaks.anna added a comment.

> How did it work without these casts all that time?.. Is it the case that programs that used atomic<void*> failed to compile?


Looks like clang's IRGen inserts the bit casts in this case. (It's possible that it was written that way because the atomic loads and stores emission went through the same interface as emission for other atomics that were restricted to int values.) However, other front ends (such as Swift) do not insert the bit casts. Since these IR instructions are defined to work with pointer types, LLVM should support them even if the clang IRGen does not emit such code.

The cmpxchg was extended to allow pointer type operands on Feb 19th (see r261281) .


================
Comment at: test/Instrumentation/ThreadSanitizer/atomic.ll:1196
@@ +1195,3 @@
+; CHECK: bitcast i8** %{{.+}} to i64*
+; CHECK-NEXT: call i64 @__tsan_atomic64_load(i64* %{{.+}}, i32 5), !dbg
+; CHECK-NEXT: inttoptr i64 %{{.+}} to i8*
----------------
dvyukov wrote:
> Are you sure that we don't run these tests on 32-bit platforms? It will fail on 32-bit platform, right?
I believe this will not fail since the test specifies the target layout, where pointers are 64 bits long:
     target datalayout = "e-p:64:64:64-...

"p[n]:<size>:<abi>:<pref>
  This specifies the size of a pointer and its <abi> and <pref>erred alignments for address space n. All sizes are in bits.  
  The address space, n, is optional, and if not specified, denotes the default address space 0. The value of n must be in the range [1,2^23)."



http://reviews.llvm.org/D17833





More information about the llvm-commits mailing list