This is the mail archive of the
mailing list for the GCC project.
Re: PATCH: tree-ssa-sink breaks stack layout
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Richard Guenther <richard dot guenther at gmail dot com>
- Cc: Eric Botcazou <ebotcazou at adacore dot com>, gcc-patches at gcc dot gnu dot org, Sandra Loosemore <sandra at codesourcery dot com>
- Date: Wed, 1 Apr 2009 09:58:36 -0400
- Subject: Re: PATCH: tree-ssa-sink breaks stack layout
- References: <49D25676.firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com>
On Wed, Apr 1, 2009 at 5:12 AM, Richard Guenther
> On Wed, Apr 1, 2009 at 2:27 AM, Daniel Berlin <firstname.lastname@example.org> wrote:
>> On Tue, Mar 31, 2009 at 6:04 PM, Eric Botcazou <email@example.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