[LLVMdev] LLVM IR is a compiler IR

Michael Clagett
Thu, 06 Oct 2011 18:29:26 -0000

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>