[PATCH] tsan: do not instrument not captured values

[Chandler Carruth]

On Thu, Jan 22, 2015 at 12:25 AM, Dmitry Vyukov <dvyukov at google.com> wrote:

> On Thu, Jan 22, 2015 at 11:14 AM, Chandler Carruth <chandlerc at google.com>
> wrote:
> >
> > On Wed, Jan 21, 2015 at 11:38 PM, Dmitry Vyukov <dvyukov at google.com>
> wrote:
> >>
> >> You are right.
> >> But this optimization is too fruitful to just discard it. So fruitful
> >> (-40% of instrumentation in a large webrtc test) that I am inclining
> >> towards ignoring the possibility of passing the object using relaxed
> >> atomics... On the other hand people do mess memory ordering, so losing
> >> these races is pity as well...
> >
> >
> > It would make me very sad to lose this feature of TSan. Of all the subtle
> > racy-queue techniques I have seen or heard of over the years, the one I
> > cited is actually one of the few that I have seen debugged specifically
> > through the use of TSan.
> >
> > I also fear losing it in small part because it is a specific portability
> > risk between x86 and weak memory architectures, one of the biggest
> features
> > of TSan for me.
> >
> > But it's wild that this is 40% of the instrumentation in a large webrtc
> > test. That seems to clearly indicate that there is *something* to be done
> > here, but I don't know yet what that is... so:
> >
> >>
> >> Maybe we can figure out a way to get both at least in most cases.
> >
> >
> > That would be my hope as well. =]
> >
> >>
> >> Few
> >> observations:
> >> 1. Leaking of stack objects to other threads is very infrequent (I
> >> would say 1%).
> >
> >
> > Infrequent relative to *captured* stack objects? Yes, but I'm not sure
> how
> > infrequent really. Mostly this is because I expect most stack objects to
> > never be captured.
>
> If I do:
>
> std::string s(...);
> s.find(...);
>
> and find is not inlined, but ctor is inlined. Is not it the case that
> s is captured, but stores in ctor can elided by this optimization?


Let's sort this out first... Might just be a terminology confusion.

This shouldn't imply capturing in the strictest sense. It should just
involve escape. For a more precise definition of what LLVM at least means
by capture (unsure if this term is used elsewhere in the literature) see
the comment at the top of the file:
http://llvm.org/docs/doxygen/html/CaptureTracking_8cpp_source.html

Inherently, memory whose address isn't captured but is just escaped can't
be used by another thread. So for nocapture pointers, I think we can
eliminate *all* the instrumentation. Does that make sense?

My current understanding is that for conservatively correct stuff we need
to instrument the last write to memory prior to its first capture, and no
writes (or reads) prior to that last write. Maybe just skipping
escaped-but-nocapture would be enough to get most of the benefit here? Or
maybe LLVM is missing really important cases that are actually nocapture?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150122/afe8f75b/attachment.html>