Initial support for LLVM > 4.0 #66
Conversation
| IntegerType::get(context, 32), | ||
| NULL)); | ||
| IntegerType::get(context, 32))); | ||
| #else |
There was a problem hiding this comment.
I wonder if we could do something like:
#if LLVM_VERSION_MAJOR > 4
#define getOrInsertFunction(M, a, b, c, d, e) \
M->getOrInsertFunction(a,b,c,d,e,0)
#else
#define getOrInsertFunction(M, a, b, c, d, e) \
M->getOrInsertFunction(a,b,c,d,e)
#endif
?
There was a problem hiding this comment.
I've been thinking about this too. I wasn't certain if this solution would actually lead to cleaner code or if all these macros cluttering the code would be detrimental for code clarity in the long run.
If you prefer the macro solution, I can of course change it :)
There was a problem hiding this comment.
A solution not involving macros, but that also reduces code duplication would be of course nicer. I guess we might be able to make this macro into a standard function in fact?
There was a problem hiding this comment.
Yes, something like that might work (not yet tested):
template<typename... ArgsTy>
Constant *getOrInsertFunction(Module* m, StringRef Name, Type *RetTy, ArgsTy... Args) {
#if LLVM_VERSION_MAJOR > 4
return m->getOrInsertFunction(Name, RetTy, Args...);
#else
return m->getOrInsertFunction(Name, RetTy, Args..., NULL);
#endif
}Type-safe and no macro magic :) I'll implement/test that tomorrow.
|
Awesome. Thank you! :) |
These changes allow coriander to be compiled with LLVM > 4.0. (I have tested with LLVM 6.0). The changes are backwards compatible to LLVM 4.0.
This also fixes issue #55 on all systems where LLVM is newer than 4.0 since it allows compiling coriander against the LLVM installed on the system. This then avoids the LLVM version mismatch.
At the moment, there is still a small caveat: When compiling coriander programs, clang 4.0 must still be used, otherwise weird standard library errors related to clang's cuda support start appearing. I don't know how to fix these at the moment.