[Bug middle-end/95528] [10/11 Regression] internal compiler error: in emit_move_insn, at expr.c:3814

[rsandifo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95528

--- Comment #6 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #4)
> I'd say the vectorizer/simplify_vector_constructor just shouldn't attempt to
> use these (e.g. vec_pack*, vec_unpack* optabs) for !VEC_MODE_P unless it is
> VECTOR_BOOLEAN_TYPE_P type.
> For i386 it would be the right thing as the patterns really assume that it
> is vector booleans and have their properties.
> Though, aarch64 seems to have vec_pack_trunc_di and vec_pack_trunc_df
> expanders, it is unclear to me what they are for and if they are really used.
> Other targets seem to only define these for vector modes.
Yeah, I agree those look odd.  The covering note for the patch
that added them was:

  https://gcc.gnu.org/pipermail/gcc-patches/2013-April/361636.html

which talks about fixing gcc.dg/vect failures.  But as James says,
only the 128-bit patterns should be needed for that.  Maybe the
the 64-bit patterns were just added for completeness.

Perhaps one justification for _di is that there is no V1DI mode.
Instead a vector of 1 DImode would itself have mode DImode.
So in principle, vec_pack_trunc_di is probably the right name
for a (V1)DI->V2SI truncate.

The same doesn't apply to _df since we don't use scalar float
modes for V1 vectors.  And (unlike at the time of the patch)
we now have V1DF.  So I agree that the _df one looks dead.

That said, for AArch64 we'd now try to mix 128-bit and 64-bit
vectors instead of vectorising with 2 64-bit vectors.  So the
_di pattern probably isn't useful in practice either.

In summary: from an AArch64 perspective, it's probably fine to
check !VECTOR_MODE_P || VECTOR_BOOLEAN_TYPE_P.  But given the V1
thing, maybe it would be better to add || m == GET_MODE_INNER (m)
as well (unless that defeats the fix).