On Tue, 30 Jul 2024, Jakub Jelinek wrote:

> On Tue, Jul 30, 2024 at 02:26:05PM +0200, Richard Biener wrote:
> > > > (Which implies that we should introduce TARGET_I387_MATH to parallel
> > > > TARGET_SSE_MATH some day...)
> > > >
> > > > > +      default:
> > > > > +       return false;
> > > >
> > > > We don't want to enable HFmode for transfers?
> > 
> > Jakub indicated that wouldn't be safe - is it?
> 
> I was worried about that, but in everything I've tried it actually looked ok
> (both HFmode and BFmode).
> *mov{hf,bf}_internal uses GPRs to move stuff (or SSE registers), in both
> cases transferable.
> 
> And TFmode should be ok as well (i.e. IEEE quad, that shouldn't go through x87
> either, it is software emulated).

So something like the following then?

/* Implement TARGET_MODE_CAN_TRANSFER_BITS.  */
static bool
ix86_mode_can_transfer_bits (machine_mode mode)
{
  if (GET_MODE_CLASS (mode) == MODE_FLOAT
      || GET_MODE_CLASS (mode) == MODE_COMPLEX_FLOAT)
    switch (GET_MODE_INNER (mode))
      {
      case SFmode:
      case DFmode:
        return !(ix86_fpmath & FPMATH_387);
      case XFmode:
        /* Do not enable XFmode, there is padding in it and it suffers
           from normalization upon load like SFmode and DFmode when
           not using SSE.  */
        return false;
      case HFmode:
      case BFmode:
      case TFmode:
        /* IEEE quad and half and brain floats never touch x87 regs.  */
        return true;
      default:
        gcc_unreachable ();
      }

  return true;
}

Reply via email to