On Mon, Jul 29, 2024 at 02:52:24PM +0200, Richard Biener wrote:
> > mode = GET_MODE_INNER (mode);
> > ?
>
> I specifically wanted to avoid this (at least for the purpose of the
> hook).
>
> > I mean say XCmode has similar problems as XFmode, or
> > V4SFmode as SFmode if i?86 -mno-sse.
> > Though, admittedly, with i?86 -msse2 -mfpmath=387 perhaps some vector modes
> > could work, which would argue for passing even vector modes to the hook.
> > Though the GET_MODE_BITSIZE != GET_MODE_PRECISION check then wants the inner
> > modes maybe.
>
> We do not support vector inner modes with padding. I didn't think of
> XCmode - though precision is 160 here and size 192, so the padding
> check should work there as well.
One thing is XCmode, another one is SCmode/DCmode/HCmode/BCmode without
-mfpmath=sse, there the target hook should say that it can't transfer bits.
For the vector V*[SDHB]Fmode it really depends on if it will be lowered to
scalar or vector moves.
And, for the GET_MODE_INNER, I also meant it for Aarch64/RISC-V VL vectors,
I think those should be considered as true by the hook, not false
because maybe_ne.
> For vector I think the x86 backend ensures we never get x87 modes as
> components. The middle-end will also not allow vector(1) float
It ensures there are no V*XFmode vectors. But whether say V*SFmode vectors
will result in vector moves which move everything safely or scalar which
would use x87 and be unsafe is unsure.
> with SFmode like it allows vector(1) int with SImode.
>
> That said, the i386 implementation needs to handle XCmode, will
> adjust.
Jakub
