Profiles Compilers

[jjscheel]

Technical Group

Profiles TG

ratification-pkg

Profiles

Technical Liaison

Christoph Muellner

Task Category

Compilers/Toolchain

Task Sub Category

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

Ratification Target

1Q2023

Statement of Work (SOW)

SOW: link

SOW Signoffs: (delete those not needed)

• Task group liaison sign-off date:
• Development partner sign-off date:
• Toolchains & Runtimes sign-off date (if gcc, LLVM, binutils, gdb work):

Waiver

• Freeze
• Ratification

Pull Request Details

RISC-V PRs

• RISC-V -march parameter documentation
• RISC-V Profiles Conventions Proposal
  ...

Upstream PRs

...

[jjscheel]

Mar 27 status from @cmuellner:

Here is a short follow-up on this topic.
We agreed to split up the proposal into four PRs to handle the changes
more efficiently and to avoid confusion about what is current
behaviour and what is targeted behaviour:

• document current -march string
• document -march string relaxation
• add custom extensions
• add profiles support

Jiawei volunteered to drive this forward.
Kito and I will support him as much as we can.

[jjscheel]

@pz9115, do you have a projected date by which this might be done and all PRs accepted?

Would you also provide links to the PRs here once they are submitted?

Thanks!

[pz9115]

I prepared this doc to record profile implement details in toolchain.

https://docs.google.com/document/d/1TZXRIgVfQHWQ6xrZflHXUCSav6xNmliojrW2bEsvPno/edit

[jjscheel]

@pz9115, thanks for the document link. What is your projected date for all PRs accepted?

[pz9115]

Should I open a new PR for this proposal, I'm not sure.

[jjscheel]

@cmuellner, can you answer @pz9115's question? I do not feel qualified to advise here. Thanks!

[jjscheel]

@pz9115, per our discussion last week and lacking an answer from @cmuellner, I believe you should proceed with your PRs as you see best. Christoph has clearly confirmed that you are in the lead here and documented what needs to be done.

Thanks for driving!

[cmuellner]

Sorry, I did not see the original notification back then.
Yes, sure, go ahead and create a new PR.

[pz9115]

Ok, I just open this new PR:
riscv-non-isa/riscv-toolchain-conventions#36

[jjscheel]

@pz9115, how long do you think it will take to have all PRs written and accepted to the riscv repos? Then, how long do you think it will take to get these changes upstreamed to the main communities?

I'm trying to pick a target date for when this item might be "done" (all PRs accepted upstream). So, any thoughts on what would be a target date would be appreciated too.

[pz9115]

I think it may take one month for the PR merged, and may take another month for upstream works, hopefully it will faster than I thought.

[jjscheel]

Great. How about we set a date for "Completion target" as July 31, 2023?

[pz9115]

Ok, for me, it seems need a long term.

[jjscheel]

I've updated the Completion Target date. THANKS!!!

[cmuellner]

In today's SIG Toolchain call, the following reminder has been brought up: toolchain support for profiles does not only need a proper extension of the -march-string and a corresponding implementation in the toolchain components. It also requires adding support for the extensions that are ratified alongside the profiles (see chapter 7 of the ratified v1.0 profiles specification).

[pz9115]

In today's SIG Toolchain call, the following reminder has been brought up: toolchain support for profiles does not only need a proper extension of the -march-string and a corresponding implementation in the toolchain components. It also requires adding support for the extensions that are ratified alongside the profiles (see chapter 7 of the ratified v1.0 profiles specification).

Okay, it's sounds reasonable. We should implement those unratified extensions in profiles, but just keep their names. Currently toolchain will do nothing with them, until they go ratified. I had sent a patch to do this, and I think it needs some tweaking now: https://gcc.gnu.org/pipermail/gcc-patches/2022-November/604868.html

[jjscheel]

@pz9115, when you get a feel for how much work exists in these additional extensions, please provide some thoughts on when you expect to submit the final PR for this work.

[pz9115]

The first step of documenting the format of RISC-V Profiles using in the compiler has been basically completed, and it will be officially merged into the riscv-toolchain-conventions document around the end of the month.
The second step is to support RISC-V profiles in the upstream of GCC. I had already sent an RFC patch, and it can be resent with some simple modifications. Of course, this will take a while to review, and it is estimated that there will be progress in an extra month.

[jjscheel]

Thanks, @pz9115. Can you kindly provide links to your PRs as comments? Then, I'll copy into the description so we have a nice summary when done.

[pz9115]

Thanks, @pz9115. Can you kindly provide links to your PRs as comments? Then, I'll copy into the description so we have a nice summary when done.

Of course, thank you Jeff.

riscv-non-isa/riscv-toolchain-conventions#36

[jjscheel]

@pz9115, thanks for the update.

