-
-
-
-
- -
- Some porting problems may exist in the following areas: -
- -
- -
Why are the LLVM source code and the front-end distributed under different +licenses?
+The C/C++ front-ends are based on GCC and must be distributed under the GPL. +Our aim is to distribute LLVM source code under a much less restrictive +license, in particular one that does not compel users who distribute tools based +on modifying the source to redistribute the modified source code as well.
+Does the University of Illinois Open Source License really qualify as an +"open source" license?
+Yes, the license is certified by the Open +Source Initiative (OSI).
+Can I modify LLVM source code and redistribute the modified source?
+Yes. The modified source distribution must retain the copyright notice and +follow the three bulletted conditions listed in the LLVM license.
+Can I modify LLVM source code and redistribute binaries or other tools based +on it, without redistributing the source?
+Yes, this is why we distribute LLVM under a less restrictive license than +GPL, as explained in the first question above.
+In what language is LLVM written?
+All of the LLVM tools and libraries are written in C++ with extensive use of +the STL.
+How portable is the LLVM source code?
+The LLVM source code should be portable to most modern UNIX-like operating +systems. Most of the code is written in standard C++ with operating system +services abstracted to a support library. The tools required to build and test +LLVM have been ported to a plethora of platforms.
+ +Some porting problems may exist in the following areas:
+ +When I run configure, it finds the wrong C compiler.
+The configure script attempts to locate first gcc and then +cc, unless it finds compiler paths set in CC and CXX +for the C and C++ compiler, respectively.
+ +If configure finds the wrong compiler, either adjust your +PATH environment variable or set CC and CXX +explicitly.
+ +The configure script finds the right C compiler, but it uses the +LLVM linker from a previous build. What do I do?
+The configure script uses the PATH to find executables, so +if it's grabbing the wrong linker/assembler/etc, there are two ways to fix +it:
+ +Adjust your PATH environment variable so that the correct + program appears first in the PATH. This may work, but may not be + convenient when you want them first in your path for other + work.
Run configure with an alternative PATH that is + correct. In a Borne compatible shell, the syntax would be:
+ +PATH=[the path without the bad program] ./configure ...
+ +This is still somewhat inconvenient, but it allows configure + to do its work without having to adjust your PATH + permanently.
When creating a dynamic library, I get a strange GLIBC error.
+Under some operating systems (i.e. Linux), libtool does not work correctly if +GCC was compiled with the --disable-shared option. To work around this, install +your own version of GCC that has shared libraries enabled by default.
+I've updated my source tree from CVS, and now my build is trying to use a +file/directory that doesn't exist.
+You need to re-run configure in your object directory. When new Makefiles +are added to the source tree, they have to be copied over to the object tree in +order to be used by the build.
+I've modified a Makefile in my source tree, but my build tree keeps using the +old version. What do I do?
+If the Makefile already exists in your object tree, you +can just run the following command in the top level directory of your object +tree:
+ +./config.status <relative path to Makefile>
+ +
If the Makefile is new, you will have to modify the configure script to copy +it over.
+ +I've upgraded to a new version of LLVM, and I get strange build errors.
+Sometimes, changes to the LLVM source code alters how the build system works. +Changes in libtool, autoconf, or header file dependencies are especially prone +to this sort of problem.
+ +The best thing to try is to remove the old files and re-build. In most +cases, this takes care of the problem. To do this, just type make +clean and then make in the directory that fails to build.
+ +I've built LLVM and am testing it, but the tests freeze.
+This is most likely occurring because you built a profile or release +(optimized) build of LLVM and have not specified the same information on the +gmake command line.
+ +For example, if you built LLVM with the command:
+ +gmake ENABLE_PROFILING=1 + +
...then you must run the tests with the following commands:
+ +cd llvm/test
gmake ENABLE_PROFILING=1
Why do test results differ when I perform different types of builds?
+The LLVM test suite is dependent upon several features of the LLVM tools and +libraries.
+ +First, the debugging assertions in code are not enabled in optimized or +profiling builds. Hence, tests that used to fail may pass.
+ +Second, some tests may rely upon debugging options or behavior that is only +available in the debug build. These tests will fail in an optimized or profile +build.
+ +Compiling LLVM with GCC 3.3.2 fails, what should I do?
+This is a bug in GCC, and + affects projects other than LLVM. Try upgrading or downgrading your GCC.
+After CVS update, rebuilding gives the error "No rule to make target".
+If the error is of the form:
+ +This may occur anytime files are moved within the CVS repository or removed +entirely. In this case, the best solution is to erase all .d files, +which list dependencies for source files, and rebuild:
+ ++% cd $LLVM_OBJ_DIR +% rm -f `find . -name \*\.d` +% gmake ++
In other cases, it may be necessary to run make clean before +rebuilding.
+LLVM currently has full support for C and C++ source languages. These are + available through a special version of GCC that LLVM calls the + C Front End
+There is an incomplete version of a Java front end available in the + llvm-java CVS repository. There is no documentation on this yet so + you'll need to download the code, compile it, and try it.
+In the examples/BFtoLLVM directory is a translator for the + BrainF*** language (2002 Language Specification).
+In the projects/Stacker directory is a compiler and runtime + library for the Stacker language, a "toy" language loosely based on Forth.
+The PyPy developers are working on integrating LLVM into the PyPy backend + so that PyPy language can translate to LLVM.
+Currently, there isn't much. LLVM supports an intermediate representation + which is useful for code representation but will not support the high level + (abstract syntax tree) representation needed by most compilers. There are no + facilities for lexical nor semantic analysis. There is, however, a mostly + implemented configuration-driven + compiler driver which simplifies the task + of running optimizations, linking, and executable generation.
++When I compile software that uses a configure script, the configure script +thinks my system has all of the header files and libraries it is testing for. +How do I get configure to work correctly? +
++The configure script is getting things wrong because the LLVM linker allows +symbols to be undefined at link time (so that they can be resolved during JIT +or translation to the C back end). That is why configure thinks your system +"has everything." +
++To work around this, perform the following steps: +
++This will allow the llvm-ld linker to create a native code executable +instead of shell script that runs the JIT. Creating native code requires +standard linkage, which in turn will allow the configure script to find out if +code is not linking on your system because the feature isn't available on your +system.
++When I compile code using the LLVM GCC front end, it complains that it cannot +find libcrtend.a. +
++The only way this can happen is if you haven't installed the runtime library. To +correct this, do:
++ % cd llvm/runtime + % make clean ; make install-bytecode ++
+How can I disable all optimizations when compiling code using the LLVM GCC front end? +
++Passing "-Wa,-disable-opt -Wl,-disable-opt" will disable *all* cleanup and +optimizations done at the llvm level, leaving you with the truly horrible +code that you desire. +
+Yes, you can use LLVM to convert code from any language LLVM supports to C. +Note that the generated C code will be very low level (all loops are lowered +to gotos, etc) and not very pretty (comments are stripped, original source +formatting is totally lost, variables are renamed, expressions are regrouped), +so this may not be what you're looking for. However, this is a good way to add +C++ support for a processor that does not otherwise have a C++ compiler. +
+ +Use commands like this:
+ +Compile your program as normal with llvm-g++:
or:
+ +With llvm-gcc3, this will generate program and program.bc. The .bc file is +the LLVM version of the program all linked together.
+ +Convert the LLVM code to C code, using the LLC tool with the C +backend:
Finally, compile the c file:
Note that, by default, the C backend does not support exception handling. +If you want/need it for a certain program, you can enable it by passing +"-enable-correct-eh-support" to the llc program. The resultant code will +use setjmp/longjmp to implement exception support that is correct but +relatively slow. +
+ +Also note: this specific sequence of commands won't work if you use a +function defined in the C++ runtime library (or any other C++ library). To +access an external C++ library, you must manually +compile libstdc++ to LLVM bytecode, statically link it into your program, then +use the commands above to convert the whole result into C code. Alternatively, +you can compile the libraries and your application into two different chunks +of C code and link them.
+ ++The __main call is inserted by the C/C++ compiler in order to guarantee +that static constructors and destructors are called when the program starts up +and shuts down. In C, you can create static constructors and destructors by +using GCC extensions, and in C++ you can do so by creating a global variable +whose class has a ctor or dtor. +
+ ++The actual implementation of __main lives in the +llvm/runtime/GCCLibraries/crtend/ directory in the source-base, and is +linked in automatically when you link the program. +
+What is this llvm.global_ctors and +_GLOBAL__I__tmp_webcompile... stuff that happens when I #include +<iostream>?
+If you #include the <iostream> header into a C++ translation unit, the +file will probably use the std::cin/std::cout/... global +objects. However, C++ does not guarantee an order of initialization between +static objects in different translation units, so if a static ctor/dtor in your +.cpp file used std::cout, for example, the object would not necessarily +be automatically initialized before your use.
+ +To make std::cout and friends work correctly in these scenarios, the +STL that we use declares a static object that gets created in every translation +unit that includes <iostream>. This object has a static +constructor and destructor that initializes and destroys the global iostream +objects before they could possibly be used in the file. The code that you see +in the .ll file corresponds to the constructor and destructor registration code. +
+ +If you would like to make it easier to understand the LLVM code +generated by the compiler in the demo page, consider using printf() +instead of iostreams to print values.
+ ++If you are using the LLVM demo page, you may often wonder what happened to all +of the code that you typed in. Remember that the demo script is running the +code through the LLVM optimizers, so if your code doesn't actually do anything +useful, it might all be deleted. +
+ ++To prevent this, make sure that the code is actually needed. For example, if +you are computing some expression, return the value from the function instead of +leaving it in a local variable. If you really want to constrain the optimizer, +you can read from and assign to volatile global variables. +
++undef is the LLVM way of representing +a value that is not defined. You can get these if you do not initialize a +variable before you use it. For example, the C function:
+ +Is compiled to "ret int undef" because "i" never has a value +specified for it. +
+- -
- Another possibility is that we hardcoded a path in our Makefiles. If - you see this, please email the LLVM bug mailing list with the name of - the offending Makefile and a description of what is wrong with it. - -
- -
- PATH=
- This is still somewhat inconvenient, but it allows - configure to do its work without having to adjust your - PATH permanently. -
- -
- -
- ./config.status <relative path to Makefile> -
- If the Makefile is new, you will have to modify the configure script to copy - it over. -
- -
- The best thing to try is to remove the old files and re-build. In most - cases, this takes care of the problem. To do this, just type make - clean and then make in the directory that fails to build. -
- -
- For example, if you built LLVM with the command: -
- gmake ENABLE_PROFILING=1 -
- ...then you must run the tests with the following commands: -
- cd llvm/test
gmake ENABLE_PROFILING=1
-
- -
- First, the debugging assertions in code are not enabled in optimized or - profiling builds. Hence, tests that used to fail may pass. -
- Second, some tests may rely upon debugging options or behavior that is - only available in the debug build. These tests will fail in an optimized - or profile build. -
+