http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
--- Comment #22 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Uroš Bizjak from comment #21)
> --- config/i386/i386.c (revision 207935)
> +++ config/i386/i386.c (working copy)
> @@ -40666,9 +40666,9 @@ ix86_vectorize_vec_perm_const_ok (enum machine_mod
> if (!d.one_operand_p)
> d.op1 = gen_raw_REG (d.vmode, LAST_VIRTUAL_REGISTER + 3);
>
> - start_sequence ();
> + init_dummy_function_start ();
> ret = ix86_expand_vec_perm_const_1 (&d);
> - end_sequence ();
> + expand_dummy_function_end ();
>
> return ret;
> }
> --cut here--
>
> Jakub, what do you think about this patch?
IMHO that is way too expensive.
So, say expand_vec_perm_interleave2 is only called with d->testing_p from
ix86_vectorize_vec_perm_const_ok, and thus I'd say something like:
if (!d->testing_p)
{
dremap.target = gen_reg_rtx (dremap.vmode);
dfinal.op0 = gen_lowpart (dfinal.vmode, dremap.target);
}
dfinal.op1 = dfinal.op0;
should fix expand_vec_perm_interleave2. I think dfinal.op0 should have
dfinal.vmode already from the caller (we can easily perhaps gcc_checking_assert
double check it when testing the patch).
