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

[Arc] Add support for struct and array states #6508

Merged
merged 1 commit into from
Dec 11, 2023

Conversation

fabianschuiki
Copy link
Contributor

Allow !arc.state to carry HW structs and arrays. The state only has to be able to compute the bit width of the inner type, but it does not care what exactly this type is.

Rework the Arc-to-LLVM lowering to do the entire lowering in one full conversion, instead of two separate ones. There is no real need for the split, and combining all patterns into one large conversion allows all Arc types to be directly converted to LLVM types. Previously, after the first partial conversion the IR would be in a strange in-between state of mixing Arc types into LLVM operations (for example, loads and stores of HW struct/array types).

@fabianschuiki fabianschuiki added the Arc Involving the `arc` dialect label Dec 10, 2023
Copy link
Member

@maerhart maerhart left a comment

Choose a reason for hiding this comment

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

That's a really useful addition. One step closer to directly support tapping aggregate registers/wires and allowing higher-level information to be passed through Arc!

@@ -16,16 +16,17 @@ class ArcTypeDef<string name> : TypeDef<ArcDialect, name> { }

def StateType : ArcTypeDef<"State"> {
let mnemonic = "state";
let parameters = (ins "::mlir::IntegerType":$type);
let parameters = (ins "::mlir::Type":$type);
Copy link
Member

Choose a reason for hiding this comment

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

Can we add a verifier to check that the getBitWidth helper can compute a valid result for the nested type?
That way we have it as an invariant and don't have to check for a valid return value each time we call getBitWidth. Plus a regression test triggering it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah great point

Allow `!arc.state` to carry HW structs and arrays. The state only has to
be able to compute the bit width of the inner type, but it does not care
what exactly this type is.

Rework the Arc-to-LLVM lowering to do the entire lowering in one full
conversion, instead of two separate ones. There is no real need for the
split, and combining all patterns into one large conversion allows all
Arc types to be directly converted to LLVM types. Previously, after the
first partial conversion the IR would be in a strange in-between state
of mixing Arc types into LLVM operations (for example, loads and stores
of HW struct/array types).
@fabianschuiki fabianschuiki merged commit 91e8b3d into main Dec 11, 2023
4 checks passed
@fabianschuiki fabianschuiki deleted the fschuiki/arc-struct-array-states branch December 11, 2023 22:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Arc Involving the `arc` dialect
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants