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

[Python] Switch CIRCT Python extension and dialects to nanobind. #8110

Merged
merged 1 commit into from
Jan 22, 2025

Conversation

mikeurbach
Copy link
Contributor

This follows the general nanobind porting guide and the upstream MLIR changes in the same vein. For the most part, this is a very direct migration accomplished with sed.

There were a couple minor differences.

Nanobind is more strict about implicit casting, which popped up in a couple places:

  • In MSFTModule, getNearestFreeInColumn was expecting a CIRCTMSFTPrimitiveType (int), but was actually being passed PrimitiveType enums at the call sites. Nanobind refused to automatically cast enum to int, so it was done manually.
  • In SVModule, SVAttributeAttr.get was expecting a bool for emitAsComment, even though it was declared as having a default of None. Nanobind refused to automatically cast None to bool, so it was done manually, with a default of false.

Nanobind also prints enums slightly differently, so one FileCheck test had to be updated for ESI.

Otherwise, the changes were purely mechanical.

This follows the general nanobind porting guide and the upstream MLIR
changes in the same vein. For the most part, this is a very direct
migration accomplished with sed.

There were a couple minor differences.

Nanobind is more strict about implicit casting, which popped up in a
couple places:

* In MSFTModule, getNearestFreeInColumn was expecting a
CIRCTMSFTPrimitiveType (int), but was actually being passed
PrimitiveType enums at the call sites. Nanobind refused to
automatically cast enum to int, so it was done manually.
* In SVModule, SVAttributeAttr.get was expecting a bool for
emitAsComment, even though it was declared as having a default of
None. Nanobind refused to automatically cast None to bool, so it was
done manually, with a default of false.

Nanobind also prints enums slightly differently, so one FileCheck test
had to be updated for ESI.

Otherwise, the changes were purely mechanical.
Copy link
Contributor

@teqdruid teqdruid left a comment

Choose a reason for hiding this comment

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

LGTM!

Will this work on Windows? We still don't have the integration tests running on the Windows builds (since they still fail). I'll have a go at checking on Windows, though it may take me a few days so feel free to land this. I'm probably the only one who has to care about Windows.

@mikeurbach
Copy link
Contributor Author

I don't know, and don't currently have a Windows environment, but I'm cautiously optimistic, because I think upstream does care about Windows, and it seems stable upstream.

@mikeurbach
Copy link
Contributor Author

Looks like wheels succeeded. Unfortunately, there was basically no change in the size: 20.9MB with nanobind, versus the previous wheels taking 21.0MB with pybind11. I'll take these wheels and see how the performance compares in a downstream tool.

@mikeurbach
Copy link
Contributor Author

I'm gonna go ahead and land this.

@mikeurbach mikeurbach merged commit c8416f7 into main Jan 22, 2025
8 checks passed
@mikeurbach mikeurbach deleted the mikeurbach/nanobind branch January 22, 2025 22:28
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