This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [tsan] ThreadSanitizer instrumentation part
- From: Xinliang David Li <davidxl at google dot com>
- To: Dmitry Vyukov <dvyukov at google dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, Wei Mi <wmi at google dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Diego Novillo <dnovillo at google dot com>, Dodji Seketeli <dodji at redhat dot com>
- Date: Thu, 1 Nov 2012 11:19:55 -0700
- Subject: Re: [tsan] ThreadSanitizer instrumentation part
- References: <CAAkRFZK0vZPCvR3W0AsDZGK463FGeiRdpt1gfPdnRsLePeEO1g@mail.gmail.com> <CACT4Y+azNYV+8ieRthd-SkQqGO82dj2+JOdL5c15DyBc9LwyfA@mail.gmail.com> <CACT4Y+YQDBVxL2GdK9o-8kn===1XzX9JaBJUpM5N4MYCJAeo=Q@mail.gmail.com>
On Thu, Nov 1, 2012 at 11:16 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
> On Thu, Nov 1, 2012 at 10:14 PM, Dmitry Vyukov <dvyukov@google.com> wrote:
>>>
>>> >> > On Wed, Oct 31, 2012 at 11:00:17PM -0700, Xinliang David Li wrote:
>>> >> >> > + /* Below are things we do not instrument
>>> >> >> > + (no possibility of races or not implemented yet). */
>>> >> >> > + if (/* Compiler-emitted artificial variables. */
>>> >> >> > + (DECL_P (expr) && DECL_ARTIFICIAL (expr))
>>> >> >> > + /* The var does not live in memory -> no possibility of
>>> >> >> > races.
>>> >> >> > */
>>> >> >> > + || (tcode == VAR_DECL
>>> >> >> > + && TREE_ADDRESSABLE (expr) == 0
>>> >> >>
>>> >> >> ==> !TREE_ADDRESSABLE (expr)
>>> >> >>
>>> >> >> > + && TREE_STATIC (expr) == 0)
>>> >> >>
>>> >> >>
>>> >> >> To detect stack varaible, TREE_STATIC can not be used. Use
>>> >> >> !DECL_EXTERNAL instead.
>>> >> >
>>> >> > TREE_STATIC is right for that.
>>> >>
>>> >> Hmm, what does this condition try to capture then?
>>> >
>>> >
>>> >
>>> > As far as I remember, I've seen global variables marked as
>>> > !ADDRESSABLE. And
>>> > this condition is to instrument global vars in any case.
>>> > But it was a long time ago.
>>>
>>> But it skips those globals without static storage and marked as not
>>> addressable.
>>>
>>> It seems to me you want to skip all stack local variables that are not
>>> address escaped.
>>
>>
>> Yes, that's correct. I am pretty sure I implemented it incorrectly :)
>
>
>
> The high-level intention is to skip memory accesses that can't constitute a
> data race.
> Originally there were some other checks, e.g. check for loads from vtable.
>
That should be caught by the is_load_const check there.
David
>
>
>>
>>
>>>
>>> Without address escape analysis, the address taken
>>> bit (not the same as addressable attribute) should be used. As far as
>>> I can tell, such bit is not available in var_decl. The varpool_node
>>> has one, but it is only for var_decls with static storage. It is also
>>> unfortunate that there is no single bit to test if a variable is
>>> function auto, though there is an interface to call which is
>>> 'auto_var_in_fn_p (...)'. The condition to skip such variable
>>> references are:
>>>
>>> if (tcode == VAR_DECL && auto_var_in_fn_p (expr, ..) &&
>>> !address_taken (expr))
>>>
>>> The TREE_ADDRESSABLE check seems redundant -- if the var_decl (instead
>>> of ssa name) appears in the assignment, why would it not be
>>> 'addressable'? And being addressable does not mean it is address taken
>>> either.
>>>
>>> Diego, is there a way to check address taken attribute for auto vars?
>>>
>>> thanks,
>>>
>>> David
>>
>>
>