LLVM 3.6 not supported

[xieyuheng]

~/lang/dale/build master make [ 1%] Building CXX object CMakeFiles/dalec.dir/src/dale/Introspection/Introspection.cpp.o In file included from /home/xyh/lang/dale/src/dale/Introspection/Introspection.h:5:0, from /home/xyh/lang/dale/src/dale/Introspection/Introspection.cpp:1: /home/xyh/lang/dale/src/dale/Introspection/../MacroProcessor/MacroProcessor.h:7:38: fatal error: llvm/ExecutionEngine/JIT.h: No such file or directory

include "llvm/ExecutionEngine/JIT.h"

                                  ^

compilation terminated. CMakeFiles/dalec.dir/build.make:77: recipe for target 'CMakeFiles/dalec.dir/src/dale/Introspection/Introspection.cpp.o' failed make[2]: * [CMakeFiles/dalec.dir/src/dale/Introspection/Introspection.cpp.o] Error 1 CMakeFiles/Makefile2:834: recipe for target 'CMakeFiles/dalec.dir/all' failed make[1]: * [CMakeFiles/dalec.dir/all] Error 2 Makefile:116: recipe for target 'all' failed make: *\ [all] Error 2

2 ~/lang/dale/build master

[tomhrr]

Thanks for the report. There's no support for LLVM 3.6 at the moment, but it's now on the to-do list. Changing to MCJIT looks like the most time-consuming part of that process.

[oubiwann]

Yeah, I ran into this one too. Had to uninstall LLVM 3.6 and use 3.5 instead. Looks like more than a few people are upset for JIT being dropped from 3.6.

[BitPuffin]

Well seems like LLVM 4.0 is out. "Can't" get Dale building on osx anymore because I can't install llvm older than 3.7 easily :\ with homebrew

EDIT: Well, I downloaded and compiled 3.5.2. But even that doesn't work anymore. I get this

[ 78%] Generating libcstdio.so
Assertion failed: (Ty->isPointerTy() && "Illegal argument for getIndexedOffset()"), function getIndexedOffset, file DataLayout.cpp, line 733.
m

[BitPuffin]

Ah found a comment in the code where this fails that says that 3.5.2 doesn't work :P I will try 3.5.1

[BitPuffin]

Hmm, now I have progressively worked my way back to 3.4.2 and the same error still happens :|

[tomhrr]

A brief recap:

• When last checked, moving to MCJIT looked to involve significant reworking of the compiler internals.
• The obvious alternative is to switch to the Interpreter. Some work has been done in that direction, such as having macros use an array of optional arguments, rather than varargs (which are supported by the classic JIT, but not supported by the Interpreter).
• There's still a fair bit of work to do to fully support the Interpreter. Unsurprisingly, most of this is due to the compiler depending on JIT-specific behaviour. Among other things:
  • functions using bool do not appear to work;
  • stack-allocated structs within macros don't work;
  • macros need to be merged into the current module, rather than relying on dynamic linking to resolve them; and
  • there are parts of the code that load LLVM modules more than once, which affects the previous part.

[tomhrr]

LLVM through to version 6 is now supported. The JIT changes were the biggest part here, but they were much simpler than anticipated. There was no need in the end to switch to using the Interpreter, fortunately.

In LLVM 3.6, the execution engine takes ownership of any LLVM module passed into it, whereas in 3.5 it is possible to pass in a pointer to a module and still make changes to it in other code. In Dale, a module is passed to the engine on creation, and the compiler adds macros to the module after that and calls those macros via the engine. It appeared that adjusting for 3.6 would involve restructuring things such that macro evaluation was deferred until after non-macro evaluation, but there was a much simpler solution: clone the module and add it to the engine whenever a macro evaluation (or similar process) needs to occur. This is not as inefficient as it sounds, since it's only necessary when the macro is defined within the module/unit that's evaluating a call to that macro: when the macro has been compiled separately, it's possible to rely on dynamic linking instead.

After 3.6 was supported, the changes to support the later versions were trivial, for the most part. The number of repeated ifdefs is pretty unpleasant, though, and the code will need to be refactored at some point