Re: [tsan] ThreadSanitizer instrumentation part

[Xinliang David Li <davidxl at google dot com>]

On Thu, Nov 1, 2012 at 1:47 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Thu, Nov 01, 2012 at 12:34:54PM -0700, Xinliang David Li wrote:
>> On Thu, Nov 1, 2012 at 12:16 PM, Jakub Jelinek <jakub@redhat.com> wrote:
>> > On Thu, Nov 01, 2012 at 11:57:21AM -0700, Xinliang David Li wrote:
>> >> That is exactly related to tsan -- it should skip local variable that
>> >> is not address taken (though still addressable, which by addressable,
>> >> it means the variable has a memory home).
>> >>
>> >> The problem is that if 'addressable' bit is not equivalent to 'address
>> >> taken', it will be too conservative to use it --- as addressable
>> >> variables may not be address taken.
>> >
>> > But TREE_ADDRESSABLE is equivalent to address taken.
>>
>> It seems not -- unless our definition of them is different. I debugged
>> the following program:
>>
>>
>> int foo()
>> {
>>   int a[1000];
>>   int i, s;
>>
>>   for (i = 0; i < 1000; i++)
>>     a[i] = i;
>>
>>   for (i = 0; i < 1000; i++)
>>     s += a[i];
>>
>>    return s;
>> }
>>
>> a's address is not taken (at source level), but it is marked as addressable.
>
> The question is when you are looking at TREE_ADDRESSABLE.  Sure, the FE
> marks it as TREE_ADDRESSABLE conservatively, but if you compile with -O2,
> in execute_update_addresses_taken called after the ccp pass TREE_ADDRESSABLE
> is cleared.  I thought the tsan pass was scheduled much later than that
> (around PRE pass).

I looked at it pretty late in the pipeline -- during cfgexpand and I
had specified -O2 in the command line.

>
>> > If you need it even less conservative, I guess you could do say:
>> >   struct ptr_info_def pi;
>> >   memset (&pi, 0, sizeof (pi));
>> >   pi.escaped = 1;
>> >   pi.nonlocal = 1;
>> >   return pt_solution_includes (&pi, decl);
>> >
>>
>> That will be nice.  Are points-to info exposed to client code like
>> this? Are there standard aliaser interfaces for them?
>
> pt_solution_includes is exported interface, though we'd need to ask richi
> when he returns whether he is fine with such an use.

yes, It is better to wrap it up in a simpler interface.

David


>
>         Jakub