llvm dev - Sep 2010 - [LLVMdev] Any experiemnts/evaluations on LLVM and graph rewriting (term-rewriting) systems?

Hi,

are there any attempts to use LLVM in graph-rewriting (term-rewriting)
language implementations?

How good is LLVM for this?

E.g., is it natural to expect that the LLVM-based implementation of the
language Concurrent Clean be any faster than its reference implementation?

Best regards
--
Valery A.Khamenya
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100913/a45df2ae/attachment.html>

Valery Khamenya wrote:
> are there any attempts to use LLVM in graph-rewriting (term-rewriting)
> language implementations?
Pure is a dynamically typed FPL based on term rewriting:

http://pure-lang.googlecode.com/

It uses the LLVM JIT to compile and execute code on the fly in an
interpreter-like environment, and can also batch-compile code to native
executables. This includes the deterministic (non-backtracking) tree
matching automata needed to implement general term rewriting in an
efficient manner.
> How good is LLVM for this?
There haven't been any other implementations of Pure compilers so that I
can't give you a real comparison. What I can say with confidence is that
LLVM made developing a code generator for Pure very convenient, because
of the readily available optimization passes, cross-platform support and
the integrated JIT.
> E.g., is it natural to expect that the LLVM-based implementation of the
> language Concurrent Clean be any faster than its reference implementation?
You should probably get in touch with David Terei. His LLVM ghc backend
seems to be doing fairly well:
http://donsbot.wordpress.com/2010/02/21/smoking-fast-haskell-code-using-ghcs-new-llvm-codegen/

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Hallo Albert,

thanks!

best regards
--
Valery A.Khamenya


On Tue, Sep 14, 2010 at 9:32 AM, Albert Graef <Dr.Graef at t-online.de>
wrote:
> Valery Khamenya wrote:
> > are there any attempts to use LLVM in graph-rewriting (term-rewriting)
> > language implementations?
>
> Pure is a dynamically typed FPL based on term rewriting:
>
> http://pure-lang.googlecode.com/
>
> It uses the LLVM JIT to compile and execute code on the fly in an
> interpreter-like environment, and can also batch-compile code to native
> executables. This includes the deterministic (non-backtracking) tree
> matching automata needed to implement general term rewriting in an
> efficient manner.
>
> > How good is LLVM for this?
>
> There haven't been any other implementations of Pure compilers so that
I
> can't give you a real comparison. What I can say with confidence is
that
> LLVM made developing a code generator for Pure very convenient, because
> of the readily available optimization passes, cross-platform support and
> the integrated JIT.
>
> > E.g., is it natural to expect that the LLVM-based implementation of
the
> > language Concurrent Clean be any faster than its reference
> implementation?
>
> You should probably get in touch with David Terei. His LLVM ghc backend
> seems to be doing fairly well:
>
>
http://donsbot.wordpress.com/2010/02/21/smoking-fast-haskell-code-using-ghcs-new-llvm-codegen/
>
> Albert
>
> --
> Dr. Albert Gr"af
> Dept. of Music-Informatics, University of Mainz, Germany
> Email:  Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de
> WWW:    http://www.musikinformatik.uni-mainz.de/ag
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100914/9465d058/attachment.html>

Hi Valery

On 13 September 2010 19:07, Valery Khamenya <khamenya at gmail.com>
wrote:
> are there any attempts to use LLVM in graph-rewriting (term-rewriting)
> language implementations?
I've added a new LLVM backend to the ghc Haskell compiler.
> How good is LLVM for this?
Works very well. I'm operating from the low levels of the ghc compiler
though where I don't need to deal with the complexity of compiling a
functional language. The input to my backend is an intermediate
language called 'Cmm' that basically a lower level C like language.

I've written a new paper about my experiences using LLVM with my
supervisor, Manuel Chakravarty that I'll be presenting in a few weeks
at the Haskell Symposium. You can grab it here:
http://www.cse.unsw.edu.au/~davidt/papers.html

Cheers,
David

Hi David,

interesting paper (I used the direct address
http://www.cse.unsw.edu.au/~davidt/downloads/ghc-llvm-hs10.pdf )

I like LLVM and enjoyed a lot playing with Concurrent Clean.
So, I hope developers of Concurrent Clean will be interested in merging of
both things.

best regards
--
Valery A.Khamenya


On Tue, Sep 14, 2010 at 3:44 PM, David Terei <davidterei at gmail.com>
wrote:
> Hi Valery
>
> On 13 September 2010 19:07, Valery Khamenya <khamenya at gmail.com>
wrote:
> > are there any attempts to use LLVM in graph-rewriting (term-rewriting)
> > language implementations?
>
> I've added a new LLVM backend to the ghc Haskell compiler.
>
> > How good is LLVM for this?
>
> Works very well. I'm operating from the low levels of the ghc compiler
> though where I don't need to deal with the complexity of compiling a
> functional language. The input to my backend is an intermediate
> language called 'Cmm' that basically a lower level C like language.
>
> I've written a new paper about my experiences using LLVM with my
> supervisor, Manuel Chakravarty that I'll be presenting in a few weeks
> at the Haskell Symposium. You can grab it here:
> http://www.cse.unsw.edu.au/~davidt/papers.html
>
> Cheers,
> David
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100914/3e0148d8/attachment.html>