-
Notifications
You must be signed in to change notification settings - Fork 11.9k
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
[WebAssembly] avoid to enable explicit disabled feature #80094
[WebAssembly] avoid to enable explicit disabled feature #80094
Conversation
In `CoalesceFeaturesAndStripAtomics`, feature string is converted to FeatureBitset and back to feature string. It will lose information about explicit diasbled features.
@llvm/pr-subscribers-backend-webassembly Author: Congcong Cai (HerrCai0907) ChangesIn Full diff: https://github.com/llvm/llvm-project/pull/80094.diff 2 Files Affected:
diff --git a/llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp b/llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp
index 2db1b6493cc47..0aadc6aca228d 100644
--- a/llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp
+++ b/llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp
@@ -200,7 +200,8 @@ class CoalesceFeaturesAndStripAtomics final : public ModulePass {
bool runOnModule(Module &M) override {
FeatureBitset Features = coalesceFeatures(M);
- std::string FeatureStr = getFeatureString(Features);
+ std::string FeatureStr =
+ getFeatureString(Features, WasmTM->getTargetFeatureString());
WasmTM->setTargetFeatureString(FeatureStr);
for (auto &F : M)
replaceFeatures(F, FeatureStr);
@@ -238,12 +239,17 @@ class CoalesceFeaturesAndStripAtomics final : public ModulePass {
return Features;
}
- std::string getFeatureString(const FeatureBitset &Features) {
+ static std::string getFeatureString(const FeatureBitset &Features,
+ StringRef TargetFS) {
std::string Ret;
for (const SubtargetFeatureKV &KV : WebAssemblyFeatureKV) {
if (Features[KV.Value])
Ret += (StringRef("+") + KV.Key + ",").str();
}
+ SubtargetFeatures TF{TargetFS};
+ for (std::string const &F : TF.getFeatures())
+ if (!SubtargetFeatures::isEnabled(F))
+ Ret += F;
return Ret;
}
diff --git a/llvm/test/CodeGen/WebAssembly/disable-feature.ll b/llvm/test/CodeGen/WebAssembly/disable-feature.ll
new file mode 100644
index 0000000000000..a9b07e2aaed5d
--- /dev/null
+++ b/llvm/test/CodeGen/WebAssembly/disable-feature.ll
@@ -0,0 +1,22 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc < %s -mattr=-sign-ext | FileCheck %s
+
+target triple = "wasm32-unknown-unknown"
+
+define i8 @ashr(i8 %v, i8 %x) {
+; CHECK-LABEL: ashr:
+; CHECK: .functype ashr (i32, i32) -> (i32)
+; CHECK-NEXT: # %bb.0:
+; CHECK-NEXT: local.get 0
+; CHECK-NEXT: i32.const 24
+; CHECK-NEXT: i32.shl
+; CHECK-NEXT: i32.const 24
+; CHECK-NEXT: i32.shr_s
+; CHECK-NEXT: local.get 1
+; CHECK-NEXT: i32.const 255
+; CHECK-NEXT: i32.and
+; CHECK-NEXT: i32.shr_s
+; CHECK-NEXT: # fallthrough-return
+ %a = ashr i8 %v, %x
+ ret i8 %a
+}
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What should happen if a feature is explicitly disabled via globally, but enabled on one of the functions in the module? IIUC, this current patch will have the string to enable it followed by the string to disable it. Which one wins? I think it would be good to have the feature enabled in that case.
How could this case happen? If explicitly disabling a feature, it should not be enabled on function. |
I think it should throw diagnose or assert it won't happen. Otherwise the user will find they disable some feature but code still has this feature. |
I have do some testing, for
If I use Which means it is impossible to have conflict between functions' feature and global feature. Related code is in |
05f9f3d
to
3edcb02
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, thanks!
This fixes a problem introduced in llvm#80094. That PR copied negative features from the TargetMachine to the end of the feature string. This is not correct, because even if we have a baseline TM of say `-simd128`, but a function with `+simd128`, the coalesced feature string must have `+simd128`, not `-sidm128`. To address the original motivation of that PR, we should instead explicitly materialize the negative features in the target feature string, so that explicitly disabled default features are honored. Unfortunately, there doesn't seem to be any way to actually test this using llc, because `-mattr` appends the specified features to the end of the `"target-features"` attribute. I've tested this locally by making it prepend the features instead.
This fixes a problem introduced in #80094. That PR copied negative features from the TargetMachine to the end of the feature string. This is not correct, because even if we have a baseline TM of say `-simd128`, but a function with `+simd128`, the coalesced feature string should have `+simd128`, not `-simd128`. To address the original motivation of that PR, we should instead explicitly materialize the negative features in the target feature string, so that explicitly disabled default features are honored. Unfortunately, there doesn't seem to be any way to actually test this using llc, because `-mattr` appends the specified features to the end of the `"target-features"` attribute. I've tested this locally by making it prepend the features instead.
This fixes a problem introduced in llvm#80094. That PR copied negative features from the TargetMachine to the end of the feature string. This is not correct, because even if we have a baseline TM of say `-simd128`, but a function with `+simd128`, the coalesced feature string should have `+simd128`, not `-simd128`. To address the original motivation of that PR, we should instead explicitly materialize the negative features in the target feature string, so that explicitly disabled default features are honored. Unfortunately, there doesn't seem to be any way to actually test this using llc, because `-mattr` appends the specified features to the end of the `"target-features"` attribute. I've tested this locally by making it prepend the features instead. (cherry picked from commit 5a7b79c)
This fixes a problem introduced in llvm#80094. That PR copied negative features from the TargetMachine to the end of the feature string. This is not correct, because even if we have a baseline TM of say `-simd128`, but a function with `+simd128`, the coalesced feature string should have `+simd128`, not `-simd128`. To address the original motivation of that PR, we should instead explicitly materialize the negative features in the target feature string, so that explicitly disabled default features are honored. Unfortunately, there doesn't seem to be any way to actually test this using llc, because `-mattr` appends the specified features to the end of the `"target-features"` attribute. I've tested this locally by making it prepend the features instead.
This fixes a problem introduced in llvm#80094. That PR copied negative features from the TargetMachine to the end of the feature string. This is not correct, because even if we have a baseline TM of say `-simd128`, but a function with `+simd128`, the coalesced feature string should have `+simd128`, not `-simd128`. To address the original motivation of that PR, we should instead explicitly materialize the negative features in the target feature string, so that explicitly disabled default features are honored. Unfortunately, there doesn't seem to be any way to actually test this using llc, because `-mattr` appends the specified features to the end of the `"target-features"` attribute. I've tested this locally by making it prepend the features instead.
This fixes a problem introduced in llvm#80094. That PR copied negative features from the TargetMachine to the end of the feature string. This is not correct, because even if we have a baseline TM of say `-simd128`, but a function with `+simd128`, the coalesced feature string should have `+simd128`, not `-simd128`. To address the original motivation of that PR, we should instead explicitly materialize the negative features in the target feature string, so that explicitly disabled default features are honored. Unfortunately, there doesn't seem to be any way to actually test this using llc, because `-mattr` appends the specified features to the end of the `"target-features"` attribute. I've tested this locally by making it prepend the features instead.
This fixes a problem introduced in llvm#80094. That PR copied negative features from the TargetMachine to the end of the feature string. This is not correct, because even if we have a baseline TM of say `-simd128`, but a function with `+simd128`, the coalesced feature string should have `+simd128`, not `-simd128`. To address the original motivation of that PR, we should instead explicitly materialize the negative features in the target feature string, so that explicitly disabled default features are honored. Unfortunately, there doesn't seem to be any way to actually test this using llc, because `-mattr` appends the specified features to the end of the `"target-features"` attribute. I've tested this locally by making it prepend the features instead. (cherry picked from commit 5a7b79c)
This fixes a problem introduced in llvm#80094. That PR copied negative features from the TargetMachine to the end of the feature string. This is not correct, because even if we have a baseline TM of say `-simd128`, but a function with `+simd128`, the coalesced feature string should have `+simd128`, not `-simd128`. To address the original motivation of that PR, we should instead explicitly materialize the negative features in the target feature string, so that explicitly disabled default features are honored. Unfortunately, there doesn't seem to be any way to actually test this using llc, because `-mattr` appends the specified features to the end of the `"target-features"` attribute. I've tested this locally by making it prepend the features instead. (cherry picked from commit 5a7b79c)
In
CoalesceFeaturesAndStripAtomics
, feature string is converted to FeatureBitset and back to feature string. It will lose information about explicit diasbled features.