Re: i386.md floating point comparison with general register

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

  In message <199903270312.WAA00768@jwlab.FEITH.COM>you write:
  > I'm looking at improving the i386 floating point comparision
  > patterns and am curious about:
  > 
  >   [(set (cc0)
  >         (match_operator 2 "VOIDmode_compare_op"
  >                         [(match_operand:XF 0 "register_operand" "f")
  >                          (float:XF
  >                           (match_operand:SI 1 "nonimmediate_operand" "rm"))]))
  > 
  > Which appears to be a pattern for the benefit of combine.  What seems odd
  > is the pattern allows the comparison of a floating point register with a
  > general register which the i386 doesn't actually support.  It's currently
  > implement by having output_float_compare load the general register into a
  > floating point register and then doing the comparison.  Why is it useful to
  > hide this move from gcc?  Should this pattern perhaps be:
  > 
  >   [(set (cc0)
  >         (match_operator 2 "VOIDmode_compare_op"
  >                         [(match_operand:XF 0 "register_operand" "f")
  >                          (float:XF
  >                           (match_operand:SI 1 "memory_operand" "m"))]))
I'd tend to agree with you.  This is precisely the kind of thing we need to
be fixing in i386.md

The only concern would be that we may be using this as a bridge pattern in
the combiner.  Consider that typically a memory operand will be loaded into
a register, so it would be rather unusual for operand1 to be a memory
operand.  By first matching the register for operand1 it is more likely that
we will then be able to re-combine the pattern with the instruction that
loaded the register from memory.

I don't have any kind of a feel for whether or not we're better off with
the existing pattern or a new one.

If we keep the existing pattern, we probably want a splitter so that we can
expose the intermediate steps.

jeff