Port Pure to the MCJIT in order to support LLVM 3.6+

Create issue
Issue #36 new
David Slate created an issue

I just downloaded and extracted the pre-built binaries for Ubuntu 14.04 of the new version of llvm: clang+llvm-3.6.0-x86_64-linux-gnu-ubuntu-14.04.tar.xz, and tried to rebuild pure-0.64. Unfortunately it looks like once again a new version of llvm has broken pure:

g++ -g -O2 -std=gnu++11 -g0 -O3 -DNDEBUG -DDEBUG=0 -I/home/david/llvm/clang+llvm-3.6.0-x86_64-linux-gnu/include -D_GNU_SOURCE -DSTDC_CONSTANT_MACROS -DSTDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -pthread -I. -I. -DPURELIB='"/usr/local/lib/pure"' -c -o pure.o pure.cc In file included from pure.cc:28:0: interpreter.hh:23:38: fatal error: llvm/ExecutionEngine/JIT.h: No such file or directory #include <llvm/ExecutionEngine/JIT.h>

It appears that the file ExecutionEngine/JIT.h disappeared between llvm-3.5.0 and llvm-3.6.0. There is still a file MCJIT.h but no JIT.h.

Comments (7)

  1. Wolfgang Brehm

    I have the same issue (llvm 3.8) and read somewhere else that it might not be that hard to port from JIT.h to MCJIT.h , maybe I will give it a try.

  2. Albert Graef

    That would be much appreciated!

    The problem are the dynamic features of the Pure language, which allow a global function definition to be refined at any time. Last time I looked, MCJIT didn't allow to recompile individual functions on the fly, only modules. If it is still that way, it will require a substantial rewrite of the compiler backend (basically, every global Pure function will have to go into its own module and these will then have to be linked together; right now the entire Pure program is just a single LLVM module).

    But don't let this discourage you; maybe MCJIT's internal workings have changed. In any case the port should be doable, just don't expect it to be a walk in the park. :)

  3. Albert Graef

    Yes, that was exactly the same kind of problem, and luckily they were able to solve it, so I have hopes for Pure as well. But it seems that it wasn't exactly a walk in the park for the Julia devs either. :) And Pure is still more extreme in that any global function must be hot-swappable at any time...

    As an aside, it would be cool to have an LLVM bitcode interface to Julia. I've thought about that ever since Julia appeared on the scene.

  4. Wolfgang Brehm

    As there is as you say a requirement that "any global function must be hot-swappable at any time" LLVM StackMaps is probably the way to go when sticking to LLVM. GNU Lightning would be an option as well. I don't know of the self modifying capabilities of julia if there are any, the runtime would certainly be capable to execute it.

  5. Log in to comment