RE: Deep CSE bug!

["Dave Korn" <dk at artimi dot com>]

> -----Original Message-----
> From: Roger Sayle 
> Sent: 18 June 2004 15:21

  Hello Roger!  I was just browsing your recent patch for the rtl-sharing
problem in the archives :)

> On Fri, 18 Jun 2004, Dave Korn wrote:
> >   Does really nobody have anything to say about the 
> semantics of REQ_EQUAL
> > on SETs of SUBREGs?

> My understanding (and working hypothesis) of REG_EQUAL notes 
> is that they
> describe the SET_SRC of a SET instruction, and their interpretation is
> completely independent of the set's target, SET_DEST.

  Ah, that's pretty much the opposite way round to what I had expected!  I
was working under the assumption that it referred to 'what the SRC will
equal after this insn until it next gets set'.

> I believe the semantics are (or should be) that given an instruction
> 
> 	(set (foo) (bar))
> 	  (REG_EQUAL  baz)
> 
> that it is the REG_EQUAL note states that at the point this 
> instruction
> is executed "bar" will have the same value as "baz".  The 
> REG_EQUAL note
> is used to record the equivalence when (set (foo) (baz)) is either not
> not recognized/available as a backend, or has a higher cost than the
> original.  In normal use, "baz" will be more grounded (contain more
> constants) than "bar".  In the RTL optimizers, it should always be
> valid to reasonable the SET_SRC on an instruction with its REG_EQUAL
> note (except when the REG_EQUAL notes contains an expression list).
>
> This also clarifies the expected behaviour when "baz" 
> references "foo".
> The contains of the REQ_EQUAL note are not available after the
> assignment if any component is clobbered by its SET.
> 
> 
> In your and Kaz's examples, it sounds like the bug is that the
> REG_EQUAL note is invalid/incorrect, rather than a flaw in CSE.


  So, looking at that insn again:

(insn 33 32 37 0 0x1002f510 (set (subreg:SI (reg:DI 80) 4)
        (reg/v:SI 75)) 22 {movsi} (nil)
    (expr_list:REG_EQUAL (const_double -1 [0xffffffff] 0 [0x0] 0 [0x0] 0
[0x0] 0 [0x0] 0 [0x0])
        (nil)))

you'd say that since REG_EQUAL refers to the dest, it should be in the same
mode as the dest, and therefore I should really want it to just say
REG_EQUAL (const_int 0)?  That seems like a reasonable hypothesis.  In the
.00.rtl dump, this insn looks like:

(insn 33 32 37 0x0 (set (subreg:SI (reg:DI 80) 4)
        (mem/u/f:SI (plus:SI (reg/f:SI 81)
                (const_int 4 [0x4])) [2 S4 A32])) -1 (nil)
    (expr_list:REG_EQUAL (const_double -1 [0xffffffff] 0 [0x0] 0 [0x0] 0
[0x0] 0 [0x0] 0 [0x0])
        (nil)))

so it's wrong right from the start.

> Perhaps someone else could comment on, confirm or deny these 
> semantics?

  Yep, that could only help.  Meanwhile I guess I'd better look at the code
that generates the REG_EQUAL in the first place and see how it gets to be
that way.  I can probably find my way around the code but any hints as to
where I should be looking would be handy!


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....