[LLVMdev] LLVM capability question.

[Reid Spencer]

Hello Michael,

On Thu, 2006-12-21 at 20:23 +0800, 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
> 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.)
> 
>      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. 

I don't think so. 

>      1. 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). 

Okay. I'm not sure what the question is. Certainly LLVM can handle
vtable type things. If this is only for garbage collection, you might
want to consider implementing the garbage collection interface in LLVM.
Please see: http://llvm.org/docs/GarbageCollection.html 

>      1. 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. 

Function call instructions can have a "tail" option which enables tail
call optimization. If you write:

    tail call void %foo ()

then you will get a tail call. Without the "tail" keyword, you won't.


>      1. 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?

I don't think so, but things could be done in the code generator to make
that happen. I believe the code generators assume there's one execution
stack.  However, I'm not the best person to answer this question so
perhaps someone else will chime in. 

Reid.

> 
> -- 
> Michael T. Richter
> Email: ttmrichter at gmail.com, mtr1966 at hotpop.com
> MSN: ttmrichter at hotmail.com, mtr1966 at hotmail.com; YIM:
> michael_richter_1966; AIM: YanJiahua1966; ICQ: 241960658; Jabber:
> mtr1966 at jabber.cn
> 
> "To [the Chinese], all other people are barbarians." --The Dalai Lama
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev