[LLVMdev] Some question on LLVM design

[Chris Lattner]

On Mon, 25 Oct 2004, Marc Ordinas i Llopis wrote:
> > Sortof.  The problem with this is that (without gcwrite) there is no way
> > to identify the stores that should be turned into write barriers.  In
> > particular, the heap may have multiple parts to it, some of which are GC'd
> > and some are not.  For example, the .NET framework has different pointer
> > types for managed and unmanaged pointers: without the ability to represent
> > both in LLVM, we could not support it.
> >
>
> Ok, I understand this now. Would allocation to different heaps be
> represented using different intrinsics, then?

Hrm, not necessarily intrinsics.  The GC interface currently only supports
one logical heap, but it would be trivial to have a custom GC that does
whatever you'd like.

> Also, some answers were provided by Reid Specer, so I'm merging the two
> threads here:
>
>  > Intrinsics are intended to be replaceable by the target's code
>  > generation, if possible/necessary, or emulated with a function call if
>  > not. Language runtimes should be just that .. calls to functions located
>  > in libraries.
>
> But sometimes it's more efficient to have knowledge of the runtime in
> the compiler, i.e. inlining method lookup. Would that be implemented
> using a lowering pass to substitute the function call for the runtime code?

It depends on what you mean.  If you mean virtual method calls, we use
pointer analysis to expose the targets of virtual method calls.  In the
future, extensions to LLVM may be able to capture more detailed
information from the front-end (using class hierarchy analysis or other
techniques), but we have not started on that work yet.

> >>2. Stack and registers
> >
> > I'm not sure what you mean.  In particular, the alloca instruction is used
> > to explicitly allocate stack space.  Because it is not possible to take
> > the address of LLVM registers, this the mechanism that we use to allocate
> > stack space.  Certain langauges do not need a stack, and thus do not need
> > to use alloca, other languages (e.g. C) do.  If you clarify your question
> > I'll be able to give a more satisfactory answer.
> >
>
> So would it be possible to pass a pointer to a structure allocated in
> the stack to a called function?

Exactly.

> As to what I'm trying to do, more below.
>
> Reid Spencer wrote:
>  > I'm not sure what you mean by a "separate stack". Register allocation
>  > can spill registers to THE stack. I'll let someone more knowledgeable
>  > about this answer.
>
> I meant a stack separate from the infinite registers. I see now that we
> need a stack for taking the address of objects, thanks.

Yup.

> >>3. Control transfer
> > I'm not sure what it is that you are trying to do.  The abstraction
> > provided by the call instruction is good for the optimizers and analyses
> > (because they see exactly what they need, not extra details), good for
> > compilation speed, and good for target independence.  Custom calling
> > conventions (link above) are specifically designed to give the code
> > generator the flexibility to pick the most efficient calling convention
> > for a particular call/return pair.
> >
> > Given all of the above (efficient compiled code, easy to write
> > analysis/xforms, happy front-ends, fast compile times), I'm not sure what
> > your approach would give.  Care to elaborate?
> >
>
> Right now, I'm just trying to think on how I'm going to map our language
> features on LLVM, to see if we can use it as our back-end with as little
> modification as possible.

Okay.  If you can express the issues you have in C or C++, one easy way to
do this is to see what LLVM code the C/C++ front-end generates for a
particular construct.  Other options are to explain what you need and ask
here :)

-Chris

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