[MooreToCore] Lower the unpacked array type to hw.array
#7893
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
fabianschuiki
approved these changes
Nov 25, 2024
|
Feel free to get LLVM commit access such that the CI builds for your PRs run automatically and you can merge your own PRs one you've gotten reviews and are happy with everything 🙂. |
The semantics do not exactly align between these two types, but they do match closely enough. There is also `hw.uarray`, which could seem like a more suitable choice; however, there are no operations defined for this type yet.
slowlime
force-pushed
the
unpacked-array-lowering
branch
from
5584aa1
to
6a46320
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This add a type conversion for unpacked arrays, mapping them to
hw.array. The approach is analogous to how unpacked structs are currently handled.As far as I understand,
hw.uarraywould be more appropriate in the future, especially once it's moved to SV. However, no operation accepts this type yet. I'm not sure what the consensus is as to whether the operation set should be extended to accommodate unpacked arrays (by adding new operations or "overloading" existing ones that deal withhw.arrays). Using packed arrays for the time being sidesteps this question.