list constants · compiler development

related to #compiler development > Memory bugs with large struct, I noticed that no lists are actually ever constants currently. That would lead to morphic segfaulting due to assuming it can mutate the lists. I assume @Folkert de Vries you have the most context on this.

Any thoughts or tips on what it would take to fix this/how large the project is. I would love to get to the point where all lists that don't contain pointers (box, str, list, recursive tag), can be compile time constants. The lists with pointers will still need to wait on fixing some relocation issue in the the surgical linker.

Brendan Hansknecht (Jan 17 2024 at 03:59):

This todo specifically: https://github.com/roc-lang/roc/blob/ae0e3593a405e77a039fc10c613eb45ef83b8ab5/crates/compiler/gen_llvm/src/llvm/build.rs#L2980-L2982

Folkert de Vries (Jan 19 2024 at 16:09):

hmm, we actually make LLVM segfault with that code. Fun

Folkert de Vries (Jan 19 2024 at 16:26):

does https://github.com/roc-lang/roc/pull/6403 work for you, or is more needed?

Folkert de Vries (Jan 20 2024 at 14:21):

well, it's interesting that this hasn't come up before, but it makes sens: morphic does not work well with static data. We use morphic to tell us "yes you can do the update in-place", and then do so blindly.

Folkert de Vries (Jan 20 2024 at 14:22):

so we need to somehow make it clear to morphic that literals are not eligible for in-place mutation

Folkert de Vries (Jan 20 2024 at 14:23):

in theory we do that already though so not sure what's up with that

Richard Feldman (Jan 20 2024 at 14:50):

Folkert de Vries said:

so we need to somehow make it clear to morphic that literals are not eligible for in-place mutation

could we generate a fake extra reference to them, so it thinks they're always shared?

Folkert de Vries (Jan 20 2024 at 15:34):

I just tested this in the morphic repo itself and there it works, so it must be something with how we encode the program

Folkert de Vries (Jan 20 2024 at 15:52):

so, actually this may be more complicated. We define

reverse : List a -> List a
reverse = \list ->
    reverseHelp list 0 (Num.subSaturated (List.len list) 1)

reverseHelp = \list, left, right ->
    if left < right then
        reverseHelp (List.swap list left right) (Num.addWrap left 1) (Num.subWrap right 1)
    else
        list

assuming we only make one specialization of reverseHelp, morphic could not really do much here. The input to reverseHelp might be shared!

At runtime the second iteration would still see that the update could happen in-place, but at compile time morphic should just tell us that no in-place mutation can happen.

We can fix this by explicitly making the list unique. I think this is at rick we should have available in the standard library at least. Exposing it to users is something we can discuss.

Folkert de Vries (Jan 20 2024 at 18:40):

hmm I now do think there is an underlying morphic problem https://github.com/morphic-lang/morphic_lib/issues/20 I know they introduced continuations later on, and I suspect there is just some information lost somewhere leading to incorrect results