------- Comment #19 from ian at airs dot com 2007-06-14 17:57 ------- Adding Richard in case he has any comment.
I don't agree with comment #17 from Doug. In the code in comment #16, if f saves &c, there is no way that it could validly use it after the block scope exits. In general if we expand the scope of a variable outside of its block scope, then the stack sharing code in cfgexpand.c will do the wrong thing. There is normally no reason for the tree code to expand the scope of a variable. But there is also nothing specifically to stop it from doing so. In this particular case store sinking is extending the life of a variable. This is a meaningless move, as there is no valid way for the stored value to be accessed. It is happening because alias analysis thinks that the function call can refer to the stored variable, although this actually can not happen. Part of the reason alias analysis is wrong is that we retain the list of addressable variables in a statement when we shouldn't. Interestingly, if I apply the tree-ssa-operands.c patch from http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01807.html then the problem goes away. But there are a few complex issues here: 1) Alias analysis thinks that a function can refer to a variable in a different block scope. 2) Nothing systematically prevents the tree code from referencing or setting variables outside of their block scope. 3) The stack sharing code in cfgexpand assumes that variables are only referenced or set within their block scope. This is going to require more investigation. I think we are mainly lucky because the tree optimizers tend to not move variables outside of their block scope. This test case just happens to show a way in which that can happen. -- ian at airs dot com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rth at gcc dot gnu dot org, | |ian at airs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
