[LLVMdev] FW: LLVM IR is a compiler IR

[Michael Clagett]

Sorry, menat to upload this to the list.

> From: greened at obbligato.org
> To: mclagett at hotmail.com
> CC: llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] LLVM IR is a compiler IR
> Date: Thu, 6 Oct 2011 14:02:48 -0500
> 
> Michael Clagett <mclagett at hotmail.com> writes:
> 
> > 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.
> 
> Let me make sure I'm understanding you correctly.  You want to map each
> of you opcodes into an LLVM sequence and then use the LLVM optimizations
> and JIT to generate efficient native code implementations?  Then you
> would invoke those implementations during interpretation?
> 
> Or is it that you want to take a bytecode program, map it to LLVM IR,
> run it through optimizations and codegen to produce a native executable?
> 
> Either one of these will work and LLVM seems like a good match as long
> as you don't expect the optimizations to understand the higher-level
> semantics of your opcodes (without some work by you, at least).
> 
> I don't quiet grasp any benefit to the first use as I would just go
> ahead and generate the optimal native code sequence for each opcode once
> and be done with it.  No LLVM needed at all.  So I suspect this is not
> what you want to do
> 
>                              -Dave
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111006/27744e77/attachment.html>