2012-02-14 06:50:51 +08:00
|
|
|
//===-- ThreadSanitizer.cpp - race detector -------------------------------===//
|
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2012-02-14 06:50:51 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file is a part of ThreadSanitizer, a race detector.
|
|
|
|
//
|
|
|
|
// The tool is under development, for the details about previous versions see
|
|
|
|
// http://code.google.com/p/data-race-test
|
|
|
|
//
|
|
|
|
// The instrumentation phase is quite simple:
|
|
|
|
// - Insert calls to run-time library before every memory access.
|
|
|
|
// - Optimizations may apply to avoid instrumenting some of the accesses.
|
|
|
|
// - Insert calls at function entry/exit.
|
|
|
|
// The rest is handled by the run-time library.
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2019-01-16 17:28:01 +08:00
|
|
|
#include "llvm/Transforms/Instrumentation/ThreadSanitizer.h"
|
[TSan] Add option for emitting compound read-write instrumentation
This adds option -tsan-compound-read-before-write to emit different
instrumentation for the write if the read before that write is omitted
from instrumentation. The default TSan runtime currently does not
support the different instrumentation, and the option is disabled by
default.
Alternative runtimes, such as the Kernel Concurrency Sanitizer (KCSAN)
can make use of the feature. Indeed, the initial motivation is for use
in KCSAN as it was determined that due to the Linux kernel having a
large number of unaddressed data races, it makes sense to improve
performance and reporting by distinguishing compounded operations. E.g.
the compounded instrumentation is typically emitted for compound
operations such as ++, +=, |=, etc. By emitting different reports, such
data races can easily be noticed, and also automatically bucketed
differently by CI systems.
Reviewed By: dvyukov, glider
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83867
2020-07-17 14:53:56 +08:00
|
|
|
#include "llvm/ADT/DenseMap.h"
|
|
|
|
#include "llvm/ADT/Optional.h"
|
2012-12-04 00:50:05 +08:00
|
|
|
#include "llvm/ADT/SmallString.h"
|
|
|
|
#include "llvm/ADT/SmallVector.h"
|
|
|
|
#include "llvm/ADT/Statistic.h"
|
|
|
|
#include "llvm/ADT/StringExtras.h"
|
2015-03-24 03:32:43 +08:00
|
|
|
#include "llvm/Analysis/CaptureTracking.h"
|
2016-06-18 18:10:37 +08:00
|
|
|
#include "llvm/Analysis/TargetLibraryInfo.h"
|
2015-03-24 03:32:43 +08:00
|
|
|
#include "llvm/Analysis/ValueTracking.h"
|
2013-01-02 19:36:10 +08:00
|
|
|
#include "llvm/IR/DataLayout.h"
|
|
|
|
#include "llvm/IR/Function.h"
|
|
|
|
#include "llvm/IR/IRBuilder.h"
|
2021-07-10 00:24:59 +08:00
|
|
|
#include "llvm/IR/Instructions.h"
|
2013-03-28 19:21:13 +08:00
|
|
|
#include "llvm/IR/IntrinsicInst.h"
|
2013-01-02 19:36:10 +08:00
|
|
|
#include "llvm/IR/Intrinsics.h"
|
|
|
|
#include "llvm/IR/LLVMContext.h"
|
|
|
|
#include "llvm/IR/Metadata.h"
|
|
|
|
#include "llvm/IR/Module.h"
|
|
|
|
#include "llvm/IR/Type.h"
|
Sink all InitializePasses.h includes
This file lists every pass in LLVM, and is included by Pass.h, which is
very popular. Every time we add, remove, or rename a pass in LLVM, it
caused lots of recompilation.
I found this fact by looking at this table, which is sorted by the
number of times a file was changed over the last 100,000 git commits
multiplied by the number of object files that depend on it in the
current checkout:
recompiles touches affected_files header
342380 95 3604 llvm/include/llvm/ADT/STLExtras.h
314730 234 1345 llvm/include/llvm/InitializePasses.h
307036 118 2602 llvm/include/llvm/ADT/APInt.h
213049 59 3611 llvm/include/llvm/Support/MathExtras.h
170422 47 3626 llvm/include/llvm/Support/Compiler.h
162225 45 3605 llvm/include/llvm/ADT/Optional.h
158319 63 2513 llvm/include/llvm/ADT/Triple.h
140322 39 3598 llvm/include/llvm/ADT/StringRef.h
137647 59 2333 llvm/include/llvm/Support/Error.h
131619 73 1803 llvm/include/llvm/Support/FileSystem.h
Before this change, touching InitializePasses.h would cause 1345 files
to recompile. After this change, touching it only causes 550 compiles in
an incremental rebuild.
Reviewers: bkramer, asbirlea, bollu, jdoerfert
Differential Revision: https://reviews.llvm.org/D70211
2019-11-14 05:15:01 +08:00
|
|
|
#include "llvm/InitializePasses.h"
|
2016-03-30 07:19:40 +08:00
|
|
|
#include "llvm/ProfileData/InstrProf.h"
|
2012-03-15 07:33:24 +08:00
|
|
|
#include "llvm/Support/CommandLine.h"
|
2012-02-14 06:50:51 +08:00
|
|
|
#include "llvm/Support/Debug.h"
|
|
|
|
#include "llvm/Support/MathExtras.h"
|
2012-03-27 01:35:03 +08:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2012-04-27 15:31:53 +08:00
|
|
|
#include "llvm/Transforms/Utils/BasicBlockUtils.h"
|
2016-11-15 05:41:13 +08:00
|
|
|
#include "llvm/Transforms/Utils/EscapeEnumerator.h"
|
Sink all InitializePasses.h includes
This file lists every pass in LLVM, and is included by Pass.h, which is
very popular. Every time we add, remove, or rename a pass in LLVM, it
caused lots of recompilation.
I found this fact by looking at this table, which is sorted by the
number of times a file was changed over the last 100,000 git commits
multiplied by the number of object files that depend on it in the
current checkout:
recompiles touches affected_files header
342380 95 3604 llvm/include/llvm/ADT/STLExtras.h
314730 234 1345 llvm/include/llvm/InitializePasses.h
307036 118 2602 llvm/include/llvm/ADT/APInt.h
213049 59 3611 llvm/include/llvm/Support/MathExtras.h
170422 47 3626 llvm/include/llvm/Support/Compiler.h
162225 45 3605 llvm/include/llvm/ADT/Optional.h
158319 63 2513 llvm/include/llvm/ADT/Triple.h
140322 39 3598 llvm/include/llvm/ADT/StringRef.h
137647 59 2333 llvm/include/llvm/Support/Error.h
131619 73 1803 llvm/include/llvm/Support/FileSystem.h
Before this change, touching InitializePasses.h would cause 1345 files
to recompile. After this change, touching it only causes 550 compiles in
an incremental rebuild.
Reviewers: bkramer, asbirlea, bollu, jdoerfert
Differential Revision: https://reviews.llvm.org/D70211
2019-11-14 05:15:01 +08:00
|
|
|
#include "llvm/Transforms/Utils/Local.h"
|
2012-02-14 06:50:51 +08:00
|
|
|
#include "llvm/Transforms/Utils/ModuleUtils.h"
|
|
|
|
|
|
|
|
using namespace llvm;
|
|
|
|
|
2014-04-22 10:55:47 +08:00
|
|
|
#define DEBUG_TYPE "tsan"
|
|
|
|
|
[TSan] Add option for emitting compound read-write instrumentation
This adds option -tsan-compound-read-before-write to emit different
instrumentation for the write if the read before that write is omitted
from instrumentation. The default TSan runtime currently does not
support the different instrumentation, and the option is disabled by
default.
Alternative runtimes, such as the Kernel Concurrency Sanitizer (KCSAN)
can make use of the feature. Indeed, the initial motivation is for use
in KCSAN as it was determined that due to the Linux kernel having a
large number of unaddressed data races, it makes sense to improve
performance and reporting by distinguishing compounded operations. E.g.
the compounded instrumentation is typically emitted for compound
operations such as ++, +=, |=, etc. By emitting different reports, such
data races can easily be noticed, and also automatically bucketed
differently by CI systems.
Reviewed By: dvyukov, glider
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83867
2020-07-17 14:53:56 +08:00
|
|
|
static cl::opt<bool> ClInstrumentMemoryAccesses(
|
2012-10-04 13:28:50 +08:00
|
|
|
"tsan-instrument-memory-accesses", cl::init(true),
|
|
|
|
cl::desc("Instrument memory accesses"), cl::Hidden);
|
[TSan] Add option for emitting compound read-write instrumentation
This adds option -tsan-compound-read-before-write to emit different
instrumentation for the write if the read before that write is omitted
from instrumentation. The default TSan runtime currently does not
support the different instrumentation, and the option is disabled by
default.
Alternative runtimes, such as the Kernel Concurrency Sanitizer (KCSAN)
can make use of the feature. Indeed, the initial motivation is for use
in KCSAN as it was determined that due to the Linux kernel having a
large number of unaddressed data races, it makes sense to improve
performance and reporting by distinguishing compounded operations. E.g.
the compounded instrumentation is typically emitted for compound
operations such as ++, +=, |=, etc. By emitting different reports, such
data races can easily be noticed, and also automatically bucketed
differently by CI systems.
Reviewed By: dvyukov, glider
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83867
2020-07-17 14:53:56 +08:00
|
|
|
static cl::opt<bool>
|
|
|
|
ClInstrumentFuncEntryExit("tsan-instrument-func-entry-exit", cl::init(true),
|
|
|
|
cl::desc("Instrument function entry and exit"),
|
|
|
|
cl::Hidden);
|
|
|
|
static cl::opt<bool> ClHandleCxxExceptions(
|
2016-11-15 05:41:13 +08:00
|
|
|
"tsan-handle-cxx-exceptions", cl::init(true),
|
|
|
|
cl::desc("Handle C++ exceptions (insert cleanup blocks for unwinding)"),
|
|
|
|
cl::Hidden);
|
[TSan] Add option for emitting compound read-write instrumentation
This adds option -tsan-compound-read-before-write to emit different
instrumentation for the write if the read before that write is omitted
from instrumentation. The default TSan runtime currently does not
support the different instrumentation, and the option is disabled by
default.
Alternative runtimes, such as the Kernel Concurrency Sanitizer (KCSAN)
can make use of the feature. Indeed, the initial motivation is for use
in KCSAN as it was determined that due to the Linux kernel having a
large number of unaddressed data races, it makes sense to improve
performance and reporting by distinguishing compounded operations. E.g.
the compounded instrumentation is typically emitted for compound
operations such as ++, +=, |=, etc. By emitting different reports, such
data races can easily be noticed, and also automatically bucketed
differently by CI systems.
Reviewed By: dvyukov, glider
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83867
2020-07-17 14:53:56 +08:00
|
|
|
static cl::opt<bool> ClInstrumentAtomics("tsan-instrument-atomics",
|
|
|
|
cl::init(true),
|
|
|
|
cl::desc("Instrument atomics"),
|
|
|
|
cl::Hidden);
|
|
|
|
static cl::opt<bool> ClInstrumentMemIntrinsics(
|
2013-03-28 19:21:13 +08:00
|
|
|
"tsan-instrument-memintrinsics", cl::init(true),
|
|
|
|
cl::desc("Instrument memintrinsics (memset/memcpy/memmove)"), cl::Hidden);
|
[TSan] Add option for emitting compound read-write instrumentation
This adds option -tsan-compound-read-before-write to emit different
instrumentation for the write if the read before that write is omitted
from instrumentation. The default TSan runtime currently does not
support the different instrumentation, and the option is disabled by
default.
Alternative runtimes, such as the Kernel Concurrency Sanitizer (KCSAN)
can make use of the feature. Indeed, the initial motivation is for use
in KCSAN as it was determined that due to the Linux kernel having a
large number of unaddressed data races, it makes sense to improve
performance and reporting by distinguishing compounded operations. E.g.
the compounded instrumentation is typically emitted for compound
operations such as ++, +=, |=, etc. By emitting different reports, such
data races can easily be noticed, and also automatically bucketed
differently by CI systems.
Reviewed By: dvyukov, glider
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83867
2020-07-17 14:53:56 +08:00
|
|
|
static cl::opt<bool> ClDistinguishVolatile(
|
2020-04-22 22:01:33 +08:00
|
|
|
"tsan-distinguish-volatile", cl::init(false),
|
|
|
|
cl::desc("Emit special instrumentation for accesses to volatiles"),
|
|
|
|
cl::Hidden);
|
[TSan] Add option for emitting compound read-write instrumentation
This adds option -tsan-compound-read-before-write to emit different
instrumentation for the write if the read before that write is omitted
from instrumentation. The default TSan runtime currently does not
support the different instrumentation, and the option is disabled by
default.
Alternative runtimes, such as the Kernel Concurrency Sanitizer (KCSAN)
can make use of the feature. Indeed, the initial motivation is for use
in KCSAN as it was determined that due to the Linux kernel having a
large number of unaddressed data races, it makes sense to improve
performance and reporting by distinguishing compounded operations. E.g.
the compounded instrumentation is typically emitted for compound
operations such as ++, +=, |=, etc. By emitting different reports, such
data races can easily be noticed, and also automatically bucketed
differently by CI systems.
Reviewed By: dvyukov, glider
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83867
2020-07-17 14:53:56 +08:00
|
|
|
static cl::opt<bool> ClInstrumentReadBeforeWrite(
|
2020-05-15 20:14:18 +08:00
|
|
|
"tsan-instrument-read-before-write", cl::init(false),
|
|
|
|
cl::desc("Do not eliminate read instrumentation for read-before-writes"),
|
|
|
|
cl::Hidden);
|
[TSan] Add option for emitting compound read-write instrumentation
This adds option -tsan-compound-read-before-write to emit different
instrumentation for the write if the read before that write is omitted
from instrumentation. The default TSan runtime currently does not
support the different instrumentation, and the option is disabled by
default.
Alternative runtimes, such as the Kernel Concurrency Sanitizer (KCSAN)
can make use of the feature. Indeed, the initial motivation is for use
in KCSAN as it was determined that due to the Linux kernel having a
large number of unaddressed data races, it makes sense to improve
performance and reporting by distinguishing compounded operations. E.g.
the compounded instrumentation is typically emitted for compound
operations such as ++, +=, |=, etc. By emitting different reports, such
data races can easily be noticed, and also automatically bucketed
differently by CI systems.
Reviewed By: dvyukov, glider
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83867
2020-07-17 14:53:56 +08:00
|
|
|
static cl::opt<bool> ClCompoundReadBeforeWrite(
|
|
|
|
"tsan-compound-read-before-write", cl::init(false),
|
|
|
|
cl::desc("Emit special compound instrumentation for reads-before-writes"),
|
|
|
|
cl::Hidden);
|
2012-03-15 07:33:24 +08:00
|
|
|
|
2012-04-23 16:44:59 +08:00
|
|
|
STATISTIC(NumInstrumentedReads, "Number of instrumented reads");
|
|
|
|
STATISTIC(NumInstrumentedWrites, "Number of instrumented writes");
|
2012-08-30 21:47:13 +08:00
|
|
|
STATISTIC(NumOmittedReadsBeforeWrite,
|
2012-04-23 16:44:59 +08:00
|
|
|
"Number of reads ignored due to following writes");
|
|
|
|
STATISTIC(NumAccessesWithBadSize, "Number of accesses with bad size");
|
|
|
|
STATISTIC(NumInstrumentedVtableWrites, "Number of vtable ptr writes");
|
2013-03-22 16:51:22 +08:00
|
|
|
STATISTIC(NumInstrumentedVtableReads, "Number of vtable ptr reads");
|
2012-04-23 16:44:59 +08:00
|
|
|
STATISTIC(NumOmittedReadsFromConstantGlobals,
|
|
|
|
"Number of reads from constant globals");
|
|
|
|
STATISTIC(NumOmittedReadsFromVtable, "Number of vtable reads");
|
2015-02-12 17:55:28 +08:00
|
|
|
STATISTIC(NumOmittedNonCaptured, "Number of accesses ignored due to capturing");
|
2012-04-11 02:18:56 +08:00
|
|
|
|
2020-12-02 02:33:18 +08:00
|
|
|
const char kTsanModuleCtorName[] = "tsan.module_ctor";
|
|
|
|
const char kTsanInitName[] = "__tsan_init";
|
2015-05-08 05:41:23 +08:00
|
|
|
|
2012-02-14 06:50:51 +08:00
|
|
|
namespace {
|
2012-04-11 02:18:56 +08:00
|
|
|
|
2012-02-14 06:50:51 +08:00
|
|
|
/// ThreadSanitizer: instrument the code in module to find races.
|
2019-01-16 17:28:01 +08:00
|
|
|
///
|
|
|
|
/// Instantiating ThreadSanitizer inserts the tsan runtime library API function
|
|
|
|
/// declarations into the module if they don't exist already. Instantiating
|
|
|
|
/// ensures the __tsan_init function is in the list of global constructors for
|
|
|
|
/// the module.
|
|
|
|
struct ThreadSanitizer {
|
[TSan] Add option for emitting compound read-write instrumentation
This adds option -tsan-compound-read-before-write to emit different
instrumentation for the write if the read before that write is omitted
from instrumentation. The default TSan runtime currently does not
support the different instrumentation, and the option is disabled by
default.
Alternative runtimes, such as the Kernel Concurrency Sanitizer (KCSAN)
can make use of the feature. Indeed, the initial motivation is for use
in KCSAN as it was determined that due to the Linux kernel having a
large number of unaddressed data races, it makes sense to improve
performance and reporting by distinguishing compounded operations. E.g.
the compounded instrumentation is typically emitted for compound
operations such as ++, +=, |=, etc. By emitting different reports, such
data races can easily be noticed, and also automatically bucketed
differently by CI systems.
Reviewed By: dvyukov, glider
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83867
2020-07-17 14:53:56 +08:00
|
|
|
ThreadSanitizer() {
|
2021-11-24 02:22:21 +08:00
|
|
|
// Check options and warn user.
|
[TSan] Add option for emitting compound read-write instrumentation
This adds option -tsan-compound-read-before-write to emit different
instrumentation for the write if the read before that write is omitted
from instrumentation. The default TSan runtime currently does not
support the different instrumentation, and the option is disabled by
default.
Alternative runtimes, such as the Kernel Concurrency Sanitizer (KCSAN)
can make use of the feature. Indeed, the initial motivation is for use
in KCSAN as it was determined that due to the Linux kernel having a
large number of unaddressed data races, it makes sense to improve
performance and reporting by distinguishing compounded operations. E.g.
the compounded instrumentation is typically emitted for compound
operations such as ++, +=, |=, etc. By emitting different reports, such
data races can easily be noticed, and also automatically bucketed
differently by CI systems.
Reviewed By: dvyukov, glider
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83867
2020-07-17 14:53:56 +08:00
|
|
|
if (ClInstrumentReadBeforeWrite && ClCompoundReadBeforeWrite) {
|
|
|
|
errs()
|
|
|
|
<< "warning: Option -tsan-compound-read-before-write has no effect "
|
|
|
|
"when -tsan-instrument-read-before-write is set.\n";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-01-16 17:28:01 +08:00
|
|
|
bool sanitizeFunction(Function &F, const TargetLibraryInfo &TLI);
|
|
|
|
|
|
|
|
private:
|
[TSan] Add option for emitting compound read-write instrumentation
This adds option -tsan-compound-read-before-write to emit different
instrumentation for the write if the read before that write is omitted
from instrumentation. The default TSan runtime currently does not
support the different instrumentation, and the option is disabled by
default.
Alternative runtimes, such as the Kernel Concurrency Sanitizer (KCSAN)
can make use of the feature. Indeed, the initial motivation is for use
in KCSAN as it was determined that due to the Linux kernel having a
large number of unaddressed data races, it makes sense to improve
performance and reporting by distinguishing compounded operations. E.g.
the compounded instrumentation is typically emitted for compound
operations such as ++, +=, |=, etc. By emitting different reports, such
data races can easily be noticed, and also automatically bucketed
differently by CI systems.
Reviewed By: dvyukov, glider
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83867
2020-07-17 14:53:56 +08:00
|
|
|
// Internal Instruction wrapper that contains more information about the
|
|
|
|
// Instruction from prior analysis.
|
|
|
|
struct InstructionInfo {
|
|
|
|
// Instrumentation emitted for this instruction is for a compounded set of
|
|
|
|
// read and write operations in the same basic block.
|
|
|
|
static constexpr unsigned kCompoundRW = (1U << 0);
|
|
|
|
|
|
|
|
explicit InstructionInfo(Instruction *Inst) : Inst(Inst) {}
|
|
|
|
|
|
|
|
Instruction *Inst;
|
|
|
|
unsigned Flags = 0;
|
|
|
|
};
|
|
|
|
|
2019-10-11 16:47:03 +08:00
|
|
|
void initialize(Module &M);
|
[TSan] Add option for emitting compound read-write instrumentation
This adds option -tsan-compound-read-before-write to emit different
instrumentation for the write if the read before that write is omitted
from instrumentation. The default TSan runtime currently does not
support the different instrumentation, and the option is disabled by
default.
Alternative runtimes, such as the Kernel Concurrency Sanitizer (KCSAN)
can make use of the feature. Indeed, the initial motivation is for use
in KCSAN as it was determined that due to the Linux kernel having a
large number of unaddressed data races, it makes sense to improve
performance and reporting by distinguishing compounded operations. E.g.
the compounded instrumentation is typically emitted for compound
operations such as ++, +=, |=, etc. By emitting different reports, such
data races can easily be noticed, and also automatically bucketed
differently by CI systems.
Reviewed By: dvyukov, glider
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83867
2020-07-17 14:53:56 +08:00
|
|
|
bool instrumentLoadOrStore(const InstructionInfo &II, const DataLayout &DL);
|
2015-03-10 10:37:25 +08:00
|
|
|
bool instrumentAtomic(Instruction *I, const DataLayout &DL);
|
2013-03-28 19:21:13 +08:00
|
|
|
bool instrumentMemIntrinsic(Instruction *I);
|
2015-03-10 10:37:25 +08:00
|
|
|
void chooseInstructionsToInstrument(SmallVectorImpl<Instruction *> &Local,
|
[TSan] Add option for emitting compound read-write instrumentation
This adds option -tsan-compound-read-before-write to emit different
instrumentation for the write if the read before that write is omitted
from instrumentation. The default TSan runtime currently does not
support the different instrumentation, and the option is disabled by
default.
Alternative runtimes, such as the Kernel Concurrency Sanitizer (KCSAN)
can make use of the feature. Indeed, the initial motivation is for use
in KCSAN as it was determined that due to the Linux kernel having a
large number of unaddressed data races, it makes sense to improve
performance and reporting by distinguishing compounded operations. E.g.
the compounded instrumentation is typically emitted for compound
operations such as ++, +=, |=, etc. By emitting different reports, such
data races can easily be noticed, and also automatically bucketed
differently by CI systems.
Reviewed By: dvyukov, glider
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83867
2020-07-17 14:53:56 +08:00
|
|
|
SmallVectorImpl<InstructionInfo> &All,
|
2015-03-10 10:37:25 +08:00
|
|
|
const DataLayout &DL);
|
2012-04-11 06:29:17 +08:00
|
|
|
bool addrPointsToConstantData(Value *Addr);
|
2021-07-10 00:24:59 +08:00
|
|
|
int getMemoryAccessFuncIndex(Type *OrigTy, Value *Addr, const DataLayout &DL);
|
2016-11-15 05:41:13 +08:00
|
|
|
void InsertRuntimeIgnores(Function &F);
|
2012-04-11 02:18:56 +08:00
|
|
|
|
2013-03-28 19:21:13 +08:00
|
|
|
Type *IntptrTy;
|
[opaque pointer types] Add a FunctionCallee wrapper type, and use it.
Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.
Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.
Then:
- update the CallInst/InvokeInst instruction creation functions to
take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.
One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.
However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)
Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.
Differential Revision: https://reviews.llvm.org/D57315
llvm-svn: 352827
2019-02-01 10:28:03 +08:00
|
|
|
FunctionCallee TsanFuncEntry;
|
|
|
|
FunctionCallee TsanFuncExit;
|
|
|
|
FunctionCallee TsanIgnoreBegin;
|
|
|
|
FunctionCallee TsanIgnoreEnd;
|
2012-02-14 06:50:51 +08:00
|
|
|
// Accesses sizes are powers of two: 1, 2, 4, 8, 16.
|
2012-02-14 08:52:07 +08:00
|
|
|
static const size_t kNumberOfAccessSizes = 5;
|
[opaque pointer types] Add a FunctionCallee wrapper type, and use it.
Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.
Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.
Then:
- update the CallInst/InvokeInst instruction creation functions to
take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.
One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.
However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)
Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.
Differential Revision: https://reviews.llvm.org/D57315
llvm-svn: 352827
2019-02-01 10:28:03 +08:00
|
|
|
FunctionCallee TsanRead[kNumberOfAccessSizes];
|
|
|
|
FunctionCallee TsanWrite[kNumberOfAccessSizes];
|
|
|
|
FunctionCallee TsanUnalignedRead[kNumberOfAccessSizes];
|
|
|
|
FunctionCallee TsanUnalignedWrite[kNumberOfAccessSizes];
|
2020-04-22 22:01:33 +08:00
|
|
|
FunctionCallee TsanVolatileRead[kNumberOfAccessSizes];
|
|
|
|
FunctionCallee TsanVolatileWrite[kNumberOfAccessSizes];
|
|
|
|
FunctionCallee TsanUnalignedVolatileRead[kNumberOfAccessSizes];
|
|
|
|
FunctionCallee TsanUnalignedVolatileWrite[kNumberOfAccessSizes];
|
[TSan] Add option for emitting compound read-write instrumentation
This adds option -tsan-compound-read-before-write to emit different
instrumentation for the write if the read before that write is omitted
from instrumentation. The default TSan runtime currently does not
support the different instrumentation, and the option is disabled by
default.
Alternative runtimes, such as the Kernel Concurrency Sanitizer (KCSAN)
can make use of the feature. Indeed, the initial motivation is for use
in KCSAN as it was determined that due to the Linux kernel having a
large number of unaddressed data races, it makes sense to improve
performance and reporting by distinguishing compounded operations. E.g.
the compounded instrumentation is typically emitted for compound
operations such as ++, +=, |=, etc. By emitting different reports, such
data races can easily be noticed, and also automatically bucketed
differently by CI systems.
Reviewed By: dvyukov, glider
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83867
2020-07-17 14:53:56 +08:00
|
|
|
FunctionCallee TsanCompoundRW[kNumberOfAccessSizes];
|
|
|
|
FunctionCallee TsanUnalignedCompoundRW[kNumberOfAccessSizes];
|
[opaque pointer types] Add a FunctionCallee wrapper type, and use it.
Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.
Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.
Then:
- update the CallInst/InvokeInst instruction creation functions to
take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.
One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.
However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)
Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.
Differential Revision: https://reviews.llvm.org/D57315
llvm-svn: 352827
2019-02-01 10:28:03 +08:00
|
|
|
FunctionCallee TsanAtomicLoad[kNumberOfAccessSizes];
|
|
|
|
FunctionCallee TsanAtomicStore[kNumberOfAccessSizes];
|
|
|
|
FunctionCallee TsanAtomicRMW[AtomicRMWInst::LAST_BINOP + 1]
|
|
|
|
[kNumberOfAccessSizes];
|
|
|
|
FunctionCallee TsanAtomicCAS[kNumberOfAccessSizes];
|
|
|
|
FunctionCallee TsanAtomicThreadFence;
|
|
|
|
FunctionCallee TsanAtomicSignalFence;
|
|
|
|
FunctionCallee TsanVptrUpdate;
|
|
|
|
FunctionCallee TsanVptrLoad;
|
|
|
|
FunctionCallee MemmoveFn, MemcpyFn, MemsetFn;
|
2012-02-14 06:50:51 +08:00
|
|
|
};
|
2019-01-16 17:28:01 +08:00
|
|
|
|
|
|
|
struct ThreadSanitizerLegacyPass : FunctionPass {
|
2020-05-09 11:19:05 +08:00
|
|
|
ThreadSanitizerLegacyPass() : FunctionPass(ID) {
|
|
|
|
initializeThreadSanitizerLegacyPassPass(*PassRegistry::getPassRegistry());
|
|
|
|
}
|
2019-01-16 17:28:01 +08:00
|
|
|
StringRef getPassName() const override;
|
|
|
|
void getAnalysisUsage(AnalysisUsage &AU) const override;
|
|
|
|
bool runOnFunction(Function &F) override;
|
|
|
|
bool doInitialization(Module &M) override;
|
|
|
|
static char ID; // Pass identification, replacement for typeid.
|
|
|
|
private:
|
|
|
|
Optional<ThreadSanitizer> TSan;
|
|
|
|
};
|
2019-10-11 16:47:03 +08:00
|
|
|
|
|
|
|
void insertModuleCtor(Module &M) {
|
|
|
|
getOrCreateSanitizerCtorAndInitFunctions(
|
|
|
|
M, kTsanModuleCtorName, kTsanInitName, /*InitArgTypes=*/{},
|
|
|
|
/*InitArgs=*/{},
|
|
|
|
// This callback is invoked when the functions are created the first
|
|
|
|
// time. Hook them into the global ctors list in that case:
|
|
|
|
[&](Function *Ctor, FunctionCallee) { appendToGlobalCtors(M, Ctor, 0); });
|
|
|
|
}
|
|
|
|
|
2012-02-14 06:50:51 +08:00
|
|
|
} // namespace
|
|
|
|
|
2019-01-16 17:28:01 +08:00
|
|
|
PreservedAnalyses ThreadSanitizerPass::run(Function &F,
|
|
|
|
FunctionAnalysisManager &FAM) {
|
2019-10-11 16:47:03 +08:00
|
|
|
ThreadSanitizer TSan;
|
2019-01-16 17:28:01 +08:00
|
|
|
if (TSan.sanitizeFunction(F, FAM.getResult<TargetLibraryAnalysis>(F)))
|
|
|
|
return PreservedAnalyses::none();
|
|
|
|
return PreservedAnalyses::all();
|
|
|
|
}
|
|
|
|
|
2021-09-16 04:26:22 +08:00
|
|
|
PreservedAnalyses ModuleThreadSanitizerPass::run(Module &M,
|
|
|
|
ModuleAnalysisManager &MAM) {
|
2019-10-11 16:47:03 +08:00
|
|
|
insertModuleCtor(M);
|
|
|
|
return PreservedAnalyses::none();
|
|
|
|
}
|
|
|
|
|
2019-01-16 17:28:01 +08:00
|
|
|
char ThreadSanitizerLegacyPass::ID = 0;
|
|
|
|
INITIALIZE_PASS_BEGIN(ThreadSanitizerLegacyPass, "tsan",
|
|
|
|
"ThreadSanitizer: detects data races.", false, false)
|
2016-06-18 18:10:37 +08:00
|
|
|
INITIALIZE_PASS_DEPENDENCY(TargetLibraryInfoWrapperPass)
|
2019-01-16 17:28:01 +08:00
|
|
|
INITIALIZE_PASS_END(ThreadSanitizerLegacyPass, "tsan",
|
|
|
|
"ThreadSanitizer: detects data races.", false, false)
|
2012-02-14 06:50:51 +08:00
|
|
|
|
2019-01-16 17:28:01 +08:00
|
|
|
StringRef ThreadSanitizerLegacyPass::getPassName() const {
|
|
|
|
return "ThreadSanitizerLegacyPass";
|
|
|
|
}
|
2012-04-27 15:31:53 +08:00
|
|
|
|
2019-01-16 17:28:01 +08:00
|
|
|
void ThreadSanitizerLegacyPass::getAnalysisUsage(AnalysisUsage &AU) const {
|
2016-06-18 18:10:37 +08:00
|
|
|
AU.addRequired<TargetLibraryInfoWrapperPass>();
|
|
|
|
}
|
|
|
|
|
2019-01-16 17:28:01 +08:00
|
|
|
bool ThreadSanitizerLegacyPass::doInitialization(Module &M) {
|
2019-10-11 16:47:03 +08:00
|
|
|
insertModuleCtor(M);
|
|
|
|
TSan.emplace();
|
2019-01-16 17:28:01 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool ThreadSanitizerLegacyPass::runOnFunction(Function &F) {
|
Change TargetLibraryInfo analysis passes to always require Function
Summary:
This is the first change to enable the TLI to be built per-function so
that -fno-builtin* handling can be migrated to use function attributes.
See discussion on D61634 for background. This is an enabler for fixing
handling of these options for LTO, for example.
This change should not affect behavior, as the provided function is not
yet used to build a specifically per-function TLI, but rather enables
that migration.
Most of the changes were very mechanical, e.g. passing a Function to the
legacy analysis pass's getTLI interface, or in Module level cases,
adding a callback. This is similar to the way the per-function TTI
analysis works.
There was one place where we were looking for builtins but not in the
context of a specific function. See FindCXAAtExit in
lib/Transforms/IPO/GlobalOpt.cpp. I'm somewhat concerned my workaround
could provide the wrong behavior in some corner cases. Suggestions
welcome.
Reviewers: chandlerc, hfinkel
Subscribers: arsenm, dschuff, jvesely, nhaehnle, mehdi_amini, javed.absar, sbc100, jgravelle-google, eraman, aheejin, steven_wu, george.burgess.iv, dexonsmith, jfb, asbirlea, gchatelet, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D66428
llvm-svn: 371284
2019-09-07 11:09:36 +08:00
|
|
|
auto &TLI = getAnalysis<TargetLibraryInfoWrapperPass>().getTLI(F);
|
2019-01-16 17:28:01 +08:00
|
|
|
TSan->sanitizeFunction(F, TLI);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
FunctionPass *llvm::createThreadSanitizerLegacyPassPass() {
|
|
|
|
return new ThreadSanitizerLegacyPass();
|
2012-02-14 06:50:51 +08:00
|
|
|
}
|
|
|
|
|
2019-10-11 16:47:03 +08:00
|
|
|
void ThreadSanitizer::initialize(Module &M) {
|
|
|
|
const DataLayout &DL = M.getDataLayout();
|
|
|
|
IntptrTy = DL.getIntPtrType(M.getContext());
|
|
|
|
|
2012-02-14 06:50:51 +08:00
|
|
|
IRBuilder<> IRB(M.getContext());
|
Rename AttributeSet to AttributeList
Summary:
This class is a list of AttributeSetNodes corresponding the function
prototype of a call or function declaration. This class used to be
called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is
typically accessed by parameter and return value index, so
"AttributeList" seems like a more intuitive name.
Rename AttributeSetImpl to AttributeListImpl to follow suit.
It's useful to rename this class so that we can rename AttributeSetNode
to AttributeSet later. AttributeSet is the set of attributes that apply
to a single function, argument, or return value.
Reviewers: sanjoy, javed.absar, chandlerc, pete
Reviewed By: pete
Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits
Differential Revision: https://reviews.llvm.org/D31102
llvm-svn: 298393
2017-03-22 00:57:19 +08:00
|
|
|
AttributeList Attr;
|
2021-08-17 09:24:22 +08:00
|
|
|
Attr = Attr.addFnAttribute(M.getContext(), Attribute::NoUnwind);
|
2012-02-14 06:50:51 +08:00
|
|
|
// Initialize the callbacks.
|
[opaque pointer types] Add a FunctionCallee wrapper type, and use it.
Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.
Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.
Then:
- update the CallInst/InvokeInst instruction creation functions to
take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.
One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.
However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)
Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.
Differential Revision: https://reviews.llvm.org/D57315
llvm-svn: 352827
2019-02-01 10:28:03 +08:00
|
|
|
TsanFuncEntry = M.getOrInsertFunction("__tsan_func_entry", Attr,
|
|
|
|
IRB.getVoidTy(), IRB.getInt8PtrTy());
|
|
|
|
TsanFuncExit =
|
|
|
|
M.getOrInsertFunction("__tsan_func_exit", Attr, IRB.getVoidTy());
|
|
|
|
TsanIgnoreBegin = M.getOrInsertFunction("__tsan_ignore_thread_begin", Attr,
|
|
|
|
IRB.getVoidTy());
|
|
|
|
TsanIgnoreEnd =
|
|
|
|
M.getOrInsertFunction("__tsan_ignore_thread_end", Attr, IRB.getVoidTy());
|
2019-10-11 16:47:03 +08:00
|
|
|
IntegerType *OrdTy = IRB.getInt32Ty();
|
2012-02-14 08:52:07 +08:00
|
|
|
for (size_t i = 0; i < kNumberOfAccessSizes; ++i) {
|
2015-08-16 03:06:14 +08:00
|
|
|
const unsigned ByteSize = 1U << i;
|
|
|
|
const unsigned BitSize = ByteSize * 8;
|
|
|
|
std::string ByteSizeStr = utostr(ByteSize);
|
|
|
|
std::string BitSizeStr = utostr(BitSize);
|
|
|
|
SmallString<32> ReadName("__tsan_read" + ByteSizeStr);
|
[opaque pointer types] Add a FunctionCallee wrapper type, and use it.
Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.
Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.
Then:
- update the CallInst/InvokeInst instruction creation functions to
take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.
One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.
However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)
Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.
Differential Revision: https://reviews.llvm.org/D57315
llvm-svn: 352827
2019-02-01 10:28:03 +08:00
|
|
|
TsanRead[i] = M.getOrInsertFunction(ReadName, Attr, IRB.getVoidTy(),
|
|
|
|
IRB.getInt8PtrTy());
|
2012-04-27 15:31:53 +08:00
|
|
|
|
2015-08-16 03:06:14 +08:00
|
|
|
SmallString<32> WriteName("__tsan_write" + ByteSizeStr);
|
[opaque pointer types] Add a FunctionCallee wrapper type, and use it.
Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.
Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.
Then:
- update the CallInst/InvokeInst instruction creation functions to
take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.
One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.
However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)
Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.
Differential Revision: https://reviews.llvm.org/D57315
llvm-svn: 352827
2019-02-01 10:28:03 +08:00
|
|
|
TsanWrite[i] = M.getOrInsertFunction(WriteName, Attr, IRB.getVoidTy(),
|
|
|
|
IRB.getInt8PtrTy());
|
2012-04-27 15:31:53 +08:00
|
|
|
|
2015-08-16 03:06:14 +08:00
|
|
|
SmallString<64> UnalignedReadName("__tsan_unaligned_read" + ByteSizeStr);
|
[opaque pointer types] Add a FunctionCallee wrapper type, and use it.
Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.
Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.
Then:
- update the CallInst/InvokeInst instruction creation functions to
take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.
One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.
However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)
Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.
Differential Revision: https://reviews.llvm.org/D57315
llvm-svn: 352827
2019-02-01 10:28:03 +08:00
|
|
|
TsanUnalignedRead[i] = M.getOrInsertFunction(
|
|
|
|
UnalignedReadName, Attr, IRB.getVoidTy(), IRB.getInt8PtrTy());
|
2015-01-28 04:19:17 +08:00
|
|
|
|
2015-08-16 03:06:14 +08:00
|
|
|
SmallString<64> UnalignedWriteName("__tsan_unaligned_write" + ByteSizeStr);
|
[opaque pointer types] Add a FunctionCallee wrapper type, and use it.
Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.
Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.
Then:
- update the CallInst/InvokeInst instruction creation functions to
take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.
One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.
However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)
Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.
Differential Revision: https://reviews.llvm.org/D57315
llvm-svn: 352827
2019-02-01 10:28:03 +08:00
|
|
|
TsanUnalignedWrite[i] = M.getOrInsertFunction(
|
|
|
|
UnalignedWriteName, Attr, IRB.getVoidTy(), IRB.getInt8PtrTy());
|
2015-01-28 04:19:17 +08:00
|
|
|
|
2020-04-22 22:01:33 +08:00
|
|
|
SmallString<64> VolatileReadName("__tsan_volatile_read" + ByteSizeStr);
|
|
|
|
TsanVolatileRead[i] = M.getOrInsertFunction(
|
|
|
|
VolatileReadName, Attr, IRB.getVoidTy(), IRB.getInt8PtrTy());
|
|
|
|
|
|
|
|
SmallString<64> VolatileWriteName("__tsan_volatile_write" + ByteSizeStr);
|
|
|
|
TsanVolatileWrite[i] = M.getOrInsertFunction(
|
|
|
|
VolatileWriteName, Attr, IRB.getVoidTy(), IRB.getInt8PtrTy());
|
|
|
|
|
|
|
|
SmallString<64> UnalignedVolatileReadName("__tsan_unaligned_volatile_read" +
|
|
|
|
ByteSizeStr);
|
|
|
|
TsanUnalignedVolatileRead[i] = M.getOrInsertFunction(
|
|
|
|
UnalignedVolatileReadName, Attr, IRB.getVoidTy(), IRB.getInt8PtrTy());
|
|
|
|
|
|
|
|
SmallString<64> UnalignedVolatileWriteName(
|
|
|
|
"__tsan_unaligned_volatile_write" + ByteSizeStr);
|
|
|
|
TsanUnalignedVolatileWrite[i] = M.getOrInsertFunction(
|
|
|
|
UnalignedVolatileWriteName, Attr, IRB.getVoidTy(), IRB.getInt8PtrTy());
|
|
|
|
|
[TSan] Add option for emitting compound read-write instrumentation
This adds option -tsan-compound-read-before-write to emit different
instrumentation for the write if the read before that write is omitted
from instrumentation. The default TSan runtime currently does not
support the different instrumentation, and the option is disabled by
default.
Alternative runtimes, such as the Kernel Concurrency Sanitizer (KCSAN)
can make use of the feature. Indeed, the initial motivation is for use
in KCSAN as it was determined that due to the Linux kernel having a
large number of unaddressed data races, it makes sense to improve
performance and reporting by distinguishing compounded operations. E.g.
the compounded instrumentation is typically emitted for compound
operations such as ++, +=, |=, etc. By emitting different reports, such
data races can easily be noticed, and also automatically bucketed
differently by CI systems.
Reviewed By: dvyukov, glider
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83867
2020-07-17 14:53:56 +08:00
|
|
|
SmallString<64> CompoundRWName("__tsan_read_write" + ByteSizeStr);
|
|
|
|
TsanCompoundRW[i] = M.getOrInsertFunction(
|
|
|
|
CompoundRWName, Attr, IRB.getVoidTy(), IRB.getInt8PtrTy());
|
|
|
|
|
|
|
|
SmallString<64> UnalignedCompoundRWName("__tsan_unaligned_read_write" +
|
|
|
|
ByteSizeStr);
|
|
|
|
TsanUnalignedCompoundRW[i] = M.getOrInsertFunction(
|
|
|
|
UnalignedCompoundRWName, Attr, IRB.getVoidTy(), IRB.getInt8PtrTy());
|
|
|
|
|
2012-04-27 15:31:53 +08:00
|
|
|
Type *Ty = Type::getIntNTy(M.getContext(), BitSize);
|
|
|
|
Type *PtrTy = Ty->getPointerTo();
|
2015-08-16 03:06:14 +08:00
|
|
|
SmallString<32> AtomicLoadName("__tsan_atomic" + BitSizeStr + "_load");
|
2021-07-02 08:42:24 +08:00
|
|
|
{
|
|
|
|
AttributeList AL = Attr;
|
|
|
|
AL = AL.addParamAttribute(M.getContext(), 1, Attribute::ZExt);
|
|
|
|
TsanAtomicLoad[i] =
|
|
|
|
M.getOrInsertFunction(AtomicLoadName, AL, Ty, PtrTy, OrdTy);
|
|
|
|
}
|
2012-04-27 15:31:53 +08:00
|
|
|
|
2015-08-16 03:06:14 +08:00
|
|
|
SmallString<32> AtomicStoreName("__tsan_atomic" + BitSizeStr + "_store");
|
2021-07-02 08:42:24 +08:00
|
|
|
{
|
|
|
|
AttributeList AL = Attr;
|
|
|
|
AL = AL.addParamAttribute(M.getContext(), 1, Attribute::ZExt);
|
|
|
|
AL = AL.addParamAttribute(M.getContext(), 2, Attribute::ZExt);
|
|
|
|
TsanAtomicStore[i] = M.getOrInsertFunction(
|
|
|
|
AtomicStoreName, AL, IRB.getVoidTy(), PtrTy, Ty, OrdTy);
|
|
|
|
}
|
2012-11-09 20:55:36 +08:00
|
|
|
|
2020-07-03 15:20:22 +08:00
|
|
|
for (unsigned Op = AtomicRMWInst::FIRST_BINOP;
|
|
|
|
Op <= AtomicRMWInst::LAST_BINOP; ++Op) {
|
|
|
|
TsanAtomicRMW[Op][i] = nullptr;
|
2014-04-25 13:29:35 +08:00
|
|
|
const char *NamePart = nullptr;
|
2020-07-03 15:20:22 +08:00
|
|
|
if (Op == AtomicRMWInst::Xchg)
|
2012-11-09 20:55:36 +08:00
|
|
|
NamePart = "_exchange";
|
2020-07-03 15:20:22 +08:00
|
|
|
else if (Op == AtomicRMWInst::Add)
|
2012-11-09 20:55:36 +08:00
|
|
|
NamePart = "_fetch_add";
|
2020-07-03 15:20:22 +08:00
|
|
|
else if (Op == AtomicRMWInst::Sub)
|
2012-11-09 20:55:36 +08:00
|
|
|
NamePart = "_fetch_sub";
|
2020-07-03 15:20:22 +08:00
|
|
|
else if (Op == AtomicRMWInst::And)
|
2012-11-09 20:55:36 +08:00
|
|
|
NamePart = "_fetch_and";
|
2020-07-03 15:20:22 +08:00
|
|
|
else if (Op == AtomicRMWInst::Or)
|
2012-11-09 20:55:36 +08:00
|
|
|
NamePart = "_fetch_or";
|
2020-07-03 15:20:22 +08:00
|
|
|
else if (Op == AtomicRMWInst::Xor)
|
2012-11-09 20:55:36 +08:00
|
|
|
NamePart = "_fetch_xor";
|
2020-07-03 15:20:22 +08:00
|
|
|
else if (Op == AtomicRMWInst::Nand)
|
2012-11-27 16:09:25 +08:00
|
|
|
NamePart = "_fetch_nand";
|
2012-11-09 20:55:36 +08:00
|
|
|
else
|
|
|
|
continue;
|
|
|
|
SmallString<32> RMWName("__tsan_atomic" + itostr(BitSize) + NamePart);
|
2021-07-02 08:42:24 +08:00
|
|
|
{
|
|
|
|
AttributeList AL = Attr;
|
|
|
|
AL = AL.addParamAttribute(M.getContext(), 1, Attribute::ZExt);
|
|
|
|
AL = AL.addParamAttribute(M.getContext(), 2, Attribute::ZExt);
|
|
|
|
TsanAtomicRMW[Op][i] =
|
|
|
|
M.getOrInsertFunction(RMWName, AL, Ty, PtrTy, Ty, OrdTy);
|
|
|
|
}
|
2012-11-09 20:55:36 +08:00
|
|
|
}
|
|
|
|
|
2015-08-16 03:06:14 +08:00
|
|
|
SmallString<32> AtomicCASName("__tsan_atomic" + BitSizeStr +
|
2012-11-09 20:55:36 +08:00
|
|
|
"_compare_exchange_val");
|
2021-07-02 08:42:24 +08:00
|
|
|
{
|
|
|
|
AttributeList AL = Attr;
|
|
|
|
AL = AL.addParamAttribute(M.getContext(), 1, Attribute::ZExt);
|
|
|
|
AL = AL.addParamAttribute(M.getContext(), 2, Attribute::ZExt);
|
|
|
|
AL = AL.addParamAttribute(M.getContext(), 3, Attribute::ZExt);
|
|
|
|
AL = AL.addParamAttribute(M.getContext(), 4, Attribute::ZExt);
|
|
|
|
TsanAtomicCAS[i] = M.getOrInsertFunction(AtomicCASName, AL, Ty, PtrTy, Ty,
|
|
|
|
Ty, OrdTy, OrdTy);
|
|
|
|
}
|
2012-02-14 06:50:51 +08:00
|
|
|
}
|
[opaque pointer types] Add a FunctionCallee wrapper type, and use it.
Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.
Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.
Then:
- update the CallInst/InvokeInst instruction creation functions to
take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.
One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.
However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)
Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.
Differential Revision: https://reviews.llvm.org/D57315
llvm-svn: 352827
2019-02-01 10:28:03 +08:00
|
|
|
TsanVptrUpdate =
|
2016-11-15 05:41:13 +08:00
|
|
|
M.getOrInsertFunction("__tsan_vptr_update", Attr, IRB.getVoidTy(),
|
[opaque pointer types] Add a FunctionCallee wrapper type, and use it.
Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.
Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.
Then:
- update the CallInst/InvokeInst instruction creation functions to
take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.
One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.
However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)
Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.
Differential Revision: https://reviews.llvm.org/D57315
llvm-svn: 352827
2019-02-01 10:28:03 +08:00
|
|
|
IRB.getInt8PtrTy(), IRB.getInt8PtrTy());
|
|
|
|
TsanVptrLoad = M.getOrInsertFunction("__tsan_vptr_read", Attr,
|
|
|
|
IRB.getVoidTy(), IRB.getInt8PtrTy());
|
2021-07-02 08:42:24 +08:00
|
|
|
{
|
|
|
|
AttributeList AL = Attr;
|
|
|
|
AL = AL.addParamAttribute(M.getContext(), 0, Attribute::ZExt);
|
|
|
|
TsanAtomicThreadFence = M.getOrInsertFunction("__tsan_atomic_thread_fence",
|
|
|
|
AL, IRB.getVoidTy(), OrdTy);
|
|
|
|
}
|
|
|
|
{
|
|
|
|
AttributeList AL = Attr;
|
|
|
|
AL = AL.addParamAttribute(M.getContext(), 0, Attribute::ZExt);
|
|
|
|
TsanAtomicSignalFence = M.getOrInsertFunction("__tsan_atomic_signal_fence",
|
|
|
|
AL, IRB.getVoidTy(), OrdTy);
|
|
|
|
}
|
[opaque pointer types] Add a FunctionCallee wrapper type, and use it.
Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.
Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.
Then:
- update the CallInst/InvokeInst instruction creation functions to
take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.
One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.
However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)
Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.
Differential Revision: https://reviews.llvm.org/D57315
llvm-svn: 352827
2019-02-01 10:28:03 +08:00
|
|
|
|
|
|
|
MemmoveFn =
|
|
|
|
M.getOrInsertFunction("memmove", Attr, IRB.getInt8PtrTy(),
|
|
|
|
IRB.getInt8PtrTy(), IRB.getInt8PtrTy(), IntptrTy);
|
|
|
|
MemcpyFn =
|
|
|
|
M.getOrInsertFunction("memcpy", Attr, IRB.getInt8PtrTy(),
|
|
|
|
IRB.getInt8PtrTy(), IRB.getInt8PtrTy(), IntptrTy);
|
|
|
|
MemsetFn =
|
|
|
|
M.getOrInsertFunction("memset", Attr, IRB.getInt8PtrTy(),
|
|
|
|
IRB.getInt8PtrTy(), IRB.getInt32Ty(), IntptrTy);
|
2012-11-29 17:54:21 +08:00
|
|
|
}
|
|
|
|
|
2012-04-11 06:29:17 +08:00
|
|
|
static bool isVtableAccess(Instruction *I) {
|
2014-11-12 05:30:22 +08:00
|
|
|
if (MDNode *Tag = I->getMetadata(LLVMContext::MD_tbaa))
|
2013-09-07 06:47:05 +08:00
|
|
|
return Tag->isTBAAVtableAccess();
|
2012-04-11 06:29:17 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2016-03-30 07:19:40 +08:00
|
|
|
// Do not instrument known races/"benign races" that come from compiler
|
|
|
|
// instrumentatin. The user has no way of suppressing them.
|
2017-04-14 11:03:24 +08:00
|
|
|
static bool shouldInstrumentReadWriteFromAddress(const Module *M, Value *Addr) {
|
2016-03-30 07:19:40 +08:00
|
|
|
// Peel off GEPs and BitCasts.
|
|
|
|
Addr = Addr->stripInBoundsOffsets();
|
|
|
|
|
|
|
|
if (GlobalVariable *GV = dyn_cast<GlobalVariable>(Addr)) {
|
|
|
|
if (GV->hasSection()) {
|
|
|
|
StringRef SectionName = GV->getSection();
|
|
|
|
// Check if the global is in the PGO counters section.
|
2017-04-15 08:09:57 +08:00
|
|
|
auto OF = Triple(M->getTargetTriple()).getObjectFormat();
|
|
|
|
if (SectionName.endswith(
|
|
|
|
getInstrProfSectionName(IPSK_cnts, OF, /*AddSegmentInfo=*/false)))
|
2016-03-30 07:19:40 +08:00
|
|
|
return false;
|
|
|
|
}
|
2016-06-21 05:24:26 +08:00
|
|
|
|
2016-07-20 04:16:08 +08:00
|
|
|
// Check if the global is private gcov data.
|
|
|
|
if (GV->getName().startswith("__llvm_gcov") ||
|
|
|
|
GV->getName().startswith("__llvm_gcda"))
|
2016-06-21 05:24:26 +08:00
|
|
|
return false;
|
2016-03-30 07:19:40 +08:00
|
|
|
}
|
2016-06-22 08:15:52 +08:00
|
|
|
|
|
|
|
// Do not instrument acesses from different address spaces; we cannot deal
|
|
|
|
// with them.
|
|
|
|
if (Addr) {
|
|
|
|
Type *PtrTy = cast<PointerType>(Addr->getType()->getScalarType());
|
|
|
|
if (PtrTy->getPointerAddressSpace() != 0)
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2016-03-30 07:19:40 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2012-04-11 06:29:17 +08:00
|
|
|
bool ThreadSanitizer::addrPointsToConstantData(Value *Addr) {
|
|
|
|
// If this is a GEP, just analyze its pointer operand.
|
|
|
|
if (GetElementPtrInst *GEP = dyn_cast<GetElementPtrInst>(Addr))
|
|
|
|
Addr = GEP->getPointerOperand();
|
|
|
|
|
|
|
|
if (GlobalVariable *GV = dyn_cast<GlobalVariable>(Addr)) {
|
|
|
|
if (GV->isConstant()) {
|
|
|
|
// Reads from constant globals can not race with any writes.
|
2012-04-23 16:44:59 +08:00
|
|
|
NumOmittedReadsFromConstantGlobals++;
|
2012-04-11 06:29:17 +08:00
|
|
|
return true;
|
|
|
|
}
|
2012-08-30 21:47:13 +08:00
|
|
|
} else if (LoadInst *L = dyn_cast<LoadInst>(Addr)) {
|
2012-04-11 06:29:17 +08:00
|
|
|
if (isVtableAccess(L)) {
|
|
|
|
// Reads from a vtable pointer can not race with any writes.
|
2012-04-23 16:44:59 +08:00
|
|
|
NumOmittedReadsFromVtable++;
|
2012-04-11 06:29:17 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2012-04-11 02:18:56 +08:00
|
|
|
// Instrumenting some of the accesses may be proven redundant.
|
|
|
|
// Currently handled:
|
|
|
|
// - read-before-write (within same BB, no calls between)
|
2015-02-12 17:55:28 +08:00
|
|
|
// - not captured variables
|
2012-04-11 02:18:56 +08:00
|
|
|
//
|
|
|
|
// We do not handle some of the patterns that should not survive
|
|
|
|
// after the classic compiler optimizations.
|
|
|
|
// E.g. two reads from the same temp should be eliminated by CSE,
|
|
|
|
// two writes should be eliminated by DSE, etc.
|
|
|
|
//
|
|
|
|
// 'Local' is a vector of insns within the same BB (no calls between).
|
|
|
|
// 'All' is a vector of insns that will be instrumented.
|
2012-05-02 21:12:19 +08:00
|
|
|
void ThreadSanitizer::chooseInstructionsToInstrument(
|
[TSan] Add option for emitting compound read-write instrumentation
This adds option -tsan-compound-read-before-write to emit different
instrumentation for the write if the read before that write is omitted
from instrumentation. The default TSan runtime currently does not
support the different instrumentation, and the option is disabled by
default.
Alternative runtimes, such as the Kernel Concurrency Sanitizer (KCSAN)
can make use of the feature. Indeed, the initial motivation is for use
in KCSAN as it was determined that due to the Linux kernel having a
large number of unaddressed data races, it makes sense to improve
performance and reporting by distinguishing compounded operations. E.g.
the compounded instrumentation is typically emitted for compound
operations such as ++, +=, |=, etc. By emitting different reports, such
data races can easily be noticed, and also automatically bucketed
differently by CI systems.
Reviewed By: dvyukov, glider
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83867
2020-07-17 14:53:56 +08:00
|
|
|
SmallVectorImpl<Instruction *> &Local,
|
|
|
|
SmallVectorImpl<InstructionInfo> &All, const DataLayout &DL) {
|
|
|
|
DenseMap<Value *, size_t> WriteTargets; // Map of addresses to index in All
|
2012-04-11 02:18:56 +08:00
|
|
|
// Iterate from the end.
|
2016-06-24 12:05:21 +08:00
|
|
|
for (Instruction *I : reverse(Local)) {
|
[TSan] Add option for emitting compound read-write instrumentation
This adds option -tsan-compound-read-before-write to emit different
instrumentation for the write if the read before that write is omitted
from instrumentation. The default TSan runtime currently does not
support the different instrumentation, and the option is disabled by
default.
Alternative runtimes, such as the Kernel Concurrency Sanitizer (KCSAN)
can make use of the feature. Indeed, the initial motivation is for use
in KCSAN as it was determined that due to the Linux kernel having a
large number of unaddressed data races, it makes sense to improve
performance and reporting by distinguishing compounded operations. E.g.
the compounded instrumentation is typically emitted for compound
operations such as ++, +=, |=, etc. By emitting different reports, such
data races can easily be noticed, and also automatically bucketed
differently by CI systems.
Reviewed By: dvyukov, glider
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83867
2020-07-17 14:53:56 +08:00
|
|
|
const bool IsWrite = isa<StoreInst>(*I);
|
|
|
|
Value *Addr = IsWrite ? cast<StoreInst>(I)->getPointerOperand()
|
|
|
|
: cast<LoadInst>(I)->getPointerOperand();
|
|
|
|
|
|
|
|
if (!shouldInstrumentReadWriteFromAddress(I->getModule(), Addr))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (!IsWrite) {
|
|
|
|
const auto WriteEntry = WriteTargets.find(Addr);
|
|
|
|
if (!ClInstrumentReadBeforeWrite && WriteEntry != WriteTargets.end()) {
|
|
|
|
auto &WI = All[WriteEntry->second];
|
|
|
|
// If we distinguish volatile accesses and if either the read or write
|
|
|
|
// is volatile, do not omit any instrumentation.
|
|
|
|
const bool AnyVolatile =
|
|
|
|
ClDistinguishVolatile && (cast<LoadInst>(I)->isVolatile() ||
|
|
|
|
cast<StoreInst>(WI.Inst)->isVolatile());
|
|
|
|
if (!AnyVolatile) {
|
|
|
|
// We will write to this temp, so no reason to analyze the read.
|
|
|
|
// Mark the write instruction as compound.
|
|
|
|
WI.Flags |= InstructionInfo::kCompoundRW;
|
|
|
|
NumOmittedReadsBeforeWrite++;
|
|
|
|
continue;
|
|
|
|
}
|
2012-04-11 02:18:56 +08:00
|
|
|
}
|
[TSan] Add option for emitting compound read-write instrumentation
This adds option -tsan-compound-read-before-write to emit different
instrumentation for the write if the read before that write is omitted
from instrumentation. The default TSan runtime currently does not
support the different instrumentation, and the option is disabled by
default.
Alternative runtimes, such as the Kernel Concurrency Sanitizer (KCSAN)
can make use of the feature. Indeed, the initial motivation is for use
in KCSAN as it was determined that due to the Linux kernel having a
large number of unaddressed data races, it makes sense to improve
performance and reporting by distinguishing compounded operations. E.g.
the compounded instrumentation is typically emitted for compound
operations such as ++, +=, |=, etc. By emitting different reports, such
data races can easily be noticed, and also automatically bucketed
differently by CI systems.
Reviewed By: dvyukov, glider
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83867
2020-07-17 14:53:56 +08:00
|
|
|
|
2012-04-11 06:29:17 +08:00
|
|
|
if (addrPointsToConstantData(Addr)) {
|
|
|
|
// Addr points to some constant data -- it can not race with any writes.
|
|
|
|
continue;
|
|
|
|
}
|
2012-04-11 02:18:56 +08:00
|
|
|
}
|
[TSan] Add option for emitting compound read-write instrumentation
This adds option -tsan-compound-read-before-write to emit different
instrumentation for the write if the read before that write is omitted
from instrumentation. The default TSan runtime currently does not
support the different instrumentation, and the option is disabled by
default.
Alternative runtimes, such as the Kernel Concurrency Sanitizer (KCSAN)
can make use of the feature. Indeed, the initial motivation is for use
in KCSAN as it was determined that due to the Linux kernel having a
large number of unaddressed data races, it makes sense to improve
performance and reporting by distinguishing compounded operations. E.g.
the compounded instrumentation is typically emitted for compound
operations such as ++, +=, |=, etc. By emitting different reports, such
data races can easily be noticed, and also automatically bucketed
differently by CI systems.
Reviewed By: dvyukov, glider
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83867
2020-07-17 14:53:56 +08:00
|
|
|
|
2020-07-31 17:09:54 +08:00
|
|
|
if (isa<AllocaInst>(getUnderlyingObject(Addr)) &&
|
2015-02-12 17:55:28 +08:00
|
|
|
!PointerMayBeCaptured(Addr, true, true)) {
|
|
|
|
// The variable is addressable but not captured, so it cannot be
|
|
|
|
// referenced from a different thread and participate in a data race
|
|
|
|
// (see llvm/Analysis/CaptureTracking.h for details).
|
|
|
|
NumOmittedNonCaptured++;
|
|
|
|
continue;
|
|
|
|
}
|
[TSan] Add option for emitting compound read-write instrumentation
This adds option -tsan-compound-read-before-write to emit different
instrumentation for the write if the read before that write is omitted
from instrumentation. The default TSan runtime currently does not
support the different instrumentation, and the option is disabled by
default.
Alternative runtimes, such as the Kernel Concurrency Sanitizer (KCSAN)
can make use of the feature. Indeed, the initial motivation is for use
in KCSAN as it was determined that due to the Linux kernel having a
large number of unaddressed data races, it makes sense to improve
performance and reporting by distinguishing compounded operations. E.g.
the compounded instrumentation is typically emitted for compound
operations such as ++, +=, |=, etc. By emitting different reports, such
data races can easily be noticed, and also automatically bucketed
differently by CI systems.
Reviewed By: dvyukov, glider
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83867
2020-07-17 14:53:56 +08:00
|
|
|
|
|
|
|
// Instrument this instruction.
|
|
|
|
All.emplace_back(I);
|
|
|
|
if (IsWrite) {
|
|
|
|
// For read-before-write and compound instrumentation we only need one
|
|
|
|
// write target, and we can override any previous entry if it exists.
|
|
|
|
WriteTargets[Addr] = All.size() - 1;
|
|
|
|
}
|
2012-04-11 02:18:56 +08:00
|
|
|
}
|
|
|
|
Local.clear();
|
|
|
|
}
|
|
|
|
|
2022-03-17 21:56:29 +08:00
|
|
|
static bool isTsanAtomic(const Instruction *I) {
|
2017-07-12 06:23:00 +08:00
|
|
|
// TODO: Ask TTI whether synchronization scope is between threads.
|
2022-03-17 21:56:29 +08:00
|
|
|
auto SSID = getAtomicSyncScopeID(I);
|
|
|
|
if (!SSID.hasValue())
|
|
|
|
return false;
|
|
|
|
if (isa<LoadInst>(I) || isa<StoreInst>(I))
|
|
|
|
return SSID.getValue() != SyncScope::SingleThread;
|
|
|
|
return true;
|
2012-04-27 15:31:53 +08:00
|
|
|
}
|
|
|
|
|
2016-11-15 05:41:13 +08:00
|
|
|
void ThreadSanitizer::InsertRuntimeIgnores(Function &F) {
|
2016-11-12 07:01:02 +08:00
|
|
|
IRBuilder<> IRB(F.getEntryBlock().getFirstNonPHI());
|
|
|
|
IRB.CreateCall(TsanIgnoreBegin);
|
2016-11-15 05:41:13 +08:00
|
|
|
EscapeEnumerator EE(F, "tsan_ignore_cleanup", ClHandleCxxExceptions);
|
|
|
|
while (IRBuilder<> *AtExit = EE.Next()) {
|
|
|
|
AtExit->CreateCall(TsanIgnoreEnd);
|
2016-11-12 07:01:02 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-01-16 17:28:01 +08:00
|
|
|
bool ThreadSanitizer::sanitizeFunction(Function &F,
|
|
|
|
const TargetLibraryInfo &TLI) {
|
2019-01-09 21:32:16 +08:00
|
|
|
// This is required to prevent instrumenting call to __tsan_init from within
|
|
|
|
// the module constructor.
|
2019-10-11 16:47:03 +08:00
|
|
|
if (F.getName() == kTsanModuleCtorName)
|
2019-01-09 21:32:16 +08:00
|
|
|
return false;
|
2020-04-05 03:55:10 +08:00
|
|
|
// Naked functions can not have prologue/epilogue
|
|
|
|
// (__tsan_func_entry/__tsan_func_exit) generated, so don't instrument them at
|
|
|
|
// all.
|
|
|
|
if (F.hasFnAttribute(Attribute::Naked))
|
|
|
|
return false;
|
2021-08-17 19:19:15 +08:00
|
|
|
|
|
|
|
// __attribute__(disable_sanitizer_instrumentation) prevents all kinds of
|
|
|
|
// instrumentation.
|
|
|
|
if (F.hasFnAttribute(Attribute::DisableSanitizerInstrumentation))
|
|
|
|
return false;
|
|
|
|
|
2019-10-11 16:47:03 +08:00
|
|
|
initialize(*F.getParent());
|
[TSan] Add option for emitting compound read-write instrumentation
This adds option -tsan-compound-read-before-write to emit different
instrumentation for the write if the read before that write is omitted
from instrumentation. The default TSan runtime currently does not
support the different instrumentation, and the option is disabled by
default.
Alternative runtimes, such as the Kernel Concurrency Sanitizer (KCSAN)
can make use of the feature. Indeed, the initial motivation is for use
in KCSAN as it was determined that due to the Linux kernel having a
large number of unaddressed data races, it makes sense to improve
performance and reporting by distinguishing compounded operations. E.g.
the compounded instrumentation is typically emitted for compound
operations such as ++, +=, |=, etc. By emitting different reports, such
data races can easily be noticed, and also automatically bucketed
differently by CI systems.
Reviewed By: dvyukov, glider
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83867
2020-07-17 14:53:56 +08:00
|
|
|
SmallVector<InstructionInfo, 8> AllLoadsAndStores;
|
2012-04-11 02:18:56 +08:00
|
|
|
SmallVector<Instruction*, 8> LocalLoadsAndStores;
|
2012-04-27 15:31:53 +08:00
|
|
|
SmallVector<Instruction*, 8> AtomicAccesses;
|
2013-03-28 19:21:13 +08:00
|
|
|
SmallVector<Instruction*, 8> MemIntrinCalls;
|
2012-02-14 06:50:51 +08:00
|
|
|
bool Res = false;
|
|
|
|
bool HasCalls = false;
|
2014-06-03 02:08:27 +08:00
|
|
|
bool SanitizeFunction = F.hasFnAttribute(Attribute::SanitizeThread);
|
2015-03-10 10:37:25 +08:00
|
|
|
const DataLayout &DL = F.getParent()->getDataLayout();
|
2012-02-14 06:50:51 +08:00
|
|
|
|
|
|
|
// Traverse all instructions, collect loads/stores/returns, check for calls.
|
2014-05-30 02:40:48 +08:00
|
|
|
for (auto &BB : F) {
|
|
|
|
for (auto &Inst : BB) {
|
2022-03-17 21:56:29 +08:00
|
|
|
if (isTsanAtomic(&Inst))
|
2014-05-30 02:40:48 +08:00
|
|
|
AtomicAccesses.push_back(&Inst);
|
|
|
|
else if (isa<LoadInst>(Inst) || isa<StoreInst>(Inst))
|
|
|
|
LocalLoadsAndStores.push_back(&Inst);
|
2021-11-17 20:56:16 +08:00
|
|
|
else if ((isa<CallInst>(Inst) && !isa<DbgInfoIntrinsic>(Inst)) ||
|
|
|
|
isa<InvokeInst>(Inst)) {
|
2016-06-18 18:10:37 +08:00
|
|
|
if (CallInst *CI = dyn_cast<CallInst>(&Inst))
|
2019-01-16 17:28:01 +08:00
|
|
|
maybeMarkSanitizerLibraryCallNoBuiltin(CI, &TLI);
|
2014-05-30 02:40:48 +08:00
|
|
|
if (isa<MemIntrinsic>(Inst))
|
|
|
|
MemIntrinCalls.push_back(&Inst);
|
2012-02-14 06:50:51 +08:00
|
|
|
HasCalls = true;
|
2015-03-10 10:37:25 +08:00
|
|
|
chooseInstructionsToInstrument(LocalLoadsAndStores, AllLoadsAndStores,
|
|
|
|
DL);
|
2012-04-11 02:18:56 +08:00
|
|
|
}
|
2012-02-14 06:50:51 +08:00
|
|
|
}
|
2015-03-10 10:37:25 +08:00
|
|
|
chooseInstructionsToInstrument(LocalLoadsAndStores, AllLoadsAndStores, DL);
|
2012-02-14 06:50:51 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// We have collected all loads and stores.
|
|
|
|
// FIXME: many of these accesses do not need to be checked for races
|
|
|
|
// (e.g. variables that do not escape, etc).
|
|
|
|
|
2014-05-31 08:11:37 +08:00
|
|
|
// Instrument memory accesses only if we want to report bugs in the function.
|
|
|
|
if (ClInstrumentMemoryAccesses && SanitizeFunction)
|
[TSan] Add option for emitting compound read-write instrumentation
This adds option -tsan-compound-read-before-write to emit different
instrumentation for the write if the read before that write is omitted
from instrumentation. The default TSan runtime currently does not
support the different instrumentation, and the option is disabled by
default.
Alternative runtimes, such as the Kernel Concurrency Sanitizer (KCSAN)
can make use of the feature. Indeed, the initial motivation is for use
in KCSAN as it was determined that due to the Linux kernel having a
large number of unaddressed data races, it makes sense to improve
performance and reporting by distinguishing compounded operations. E.g.
the compounded instrumentation is typically emitted for compound
operations such as ++, +=, |=, etc. By emitting different reports, such
data races can easily be noticed, and also automatically bucketed
differently by CI systems.
Reviewed By: dvyukov, glider
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83867
2020-07-17 14:53:56 +08:00
|
|
|
for (const auto &II : AllLoadsAndStores) {
|
|
|
|
Res |= instrumentLoadOrStore(II, DL);
|
2012-10-04 13:28:50 +08:00
|
|
|
}
|
2012-02-14 06:50:51 +08:00
|
|
|
|
2014-05-31 08:11:37 +08:00
|
|
|
// Instrument atomic memory accesses in any case (they can be used to
|
|
|
|
// implement synchronization).
|
2012-10-04 13:28:50 +08:00
|
|
|
if (ClInstrumentAtomics)
|
2014-05-30 02:40:48 +08:00
|
|
|
for (auto Inst : AtomicAccesses) {
|
2015-03-10 10:37:25 +08:00
|
|
|
Res |= instrumentAtomic(Inst, DL);
|
2012-10-04 13:28:50 +08:00
|
|
|
}
|
2012-04-27 15:31:53 +08:00
|
|
|
|
2014-05-31 08:11:37 +08:00
|
|
|
if (ClInstrumentMemIntrinsics && SanitizeFunction)
|
2014-05-30 02:40:48 +08:00
|
|
|
for (auto Inst : MemIntrinCalls) {
|
|
|
|
Res |= instrumentMemIntrinsic(Inst);
|
2013-03-28 19:21:13 +08:00
|
|
|
}
|
|
|
|
|
2016-11-12 07:01:02 +08:00
|
|
|
if (F.hasFnAttribute("sanitize_thread_no_checking_at_run_time")) {
|
|
|
|
assert(!F.hasFnAttribute(Attribute::SanitizeThread));
|
|
|
|
if (HasCalls)
|
2016-11-15 05:41:13 +08:00
|
|
|
InsertRuntimeIgnores(F);
|
2016-11-12 07:01:02 +08:00
|
|
|
}
|
|
|
|
|
2012-02-14 06:50:51 +08:00
|
|
|
// Instrument function entry/exit points if there were instrumented accesses.
|
2012-10-04 13:28:50 +08:00
|
|
|
if ((Res || HasCalls) && ClInstrumentFuncEntryExit) {
|
2012-02-14 06:50:51 +08:00
|
|
|
IRBuilder<> IRB(F.getEntryBlock().getFirstNonPHI());
|
|
|
|
Value *ReturnAddress = IRB.CreateCall(
|
|
|
|
Intrinsic::getDeclaration(F.getParent(), Intrinsic::returnaddress),
|
|
|
|
IRB.getInt32(0));
|
|
|
|
IRB.CreateCall(TsanFuncEntry, ReturnAddress);
|
2016-11-15 05:41:13 +08:00
|
|
|
|
|
|
|
EscapeEnumerator EE(F, "tsan_cleanup", ClHandleCxxExceptions);
|
|
|
|
while (IRBuilder<> *AtExit = EE.Next()) {
|
|
|
|
AtExit->CreateCall(TsanFuncExit, {});
|
2012-02-14 06:50:51 +08:00
|
|
|
}
|
2012-03-27 01:35:03 +08:00
|
|
|
Res = true;
|
2012-02-14 06:50:51 +08:00
|
|
|
}
|
|
|
|
return Res;
|
|
|
|
}
|
|
|
|
|
[TSan] Add option for emitting compound read-write instrumentation
This adds option -tsan-compound-read-before-write to emit different
instrumentation for the write if the read before that write is omitted
from instrumentation. The default TSan runtime currently does not
support the different instrumentation, and the option is disabled by
default.
Alternative runtimes, such as the Kernel Concurrency Sanitizer (KCSAN)
can make use of the feature. Indeed, the initial motivation is for use
in KCSAN as it was determined that due to the Linux kernel having a
large number of unaddressed data races, it makes sense to improve
performance and reporting by distinguishing compounded operations. E.g.
the compounded instrumentation is typically emitted for compound
operations such as ++, +=, |=, etc. By emitting different reports, such
data races can easily be noticed, and also automatically bucketed
differently by CI systems.
Reviewed By: dvyukov, glider
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83867
2020-07-17 14:53:56 +08:00
|
|
|
bool ThreadSanitizer::instrumentLoadOrStore(const InstructionInfo &II,
|
2015-03-10 10:37:25 +08:00
|
|
|
const DataLayout &DL) {
|
[TSan] Add option for emitting compound read-write instrumentation
This adds option -tsan-compound-read-before-write to emit different
instrumentation for the write if the read before that write is omitted
from instrumentation. The default TSan runtime currently does not
support the different instrumentation, and the option is disabled by
default.
Alternative runtimes, such as the Kernel Concurrency Sanitizer (KCSAN)
can make use of the feature. Indeed, the initial motivation is for use
in KCSAN as it was determined that due to the Linux kernel having a
large number of unaddressed data races, it makes sense to improve
performance and reporting by distinguishing compounded operations. E.g.
the compounded instrumentation is typically emitted for compound
operations such as ++, +=, |=, etc. By emitting different reports, such
data races can easily be noticed, and also automatically bucketed
differently by CI systems.
Reviewed By: dvyukov, glider
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83867
2020-07-17 14:53:56 +08:00
|
|
|
IRBuilder<> IRB(II.Inst);
|
|
|
|
const bool IsWrite = isa<StoreInst>(*II.Inst);
|
|
|
|
Value *Addr = IsWrite ? cast<StoreInst>(II.Inst)->getPointerOperand()
|
|
|
|
: cast<LoadInst>(II.Inst)->getPointerOperand();
|
2021-07-10 00:24:59 +08:00
|
|
|
Type *OrigTy = getLoadStoreType(II.Inst);
|
2017-02-16 02:57:06 +08:00
|
|
|
|
|
|
|
// swifterror memory addresses are mem2reg promoted by instruction selection.
|
|
|
|
// As such they cannot have regular uses like an instrumentation function and
|
|
|
|
// it makes no sense to track them as memory.
|
|
|
|
if (Addr->isSwiftError())
|
|
|
|
return false;
|
|
|
|
|
2021-07-10 00:24:59 +08:00
|
|
|
int Idx = getMemoryAccessFuncIndex(OrigTy, Addr, DL);
|
2012-04-27 15:31:53 +08:00
|
|
|
if (Idx < 0)
|
2012-02-14 06:50:51 +08:00
|
|
|
return false;
|
[TSan] Add option for emitting compound read-write instrumentation
This adds option -tsan-compound-read-before-write to emit different
instrumentation for the write if the read before that write is omitted
from instrumentation. The default TSan runtime currently does not
support the different instrumentation, and the option is disabled by
default.
Alternative runtimes, such as the Kernel Concurrency Sanitizer (KCSAN)
can make use of the feature. Indeed, the initial motivation is for use
in KCSAN as it was determined that due to the Linux kernel having a
large number of unaddressed data races, it makes sense to improve
performance and reporting by distinguishing compounded operations. E.g.
the compounded instrumentation is typically emitted for compound
operations such as ++, +=, |=, etc. By emitting different reports, such
data races can easily be noticed, and also automatically bucketed
differently by CI systems.
Reviewed By: dvyukov, glider
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83867
2020-07-17 14:53:56 +08:00
|
|
|
if (IsWrite && isVtableAccess(II.Inst)) {
|
|
|
|
LLVM_DEBUG(dbgs() << " VPTR : " << *II.Inst << "\n");
|
|
|
|
Value *StoredValue = cast<StoreInst>(II.Inst)->getValueOperand();
|
2013-12-02 16:07:15 +08:00
|
|
|
// StoredValue may be a vector type if we are storing several vptrs at once.
|
|
|
|
// In this case, just take the first element of the vector since this is
|
|
|
|
// enough to find vptr races.
|
|
|
|
if (isa<VectorType>(StoredValue->getType()))
|
|
|
|
StoredValue = IRB.CreateExtractElement(
|
|
|
|
StoredValue, ConstantInt::get(IRB.getInt32Ty(), 0));
|
2013-12-05 23:03:02 +08:00
|
|
|
if (StoredValue->getType()->isIntegerTy())
|
|
|
|
StoredValue = IRB.CreateIntToPtr(StoredValue, IRB.getInt8PtrTy());
|
2012-07-05 17:07:31 +08:00
|
|
|
// Call TsanVptrUpdate.
|
2015-05-19 06:13:54 +08:00
|
|
|
IRB.CreateCall(TsanVptrUpdate,
|
|
|
|
{IRB.CreatePointerCast(Addr, IRB.getInt8PtrTy()),
|
|
|
|
IRB.CreatePointerCast(StoredValue, IRB.getInt8PtrTy())});
|
2012-04-23 16:44:59 +08:00
|
|
|
NumInstrumentedVtableWrites++;
|
2012-03-27 01:35:03 +08:00
|
|
|
return true;
|
|
|
|
}
|
[TSan] Add option for emitting compound read-write instrumentation
This adds option -tsan-compound-read-before-write to emit different
instrumentation for the write if the read before that write is omitted
from instrumentation. The default TSan runtime currently does not
support the different instrumentation, and the option is disabled by
default.
Alternative runtimes, such as the Kernel Concurrency Sanitizer (KCSAN)
can make use of the feature. Indeed, the initial motivation is for use
in KCSAN as it was determined that due to the Linux kernel having a
large number of unaddressed data races, it makes sense to improve
performance and reporting by distinguishing compounded operations. E.g.
the compounded instrumentation is typically emitted for compound
operations such as ++, +=, |=, etc. By emitting different reports, such
data races can easily be noticed, and also automatically bucketed
differently by CI systems.
Reviewed By: dvyukov, glider
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83867
2020-07-17 14:53:56 +08:00
|
|
|
if (!IsWrite && isVtableAccess(II.Inst)) {
|
2013-03-22 16:51:22 +08:00
|
|
|
IRB.CreateCall(TsanVptrLoad,
|
|
|
|
IRB.CreatePointerCast(Addr, IRB.getInt8PtrTy()));
|
|
|
|
NumInstrumentedVtableReads++;
|
|
|
|
return true;
|
|
|
|
}
|
[TSan] Add option for emitting compound read-write instrumentation
This adds option -tsan-compound-read-before-write to emit different
instrumentation for the write if the read before that write is omitted
from instrumentation. The default TSan runtime currently does not
support the different instrumentation, and the option is disabled by
default.
Alternative runtimes, such as the Kernel Concurrency Sanitizer (KCSAN)
can make use of the feature. Indeed, the initial motivation is for use
in KCSAN as it was determined that due to the Linux kernel having a
large number of unaddressed data races, it makes sense to improve
performance and reporting by distinguishing compounded operations. E.g.
the compounded instrumentation is typically emitted for compound
operations such as ++, +=, |=, etc. By emitting different reports, such
data races can easily be noticed, and also automatically bucketed
differently by CI systems.
Reviewed By: dvyukov, glider
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83867
2020-07-17 14:53:56 +08:00
|
|
|
|
|
|
|
const unsigned Alignment = IsWrite ? cast<StoreInst>(II.Inst)->getAlignment()
|
|
|
|
: cast<LoadInst>(II.Inst)->getAlignment();
|
|
|
|
const bool IsCompoundRW =
|
|
|
|
ClCompoundReadBeforeWrite && (II.Flags & InstructionInfo::kCompoundRW);
|
|
|
|
const bool IsVolatile = ClDistinguishVolatile &&
|
|
|
|
(IsWrite ? cast<StoreInst>(II.Inst)->isVolatile()
|
|
|
|
: cast<LoadInst>(II.Inst)->isVolatile());
|
|
|
|
assert((!IsVolatile || !IsCompoundRW) && "Compound volatile invalid!");
|
|
|
|
|
2015-03-10 10:37:25 +08:00
|
|
|
const uint32_t TypeSize = DL.getTypeStoreSizeInBits(OrigTy);
|
[opaque pointer types] Add a FunctionCallee wrapper type, and use it.
Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.
Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.
Then:
- update the CallInst/InvokeInst instruction creation functions to
take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.
One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.
However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)
Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.
Differential Revision: https://reviews.llvm.org/D57315
llvm-svn: 352827
2019-02-01 10:28:03 +08:00
|
|
|
FunctionCallee OnAccessFunc = nullptr;
|
2020-04-22 22:01:33 +08:00
|
|
|
if (Alignment == 0 || Alignment >= 8 || (Alignment % (TypeSize / 8)) == 0) {
|
[TSan] Add option for emitting compound read-write instrumentation
This adds option -tsan-compound-read-before-write to emit different
instrumentation for the write if the read before that write is omitted
from instrumentation. The default TSan runtime currently does not
support the different instrumentation, and the option is disabled by
default.
Alternative runtimes, such as the Kernel Concurrency Sanitizer (KCSAN)
can make use of the feature. Indeed, the initial motivation is for use
in KCSAN as it was determined that due to the Linux kernel having a
large number of unaddressed data races, it makes sense to improve
performance and reporting by distinguishing compounded operations. E.g.
the compounded instrumentation is typically emitted for compound
operations such as ++, +=, |=, etc. By emitting different reports, such
data races can easily be noticed, and also automatically bucketed
differently by CI systems.
Reviewed By: dvyukov, glider
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83867
2020-07-17 14:53:56 +08:00
|
|
|
if (IsCompoundRW)
|
|
|
|
OnAccessFunc = TsanCompoundRW[Idx];
|
|
|
|
else if (IsVolatile)
|
2020-04-22 22:01:33 +08:00
|
|
|
OnAccessFunc = IsWrite ? TsanVolatileWrite[Idx] : TsanVolatileRead[Idx];
|
|
|
|
else
|
|
|
|
OnAccessFunc = IsWrite ? TsanWrite[Idx] : TsanRead[Idx];
|
|
|
|
} else {
|
[TSan] Add option for emitting compound read-write instrumentation
This adds option -tsan-compound-read-before-write to emit different
instrumentation for the write if the read before that write is omitted
from instrumentation. The default TSan runtime currently does not
support the different instrumentation, and the option is disabled by
default.
Alternative runtimes, such as the Kernel Concurrency Sanitizer (KCSAN)
can make use of the feature. Indeed, the initial motivation is for use
in KCSAN as it was determined that due to the Linux kernel having a
large number of unaddressed data races, it makes sense to improve
performance and reporting by distinguishing compounded operations. E.g.
the compounded instrumentation is typically emitted for compound
operations such as ++, +=, |=, etc. By emitting different reports, such
data races can easily be noticed, and also automatically bucketed
differently by CI systems.
Reviewed By: dvyukov, glider
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83867
2020-07-17 14:53:56 +08:00
|
|
|
if (IsCompoundRW)
|
|
|
|
OnAccessFunc = TsanUnalignedCompoundRW[Idx];
|
|
|
|
else if (IsVolatile)
|
2020-04-22 22:01:33 +08:00
|
|
|
OnAccessFunc = IsWrite ? TsanUnalignedVolatileWrite[Idx]
|
|
|
|
: TsanUnalignedVolatileRead[Idx];
|
|
|
|
else
|
|
|
|
OnAccessFunc = IsWrite ? TsanUnalignedWrite[Idx] : TsanUnalignedRead[Idx];
|
|
|
|
}
|
2012-02-14 06:50:51 +08:00
|
|
|
IRB.CreateCall(OnAccessFunc, IRB.CreatePointerCast(Addr, IRB.getInt8PtrTy()));
|
[TSan] Add option for emitting compound read-write instrumentation
This adds option -tsan-compound-read-before-write to emit different
instrumentation for the write if the read before that write is omitted
from instrumentation. The default TSan runtime currently does not
support the different instrumentation, and the option is disabled by
default.
Alternative runtimes, such as the Kernel Concurrency Sanitizer (KCSAN)
can make use of the feature. Indeed, the initial motivation is for use
in KCSAN as it was determined that due to the Linux kernel having a
large number of unaddressed data races, it makes sense to improve
performance and reporting by distinguishing compounded operations. E.g.
the compounded instrumentation is typically emitted for compound
operations such as ++, +=, |=, etc. By emitting different reports, such
data races can easily be noticed, and also automatically bucketed
differently by CI systems.
Reviewed By: dvyukov, glider
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83867
2020-07-17 14:53:56 +08:00
|
|
|
if (IsCompoundRW || IsWrite)
|
|
|
|
NumInstrumentedWrites++;
|
|
|
|
if (IsCompoundRW || !IsWrite)
|
|
|
|
NumInstrumentedReads++;
|
2012-02-14 06:50:51 +08:00
|
|
|
return true;
|
|
|
|
}
|
2012-04-27 15:31:53 +08:00
|
|
|
|
|
|
|
static ConstantInt *createOrdering(IRBuilder<> *IRB, AtomicOrdering ord) {
|
|
|
|
uint32_t v = 0;
|
|
|
|
switch (ord) {
|
2016-04-07 05:19:33 +08:00
|
|
|
case AtomicOrdering::NotAtomic:
|
|
|
|
llvm_unreachable("unexpected atomic ordering!");
|
2016-08-17 13:10:15 +08:00
|
|
|
case AtomicOrdering::Unordered: LLVM_FALLTHROUGH;
|
2016-04-07 05:19:33 +08:00
|
|
|
case AtomicOrdering::Monotonic: v = 0; break;
|
|
|
|
// Not specified yet:
|
|
|
|
// case AtomicOrdering::Consume: v = 1; break;
|
|
|
|
case AtomicOrdering::Acquire: v = 2; break;
|
|
|
|
case AtomicOrdering::Release: v = 3; break;
|
|
|
|
case AtomicOrdering::AcquireRelease: v = 4; break;
|
|
|
|
case AtomicOrdering::SequentiallyConsistent: v = 5; break;
|
2012-04-27 15:31:53 +08:00
|
|
|
}
|
2012-11-09 22:12:16 +08:00
|
|
|
return IRB->getInt32(v);
|
2012-04-27 15:31:53 +08:00
|
|
|
}
|
|
|
|
|
2013-03-28 19:21:13 +08:00
|
|
|
// If a memset intrinsic gets inlined by the code gen, we will miss races on it.
|
|
|
|
// So, we either need to ensure the intrinsic is not inlined, or instrument it.
|
|
|
|
// We do not instrument memset/memmove/memcpy intrinsics (too complicated),
|
|
|
|
// instead we simply replace them with regular function calls, which are then
|
|
|
|
// intercepted by the run-time.
|
|
|
|
// Since tsan is running after everyone else, the calls should not be
|
|
|
|
// replaced back with intrinsics. If that becomes wrong at some point,
|
|
|
|
// we will need to call e.g. __tsan_memset to avoid the intrinsics.
|
|
|
|
bool ThreadSanitizer::instrumentMemIntrinsic(Instruction *I) {
|
|
|
|
IRBuilder<> IRB(I);
|
|
|
|
if (MemSetInst *M = dyn_cast<MemSetInst>(I)) {
|
2015-05-19 06:13:54 +08:00
|
|
|
IRB.CreateCall(
|
|
|
|
MemsetFn,
|
|
|
|
{IRB.CreatePointerCast(M->getArgOperand(0), IRB.getInt8PtrTy()),
|
|
|
|
IRB.CreateIntCast(M->getArgOperand(1), IRB.getInt32Ty(), false),
|
|
|
|
IRB.CreateIntCast(M->getArgOperand(2), IntptrTy, false)});
|
2013-03-28 19:21:13 +08:00
|
|
|
I->eraseFromParent();
|
|
|
|
} else if (MemTransferInst *M = dyn_cast<MemTransferInst>(I)) {
|
2015-05-19 06:13:54 +08:00
|
|
|
IRB.CreateCall(
|
|
|
|
isa<MemCpyInst>(M) ? MemcpyFn : MemmoveFn,
|
|
|
|
{IRB.CreatePointerCast(M->getArgOperand(0), IRB.getInt8PtrTy()),
|
|
|
|
IRB.CreatePointerCast(M->getArgOperand(1), IRB.getInt8PtrTy()),
|
|
|
|
IRB.CreateIntCast(M->getArgOperand(2), IntptrTy, false)});
|
2013-03-28 19:21:13 +08:00
|
|
|
I->eraseFromParent();
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2012-11-26 19:36:19 +08:00
|
|
|
// Both llvm and ThreadSanitizer atomic operations are based on C++11/C1x
|
2014-01-25 01:20:08 +08:00
|
|
|
// standards. For background see C++11 standard. A slightly older, publicly
|
2012-11-26 19:36:19 +08:00
|
|
|
// available draft of the standard (not entirely up-to-date, but close enough
|
|
|
|
// for casual browsing) is available here:
|
2012-11-27 00:27:22 +08:00
|
|
|
// http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf
|
2012-11-26 19:36:19 +08:00
|
|
|
// The following page contains more background information:
|
|
|
|
// http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/
|
|
|
|
|
2015-03-10 10:37:25 +08:00
|
|
|
bool ThreadSanitizer::instrumentAtomic(Instruction *I, const DataLayout &DL) {
|
2012-04-27 15:31:53 +08:00
|
|
|
IRBuilder<> IRB(I);
|
|
|
|
if (LoadInst *LI = dyn_cast<LoadInst>(I)) {
|
|
|
|
Value *Addr = LI->getPointerOperand();
|
2021-07-10 00:24:59 +08:00
|
|
|
Type *OrigTy = LI->getType();
|
|
|
|
int Idx = getMemoryAccessFuncIndex(OrigTy, Addr, DL);
|
2012-04-27 15:31:53 +08:00
|
|
|
if (Idx < 0)
|
|
|
|
return false;
|
2015-08-16 03:06:14 +08:00
|
|
|
const unsigned ByteSize = 1U << Idx;
|
|
|
|
const unsigned BitSize = ByteSize * 8;
|
2012-04-27 15:31:53 +08:00
|
|
|
Type *Ty = Type::getIntNTy(IRB.getContext(), BitSize);
|
2012-10-25 01:25:11 +08:00
|
|
|
Type *PtrTy = Ty->getPointerTo();
|
2012-04-27 15:31:53 +08:00
|
|
|
Value *Args[] = {IRB.CreatePointerCast(Addr, PtrTy),
|
|
|
|
createOrdering(&IRB, LI->getOrdering())};
|
2016-11-08 03:09:56 +08:00
|
|
|
Value *C = IRB.CreateCall(TsanAtomicLoad[Idx], Args);
|
|
|
|
Value *Cast = IRB.CreateBitOrPointerCast(C, OrigTy);
|
|
|
|
I->replaceAllUsesWith(Cast);
|
2012-04-27 15:31:53 +08:00
|
|
|
} else if (StoreInst *SI = dyn_cast<StoreInst>(I)) {
|
|
|
|
Value *Addr = SI->getPointerOperand();
|
2021-07-10 00:24:59 +08:00
|
|
|
int Idx =
|
|
|
|
getMemoryAccessFuncIndex(SI->getValueOperand()->getType(), Addr, DL);
|
2012-04-27 15:31:53 +08:00
|
|
|
if (Idx < 0)
|
|
|
|
return false;
|
2015-08-16 03:06:14 +08:00
|
|
|
const unsigned ByteSize = 1U << Idx;
|
|
|
|
const unsigned BitSize = ByteSize * 8;
|
2012-04-27 15:31:53 +08:00
|
|
|
Type *Ty = Type::getIntNTy(IRB.getContext(), BitSize);
|
2012-10-25 01:25:11 +08:00
|
|
|
Type *PtrTy = Ty->getPointerTo();
|
2012-04-27 15:31:53 +08:00
|
|
|
Value *Args[] = {IRB.CreatePointerCast(Addr, PtrTy),
|
2016-11-08 03:09:56 +08:00
|
|
|
IRB.CreateBitOrPointerCast(SI->getValueOperand(), Ty),
|
2012-04-27 15:31:53 +08:00
|
|
|
createOrdering(&IRB, SI->getOrdering())};
|
2014-08-27 13:25:25 +08:00
|
|
|
CallInst *C = CallInst::Create(TsanAtomicStore[Idx], Args);
|
2012-04-27 15:31:53 +08:00
|
|
|
ReplaceInstWithInst(I, C);
|
2012-11-09 20:55:36 +08:00
|
|
|
} else if (AtomicRMWInst *RMWI = dyn_cast<AtomicRMWInst>(I)) {
|
|
|
|
Value *Addr = RMWI->getPointerOperand();
|
2021-07-10 00:24:59 +08:00
|
|
|
int Idx =
|
|
|
|
getMemoryAccessFuncIndex(RMWI->getValOperand()->getType(), Addr, DL);
|
2012-11-09 20:55:36 +08:00
|
|
|
if (Idx < 0)
|
|
|
|
return false;
|
[opaque pointer types] Add a FunctionCallee wrapper type, and use it.
Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.
Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.
Then:
- update the CallInst/InvokeInst instruction creation functions to
take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.
One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.
However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)
Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.
Differential Revision: https://reviews.llvm.org/D57315
llvm-svn: 352827
2019-02-01 10:28:03 +08:00
|
|
|
FunctionCallee F = TsanAtomicRMW[RMWI->getOperation()][Idx];
|
2014-04-25 13:29:35 +08:00
|
|
|
if (!F)
|
2012-11-09 20:55:36 +08:00
|
|
|
return false;
|
2015-08-16 03:06:14 +08:00
|
|
|
const unsigned ByteSize = 1U << Idx;
|
|
|
|
const unsigned BitSize = ByteSize * 8;
|
2012-11-09 20:55:36 +08:00
|
|
|
Type *Ty = Type::getIntNTy(IRB.getContext(), BitSize);
|
|
|
|
Type *PtrTy = Ty->getPointerTo();
|
|
|
|
Value *Args[] = {IRB.CreatePointerCast(Addr, PtrTy),
|
|
|
|
IRB.CreateIntCast(RMWI->getValOperand(), Ty, false),
|
|
|
|
createOrdering(&IRB, RMWI->getOrdering())};
|
2014-08-27 13:25:25 +08:00
|
|
|
CallInst *C = CallInst::Create(F, Args);
|
2012-11-09 20:55:36 +08:00
|
|
|
ReplaceInstWithInst(I, C);
|
|
|
|
} else if (AtomicCmpXchgInst *CASI = dyn_cast<AtomicCmpXchgInst>(I)) {
|
|
|
|
Value *Addr = CASI->getPointerOperand();
|
2021-07-10 00:24:59 +08:00
|
|
|
Type *OrigOldValTy = CASI->getNewValOperand()->getType();
|
|
|
|
int Idx = getMemoryAccessFuncIndex(OrigOldValTy, Addr, DL);
|
2012-11-09 20:55:36 +08:00
|
|
|
if (Idx < 0)
|
|
|
|
return false;
|
2015-08-16 03:06:14 +08:00
|
|
|
const unsigned ByteSize = 1U << Idx;
|
|
|
|
const unsigned BitSize = ByteSize * 8;
|
2012-11-09 20:55:36 +08:00
|
|
|
Type *Ty = Type::getIntNTy(IRB.getContext(), BitSize);
|
|
|
|
Type *PtrTy = Ty->getPointerTo();
|
2016-03-08 07:16:23 +08:00
|
|
|
Value *CmpOperand =
|
2016-11-08 03:09:56 +08:00
|
|
|
IRB.CreateBitOrPointerCast(CASI->getCompareOperand(), Ty);
|
2016-03-08 07:16:23 +08:00
|
|
|
Value *NewOperand =
|
2016-11-08 03:09:56 +08:00
|
|
|
IRB.CreateBitOrPointerCast(CASI->getNewValOperand(), Ty);
|
2012-11-09 20:55:36 +08:00
|
|
|
Value *Args[] = {IRB.CreatePointerCast(Addr, PtrTy),
|
2016-03-08 07:16:23 +08:00
|
|
|
CmpOperand,
|
|
|
|
NewOperand,
|
2014-03-11 18:48:52 +08:00
|
|
|
createOrdering(&IRB, CASI->getSuccessOrdering()),
|
|
|
|
createOrdering(&IRB, CASI->getFailureOrdering())};
|
IR: add "cmpxchg weak" variant to support permitted failure.
This commit adds a weak variant of the cmpxchg operation, as described
in C++11. A cmpxchg instruction with this modifier is permitted to
fail to store, even if the comparison indicated it should.
As a result, cmpxchg instructions must return a flag indicating
success in addition to their original iN value loaded. Thus, for
uniformity *all* cmpxchg instructions now return "{ iN, i1 }". The
second flag is 1 when the store succeeded.
At the DAG level, a new ATOMIC_CMP_SWAP_WITH_SUCCESS node has been
added as the natural representation for the new cmpxchg instructions.
It is a strong cmpxchg.
By default this gets Expanded to the existing ATOMIC_CMP_SWAP during
Legalization, so existing backends should see no change in behaviour.
If they wish to deal with the enhanced node instead, they can call
setOperationAction on it. Beware: as a node with 2 results, it cannot
be selected from TableGen.
Currently, no use is made of the extra information provided in this
patch. Test updates are almost entirely adapting the input IR to the
new scheme.
Summary for out of tree users:
------------------------------
+ Legacy Bitcode files are upgraded during read.
+ Legacy assembly IR files will be invalid.
+ Front-ends must adapt to different type for "cmpxchg".
+ Backends should be unaffected by default.
llvm-svn: 210903
2014-06-13 22:24:07 +08:00
|
|
|
CallInst *C = IRB.CreateCall(TsanAtomicCAS[Idx], Args);
|
2016-03-08 07:16:23 +08:00
|
|
|
Value *Success = IRB.CreateICmpEQ(C, CmpOperand);
|
|
|
|
Value *OldVal = C;
|
|
|
|
if (Ty != OrigOldValTy) {
|
|
|
|
// The value is a pointer, so we need to cast the return value.
|
|
|
|
OldVal = IRB.CreateIntToPtr(C, OrigOldValTy);
|
|
|
|
}
|
IR: add "cmpxchg weak" variant to support permitted failure.
This commit adds a weak variant of the cmpxchg operation, as described
in C++11. A cmpxchg instruction with this modifier is permitted to
fail to store, even if the comparison indicated it should.
As a result, cmpxchg instructions must return a flag indicating
success in addition to their original iN value loaded. Thus, for
uniformity *all* cmpxchg instructions now return "{ iN, i1 }". The
second flag is 1 when the store succeeded.
At the DAG level, a new ATOMIC_CMP_SWAP_WITH_SUCCESS node has been
added as the natural representation for the new cmpxchg instructions.
It is a strong cmpxchg.
By default this gets Expanded to the existing ATOMIC_CMP_SWAP during
Legalization, so existing backends should see no change in behaviour.
If they wish to deal with the enhanced node instead, they can call
setOperationAction on it. Beware: as a node with 2 results, it cannot
be selected from TableGen.
Currently, no use is made of the extra information provided in this
patch. Test updates are almost entirely adapting the input IR to the
new scheme.
Summary for out of tree users:
------------------------------
+ Legacy Bitcode files are upgraded during read.
+ Legacy assembly IR files will be invalid.
+ Front-ends must adapt to different type for "cmpxchg".
+ Backends should be unaffected by default.
llvm-svn: 210903
2014-06-13 22:24:07 +08:00
|
|
|
|
2016-03-08 07:16:23 +08:00
|
|
|
Value *Res =
|
|
|
|
IRB.CreateInsertValue(UndefValue::get(CASI->getType()), OldVal, 0);
|
IR: add "cmpxchg weak" variant to support permitted failure.
This commit adds a weak variant of the cmpxchg operation, as described
in C++11. A cmpxchg instruction with this modifier is permitted to
fail to store, even if the comparison indicated it should.
As a result, cmpxchg instructions must return a flag indicating
success in addition to their original iN value loaded. Thus, for
uniformity *all* cmpxchg instructions now return "{ iN, i1 }". The
second flag is 1 when the store succeeded.
At the DAG level, a new ATOMIC_CMP_SWAP_WITH_SUCCESS node has been
added as the natural representation for the new cmpxchg instructions.
It is a strong cmpxchg.
By default this gets Expanded to the existing ATOMIC_CMP_SWAP during
Legalization, so existing backends should see no change in behaviour.
If they wish to deal with the enhanced node instead, they can call
setOperationAction on it. Beware: as a node with 2 results, it cannot
be selected from TableGen.
Currently, no use is made of the extra information provided in this
patch. Test updates are almost entirely adapting the input IR to the
new scheme.
Summary for out of tree users:
------------------------------
+ Legacy Bitcode files are upgraded during read.
+ Legacy assembly IR files will be invalid.
+ Front-ends must adapt to different type for "cmpxchg".
+ Backends should be unaffected by default.
llvm-svn: 210903
2014-06-13 22:24:07 +08:00
|
|
|
Res = IRB.CreateInsertValue(Res, Success, 1);
|
|
|
|
|
|
|
|
I->replaceAllUsesWith(Res);
|
|
|
|
I->eraseFromParent();
|
2012-11-09 20:55:36 +08:00
|
|
|
} else if (FenceInst *FI = dyn_cast<FenceInst>(I)) {
|
|
|
|
Value *Args[] = {createOrdering(&IRB, FI->getOrdering())};
|
[opaque pointer types] Add a FunctionCallee wrapper type, and use it.
Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.
Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.
Then:
- update the CallInst/InvokeInst instruction creation functions to
take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.
One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.
However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)
Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.
Differential Revision: https://reviews.llvm.org/D57315
llvm-svn: 352827
2019-02-01 10:28:03 +08:00
|
|
|
FunctionCallee F = FI->getSyncScopeID() == SyncScope::SingleThread
|
|
|
|
? TsanAtomicSignalFence
|
|
|
|
: TsanAtomicThreadFence;
|
2014-08-27 13:25:25 +08:00
|
|
|
CallInst *C = CallInst::Create(F, Args);
|
2012-11-09 20:55:36 +08:00
|
|
|
ReplaceInstWithInst(I, C);
|
2012-04-27 15:31:53 +08:00
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2021-07-10 00:24:59 +08:00
|
|
|
int ThreadSanitizer::getMemoryAccessFuncIndex(Type *OrigTy, Value *Addr,
|
2015-03-10 10:37:25 +08:00
|
|
|
const DataLayout &DL) {
|
2012-04-27 15:31:53 +08:00
|
|
|
assert(OrigTy->isSized());
|
2021-07-10 00:24:59 +08:00
|
|
|
assert(
|
|
|
|
cast<PointerType>(Addr->getType())->isOpaqueOrPointeeTypeMatches(OrigTy));
|
2015-03-10 10:37:25 +08:00
|
|
|
uint32_t TypeSize = DL.getTypeStoreSizeInBits(OrigTy);
|
2012-04-27 15:31:53 +08:00
|
|
|
if (TypeSize != 8 && TypeSize != 16 &&
|
|
|
|
TypeSize != 32 && TypeSize != 64 && TypeSize != 128) {
|
|
|
|
NumAccessesWithBadSize++;
|
|
|
|
// Ignore all unusual sizes.
|
|
|
|
return -1;
|
|
|
|
}
|
2013-05-25 06:23:49 +08:00
|
|
|
size_t Idx = countTrailingZeros(TypeSize / 8);
|
2012-04-27 15:31:53 +08:00
|
|
|
assert(Idx < kNumberOfAccessSizes);
|
|
|
|
return Idx;
|
|
|
|
}
|