[LLVMdev] LLVM and managed languages
atrick at apple.com
Fri Jul 1 16:41:04 PDT 2011
I have some questions below. If these topics have already been discussed in earlier threads, kindly point me there. I'm aware of your GC proposal, but the rest is new to me.
On Jul 1, 2011, at 11:05 AM, Talin wrote:
> Garbage collection is still way too difficult. The biggest problem is the inability to track SSA values - it requires the frontend to generate very inefficient and error-prone code, manually spilling SSA values to the stack around nearly every function call. I've written proposals for improving the situation, which I won't repeat here - but realistically there's no way that I am ever going to have time learn to enough about LLVM's code generation passes to implement something like this myself.
> Another area which I'd like to see supported is stack walking - that is, starting from the current call frame, iterate through all of the call frames above it. Currently the only way to do this is via platform-specific assembly language - I'd think it would be relatively simple to make an intrinsic that does this. (Note that the current stack intrinsics are unusable, because they are (a) unreliable, and (b) inefficient. Taking an integer index of a stack frame as a parameter is not the right way to do it.)
> I have to say, if there's any single issue that could make me give up on LLVM and switch over to using something like a JVM, it would be this - because as far as I can tell, LLVM's garbage collection features are in exactly the same state they were in when I started working with LLVM four years ago.
JVM implementers have done a lot of work in their respective compiler backend to support moving collectors. I'm not aware of any efficient solution short of making the backend aware of object pointer types. i.e. Machine operands need to carry these types.
For stack walking, what do you need in addition to DWARF unwind? Or is generating correct unwind tables the problem? I'm not sure what stack intrinsics you mean... returnaddress and frameaddress? They don't always work if you provide the necessary target options? It almost sounds like you want more control than libunwind provides? Or do you want more efficiency?
> Light-weight coroutines would be a "nice to have", as would better concurrency primitives.
This could be interesting. Can you explain in more detail or just point me to some examples?
> There's been a lot of discussion about divide-by-zero errors and other non-declared exceptions. Having this available would be a great help.
What is a non-declared exception (no throw statement in the source code?), and do you think something is missing from LLVM IR? I don't see any difficulty expressing Java/C# exceptions in LLVM IR. Do you want to build high-level language semantics into LLVM IR to avoid duplicating effort across Java/C#/Tart frontends? Or do you want better optimization/codegen in these cases (language-friendly backend)?
Keep in mind that adding higher level IR constructs only inhibits optimization. Java bytecode bakes language semantics into opcodes as a compression technique. It's not a form that is amenable to optimization.
Maybe what you really want is a managed language toolkit for use in frontends such as yours?
Backing up now to the overall topic, which of these general themes fits your experience:
1) You want more efficient support for implementing advanced runtime features for a given target
2) You want more ABI abstraction for easier porting across a range of targets
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev