[Bug rtl-optimization/42691] problematic REG_EQUAL note added to SUBREG

["jingyu at google dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- 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-bugzilla@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