Commit Message

Hi,
In split_function() (ipa-split.c), for the newly created call stmt,
its block is set to the outermost scope, i.e.
DECL_INITIAL(current_function_decl). When we inline this
partially outlined function, we create the new block based on the
block for the call stmt (in expand_call_inline()).
So the new block for the inlined body is in
parallel to the function top level scope. This bad block structure will
late result in a bad stack layout.
This patch fixes the issue by setting the correct block number. It
starts with the split_point entry bb to find the block stmt in the
outlined region. The entry_bb maybe an empty BB so we need to follow
the CFG until we find a non-empty bb.
My early patch tried to use the block info from the first non-empty
bb in the outlined regision. But that failed bootstrap as some of the
stmts (assignment stmt) do not have the block info (bug?). So in this
patch I traverse all the stmts in the bb until getting the block info.
Tested with gcc bootstap.
Thanks,
2012-04-24 Rong Xu <xur@google.com>
* ipa-split.c (split_function): set the correct block for the
call statement.
--
This patch is available for review at http://codereview.appspot.com/6111050

> We do not depend on the block structure any more when dealing with> stack layout for variables in GCC 4.7.0 and above. I am not saying> your patch is incorrect or not needed. Just it will not have an> effect on variable stack layout.
It might be worth backporting to the 4.6 branch though, these stack layout
issues are very nasty.

On Fri, Apr 27, 2012 at 12:50 PM, Eric Botcazou <ebotcazou@adacore.com> wrote:
>> We do not depend on the block structure any more when dealing with>> stack layout for variables in GCC 4.7.0 and above. I am not saying>> your patch is incorrect or not needed. Just it will not have an>> effect on variable stack layout.>> It might be worth backporting to the 4.6 branch though, these stack layout> issues are very nasty.
What about not setting a BLOCK on the call stmt? That said, I can't see
how outlining a SESE region that starts at the beginning of the function
is not conservatively using the outermost BLOCK ... so, is the bug not
elsewhere?
Richard.
> --> Eric Botcazou

> On Fri, Apr 27, 2012 at 12:50 PM, Eric Botcazou <ebotcazou@adacore.com> wrote:> >> We do not depend on the block structure any more when dealing with> >> stack layout for variables in GCC 4.7.0 and above. I am not saying> >> your patch is incorrect or not needed. Just it will not have an> >> effect on variable stack layout.> >> > It might be worth backporting to the 4.6 branch though, these stack layout> > issues are very nasty.> > What about not setting a BLOCK on the call stmt? That said, I can't see
I recall that not seetting the block did lead to ICE...
> how outlining a SESE region that starts at the beginning of the function> is not conservatively using the outermost BLOCK ... so, is the bug not> elsewhere?
... so I made the exactly same conclussion.
The problem is with stack vars allocated in header that survive till the
tail part?
Honza
> > Richard.> > > --> > Eric Botcazou

On Fri, Apr 27, 2012 at 5:06 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> On Fri, Apr 27, 2012 at 12:50 PM, Eric Botcazou <ebotcazou@adacore.com> wrote:>> >> We do not depend on the block structure any more when dealing with>> >> stack layout for variables in GCC 4.7.0 and above. I am not saying>> >> your patch is incorrect or not needed. Just it will not have an>> >> effect on variable stack layout.>> >>> > It might be worth backporting to the 4.6 branch though, these stack layout>> > issues are very nasty.>>>> What about not setting a BLOCK on the call stmt? That said, I can't see>> I recall that not seetting the block did lead to ICE...>>> how outlining a SESE region that starts at the beginning of the function>> is not conservatively using the outermost BLOCK ... so, is the bug not>> elsewhere?>> ... so I made the exactly same conclussion.> The problem is with stack vars allocated in header that survive till the> tail part?
A SESE region does not necessary at the beginning of the function.
They can be anywhere.
In the example I attached, it is at the end of function.
Even if the outlined region is at the beginning the function. setting
the call_stmt as the outermost
block is also incorrect.
For c++ programs, the block for function level local variables is not
DECL_INITIAL(current_function_decl).
It is the subblock of DECL_INITIAL(current_function_decl).
This is different from c programs.
-Rong
>> Honza>>>> Richard.>>>> > -->> > Eric Botcazou