zixuan-wu added a comment. In D115921#3224329 <https://reviews.llvm.org/D115921#3224329>, @jrtc27 wrote:
> 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, for new extensions 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. If I don't understand wrong, all you want to say is that the extension version is just for indication, and not for functionality? So the RV spec does not require compiler to support multi-version. Anybody else has more comments about support multi-version extension? Or it has been decided already? 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
