------- Comment #3 from jingyu at google dot com 2010-01-12 02:45 ------- Subject: Re: problematic REG_EQUAL note added to SUBREG
On Mon, Jan 11, 2010 at 2:00 PM, ebotcazou at gcc dot gnu dot org <gcc-bugzi...@gcc.gnu.org> wrote: > > > ------- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-01-11 22:00 > ------- > The REG_EQUAL note is correct after fwprop but not after combine, so the > problem lies in combine. The note should have been removed by > adjust_for_new_dest since the destination of I3 has changed. > Unfortunately, the note is not removed by adjust_for_new_dest. I traced gcc and saw how it combined insn 156 and insn 62. First, gcc works out a new pattern "newpat" which sets 0x7ff0000000000000 to reg 180 and jumps to "validate_replacement", where it checks if the result of combination a valid instruction. line3061: /* Is the result of combination a valid instruction? */ line3062: insn_code_number = recog_for_combine (&newpat, i3, &new_i3_notes); In our case, insn_code_number is 164. Then gcc comes to line3657. Since changed_i3_dest is 0, gcc does not call adjust_for_new_dest at all. line3657: if (changed_i3_dest) { PATTERN (i3) = newpat; adjust_for_new_dest (i3); } After this, there is no chance where the note of i3 can be removed. I did not read the entire combine pass. So I am not sure whether it is fine to just add something like this after line3062 where recog_for_combine is called. if (insn_code_number >= 0) changed_i3_dest = 1; Another option to fix this problem is not to attach REG_EQUAL note to "set subreg reg" at all during forward propagation. Index: fwprop.c ============================== ===================================== --- fwprop.c (revision 155510) +++ fwprop.c (working copy) @@ -1297,7 +1297,7 @@ forward_propagate_and_simplify (df_ref u recognized. Either we're already replacing in the note, or we'll separately try plugging the definition in the note and simplifying. */ - set_reg_equal = (note == NULL_RTX); + set_reg_equal = (note == NULL_RTX && REG_P (SET_DEST (use_set))); } if (GET_MODE (*loc) == VOIDmode) I have tested this patch on arm-unknown-eabi target. There is no regression. What do you think? Thanks, Jing > > -- > > ebotcazou at gcc dot gnu dot org changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |ebotcazou at gcc dot gnu dot > | |org > Component|middle-end |rtl-optimization > Summary|Wrong REG_EQUAL note is |problematic REG_EQUAL note > |added to SUBREG node |added to SUBREG > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42691 > > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42691