As I know, GCC has this website to figure out the relationship between different flags using while optimization. GCC example website. Like fpartialInlining can only be useful when findirectInlining is turned on.
I think the same thing would happen in clang, in other words, I think the different passes may have this kind of dependcy/confilcts relationship in LLVM(CLANG).
But after checking all the document provided by developers, I find it just say something about the functionality in these passes. LLVM PASS DOC
So my question can be divided into 2 parts I think:
Does the dependency exists in LLVM PASS or there is no such dependency/conflicts
If there is, how can I find them.
You can find which passes are using in which optimization levels by clang while compiling any c or c++ code with clang and try to figure out dependencies. For example:
clang -O2 --target=riscv32 -mllvm -debug-pass=Structure example.c
(You can use also -debug-pass=Arguments instead of -debug-pass=Structure. It depends readability.)
this will give which passes used by clang at 2. optimization level for riscv32 target. If you don't give a target it sets default as your host machine target, and keep in mind that some used passes changes related to different targets at same optimization levels.
Related
I am trying to get LLVM IR for a file which is linked with some static libararies.
I tried to link using llvm-link . It just copy the .bc files in one file ( not like native linking).
clang -L$(T_LIB_PATH) -lpthread -emit-llvm gives an error: emit-llvm can not be used with linking. When passing -c option, it gives warning that the linking options were not used.
My main goal is to get .bc file with all resolved symbols and references. How can I achieve that with clang version 3.4.?
You may have a look at wllvm. It is a wrapper on the compiler, which enable to build a project and extract the LLVM bitcode of the whole program.
You need to use wllvm and wllvm++ for C and C++, respectively (after setting some environment variables).
Some symbols come from source code via LLVM IR. IR is short for intermediate representation. Those symbols are easy to handle, just stop in the middle of the build process.
Some others come from a library and probably were generated by some other compiler, one that never makes any IR, and in any case the compiler was run by some other people at some other location. You can't go back in time and make those people build IR for you, even if their compiler has the right options. All you can do is obtain the source code for the libraries and build your entire application from source.
I'd like to convert a CMake-based C++ library to bazel.
As part of the current CMake project, I'm using a libclang-based code generator that parses C++ headers and generates C++ code from the parsed AST. In order to do that, I need the actual compiler flags used to build the cc_library the header is part of. The flags are passed to the code generation tool so it can use clang's preprocessor.
Is there any way I could access the compiler flags used to build a dependency from a skylark- or gen_rule rule? I'm particularly interested in the include paths and defines.
We're working on it. Well, not right now, but will soon. You might want to subscribe to the corresponding issue, and maybe describe your requirements there so we take them into account when designing the API.
I'm using Clang 3.8 to compile one file that comes from a different source in a project. This is a temporary crutch, as this file is an addition to a library that I also use, and the code it has will be part of that library's next release. However, these people develop with less stringent warning flags than I do.
I'm not interested in these warnings as they're benign, I don't maintain that file, and it'll go away within a few months. Of course, I can selectively remove a warning or two, but I think that it makes more sense in this case to disable all and every warnings that it generates because I could change the warning settings of my project later and more occurrences could come out of it.
I've tried #pragma clang diagnostic ignored "-Weverything", but Clang warns that -Weverything is an unknown warning group.
How can I ask Clang to not generate any warnings for that file?
Indeed, the "-Weverything" is not a group of warnings, but just a special option passed to the compiler. Here is code that handles this case: lib/Basic/Warnings.cpp:118
You still can compile your problematic source file using slightly different rules/flags as you use for others sources:
clang -Wno-everything foo.c
However, I'd recommend to disable each warning explicitly using #pragma.
In case you disable all warnings, and then upgrade your compiler, then you may miss some new warnings, which could be important (e.g. undefined behaviour checks, security checks, etc).
Also, imagine what happens if the file is not gone after three months, but stays in the project forever.
If you need your compiler flags to be consistent between GCC and Clang, they both have the -w flag:
$ clang --help | grep -i suppress
-w Suppress all warnings
I've been trying to make the switch to LLVM, since I'd like to get more into the whole 'software-dev' scene, and it seems like right now, LLVM is the future. I built LLVM/Clang/LLD/compiler-rt/libcxx from source several times now, both with GNU/GCC and LLVM/Clang.
The problem appears when I try to use the newly compiled compilers. From what I can see, clang is using GNU ld rather than LLVM's lld. Is this true?
LLD seems to be a very limited program from the lld -help output, but from what I have read, it is as full featured as ld. I cannot find documentation on how to use it anywhere -- does anyone know where I can find some kind of comprehensive manual on it?
Thank you.
Pass -fuse-ld=lld to clang to make it use lld for linking. By now, it's in very good shape.
You can pass -v or -### to clang to make it print which linker command it runs or would run.
There's no manual for the moment and depending on platform may work well enough for you. That said, if lld were "production ready" we'd have switched clang to using it by default for the various platforms. It's not there yet so I wouldn't suggest you use it for your day to day development.
The LLVM team say that is production ready because FreeBSD can compile and link a lot of things with LLD.
The documentation on the LLD project can be found on http://lld.llvm.org/.
It's written :
LLD is a drop-in replacement for the GNU linkers.
That accepts the same command line arguments and linker scripts as GNU.
So you can use same arguments than GNU LD.
I know this question is old, but there is a newer solution to it:
To use the ld.lld linker when building any llvm target, just pass -DLLVM_ENABLE_LLD=ON in the commandline to cmake.
//Use lld as C and C++ linker.
LLVM_ENABLE_LLD:BOOL=TRUE
For other cmake projects, pass: -DCMAKE_LINKER=/etc/bin/ld.lld
I have a ModulePass that's working with the opt tool, but I'm having trouble figuring out how to make it available to clang at the command line. My current workflow for using my pass is:
clang -c -emit-llvm [c-source code files]
llvm-link [llvm bitcode files]
opt -load [PassName].so -[pass-name] [linked llvm file]
llc [resulting bitcode file]
gcc [resulting assembler file] -o [target]
I would like to get my pass integrated with the clang command line so that it could be invoked as part of the build of existing software (e.g. c++ standard library) without having to remake the whole build system for each thing I compile. I've seen hints about how to do this, but I haven't been able to put the pieces together into a working setup.
Run an LLVM Pass Automatically with Clang describes exactly what I want, but the method appears to be deprecated in LLVM 3.4 (PassManagerBuilder has been moved to the legacy namespace).
LLVM - Run Own Pass automatically with clang seems to address the basic issue, but I was hoping I could do this without having to modify clang (which seems to be what's suggested there).
What is the best way to make a new pass available from clang using LLVM 3.4?
Clang still uses PassManagerBuilder as of 3.5 (see the PassManagerBuilderWrapper class in BackendUtil.cpp). So I believe extending it with RegisterStandardPasses, as in my blog post, is still the only way to add a pass to Clang's pass manager.
It's frustratingly difficult to find any information about how deprecated the "old" pass manager infrastructure is. But since Clang is still using it, it can't be that deprecated. :)