Aliasing patch for tree-optimization/28778

Daniel Jacobowitz drow@false.org
Sat Aug 26 14:31:00 GMT 2006


On Sat, Aug 26, 2006 at 03:01:23AM -0400, Daniel Berlin wrote:
> he real problem here is that for some reason we don't believe SMT.5
> may-aliases blist.0, so the escaping code never marks blist.0 as being
> call clobbered.
> 
> Note that if you look at the aliasing dump, it says
> 
> find: Total number of aliased vops: 0
> 
> This is wrong, and likely triggers some if aliased_vops != 0 check
> somewhere causing the underlying issue of not putting things into
> SMT.5's may-alias list.

If you change the type of the argument from long back to int, then
you get:

find: Total number of aliased vops: 0

Variable: list, UID 1873, int[32], is aliased, is addressable, call
clobbered, default def: list_4

Variable: SMT.4, UID 1882, const int, is addressable, is global, call
clobbered, may aliases: { list }

It's correct but there are still no aliased vops.  So I'm not convinced
that will help.

> Part of the reason the code was rewritten was to separate the idea of
> points-to and call clobbering and compute both properly :).

So I guess this comment is stale?

  /* For each pointer P_i, determine the sets of variables that P_i may
     point-to.  For every addressable variable V, determine whether the
     address of V escapes the current function, making V call-clobbered
     (i.e., whether &V is stored in a global variable or if its passed as a
     function call argument).  */
  compute_points_to_sets (ai);

Since it surely fails to figure out whether &list escapes.  It only
marks escape sites, and call clobbering doesn't happen till later.

> If not, you also have to get it to properly put blist.0 on SMT.5's
> may-alias list.

It seems like this should happen in compute_flow_insensitive_aliasing,
where we compare the set of addressable variables to the set of
pointers.  There's one pointer (blist.0) and one addressable variable
(list). But may_alias_p returns false, because TBAA says that the alias
sets are not compatible.

So I suppose that if the value (blist.0) escapes, we can't trust TBAA.
Within a function, if blist.0 were dereferenced it would be a TBAA
violation (I really wonder how useful that is sometimes), and if it is
cast back to a valid type then that pointer would show up in the
pointer list and we'd handle it there where TBAA wouldn't complain. 
But here we don't know what might happen to blist.0, so it could be
valid elsewhere.

I don't see a handy way to figure out if blist.0 escapes; the best I
can think of would be to walk all associated SSA names and check their
pointer info, but that's gross.  There's room for plenty of flag bits
in var_ann, though, so I could record it there as value_escapes
whenever we set a pointer's escape mask.

I'll try that.  Meanwhile, is my logic vaguely correct?

-- 
Daniel Jacobowitz
CodeSourcery



More information about the Gcc-patches mailing list