Hi Zhongyao,
Sorry for the long delay and thanks for working on this.
I assume you added the VLA modes to the iterator for
-mrvv-vector-bitz=zvl? I think that's a good thing, at least until we
manage to represent vec_extract etc. differently in the middle end. I'm
pretty far with that patch but not yet finished. Also it might be
contentious so I wouldn't want your patch to depend on it.
Adding HF and BF is fine, they were just forgotten before.
> - rtx ops[] = {d->target, d->target, tmp, gen_int_mode (vlen / 2,
> Pmode)};
> - icode = code_for_pred_slide (UNSPEC_VSLIDEUP, vmode);
> - emit_vlmax_insn (icode, SLIDEUP_OP_MERGE, ops);
> +
> + machine_mode imode = related_int_vector_mode (vmode).require ();
> + emit_insn (gen_vec_concat (imode, gen_lowpart (imode, d->target),
> + lo, hi));
I did quick local testing and saw an ICE here with zvl256. I think the
issue is that with -mrvv-vector-bits=zvl we can get a mix of VLA "in
name" modes with fixed size as well as real VLS modes. And obviously we
don't define vec_concat_rvvmf2si_v2si or something so gen_vec_concat
will return NULL. For the time being you'd need to guard against that
and use the old code path. We have been hitting this issue repeatedly
with vec_extract. A high-maintenance solution would be to split all our
patterns into VLA and VLS but... :)
> +/* FIXME (missed optimization): Ideally each concat needs only 1
> vslideup,
> + but frontend lowering of __builtin_shufflevector currently zero-pads each
> + half-width input first, resulting in 2 padding constructors and 1 concat
> + per function (35 * 3 = 105). */
It looks like we need more slideups than before for certain cases? Is
that only for LMUL>1? Why is that? Before we could just slideup one
element while we now have two zero-padded vectors that are being
combined? If so, can we exclude those cases (everything <=
REGMODE_NATURAL_SIZE)?
--
Regards
Robin
