Add RISC-V Profiles format

[pz9115]

This is a subset work form #26.
Add RISC-V Profiles format only. The doc record in:
https://docs.google.com/document/d/1TZXRIgVfQHWQ6xrZflHXUCSav6xNmliojrW2bEsvPno/edit.

[asb]

I'm not sure this is the right place to be advocating for why profiles make sense.

Regarding "It's also easy to combine a profile with any extensions" - this patch should give an example of that.

[pz9115]

Fixed in new version, remove this descriptions, give an example behind.

[preames]

This got briefly brought up during the SIG toolchain meeting today, but got rapidly derailed into a process discussion. Since the root point seems important, I am repeating it here.

In addition to defining the syntax for the -march string for profiles, there is a separate set of task items required to define and implement support for each of the new extensions which were defined in the ratified profile document.

From the perspective of LLVM, my current intent is to make the support for all the various extensions a blocker for merging the -march profile parsing support. This may evolve, and I'm open to the arguments on why we should adopt a different posture, but that argument will need to be explicitly made.

[pz9115]

This got briefly brought up during the SIG toolchain meeting today, but got rapidly derailed into a process discussion. Since the root point seems important, I am repeating it here.

In addition to defining the syntax for the -march string for profiles, there is a separate set of task items required to define and implement support for each of the new extensions which were defined in the ratified profile document.

From the perspective of LLVM, my current intent is to make the support for all the various extensions a blocker for merging the -march profile parsing support. This may evolve, and I'm open to the arguments on why we should adopt a different posture, but that argument will need to be explicitly made.

You are right, Christoph added a comment here riscv-admin/dev-partners#16 (comment). In fact, we need to nothing until those new extensions are actually ratified(more details are needed in extenisons specification to approach). So I think maybe is a good idea that only implements the new extensions' names in toolchain Profiles support.

[topperc]

"it not use" -> "it does not use"

[pz9115]

Updated, thanks for your checking.

[TommyMurphyTM1234]

Isn't this incorrect due to the spaces around the '=' character?

-march = rv64imafdc_zicsr_ziccif_ziccrse_ziccamoa_zicclsm_za128rs_zba_zbb_zbc_zbs

[pz9115]

I think you are right, remove the incorrect spaces, thanks!

[TommyMurphyTM1234]

Incorrect placement of code (backtick) markup?

[pz9115]

I'm trying to emphasize here the rules for using, do you have any good solutions?

[pthariensflame]

Suggested change

	To distinguish between ordinary extension input and input with profiles,
	profiles are assumed to be entered `at the beginning of the -march option`, and
	then input other extensions. Profiles `should use uppercase letters` in the `-march`
	option.
	To distinguish between ordinary extension input and input with profiles,
	profiles are assumed to be entered `at the beginning of the -march option`, and
	then input other extensions. Profiles *should use uppercase letters* in the `-march`
	option.

[TommyMurphyTM1234]

Spaces around '=' character are incorrect?

[pz9115]

Removed, thank you!

[cmuellner]

The status of the profiles support was briefly discussed in today's SIG toolchain call:

