PATCH: tree-ssa-sink breaks stack layout

[Michael Matz]

Hi,

On Wed, 1 Apr 2009, Daniel Berlin wrote:

> > 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.

Okay, agreed.  I just fear that fixing this problem again leads us to not 
fixing the root cause (block tree bla).

> >  nor would it fix the real problem.
> 
> The other posited solutions are to use live range info.

With a proper definition of lifeness, yes.  Those large arrays need to die 
as early as possible (namely when they go out of scope in the source 
language, _even when a pointer to them escapes_).  Obviously that poses a 
problem when transformations already moved references to them out of their 
original scopes.  Then they can't die at scope border.  IOW you really 
want to make use of the scope tree as much as possible to restrict the 
life range.  The difficulty lies in "as possible" :)


Ciao,
Michael.