-
Notifications
You must be signed in to change notification settings - Fork 321
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
Add NNPA level compatibility check #2533
Conversation
Signed-off-by: Mike Essenmacher <[email protected]>
Signed-off-by: Mike Essenmacher <[email protected]>
Signed-off-by: Mike Essenmacher <[email protected]>
Signed-off-by: Mike Essenmacher <[email protected]>
Signed-off-by: Mike Essenmacher <[email protected]>
Signed-off-by: Mike Essenmacher <[email protected]>
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.
@mikeessen thanks for the patch!
I see we have another locations that need isCompatibleWithNNPALevel
, those are inside addDynamicallyLegalOpFor
functions in https://github.com/onnx/onnx-mlir/blob/main/src/Accelerators/NNPA/Conversion/ONNXToZHigh/RewriteONNXForZHigh.cpp.
// The NNPA levels. | ||
static constexpr const char *NNPA_Z13 = "z13"; | ||
static constexpr const char *NNPA_Z14 = "z14"; | ||
static constexpr const char *NNPA_Z15 = "z15"; |
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.
Do we use NNPA_Z{13, 14, 15}
in practice?
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.
Thanks, I removed the definitions for NNPA_Z{13, 14, 15}
/// A function to check whether the input NNPA level, ie. "z16", is compatible | ||
/// with the current NNPA level. | ||
bool isCompatibleWithNNPALevel(std::string inputNNPALevel) { | ||
if (convertNNPALevel(inputNNPALevel) <= convertNNPALevel(mcpu)) { |
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.
For brevity, we can use return convertNNPALevel(inputNNPALevel) <= convertNNPALevel(mcpu);
BTW, a corner case, if both convertNNPALevel(inputNNPALevel)
and convertNNPALevel(cpu)
return 0 (because of some failure), this condition is true
that is not what we want. Perhaps, you could check if convertNNPALevel
succeeded or not before doing comparison.
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.
Thanks, I updated for the corner case and also brevity.
// Check NNPA level. | ||
if (!isCompatibleWithNNPALevel(NNPA_Z16)) { | ||
return false; | ||
} |
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 redundant. Just returning false
for unsupported ops is enough.
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.
Thanks, I updated to just return false.
// Check NNPA level. | ||
if (!isCompatibleWithNNPALevel(NNPA_Z16)) { | ||
return false; | ||
} |
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.
Could you please remove {
and }
for this simple if? Same for other locations.
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.
@tungld unless it's a standard in onnx-mlir to drop the {}
's for one line if
statements, I lean towards keeping them. Functionally nothing changes but the braces are less error prone during maintenance or debugging scenarios.
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.
@cjvolzka we don't have a standard but we follow LLVM coding style: https://llvm.org/docs/CodingStandards.html#don-t-use-braces-on-simple-single-statement-bodies-of-if-else-loop-statements
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.
Ok, good to know. I defer to the established norm for the repo on such things.
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.
Thanks, updated to remove { } from these statements.
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.
The only places I think it's ok to have extra {}
is in the presence of nested ifs, as dangling else
are dangerous. Otherwise, best to keep to the LLVM formatting rules
Signed-off-by: Mike Essenmacher <[email protected]>
@tungld I updated the |
@@ -499,6 +499,10 @@ void getRewriteONNXForZHighDynamicallyLegal( | |||
// broadcasting. | |||
addDynamicallyLegalOpFor<ONNXAddOp>( | |||
target, dimAnalysis, [](ONNXAddOp op, const DimAnalysis *dimAnalysis) { | |||
// Check NNPA level. | |||
if (!isCompatibleWithNNPALevel(NNPA_Z16)) { | |||
return false; |
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.
@mikeessen I am sorry that the logic here is a bit confusing. false
means the operation is illegal and must be rewritten to run on NNPA, while true
means the operation is legal and will remain on CPU. So I think we should return true. Same for the other changes in this file.
It's contrary to the logic in isSuitableForZDNN
. Actually it's like calling ! isSuitableForZDNN()
.
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.
Thanks for the clarification. I updated false to true.
Signed-off-by: Mike Essenmacher <[email protected]>
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! Thanks for the patch!
Signed-off-by: Mike Essenmacher <[email protected]>
Signed-off-by: Mike Essenmacher <[email protected]>
Signed-off-by: Mike Essenmacher <[email protected]>
Jenkins Linux ppc64le Build #11900 [push] Add NNPA level compatibi... started at 11:50 |
Jenkins Linux amd64 Build #12883 [push] Add NNPA level compatibi... started at 10:42 |
Jenkins Linux s390x Build #12907 [push] Add NNPA level compatibi... started at 11:42 |
Jenkins Linux amd64 Build #12883 [push] Add NNPA level compatibi... passed after 1 hr 16 min |
Jenkins Linux s390x Build #12907 [push] Add NNPA level compatibi... passed after 1 hr 21 min |
Jenkins Linux ppc64le Build #11900 [push] Add NNPA level compatibi... passed after 1 hr 46 min |
@mikeessen Can you confirm: we now need the |
@AlexandreEichenberger Yes, mcpu z16 is required for maccel NNPA to take effect. |
This is my expectation. Somewhere llvm has to be using something as a default mcpu when one isn't specified. Something makes me think that's z13 but I might be off. Whatever that default is, it's not z16. So an unspecified mcpu means "use z13 (or whatever the llvm default is) instructions". NNPA instructions won't be available for anything but the latest processor. So before this change, specifying only -maccel=NNPA, we would create a model that targeted (by implied default) for z13 which couldn't possibly run on z13. After this change, specifying only -maccel=NNPA, we compile a model that will run on z13 using all available NNPA instructions for z13 (which is zero). |
@mikeessen would you mind checking the doc that all our examples that have NNPA also have the |
@AlexandreEichenberger Thanks, there are a couple examples which needed updating. I created a PR to address: #2551 |
Thanks for the quick fixes on the doc :-) |
Add NNPA level compatibility check to validate operations for the specified --mcpu value.