LLVM backend to Omega

[GoogleCodeExporter]

http://llvm.org is a modular optimization and code generation project.

This issue request an LLVM emitter for Omega.

An intermediate step could be compilation of "Code _" to llvm assembly
files (.ll)

The full functionality would be the output of LLVM bitcode files (.bc)

Original issue reported on code.google.com by ggr...@gmail.com on 17 Jul 2007 at 10:05

[GoogleCodeExporter]

Started implementation of converting
Code a
valued expressions to LLVM assembly.
This is what I can do at the moment:

prompt> gener [|2 - 3 > (div 6 2)|]
" %x4670 = sub i32 2 i32 3
 %x4671 = div i32 6 i32 2
 %x1 = icmp gt i32 %x4670 i32 %x4671
 return i1 %x1
" : [Char]

I am using a Thrist mechanism to represent LLVM basic blocks.

The sources are in a private repository a.t.m. and will be
published when useful.

Original comment by ggr...@gmail.com on 7 Nov 2007 at 2:10

• Changed state: Started

[GoogleCodeExporter]

of course, gener is not a pure function, and thus should live in the IO monad.

alternatively it could be a command-line interface command (like :type or :kind)

Original comment by ggr...@gmail.com on 13 Nov 2007 at 10:40

[GoogleCodeExporter]

of course, gener is not a pure function, and thus should live in the IO monad.

alternatively it could be a command-line interface command (like :type or :kind)

Original comment by ggr...@gmail.com on 13 Nov 2007 at 10:41

[GoogleCodeExporter]

there is now some *very* preliminary stuff checked in on branches/llvm-gen

Original comment by ggr...@gmail.com on 22 Dec 2007 at 6:47

[GoogleCodeExporter]

Okay, I have something that more-or-less transforms simple expressions to LLVM
assembly, but there is a gaping hole when trying to compile polymorphism.

My recent idea is that a type inference pass could be run on the Exp data (as 
opposed
to the AST) to infer "representation types" (which have some better 
relationship to
LLVM types). To this end FIO and Exp must be given the appropriate Typable 
interface.

The presence of literal data in pattern matches would constrain the inference 
process.

I did not think about it much.

In any case (ab)using the omega type inferrer to also find appropriate LLVM 
types
would probably be unmaintainable and ugly.

Original comment by ggr...@gmail.com on 1 Jul 2008 at 11:44

[GoogleCodeExporter]

the steps to be taken atm. are:

1) resync the branch with the trunk
2) prototype an inference engine
3) satisfy the needed interfaces
4) finish the type inferencer
5) finish LLVM gen

Original comment by ggr...@gmail.com on 1 Jul 2008 at 11:48

[GoogleCodeExporter]

step 1) done as of r160

Original comment by ggr...@gmail.com on 2 Jul 2008 at 9:35