X-Git-Url: http://plrg.eecs.uci.edu/git/?a=blobdiff_plain;f=docs%2FFAQ.html;h=ea2f802d1dd17f2bac314d4fd1e7d588777196cd;hb=e81cd881b165fd4197a25e21a88e25f781754e55;hp=512425a88f11d4f4137895a585e8cbdb3b816dff;hpb=32a32f070ce5d5f49d7b1a6a209d1b99133fe0fa;p=oota-llvm.git diff --git a/docs/FAQ.html b/docs/FAQ.html index 512425a88f1..ea2f802d1dd 100644 --- a/docs/FAQ.html +++ b/docs/FAQ.html @@ -1,214 +1,682 @@ - + + +
+-
-
-
-
- -
- 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 Subversion, 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 Subversion update, rebuilding gives the error "No rule to make +target".
+If the error is of the form:
+ ++gmake[2]: *** No rule to make target `/path/to/somefile', needed by +`/path/to/another/file.d'.+
+Stop. +
This may occur anytime files are moved within the Subversion 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.
+llvmc is experimental and isn't really supported. We suggest +using llvm-gcc instead.
+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 + java module. There is no documentation on this yet so + you'll need to download the code, compile it, and try it.
+In the stacker module 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++:
+ ++% llvm-g++ x.cpp -o program ++
or:
+ ++% llvm-g++ a.cpp -c +% llvm-g++ b.cpp -c +% llvm-g++ a.o b.o -o program ++
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:
+ ++% llc -march=c program.bc -o program.c ++
Finally, compile the C file:
+ ++% cc x.c ++
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 +bitcode, 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.
+ +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:
+ ++int X() { int i; return i; } ++
Is compiled to "ret i32 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. -