Skip to content
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

Merged
merged 4 commits into from
Jun 28, 2024
Merged

Conversation

YellowHCH
Copy link
Collaborator

  • support NotOp
  • support lowering CumSumOp to stablehlo
  • fix concat with incompatible element type operands

@YellowHCH YellowHCH requested a review from Connor-XY June 25, 2024 14:24
// %unq = onnx.Unsqueeze(%cast, %axes) : tensor<?xTy1> -> tensor<?xTy1>
// onnx.Concat(..., %unq, ...) -> tensor<?xTy1>
// clang-format on
struct CheckUnsqueezeOp : public OpRewritePattern<mlir::ONNXUnsqueezeOp> {
Copy link
Collaborator

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?

Copy link
Collaborator Author

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) {
Copy link
Collaborator

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

Copy link
Collaborator Author

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);
Copy link
Collaborator

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

@YellowHCH YellowHCH force-pushed the chhuang/fix_unsupport_models branch from 908780f to 50c5ed1 Compare June 26, 2024 05:16
- support NotOp
- support lowering CumSumOp to stablehlo
- fix concat with incompatible element type operands

Signed-off-by: Chenhui Huang <huangchenhui.yellow@bytedance.com>
@YellowHCH YellowHCH force-pushed the chhuang/fix_unsupport_models branch from 50c5ed1 to c971910 Compare June 26, 2024 05:19
@YellowHCH YellowHCH requested a review from Connor-XY June 26, 2024 05:31
@YellowHCH YellowHCH merged commit 9a41649 into main Jun 28, 2024
3 checks passed
@YellowHCH YellowHCH deleted the chhuang/fix_unsupport_models branch June 28, 2024 12:47
Vremold added a commit that referenced this pull request Jul 4, 2024
  - 9a41649 [onnx-frontend] fix some error (#372)
  - 473bb38 [compiler] fix inf/nan convert to i32 on x86_64 arch (#378)

GitOrigin-RevId: 9a41649
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants