This is the mail archive of the
mailing list for the GCC project.
Re: [tsan] Instrument atomics
On Mon, Nov 26, 2012 at 12:35 AM, Jakub Jelinek <firstname.lastname@example.org> wrote:
> On Mon, Nov 26, 2012 at 12:17:44PM +0400, Dmitry Vyukov wrote:
>> On Sat, Nov 24, 2012 at 12:58 PM, Dmitry Vyukov <email@example.com> wrote:
>> >>> Ok. A slight problem then is that where the tsan pass sits right now, there
>> >>> is no easy way to find out if the builtin call will be expanded inline or
>> >>> not, so (similar for asan), if we instrument them in the pass, it might be
>> >>> instrumented twice at runtime if the builtin is expanded as a library call
>> >>> (once the added instrumentation for the builtin, once in the intercepted
>> >>> library call). That isn't wrong, just might need slightly more resources
>> >>> than if we ensured we only instrument the builtin if it isn't expanded
>> >>> inline.
>> >> Should inlining of those functions be disabled as if -fno-builtins is specified?
>> > Yes, it sounds reasonable. Performance characteristics under tsan
>> > differ significantly, so most likely we don't care.
>> Do we still need range access functions then?
> Yes. I think whether to instrument builtins inline or not should be a user
Why is that? Most users probably are not aware builtins can be inlined
or care about it.
>, -fsanitize-thread and either nothinng or -fno-builtin. Implying
> -fno-builtin might penalize some code unnecessarily (remember, builtin
> handling is not only about expanding some builtins inline, but also about
> folding them if they are used with constant arguments, performing all sorts
> of optimizations etc.,
Yes, in some cases, it can incur a little runtime overhead as
memset(&i, 1, 4);
but I think compared with tsan's runtime overhead, this is almost negligible.
> all of which are ok, just we don't have a knob to
> disable inline expansion of some builtins (which, some are certainly ok,
> e.g. those that don't have a library counterpart).
There is an internal interface to call:
disable_builtin_function (...) -- tsan option process can call it
selectively for the stringop related builtins.
> Also note that many programs use __builtin_* calls directly and then you
> can't disable recognizing them as builtins.
Those calls won't be affected, I think. Compiler can also directly
generate builtin calls. However that means the range checking is still