This is the mail archive of the
mailing list for the GCC project.
Re: PATCH: tree-ssa-sink breaks stack layout
- From: Sandra Loosemore <sandra at codesourcery dot com>
- To: Daniel Berlin <dberlin at dberlin dot org>
- Cc: Eric Botcazou <ebotcazou at adacore dot com>, gcc-patches at gcc dot gnu dot org
- Date: Wed, 01 Apr 2009 08:26:26 -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>
Daniel Berlin wrote:
This is independent of the fact that it's clearly missing an aliasing
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 :)
I was mulling this over again, and I think Daniel may be onto something here.
In the abstract, when you're attempting to do code motion of a statement that
involves a memory write, you need to examine all the intervening statements that
do memory reads to see if they may reference the same location. One of the most
basic rules in alias analysis is typically that references to different objects
cannot alias, and that different local variables are different objects.
The stack sharing is breaking that assumption. As I've said, that's an
important optimization and we can't disable it entirely. So now it seems to me
that the more correct place to address this is by making the alias analysis more
conservative: different local variables are known to be different objects only
when they are both visible in the same lexical scope.
Thoughts on that? Maybe I'm totally off-base here.... I've previously done a
lot of work on alias analysis and code motion in another compiler, but I'm still
relatively unfamiliar with gcc internals.
-Sandra the trying-to-learn-as-she-goes-along