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

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

On 10/19/2023 5:22 AM, Petr Pavlu wrote:
> 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.
> 
Thank you Petr. We can plan next step if this method is agreed to be the
right direction.

Thanks,
Fei.

> Petr