Revert "tsan: model atomic read for failing CAS"

https://lab.llvm.org/buildbot/#/builders/70/builds/21206 hangs.

This reverts commit 2fec52a40261ecab7fc621184159f464c67dcfa4.

tsan: model atomic read for failing CAS

See the added test and https://github.com/google/sanitizers/issues/1520
for the description of the problem.
The standard says that failing CAS is a memory loa

tsan: model atomic read for failing CAS

See the added test and https://github.com/google/sanitizers/issues/1520
for the description of the problem.
The standard says that failing CAS is a memory load only,
model it as such to avoid false positives.

Reviewed By: melver

Differential Revision: https://reviews.llvm.org/D124507

show more ...

tsan: new runtime (v3)

This change switches tsan to the new runtime which features:
- 2x smaller shadow memory (2x of app memory)
- faster fully vectorized race detection
- small fixed-size vecto

tsan: new runtime (v3)

This change switches tsan to the new runtime which features:
- 2x smaller shadow memory (2x of app memory)
- faster fully vectorized race detection
- small fixed-size vector clocks (512b)
- fast vectorized vector clock operations
- unlimited number of alive threads/goroutimes

Depends on D112602.

Reviewed By: melver

Differential Revision: https://reviews.llvm.org/D112603

show more ...

Revert "tsan: new runtime (v3)"

This reverts commit 5a33e412815b8847610425a2a3b86d2c7c313b71 becuase it
breaks LLDB.

https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/39208/

tsan: new runtime (v3)

This change switches tsan to the new runtime which features:
- 2x smaller shadow memory (2x of app memory)
- faster fully vectorized race detection
- small fixed-size vecto

tsan: new runtime (v3)

This change switches tsan to the new runtime which features:
- 2x smaller shadow memory (2x of app memory)
- faster fully vectorized race detection
- small fixed-size vector clocks (512b)
- fast vectorized vector clock operations
- unlimited number of alive threads/goroutimes

Depends on D112602.

Reviewed By: melver

Differential Revision: https://reviews.llvm.org/D112603

show more ...

Revert "tsan: new runtime (v3)"

This reverts commit 66d4ce7e26a5ab00f7e4946b6e1bac8f805010fa.

Chromium tests started failing:
https://bugs.chromium.org/p/chromium/issues/detail?id=1275581

tsan: new runtime (v3)

This change switches tsan to the new runtime which features:
- 2x smaller shadow memory (2x of app memory)
- faster fully vectorized race detection
- small fixed-size vecto

tsan: new runtime (v3)

This change switches tsan to the new runtime which features:
- 2x smaller shadow memory (2x of app memory)
- faster fully vectorized race detection
- small fixed-size vector clocks (512b)
- fast vectorized vector clock operations
- unlimited number of alive threads/goroutimes

Depends on D112602.

Reviewed By: melver

Differential Revision: https://reviews.llvm.org/D112603

show more ...

Revert "tsan: new runtime (v3)"

This reverts commit ebd47b0fb78fa11758da6ffcd3e6b415cbb8fa28.
This was causing unexpected behavior in programs.

tsan: new runtime (v3)

This change switches tsan to the new runtime which features:
- 2x smaller shadow memory (2x of app memory)
- faster fully vectorized race detection
- small fixed-size vecto

tsan: new runtime (v3)

This change switches tsan to the new runtime which features:
- 2x smaller shadow memory (2x of app memory)
- faster fully vectorized race detection
- small fixed-size vector clocks (512b)
- fast vectorized vector clock operations
- unlimited number of alive threads/goroutimes

Differential Revision: https://reviews.llvm.org/D112603

show more ...

Revert "tsan: new runtime (v3)"

Summary:
This reverts commit 1784fe0532a69ead17793bced060a9bf9d232027.

Broke some bots:
https://lab.llvm.org/buildbot#builders/57/builds/12365
http://green.lab.llvm.

Revert "tsan: new runtime (v3)"

Summary:
This reverts commit 1784fe0532a69ead17793bced060a9bf9d232027.

Broke some bots:
https://lab.llvm.org/buildbot#builders/57/builds/12365
http://green.lab.llvm.org/green/job/clang-stage1-RA/25658/

