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

[Wu, F. <fe...@in...>]

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?

Thanks,
Fei.

> This version solves the vector register group at the backend w/o a new
> register allocation algorithm, instead of using helper functions at the
> backend, this also enables the fast prototype by leveraging the code
> from QEMU, so this prototype does borrow a lot of QEMU code right now.
> But it's just an intermediate step, finally we will replace the QEMU
> code with intrinsics or generate the binary encoding directly to avoid
> the helper functions for performance. The framework itself is generic
> enough and don't need change during the transition.
> 
> Thanks,
> Fei.
> 
>