[LLVMdev] LLVM IR is a compiler IR

David A. Greene greened at obbligato.org
Thu Oct 6 12:02:48 PDT 2011


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



More information about the llvm-dev mailing list