Aliasing patch for tree-optimization/28778

Daniel Berlin dberlin@dberlin.org
Sat Aug 26 18:12:00 GMT 2006


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



More information about the Gcc-patches mailing list