Skip to content

[RISCV] Teach .option arch to support experimental extensions. #89727

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 6 commits into from
May 6, 2024

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 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
@@ -51,6 +51,9 @@ STATISTIC(RISCVNumInstrsCompressed,

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.

@@ -2824,8 +2827,12 @@ 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);
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.

@@ -169,6 +169,9 @@ void riscv::getRISCVTargetFeatures(const Driver &D, const llvm::Triple &Triple,
Features.push_back("-relax");
}

if (!Args.hasArg(options::OPT_menable_experimental_extensions))
Features.push_back("+no-experimental-ext");
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.

@@ -51,7 +51,6 @@ STATISTIC(RISCVNumInstrsCompressed,

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.

StringRef(Feature).starts_with("experimental-"))
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 mc Machine (object) code
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants