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] ThreadSanitizer instrumentation part


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
>>
>>
>


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