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

[examples][MLIRPython] support different tensor dtype in importer #180

Merged

Conversation

xTayEx
Copy link
Contributor

@xTayEx xTayEx commented Aug 5, 2023

Currently, importer only support tensor with torch.float32 dtype. This PR adds support for different tensor dtype.

Copy link
Member

@linuxlonelyeagle linuxlonelyeagle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I made some brief comments. I think the corresponding test cases should also be provided .

@xTayEx xTayEx force-pushed the feat/different_tensor_dtype_importer branch from e98ee65 to e3b438b Compare August 7, 2023 14:36
@xTayEx xTayEx force-pushed the feat/different_tensor_dtype_importer branch from e3b438b to 39ca419 Compare August 7, 2023 14:38
@xTayEx
Copy link
Contributor Author

xTayEx commented Aug 7, 2023

I made some brief comments. I think the corresponding test cases should also be provided .

Got it! I have add some test and use pattern match syntax in the new update. Give a review when you're free. Thanks :)

Copy link
Member

@linuxlonelyeagle linuxlonelyeagle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks good. There are a few other things that need to be done here, you can look at matmul here, the function that generates matmul should also support the type you added (i32), and examples should be provided accordingly.test_different_type.py is fuzzy,arith_add.py describes the contents stored in this file.Finally, thank you for your work .

@linuxlonelyeagle
Copy link
Member

When an issue is resolved, you can click Resolve conversation.


int32_in1 = torch.randint(0, 10, (10,)).to(torch.int32)
int32_in2 = torch.randint(0, 10, (10,)).to(torch.int32)
foo_mlir(int32_in1, int32_in2)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should not create a new test directory here, you should write the code here to arith_add.py.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for you review. I think the arith_add.py file is for demo purpose, not for testing. Therefore I create the test_different_dtype.py for just for testing the different dtype support feature. What do you think?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see what you mean, but I don't think it makes sense to recreate a directory for testing purposes, and at the same time it would cause confusion in the directory structure. arith_add.py should be used as an example and also for testing purposes.I think this is an obvious thing to do.

Copy link
Contributor Author

@xTayEx xTayEx Aug 9, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it. I have removed the test directory and put test code in arith_add.py in the latest commit. The redundant end lines should also have been removed. Give the updates a review when you're free. Thanks! :)

Copy link
Member

@linuxlonelyeagle linuxlonelyeagle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some brief comments.

Copy link
Member

@linuxlonelyeagle linuxlonelyeagle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, there are a few minor problems.

def foo(x, y):
return x + y


Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The two new lines added in rows 5 and 9 look unnecessary.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for pointing that out. I'd like to clarify that the two new lines added in rows 5 and 9 were automatically inserted by the yapf formatter, which use the .style.yapf file as configuration. If this is an issue, please let me know how you'd like me to proceed, or if there are other formatting rules I should follow.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, it doesn't look like it needs to be changed.

@linuxlonelyeagle
Copy link
Member

@zhanghb97 I have reviewed the code as well, please review the code.

@zhanghb97 zhanghb97 merged commit 9c3a0db into buddy-compiler:main Oct 17, 2023
1 check passed
@zhanghb97
Copy link
Member

Thanks! @xTayEx @linuxlonelyeagle

ShiHaoGao pushed a commit to ShiHaoGao/buddy-mlir that referenced this pull request Oct 18, 2024
…ddy-compiler#180)

* [examples][MLIRPython] support different tensor dtype in importer

* [examples][MLIRPython] use pattern match syntax for dtype matching
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.

3 participants