Skip to content

Conversation

@yetingk
Copy link
Contributor

@yetingk yetingk commented Apr 23, 2024

Previously .option arch denied extenions are not belongs to RISC-V features. But experimental features have experimental- prefix, so .option arch can not serve for experimental extension.
This patch uses the features of extensions to identify extension existance.

Previously .option arch denied extenions are not belongs to RISC-V features. But
experimental features have experimental- prefix, so .option arch can not
serve for experimental extension.
This patch uses the features of extensions to identify extension
existance.
@yetingk yetingk requested review from asb, jrtc27 and topperc April 23, 2024 09:33
@llvmbot llvmbot added backend:RISC-V llvm:mc Machine (object) code labels Apr 23, 2024
@llvmbot
Copy link
Member

llvmbot commented Apr 23, 2024

@llvm/pr-subscribers-clang-driver
@llvm/pr-subscribers-clang
@llvm/pr-subscribers-backend-risc-v

@llvm/pr-subscribers-mc

Author: Yeting Kuo (yetingk)

Changes

Previously .option arch denied extenions are not belongs to RISC-V features. But experimental features have experimental- prefix, so .option arch can not serve for experimental extension.
This patch uses the features of extensions to identify extension existance.


Full diff: https://github.com/llvm/llvm-project/pull/89727.diff

2 Files Affected:

  • (modified) llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp (+4-3)
  • (modified) llvm/test/MC/RISCV/option-arch.s (+8-1)
diff --git a/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp b/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
index 3f4a73ad89bf8a..80ff70f1095f4c 100644
--- a/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
+++ b/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
@@ -2824,8 +2824,9 @@ bool RISCVAsmParser::parseDirectiveOption() {
         break;
       }
 
