Hi, all
I'd like to write a code that can build different codes based on LLVM version.
Like code snippets in the below.
#ifdef __LLVM_29__
PHINode *PN = Builder.CreatePHI (Type::getDoubleTy(getGlobalContext()), 2, "iftmp");
#elif __LLVM_28__
PHINode *PN = Builder.CreatePHI (Type::getDoubleTy(getGlobalContext()), "iftmp");
#else
assert ("wrong version");
#endif
I've been trying to find something like these (__LLVM_29__, __LLVM_28__), but I couldn't find them yet.
Thanks for your help.
Regard, Kangkook
Kangkook Jee <aixer77@gmail.com > writes:
Hi, all
I'd like to write a code that can build different codes based on LLVM version.
Like code snippets in the below.
#ifdef __LLVM_29__
PHINode *PN = Builder.CreatePHI (Type::getDoubleTy(getGlobalContext()), 2, "iftmp");
#elif __LLVM_28__
PHINode *PN = Builder.CreatePHI (Type::getDoubleTy(getGlobalContext()), "iftmp");
#else
assert ("wrong version");
#endif
I've been trying to find something like these (__LLVM_29__,
__LLVM_28__), but I couldn't find them yet.
llvm/Config/config.h defines PACKAGE_VERSION to a string like "3.0", but
I'm afraid that it is not very convenient for your purposes.
To the developers: maybe it is a good idea to define something like
LLVM_MAJOR_VERSION and LLVM_MINOR_VERSION ? Preferably in llvm-config.h
Hi Óscar,
To the developers: maybe it is a good idea to define something like
LLVM_MAJOR_VERSION and LLVM_MINOR_VERSION ? Preferably in llvm-config.h
probably it's best to just go ahead and implement this (with PACKAGE_VERSION
being auto-computed from these) and see if anyone objects
Ciao, Duncan.
Yuri
May 31, 2011, 8:29pm
#4
But this only works for C++ apps compiled with headers.
It's better to implement version to be returned through the API exported from libLLVM.so
Yuri
Yuri
June 3, 2011, 12:19am
#6
I am attaching the patch for the version to be exported through the API.
Yuri
patch.txt (1.39 KB)
Yuri
June 3, 2011, 12:42am
#7
Sorry, disregard the previous patch.
Correct patch is attached.
Yuri
patch.txt (1.64 KB)
A minor point: Make that function parameter an enum instead of a boolean. That would make it possible to extend the function so it returns other information without potentially breaking client code (which might pass in 1 or -1 or something entirely different to get repository information).
Just my 2c.
Regards,
Jo
Also, boolean parameters are bad for writing self-documenting code; compare
LLVMGetVersion(REPOSITORY_VERSION);
versus
LLVMGetVersion(true);
(in the second case, reading the caller code is not enough to
understand the intent).
See also
http://www.jroller.com/alexRuiz/entry/boolean_arguments_can_be_evil
http://blogs.msdn.com/b/oldnewthing/archive/2006/08/28/728349.aspx
Csaba
Yuri
June 3, 2011, 7:04pm
#10
Following the suggestions of Joachim Durchholz and Csaba Raduly, I submit the updated patch.
Yuri
patch.txt (1.8 KB)
Yuri
June 29, 2011, 9:04pm
#11
Could somebody check in this patch? I think it got lost in mailing lists llvmdev@ and llvm-commits@ and forgotten about.
Thank you,
Yuri
patch.txt (1.8 KB)