[Bug target/51244] [SH] Inefficient conditional branch and code around T bit

["laurent.alfonsi at st dot com" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244

--- Comment #61 from Laurent Aflonsi <laurent.alfonsi at st dot com> ---
Yes that's the point. L3 can be reached by another block (L2):

    tst    r2,r2
    mov    #-1,r2
    negc    r2,r2
.L3:
    tst    r2,r2
    bt/s    .L11
        [...]
.L2:
    mov.l    @r4,r2
    tst    r2,r2
    bra    .L3
    movt    r2

The movt(L2) and the tst(L3) are both removed, and that's coherent for that run
path, because it is preceded by the tst r2,r2.
But that makes the first path incoherent because L3 can be reached by the very
first block. I have written a first fix, too restrictive ("pr25869-19.c
scan-assembler-not movt" is failing) :

--- ./gcc/gcc/config/sh/sh.md.orig
+++ ./gcc/gcc/config/sh/sh.md
@@ -8523,7 +8523,8 @@
           T bit.  Notice that some T bit stores such as negc also modify
           the T bit.  */
        if (modified_between_p (get_t_reg_rtx (), s1.insn, testing_insn)
-           || modified_in_p (get_t_reg_rtx (), s1.insn))
+           || modified_in_p (get_t_reg_rtx (), s1.insn)
+           || !no_labels_between_p(s1.insn, testing_insn))
          operands[2] = NULL_RTX;

        break;

The idea would be to check if "s1.insn block dominates testing_insn block",
but I don't know how to write it at this stage.

More generally, I'm surprised to see that optimization at mapping level, isn't
this a generic problematic that should be handled at rtl dead code elimination
stage on the T bit register ?

Thanks,
Laurent