This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Questions about i386 redundant test and comparison removal
- To: law at cygnus dot com
- Subject: Re: Questions about i386 redundant test and comparison removal
- From: john at feith dot com (John Wehle)
- Date: Sat, 6 Jun 1998 14:08:29 -0400
- cc: egcs at cygnus dot com
> consider a machine where memory loads do not set cc0, but
> an add or subtract does set them in some useful manner.
>
> (set (regx) (plus ...)) Would record regx & the status bits that
> are useful after a plus.
>
> [ ... stuff that doesn't scrog cc0 ]
> (set (regx) (load from memory)
>
> (set (cc0) (regx))
> conditional branch
>
> If you don't track the SET_DESTs and invalidate known cc0 status
> at the second set of regx, then you may end up deleting the
> (set (cc0)) instruction even though it is not redundant.
Umm ... I'm a little confused:
1) If I'm not tracking SET_DESTs then why would I think that the
(set (cc0) (regx)) is redundant in the above example?
Even if the case of:
(set (regx) (load from memory location a))
(set (cc0) (regx))
(set (regx) (load from memory location b))
(set (cc0) (regx))
conditional branch
I don't understand why SET_DESTs needs to be tracked. NOTICE_UPDATE_CC
can still invalidate the known cc0 status at the second set of regx since
it was mentioned as the SET_SRC for the first set of cc0. I understand
the need to invalidate, I'm just not seeing how that requires tracking
the SET_DESTs.
Tracking SET_DESTs does allow for noticing that set cc0 is redundant in
the example below:
(set (regx) (plus ...))
(set (cc0) (regx))
-- John
-------------------------------------------------------------------------
| Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com |
| John Wehle | Fax: 1-215-540-5495 | |
-------------------------------------------------------------------------