On Mon, Feb 26, 2024 at 09:53:41AM +0100, Richard Biener wrote:
> On Mon, 26 Feb 2024, Jakub Jelinek wrote:
>
> > On Mon, Feb 26, 2024 at 09:00:58AM +0100, Richard Biener wrote:
> > > > > @@ -6756,7 +6756,8 @@ vectorizable_operation (vec_info *vinfo,
> > > > > those through even when the mode isn't word_mode. For
> > > > > ops we have to lower the lowering code assumes we are
> > > > > dealing with word_mode. */
> > > > > - if ((((code == PLUS_EXPR || code == MINUS_EXPR || code ==
> > > > > NEGATE_EXPR)
> > > > > + if (!INTEGRAL_TYPE_P (TREE_TYPE (vectype))
> > > > > + || (((code == PLUS_EXPR || code == MINUS_EXPR || code ==
> > > > > NEGATE_EXPR)
> > > > > || !target_support_p)
> > > > > && maybe_ne (GET_MODE_SIZE (vec_mode), UNITS_PER_WORD))
> > > > > /* Check only during analysis. */
> > >
> > > I think it will work fine. Even after the last TLC this feels like in
> > > the need of more TLC ;)
> >
> > Note, at least in theory, floating point NEGATE_EXPR could be handled just
> > fine in the emulated vectors, just xor the sign bit, and
> > BIT_{AND,IOR,XOR}_EXPR also would work but likely aren't valid IL on
> > floating point modes (though e.g. in RTL they are used even for them),
>
> Hmm, I think vector types not supported only ever get integer modes
> assigned, not FP modes so the operations would be on integer modes.
I mean one could still SLP vectorize using the emulated vectors
float a[2], b[2];
...
a[0] = -b[0];
a[1] = -b[1];
as effectively
*(unsigned long long *)a = *(unsigned long long *)b ^ 0x8000000080000000ULL;
if we handled that case later on (except the above !INTEGRAL_TYPE_P check
would prevent that).
As for BIT_{AND,IOR,XOR}_EXPR, seems the GIMPLE verifiers actually don't
disallow
float f, g;
f_3 |= g_4;
etc. (but the FEs do), though maybe we'd ICE on some targets during
expansion; i386.md has {and,ior,xor}{s,d,x}f3 optabs.
Emulation using integer mode would be well defined.
Jakub
