This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: tree-ssa-sink breaks stack layout
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.