This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Sun, Apr 5, 2009 at 8:42 PM, Mark Mitchell <> wrote:
> Ian Lance Taylor wrote:
>>> No idea if that would (easily) work out, of course. ?Some targets
>>> may have different costs and thus optimization decision based
>>> on the offset size used with virtual-stack-vars.
>> Certainly true, but I bet that we could generate better code for such
>> targets than we do today, because we would have a chance to sort the
>> most frequently used stack variables into the lower stack offsets.
> I think we ought to separate this discussion into two parts:
> (1) What can we do to eliminate a serious defect in the short-term?
> This is a case of silently generating wrong code, with a simple,
> reasonable test case.
> (2) What is the right long-term solution?
> Let's work (1) out first, since we all agree that (2) is going to be
> something more complex; fundamentally, we have an optimization that
> assumes lexical scopes matter, and other optimizations that pay no
> attention to them.
> Obviously, the truly conservative solution is to eliminate stack-slot
> sharing, but we know that's going to lead to truly huge stack frames,
> and truly bad code, on some real-world inputs. ?Can we disable it for
> -fno-strict-aliasing, since -fstrict-aliasing seems to at least paper
> over the common cases of the bug? ?If so, we'd impact our -O1
> optimization (and maybe -O0 code-generation), but mitigate the problem.
> ?Or, can we do as Danny and Michael have been discussing and make
> cfgexpand use a more conservative approach to determining sharing when
> -fno-strict-aliasing?
> There's nothing wrong with further papering-over of the problem, if that
> reduces the set of affected programs and we don't have a better
> short-term solution. ?An unachievable no-bugs solution should not be the
> enemy of an achievable fewer-bugs solution.
> One possible approach for (2) is to promote variables into bigger
> lexical scopes when we do things like we're doing in tree-ssa-sink.
> Lexical scopes form a tree, so there's always a dominating node to which
> we can safely move the variable. ?Of course, though, once you start
> moving statements that deal with pointers, you have to conservatively
> promote all the variables to which the pointers might point.
> I think it would be a shame to completely stop relying on lexical scope
> information as there are going to be variables that can share stack
> slots, but for which no after-the-fact analysis not relying on lexical
> scopes (or something equivalent thereto) can prove that. ?The canonical
> example is:
> ?{ int i; f(&i); }
> ?{ int j; f(&j); }
> If you throw the braces away, once the addresses escape, you can't know
> that it's safe to share the slots for i and j. ?The opposite point is
> that it would certainly be good to be able to share slots for variables
> that are in the same scope, if their lifetimes don't overlap. ?So,
> lexical scope information ought to be one part of the analysis, not the
> entire analysis.

You can make use of lexical scope information for example at gimple
lowering time and unify variables in different scopes there (bascially
do "stack slot sharing" by merging decls).  We would need to deal with
debug information loss here and maybe pessimize optimization in
some cases.

I do not think we can reliably paper over the problem - just do some
additional papering until someone finds a new testcase.  We also
should not start "adjusting" scope blocks anywhere - this just leads to
maintainance problems IMHO.

Note that we already do way less stack-slot sharing with -fstrict-aliasing
which is likely the reason that the problem is harder to trigger there.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]