This is an archive of the discontinued LLVM Phabricator instance.

[RISCV][NFC] Package version number information using RISCVExtensionVersion.
AbandonedPublic

Authored by ym1813382441 on Feb 23 2023, 8:33 PM.

Details

Summary

This helps to support multiple version number extensions later.

Diff Detail

Event Timeline

ym1813382441 created this revision.Feb 23 2023, 8:33 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 23 2023, 8:33 PM
ym1813382441 requested review of this revision.Feb 23 2023, 8:33 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptFeb 23 2023, 8:33 PM

Thank you for the patch. May you explain how this would help support multi-versioning?

llvm/include/llvm/Support/RISCVISAInfo.h
24

Does the structure already work as-is?

llvm/lib/Support/RISCVISAInfo.cpp
190

Maybe handling this with a compiler error is better than an assertion error.

I want to use arrays to maintain the supported version number of each extension, this patch in using the find algorithm helps to simplify the code.

llvm/include/llvm/Support/RISCVISAInfo.h
24

I've tested it and it works.

llvm/lib/Support/RISCVISAInfo.cpp
190

Currently the compiler does not allow the same extension to appear more than once.
If it happens something has gone wrong.

craig.topper added a comment.EditedFeb 23 2023, 11:27 PM

Can you outline your full plan and why you want to do this. We need to see the bigger picture.

ym1813382441 marked 2 inline comments as done.Feb 23 2023, 11:55 PM

Can you outline your full plan and why you want to do this. We need to see the bigger picture.

I'm implementing this idea

I meant what extensions are you planning to support multiple versions for and why? How will this work in the assembler, code generator, and disassembler which use SubtargetFeatures not RISCVISAInfo.

I meant what extensions are you planning to support multiple versions for and why? How will this work in the assembler, code generator, and disassembler which use SubtargetFeatures not RISCVISAInfo.

My intention is to support RVV0.71, since specific cpu's exist for the XuanTie C900 series. In LLVM use Feature to distinguish between different versions of extensions. I am considering how to solve this problem, using multiple .td files in the worst case.

My intention is to support RVV0.71, since specific cpu's exist for the XuanTie C900 series. In LLVM use Feature to distinguish between different versions of extensions. I am considering how to solve this problem, using multiple .td files in the worst case.

@ym1813382441
Thanks for your works and we really appreciate it. :-)
Similar proposal has been rejected by the community (please refer to D115921 for previous discussion) and I don't know if others have changed their minds.

How much of the existing vector code in the backend including tablegen can be reused for 0.71? How much of the intrinsic interface can be used? If we’re talking about completely duplicating everything it is very unlikely we can accept it. RISCVGenDAGISel.inc, for example, is already significantly larger than any other target in tree. I don’t know how big it can get before it becomes an issue.

How many people are going to maintain this other version?

asb added a comment.Feb 24 2023, 1:36 AM

@ym1813382441 thanks for the contribution. In many cases, this kind of incremental and tightly focused patch is a good way to start things. But in this case, there's a few bigger issues.

  • As has been pointed out, the discussion about supporting multiple ISA versions has been started before. The barrier isn't the code change required, but more about agreeing we actually want/need to support multiple extension versions simultaneously (RISC-V International seem to have indicated they'd add new named extensions rather than add instructions to an existing extension in the future), and perhaps the biggest blocker has been around the handling of build attributes, what is accepted / produces an error / produces a warning by what tool and so on. We've been discussing this in the recent RISC-V LLVM sync-up calls and a few people who've been thinking about these issues for a while are hoping to come up with a proposal in the coming weeks.
  • If the ultimate intention is to support V0.7, then as Craig suggests that's a much bigger discussion. We really need to understand what the level of changes would be required, how this would impact in-tree code for V1.0, what the burden might be going forwards and so on. Not all points are relevant, but I've often thought that the considerations for Contributing Extensions to Clang provide a good starting point. e.g.
    • Evidence of a significant user community
    • A specific need to reside within the upstream tree
    • A long term support plan
    • A high quality implementation
    • Testing

How much of the existing vector code in the backend including tablegen can be reused for 0.71? How much of the intrinsic interface can be used? If we’re talking about completely duplicating everything it is very unlikely we can accept it. RISCVGenDAGISel.inc, for example, is already significantly larger than any other target in tree. I don’t know how big it can get before it becomes an issue.

How many people are going to maintain this other version?

I will not submit RVV0.71 to the community, I just want to extend the interface to support multiple versions, this will help to solve the compatibility issue of different versions of the extension, this issue is common.

How much of the existing vector code in the backend including tablegen can be reused for 0.71? How much of the intrinsic interface can be used? If we’re talking about completely duplicating everything it is very unlikely we can accept it. RISCVGenDAGISel.inc, for example, is already significantly larger than any other target in tree. I don’t know how big it can get before it becomes an issue.

How many people are going to maintain this other version?

Just FYI. We have tried our best to reuse code for RVV 1.0 and there are about 500 lines for C intrinsics, 80 lines for LLVM intrinsics, 1200 lines for pseudos and patterns and 1500 lines for custom ISel. The pseudos/patterns/ISel parts can be less since we have duplicated some code and the impact on RISCVGenDAGISel.inc is hard to estimate because we have some custom extensions. And for MC layer, the code are completely duplicated since a lot of instructions have different encodings.

eopXD added inline comments.Feb 26 2023, 5:35 AM
llvm/include/llvm/Support/RISCVISAInfo.h
24

I mean, without your modification to the structure, the original structure already works. So I don't see how refactoring here can help you more on supporting multiple versions of the same extension.

llvm/lib/Support/RISCVISAInfo.cpp
190

Yes. So we need to have an error instead of an assertion error to do this.

ym1813382441 added inline comments.Feb 26 2023, 6:18 PM
llvm/include/llvm/Support/RISCVISAInfo.h
24

I just move RISCVExtensionVersion structure here, and remove RISCVExtensionInfo structure.
I think that RISCVExtensionInfo is redundant.

llvm/lib/Support/RISCVISAInfo.cpp
190

Are you expecting an error message from the compiler?

ym1813382441 abandoned this revision.Feb 26 2023, 8:01 PM

RISC-V International seem to have indicated they'd add new named extensions rather than add instructions to an existing extension in the future.
Related discussions at D115921