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