-
Notifications
You must be signed in to change notification settings - Fork 44
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
[onnx-frontend] fix some error #372
Conversation
YellowHCH
commented
Jun 25, 2024
- support NotOp
- support lowering CumSumOp to stablehlo
- fix concat with incompatible element type operands
// %unq = onnx.Unsqueeze(%cast, %axes) : tensor<?xTy1> -> tensor<?xTy1> | ||
// onnx.Concat(..., %unq, ...) -> tensor<?xTy1> | ||
// clang-format on | ||
struct CheckUnsqueezeOp : public OpRewritePattern<mlir::ONNXUnsqueezeOp> { |
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.
Is it better to check if the operands have the same type as the result of concat? If not, then you add a cast to the operand. This shouldn't be specific to Unsqueeze?
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.
Check ConcatOp directly seems better
-/// Checks whether a variadic value is produced by dense ONNXConstantOps. | ||
+/// Checks whether a variadic value is produced by dense ONNXConstantOps and has | ||
+/// same element type. | ||
bool isVariadicOperandFromDenseONNXConstantOp(ValueRange operands) { |
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.
maybe we don't need to check if they have the same data type? If their datatype mismatches, it will fail at op verification anyway
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.
maybe we don't need to check if they have the same data type? If their datatype mismatches, it will fail at op verification anyway
Agree that, this check is redundant after fixing the incompatible operand types of concat
ONNXMaxPoolSingleOutOpAdaptor, ONNXMaxPoolSingleOutOpShapeHelper>>(ctx); | ||
patterns.insert<ONNXPoolOpLoweringToStablehlo<ONNXAveragePoolOp, | ||
ONNXAveragePoolOpAdaptor, ONNXAveragePoolOpShapeHelper>>(ctx); | ||
+ patterns.insert<ONNXCumSumOpLowering>(ctx); |
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.
need to add a test for op conversion (In onnx-mlir/test/conversion/onnx_to_stablehlo), add them in the patch, and later make a PR to onnx-mlir upstream
908780f
to
50c5ed1
Compare
- support NotOp - support lowering CumSumOp to stablehlo - fix concat with incompatible element type operands Signed-off-by: Chenhui Huang <huangchenhui.yellow@bytedance.com>
50c5ed1
to
c971910
Compare