Profiling and GCOV generate known data-racy loads/stores. Pretend they
are atomic so that analysis using PC-keyed metadata for atomics do not
report them as data races (which would look like false positives).
Details
Details
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Comment Actions
We also discussed that msan/asan shadow accesses need to be ignored.
MSan accesses can lead to false positives, ASan just to unnecessary checking.
It can also make sense to exclude accesses to global const objects.
Comment Actions
Good points - will add in a future patch. Identifying sanitizer accesses is not obvious, probably need to add some more metadata in sanitizer passes.
Comment Actions
TSan pass has these checks, probably can just copy-paste these:
if (addrPointsToConstantData(Addr)) { // Addr points to some constant data -- it can not race with any writes. continue; } if (isa<AllocaInst>(getUnderlyingObject(Addr)) && !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; }