[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code

["dnovillo at google dot com" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #27 from dnovillo at google dot com  2007-06-19 17:39 -------
Subject: Re:  [4.2 Regression] Incorrect stack sharing
 causing removal of live code

On 6/19/07 1:26 PM, rth at gcc dot gnu dot org wrote:
> ------- Comment #26 from rth at gcc dot gnu dot org  2007-06-19 17:26 -------
> (In reply to comment #10)
>> Talked to Dan Berlin and Diego Novillo here at Google. They told me
>> that all locals are promoted to function scope.
> 
> That *only* applies to register variables, not stack variables.

Yes, but our GIMPLE optimizers don't know that and we do not have a way
of enforcing that in GIMPLE.  There just are no scope boundaries in the
SSA web.  So, the end result is that in SSA we only have function scope.


> We very very much want to preserve scope of stack variables, because
> we very very much want to share stack space between stack variables
> of different scopes.  Failure to do so causes bad interactions with
> inlining, and causes stack space consumtion to grow to unacceptable
> levels.  I.e. you can't build kernels anymore.

Agreed.  We have to find a way of either tying the hands of code motion
transformations by making them use the SSA web *and* the TREE_BLOCKs, or
make stack slot sharing aware of live ranges.

Right now we have the unfortunate situation that an optimizer is making
a valid transformation which breaks the scope assumption that stack
sharing uses.

I am not sure if it would be practical to force code motion
optimizations to use anything other than the SSA web to do their
analysis.  Perhaps we could force scopes by building barriers on the SSA
web itself (say, by putting PHI nodes at scope boundaries, or something).

Alternatively, we could incorporate live-range analysis to stack slot
sharing.  That way, if code motion creates undue stack slot pressure, we
would merely emit suboptimal code, instead of wrong code.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327