Re: PATCH: tree-ssa-sink breaks stack layout

[Richard Guenther <richard dot guenther at gmail dot com>]

On Wed, Apr 1, 2009 at 2:27 AM, Daniel Berlin <dberlin@dberlin.org> wrote:
> On Tue, Mar 31, 2009 at 6:04 PM, Eric Botcazou <ebotcazou@adacore.com> wrote:
>>> Well, no, it is a *real* bug that it claims the two objects
>>> must-conflict and decides they can share a space when we have no
>>> informatin available to substantiate this
>>
>> We're at -O1 so it's true that the objects must-conflict in the alias.c sense.
>
> alias.c uses conflict as a synonym for the word "alias" in almost all
> places, and there is no documentation elsewhere, so uh, claiming i'm
> "changing the definition" seems a bit much, that said ...
>
>> The code thinks that if the blocks are different and the objects must-conflict
>> then it's enough to conclude that the slots can be shared. ?That's wrong.
>>
>> You seem to be proposing to change the definition of must-conflict;
>> ?it seems
>> to me (and that was the conclusion of the discussion in PR middle-end/32327)
>> that the problem is rather in the "if the blocks are different".
> This is independent of the fact that it's clearly missing an aliasing
> conflict above.
> Then again, I have no dog in this fight, I can happily wait till you
> fix this with live range info and then discover it's still borked
> because it is using alias information wrong :)

This alias sets are conflicting check was added for the very same reason - to
paper over bugs that may appear otherwise due to RTL scheduling of loads/stores
which may make life-ranges of stack variables which share their stack slot
overlapping.  The theory is that the scheduler won't do such thing if the
alias sets conflict (which is of course not exactly true if you can disambiguate
using offsets, so you can still get overlapping lifetime of a whole struct just
not individual parts ... if that will break anything is another question).

Richard.