On Wed, Sep 30, 2020 at 10:01 PM Jim Wilson <j...@sifive.com> wrote:
>
> On Tue, Sep 29, 2020 at 11:40 PM Richard Biener
> <richard.guent...@gmail.com> wrote:
> > 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.
>
> At the gimple level, all vector operations have an implicit vsetvl, so
> it doesn't matter much how they are sorted. As long as they don't get
> sorted across an explicit vsetvl that they depend on. But the normal
> way to use explicit vsetvl is to control a loop, and you can't move
> dependent operations out of the loop, so it tends to work. Setting
> vsetvl in the middle of a basic block is less useful and less common,
> and very unlikely to work unless you really know what you are doing.
> Basically, RISC-V wasn't designed to work this way, and so you
> probably shouldn't be writing your code this way. There might be edge
> cases where we aren't handling this right, as we aren't writing code
> this way, and hence we aren't testing this support. This is still a
> work in progress.
>
> Good RVV code should look more like this:
>
> #include <riscv_vector.h>
> #include <stddef.h>
>
> void saxpy(size_t n, const float a, const float *x, float *y) {
> size_t l;
>
> vfloat32m8_t vx, vy;
>
> for (; (l = vsetvl_e32m8(n)) > 0; n -= l) {
> vx = vle32_v_f32m8(x);
> x += l;
> vy = vle32_v_f32m8(y);
> // vfmacc
> vy = a * vx + vy;
> vse32_v_f32m8(y, vy);
> y += l;
> }
> }
Ah, ok - that makes sense.
> We have a lot of examples in gcc/testsuite/gcc.target/riscv/rvv that
> we are using for testing the vector support.
That doesn't seem to exist (but maybe it's just not on trunk yet).
Richard.
> Jim
