Hi Robin,
>
> Wouldn't even/odd work for VLA just as well? Could even say it's more
> natural for them?
Yes, they would work for VLA naturally, and I'll support VLA in v2. Btw
I guess stuff like shuffle_interleave_patterns would also fit into VLA
well? Not the scope of the patch though.
> I like the "2x" trick here and wonder if we couldn't use it in the other
> pattern recognizers as well. Also, IIRC the 4x pattern also occurs in
> x264 codegen. Maybe it's possible to rewrite the perm somehow in a
> separate re-usable function?
>
I'll add a re-usable function for this in v2.
> Any reason why the first insn has an earlyclobber but the others don't?
> Is there overlap? Also, why vcompress rather than something else? I
> guess you just didn't want to introduce a new type? All this type
> matching should go away anyway so it might not be too bad but it's a bit
> misleading. Not a blocker I'd say.
I'll add a new type and remove the earlyclobber here. This was written
over a year ago downstream, and unfortunately we forgot the context. It
was probably from some an older internal version of the extension with
some deprecated overlapping rules.
>
> > --- /dev/null
> > +++
> > b/gcc/testsuite/gcc.target/riscv/rvv/autovec/vls-vlmax/shuffle-interleave-evenodd-run.c
> > @@ -0,0 +1,122 @@
> > +/* { dg-do run } */
> > +/* { dg-require-effective-target riscv_v_ok } */
> Why not rv64 here? Or maybe, why rv64 in the other test? :)
> Also, why no separate xth run tests?
>
> > +/* { dg-add-options riscv_v } */
> > +/* { dg-additional-options "-O3 -mrvv-max-lmul=m8 -std=gnu99" } */
>
> Are these supposed to be baseline tests? I'm not against that but would
> have expected them to execute the new functionality.
They were supposed to be baseline tests, and rv64 should not be required.
I'll change them to xxtvarith tests to test the
shuffle_interleave_even_odd_patterns path.
I'll send v2 soon.
Thanks,
Bohan