This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 6 GCC regressions, 2 new, with your patch on 2002-07-20T23:26:42Z.


Richard Henderson <rth@redhat.com> writes:

> On Sun, Jul 21, 2002 at 09:38:43PM +0200, Jan Hubicka wrote:
> > This is really interesting case.  The beggining of function contains:
> > (insn 4 3 6 0 (nil) (set (reg:SI 62)
> >         (mem/f:SI (plus:SI (reg/f:SI 16 argp)
> >                 (const_int 4 [0x4])) [4 y+0 S4 A32])) 45 {*movsi_1}
> > (nil)
> >     (expr_list:REG_EQUIV (mem/f:SI (plus:SI (reg/f:SI 16 argp)
> >                 (const_int 4 [0x4])) [4 y+0 S4 A32])
> >         (nil)))
> > 
> > And later also:
> > 
> > (insn 12 6 21 0 0x401a3a80 (set (reg/v/f:SI 64)
> >         (mem/f:SI (plus:SI (reg/f:SI 16 argp)
> >                 (const_int 4 [0x4])) [4 S4 A8])) 45 {*movsi_1} (nil)
> >     (nil))
> > 
> > cselib notices the equivalence and cprop actually does the replacement
> > of reg 64 by reg 62.  But the REG_EQUIV note is not really valid, as the
> > value of memory copy y is not valid during the function (overwriten by
> > bar call).
> 
> Your reasoning is incorrect.  REG_EQUIV is a _local_ equivalence,
> free to be killed at any moment.  REG_EQUAL is the global equivalence.

It's the other way around.  rtl.h says:

  /* Like REG_EQUIV except that the destination is only momentarily equal
     to the specified rtx.  Therefore, it cannot be used for substitution;
     but it can be used for cse.  */
  REG_EQUAL,

Thus, it looks like the right thing for this problem is to generate a
REG_EQUAL note instead of a REG_EQUIV.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]