Re: [PATCH] Jump bypassing and improved constant propagation

[Richard Henderson <rth at redhat dot com>]

On Sun, May 26, 2002 at 09:45:36PM -0600, Roger Sayle wrote:
> I'm sure you realize, but its not that it "cannot be moved", but
> rather that it "isn't currently moved" or is "much harder to move" :>

Point taken.

> Dare I mention PR opt/6405 which was in response for your "Request
> for Regressions" http://gcc.gnu.org/ml/gcc/2002-02/msg00307.html ?

That's not really the same thing.  That if leaves the loop.  I'm
thinking more of

	for (i = -1; i < 10; ++i)
	  {
	    char *p;
	    if (i < 0)
	      p = "";
	    else
	      p = &array[i];
	    // do something with p
	  }

where perhaps loop decides that the i*4 giv isn't always computed
so we won't reduce it.  Whereas if the loop had been written with
a conditional move everything would have been fine.

Maybe.  It's just a guess.

> It may just be my misunderstanding but I was hoping to extend the
> existing "#ifdef HAVE_cc0" to targets such as x86, that don't have
> a single cc0_rtx, but instead several MODE_CC registers that are set
> immediately before a conditional jump.  I'd assumed, perhaps very
> incorrectly, that "GET_MODE_CLASS (GET_MODE (cc0_rtx)) == MODE_CC"
> making the current code a simplified superset of the original.

Nope, the two cases are disjoint.  GET_MODE (cc0_rtx) == VOIDmode.

> Let me know if I still need "#ifdef HAVE_cc0".

Yep.

> 
> > What if the target uses DImode comparisons to feed the jump
> > insn (e.g. alpha)?
> 
> Unfortunately, CVS isn't bootstrapping for me on alphaev67-dec-osf5.1
> at the moment.

Really?  It built for me on linux on Friday...

> How are DI mode comparisons handled on the alpha
> and similar architectures?  [I'll investigate at work tomorrow].

On alpha, conditional branches are of the form

	(if_then_else (OP (match_operand:DI 0 "register_operand" "r")
			  (const_int 0))
		      ...)

where OP is any of EQ,NE,LT,GT,LE,GE.  That is, we compare and register
against zero and branch in one instruction.  If we want to compare
against something other than zero, say X < Y, then we have a compare
instruction whose result is a boolean 0/1, then we branch EQ/NE against
that.

On ia64, conditional branches use predicate registers, which are single-bit
booleans.  So the result of the compare instruction is a BImode register.
On x86-type architectures the flags are complex enough that we get in
trouble if we assume too much about them.  Thus the checks for MODE_CC
in jump.c and in combine.c wrt suppression comparison reversals.  Thus
we get better results if we tell the compiler "yes, this really is just
a truth value; do what you want".

> This I wasn't 100% sure of.  I knew that cc0 was supposed to be
> dead following the jump instruction.  I was hoping the same was
> true for CC_MODE, which seems to be backed up on x86 for atleast
> GCC bootstrap, testsuite and SPEC2000.

For x86, it's definitely going to be true.  First, the flags are
modeled with a fixed hard register, which GCSE isn't going to touch.
Second, virtually everything clobbers the flags, which means that
even if GCSE did handle hard regs, expressions involving these
quantities are immediately killed.

> My contingency if this turned out not to be the case, was to use
> insert_insn_on_edge to place a copy of the original "setcc" on the
> redirected edge.

Not a bad idea.  Especially for the case of MODE_INT results, 
for which you could emit the folded constant result.

> If it transpired that the condition code wasn't used, the insn
> would be marked dead and cleaned up later.  The worry was that
> inserting insns on each edge in the hope that they'd be cleaned
> up would slow down the compiler, especially if they were never
> actually required.

It would be *really* nice to avoid emitting code that is almost
always not going to be used...

> Can the limited lifetimes of CC_MODE registers be guaranteed in early
> passes (GCSE) or on some platforms?

I would be hesitant to allow such guarantees.  That's the kind of
thing that you forget about two years down the road and then find
out that rearranging the order of optimization passes resulted in 
situations which violate the assumptions.

> > One more thing: have you checked to see if this completely obsoletes
> > thread_jump?  If so, we can delete it.  If not, which cases are still
> > caught by the old code?  Are there enough remaining to justify the
> > time spent?
> 
> I was hoping to get the existing performance improving code reviewed
> before investigating "redirect_edge_and_branch_force" or the effects
> of disabling passes or rearranging their order.  If "jump bypassing"
> was considered inappropriate for GCC there'd be no point in tweaking
> the implementation.

I think this idea is definitely promising, don't get me wrong.
But I think given that you're adding functionality that (partially)
overlaps existing code, these questions are better asked sooner
that later.


r~