On 11/18/2011 10:29 PM, Eric Botcazou wrote: >> For the test-case of PR50764, a dead label is introduced by >> fixup_reorder_chain in cfg_layout_finalize, called from >> pass_reorder_blocks. > > I presume that there is no reasonable way of preventing fixup_reorder_chain > from introducing it or of teaching fixup_reorder_chain to remove it? >
This (untested) patch also removes the dead label for the PR, and I think it is safe. ... Index: cfglayout.c =================================================================== --- cfglayout.c (revision 181377) +++ cfglayout.c (working copy) @@ -702,6 +702,21 @@ relink_block_chain (bool stay_in_cfglayo } +static bool +forced_label_p (rtx label) +{ + rtx insn, forced_label; + for (insn = forced_labels; insn; insn = XEXP (insn, 1)) + { + forced_label = XEXP (insn, 0); + if (!LABEL_P (forced_label)) + continue; + if (forced_label == label) + return true; + } + return false; +} + /* Given a reorder chain, rearrange the code to match. */ static void @@ -857,6 +872,12 @@ fixup_reorder_chain (void) (e_taken->src, e_taken->dest)); e_taken->flags |= EDGE_FALLTHRU; update_br_prob_note (bb); + if (LABEL_NUSES (ret_label) == 0 + && !LABEL_PRESERVE_P (ret_label) + && LABEL_NAME (ret_label) == NULL + && !forced_label_p (ret_label) + && single_pred_p (e_taken->dest)) + delete_insn (ret_label); continue; } } ... But I see 2 potential issues: - it only catches this case in fixup_reorder_chain. I don't know if there are more cases, but the earlier catch-all-afterwards patch surely will catch those, this patch probably not. - I'm not sure if the use count will drop always drop to 0 in fixup_reorder_chain, that might only happen after rebuild_jump_labels. Thanks, - Tom