Re: alpha failure on 920810-1

[Jeffrey A Law <law@cygnus.com>]

  In message < 19980430173828.15223@dot.cygnus.com >you write:
  > On Wed, Apr 29, 1998 at 10:57:53PM -0700, I wrote:
  > > In conversation with Jim today, we decided that 
  > > 
  > >          (set (reg:DF 1) (eq:DF (reg:DF 2) (reg:DF 3)))
  > >          (set (reg:DF 4)
  > >            (if_then_else:DF (eq:CC (reg:DF 1) (const_int 0))
  > >              (reg:DF 5) (reg:DF 4)))
  > > 
  > > is a reasonable compromise.  It turns out that combine already knows
  > > that it can't do anything with CCmode compares, and with my previous
  > > patch modified just a tad, that takes care of loop, jump, and cse.
  > > 
  > > I've bootstrapped succesfully with these changes, and am currently
  > > running Spec95.  Patches will follow once no regressions are shown.
  > 
  > Here they are, as promised.  Ok to apply?
  > 
  > 
  > r~
  > 
  > 
  > 
  > Thu Apr 30 17:27:47 1998  Richard Henderson  <rth@cygnus.com>
  > 
  > 	* loop.c (get_condition): Don't combine when either compare is MODE_CC.
  > 	* machmode.h (COMPLEX_MODE_P): New macro.
  > 	* alpha.c (alpha_emit_conditional_branch): New function.  Taken from
  > 	the body of beq, additionally set the mode of the branch to CCmode for
  > 	FP compares and not fast_math.  
  > 	(alpha_emit_conditional_move): Always use a compare insn for FP
  > 	when not fast_math, as well as setting CCmode on the cmov.
  > 	* alpha.md (beq, bne, blt, et al): Call alpha_emit_conditional_branch.
Seems pretty reasonable to me if Jim doesn't have objections.

I note that your patch doesn't actually use COMPLEX_MODE_P, but I do
think we ought to have it to be consistent with the other *_MODE_P
tests.

jeff