We recently noticed that GCC has merged some patches for the T-Head Vector extension (a variant of vector extension by T-Head groups, specification here), as seen here: [PATCH v5] RISC-V: Support XTheadVector extension. And we would like to ask if the LLVM upstream would like to see this extension supported officially, as GCC does.
We have been working on the LLVM implementation of it since July 2023. Our repo is ruyisdk/llvm-project, which has basic support for some vector operations like load/store and some arithmetic things (and there are progress summaries on the README, updated from time to time). And I successfully ran this test source compiled by the LLVM in our fork in my T-Head boards. Now we are working on more intrinsics of the T-Head Vector in both LLVM and Clang.
If the upstream is happy about this extension, we will start rebasing our work on top of the newest upstream and sending pull requests at the same time (the initial patch would be MC support I guess).
Thanks for starting this discussion. I think the key things I’d look at when evaluating a non-standard extension are:
Is there a user community for it
Is there a clear specification we can use to evaluate the implementation against
Is the proposed implementation of a high quality
Will the author support the code long term, participate in code reviews etc
How large / invasive is the implementation. i.e. what impact will it have on the rest of the RISC-V backend
The last one is the big question mark for me. We’ve often assumed that supporting the older vector spec could be quite a large burden, though @kito-cheng indicates it turned out not to be huge for GCC. Could you say a bit about how that works out in your LLVM implementation?
Thanks for working on this. I was hoping that LLVM might also eventually get support for this now that it’s being added to GCC.
There are quite a large number of RISC-V systems currently shipping with this implementation of the vector specification, including some workstation class like the 64-core MilkV Pioneer, and still comparatively few that implement the actual RVV 1.0 spec.
I’m at least one user (with a Pioneer system) that would very much like to see this available for LLVM.
Thanks @silvanshade. I perhaps should have been clearer with my post - I was trying to list the general framework I think is appropriate for considering extensions rather than indicating all those things are unanswered questions in my mind. As you suggest in your answer, I think bulletpoints 1 and 2 are quite clear - it’s the last three bulletpoints that really need more careful evaluation and some input from the patch author(s).
On this point specifically, no, having support for other vendor extensions - even those from the same vendor - is not a particularly powerful argument in favor of accepting a new one.
In general, the concern with t-head vector is the implementation complexity, ongoing development, and testing. I’ve talked a few folks offline who indicate that the t-head implementation subseted the original 0.7 spec in a bunch of ways which make it more manageable, but we need to see an actual proposal from an interested contributor which addresses this point.
One other point worth highlighting. We’ve got a spectrum of choices available for what “supporting” t-head vector can mean.
We could chose to add assembly/disassembly support, and nothing else. We have existing precedent for this with a few other extensions already. This to me seems the easiest to justify.
We could support intrinsics. We could support generic code generation. The way the RISCV is currently structured, these are largely independent (and slightly duplicating) sets of work. The second is required for auto-vectorization, the former enables hand written intrinsic code.
Looking at the linked repo from OP, I see work for the assembly/disassembly piece, and some of the required changes for intrinsics. I don’t see the generic codegen/autovec parts at first glance.
From the point of the end-user, I don’t think it’s unreasonable to expect that if there is relatively extensive support for a set of extensions for a given architecture that the intention should be to provide the most complete support possible, assuming there aren’t serious technical obstacles preventing that.
From the point of view of the maintainer, of course there are all sorts of additional factors to consider, which you point out, and which I basically agree with.
I think the GCC implementation has already demonstrated the general feasibility of supporting this extension alongside existing RVV implementations. But yes, a concrete proposal is needed for this to be realizable in any case.
It seems to me that the most realistic approach would be to implement these different levels of support in stages rather than necessarily thinking or hoping that they would all happen at once.
Right, the linked PR only includes modifications for the assembly / machine-code part of the picture. So there would still be quite a lot of additional work necessary to reach the other levels of support.
Just to keep everything cross-linked, there’s now a PR for MC layer support. I’ve asked we try to keep higher level discussion about supporting xtheadvector here so discussion doesn’t get spread out all over the place.
We did discuss in the last RISC-V LLVM sync-up call and one concern raised was that although at first look the MC layer support doesn’t seem overly complex, the amount of work needed for the intrinsics isn’t yet clear, and it would be helpful to understand if MC layer support is useful to those wishing to use this extension, or if it’s not much use until intrinsics are supported as well?
MC layer support could still be useful in principle at least for testing and potentially debugging purposes but I’m not sure it would really make sense to push for merging that in isolation without understanding how it will fit into further developments.