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 <[email protected]> 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).
> > 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.
Jakub
