Re: Aliasing patch for tree-optimization/28778

[Daniel Berlin <dberlin at dberlin dot org>]

Daniel Jacobowitz wrote:
> 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.
> 
Unfortunately, this is going to be a mild pain in the ass to fix, and
require some escaping rewrite.

I'll take care of it, but it might be better to put off till 4.3