Reviewers: vitalybuka, melver

Subscribers:

show more ...

tsan: new runtime (v3)

This change switches tsan to the new runtime which features:
- 2x smaller shadow memory (2x of app memory)
- faster fully vectorized race detection
- small fixed-size vecto

tsan: new runtime (v3)

This change switches tsan to the new runtime which features:
- 2x smaller shadow memory (2x of app memory)
- faster fully vectorized race detection
- small fixed-size vector clocks (512b)
- fast vectorized vector clock operations
- unlimited number of alive threads/goroutimes

Depends on D112602.

Reviewed By: melver

Differential Revision: https://reviews.llvm.org/D112603

show more ...

Revert "tsan: new runtime (v3)"

Summary:
This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b.
There is a number of bot failures:
http://45.33.8.238/mac/38755/step_4.txt
https://green.lab.ll

Revert "tsan: new runtime (v3)"

Summary:
This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b.
There is a number of bot failures:
http://45.33.8.238/mac/38755/step_4.txt
https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c

Reviewers: vitalybuka, melver

Subscribers:

show more ...

tsan: new runtime (v3)

This change switches tsan to the new runtime which features:
- 2x smaller shadow memory (2x of app memory)
- faster fully vectorized race detection
- small fixed-size vecto

tsan: new runtime (v3)

This change switches tsan to the new runtime which features:
- 2x smaller shadow memory (2x of app memory)
- faster fully vectorized race detection
- small fixed-size vector clocks (512b)
- fast vectorized vector clock operations
- unlimited number of alive threads/goroutimes

Depends on D112602.

Reviewed By: melver

Differential Revision: https://reviews.llvm.org/D112603

show more ...

tsan: use DCHECK instead of CHECK in atomic functions

Atomic functions are semi-hot in profiles.
The CHECKs verify values passed by compiler
and they never fired, so replace them with DCHECKs.

Revi

tsan: use DCHECK instead of CHECK in atomic functions

Atomic functions are semi-hot in profiles.
The CHECKs verify values passed by compiler
and they never fired, so replace them with DCHECKs.

Reviewed By: vitalybuka, melver

Differential Revision: https://reviews.llvm.org/D107373

show more ...

tsan: new MemoryAccess interface

Currently we have MemoryAccess function that accepts
"bool kAccessIsWrite, bool kIsAtomic" and 4 wrappers:
MemoryRead/MemoryWrite/MemoryReadAtomic/MemoryWriteAtomic.

tsan: new MemoryAccess interface

Currently we have MemoryAccess function that accepts
"bool kAccessIsWrite, bool kIsAtomic" and 4 wrappers:
MemoryRead/MemoryWrite/MemoryReadAtomic/MemoryWriteAtomic.

Such scheme with bool flags is not particularly scalable/extendable.
Because of that we did not have Read/Write wrappers for UnalignedMemoryAccess,
and "true, false" or "false, true" at call sites is not very readable.

Moreover, the new tsan runtime will introduce more flags
(e.g. move "freed" and "vptr access" to memory acccess flags).
We can't have 16 wrappers and each flag also takes whole
64-bit register for non-inlined calls.

