jrtc27 added a comment. In D115921#3224324 <https://reviews.llvm.org/D115921#3224324>, @zixuan-wu wrote:
> In D115921#3224284 <https://reviews.llvm.org/D115921#3224284>, @jrtc27 wrote: > >> but also with RISC-V extensions not being changed once ratified any more >> (changes mean new extensions entirely, not new versions) > > I don't think so. Or why is there version in RISC-V spec? That was added years ago before there was any plan/policy for ratifying new extensions beyond the initial GC set. https://docs.google.com/presentation/d/1nQ5uFb39KA6gvUi5SReWfIQSiRN7hp6z7ZPfctE4mKk/edit#slide=id.p1 is the current lifecycle; note that //only// errata can be fixed after ratification, everything else requires a new extension (see the blue arrow and brown box below it). As far as I can tell it serves no purpose other than to distinguish draft specs from ratified ones. > And not only for standard extension, but also it's needed in custom extension. Vendor extensions are going to be enough of a support pain in Clang. I sincerely hope they don't make life worse by defining multiple versions, rather than doing it properly and defining new extensions every time they add things. It's not just for the toolchain's benefit; it also improves forwards compatibility for kernels/loaders, as they won't know about new versions, but may know about existing versions, so if they support "Xvendorbase" then software that wants to take advantage of "Xvendorbase" and "Xvendornew" can still use "Xvendorbase", but if the kernel/loader only supports "Xvendor1p0" and software wants to use "Xvendor2p0" then it can't do anything, it'd need to be more careful and also have an "Xvendor1p0" implementation. Extending rather than redefining comes with real benefits. > BTW, it's been supported to parse version of -march in clang side. It parses and checks the version, but it only allows //the// version of the extension Clang currently implements. Parsing the version is a hard requirement since it can be part of a valid arch string. Supporting multiple versions is not. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D115921/new/ https://reviews.llvm.org/D115921 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
