From mboxrd@z Thu Jan  1 00:00:00 1970
From: Greg McGary <greg@mcgary.org>
To: law@cygnus.com
Cc: gcc@gcc.gnu.org
Subject: thread_jumps does nothing for ix86
Date: Fri, 22 Sep 2000 00:46:00 -0000
Message-id: <200009220746.AAA28313@kayak.mcgary.org>
X-SW-Source: 2000-09/msg00525.html

I discovered that thread_jumps spins its wheels but amounts to a no-op
for ix86.  I assume this is a bug.

Here is a typical sequence of insns for a conditional jump:

(insn 403 402 404 (set (reg:CC 17 flags)
        (compare:CC (reg:SI 136)
            (reg:SI 137))) -1 (nil)
    (nil))

(jump_insn 404 403 405 (set (pc)
        (if_then_else (ltu (reg:CC 17 flags)
                (const_int 0 [0x0]))
            (label_ref 409)
            (pc))) -1 (nil)
    (nil))

Call the first one the "compare insn" and the second the "jump insn".

The compare insn always sets reg:CC, and immediately after, the jump
insn is always conditional on a relop between reg:CC and const0_rtx.

Now, consider thread_jumps.  We locate a conditional branch b1, then
scan forward from b1's target to find b2.  While scanning for b2, we
note registers that are modified.  Immediately prior to finding b2 (a
jump insn) we scan past b2's compare insn which sets reg:CC, and we
remember by setting modified_regs[17].

When it comes time to check for threadability, rtx_equal_for_thread_p
considers equivalence of b1's reg:CC and b2's reg:CC, but
modified_regs[17] is nonzero, and hard regs are never considered
equivalent if modified, so rtx_equal_for_thread_p always returns false
in this context, hence thread_jumps does nothing for ix86.

Has this ever worked?  Was there a time when a jump insn's condition
referred directly to the operands of what's now in the compare insn,
so that we didn't trip over the intervening set of reg:CC?

Any suggestions for a machine-independent way to fix this?

Greg