-
Notifications
You must be signed in to change notification settings - Fork 14.3k
[nvptx] Fix autoupdater's intrinsic matcher #73330
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
Conversation
The nvptx autoupdater's intrinsic matcher has some suspicious-looking strings. These use '_' (underbar) as the separator, rather than '.' (dot) like all the others. The 'fma.rn.ftz_bf16' string particularly so, as it's paired with 'fma.rn.ftz.bf16x2'. These strings were like this from the original commit (250f2bb) in 2023-06-23 by [email protected]. AFAICT looking at the rest of that diff, there's nothing special about the 5 intrinsics affected, and the TD files do not seem to be making any effort to use '_' rather than '.' on them. There is no change in test coverage -- these intrinsics do not appear to be tested?
@llvm/pr-subscribers-llvm-ir Author: Nathan Sidwell (urnathan) ChangesThe nvptx autoupdater's intrinsic matcher has some suspicious-looking strings. These use '' (underbar) as the separator, rather than '.' (dot) like all the others. The 'fma.rn.ftz_bf16' string particularly so, as it's paired with 'fma.rn.ftz.bf16x2'. These strings were like this from the original commit (250f2bb) in 2023-06-23 by [email protected]. AFAICT looking at the rest of that diff, there's nothing special about the 5 intrinsics affected, and the TD files do not seem to be making any effort to use '' rather than '.' on them. There is no change in test coverage -- these intrinsics do not appear to be tested? Full diff: https://github.com/llvm/llvm-project/pull/73330.diff 1 Files Affected:
diff --git a/llvm/lib/IR/AutoUpgrade.cpp b/llvm/lib/IR/AutoUpgrade.cpp
index 63c4b2c71299900..6d55544c0af0dd5 100644
--- a/llvm/lib/IR/AutoUpgrade.cpp
+++ b/llvm/lib/IR/AutoUpgrade.cpp
@@ -635,12 +635,12 @@ static Intrinsic::ID ShouldUpgradeNVPTXBF16Intrinsic(StringRef Name) {
return StringSwitch<Intrinsic::ID>(Name)
.Case("bf16", Intrinsic::nvvm_fma_rn_bf16)
.Case("bf16x2", Intrinsic::nvvm_fma_rn_bf16x2)
- .Case("ftz_bf16", Intrinsic::nvvm_fma_rn_ftz_bf16)
+ .Case("ftz.bf16", Intrinsic::nvvm_fma_rn_ftz_bf16)
.Case("ftz.bf16x2", Intrinsic::nvvm_fma_rn_ftz_bf16x2)
.Case("ftz.relu.bf16", Intrinsic::nvvm_fma_rn_ftz_relu_bf16)
.Case("ftz.relu.bf16x2", Intrinsic::nvvm_fma_rn_ftz_relu_bf16x2)
- .Case("ftz_sat.bf16", Intrinsic::nvvm_fma_rn_ftz_sat_bf16)
- .Case("ftz_sat.bf16x2", Intrinsic::nvvm_fma_rn_ftz_sat_bf16x2)
+ .Case("ftz.sat.bf16", Intrinsic::nvvm_fma_rn_ftz_sat_bf16)
+ .Case("ftz.sat.bf16x2", Intrinsic::nvvm_fma_rn_ftz_sat_bf16x2)
.Case("relu.bf16", Intrinsic::nvvm_fma_rn_relu_bf16)
.Case("relu.bf16x2", Intrinsic::nvvm_fma_rn_relu_bf16x2)
.Case("sat.bf16", Intrinsic::nvvm_fma_rn_sat_bf16)
@@ -677,8 +677,8 @@ static Intrinsic::ID ShouldUpgradeNVPTXBF16Intrinsic(StringRef Name) {
.Case("bf16x2", Intrinsic::nvvm_fmin_bf16x2)
.Case("ftz.bf16", Intrinsic::nvvm_fmin_ftz_bf16)
.Case("ftz.bf16x2", Intrinsic::nvvm_fmin_ftz_bf16x2)
- .Case("ftz.nan_bf16", Intrinsic::nvvm_fmin_ftz_nan_bf16)
- .Case("ftz.nan_bf16x2", Intrinsic::nvvm_fmin_ftz_nan_bf16x2)
+ .Case("ftz.nan.bf16", Intrinsic::nvvm_fmin_ftz_nan_bf16)
+ .Case("ftz.nan.bf16x2", Intrinsic::nvvm_fmin_ftz_nan_bf16x2)
.Case("ftz.nan.xorsign.abs.bf16",
Intrinsic::nvvm_fmin_ftz_nan_xorsign_abs_bf16)
.Case("ftz.nan.xorsign.abs.bf16x2",
|
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.
LGTM. I guess that means that this is effectively dead code, but it's probably safer to just keep it.
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.
LGTM
The nvptx autoupdater's intrinsic matcher has some suspicious-looking strings. These use
_
(underbar) as the separator, rather than '.' (dot) like all the others. The 'fma.rn.ftz_bf16' string particularly so, as it's paired with 'fma.rn.ftz.bf16x2'. These strings were like this from the original commit (250f2bb) in 2023-06-23 by [email protected]. AFAICT looking at the rest of that diff, there's nothing special about the 5 intrinsics affected, and the TD files do not seem to be making any effort to use '_' rather than '.' on them.There is no change in test coverage -- these intrinsics do not appear to be tested?