[Bug rtl-optimization/31848] [4.3 regression] Invalid loop optimization causes bootstrap failure in genautomata
rakdver at kam dot mff dot cuni dot cz
gcc-bugzilla@gcc.gnu.org
Thu May 10 08:42:00 GMT 2007
------- Comment #6 from rakdver at kam dot mff dot cuni dot cz 2007-05-10 09:42 -------
Subject: Re: [4.3 regression] Invalid loop optimization causes bootstrap
failure in genautomata
> Now, imagine the representative of a class of invariant insns is this one:
>
> (gdb) next
> 1161 reorder_insns (inv->insn, inv->insn, BB_END (preheader));
> (gdb) p debug_rtx(inv->insn)
> (insn 552 551 644 57 foo.c:11152 (set (reg:SI 323)
> (reg/v/f:SI 170 [ compressed_min_issue_delay_vect ])) 161
> {*arm_movsi_insn} (nil)
> (expr_list:REG_EQUAL (const_int 0 [0x0])
> (nil)))
> $7 = void
The heuristics may need some tweaking... moving reg-reg moves out of
loop seems unnecessary. Anyway,
> ...and we've moved the insn with note and all out of the loop, even though the
> note is not valid anymore.
> Index: loop-invariant.c
> ===================================================================
> --- loop-invariant.c (revision 124576)
> +++ loop-invariant.c (working copy)
> @@ -1156,9 +1156,21 @@ move_invariant_reg (struct loop *loop, u
> to let emit_move_insn produce a valid instruction stream. */
> if (REG_P (dest) && !HARD_REGISTER_P (dest))
> {
> + rtx note;
> +
> emit_insn_after (gen_move_insn (dest, reg), inv->insn);
> SET_DEST (set) = reg;
> reorder_insns (inv->insn, inv->insn, BB_END (preheader));
> +
> + /* If there is a REG_EQUAL note on the insn we just moved, and
> + insn is in a basic block that is not always executed, the note
> + may no longer be valid after we move the insn.
> + Note that uses in REG_EQUAL notes are taken into account in
> + the computation of invariants. Hence it is safe to retain the
> + note even if the note contains register references. */
> + if (! inv->always_executed
> + && (note = find_reg_note (inv->insn, REG_EQUAL, NULL_RTX)))
> + remove_note (inv->insn, note);
> }
> else
> {
>
>
> Zdenek, what do you think about this?
the patch looks OK.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31848
More information about the Gcc-bugs
mailing list