This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Wed, Apr 1, 2009 at 12:08 PM, Michael Matz <> wrote:
> Hi,
> On Wed, 1 Apr 2009, Daniel Berlin wrote:
>> >> Yes, so when it doesn't have type-based info to the contrary, it
>> >> should be saying they may not share stack slots, instead, it says
>> >> they can.
>> >
>> > Well, it also doesn't have type-based info to later break in the face
>> > of stack slot sharing, so it says "safe!". ?No longer true if we start
>> > to use PTA info or any other clever non-TBAA disambiguation of course.
>> I completely agree that nothing later than stack slot sharing should be
>> breaking this sharing in the face of the aliasing info it has. However,
>> my point is that stack slot sharing *itself* is breaking it by saying it
>> can share them based on this aliasing info :)
> Well, it can because nothing later will break it (and the sharing itself
> is no transformation). ?It all breaks down only because the sharing is
> invalid, not because of the aliasing info, but because of the unfulfilled
> prerequisite that stack variables are only accessed in basic blocks that
> belong to the tree BLOCK that variable is declared in.
> Changing the aliasing routines to return "non-must alias" on
> -fno-strict-aliasing would work around the specific problem triggering
> this discussion, granted. ?But it neither would be a bug fix (as not the
> aliasing info induces the breakage)

I disagree that it is not a bug fix, since the aliasing info it is
returning is still wrong, and fixing it would fix the problem here.
It claims the objects must-conflict at O1. That is false. They are
may-conflict at O1.

>  nor would it fix the real problem.

The other posited solutions are to use live range info.
Given that you can have pointers into stack space, you are still going
to have to use correct aliasing info to get this right with live
ranges :)

> But OTOH I think we more or less all agree on the cause of the problem and
> are just argumenting in circles :-)

I don't disagree that if you fixed it to not use scopes you would
probably get the right answer
That doesn't make it claiming these objects must-conflict any less
wrong or buggy, or any less of a fix for this particular problem.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]