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

Data.Vector more appropriate to represent the subtypes of aggregate types #357

Open
jfaure opened this issue Aug 28, 2021 · 2 comments
Open

Comments

@jfaure
Copy link
Contributor

jfaure commented Aug 28, 2021

currently basic haskell list type is used, but we often want to index the list (even in llvm-hs itself eg IRBuilder.gep)
eg. AST.Type.StructureType , Constant.Array etc..

@andrew-wja andrew-wja changed the title Data.Vector more appropriate for aggregate types Data.Vector more appropriate to represent the subtypes of aggregate types Aug 31, 2021
@andrew-wja
Copy link
Member

andrew-wja commented Aug 31, 2021

@jfaure there's certainly an argument to be made for it. Do we actually use numerical indexing on a list of types with Data.List.!! in the code? If so we probably should switch to an array rather than a list, I would be happy to review a patch with this change.

Edit: I looked in LLVM.AST.Typed and we do indeed index into the list of types using an integer. It would be worth looking for all instances of Data.List.!! in the codebase and considering whether more things should become vectors rather than lists.

@jfaure
Copy link
Contributor Author

jfaure commented Aug 31, 2021

In the same vein, Integer is used everywhere for llvm int literals.
Since I use Word64 whenever possible (ie. pretty much always since anything larger than i64 is very rare), i have to call 'fromIntegral' frequently.
The issue here is that the overhead from unnecessarily using gmp is massive.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants