On Mon, 29 Jul 2024, Jakub Jelinek wrote:
> 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.
I guess the adjusted hook doing
if (GET_MODE_CLASS (mode) == MODE_FLOAT
|| GET_MODE_CLASS (mode) == MODE_COMPLEX_FLOAT)
switch (GET_MODE_INNER (mode))
{
case SFmode:
case DFmode:
return TARGET_SSE_MATH && !TARGET_MIX_SSE_I387;
default:
return false;
}
would cover that.
> For the vector V*[SDHB]Fmode it really depends on if it will be lowered to
> scalar or vector moves.
Hmm, indeed vector(4) float can get V4SFmode even without SSE enabled
since we use targetm.vector_mode_supported_any_target_p to decide
whether that mode is usable. So that might later get lowered to
x87 SFmode though the problematic load/store stmts are _not_ lowered
by vector lowering.
Indeed
typedef float v2sf __attribute__((vector_size(8)));
typedef int v2si __attribute__((vector_size(8)));
v2si v, v3;
v2sf v2;
void foo ()
{
v2sf x = *(v2sf *)&v;
v2si i = v;
v2 = x;
v3 = i;
}
gets optimized to
x_3 = MEM[(v2sf *)&v];
_7 = VIEW_CONVERT_EXPR<vector(2) int>(x_3);
v2 = x_3;
v3 = _7;
with -mno-sse even, but in the end the v2sf load prevails and gets
expanded via
movl v, %edx
movl v+4, %eax
same with double/long long.
So I _think_ this should not be a concern either. Actual float
operations remain float.
> 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.
I don't think relevant modes will have size/precision mismatches
and maybe_ne should work here. Richard?
> > 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.
The experiment above shows it "works". I'm not sure to what extent
the x86 makes sure that SFmode moves never end up in the FP stack
on x86-64 - this is why it's up to the target hook to say what's safe
and what not.
Maybe the hook documentation needs to clarify with RTL specific
wording I am not aware of - it basically says whether a move through MODE
is preserving the bit pattern (so mem <- reg, reg <- mem but also reg <-
reg).
Richard.
> > with SFmode like it allows vector(1) int with SImode.
> >
> > That said, the i386 implementation needs to handle XCmode, will
> > adjust.
>
> Jakub
>
>
--
Richard Biener <rguent...@suse.de>
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