• this was discussed at the GNU Cauldron with Kito and Palmer (I did not attend, therefore I can't say exactly what was discussed there)
• patches are expected to get on the list this month (October 2023)

[cmuellner]

An initial patch was sent to the GCC mailing list today: https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637490.html

[jrtc27]

Uppercase strings being required in things like -march is very unusual; I would be much more in favour of keeping things lowercase

[cmuellner]

The architecture review committee has sent out the following text about how profiles support in toolchains should look like:

In response to some recent discussion in the Apps and Tools HC about how profiles should be represented in GCC/LLVM, the ARC provides this answer: compilers should use a single parameter for an ISA string. An ISA string begins with either a base ISA name (e.g. rv64i) or a profile name (e.g. rva23u64) and is optionally followed by additional extensions (e.g. rv64imac_zicond or rva23u64_zfh_zicond). If the ISA string begins with a profile name, it is equivalent to replacing the profile name with its mandatory base ISA and its mandatory extensions; any optional extensions in a profile must be explicitly named if their inclusion is desired. ISAs are sets, and concatenating strings takes the union, so redundancy is legal (e.g. rva23u64, rva23u64_zicsr, and rva23u64_zicsr_zicsr are all valid and equivalent).

https://lists.riscv.org/g/tech-unprivileged/message/611

[wangpc-pp]

Draft LLVM implementation: llvm/llvm-project#76357.

[wangpc-pp]

Reverse ping. Is there any progress?

[cmuellner]

The GCC implementation is tracked here: riscv-admin/dev-partners#16.

There was a request to wait on the GCC patch regarding the adoption of profiles in toolchain components: https://gcc.gnu.org/pipermail/gcc-patches/2023-December/641025.html.

So, at this point, we have clear guidelines from RVI regarding the adoption. We have this PR, and we have patches for GCC and LLVM. This can all move forward if upstream maintainers are fine with it.

Given the relatively low impact on toolchains, I'm fine with waiting until the GCC 15 branch opens up.
LLVM might move on earlier.

[cmuellner]

LLVM support landed upstream a few days ago (see also llvm/llvm-project#76357).

[kepstin]

The text in this PR currently differs from the ARC decision mentioned in #36 (comment) and the implementation in LLVM in llvm/llvm-project#76357 in two significant ways:

• Profile names are specified in lowercase, not uppercase
• Additional extensions are specified with _ as the separator, not +

I worry that this inconsistency might cause compatibility issues.

[wangpc-pp]

@pz9115 Hi Jiawei, can you please update the RFC according to the comment?

The architecture review committee has sent out the following text about how profiles support in toolchains should look like:

In response to some recent discussion in the Apps and Tools HC about how profiles should be represented in GCC/LLVM, the ARC provides this answer: compilers should use a single parameter for an ISA string. An ISA string begins with either a base ISA name (e.g. rv64i) or a profile name (e.g. rva23u64) and is optionally followed by additional extensions (e.g. rv64imac_zicond or rva23u64_zfh_zicond). If the ISA string begins with a profile name, it is equivalent to replacing the profile name with its mandatory base ISA and its mandatory extensions; any optional extensions in a profile must be explicitly named if their inclusion is desired. ISAs are sets, and concatenating strings takes the union, so redundancy is legal (e.g. rva23u64, rva23u64_zicsr, and rva23u64_zicsr_zicsr are all valid and equivalent).

https://lists.riscv.org/g/tech-unprivileged/message/611

[pz9115]

@pz9115 Hi Jiawei, can you please update the RFC according to the comment?

The architecture review committee has sent out the following text about how profiles support in toolchains should look like:

In response to some recent discussion in the Apps and Tools HC about how profiles should be represented in GCC/LLVM, the ARC provides this answer: compilers should use a single parameter for an ISA string. An ISA string begins with either a base ISA name (e.g. rv64i) or a profile name (e.g. rva23u64) and is optionally followed by additional extensions (e.g. rv64imac_zicond or rva23u64_zfh_zicond). If the ISA string begins with a profile name, it is equivalent to replacing the profile name with its mandatory base ISA and its mandatory extensions; any optional extensions in a profile must be explicitly named if their inclusion is desired. ISAs are sets, and concatenating strings takes the union, so redundancy is legal (e.g. rva23u64, rva23u64_zicsr, and rva23u64_zicsr_zicsr are all valid and equivalent).

https://lists.riscv.org/g/tech-unprivileged/message/611

Hi PengCheng, I update the description in Profiles to sync with LLVM implement, please check it.

[pz9115]

The text in this PR currently differs from the ARC decision mentioned in #36 (comment) and the implementation in LLVM in llvm/llvm-project#76357 in two significant ways:

• Profile names are specified in lowercase, not uppercase
• Additional extensions are specified with _ as the separator, not +

I worry that this inconsistency might cause compatibility issues.

Sync the format with LLVM implement, using lowercase and _ in Profiles format.

[wangpc-pp]

The naming convention of profiles may not be like this any more if I read what the sig-profiles (https://lists.riscv.org/g/sig-profiles/message/83) is doing rightly. The proposed profile naming is here (I don't know if every one can read it): https://docs.google.com/document/d/19xXIMnk1MNRZIp9fnW0yzBvnRnqko0LJT0XUjUvDVZ4/
So, I think, here we can just say that profile-name will be a valid list of released profiles. As for the format, we should refer to the document of profiles.

[pz9115]

Ok，it sounds great, will update it in new version.

[wangpc-pp]

Then we don't need these eBNFs?

[pz9115]

Removed.

[topperc]

", the toolchain will check" should be the start of a new sentence.

[topperc]

This sentence is kind of awkward.

[topperc]

"Profiles name" -> "Profile names" if we are talking about a list of names of multiple profiles.

[topperc]

Aren't the profiles named rva23 and rvb23. There is no A or B after 23.

[topperc]

Missing "b"

[topperc]

"Profiles should input in the -march option." seems redundant with the previous sentece.

[topperc]

There is no rva22u32 profile. I think this should be rva22u64?

[pz9115]

Thanks for your comments, fixed in new commit.