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

[Daniel Berlin <dberlin at dberlin dot org>]

On Tue, Mar 31, 2009 at 1:44 PM, Sandra Loosemore
<sandra@codesourcery.com> wrote:
> This patch addresses a problem that was reported by one of our ARM users.
> However, it seems not to be ARM-specific.
>
> If the attached test program is compiled for arm-none-eabi target with -O1,
> it fails by incorrectly calling a pure virtual method. ?What is happening is
> that tree-ssa-sink is moving code from the inlined destructor for STUFF, in
> the first nested block, into the second nested block, where it ends up after
> the code for the inlined constructor for STUFF2. ?Then, cfgexpand comes
> along and decides that STUFF and STUFF2 can share stack space because they
> are in disjoint lexical blocks. ?Thus the sunk destructor statement for
> STUFF ends up trashing the vtable of STUFF2. ?The test program appears to
> work correctly at -O2 only because -fstrict-aliasing prevents cfgexpand from
> assigning STUFF and STUFF2 to the same stack offset.
>
> The attached patch fixes the problem, but it's rather crude. ?I admit I'm
> not very familiar with the data structures available in this part of the
> compiler,
> for instance, and there may be better ways to test for moving across a
> lexical block boundary, and more specific tests on the form of the statement
> to decide it's safe to move after all. ?Could any experts help me clean it
> up?
>
> I'm also concerned that there may be other places in the new tree
> optimization passes where code motion is being performed without regard to
> lexical block boundaries. ?Again, any experts want to weigh in on this?

Absolutely none of the optimizations in the middle end  care about
lexical block boundaries, and it the fact that we have the info at all
is not meant to be used to block or stop optimizations.
In fact, the very first thing GIMPLE lowering does is remove lexical scopes!

"/* The differences between High GIMPLE and Low GIMPLE are the
   following:

   1- Lexical scopes are removed (i.e., GIMPLE_BIND disappears).
"

ISTM the bug here is in trying to use lexical scope data, after we've
destroyed it, to make decisions about aliasing.

If we want to try to introduce lexical scopes into low gimple, and
respect them in optimizations, you are basically talking about
changing some very fundamental assumptions our tree level
optimizations make.