-      auto Ext = llvm::lower_bound(RISCVFeatureKV, Arch);
-      if (Ext == std::end(RISCVFeatureKV) || StringRef(Ext->Key) != Arch ||
+      std::string &&Feature = RISCVISAInfo::getTargetFeatureForExtension(Arch);
+      auto Ext = llvm::lower_bound(RISCVFeatureKV, Feature);
+      if (Ext == std::end(RISCVFeatureKV) || StringRef(Ext->Key) != Feature ||
           !RISCVISAInfo::isSupportedExtension(Arch)) {
         if (isDigit(Arch.back()))
           return Error(
@@ -2834,7 +2835,7 @@ bool RISCVAsmParser::parseDirectiveOption() {
         return Error(Loc, "unknown extension feature");
       }
 
-      Args.emplace_back(Type, Ext->Key);
+      Args.emplace_back(Type, Arch.str());
 
       if (Type == RISCVOptionArchArgType::Plus) {
         FeatureBitset OldFeatureBits = STI->getFeatureBits();
diff --git a/llvm/test/MC/RISCV/option-arch.s b/llvm/test/MC/RISCV/option-arch.s
index 6ee133c7159a27..40675f9e4b434b 100644
--- a/llvm/test/MC/RISCV/option-arch.s
+++ b/llvm/test/MC/RISCV/option-arch.s
@@ -1,7 +1,7 @@
 # RUN: llvm-mc -triple riscv32 -show-encoding < %s \
 # RUN:   | FileCheck -check-prefixes=CHECK %s
 # RUN: llvm-mc -triple riscv32 -filetype=obj < %s \
-# RUN:   | llvm-objdump  --triple=riscv32 --mattr=+c,+m,+a,+f,+zba -d -M no-aliases - \
+# RUN:   | llvm-objdump  --triple=riscv32 --mattr=+c,+m,+a,+f,+zba,+experimental-zicfiss -d -M no-aliases - \
 # RUN:   | FileCheck -check-prefixes=CHECK-INST %s
 
 # Test '.option arch, +' and '.option arch, -' directive
@@ -78,6 +78,13 @@ lr.w t0, (t1)
 # CHECK: encoding: [0xb3,0x22,0x73,0x20]
 sh1add t0, t1, t2
 
+# Test experimental extension
+# CHECK: .option arch, +zicfiss
+.option arch, +zicfiss
+# CHECK-INST: sspopchk ra
+# CHECK: encoding: [0x73,0xc0,0xc0,0xcd]
+sspopchk ra
+
 # Test '.option arch, <arch-string>' directive
 # CHECK: .option arch, rv32i2p1_m2p0_a2p1_c2p0
 .option arch, rv32i2p1_m2p0_a2p1_c2p0

@jrtc27
Copy link
Collaborator

jrtc27 commented Apr 23, 2024

I’m concerned about testing this; experimental extensions are, by policy, transient in LLVM, eventually either being promoted to non-experimental or being dropped, which means churn in this test every time the chosen extension is no longer present and experimental. What are your thoughts there?

@jrtc27
Copy link
Collaborator

jrtc27 commented Apr 23, 2024

Also, does this obey -menable-experimental-extensions?

@yetingk
Copy link
Contributor Author

yetingk commented Apr 23, 2024

Also, does this obey -menable-experimental-extensions?

IMO, I prefer this feature depends on -menable-experimental-extensions, since I think the option is to make user aware of experimental extensions.

@yetingk yetingk requested a review from kito-cheng April 23, 2024 13:05
@jrtc27
Copy link
Collaborator

jrtc27 commented Apr 23, 2024

Also, does this obey -menable-experimental-extensions?

IMO, I prefer this feature depends on -menable-experimental-extensions.

Yes, I believe it should. My question is whether it currently does, especially given I don’t believe your current patch is testing it?

@yetingk
Copy link
Contributor Author

yetingk commented Apr 23, 2024

It currently doesn't obey -menable-experimental-extensions. I will give a fix and tests for this.

@llvmbot llvmbot added clang Clang issues not falling into any other category clang:driver 'clang' and 'clang++' user-facing binaries. Not 'clang-cl' labels Apr 24, 2024
static cl::opt<bool> AddBuildAttributes("riscv-add-build-attributes",
cl::init(false));
static cl::opt<bool>
DisableExperimentalExtension("riscv-disable-experimental-ext",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why disable instead of enable?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since only clang needs specific option to allows experimental extensions.


auto Ext = llvm::lower_bound(RISCVFeatureKV, Arch);
if (Ext == std::end(RISCVFeatureKV) || StringRef(Ext->Key) != Arch ||
std::string &&Feature = RISCVISAInfo::getTargetFeatureForExtension(Arch);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why an rvalue reference?

Copy link
Contributor Author

@yetingk yetingk Apr 24, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it might less call a string constructor() and just use the return string value. But acutally I am not really sure how does rvalue reference work.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you should just use std::string Feature. I think std::string &&Feature will just make a reference to a hidden temporary object.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@topperc
Copy link
Collaborator

topperc commented Apr 25, 2024

Does this disable use of experimental extensions for a .option arch in an inline assembly block without -menable-experimental-extensions.

@yetingk
Copy link
Contributor Author

yetingk commented Apr 25, 2024

Does this disable use of experimental extensions for a .option arch in an inline assembly block without -menable-experimental-extensions.

No. my patch could not block the case. I will try to think this problem after my sleep.

@yetingk
Copy link
Contributor Author

yetingk commented Apr 26, 2024

I fix the issue by using feature to control the permission of experimental extension.

Does this disable use of experimental extensions for a .option arch in an inline assembly block without -menable-experimental-extensions.

Copy link
Collaborator

@topperc topperc Apr 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We also check OPT_menable_experimental_extensions in getArchFeatures and push a different feature when it is set. Do we need 2 extensions that are the opposite of each other?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed. Only use +experimental feature.


static cl::opt<bool> AddBuildAttributes("riscv-add-build-attributes",
cl::init(false));

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unrelated change?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

return Error(Loc, "Unexpected experimental extensions.");
auto Ext = llvm::lower_bound(RISCVFeatureKV, Feature);
if (Ext == std::end(RISCVFeatureKV) || StringRef(Ext->Key) != Feature ||
!RISCVISAInfo::isSupportedExtension(Arch)) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we still need the RISCVISAInfo::isSupportedExtension(Arch) check here? Did RISCVISAInfo::getTargetFeatureForExtension already take care of it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. Thank you.

Copy link
Collaborator

@topperc topperc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@yetingk
Copy link
Contributor Author

yetingk commented May 5, 2024

@topperc Sorry, there was a quick fix after the approve. getTargetFeatureForExtension could approve the extension with version. It may be better to allow them, but I am not sure the error message could be enough readable if we use wrong version number and is the format of output needed version number?

@yetingk yetingk merged commit d70267f into llvm:main May 6, 2024
zmodem added a commit that referenced this pull request May 6, 2024
@zmodem
Copy link
Collaborator

zmodem commented May 6, 2024

6217abc should fix the test failures.

@pogo59
Copy link
Collaborator

pogo59 commented May 6, 2024

Driver tests are supposed to verify Driver behavior. That is, use -### and make sure the correct option is being passed down to the compiler. They should not be compiling anything.

@yetingk
Copy link
Contributor Author

yetingk commented May 7, 2024

@zmodem very thank you for the help.

@yetingk
Copy link
Contributor Author

yetingk commented May 7, 2024

@pogo59 Thank you for the advise. I will update the test cases.

yetingk pushed a commit to yetingk/llvm-project that referenced this pull request May 7, 2024
PR llvm#89727 added the two test cases to verify `.option arch` should only
work when having -menable-experimental-extensions. And the test idea could be
splitted to
1. When having menable-experimental-extensions, clang passes +experimental.
2. `.option arch` only enabled when +experimental enabled.
And we already had the two kind of test.
@@ -0,0 +1,7 @@
// RUN: %clang --target=riscv64 -menable-experimental-extensions -c -o /dev/null %s
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are these clang tests? This is entirely testing llvm/ code. Never mind the weirdness of putting them in Driver/, nor the fact that they’re missing a REQUIRES: riscv-registered-target given they use the backend, they don’t belong in clang/ at all surely?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. I am sorry that I didn't find out the obvious mistake. I am going to review my development process.

@@ -0,0 +1,7 @@
// RUN: %clang --target=riscv64 -menable-experimental-extensions -c -o /dev/null %s
// RUN: ! %clang --target=riscv64 -c -o /dev/null %s 2>&1 | FileCheck -check-prefixes=CHECK-ERR %s
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use not rather than !

Copy link
Contributor Author

@yetingk yetingk May 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the suggestion. I will fix this if #91324 could not remove the tests.

yetingk added a commit that referenced this pull request May 7, 2024
PR #89727 added the two test cases to verify `.option arch` should only
work when having -menable-experimental-extensions. And the test idea
could be splitted to
1. When having menable-experimental-extensions, clang passes
+experimental.
2. `.option arch` only enabled when +experimental enabled. 

And we already had the two kind of tests.
@MaskRay
Copy link
Member

MaskRay commented May 13, 2024

The clang/test/Driver codegen tests might have been removed. Note: clang/test/Driver is to test how clangDriver passes options to cc1, not for sema/codegen/etc.

@yetingk
Copy link
Contributor Author

yetingk commented May 14, 2024

The clang/test/Driver codegen tests might have been removed. Note: clang/test/Driver is to test how clangDriver passes options to cc1, not for sema/codegen/etc.

Thank you for the reminder.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backend:RISC-V clang:driver 'clang' and 'clang++' user-facing binaries. Not 'clang-cl' clang Clang issues not falling into any other category llvm:mc Machine (object) code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants