LLVM back end

[Simon Marlow]

Simon Peyton-Jones wrote:
> How about
> * concurrency (the ability to have zillions of little stacks,
>         with stack overflow checks and growing the stck on overflow)?
> * exception handling (the ability to crawl over the stack
>         looking for exception catch frames)?
> * garbage collection (the ability to find pointers in the stack)

I'd imagined that we'd use LLVM as a low-level code generator, doing our own 
stack management and using the existing GHC runtime support for all of these 
things.  Michael seems to be saying something different though... but it seems 
to me that anything other than using LLVM as a code generator only is a *lot* of 
work, and in direct competition with C--, so not an easy sell.

Cheers,
	Simon

> Simon
> 
> | -----Original Message-----
> | From: glasgow-haskell-users-bounces at haskell.org [mailto:glasgow-
> | haskell-users-bounces at haskell.org] On Behalf Of Wolfgang Thaller
> | Sent: 20 December 2006 23:55
> | To: ttmrichter at gmail.com
> | Cc: GHC Users; Simon Marlow
> | Subject: Re: LLVM back end
> |
> | On 20-Dec-06, at 10:10 AM, Michael T. Richter wrote:
> |
> | > Well, I'm almost entirely ignorant of LLVM and of Haskell --
> | > especially the internals of both.  That makes me ideally suited for
> | > this project since I'm not aware that it's impossible.
> |
> | I'm afraid LLVM currently lacks some features that are required for
> | efficient GHC code generation, specifically:
> |
> | a) Global Register Variables
> | b) The ability to put data next to code
> | c) (maybe, I'm not sure) Tailcalls
> |
> | ad a)
> | We need to keep some things in global registers for speed reasons
> | (depending on the number of available registers); among other things,
> | the haskell stack pointer and the heap pointer. Using regular global
> | variables instead would be a lot slower.
> |
> | ad b)
> | With (almost) every chunk of code, we want to associate a smal chunk
> | of data (the "info table") which contains information used by the
> | garbage collector and other parts of the run time system. We want to
> | use only one pointer to point to both of those things, and we don't
> | want to waste time with any additional indirections, so we make the
> | pointer point between the data chunk and the code chunk.
> |
> | ad c)
> | While they are supported in theory, I couldn't get LLVM to generate
> | any tailcalls. Maybe I've done something wrong, maybe they're not
> | really implemented yet.
> |
> | So I guess step one would be to start negotiating about those things
> | with the LLVM people.
> |
> | Cheers,
> |
> | Wolfgang
> |
> | _______________________________________________
> | Glasgow-haskell-users mailing list
> | Glasgow-haskell-users at haskell.org
> | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users