<li><a href="#translatecxx">Can I use LLVM to convert C++ code to C code?</a></li>
+ <li><a href="#platformindependent">Can I compile C or C++ code to platform-independent LLVM bitcode?</a></li>
+
</ol>
</li>
<li><p>Run <tt>configure</tt> with an alternative <tt>PATH</tt> that is
correct. In a Borne compatible shell, the syntax would be:</p>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
% PATH=[the path without the bad program] ./configure ...
</pre>
-</div>
<p>This is still somewhat inconvenient, but it allows <tt>configure</tt>
to do its work without having to adjust your <tt>PATH</tt>
can just run the following command in the top level directory of your object
tree:</p>
-<div class="doc_code">
-<pre>% ./config.status <relative path to Makefile></pre>
-</div>
+<pre class="doc_code">
+% ./config.status <relative path to Makefile>
+</pre>
<p>If the Makefile is new, you will have to modify the configure script to copy
it over.</p>
<p>For example, if you built LLVM with the command:</p>
-<div class="doc_code">
-<pre>% gmake ENABLE_PROFILING=1</pre>
-</div>
+<pre class="doc_code">
+% gmake ENABLE_PROFILING=1
+</pre>
<p>...then you must run the tests with the following commands:</p>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
% cd llvm/test
% gmake ENABLE_PROFILING=1
</pre>
-</div>
</div>
<div class="answer">
<p>If the error is of the form:</p>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
gmake[2]: *** No rule to make target `/path/to/somefile', needed by
`/path/to/another/file.d'.<br>
Stop.
</pre>
-</div>
<p>This may occur anytime files are moved within the Subversion repository or
removed entirely. In this case, the best solution is to erase all
<tt>.d</tt> files, which list dependencies for source files, and rebuild:</p>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
% cd $LLVM_OBJ_DIR
% rm -f `find . -name \*\.d`
% gmake
</pre>
-</div>
<p>In other cases, it may be necessary to run <tt>make clean</tt> before
rebuilding.</p>
The only way this can happen is if you haven't installed the runtime library. To
correct this, do:</p>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
% cd llvm/runtime
% make clean ; make install-bytecode
</pre>
</div>
-</div>
<div class="question">
<p>
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.
-</p>
+so this may not be what you're looking for. Also, there are several
+limitations noted below.<p>
<p>Use commands like this:</p>
<ol>
<li><p>Compile your program as normal with llvm-g++:</p>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
% llvm-g++ x.cpp -o program
</pre>
-</div>
<p>or:</p>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
% llvm-g++ a.cpp -c
% llvm-g++ b.cpp -c
% llvm-g++ a.o b.o -o program
</pre>
-</div>
<p>With llvm-gcc3, this will generate program and program.bc. The .bc
file is the LLVM version of the program all linked together.</p></li>
<li><p>Convert the LLVM code to C code, using the LLC tool with the C
backend:</p>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
% llc -march=c program.bc -o program.c
-</pre>
-</div></li>
+</pre></li>
<li><p>Finally, compile the C file:</p>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
% cc x.c
-</pre>
-</div></li>
+</pre></li>
</ol>
-<p>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.</p>
+<p>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.</p>
-<p>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
+<p>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 can compile the
+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.</p>
+<p>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.</p>
+
+<p>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.</p>
+
+</div>
+
+<div class="question">
+<p>
+<a name="platformindependent">Can I compile C or C++ code to platform-independent LLVM bitcode?</a>
+</p>
+</div>
+
+<div class="answer">
+
+<p>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.</p>
+
+<p>Another example is <tt>sizeof</tt>. It's common for <tt>sizeof(long)</tt>
+to vary between platforms. In most C front-ends, <tt>sizeof</tt> is expanded
+to a constant immediately, thus hardwaring a platform-specific detail.</p>
+
+<p>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.</p>
+
</div>
<!-- *********************************************************************** -->
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:</p>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
int X() { int i; return i; }
</pre>
-</div>
<p>Is compiled to "<tt>ret i32 undef</tt>" because "<tt>i</tt>" never has
a value specified for it.</p>
projects / oota-llvm.git / blobdiff