Thanks for review.
> 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.
>
I saw only VLS was supported, can't find why, so add VLA as well.
> > - 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... :)
my bad for missing that. I'll guard this in v2 and fall back to the
old path when modes don't match.
BTW, how did you test with zvl256? I didn't see that failure in my
regtest. did you just add -mrvv-vector-bits=zvl to my testcase?
>
> > +/* 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)?
No, that's not a regression.
On trunk now (https://godbolt.org/z/bjE5b7qPP) there are spills;
with this patch, it turns out to have no spills and 3 slideups.
What I meant here was just a hint for future work, ideally it should
only need 1 slideup and no spills, but that's not this patch's job.
--
Regards,
Zhongyao
