llvm dev - Mar 2009 - [LLVMdev] Rolling my own LLVM assembly language parser

On Wednesday 25 March 2009 17:12:34 John Criswell wrote:
> jstanier wrote:
> > Hi everyone,
> >
> > I'm currently in the first year of my PhD, and I'm going to be
looking at
> > an experimental IR for my thesis. After looking at a variety of
research
> > compilers I've come to the conclusion that LLVM is the nicest to
work
> > with for my purposes. I was considering writing the code to construct
> > this experimental IR from LLVM assembly, and then at the end of the
> > process (i.e. new optimisations and transformations, etc.) I'll
translate
> > back into LLVM assembly to allow compilation to continue. This keeps
> > everything modular, means I can work with "real" languages
rather than
> > toy ones, and so on.
>
> It seems to me that an easier approach would be to convert in-memory
> LLVM IR to your experimental IR using the LLVM libraries, then do
> whatever you do with your experimental IR, and then convert the code
> back into in-memory LLVM IR for LLVM based optimizations and code
> generation.  The libraries for manipulating LLVM IR are well designed,
> reasonably documented, and seem to me to be easier to work with than
> creating your own LLVM IR parser.
I assume James is only considering reinventing this wheel because he is not 
using C++. LLVM does not play nice with other languages because C++ is quite 
uninteroperable. There are C bindings to LLVM that make it a lot easier but, 
of course, they are far from complete.

So I can fully appreciate the desire to do something like this. However, my 
recommendation would be to augment LLVM with better interop rather than 
reimplement bits of it in other languages. So I would advise James to work on 
a more language agnostic machine-readable format for LLVM's IR (e.g. XML 
based) and contribute code to LLVM that lets it IO in that format as well as 
the current human-readable form.

As we discussed before, something like an autogenerated XML-RPC server to the 
whole of LLVM would be a much better solution offering easy interop with a 
huge variety of languages without having to write and maintain all of these 
bindings.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

Jon -- you're right with your intuition. I also think the XML idea is great,
and something I might look into contributing when I have some more free
time. 

For the time being I'm setting myself up in the /projects directory of the
source, and I'm going to have a play from there.
-- 
View this message in context:
http://www.nabble.com/Rolling-my-own-LLVM-assembly-language-parser-tp22704803p22721255.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.

On Wednesday 25 March 2009 14:16:42 Jon Harrop wrote:
> I assume James is only considering reinventing this wheel because he is
> not using C++. LLVM does not play nice with other languages because C++
> is quite uninteroperable. There are C bindings to LLVM that make it a lot
> easier but, of course, they are far from complete.
>
> So I can fully appreciate the desire to do something like this. However,
> my recommendation would be to augment LLVM with better interop rather
> than reimplement bits of it in other languages. So I would advise James
> to work on a more language agnostic machine-readable format for LLVM's
IR
> (e.g. XML based) and contribute code to LLVM that lets it IO in that
> format as well as the current human-readable form.
For what it's worth, I'm working on creating an LLVM backend for a small
stack machine, and so far it seems a very poor fit for any of LLVM's 
CodeGen backend.

My current approach -- which may change, but is the best I've come up with 
so far -- is to use make an LLVM pass in C++ where I do nothing but spit 
out the module in a target-specific format that I can easily read from 
Python, where the I'm implemented the bulk of my actual backend. I'm
doing
this largely to avoid writing an .ll or .bc parser (which wouldn't be 
terrible, but I'm not sure how stable those formats really are).

-- 
Wesley J. Landaker <wjl at icecavern.net> <xmpp:wjl at
icecavern.net>
OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090326/c874915f/attachment.sig>

Wesley J. Landaker wrote:
> 
> My current approach...
> 
I was just looking at the documentation for writing an LLVM pass, and I
believe this is what I am going to do too. Once I've constructed my new IR,
I'm not completely sure whether I'll keep working "inside"
LLVM, although I
know I'd like to generate LLVM assembly or bitcode at the other end of my
own IR's transformations and optimisations. It's nice to have options
though!
-- 
View this message in context:
http://www.nabble.com/Rolling-my-own-LLVM-assembly-language-parser-tp22704803p22743869.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.