[LLVMdev] LLVM capability question.

[Chris Lattner]

On Thu, 21 Dec 2006, Michael T. Richter wrote:
> I'm losing my sanity, so I thought I'd try and generate an LLVM target
> for the Glasgow Haskell Compiler (GHC).  In talking to some of the

Ah, so you had to lose your sanity before considering llvm... I see.  :)
:)

> people in the GHC mailing list some issues have come up that I can't
> find a ready answer to.  (Others came up that I could, so I don't feel
> quite as stupid or helpless as I could.)

Ok,

>     1. Is there any way to hint that a global pointer variable should
>        be put in a register when further translated to some native form
>        of code?  This is specifically necessary, apparently, for the
>        current stack and heap pointers in GHC for speed reasons.

llvm-gcc supports the GCC 'asm("%ebx")' syntax for global variables.  Note 
that, like GCC, LLVM only makes guarantees about the contents of the 
register during inline asm calls, so this may not be sufficient for you.

If this isn't sufficient, it may make sense to do a simple extension to 
LLVM to provide a capability to do this sort of thing.  However, you 
should do some performance analysis to determine if this is needed, LLVM 
produces very different code than GCC, so you may not need to do this.

>     2. This I'm just going to quote: "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."  I've
>        asked for clarification on this from the original author, but I
>        suspect it's something like having a pointer to code base that
>        uses negative offsets to associated data (like some C++
>        implementations use for the vtable).

C++ v-tables aren't typically implemented this way, AFAIK.  However, it 
should be easy to add an intrinsic to capture this and do the right thing.

>     3. What is the actual support for tail calls?  The docs are pretty
>        vague on this point -- the "tail" keyword seems to "enable" tail
>        call optimisation.  I'm not sure what that means.

When a call is marked 'tail', the compiler is allowed to assume that the 
callee does not access the caller's stack.  Thus, if marked 'tail', in the 
tail position (right before a return), and marked 'fastcc' (so arguments 
can be passed normal order instead of reverse order), the code generator 
can deallocate the stack before calling the callee.

AFAIK, the X86 backend is currently the only one that supports this, and 
you have to pass a special option to get it to do so.  It should be 
straight-forward to extend other targets to support this, but there has 
been little demand so far.

>     4. GHC relies an awful lot on having many, many, many "little
>        stacks".  Is it possible to have lots of tiny stacks in LLVM's
>        architecture, to switch between them easily, to check when they
>        overflow and to automatically grow them when they exceed their
>        bounds?

It depends on what you mean.  There are multiple ways to achieve this. 
The simplest way is to use CPS:
http://nondot.org/sabre/LLVMNotes/ExplicitlyManagedStackFrames.txt

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/