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;
}