This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Debugging CSE, on the right track?
- To: Carlo Wood <carlo at runaway dot xs4all dot nl>
- Subject: Re: Debugging CSE, on the right track?
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Wed, 08 Jul 1998 00:01:52 -0600
- cc: egcs at cygnus dot com (egcs at cygnus dot com)
- Reply-To: law at cygnus dot com
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