First I'm sorry for my poor English and ambiguous questions.
I'm now trying to create an llvm front-end for new language that defined by me.
More detail, I'm making scanners, parsers, and IR code generators.
I'm now making IR Code generator using LLVM API(C++) such as IRBuilder, Context, Module.. etc
But i recently know that the LLVM API does not support backward compatibility.
Depending on the version, header file paths are different, or some functions and classes are not supported.
So, my question is below:
Which LLVM version is the most popular?
What LLVM version should I use for my project?
I want to make my project as portable.
In the other words, I want to make my project that minimize problems occurs when build my project in other environments.
Now I'm using LLVM 6.0.0svn version. That is result of following this page:
(https://llvm.org/docs/GettingStarted.html)
But i know how to install llvm previous version.
Thank you for reading.
IR building API is more or less stable. As for "popularity", there is no such thing as most popular version. It is up to you, language writers, to choose what version of LLVM to use. Some languages try to closely follow tip-of-head, so they are compatible with fresh releases. Others make switch from time to time, on the need basis. Finally, there are tools like KLEE that try to keep compatibility across different version using #ifdefs, and this turned out to be not very hard.
I would recommend using the latest version as it can be difficult to find documentation for older versions and of course the newer versions provide more features.
Related
I read about tool called "include-what-you-use" which can help clean superfluous includes
from source code. I understood that there is a version for compiler LLVM(clang) and version for GCC.
My questions are:
Why this tool is compiler-dependent and not "cross-platform" for compilers. Why from the beginning the creators of the tool didn't make it compiler-independent? Is it related to the special implementation it has or something like that?
If I want to take a version of the tool compatible for LLVM and I want to make it compatible with GCC (since I'm working with GCC), what do I have to do for that?
For the most part, Include-What-You-Use should be able to handle any valid C++ codebase, regardless of whether that codebase was written with gcc or clang in mind. I recently had the occasion to run Include-What-You-Use on a very large codebase that was usually compiled with gcc and it worked fine. So in that sense it is already compatible.
That said, it might not work perfectly. It's likely that some of the information it provides will be wrong, even if it's a clang codebase. So always verify the output manually.
why this tool is compiler-dependent and not "cross-platform" for compilers. Why from the beginning the creaters of the tool didn't make
it compiler-independent ? is it related to the special implementation
it has or something like that ?
Reason is simple, clang has is more modern fresh and has better modular architecture. As a result is is much easier to create tools using clang modules.
That is why clang was first which had address sanitizer and have more cool sanitizers. And this is why when someone creates new tool for C++ stars from clang.
If i want to take a version of the tool compatible for llvm and i want to make it compatible with gcc(since i'm working with gcc). What
i have to do for that ?
clang was created since Apple was not happy with gcc. So when it was written it supposed to be as much compatible with gcc as possible, since there was lots of code which was verified with gcc.
Since clang is mature now and provides new own features, there might be small differences with gcc (for example different bugs in implementations of new C++ standards), but in most common code there should be no problem.
IWYU should work without problems on both compilers. My coworker used it on large project build with 3 compilers (clang, gcc and VS) and it worked like a charm.
The tool itself needs parts of the compiler! It is sitting somewhere between reading the source and parsing it. LLVM provides an API which is used for the tool. The tool itself is not standalone but a plugin to the clang/llvm. As this, it needs the clang/llvm.
The modifications which will be done by the tool are fully compatible to every c++ compiler. And also the plugin in combination with clang/llvm should be able to parse more or less every code base independent of used other compilers. There might be some strange macros which are supported by other tool chains, which llvm might be struggle with. But that should be a rare case at all.
Does anybody know the difference between Win-builds and MinGW-builds? I'm really interested in C++11 (14) compiler for Windows, but unfortunately MSVC is not yet fully C++11 compliant.
The difference is simple: they have little bit different goals.
In particular, if you want to develop on Windows (i.e. don't need cross-compilation), then you better off with MinGW-builds project which essentially provides several feature-rich variants of the MinGW-w64 toolchain. The table in the link gives good summary of the features I'm talking about. You can basically pick the compiler based on your requirements to addressing model, threading model, exception model. I consider it mature and stable as I use it for everyday work and I'm very satisfied with the quality.
On the other hand, Win-builds project's primary goal seems to be cross-compilation. You'll notice that in their thesis in the link, and you'll also notice that it is less feature-rich than MinGW-builds, hence you have less flexibility with it. It is also relatively new compared to MinGW-builds, so I would expect to potentially experience some issues with it.
NOTE: Please, understand that both of these projects are simply builds (distributed ready-to-use binaries) of the MinGW-w64 toolchain (GCC port for Windows which supports both x86 and x64 targets) on whose web-site both links above are pointing. They are provided only for user convenience, so that we (users) don't have to hassle with compilation of the MinGW-w64 toolchain ourselves, but nobody prevents you from doing that if you're experienced enough and know what you want.
For further reading on related topic and C++11, I would recommend my other answer which you might find interesting.
Good luck.
I'm currently working in a pet programming language (for learning purposes), and have gone through a lot of research over the past year, and I think its time to finally start modelling the concepts of such a languague. First of all I want it to compile to some intermediate form, such as JVM or .NET bytecode, the goal being multiplatform/architecture compatibily. Second, I want it to be fast (I also have many other things in mind, but its not the purpose of this topic to discuss those).
The best options that came to my mind were:
Compile to JVM bytecode and use OpenJDK as runtime environment,
Compile to .NET bytecode and use Mono as runtime environment,
Compile to LLVM IR and use LLVM as runtime environment.
As you may have imagined, I've chosen LLVM. Why? because its blazing fast. I did a little benchmark using the C++ N-Body code, and achieved 7s in my machine with lli jitted IR, in contrast with 27s with clang native compiled code (I know clang first make IR then machine code).
So, here is my question: Is there any redistributable version of the LLVM basic toolset (I just need lli) that I can use? Or I must compile my own? If the latter, can you provide me with any hints on how to do it? If I really must do it, I'm thinking is cross-compiling them from my machine (Intel Mac), and generating some installers (say, an .msi for windows, .rpm and .deb for popular linux distros and .pkg for Macs). Remember, I only need a minimal subset of LLVM, such that this subset is capable of acting like a VM, by using "lli ". The real question here is how to use LLVM as a typical virtual machine.
First, I think all 3 options - LLVM IR + LLVM, Java Bytecode + OpenJDK, and .NET CIL + Mono - are excellent options, and I agree deciding between them is not easy.
If you go for LLVM and you just want to use lli, you can compile LLVM to your target platform and pack the resulting lli executable with your distribution, it should work.
Another way to write a JIT compiler via LLVM is to use an execution engine - see the handy examples in the Kaleidoscope tutorial. That means that you write your own program which will JIT-compile your own language, compile it to whatever platform you want while statically linking it with LLVM, and then distribute it.
In any case, since a JIT compiler requires copying an LLVM binary to the client side, make sure to attach a copyright notice with your distribution (you don't have to open-source your distribution, though).
The clang 3.0 online demo page http://llvm.org/demo/index.cgi provides an option to output LLVM C++ API code" representing the LLVM-IR for the input program.
Is "produce LLVM C++ API code" output a clang option (and if so, what is it)?
Or is it an llvm tool option (which one)?
Is it possible to do the same thing but from LLVM-IR input? Basically I'd like to see the proper llvm c++ api calls needed to produce a particular given llvm-ir sequence. I'd like to learn backwards by example rather than forwards from the documentation.
Manual pages and --help and --help-hidden for clang, llvm-as and llvm-dis don't show anything obvious.
edit: OK now I see in the output on that web page, "generated by llvm2cpp". But I can't find that tool in recent llvm releases, only old releases, has a new tool in 2.9 and 3.0 taken over for llvm2cpp?
Yes. C++ backend is the tool which does this. Try "llc -march=cpp foo.bc"
I ran into exactly the same problem and saw the CPPBuilder mentioned a couple of times. This approach unfortunately no longer works on recent LLVM versions as the CPPBackend was removed between 3.8 and 3.9.
If you want the CPP backend you (i) have to configure llvm and add cppbackend to -DLLVM_TARGETS_TO_BUILD during the initial configure and (ii) run an llvm <= 3.8.
The feature was removed because it did not use IRBuilder and almost nobody used it. My solution was to rely on the old version to get inspired, then implement it myself.
I have a question concerning the LLVM compiler:
I would like to use it to compile my Objective-C source code for Mac and iOS and from their release notes it seems that LLVM is stable enough for using this.
Having made good experiences with the LLVM I would also like to use it to compile C++ or Objective-C++. However it is not clear to me if I should still use the hybrid LLVM-GCC compiler (the GCC parser and the LLVM code generator) or the pure LLVM compiler.
I am also unsure about the new C++ standard library and if I should use it and how I would make the transition from GNU's libstdc++.
The Questions
Which compiler would one use today to generate fast production quality code from C++: the LLVM-GCC hybrid compiler or pure LLVM?
Should one migrate the C++ standard library from GNU's libstdc++ to the new libc++ library created by the LLVM project?
Any comments and hints are appreciated.
Several questions asked here, I'll try to answer all of them.
There is no "pure LLVM compiler". LLVM is a set of libraries which do code optimization and code generation . There are several C/C++ frontends which can be hooked to LLVM. Among them are clang and llvm-gcc. See http://llvm.org/ for more information about various components of LLVM Compiler Infrastructure. As written at http://llvm.org/docs/ReleaseNotes.html, llvm-gcc is EOL since LLVM 2.9 release, so you'd better use clang, because it will certainly be developed and maintained in the future.
libc++ is still in development, so for production you should use vendor-provided C++ (libstdc++ in your case).
Remember, all this stuff is changing, so benchmarks gets easily outdated.
I've found following report interesting, not only as a kind of benchmark, but it seems showing some LLVM vs GCC compiler differences :
Clang/LLVM Maturity Evaluation Report by Dominic Fandrey