From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jeffrey A Law <law@cygnus.com>
To: Carlo Wood <carlo@runaway.xs4all.nl>
Cc: egcs@cygnus.com (egcs@cygnus.com)
Subject: Re: Debugging CSE, on the right track? 
Date: Wed, 08 Jul 1998 04:25:00 -0000
Message-id: <10437.899877712@hurl.cygnus.com>
References: <199807080001.CAA03897@jolan.ppro>
X-SW-Source: 1998-07/msg00300.html

  In message < 199807080001.CAA03897@jolan.ppro >you write:
  > The bug occurs because the CSE thinks expressions are equivalent that are
  > not equivalent.  The exact order in which this happens is as follows:
Correct.


  > (insn 18 16 20 (set (reg:SI 24)
  >         (reg:SI 0 %eax)) -1 (nil)
  >     (insn_list:REG_RETVAL 12 (expr_list:REG_EQUAL (expr_list (symbol_ref:SI
  >  ("f"))
  >                 (expr_list (reg/v:SI 23)
  >                     (nil)))
  >             (nil))))
  > 
  > RESULT:
  > 
  > EQUIVALENCES:
  > 
  > * (reg:SI 24)
  > * (expr_list (symbol_ref:SI ("f"))
  > 		      (expr_list (reg/v:SI 23)
  > 			  (nil)))
This is one of the two critical insns to watch.

  > ------------------------------------
  > * (reg:SI 24)
  > * (reg/v:SI 21)
  > * (expr_list (symbol_ref:SI ("f"))
  > 		      (expr_list (reg/v:SI 23)	<== WRONG!!! (reg/v:SI 23)
  > 			  (nil)))		             was changed!
Correct.

The real problem at hand is reg23 is used in a libcall, but is also
used outside of the libcall.  That is not supposed to happen -- to
prevent this exact problem.

I believe fixing this is relatively straightforward (copy r23 into
a new pseudo just before each libcall block, then use the new pseudo
in the libcall block).   I was unable to get such a patch to work
properly though, so I took an alternate track to fix the problem.

  > Isn't what we really WANT after that last instruction, the following
  > equivalences?
I don't really follow your equivalency lists.  But what we want is for 
the EXPR_LISTs to be correct -- instead of referencing r23, they
should reference (const_int 1) in the first one and (const_int 2) in
the second one.

  > Or - what seems more logical to me - don't we want to store the quantity
  > value of an expr_list instead of the expr_list itself, when this expr_list
  > is part of another expr_list?  I mean, it doesn't make much sense to
  > store
  > 
  > * (expr_list (symbol_ref:SI ("f"))
  >                       (expr_list (const_int 1)
  >                           (nil)))
  > 
  > either; It would make more sense to store:
  > 
  > * (expr_list (symbol_ref:SI ("f"))
  >                       (qty_value (26)
  >                           (nil)))
The EXPR_LISTs should reference the inputs to the libcall; in this
case the inputs are (const_int 0) and (const_int 1). 


  > if `26' is the qty value assigned to (const_int 1).
  > In that case we don't have to care about replacing
  > (reg/v:SI 23) when its value changes: You store the
  > quantity value to begin with.
  > 
  > Am I making any sense?
A little.
jeff