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
