https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104445
--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Uroš Bizjak from comment #9)
> (In reply to rguent...@suse.de from comment #8)
> > > (In reply to Richard Biener from comment #6)
> > > > We are missing vec_extractv2sisi or vec_extractv8qiv4qi, with -mno-mmx
> > > > -mavx.
> > > > It seems we have addv2si3 available though.
> > >
> > > vec_extractv2sisi is available in mmx.md even with -mno-mmx:
> > >
> > > (define_expand "vec_extractv2sisi"
> > > [(match_operand:SI 0 "register_operand")
> > > (match_operand:V2SI 1 "register_operand")
> > > (match_operand 2 "const_int_operand")]
> > > "TARGET_MMX || TARGET_MMX_WITH_SSE"
> > > {
> > > ix86_expand_vector_extract (TARGET_MMX_WITH_SSE, operands[0],
> > > operands[1], INTVAL (operands[2]));
> > > DONE;
> > > })
> >
> > But I think with -m32 we have !TARGET_MMX_WITH_SSE
>
> Yes, that is true. Please note that in this case, we don't have addv2si3 as
> well as it also depends on TARGET_MMX_WITH_SSE.
Oh, the testcase doesn't use add but xorv8qi3. But since we're using
DImode for v8qi we of course do have support for it but also obviously
later will fail the vec_extract obtab queries ... a disi vec_extract
does not exist.
So it's the vectorizers fault to not properly account for scalar integer mode
vector types.