Introduce AccessType enum that contains bit mask of
read/write, atomic/non-atomic, and later free/non-free,
vptr/non-vptr.
Such scheme is more scalable, more readble, more efficient
(don't consume multiple registers for these flags during calls)
and allows to cover unaligned and range variations of memory
access functions as well.

Also switch from size log to just size.
The new tsan runtime won't have the limitation of supporting
only 1/2/4/8 access sizes, so we don't need the logarithms.

Also add an inline thunk that converts the new interface to the old one.
For inlined calls it should not add any overhead because
all flags/size can be computed as compile time.

Reviewed By: vitalybuka, melver

Differential Revision: https://reviews.llvm.org/D107276

show more ...

tsan: don't save creation stack for some sync objects

Currently we save the creation stack for sync objects always.
But it's not needed to some sync objects, most notably atomics.
We simply don't us

tsan: don't save creation stack for some sync objects

Currently we save the creation stack for sync objects always.
But it's not needed to some sync objects, most notably atomics.
We simply don't use atomic creation stack anywhere.
Allow callers to control saving of the creation stack
and don't save it for atomics.

Depends on D107257.

Reviewed By: melver

Differential Revision: https://reviews.llvm.org/D107258

show more ...

tsan: refactor MetaMap::GetAndLock interface

Don't lock the sync object inside of MetaMap methods.
This has several advantages:
- the new interface does not confuse thread-safety analysis
so we

tsan: refactor MetaMap::GetAndLock interface

Don't lock the sync object inside of MetaMap methods.
This has several advantages:
- the new interface does not confuse thread-safety analysis
so we can remove a bunch of NO_THREAD_SAFETY_ANALYSIS attributes
- this allows use of scoped lock objects
- this allows more flexibility, e.g. locking some other mutex
between searching and locking the sync object
Also prefix the methods with GetSync to be consistent with GetBlock method.
Also make interface wrappers inlinable, otherwise we either end up with
2 copies of the method, or with an additional call.

Reviewed By: melver

Differential Revision: https://reviews.llvm.org/D107256

show more ...

tsan: remove /**/ at the of multi-line macros

Prefer code readability over writeability.

Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D106982

tsan: don't print __tsan_atomic* functions in report stacks

Currently __tsan_atomic* functions do FuncEntry/Exit using caller PC
and then use current PC (pointing to __tsan_atomic* itself) during
me

tsan: don't print __tsan_atomic* functions in report stacks

Currently __tsan_atomic* functions do FuncEntry/Exit using caller PC
and then use current PC (pointing to __tsan_atomic* itself) during
memory access handling. As the result the top function in reports
involving atomics is __tsan_atomic* and the next frame points to user code.

Remove FuncEntry/Exit in atomic functions and use caller PC
during memory access handling. This removes __tsan_atomic*
from the top of report stacks, so that they point right to user code.

The motivation for this is performance.
Some atomic operations are very hot (mostly loads),
so removing FuncEntry/Exit is beneficial.
This also reduces thread trace consumption (1 event instead of 3).

__tsan_atomic* at the top of the stack is not necessary
and does not add any new information. We already say
"atomic write of size 4", "__tsan_atomic32_store" does not add
anything new.

It also makes reports consistent between atomic and non-atomic
accesses. For normal accesses we say "previous write" and point
to user code; for atomics we say "previous atomic write" and now
also point to user code.

Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D106966

show more ...

tsan: disable thread safety analysis in more functions

In preparation for replacing tsan Mutex with sanitizer_common Mutex,
which has thread-safety annotations. Thread safety analysis does not
under

tsan: disable thread safety analysis in more functions

In preparation for replacing tsan Mutex with sanitizer_common Mutex,
which has thread-safety annotations. Thread safety analysis does not
understand MetaMap::GetAndLock which returns a locked sync object.

Reviewed By: vitalybuka, melver

Differential Revision: https://reviews.llvm.org/D106548

show more ...

tsan: remove the stats subsystem

I don't think the stat subsystem was ever used since tsan
development in 2012. But it adds lots of code and this
effectively dead code needs to be updated if the run

tsan: remove the stats subsystem

I don't think the stat subsystem was ever used since tsan
development in 2012. But it adds lots of code and this
effectively dead code needs to be updated if the runtime
code changes, which adds maintanance cost for no benefit.
Normal profiler usually gives enough info and that info
is more trustworthy.
Remove the stats subsystem.

Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D106276

show more ...

[TSAN] Honor failure memory orders in AtomicCAS

LLVM has lifted strong requirements for CAS failure memory orders in 431e3138a and 819e0d105e84.

Add support for honoring them in `AtomicCAS`.

https

[TSAN] Honor failure memory orders in AtomicCAS

LLVM has lifted strong requirements for CAS failure memory orders in 431e3138a and 819e0d105e84.

Add support for honoring them in `AtomicCAS`.

https://github.com/google/sanitizers/issues/970

Differential Revision: https://reviews.llvm.org/D99434

show more ...

Remove NOLINTs from compiler-rt

llvm-svn: 371687

compiler-rt: Rename .cc file in lib/tsan/rtl to .cpp

Like r367463, but for tsan/rtl.

llvm-svn: 367564