Problem when defining new mips insns

[Roger Sayle]

On 23 Oct 2004, Pontus Lidman wrote:
> Thank you for your reply. Perhaps I should have mentioned that it's on
> mips64. TImode integers are 16 bytes, DImode ones are 8, so
> sizeof(DImode)==sizeof(double). So I don't understand why it wants to
> use TImode values in this case.

I think if you discover that you'll be closer to debugging your patch :>
The relevant code is (perhaps) around line 2285 of optabs.c:

  /* Try negating floating point values by flipping the sign bit.  */
  if (unoptab->code == NEG && class == MODE_FLOAT
      && GET_MODE_BITSIZE (mode) <= 2 * HOST_BITS_PER_WIDE_INT)
    {
      const struct real_format *fmt = REAL_MODE_FORMAT (mode);
      enum machine_mode imode = int_mode_for_mode (mode);
      int bitpos = (fmt != 0) ? fmt->signbit : -1;

You need to discover why int_mode_for_mode (DFmode) is returning
TImode instead of DImode.  Another possibility is that your target
is unable to perform a DImode XOR, so expand_binop(imode, xor_optab, ...
is widening the operation to TImode.

And of course, the above code should never even get executed unless
your MIPS variant doesn't have a negdf2 pattern!?  It looks like
CVS mainline's current mips.md unconditionally defines a negdf2.

Roger
--