[eschew]

At least two of the article's statements about LLVM are false. In particular:

1) LLVM doesn't place any restrictions on how a language runtime allocates memory.

2) LLVM doesn't "expect" a stack map -- it provides infrastructure to compute them if the front end wants to, but the front end is completely free to ignore that infrastructure.

[fao_]

Are those corrections to the incorrect statements, or the incorrect statements themselves? It's not very clear, I'm sorry.

[sinistersnare]

So I wouldnt say that LLVM places restrictions, but I will say a little of my experience doing LLVM + BoehmGC

BoehmGC uses the stack for its root set (where it starts to find live memory). With LLVM, you dont ever need to explicitly use the stack, you can use registers for everything and make LLVM figure out if it should go on the stack or not. If you want to use Boehm with LLVM, you are forced to explicitly allocate everything on the stack, and not just on a register, so that Boehm is guaranteed to find the memory.

So I wouldnt say restriction, but definitely you need to think about how LLVM operates with the GC and other runtime components of your language.

[eschew]

Ah, they are corrections to the article's incorrect statements! I apologize for the ambiguity.

[Groxx]

Yeah, it was fuzzy to me too. Found this in the article though:

> First, a description of how SBCL’s generational GC works:

> ...

> Being conservative with regards to the stack. That creates a major clash with LLVM which expects a stack map. A stack map declares which data type can be found where on the stack for a function (as in every invocation of that function needs to comply to it), whereas SBCL’s compiler can and does generate code that just places anything anywhere. This makes the stack a lot more compact in some call patterns.

So those were intended as corrections.