[PATCH] D83625: [TSan] Optimize handling of racy address

Dmitry Vyukov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jul 15 08:31:27 PDT 2020


dvyukov added a comment.

In D83625#2153333 <https://reviews.llvm.org/D83625#2153333>, @protze.joachim wrote:

> > Right, it can do more harm.
>
> What do you think about comparing the local stack against the two hashes in racy_stacks?
>  I would propably have this defaulting to false unless we find it convenient for the typical usecase.


I would avoid doing this right now because the use case for this is moot, and this is additional code, code reviews and slowdown.

>>> Also, I plan to add a `suppress_max_stack_depth=n` flag. The `HandleRacyStacks` function will only compare the top n frames in this case.
>>>  For race in recursive algorithms, this will allow to remove duplicates with different recursion depth. (For OpenMP, this specifically helps for tasking programs)
>> 
>> What will be the default? What is the useful value for OpenMP programs?
> 
> My suggestion for the default is infinite / MAX_INT, i.e. not change existing behavior.

And what do you plan to use/suggest for openmp? I am asking because if it's, say, 50, then we could probably simply make it the default and no flag at all. But if it's 5, then probably we can't.

> Is there a runtime interface to adjust the flags? This would allow libarcher to tweak this flag during initialization, and I could also choose different defaults for other flags.
>  I always suggest `ignore_noninstrumented_modules=1` for OpenMP and Fortran codes to suppress false reports from libomp and libgfortran.

No, I don't think there such interface.
There is something like __default_options global var. It's supposed for end program (b/c there can be only 1). It also needs to override the weak definition we have in the runtime.
You may try. If we are super lucky then it may work and end program may even be able to override it again. But it all will depend on how the openmp library is linked.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D83625/new/

https://reviews.llvm.org/D83625





More information about the llvm-commits mailing list