http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50251
--- Comment #15 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-09-02 11:02:22 UTC --- (In reply to comment #14) > > but for some reason it doesn't trigger? > > The bb containing the __builtin_stack_restore has 2 successors: > ... > <bb 6>: > D.2099_18 = MEM[(int *)&D.2129][5]{lb: 0 sz: 4}; > __builtin_stack_restore (saved_stack.3_5); > if (D.2099_18 != 15) > goto <bb 7>; > else > goto <bb 8>; > ... > > This case doesn't fall into the cases described in the header comment. > ... > /* Try to optimize out __builtin_stack_restore. Optimize it out > if there is another __builtin_stack_restore in the same basic > block and no calls or ASM_EXPRs are in between, or if this block's > only outgoing edge is to EXIT_BLOCK and there are no calls or > ASM_EXPRs after this __builtin_stack_restore. */ > ... > > It hits this piece of code in optimize_stack_restore and returns, so it > doesn't > reach second_stack_restore: > ... > /* Allow one successor of the exit block, or zero successors. */ > switch (EDGE_COUNT (bb->succs)) > { > case 0: > break; > case 1: > if (single_succ_edge (bb)->dest != EXIT_BLOCK_PTR) > return NULL_TREE; > break; > default: > return NULL_TREE; > } > second_stack_restore: > ... > > > For the stack-save-restore.c, if I declare p inside the function, cse creates > a > (set (sp) (sp)), which is eliminated. > But for the 20010209-1.c example, that doesn't happen. Ok, the code really tries to optimize the case of __builtin_stack_restore being called right before exiting the function only. That's because it doesn't look for alloca() calls inbetween the stack-save/restore pair at all (just for ones following a restore).