[LLVMdev] Some question on LLVM design
Marc Ordinas i Llopis
lists at tragnarion.com
Mon Oct 25 07:00:11 CDT 2004
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
> 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.
Marc Ordinas i Llopis | Tragnarion Studios
More information about the LLVMdev