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

-- 
Daniel Jacobowitz
CodeSourcery


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