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.


> 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.

Duh, you are right.  I am always swapping meaning of the notes.
> 
> Irritatingly, the test case isn't failing for me at the moment, so
> I can't make any more progress here.

You need to revert the code regarding to REG_EQUIV note in the gcse
cprop code.  I will re-check what is going on.

Honza
> 
> 
> r~


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