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

Richard Guenther wrote:

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

That's not going to be very easy for variables with different types.

> I do not think we can reliably paper over the problem - just do some
> additional papering until someone finds a new testcase. 

That doesn't mean that's a bad thing to do.  That's the whole nature of
papering over bugs; you push them into more obscure corners.  But,
that's not a bad thing; it may be intellectually unappealing, but it
makes the compiler better until you can fix it correctly.  From the
user's point of view, papering over a bug is a good thing.

We should resist the conclusion that this is just an unfixable bug until
we go off and build lots of new infrastructure.  That's not a
user-centric point of view.  I'm not accusing you of taking this
approach; just saying that it's not good for us collectively to do so.

Let's find some way to mitigate the damage in 4.4 while we search for a
longer-term solution for 4.5.

> We also
> should not start "adjusting" scope blocks anywhere - this just leads to
> maintainance problems IMHO.

Yes, keeping track of when we do things that move things into other
scopes would require work; we have to maintain invariants that right now
we may not, and it's easy to forget to do these kinds of checks.  But,
maintaining invariants is sometimes the price of building an optimizing
compiler.  Maybe we can build abstractions for moving code that do the
checks for us.

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

Yes -- and that reduced sharing is a weakness, leading to inferior
code-generation.  So, in terms of the long-term solution, yes, we should
try to find an approach that balances alias analysis against sharing.

Mark Mitchell
(650) 331-3385 x713

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