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.
Related
LLVM used to provide llc -march=cpp test.ll -o test.cpp instruction to learn C++ API, but this is not available in llvm 12.
Unfortunately, there is no alternative. The reason why C++ backend was removed long time ago is quite simple: it did not serve its main intention to be a guide to LLVM C++ API well, it generated suboptimal code and was not updated to support the latest changes to C++ API.
You can use the code of existing transformation passes to learn LLVM C++ API
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.
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.
I'm trying to write a plugin to clang or gcc to interpret custom [[cxx11::attributes]] and generate some code based on that.
Since version 4.5, gcc supports plugins that can be hooked at almost every compilation steps. However, I think gcc is not very clear about how modify its AST and navigate through it (at least I'm having a bad time trying...).
Then I remembered that clang was designed to be extended and used as a library and I gave it a shot. After digging around I found some topics saying clang does not support custom attributes. I cried.
My main goal is to generate code based on any kind of annotations that user can use at code. I'd like to use c++11 attributes because they are very clear. Pragmas are also an option but they have some limitations.
Here are the questions:
1) Is it really (currently) impossible to have custom attributes in clang?
2) What is the best way to learn gcc internals? (I read lots of pages of documentation but still they didn't say what I want)
3) Does gcc have some dump function to print its AST like clang does? It would help a lot to explore its tree.
Thank you! Any information/tip would be appreciated!
GCC plugins are specific to GCC, and even (in principle) to a particular version of GCC (there is no guarantee that a plugin coded for GCC 4.8 would work on GCC 4.9).
You might consider extending GCC with MELT, which is a lispy domain specific language to extend GCC, implemented as a GCC (meta-) plugin.
However, you need to understand the internal representations of GCC (Gimple, Trees, the pass manager, ...). Read first my slides on GCC plugins thru the MELT example (Linux Collaboration Summit, march 2014)
You can easily add GCC attributes with plugins and with MELT, and probably also C++11 attributes.
And yes, GCC has a lot of possible dumps (try using -fdump-tree-all).
You'll better use recent versions of GCC (e.g. 4.9.1) and of MELT (e.g. 1.1.2 or later; I'll probably release MELT 1.1.3 within a week or two)
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