This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Questions about i386 redundant test and comparison removal
- To: law at cygnus dot com
- Subject: Questions about i386 redundant test and comparison removal
- From: john at feith dot com (John Wehle)
- Date: Fri, 5 Jun 1998 14:15:30 -0400
- cc: egcs at cygnus dot com
It appears that in the case of setting cc0 final_scan_insn compares
SET_SRC (set) to cc_status.value1 and cc_status.value2 to see if
it has already be set to the desired value in which case the insn
is "deleted". Later on NOTICE_UPDATE_CC is invoked in order to
record the current state of cc0 in cc_status.flags and the patterns
causing that state in cc_status.value1 and cc_status.value2.
Assuming that I am correct regarding the above, I am confused by
the following code in i386.c notice_update_cc:
case PLUS: case MINUS: case NEG:
case AND: case IOR: case XOR:
cc_status.flags = CC_NO_OVERFLOW;
cc_status.value1 = SET_SRC (exp);
cc_status.value2 = SET_DEST (exp);
break;
/* This is the bsf pattern used by ffs. */
case UNSPEC:
if (XINT (SET_SRC (exp), 1) == 5)
{
/* Only the Z flag is defined after bsf. */
cc_status.flags
= CC_NOT_POSITIVE | CC_NOT_NEGATIVE | CC_NO_OVERFLOW;
cc_status.value1 = XVECEXP (SET_SRC (exp), 0, 0);
break;
}
/* FALLTHRU */
What does SET_DEST (exp) have to do with setting cc0? Also, why doesn't
cc_status.value2 need to be cleared in the case of UNSPEC?
-- John
-------------------------------------------------------------------------
| Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com |
| John Wehle | Fax: 1-215-540-5495 | |
-------------------------------------------------------------------------