[llvm-dev] A "Java Backend"

[Lorenzo Laneve via llvm-dev]

Passing through LLVM IR would enable LLVM to apply its optimizers and, as I said, I know that creating a custom standalone backend could be easier, but enabling LLVM to translate to Bytecode would enable all of its frontends to do it.
I know that it might be quite hard to treat Java or .NET as LLVM targets, but could this be a challenge? Let LLVM IR be compiled to Bytecode and CLI, which are higher level than our IR.

> On Jul 21, 2016, at 11:36 AM, David Chisnall <david.chisnall at cl.cam.ac.uk> wrote:
> 
>> On 21 Jul 2016, at 09:31, Lorenzo Laneve <lore97drk at icloud.com> wrote:
>> 
>> I thought about something like that but I think it's not a good idea.
>> Like writing an AST visitor on Clang for example would be cool but it isn't open to other frontends, and I think that this is a job for LLVM.
>> What about java-* attributes that can be put on certain IR operations to indicate structures that are needed to know about the Java Bytecode structure, or operations that should be translated in a specific way for Java?
>> These attributes can be added to the IR modules optionally like debug info
> 
> I’m not sure what problem you’re trying to solve.  Providing these attributes from the front end and ensuring that they’re correctly preserved by optimisers would likely be more effort than writing a Java bytecode back end (and a lot more for any language that has a simple mapping to the Java object model).  By the time code is in LLVM IR, it’s already got a lot of assumptions about things like calling conventions and data layout embedded in it.  You’d need to treat the Java back end as another target in your front end (and a particularly weird one, at that).
> 
> If I had a front end that I wanted to use to target the JVM then I would not go via LLVM IR to get there.  The same probably holds for the CLR, though it’s a little bit less clear cut.
> 
> David
>