This is the mail archive of the gcc-patches@gcc.gnu.org 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


Daniel Berlin wrote:

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.

Yes, I also considered this. I was confused because the current lexical-block-based analysis in cfgexpand long predates the new gimple optimizations and data structures, so I didn't know which was correct, or if the lexical block information still being available and used at that point meant it was supposed to be preserved and valid throughout the tree optimizations even if it was no longer the primary representation. Plus, the stack space sharing optimization is an important one for some applications, whereas we'll have another chance to do code motion after we convert to RTL; so given a choice between disabling one or the other as a quick fix, it seemed better to attack it at the tree-ssa-sink end.


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.

Yes, I did say I'm worried about the correctness issues here. But, changing fundamental assumptions doesn't sound like a quick fix, either. :-(


I could look into fixing the stack layout code, but to get it done anytime soon I'd appreciate being pointed in the right direction in terms of what variable lifetime analysis information is both available and valid at that point. Or, maybe somebody who is already a whiz at this could get a fix in a lot faster than it would take me to climb the learning curve?

-Sandra


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