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

> 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.

This defect has been there for years though so I don't see the urgency.

> (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?

But -fno-strict-aliasing is the option to use if you want stack slot sharing, 
with -fstrict-aliasing you cannot share as efficiently because the scheduler 
will move instructions around.

> 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.

Papering over it again will very likely delay its resolution again.

Eric Botcazou

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