Comments on: LLVM 3.1, Haskell 7.4.1, and OS X

By: Joshua Moerman

Joshua Moerman — Tue, 30 Apr 2013 10:15:25 +0000

My default compiler for c++ is clang++, but g++ also works fine.

I compiled llvm/clang with clang++, I used this new clang to compile llvm-base, maybe there is the problem. Because for using the new clang, I also needed the libc++ (there where some errors, which were only found by the newer compiler). Maybe I should compile llvm-base with g++…

By: Michael Greenberg

Michael Greenberg — Mon, 29 Apr 2013 12:48:42 +0000

In reply to Joshua Moerman. Have you successfully compiled other C++ code on your machine? It looks like g++ is having trouble finding the STL, so I think you may need to install the Xcode command line tools. Just a guess, though...

By: Joshua Moerman

Joshua Moerman — Mon, 29 Apr 2013 10:00:09 +0000

Thanks for post. I tried this with LLVM 3.3 on OS X 10.7.5 with GHC 7.4.2, but didn’t succeed :(. It succesfully finds LLVMModuleCreateWithName, so installing llvm-base and llvm was no problem. However when I try to compile Hello.hs, I get a lot of linker errors: http://pastebin.com/PrBdp6xA.

I guess I’ll try LLVM 3.1, hopefully it is not a problem in GHC/OSX 10.7…

By: Michael Greenberg

Michael Greenberg — Fri, 12 Apr 2013 18:53:00 +0000

I think pre tags should work. I'm not surprised that blog entry's code doesn't work: it's 4 years old. I'm not sure what's wrong with it. I remember having some trouble with createStringNul---I use withStringNul. That, the unnamed function, and the missing ignore on the call are the only differences I can see with my code. Maybe start with mine and translate into theirs? In general, my code uses the FFI bindings as much as possible: the library isn't completely finished, so not everything hangs together, and things are often brittle. Frankly, the typeclasses just get in the way---and are a huge negative when you're writing a compiler. To make LLVM calls that meet the GADT constraints, your IR has to be at least as constrained: no thanks.

By: Jonathan Gallagher

Jonathan Gallagher — Fri, 12 Apr 2013 18:44:19 +0000

I copied the code literally from http://augustss.blogspot.ca/2009/01/llvm-llvm-low-level-virtual-machine-is.html
I tried formatting in this textbox, but it didn’t work. I’ll try again.

bldGreet :: CodeGenModule (Function (IO ()))
bldGreet = do
puts IO Word32)
greetz <- createStringNul "Hello, World!"
func <- createFunction ExternalLinkage $ do
tmp <- getElementPtr0 greetz (0::Word32, ())
call puts tmp — Throw away return value.
ret ()
return func

The error message is
"Ambiguous type variable n0' in the constraint: (type-level-0.2.4:Data.TypeLevel.Num.Sets.NatI n0) arising from a use ofgetElementPtr0' Probable fix: add a type signature that fixes these type variable(s)"

If you can help at all — I will be very grateful. The documentation for the Haskell binding is not quite there, so I am really struggling through this.

By: Michael Greenberg

Michael Greenberg — Fri, 12 Apr 2013 18:20:51 +0000

No idea without the error message. The code as pasted isn't correctly formatted: there's a stray paren at the end of your puts call. The typeclasses in the Haskell binding for GEP calls may be funny---you may have more luck with getElementPtr0. You may need a thunk after your call to createFunction.

By: Jonathan Gallagher

Jonathan Gallagher — Fri, 12 Apr 2013 18:15:16 +0000

Thank you for the reply. Do you by chance know why the example

bldGreet :: CodeGenModule (Function (IO ()))
bldGreet = do
puts IO Word32)
greetz <- createStringNul "Hello, World!"
func <- createFunction ExternalLinkage $ do
tmp <- getElementPtr greetz (0::Word32, (0::Word32, ()))
call puts tmp — Throw away return value.
ret ()
return func

from the blog does not work/ what the ambiguity is?

By: Jonathan Gallagher

Jonathan Gallagher — Fri, 12 Apr 2013 13:42:02 +0000

Ahh. I figured it out mostly. LLVM has an associated LLVM-Base — one of the modules is called FFI.Core, and this defines addFunction — which uses Haskell’s FFI to pull in a C function by name. When you call newNamedFunction, the default is to assume that the name of the function corresponds to a C function which is on the FFI interface. Unless the definition is redirected through e.g. defineFunction, this is what will happen. So if you give it nonsense, you will get a runtime error on lli. I guess this leaves as a question what possible functions are available through the FFI, and so on.

By: Michael Greenberg

Michael Greenberg — Fri, 12 Apr 2013 13:33:56 +0000

So puts, in this example, is going to have its definition filled in by the linker because it’s part of standard libc. I haven’t tried this experiment, but I wouldn’t be surprised if changing the linkage type to PrivateLinkage broke the program.

I haven’t played around with linking in extra things when building programs with LLVM, but I’m pretty sure the way to do it is with llvm-ld.

By: Jonathan Gallagher

Jonathan Gallagher — Fri, 12 Apr 2013 13:26:30 +0000

Hello — nice post. I don’t understand how newNamedFunction works. So on one hand I do “understand” it works when it is followed by definedFunction. That makes sense to me. But when you don’t define it, my guess it that it is looked up from somewhere. Do you know where? Is there a list of functions that can be used, or can I write a config file and specify the function and where to find it?