Re: [Valgrind-developers] [RFC 00/12] RISC-V Vector support for Valgrind

[Petr P. <pet...@da...>]

On 25. Sep 23 10:14, Wu, Fei wrote:
> On 8/21/2023 4:57 PM, Wu, Fei wrote:
> > On 5/26/2023 10:08 PM, Wu, Fei wrote:
> >> On 5/26/2023 9:59 PM, Fei Wu wrote:
> >>> I'm from Intel RISC-V team and working on a RISC-V International
> >>> development partner project to add RISC-V vector (RVV) support on 
> >>> Valgrind, the target tool is memcheck. My work bases on commit
> >>> 71272b252977 of Petr's riscv64-linux branch, many thanks to Petr for his
> >>> great work first.
> >>>     https://github.com/petrpavlu/valgrind-riscv64
> >>>
> > A vector IR version has been added into this repo (branch poc-rvv):
> >     https://github.com/intel/valgrind-rvv/commits/poc-rvv
> > 
> > A bunch of RVV instructions have been enabled, and I plan to enable more
> > instructions to run some general benchmarks, coremark is the first one.
> > 
> I enabled all the RVV instructions except floating-point and fixed-point
> ones, I think it's ready to have a try and an initial review.
> 	https://github.com/intel/valgrind-rvv/commits/poc-rvv
> 
> The designs of this patch series:
> * All the RVV instructions have a corresponding vector-IR, except
> load/store which is still using the split-to-scalar pattern according to
> the mask.
> * Most of the instructions where each element is calculated
> independently such as vadd, are implemented as (read origin, calculate
> the result as unmasked version, apply mask), so that it's not necessary
> to define both masked and unmasked version for the same vector IR. For
> the other instructions such as vredsum, the masked and unmasked
> instructions are treated differently.
> * Besides the `vl' which is encoded in vector op/ty, there are some
> other info such as vlmax needed to pass from frontend to backend, we
> have a basic method to do it.
> 
> I have done very limited testing on the code, usually a very basic test
> for single instruction correctness. The memcheck logic for some
> instructions still wait for polishing, it might not be able to find all
> the bugs memcheck is supposed to identify, but at least it shouldn't
> block us to try it against rvv binaries and find the bugs unrelated to
> RVV instructions.
> 
> @Petr, could you please take a look?

Sorry, I somehow missed this email and only noticed it now. I'll try to
find some time to have a look. I played a bit with SVE support in
Valgrind last month. I didn't get as far as I wanted to but it gave me
some understanding what could work and where different approaches might
be too much RISC-V specific.

Petr