Valgrind On-boarding Project for Intel

[jjscheel]

Technical Group

Applications & Tools HC

ratification-pkg

Vector

Technical Liaison

Haicheng

Task Category

Other

Task Sub Category

• gcc
• binutils
• gdb
• intrinsics
• Java
• KVM
• ld
• llvm
• Linux kernel
• QEMU
• Spike

Ratification Target

3Q2023

Statement of Work (SOW)

Component names:
Valgrind

Requirements:

1. Design and implement a general framework to support RVV instructions on Valgrind
   including binary disassembly, IR encoding and instrumentation.
2. Enable valgrind memcheck and riscv vector unit-stride load/store instructions to demonstrate Valgrind
   RVV framework functionality.

Deliverables:

• General framework to support RVV instructions in Valgrind
• Valgrind memcheck with RVV unit-stride load/store instruction support
• Support 32 vector registers, and related unprivileged CSRs (vtype, vl, vlenb)
• Vector Configuration-Setting Instructions Support (vsetvli/vsetivli/vsetvl)
• Vector unit-stride Load/Store Instructions Support (vle8/vle16/vle32/vle64/vse8/vse16/vse32/vse64/vle8ff/vmseq/vmseq/vmsne/vmor/vfirst/vlm/vsm/vmsif/vmv)

Acceptance Criteria:

• Such test cases get pass in https://github.com/riscv-non-isa/rvv-intrinsic-doc/tree/master/examples:
  • rvv_memcpy.c
  • rvv_strcmp.c
  • rvv_strcpy.c
  • rvv_strlen.c
  • rvv_strncpy.c
• Memcheck can detect out the errors injected by some modifications based on above test cases.

Projected timeframe: 2023-06-30

SOW Signoffs:

• Task group liaison sign-off:
• Development partner sign-off
• Application & Tools HC sign-off (if POC or toolchain/library work):

Waiver

• Freeze
• Ratification

Pull Request Details

No response

[haicheng-li]

there is not edit button, so maybe I can create another issue to track it. how do you think? @jjscheel

[jjscheel]

@haicheng-li, I see that. We can do 2 things:

1. I can input your text from the document you sent me
2. You can create your own item which will allow you to edit your comments

Let me know if you want me to do the first item.

[haicheng-li]

• I can input your text from the document you sent me

Pls. help input the text then. Thanks.

[jjscheel]

@haicheng-li, i've provide the information from the Valgrind-RVV-intel-SOW.docx included in your email. Please let me know if this is what you need.

[haicheng-li]

@haicheng-li, i've provide the information from the Valgrind-RVV-intel-SOW.docx included in your email. Please let me know if this is what you need.

@jjscheel, yes, it's our proposed SOW, thanks for the help. Could we proceed the sign-off process if there is no objection to the plan? thanks.

[jjscheel]

@ptomsich, can you review the contents of the SOW in the first entry of this issue and confirm your signoff and/or propose any needed updates? Thanks!

[jjscheel]

The SOW has been approved. Marking the item as such.

@haicheng-li, I look forward to status on your progress. THANKS!!!!

[jjscheel]

@haicheng-li, please give some thought as to "sizing" the effort and then extrapolate that to when you think the last PR will be accepted for the work (i.e. we are completely done) with this. Generally, on-boarding items should take 1-3 months, but that is a guideline, not a rule.

[atwufei]

we have posted the initial RFC patch series here:
https://sourceforge.net/p/valgrind/mailman/message/37850301/

[jjscheel]

Thanks, @atwufei! It is good to see some response in the thread too.

[jjscheel]

@ptomsich, it would be greatly appreciated if you'd provide your feedback on the code as part of the mentoring for this on-boarding project. Thanks!

[jjscheel]

@haicheng-li, @atwufei, would you kindly provide a brief summary of the information you shared in Tuesday's meeting here? Thanks!

[atwufei]

I have sent out the patches with the prototype of new vector-IR design, Petr gave some positive reviews in general. He will try to verify if this design is also suitable for ARM SVE2, we can move faster after it's proved to be the generic solution for vlen vector.

https://sourceforge.net/p/valgrind/mailman/valgrind-developers/?viewmonth=202307&viewday=18

[jjscheel]

Thanks, @atwufei! It sounds like we are making good progress.

When we have verification that the community is happy with the design and the PR is in good shape, I propose we can declare this item complete.

[atwufei]

We have a public tree for this:
https://github.com/intel/valgrind-rvv/tree/poc-rvv

This branch has the initial code of vector IR, which looks the preferred method for RVV on valgrind. It can run some test cases with RVV instructions.

[jjscheel]

@ptomsich, per my email, please review the PR from Wufei and let me know if we can declare the Intel on-boarding as a DevPartner complete. Thanks!

[jjscheel]

