This is an archive of the discontinued LLVM Phabricator instance.

[TSAN] Add option to allow instrumenting reads of reads-before-writes
ClosedPublic

Authored by melver on May 14 2020, 11:56 PM.

Details

Reviewers
dvyukov
glider
Summary

Add -tsan-instrument-read-before-write which allows instrumenting reads
of reads-before-writes.

This is required for KCSAN [1], where under certain configurations plain
writes behave differently (e.g. aligned writes up to word size may be
treated as atomic). In order to avoid missing potential data races due
to plain RMW operations ("x++" etc.), we will require instrumenting
reads of reads-before-writes.

[1] https://github.com/google/ktsan/wiki/KCSAN

Diff Detail

Event Timeline

melver created this revision.May 14 2020, 11:56 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 14 2020, 11:56 PM

Maybe this flag should turn off instrumentation of the "atomic" writes? Then the "reads-before-write" are not before writes anymore and will be naturally instrumented. And we also get faster execution. What do you think?

Maybe this flag should turn off instrumentation of the "atomic" writes? Then the "reads-before-write" are not before writes anymore and will be naturally instrumented. And we also get faster execution. What do you think?

Do you mean putting some of KCSAN's logic to determine what are "atomic" writes here? For one, I don't think it's reliable because the logic in KCSAN may change again and we shouldn't make any code here be KCSAN-specific.

The other thing is that conflicts between "atomic write" and "plain read" will be missed.

Or did I misunderstand what you meant?

Maybe this flag should turn off instrumentation of the "atomic" writes? Then the "reads-before-write" are not before writes anymore and will be naturally instrumented. And we also get faster execution. What do you think?

Do you mean putting some of KCSAN's logic to determine what are "atomic" writes here? For one, I don't think it's reliable because the logic in KCSAN may change again and we shouldn't make any code here be KCSAN-specific.

The other thing is that conflicts between "atomic write" and "plain read" will be missed.

Or did I misunderstand what you meant?

Based on offline discussion my comment is withdrawn.

dvyukov accepted this revision.May 15 2020, 2:44 AM
This revision is now accepted and ready to land.May 15 2020, 2:44 AM