</head>
<body>
-<div class="doc_title">
+<h1>
LLVM: Frequently Asked Questions
-</div>
+</h1>
<ol>
<li><a href="#license">License</a>
<li>After Subversion update, rebuilding gives the error "No rule to make
target".</li>
- <li><a href="#llvmc">The <tt>llvmc</tt> program gives me errors/doesn't
- work.</a></li>
+ <li><a href="#srcdir-objdir">When I compile LLVM-GCC with srcdir == objdir,
+ it fails. Why?</a></li>
</ol></li>
<li><a href="#felangs">Source Languages</a>
<li><a href="#undef">What is this "<tt>undef</tt>" thing that shows up in
my code?</a></li>
+
+ <li><a href="#callconvwrong">Why does instcombine + simplifycfg turn
+ a call to a function with a mismatched calling convention into "unreachable"?
+ Why not make the verifier reject it?</a></li>
</ol>
</li>
</ol>
<div class="doc_author">
- <p>Written by <a href="http://llvm.org">The LLVM Team</a></p>
+ <p>Written by <a href="http://llvm.org/">The LLVM Team</a></p>
</div>
<!-- *********************************************************************** -->
-<div class="doc_section">
+<h2>
<a name="license">License</a>
-</div>
+</h2>
<!-- *********************************************************************** -->
<div class="question">
</div>
<!-- *********************************************************************** -->
-<div class="doc_section">
+<h2>
<a name="source">Source Code</a>
-</div>
+</h2>
<!-- *********************************************************************** -->
<div class="question">
</div>
<!-- *********************************************************************** -->
-<div class="doc_section">
+<h2>
<a name="build">Build Problems</a>
-</div>
+</h2>
<!-- *********************************************************************** -->
<div class="question">
rebuilding.</p>
</div>
-<div class="question"><p><a name="llvmc">
-<p>The <tt>llvmc</tt> program gives me errors/doesn't work.</a></p>
+<div class="question">
+<p><a name="srcdir-objdir">When I compile LLVM-GCC with srcdir == objdir, it
+ fails. Why?</a></p>
</div>
<div class="answer">
-<p><tt>llvmc</tt> is experimental and isn't really supported. We suggest
- using <tt>llvm-gcc</tt> instead.</p>
+<p>The <tt>GNUmakefile</tt> in the top-level directory of LLVM-GCC is a special
+ <tt>Makefile</tt> used by Apple to invoke the <tt>build_gcc</tt> script after
+ setting up a special environment. This has the unfortunate side-effect that
+ trying to build LLVM-GCC with srcdir == objdir in a "non-Apple way" invokes
+ the <tt>GNUmakefile</tt> instead of <tt>Makefile</tt>. Because the
+ environment isn't set up correctly to do this, the build fails.</p>
+
+<p>People not building LLVM-GCC the "Apple way" need to build LLVM-GCC with
+ srcdir != objdir, or simply remove the GNUmakefile entirely.</p>
+
+<p>We regret the inconvenience.</p>
</div>
<!-- *********************************************************************** -->
-<div class="doc_section"><a name="felangs">Source Languages</a></div>
+<h2>
+ <a name="felangs">Source Languages</a>
+</h2>
<div class="question">
<p><a name="langs">What source languages are supported?</a></p>
<p>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 <i>mostly
- implemented</i> configuration-driven
- <a href="CompilerDriver.html">compiler driver</a> which simplifies the task
- of running optimizations, linking, and executable generation.</p>
+ facilities for lexical nor semantic analysis.</p>
</div>
<div class="question">
</div>
<!-- *********************************************************************** -->
-<div class="doc_section">
+<h2>
<a name="cfe">Using the GCC Front End</a>
-</div>
+</h2>
<div class="question">
<p>When I compile software that uses a configure script, the configure script
<p>Use commands like this:</p>
<ol>
- <li><p>Compile your program as normal with llvm-g++:</p>
+ <li><p>Compile your program with llvm-g++:</p>
<pre class="doc_code">
-% llvm-g++ x.cpp -o program
+% llvm-g++ -emit-llvm x.cpp -o program.bc -c
</pre>
<p>or:</p>
<pre class="doc_code">
-% llvm-g++ a.cpp -c
-% llvm-g++ b.cpp -c
-% llvm-g++ a.o b.o -o program
+% llvm-g++ a.cpp -c -emit-llvm
+% llvm-g++ b.cpp -c -emit-llvm
+% llvm-ld a.o b.o -o program
</pre>
- <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>
+ <p>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>
<li><p>Finally, compile the C file:</p>
<pre class="doc_code">
-% cc x.c
+% cc x.c -lstdc++
</pre></li>
</ol>
<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
+ when compiled with the C back end because of ABI incompatibilities with
standard C++ libraries.</p>
</div>
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>
+ targeting.</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>
+ a constant immediately, thus hard-wiring 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
</div>
<!-- *********************************************************************** -->
-<div class="doc_section">
+<h2>
<a name="cfe_code">Questions about code generated by the GCC front-end</a>
-</div>
+</h2>
<div class="question">
<p><a name="iosinit">What is this <tt>llvm.global_ctors</tt> and
<div class="question">
<p><a name="undef">What is this "<tt>undef</tt>" thing that shows up in my
- code?</p>
+ code?</a></p>
</div>
<div class="answer">
value specified for it.</p>
</div>
+<!--=========================================================================-->
+
+<div class="question">
+<p><a name="callconvwrong">Why does instcombine + simplifycfg turn
+ a call to a function with a mismatched calling convention into "unreachable"?
+ Why not make the verifier reject it?</a></p>
+</div>
+
+<div class="answer">
+<p>This is a common problem run into by authors of front-ends that are using
+custom calling conventions: you need to make sure to set the right calling
+convention on both the function and on each call to the function. For example,
+this code:</p>
+
+<pre class="doc_code">
+define fastcc void @foo() {
+ ret void
+}
+define void @bar() {
+ call void @foo()
+ ret void
+}
+</pre>
+
+<p>Is optimized to:</p>
+
+<pre class="doc_code">
+define fastcc void @foo() {
+ ret void
+}
+define void @bar() {
+ unreachable
+}
+</pre>
+
+<p>... with "opt -instcombine -simplifycfg". This often bites people because
+"all their code disappears". Setting the calling convention on the caller and
+callee is required for indirect calls to work, so people often ask why not make
+the verifier reject this sort of thing.</p>
+
+<p>The answer is that this code has undefined behavior, but it is not illegal.
+If we made it illegal, then every transformation that could potentially create
+this would have to ensure that it doesn't, and there is valid code that can
+create this sort of construct (in dead code). The sorts of things that can
+cause this to happen are fairly contrived, but we still need to accept them.
+Here's an example:</p>
+
+<pre class="doc_code">
+define fastcc void @foo() {
+ ret void
+}
+define internal void @bar(void()* %FP, i1 %cond) {
+ br i1 %cond, label %T, label %F
+T:
+ call void %FP()
+ ret void
+F:
+ call fastcc void %FP()
+ ret void
+}
+define void @test() {
+ %X = or i1 false, false
+ call void @bar(void()* @foo, i1 %X)
+ ret void
+}
+</pre>
+
+<p>In this example, "test" always passes @foo/false into bar, which ensures that
+ it is dynamically called with the right calling conv (thus, the code is
+ perfectly well defined). If you run this through the inliner, you get this
+ (the explicit "or" is there so that the inliner doesn't dead code eliminate
+ a bunch of stuff):
+</p>
+
+<pre class="doc_code">
+define fastcc void @foo() {
+ ret void
+}
+define void @test() {
+ %X = or i1 false, false
+ br i1 %X, label %T.i, label %F.i
+T.i:
+ call void @foo()
+ br label %bar.exit
+F.i:
+ call fastcc void @foo()
+ br label %bar.exit
+bar.exit:
+ ret void
+}
+</pre>
+
+<p>Here you can see that the inlining pass made an undefined call to @foo with
+ the wrong calling convention. We really don't want to make the inliner have
+ to know about this sort of thing, so it needs to be valid code. In this case,
+ dead code elimination can trivially remove the undefined code. However, if %X
+ was an input argument to @test, the inliner would produce this:
+</p>
+
+<pre class="doc_code">
+define fastcc void @foo() {
+ ret void
+}
+
+define void @test(i1 %X) {
+ br i1 %X, label %T.i, label %F.i
+T.i:
+ call void @foo()
+ br label %bar.exit
+F.i:
+ call fastcc void @foo()
+ br label %bar.exit
+bar.exit:
+ ret void
+}
+</pre>
+
+<p>The interesting thing about this is that %X <em>must</em> be false for the
+code to be well-defined, but no amount of dead code elimination will be able to
+delete the broken call as unreachable. However, since instcombine/simplifycfg
+turns the undefined call into unreachable, we end up with a branch on a
+condition that goes to unreachable: a branch to unreachable can never happen, so
+"-inline -instcombine -simplifycfg" is able to produce:</p>
+
+<pre class="doc_code">
+define fastcc void @foo() {
+ ret void
+}
+define void @test(i1 %X) {
+F.i:
+ call fastcc void @foo()
+ ret void
+}
+</pre>
+
+</div>
+
<!-- *********************************************************************** -->
<hr>
<a href="http://validator.w3.org/check/referer"><img
src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
- <a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
+ <a href="http://llvm.org/">LLVM Compiler Infrastructure</a><br>
Last modified: $Date$
</address>
projects / oota-llvm.git / blobdiff