What support is there for a higher level source language constructs for + +
+Your compiler front-end will communicate with LLVM by creating a module in + the LLVM intermediate representation (IR) format. Assuming you want to + write your language's compiler in the language itself (rather than C++), + there are 3 major ways to tackle generating LLVM IR from a front-end:
+-
+
-
+ Call into the LLVM libraries code using your language's FFI
+ (foreign function interface).
+
-
+
- for: best tracks changes to the LLVM IR, .ll syntax, + and .bc format +
- for: enables running LLVM optimization passes without a + emit/parse overhead +
- for: adapts well to a JIT context +
- against: lots of ugly glue code to write +
+ -
+ Emit LLVM assembly from your compiler's native language.
+
-
+
- for: very straightforward to get started +
- against: the .ll parser is slower than the bitcode reader + when interfacing to the middle end +
- against: you'll have to re-engineer the LLVM IR object + model and asm writer in your language +
- against: it may be harder to track changes to the IR +
+ -
+ Emit LLVM bitcode from your compiler's native language.
+
-
+
- for: can use the more-efficient bitcode reader when + interfacing to the middle end +
- against: you'll have to re-engineer the LLVM IR object + model and bitcode writer in your language +
- against: it may be harder to track changes to the IR +
+
If you go with the first option, the C bindings in include/llvm-c should + help a lot, since most languages have strong support for interfacing with + C. The most common hurdle with calling C from managed code is interfacing + with the garbage collector. The C interface was designed to require very + little memory management, and so is straightforward in this regard.
+I don't understand the GetElementPtr - instruction. Help!
+See The Often Misunderstood GEP - Instruction. + Instruction.
+% cd llvm/runtime % make clean ; make install-bytecode
@@ -518,7 +557,7 @@ code that you desire.
@@ -527,99 +566,100 @@ code that you desire. 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. - +so this may not be what you're looking for. Also, there are several +limitations noted below.
Use commands like this:
-
-
Compile your program as normal with llvm-g++:
+ Compile your program as normal with llvm-g++:
---+
% llvm-g++ x.cpp -o program
-or:
+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.
+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:
+ 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:
+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. -
+Using LLVM does not eliminate the need for C++ library support. +If you use the llvm-g++ front-end, the generated code will depend on +g++'s C++ support libraries in the same way that code generated from +g++ would. If you use another C++ front-end, the generated code will +depend on whatever library that front-end would normally require.
-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.
- -If you are working on a platform that does not provide any C++ +libraries, you may be able to 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 might compile the +libraries and your application into two different chunks of C code and link +them.
+Note that, by default, the C back end 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 relatively slow, and +not C++-ABI-conforming on most platforms, but otherwise correct.
+Also, there are a number of other limitations of the C backend that +cause it to produce code that does not fully conform to the C++ ABI on +most platforms. Some of the C++ programs in LLVM's test suite are known +to fail when compiled with the C back end because of ABI incompatiblities +with standard C++ libraries.
- - - - --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. +Can I compile C or C++ code to platform-independent LLVM bitcode?
+No. C and C++ are inherently platform-dependent languages. The most +obvious example of this is the preprocessor. A very common way that C code +is made portable is by using the preprocessor to include platform-specific +code. In practice, information about other platforms is lost after +preprocessing, so the result is inherently dependent on the platform that +the preprocessing was targetting.
+ +Another example is sizeof. It's common for sizeof(long) +to vary between platforms. In most C front-ends, sizeof is expanded +to a constant immediately, thus hardwaring a platform-specific detail.
+ +Also, since many platforms define their ABIs in terms of C, and since +LLVM is lower-level than C, front-ends currently must emit platform-specific +IR in order to have the result conform to the platform ABI.
--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. -
+
int X() { int i; return i; }
-Is compiled to "ret i32 undef" because "i" never has a value specified for it.
@@ -702,9 +740,9 @@ a value specified for it.
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS">
Last modified: $Date$