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;
}
}
We have a lot of examples in gcc/testsuite/gcc.target/riscv/rvv that
we are using for testing the vector support.
Jim
