This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tsan] Instrument atomics


On Mon, Nov 26, 2012 at 12:35 AM, Jakub Jelinek <jakub@redhat.com> 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 <dvyukov@google.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
> decision

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

int i;
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
needed.

David


>
>         Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]