> Perhaps the most important property of BitC's backend language are its > features regarding garbage collection. I don't know if the Haskell > Cmm->LLVM backend uses LLVM's GC features (well, we can be sure that > it doesn't use the shadow stack); the problem may be already solved at > the Cmm level?
I'd be very surprised if Haskell used llvm's gc features at all. Not only because of reasons mentioned here [1] But because the entire toolchain was developed absent of llvm or anything like it. My first thought was that those restrictions don't apply to Bitc, but if const/readonly will be the norm, then its allocations might greatly exceed the use case for which llvm was created. I like the idea of Clight, but it doesn't really solve the problem of being platform agnostic. It currently supports powerPC. So x86 and arm seem a long ways off. IMO the fastest route to production for BitC would be LLVM and its gc mechanism. If it turns out to be slow, then we can examine building a custom one on top of LLVM or enhancing LLVM for a more streamlined allocation model. [1] http://lhc-compiler.blogspot.com/2009/01/why-llvm-probably-wont-replace-c.html > > [1] www.cse.unsw.edu.au/~pls/thesis/davidt-thesis.pdf > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
