[LLVMdev] LLVM IR is a compiler IR

[Michael Clagett]

Hi Folks --

Let me go ahead and pose a question similar to the one Joachim poses below.  I too am trying to evaluate whether LLVM will be of use to me in building a compiler and garbage collection mechanism for a byte code vm that I have built.  Although there are multiple types of code that can be created with this system, all of them eventually translate to execution of one or more of these byte codes -- with the exception of stuff that's coded directly in Intel assembly language (which I understand can be output as is and left untouched by the LLVM compiler if desired).  There's about 32 core op codes that constitute the basic instruction set and I can envision mapping each of these to some sequence of LLVM IR.   There's also a whole lot more "extended opcodes" that are executed by the same core instruction execution loop but which are coded using the built-in Intel assembler and added dynamically by the system.  I could envision also going to the trouble of mapping each of these to a sequence of LLVM IR instructions and then being able to emit a series of LLVM IR sequences purely based on the sequence of vm opcodes encountered in a scan of code compiled for the vm.  

I'm hoping that such a product could then be submitted to all the LLVM optimizations and result in better Intel assembly code generation than what I have hand-coded myself (in my implementations of either the core or the extended opcodes -- and especially in the intel code sequences resulting from the use of these opcodes in sequences together).  So first question is simply to ask for a validation of this thinking and whether such a strategy seems feasible.

The second question pertains to this discussion thread.  If at the end of the day, all I am trying to do is compile for an 80x86 platform (although ideally hoping to target Windows, Linux and the Mac) and don't need to target multiple processors, then LLVM should add significant value for me if the answer to the first question is that it is a sound and sensible strategy.  And most of the discussion in this thread about platform-specific issues shouldn't apply if I only have one processor type to target.  Am I thinking about this correctly?

Any insights from some of you old hands would be greatly appreciated.   

Thanks.

Mike


Message: 1
Date: Wed, 05 Oct 2011 17:10:36 -0500
From: greened at obbligato.org (David A. Greene)
Subject: Re: [LLVMdev] LLVM IR is a compiler IR
To: Joachim Durchholz <jo at durchholz.org>
Cc: llvmdev at cs.uiuc.edu
Message-ID: <nngk48j5btv.fsf at transit.us.cray.com>
Content-Type: text/plain; charset=us-ascii
 
Joachim Durchholz <jo at durchholz.org> writes:
 
> Now that the dust begins to settle... I'm wondering whether LLVM is for me.
>
> I'm working on something that can be used to create software for 
> different environments: C/C++, JVM, CLR, Parrot, etc.
> I.e. one language for different environments, but not write once, run 
> anywhere.
>
> Now what would be the role of LLVM in such an infrastructure?
> Just backend for C/C++ linkage, and I should go and look elsewhere for 
> JVM/CLR/whateverVM?
> Should I look into LLVM subprojects? Which ones?
 
It depends on what you want to do with the IR.  If you want to create
object files, LLVM is great.  You just need to map the semantics of the
various HLLs onto the LLVM IR language, as with any translator.  For any
kind of code-generator-ish thing, it's hard to beat LLVM IR, IMHO.
 
If you want to JIT, then some of LLVM IR's limitations will impact the
speed of code generation, as Dan outlined.
 
If you want to do fancy transformations that use or analyze high-level
language semantics, LLVM IR may not be right for you, as most of that
information is lost by the time the code has been converted to LLVM IR.
 
                                  -Dave
 
 

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111006/905d4bb7/attachment.html>