@atwufei, I have approval from Philipp for the on-boarding process. We will now consider Intel a full Development Partner. Thank you and congratulations.

I'll get updates to the site and ensure we get this announced in the coming week through various RISC-V areas.

[haicheng-li]

great to hear the progress, and thanks all for help to make this happen! @jjscheel @atwufei @ptomsich

[jjscheel]

@atwufei, any updates?

[atwufei]

I've committed a lot more patches to the repo: https://github.com/intel/valgrind-rvv/tree/poc-rvv

The majority of the integer rvv instructions are enabled except a few, it can run coremark compiled with auto-vecterization option, and we expect to complete the integer rvv instructions. Please note:

1. "enable" means valgrind can run the binary with this instructions, there is still work to make the semantics of memcheck right, although I have tried to make it so, we might not find every memory access problem in rvv instruction, but the bottom line is that there is no side-effect on non-rvv instruction.
2. we have not tested it very much, we try to support more instructions first.
3. no work on fixed-point and floating-point insn yet, they are low priority.

[jjscheel]

@atwufei, can you summarize the recent activity here when you have a moment? Thanks!

[atwufei]

After I sent the RVV prototype, Petr, who is the maintainer of valgrind riscv porting, investigated ARM SVE on valgrind and now he has an initial SVE prototype, so it's the time to seek for a unified solution for both and even other vector ISAs.

Regarding to my RVV prototype, Petr's most concern is that "vl" is embedded into every IRType, which he thinks it's too riscv-centric and it has some drawbacks. His proposal is to use "mask" to represent "vl", which I think it's too sve-centric, we need a concrete solution for all the rvv instructions from both function and performance perspectives if we want to go this way. Currently the discussion is still ongoing.

[ptomsich]

Representing "vl" as a constraint on the "mask" sounds like a good implementation choice, especially given future directions for RISC-V SIMD summarized in https://github.com/riscv-admin/vector/blob/main/taskgroups/DEB.md

…

On Tue, 28 Nov 2023 at 07:04, Wu Fei ***@***.***> wrote: After I sent the RVV prototype, Petr, who is the maintainer of valgrind riscv porting, investigated ARM SVE on valgrind and now he has an initial SVE prototype, so it's the time to seek for a unified solution for both and even other vector ISAs. Regarding to my RVV prototype, Petr's most concern is that "vl" is embedded into every IRType, which he thinks it's too riscv-centric and it has some drawbacks. His proposal is to use "mask" to represent "vl", which I think it's too sve-centric, we need a concrete solution for all the rvv instructions from both function and performance perspectives if we want to go this way. Currently the discussion is still ongoing. — Reply to this email directly, view it on GitHub <#31 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADSKDHTT5Z6VHJVYPW45K73YGV5HBAVCNFSM6AAAAAAW2VC76GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRZGE3TKOBWGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[jjscheel]

FYI, an email was received from David Abdurachmanov about build hardware for Valgrind:

Valgrind upstreaming is stuck
for months now [2]. One of the reasons for that is the lack of
available hardware for development. There are no builders in
http://builder.sourceware.org/ Naturally I looked into cfarm (GCC
Compile Farm) and there aren't many boards either.

[2] https://bugs.kde.org/show_bug.cgi?id=468575

I will work with David to address the issue as best we can.

Please be aware of the RISC-V Developer Board program described here:
https://riscv.org/risc-v-developer-boards/

Interested projects/parties should follow the yellow button to this page and apply for appropriate hardware:
https://riscv.org/risc-v-developer-boards/details/

Please let me know if you hear of any concerns in this area and feel free to make introductions as needed.

[haicheng-li]

Fei is working on PoC development of the revised design that removes vl from IR. We will get back to discuss with Petr when PoC is done and tested working fine for ARM side.

[haicheng-li]

https://sourceforge.net/p/valgrind/mailman/message/58728269/
the PoC of revised design was done and sent out for review.

[jjscheel]

Are we still making progress here? Anything to share?

BTW, I notice that this is closed. Any idea when and why that was done?

[jjscheel]

Looks like it was closed late last year, likely inadvertently. Re-opened mostly for tracking purposes. We can close again if people feel strongly about it, but typically we keep open until PR accepted upstream.

[haicheng-li]

Xiao Wang ([email protected]) will work on this together with Fei.
his github account is XiaoWang1772

[jjscheel]

Thanks, @haicheng-li. I've added Xiao in Groups.IO and will get an invite out shortly to the
riscv-devpartner-partners team in the riscv-admin organization. That will enable access to this and all issues.

[jjscheel]

Welcome, @XiaoWang1772!

[XiaoWang1772]

I would work with Jun from CAS to continue the effort to support B-ext, V-ext. We need to ramp up on the current project status first. Thanks.