The proposal of '.option arch' directive is https://github.com/riscv-non-isa/riscv-asm-manual/pull/67
Note: For '.option arch, +/-' directive, version number is not yet supported.
Differential D123515
[RISCV] Support '.option arch' directive StephenFan on Apr 11 2022, 7:53 AM. Authored by
Details The proposal of '.option arch' directive is https://github.com/riscv-non-isa/riscv-asm-manual/pull/67 Note: For '.option arch, +/-' directive, version number is not yet supported.
Diff Detail
Unit Tests Event TimelineComment Actions Thanks for the patch! One quick suggestion from a rapid scan is that it would be good to have test coverage for illegal extension combinations (including for .option arch removing an extension that is a dependency of another enaabled extension). Comment Actions
Comment Actions You now accept .option arch, rv32ic (without the quotes) but that's not covered in the valid tests. The test coverage could be extended a bit to cover e.g.:
Comment Actions This patch is needed for zbb support as per: https://lore.kernel.org/all/20230117122447.y6tdsmsxqdwf76ri@orel/ Comment Actions For Zbb support *in the Linux kernel for its hand-written assembly routines*. Zbb works in Clang/LLVM today, and you can get it with -march=...zbb..., whether for compiler-generated code or hand-written assembly. Comment Actions Overall LGTM. Only some minor points left to address.
Comment Actions First and foremost, thank you for keeping this up to date and iterating upon it while the .option arch proposal was under review in the asm manual. I think we're basically almost there. I've left a few inline comments (and +1 on Luis' suggestion to cover the case where you e.g. +d then -d, and +f should remain enabled.) What is your intended behaviour for experimental extensions? It looks like they would be accepted with a fullarch string including the full version, but it seems are rejected for for +foo/-foo (when invoking llvm-mc directly at least). I think that is fine, as we don't really seek to make experimental extensions fully first class citizens. But it seems as though this implementation rejects version numbers in for +foo and -foo while the spec accepts a version such as 2p1 or 2. Accepting a version would give an easy way of supporting experimental extensions too. We should really have some test coverage for experimental extensions. I _think_ we've probably resolved our discussions on versioning and extensions enough that we shouldn't have too much uncertainty on how this is handled. But once the review comments are addressed, I'd be open to landing this without the version parsing support if you don't have time to look at that - if so, I'd suggest changing the error from "Don't specify version number, extensions don't rely on version numbers" to "Extension version number parsing not currently implemented" or similar.
Comment Actions Adding a test showing that using .option arch in inline assembly doesn't affect ELF attributes nor set the EF_RISCV_RVC ELF flag would be nice. The latter can also be tested for assembly files. Comment Actions Thanks for all of the improvements so far. Two additional problems I noticed:
Comment Actions svnapot can be parsed from arch string. I think we need an API in RISCVISAInfo to decide that some extensions are non-extension features, only rejecting in the logic of parse .option arch directive seems tricky. Comment Actions There's nothing wrong with .option arch, +svnapot; it's an extension, so it's valid to put in the arch string, it's just a bit pointless as it doesn't actually do anything to the toolchain.
Comment Actions Looks like some users are looking forward to this patch, would you mind accepting it first and then addressing your comments separately @craig.topper ? Comment Actions Issues need fixing before it lands, making exceptions sets a bad precedent
Comment Actions @jrtc27 are there any remaining issues you'd like to see addressed in the first commit. Android developers are really anxious to get this in to enable V extension support in the kernel. Comment Actions I still really don't like the target streamer interface... using a bool for +/- would at least help, but IMO this should surely be something like an emitOptionArch that takes a list of string-enum pairs, where the enum is something like Full/Plus/Minus. It's the PrefixEmitted that feels particularly egregious.
Comment Actions Am I right in thinking we're at the point now where we're discussing slightly cleaner implementation approaches but are happy the functionality is correct and faithful to the specification? I think a careful review of the functionality is warranted as we have been bitten before by subtle issues in this kind of thing slipping in and causing problems far down the road. But this is also a blocker for parity with GCC on Linux kernel builds in particular and the patch author has gone through a lot of rounds of feedback already, so I'd be quite keen to land this and follow-up with refactoring patches, if my understanding of the situation is correct. Comment Actions Looks like reducing the Streamer interface from 3 down to 1 would require refactoring the code to collect the information before sending it to the streamer. I suggest this be moved to a future patch for expediency of getting this landed since the code has already been reviewed. As long as we're the only target using it, it doesn't seem hard to change. I'm willing to help @StephenFan improve this post-commit. Comment Actions Thank you all! Considering Android developers are really anxious to get this, I will land it tonight if there are no strong objections.
|
Two nits:
"that expanded" -> "that is expanded"?
Missing period.