This helps to support multiple version number extensions later.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Event Timeline
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. |
Can you outline your full plan and why you want to do this. We need to see the bigger picture.
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?
@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
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.
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.
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. |
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
Does the structure already work as-is?