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

[Daniel Berlin <dberlin at dberlin dot org>]

On Wed, Apr 1, 2009 at 5:12 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> 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).
>

All true, but look at this way:

At O1, objects_must_conflict is returning 1 (causing it to not add an
aliasing conflict and share the slots)
At O2, objects_must_conflict is returning 0 (causing it to add an
aliasing conflict and not share the slots)

Either the objects conflict or they don't. Conservatively, it needs to
return the answer that *doesn't* allow sharing, which it clearly is
*not* doing.

--Dan