Optimize literal list construction in LLVM backend #6832
Conversation
Currently, list literals are always heap-allocated and their elements are stored by emitting a GEP and store for each item in the literal. This produces huge quantities of IR, causing compile times for e.g. programs with large literals or ingested files to blow up. Instead, if a list literal consists entirely of literal values, create a global section for the literal and return a pointer to it.
|
Tested this using roc-htmx-playground, massive speed up in compile time, and significantly smaller LLVM IR file produced. |
| for _ in 0..zero_elements { | ||
| global_elements.push(element_type.const_zero()); | ||
| } | ||
| let mut bytes = Vec::with_capacity_in(refcount_slot_elements data_bytes, env.arena); |
There was a problem hiding this comment.
Is this bytes or elements? Can we build up elements, but directly write bytes? I think we need that level of control to properly set the refcount.
There was a problem hiding this comment.
pretty sure we can't directly write bytes with the llvm api
| let is_all_constant = elems.iter().all(|e| e.is_literal()); | ||
|
|
||
| if is_all_constant { |
There was a problem hiding this comment.
Just a note, I think we will have to restrict this for now to is_all_constant and does_not_contain_pointers. I think the surgical linker does not currently handle constants that contain pointers. So no lists of lists, lists of strings, lists of recursive tags, etc.
| // TODO re-enable, currently causes morphic segfaults because it tries to update | ||
| // constants in-place... | ||
| // if element_type.is_int_type() { |
There was a problem hiding this comment.
you can't just ignore this comment :) the issue is real, the generated code will try to in-place modify the list which is now stored in read-only memory. I think the proper fix for now is to store all bytes in a global, and then use a memcpy instead of a normal loop to allocate the list on the heap when it is instantiated.
There was a problem hiding this comment.
Is that the issue that we're running into CI? I deleted the comment because I figured that was independent to the implementation in that branch, not the one in this PR.
There was a problem hiding this comment.
I believe that that is the issue yes. Some in-place mutation is occuring on bytes that are in the readonly section of the binary.
|
Thank you for your contribution! Sometimes PRs end up staying open for a long time without activity, which can make the list of open PRs get long and time-consuming to review. To keep things manageable for reviewers, this bot automatically closes PRs that haven’t had activity in 60 days. This PR hasn’t had activity in 30 days, so it will be automatically closed if there is no more activity in the next 30 days. Keep in mind that PRs marked |
Currently, list literals are always heap-allocated and their elements
are stored by emitting a GEP and store for each item in the literal.
This produces huge quantities of IR, causing compile times for e.g.
programs with large literals or ingested files to blow up.
Instead, if a list literal consists entirely of literal values, create a
global section for the literal and return a pointer to it.