http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54953
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2012-10-17
Target Milestone|--- |4.8.0
Ever Confirmed|0 |1
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-10-17
16:03:50 UTC ---
I've tried:
--- dce.c.jj1 2012-10-08 21:37:36.000000000 +0200
+++ dce.c 2012-10-17 17:32:19.855891915 +0200
@@ -880,7 +880,9 @@ word_dce_process_block (basic_block bb,
for (def_rec = DF_INSN_DEFS (insn); *def_rec; def_rec++)
dead_debug_insert_temp (&debug, DF_REF_REGNO (*def_rec), insn,
- DEBUG_TEMP_BEFORE_WITH_VALUE);
+ marked_insn_p (insn)
+ ? DEBUG_TEMP_AFTER_WITH_REG
+ : DEBUG_TEMP_BEFORE_WITH_VALUE);
}
if (dump_file)
@@ -981,7 +983,9 @@ dce_process_block (basic_block bb, bool
if (debug.used && !bitmap_empty_p (debug.used))
for (def_rec = DF_INSN_DEFS (insn); *def_rec; def_rec++)
dead_debug_insert_temp (&debug, DF_REF_REGNO (*def_rec), insn,
- DEBUG_TEMP_BEFORE_WITH_VALUE);
+ needed
+ ? DEBUG_TEMP_AFTER_WITH_REG
+ : DEBUG_TEMP_BEFORE_WITH_VALUE);
}
dead_debug_local_finish (&debug, NULL);
but that isn't enough (well, it seems likely the testcase passes again, but
isn't correct).
The problem is in:
654 /* If there's a single (debug) use of an otherwise unused REG, and
655 the debug use is not part of a larger expression, then it
656 probably doesn't make sense to introduce a new debug temp. */
657 if (where == DEBUG_TEMP_AFTER_WITH_REG && !uses->next)
658 {
659 rtx next = DF_REF_INSN (uses->use);
660
661 if (DEBUG_INSN_P (next) && reg == INSN_VAR_LOCATION_LOC (next))
662 {
663 XDELETE (uses);
664 return 0;
665 }
666 }
in dead_debug_insert_temp, which triggers in this case and just does nothing.
I wonder why that hunk has been added, if the pseudo is live at that point,
surely it doesn't make sense, but if it becomes dead in between the insn and
the single debug use, then inserting a new debug temp is desirable even in that
case. If it is fine for some reason for df-problems.c uses, perhaps we should
have another DEBUG_TEMP_AFTER_WITH_REG_FORCE where mode or similar that would
do the same thing as DEBUG_TEMP_AFTER_WITH_REG, but not trigger this kind of
?optimization?.
