For OpenMP, when my code is using the functions in its API (for example, omp_get_thread_num()) without using its directives (such as those #pragma omp ...),
why directly specifying libgomp.a to
gcc instead of using -fopenmp
doesn't work, such as
gcc hello.c /usr/lib/gcc/i686-linux-gnu/4.4/libgomp.a -o hello
Update: I just found that linking to libgomp.a does not work, but linking to libgomp.so works. Does it mean OpenMP can not be static linked?
Why -fopenmp only works without
specifying the library files
gcc hello.c -fopenmp -o hello
Update: In other words, when using -fopenmp, why explicit linking to libgomp.so is not required?
Why does this also compile:
gcc hello.c -L/usr/lib/gcc/i686-linux-gnu/4.4/ -lgomp -o hello
Will this ignore OpenMP directives
in the code if there is any?
Thanks and regards!
In general, keep in mind that the directives and the functions are different things; the former are controlled by -fopenmp and the latter are controlled by linking to the OpenMP library.
(Updated to incorporate comments) Try using the -fopenmp and -static options to statically link OpenMP. Because this implies -lgomp -lrt, the following command won't compile correctly unless you also specify the location of librt.a.
gcc hello.c /usr/lib/gcc/i686-linux-gnu/4.4/libgomp.a -o hello
(Updated to incorporate comments) I imagine that the following command is compiling correctly because the OpenMP library is already in your library path and your system's dynamic linker is automatically linking with libgomp.so.
gcc hello.c -fopenmp -o hello
The following command is probably compiling properly because it is linking to the shared object for OpenMP (libgomp.so). Note that the -static option is not used.
gcc hello.c -L/usr/lib/gcc/i686-linux-gnu/4.4/ -lgomp -o hello
If you don't specify the -fopenmp option, OpenMP directives should be ignored.
Related
I'm building an IR level Pass for LLVM which instrument the functions with calls to my runtime library.
So far I have used the following lines to compile any C file with my pass and link it with the runtime library and guaranteeing that the runtime library function calls are inlined.
Compiling source to IR...
clang -S -emit-llvm example.c -o example-codeIR.ll -I ../runtime
Running Pass with opt...
opt -load=../build/PSS/libPSSPass.so -PSSPass -overwrite -always-inline -S -o example-codeOpt.ll example-codeIR.ll
Linking IR with runtime library...
llvm-link -o example-linked.bc example-codeOpt.ll ../runtime/obj/PSSutils.ll
Compiling bitcode to binary...
clang -ldl -O3 -o example example-linked.bc ../initializer/so/shim.so
Now I would like to test my pass with the LLVM testsuite and the only thing I can do is pass flags to the test suite. I can't control the steps of of compilation and generate so many files for each test case.
Is there a way to do the same as above without having to save intermediate files and yet keep the order of the steps?
I have tried the following:
clang -ldl -Xclang -load -Xclang ../build/PSS/libPSSPass.so ../initializer/so/shim.so ../runtime/obj/PSSutils.ll $<
But I ran into the problem that I can't compile both IR and .c files.
If I compile the runtime library to be an object file the functions in it will not get inlined anymore which is the main goal of the above steps.
So to Answer my question:
first of all, call to shared objects are never inlined. hence, the above mentioned shared objects should be compiled to objects instead. The -flto=thin flag should be used when compiling the objects to build a summary of the functions so the linker can perform link time optimizations.
And in the final step of compiling the target you will need to also compile it with -flto=thin flag and the compiler will do the magic for you.
such as:
gcc test.c mystaticlib.a -o test -O2
would -O2 take effect for mystaticlib.a, or just test.c?
-O2 is a compilation flag. The only input you're compiling in this example is test.c. mystaticlib.a is not compiled, but rather linked with the compilation output of test.c to create the executable test. Since mystaticlib.a isn't compiled here, the -O2 flag does not affect it.
I have a C code and I want to call the functions in it from R by creating a shared object and dynamically loading that object in R. The code to create a shared object in R is:
R CMD SHLIB myfile.c
And the general way is:
gcc -c -Wall -Werror -fpic myfile.c
gcc -shared -o myfile.so myfile.o
I am wondering whether there is any difference between the two myfile.so files created by those different pieces of code in terms of usage in R. The sizes of the two files are quite different (17KB and 32 KB), which confused me.
When you do
gcc -c -Wall -Werror -fpic myfile.c
gcc -shared -o myfile.so myfile.o
you miss several flags that R CMD SHLIB takes, like optimization flag -O2, debugging flag -g, etc. Why not have a look at what is printed to the screen when you do:
R CMD SHLIB myfile.c
Flags I have mentioned have influence on code size, as well as efficiency of your compiled code. The resulting object code is different. You can use disassembler:
objdump -d myfile.so
to check (binary) assembly code as well as code size. You can also use
gcc -S -Wall -Werror -fpic myfile.c
to check (readable) assembly code. You will see huge difference whether you use -O2 or not.
Godbolt compiler explore is a GUI interactive assembler. You type in C code on the left-side window, then choose compiler, compilation flags, output display configuration, etc, then the assembly code will be produced on the right-side window. This is super convenient for HPC code writers to evaluate and optimize their code. For you, this is a handy approach to compare the difference in object code.
I created a library for my C programs and this includes threads. I usually work with Code::Blocks and I never had problems, but now I need to compile programs directly from terminal. I saw that I need to write -lpthread but also my library name (its name is my_lib.h). I tried to compile first the library with gcc my_lib.c -c and this works; after, I tried this gcc main.c my_lib.h -o main -lpthread, but this doesn't work.
So what is the correctly sintax to compile this program that uses my_lib.h?
I assume my_lib.c is just a module (object file) rather than shared library.
The compiling consists of two parts - compiling into object files and then linking:
# compiling (note the -c)
gcc -c my_lib.c
gcc -c main.c
# linking (no -c, just specify target with -o)
gcc -o main main.o my_lib.o -lpthread
Header files are never compiled (explicitly), they are just included from the .c files and therefore never produce .o file.
I want clang to compile my C/C++ code to LLVM bitcode rather than a binary executable. How can I achieve that?
And if I have the LLVM bitcode, how can I further compile it to a binary executable?
I want to add some of my own code to the LLVM bitcode before compiling to a binary executable.
Given some C/C++ file foo.c:
> clang -S -emit-llvm foo.c
Produces foo.ll which is an LLVM IR file.
The -emit-llvm option can also be passed to the compiler front-end directly, and not the driver by means of -cc1:
> clang -cc1 foo.c -emit-llvm
Produces foo.ll with the IR. -cc1 adds some cool options like -ast-print. Check out -cc1 --help for more details.
To compile LLVM IR further to assembly, use the llc tool:
> llc foo.ll
Produces foo.s with assembly (defaulting to the machine architecture you run it on). llc is one of the LLVM tools - here is its documentation.
Use
clang -emit-llvm -o foo.bc -c foo.c
clang -o foo foo.bc
If you have multiple source files, you probably actually want to use link-time-optimization to output one bitcode file for the entire program. The other answers given will cause you to end up with a bitcode file for every source file.
Instead, you want to compile with link-time-optimization
clang -flto -c program1.c -o program1.o
clang -flto -c program2.c -o program2.o
and for the final linking step, add the argument -Wl,-plugin-opt=also-emit-llvm
clang -flto -Wl,-plugin-opt=also-emit-llvm program1.o program2.o -o program
This gives you both a compiled program and the bitcode corresponding to it (program.bc). You can then modify program.bc in any way you like, and recompile the modified program at any time by doing
clang program.bc -o program
although be aware that you need to include any necessary linker flags (for external libraries, etc) at this step again.
Note that you need to be using the gold linker for this to work. If you want to force clang to use a specific linker, create a symlink to that linker named "ld" in a special directory called "fakebin" somewhere on your computer, and add the option
-B/home/jeremy/fakebin
to any linking steps above.
If you have multiple files and you don't want to have to type each file, I would recommend that you follow these simple steps (I am using clang-3.8 but you can use any other version):
generate all .ll files
clang-3.8 -S -emit-llvm *.c
link them into a single one
llvm-link-3.8 -S -v -o single.ll *.ll
(Optional) Optimise your code (maybe some alias analysis)
opt-3.8 -S -O3 -aa -basicaaa -tbaa -licm single.ll -o optimised.ll
Generate assembly (generates a optimised.s file)
llc-3.8 optimised.ll
Create executable (named a.out)
clang-3.8 optimised.s
Did you read clang documentation ? You're probably looking for -emit-llvm.