This is the mail archive of the
mailing list for the GCC project.
Re: Aliasing patch for tree-optimization/28778
On Sat, Aug 26, 2006 at 10:08:50AM -0400, Daniel Jacobowitz wrote:
> 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?
FWIW, it does fix the test case, but I'm not convinced that I can query
"does the pointer escape" safely so early. That SSA_NAME might not
escape, but end up stored in something which does; we won't figure that
out until after flow insensitive aliasing is done, I don't think. Not
sure I've made any progress here.