New ThreadSanitizer runtime (v3)

[Dmitry Vyukov <dvyukov@google.com>]

Hi gcc developers,

I wanted to give heads up regarding a significant re-design of the
ThreadSanitizer runtime:
https://reviews.llvm.org/D112603
Currently it's submitted:
https://github.com/llvm/llvm-project/commit/1784fe0532a69ead17793bced060a9bf9d232027
but can well be rolled back if too many buildbots fail, but should be
submitted again soon anyway.

It was extensively tested and lots of bugs were fixed, but it's still
possible it will cause some issues just because of the size of the
change and OS/arch sensitivity.

For a wide range of real programs it provides 20%-4x speedup on x86_64
and 20-40% memory consumption reduction.

One issue that will come up with gcc is the use of the new
disable_sanitizer_instrumentation attribute in tests:
https://clang.llvm.org/docs/AttributeReference.html#disable-sanitizer-instrumentation
e.g.:
https://github.com/llvm/llvm-project/blob/1784fe0532a69ead17793bced060a9bf9d232027/compiler-rt/test/tsan/java_symbolization.cpp#L5
ThreadSanitizer is now more picky about recursing from runtime
callbacks back into runtime.
You may either disable these tests, or move callbacks into
non-instrumented files (though, will require forking tests), or
implement the attribute.
Some uses of the disable_sanitizer_instrumentation attribute were also
discussed in the Linux kernel context. KMSAN will use it and kernel
noinstr functions could use it, though currently noinstr functions are
post-processed with kernel's objtool, which nops any sanitizer
callbacks. The objtool approach will continue to work, so it's not
that the attribute is mandated.