Hi There,
I've just started reading about LLVM and I just wanted to make sure that it can do what I was hoping it could do. Am I correct in assuming that I could use LLVM as a backend for a compiler, emiting LLVM byte codes which could either be natively compiled (Sparc and x86) or byte code interpretted / JITed??
Yes, that's right!
In fact, shortly the process of doing that will get easier with the
llvmc (compiler driver) tool that I'm working on. You write your
compiler to generate either bytecode or LLVM assembly and a
configuration file. The rest of it (optimization, linking, codegen) can
be done with existing LLVM tools. If you later want to include those
features in your compiler, you can (via the C++ interface) and just
reconfigure your compiler's configuration file.
Welcome to LLVM, Peter!
Reid.
That is correct.
You can write your own front-end or use our C/C++ front end to emit LLVM
bytecode, and then our tools (llc, static compiler, or lli,
interpreter/jit) can generate native code from the LLVM.
Reid Spencer wrote:
Yes, that's right!
In fact, shortly the process of doing that will get easier with the
llvmc (compiler driver) tool that I'm working on. You write your
compiler to generate either bytecode or LLVM assembly and a
Does that mean the front end must decide between emiting bytecode for interpretting/JITing and LLVM assembly for native compilation? You can't emit the one kind of output for either end target (interpretted bytecode or native compilation)?
configuration file. The rest of it (optimization, linking, codegen) can
be done with existing LLVM tools. If you later want to include those
features in your compiler, you can (via the C++ interface) and just
reconfigure your compiler's configuration file.Welcome to LLVM, Peter!
Thanks :o)
Not at all, there's only one version of LLVM IR, but it can appear in
binary bytecode or textual form (human-readable). They have a
one-to-one correlation.
There is an assembler (llvm-as) and disassembler (llvm-dis) for
translating between the two formats.
Misha Brukman wrote:
Hi There,
I've just started reading about LLVM and I just wanted to make sure that it can do what I was hoping it could do. Am I correct in assuming that I could use LLVM as a backend for a compiler, emiting LLVM byte codes which could either be natively compiled (Sparc and x86) or byte code interpretted / JITed??
Now, PowerPC as well!
and at 5:48 PM, Peter Ashford wrote:
Not at all, there's only one version of LLVM IR, but it can appear in
binary bytecode or textual form (human-readable). They have a
one-to-one correlation.There is an assembler (llvm-as) and disassembler (llvm-dis) for
translating between the two formats.Ah, great! That does mean that LLVM does what I was hoping for. Thanks for the info :o)
That's good 
because fundamentally, this *is* what LLVM was designed for -- to work as a common back-end with some specific capabilities. The IR will not directly represent most high-level language features but it should be possible to efficiently implement them and, in most cases, implement them cleanly enough to allow generic LLVM optimizations to produce efficient code for them as well. By making the IR persistent and simple, it should be possible to apply the optimizations at multiple stages, from development time through production runs.
Of course, that's the theory If you find cases where the IR doesn't allow some optimizations you want or would lead to inefficient code due to design limitations (not simply missing analysis or optimization passes), please let us know.
--Vikram
http://www.cs.uiuc.edu/~vadve
http://llvm.cs.uiuc.edu/
Reid Spencer wrote:
Yes, that's right!
In fact, shortly the process of doing that will get easier with the
llvmc (compiler driver) tool that I'm working on.
[another newbie delurks]
Hi, Reid. Been tinkering with LLVM about 2 weeks now. I've been using the Stacker Compiler as an example so far for my own little project. Is this tool you mentioned coming "Real Soon Now(tm)", or is it months away? If its coming soon, should I avoid using the Stacker example as a template? In other words, how much is this tool going to change the way one builds a frontend to LLVM? Sorry in advance if this is a stupid question, LLVM is still a new beast to me.
Thanks folks for your effort here, after looking at GCC sources to see what writing a frontend would be like, LLVM looks like manna from heaven. Oh wait, that would make you guys.... uhh.... never mind.
Ed
Reid Spencer wrote:
> Yes, that's right!
>
> In fact, shortly the process of doing that will get easier with the
> llvmc (compiler driver) tool that I'm working on.
[another newbie delurks]
heh. Hi!
Hi, Reid. Been tinkering with LLVM about 2 weeks now. I've been using the
Stacker Compiler as an example so far for my own little project. Is this tool
you mentioned coming "Real Soon Now(tm)", or is it months away?
You can look at llvmc today in llvm/tools/llvmc. It won't build
automatically because its not in llvm/tools/Makefile yet, but that will
happen this week. It does everything except linking right now. I hope to
finish it by month's end.
If its coming
soon, should I avoid using the Stacker example as a template? In other words,
how much is this tool going to change the way one builds a frontend to LLVM?
Sorry in advance if this is a stupid question, LLVM is still a new beast to me.
The Stacker example is still a reasonable way to *start* your compiler.
You can get an optimizing back end that generates native or bytecode
output up and running by merely writing a simple translator (like
Stacker) and a configuration file (for which there is a stacker example
as well). Furthermore it will allow you to automagically link with other
LLVM compiled language (e.g. C/C++/LLVM Assembly). You have two choices
initially: write a front end that produces LLVM Assembly text files
(like the scheme front end) or write one that uses the C++ IR and
produces bytecode files (like Stacker). The rest is handled by llvmc.
As your compiler mature and if you write it in C++, you can make it do
optimizations and configure llvmc not to run "opt". This will give you
better control over the optimizations passes, allow you to write your
own language specific passes, and also do the bulk of compilation more
quickly (fewer execs, less file I/O, etc.). Linking will still be
handled automatically by llvmc.
Thanks folks for your effort here, after looking at GCC sources to see what
writing a frontend would be like, LLVM looks like manna from heaven.
Yeah, my sentiments exactly. I faced the same "need a backend" problem
last November. When I found I could invent a language (Stacker) and
implement something that worked in 4 days, I was thrilled. I had spent 4
MONTHS just trying to grok the GCC mailing list, never mind the code!
As for "manna from heaven", I think you just made Misha's quote book
Welcome Aboard!
Reid.