I notice that the PR is for the RISC-V repository. We will want to track the work all the way into the upstream repositories for completeness. So, please make sure to add those too when they are available (if you have them). Thanks!

[pz9115]

Yes, It's for RISC-V repository and define the basic format that profile name should follow. It still under discussing about the Zicc* extensions effect for toolchain behaviour. Maybe recently will release a doc to make it more clearly.

[jjscheel]

@pz9115, any updates here?

[cmuellner]

We touched this yesterday in the SIG toolchain call. There were no comments to the march-string proposal for quite some time. So the next step would be to send patches to the upstream projects (Binutils, GCC, LLVM) to get them reviewed.

[pz9115]

WIP, plan to resend patches within this month.

[jjscheel]

Thanks, @pz9115! Please list PRs when submitted!

[pz9115]

Discussed in the last RISC-V GNU toolchain meeting, WIP.

[pz9115]

Resent patches to upstream, status change to in review, expect to generate many new discussions:

https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637490.html

[pz9115]

No new recovery has been received yet， waiting for comments, maybe will discussing next SIG-Toolchain meeting in next Monday.

[pz9115]

Reviewed by Jeff Law and resend the patch, re-reviewing

https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640324.html

[jjscheel]

@pz9115, can you provide an update here too?

[pz9115]

Palmer suggested to wait Profiles spec get more progress:

https://gcc.gnu.org/pipermail/gcc-patches/2023-December/641025.html

I will resend dummy extensions support in gcc part first as Christoph's suggestion:

https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640332.html

[pz9115]

Since there is still a lot of discussions in Profiles TG, we want to wait gcc-15(release in May) to reimplement the total Profiles feature.

[pz9115]

GCC 14 was released, now preparing patches to upstream.

[cmuellner]

@pz9115, when do you expect to rebase and resend the GCC patches?

[pz9115]

@pz9115, when do you expect to rebase and resend the GCC patches?

Yes, will resent it within this week.

Include a RVA23 & RVB23 RFC patch

[jjscheel]

Thanks, @pz9115. Please post a link here with the RFC for RVA23 and RVB23. We need that to Freeze for the new profile.

[cmuellner]

The RVI20/RVA20 support patch was resent a few hours ago: https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658082.html

[pz9115]

Update RVA/B23 patch in https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658502.html @jjscheel

[pz9115]

Update Binutils support in https://sourceware.org/pipermail/binutils/2024-August/136129.html

[cmuellner]

@pz9115, thanks for working on this! Your patches unblocked the Zimop/Zcmop situation, and this extension is now finally supported in Binutils:

• https://sourceware.org/git?p=binutils-gdb.git;a=commit;h=3ba06284d2cada7a4798f7849da113661aff07dd
• https://sourceware.org/git?p=binutils-gdb.git;a=commit;h=8a3ffa71945816b941d3dea9ebc7013d5be7a1a4

So, we have patches for almost everything on the lists (I think I have not seen an RFC patch for RVA23/RVB23, but that's not a big deal).

The overall strategy is now:

1. get Zimop/Zcmop into Binutils
2. get RVA20/RVA22 into Binutils
3. get Zimop/Zcmop into GCC
4. get RVA20/RVA22 into GCC
5. have RFC patches for RVA23/RVB23 for Binutils and GCC on the lists
6. wait for RVA23/RVB23 ratification
7. rebase and retest RVA23/RVB23 patches and resend them
8. get RVA23/RVB23 into Binutils
9. get RVA23/RVB23 into GCC

[pz9115]

The Zimop/Zcmop had merged into both gcc and binutils upstream——
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c8f3fdd53871a20838be532b58ef610bf1dd75e1

https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=3ba06284d2cada7a4798f7849da113661aff07dd

And update the gcc Profiles patch support——
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660838.html

[pz9115]

Received comment form Palmer and Nelson, preparing a new version patch.

https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660947.html
https://sourceware.org/pipermail/binutils/2024-September/136589.html

[cmuellner]

We discussed profile support in GCC in the RISC-V BoF session at the GNU Cauldron 2024 in Prague three days ago, and we (Jeff Law, Kito, Palmer, and Jiawei were among the attendees) reached the consensus that we will add GCC support for ratified profiles.

There are concerns that CPU/SoC vendors will claim profile compliance when, in fact, they are not (independent of whether this happens intentionally or not). It could be as little as a tiny bug that makes a CPU/SoC incompatible with a profile it is marketing for. This could (or likely will) lead to bug reports where users blame SW implementations as being erroneous because they won't run on their device (which claims to be profile compatible). However, there is little we can do on the SW side besides closing such tickets as invalid and hoping that volunteers (in the best case, the CPU/SoC vendors themselves) engage with the upstream community to solve the problem.

We all agreed that we would like stricter compliance tests for vendors to increase the confidence level of the claims to be compatible with RVI extensions or profiles.