Originially there are two places that does parsing - parseArchString and
parseFeatures, each with its code on dependency check and implication.
This patch extracts common parts of the two as functions of RISCVISAInfo
and let them 2 use it.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
The test cases are modified because unifying the logic here shows the place where clang / llvm deal with target feature inconsistently.
I think it would be beneficial if we have them consistent.
- Test cases with clang -cc1 originally don't do dependency check to target feature specified
- This patch add target feature so that dependency checks can pass
Update:2021/10/31
This second part is canceled after Alex's comment below.
Originally clang driver's -march enforces version to be specified, while llvm allows .attribute arch to not specify version (and picks the default one)This patch lets clang search for default version if no version is specified (so delete NOVERS test case in clang/test/Driver/riscv-arch.c
Thank you for the patch. This doesn't apply cleanly to current HEAD, could you please rebase?
I think the second part of this that you list, where the ISA extension version becomes optional is undesirable. We made the explicit choice of requiring the version string to be specified for experimental extensions in order to make it even clearer up-front that these are subject to change (and to allow people to catch easily when the supported ISA version has changed in a compiler update).
Address comment: Enforce user to specify version checks.
@asb Thank you for leaving comments for this patch.
Set ExperimentalExtensionVersionCheck=true for RISCVISAInfo::parseArchString in RISCVAsmParser.cpp
Add version numbers for test case in attribute-arch.s
Add version numbers for test case in attribute-arch.s
Thanks for updating the patch. Why change this test case? I thought those lines were verifying that .attribute arch without a version number was accepted but the output file included a version number. I'll admit that's not fully consistent with requiring the version number explicitly on the command-line. If a behaviour change is desired here, it would be good to test the case where version numbers aren't specified.
I think for a patch like this, if it at all possible it would be best to do the refactoring in a way that doesn't alter behaviour and then follow-up with separate patches that change any other behaviour (if desired). Then we can review and discuss the refactoring and any functional changes separately, without one discussion blocking the other.
@asb Thanks for the reply.
To clarify the question, the 2 inconsistencies are:
- Test cases with clang -cc1 originally don't do dependency check to target feature specified (handled by parseFeatures)
- Clang driver's -march (handled by parseArchString) enforces version to be specified, while llvm allows .attribute arch to not specify version and picks the default one (handled by parseFeatures)
What this patch tries to do, letting the 2 actions rely on the same function call will mean to alter the behavior on one of them.
In my humble opinion, it is rather awkward to make this patch an NFC while letting the 2 actions call the same function.
Maybe we can first come to a conclusion on how do we unify and then implement them in this patch.
The main intentions of unifying them is that there will be some implications and dependency checks on the addition of zve and zvl,
so unifying the logics will make the addition have less code duplication.
OK, that reasoning makes sense. I think my only outstanding request would be to ensure there's some test coverage for the case of .attribute arch with an experimental extension without version info.
- Update code (zfh have been added recently.
- Added test case attribute-arch-invalid.s to show that experimental extensions need to specify the version explicitly.