This is an archive of the discontinued LLVM Phabricator instance.

Tread TSan LLVM flags to driver: account for external flag values in TSan.
ClosedPublic

Authored by alekseyshl on Nov 9 2016, 9:49 AM.

Details

Reviewers
dvyukov
eugenis
Summary

Tread TSan LLVM flags to driver: account for external flag values in TSan.

Event Timeline

alekseyshl updated this revision to Diff 77365.Nov 9 2016, 9:49 AM
alekseyshl retitled this revision from to Tread TSan LLVM flags to driver: account for external flag values in TSan..
alekseyshl updated this object.
alekseyshl added a reviewer: eugenis.
alekseyshl added a subscriber: llvm-commits.
eugenis accepted this revision.Nov 9 2016, 11:38 AM
eugenis edited edge metadata.

LGTM

This revision is now accepted and ready to land.Nov 9 2016, 11:38 AM
pcc added a subscriber: pcc.Nov 9 2016, 12:07 PM

Could/should these be function attributes rather than pass arguments?

dvyukov edited edge metadata.Nov 9 2016, 2:59 PM

Could/should these be function attributes rather than pass arguments?

The use that we have for these flags is related to ignoring atomics in a huge source file, applying attributes to all functions in that file is impractical.
We have similar compiler flags for other sanitizers as well.
We could add attributes along with flags, but we don't have any uses for that at the moment.

lib/Transforms/Instrumentation/ThreadSanitizer.cpp
85–96

Do we need default parameter values here? I would expect that not.

114

I would make them const as they are initialized only in ctor and are not meant to change.

dvyukov accepted this revision.Nov 9 2016, 2:59 PM
dvyukov edited edge metadata.

LGTM with nits

pcc added a comment.Nov 9 2016, 3:45 PM

We could add attributes along with flags, but we don't have any uses for that at the moment.

The use case I have in mind is to make the sanitizers work better with LTO by running the sanitizer passes at link time. That would require that we preserve the flag settings in bitcode. Granted this isn't how things work right now, but it may be worth making it easier to get there given that these are new flags.

Attribute is definitely the right long term solution, but it would be more efficient to move all sanitizer options to attributes in bulk. It also adds overhead (possibly tiny) compared to the pass argument approach, so it only makes sense to do if we plan to move instrumentation passes to the link stage right away. I don't think we want to work on that right now.

So the question is, do we want this temporary implementation, or are we fine with -mllvm flags? Seeing as the code is already written, I'd prefer to land this change now.

pcc added a comment.Nov 9 2016, 5:21 PM

There are a couple of intermediate steps towards making the flags you're introducing in D26461 work correctly with LTO:

  1. teach the clang driver to understand the flags
  2. thread the flags down to the pass via attributes

What I would suggest is that we could initially take step 1 by having the driver translate -fsanitize-thread-* flags to -mllvm flags for the frontend, and take step 2 in a separate change.

alekseyshl updated this revision to Diff 77433.Nov 9 2016, 6:05 PM
alekseyshl marked an inline comment as done.
alekseyshl edited edge metadata.
  • Rename params to match their functionality.
alekseyshl added inline comments.Nov 9 2016, 6:07 PM
lib/Transforms/Instrumentation/ThreadSanitizer.cpp
85–96

Yes, we do. FunctionPass is expected to have a zero arg ctor (see PassSupport.h, callDefaultCtor).

LGTM on my side
I don't know what amount of work is changing flags to attributes.

This patch is not necessary anymore, D26461 uses legacy -llvm flags now.

eugenis closed this revision.Nov 28 2016, 1:32 PM

r286670