[LLVMdev] Some question on LLVM design

[Marc Ordinas i Llopis]

Thanks all for the fast answers, I'm certainly understanding LLVM 
better. Some more comments below:

Chris Lattner wrote:
>>Couldn't the front-end just produce stores/volatile stores and then a
>>compilation pass transform them into a write-barrier if necessary?
> 
> 
> 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?

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?

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

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.

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

Thanks everyone,

Marc Ordinas i Llopis | Tragnarion Studios