On Tue, Sep 29, 2020 at 9:46 PM Jim Wilson <j...@sifive.com> wrote:
>
> On Tue, Sep 29, 2020 at 3:47 AM 夏 晋 via Gcc <gcc@gcc.gnu.org> wrote:
> > I tried to set the "vlen" after the add & multi, as shown in the following
> > code:
>
> > vf32 x3,x4;
> > void foo1(float16_t* input, float16_t* output, int vlen){
> > vf32 add = x3 + x4;
> > vf32 mul = x3 * x4;
> > __builtin_riscv_vlen(vlen); //<----
> > storevf(&output[0], add);
> > storevf(&output[4], mul);
> > }
>
> Not clear what __builtin_riscv_vlen is doing, or what exactly your
> target is, but the gcc port I did for the RISC-V draft V extension
> creates new fake vector type and vector length registers, like the
> existing fake fp and arg pointer registers, and the vsetvl{i}
> instruction sets the fake vector type and vector length registers, and
> all vector instructions read the fake vector type and vector length
> registers. That creates the dependence between the instructions that
> prevents reordering. It is a little more complicated than that, as
> you can have more than one vsetvl{i} instruction setting different
> vector type and/or vector length values, so we have to match on the
> expected values to make sure that vector instructions are tied to the
> right vsetvl{i} instruction. This is a work in progress, but overall
> it is working pretty well. This requires changes to the gcc port, as
> you have to add the new fake registers in gcc/config/riscv/riscv.h.
> This isn't something you can do with macros and extended asms.
But this also doesn't work on GIMPLE. On GIMPLE riscv_vlen would
be a barrier for code motion if you make it __attribute__((returns_twice))
since then abnormal edges distort the CFG in a way preventing such motion.
> See for instance
>
> https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/Krhw8--wmi4/m/-3IPvT7JCgAJ
>
> Jim
