Re: [RFC] Unconditionally clean up CFG before emitting prologue
On Mon, Apr 9, 2012 at 6:11 PM, Eric Botcazou ebotca...@adacore.com wrote: Isn't the gimple cfg-cleanup we run post optimization (right before expansion) not enough? Or the cfg-cleanup we perform right after expansion now? At least if the branches are really caused by the gimplification process I would expect things to be cleaned up at this point, no? At least the patch has a non-null (albeit minor) effect, which pertains mainly to jump threading (typical diff attached, Ada code at -O0 on x86-64). So it's trivial forwarders that are removed. I wonder why cfgcleanup on the tree level does not do this, or why it does that on the RTL level. Are the blocks becoming empty only during/after register allocation? Richard. -- Eric Botcazou
[RFC] Unconditionally clean up CFG before emitting prologue
Hi,
with the numerous checks generated in Ada, the gimplification process can
generated dead branches that aren't easily eliminated at -O0 and can impair
the debugging experience. We have found that unconditionally cleaning up the
CFG before emitting the prologue/epilogue can help in some cases. This is the
same idiom already used in rest_of_handle_jump2 for example.
Tested on x86_64-suse-linux. Comments?
2012-04-09 Eric Botcazou ebotca...@adacore.com
* function.c (rest_of_handle_thread_prologue_and_epilogue): Clean up
the CFG before generating prologue/epilogue even when not optimizing.
--
Eric Botcazou
Index: function.c
===
--- function.c (revision 186176)
+++ function.c (working copy)
@@ -6877,8 +6877,7 @@ struct rtl_opt_pass pass_leaf_regs =
static unsigned int
rest_of_handle_thread_prologue_and_epilogue (void)
{
- if (optimize)
-cleanup_cfg (CLEANUP_EXPENSIVE);
+ cleanup_cfg (optimize ? CLEANUP_EXPENSIVE : 0);
/* On some machines, the prologue and epilogue code, or parts thereof,
can be represented as RTL. Doing so lets us schedule insns between
Re: [RFC] Unconditionally clean up CFG before emitting prologue
Isn't the gimple cfg-cleanup we run post optimization (right before expansion) not enough? Or the cfg-cleanup we perform right after expansion now? At least if the branches are really caused by the gimplification process I would expect things to be cleaned up at this point, no? At least the patch has a non-null (albeit minor) effect, which pertains mainly to jump threading (typical diff attached, Ada code at -O0 on x86-64). -- Eric Botcazou @@ -648,7 +648,6 @@ jmp .L70 .L206: nop -.L71: leaq -768(%rbp), %rax addq $448, %rax movq %rax, %rdi @@ -1107,7 +1106,6 @@ .LEHE34: cmpl $1, %ebx jne .L197 -.L93: movq 16(%rbp), %rax movzbl 186(%rax), %eax testb %al, %al @@ -1398,7 +1396,6 @@ call prime__worlds_secondary_greeks__compute_secondary_greeks__B68b___finalizer.3706 cmpl $1, %ebx jne .L198 -.L112: cmpb $0, -3925(%rbp) je .L113 movq 16(%rbp), %rax @@ -1672,14 +1669,14 @@ .L204: movq -4000(%rbp), %rax movq -4008(%rbp), %rdx - jmp .L151 + jmp .L156 .L186: movq %rax, %rcx movq %rdx, %rax cmpq $6, %rax je .L154 movq %rcx, %rax - jmp .L151 + jmp .L156 .L154: movq %rcx, -96(%rbp) movq -96(%rbp), %rax @@ -1712,7 +1709,6 @@ je .L67 jmp .L204 .L185: -.L151: jmp .L156 .L191: movq %rax, -4024(%rbp) @@ -1773,9 +1769,8 @@ .L197: movq -4016(%rbp), %rax movq -4032(%rbp), %rdx - jmp .L166 + jmp .L156 .L192: -.L166: jmp .L156 .L193: movq %rax, -4048(%rbp) @@ -1838,9 +1833,8 @@ jmp .L70 .L117: movq %r15, %rax - jmp .L173 + jmp .L174 .L196: -.L173: jmp .L174 .L175: .L174: @@ -2510,7 +2504,6 @@ jmp .L253 .L286: nop -.L254: movq 24(%rbp), %rax movzbl 101(%rax), %eax testb %al, %al @@ -2578,12 +2571,12 @@ .L285: movq %r14, %rax movq %r15, %rdx - jmp .L264 + jmp .L269 .L278: movq %rdx, %rcx cmpq $2, %rcx je .L267 - jmp .L264 + jmp .L269 .L267: movq %rax, -56(%rbp) movq -56(%rbp), %rax @@ -2617,7 +2610,6 @@ je .L250 jmp .L285 .L277: -.L264: jmp .L269 .L283: movq %rax, %rbx
