X-Git-Url: http://plrg.eecs.uci.edu/git/?a=blobdiff_plain;f=docs%2FFAQ.html;h=620cf2500a48f09a26d2ecf6de75f776765401e3;hb=f1ac465b67d5fc11a0d9cd09b98ceb4ffa75dd97;hp=83719b74e4098b98c80f794383c332e679cc401b;hpb=f159402cbd7504297ad91efdabce86ce6a443115;p=oota-llvm.git diff --git a/docs/FAQ.html b/docs/FAQ.html index 83719b74e40..620cf2500a4 100644 --- a/docs/FAQ.html +++ b/docs/FAQ.html @@ -12,9 +12,9 @@ -
+

LLVM: Frequently Asked Questions -

+
  1. License @@ -124,19 +124,23 @@
  2. What is this "undef" thing that shows up in my code?
  3. + +
  4. Why does instcombine + simplifycfg turn + a call to a function with a mismatched calling convention into "unreachable"? + Why not make the verifier reject it?
-

Written by The LLVM Team

+

Written by The LLVM Team

-
+

License -

+
@@ -185,9 +189,9 @@
-
+

Source Code -

+
@@ -223,9 +227,9 @@ LLVM have been ported to a plethora of platforms.

-
+

Build Problems -

+
@@ -426,14 +430,14 @@ Stop.
-

When I compile LLVM-GCC with srcdir == objdir, it +

When I compile LLVM-GCC with srcdir == objdir, it fails. Why?

The GNUmakefile in the top-level directory of LLVM-GCC is a special Makefile used by Apple to invoke the build_gcc script after - setting up a special environment. This has the unforunate side-effect that + 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 GNUmakefile instead of Makefile. Because the environment isn't set up correctly to do this, the build fails.

@@ -445,7 +449,9 @@ Stop.
-
Source Languages
+

+ Source Languages +

What source languages are supported?

@@ -551,9 +557,9 @@ Stop.
-
+

Using the GCC Front End -

+

When I compile software that uses a configure script, the configure script @@ -628,22 +634,22 @@ Stop.

Use commands like this:

    -
  1. Compile your program as normal with llvm-g++:

    +
  2. Compile your program with llvm-g++:

    -% llvm-g++ x.cpp -o program
    +% llvm-g++ -emit-llvm x.cpp -o program.bc -c
     

    or:

    -% 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
     
    -

    With llvm-gcc3, this will generate program and program.bc. The .bc - file is the LLVM version of the program all linked together.

  3. +

    This will generate program and program.bc. The .bc + file is the LLVM version of the program all linked together.

  4. Convert the LLVM code to C code, using the LLC tool with the C backend:

    @@ -655,7 +661,7 @@ Stop.
  5. Finally, compile the C file:

    -% cc x.c
    +% cc x.c -lstdc++
     
@@ -681,7 +687,7 @@ Stop.

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.

@@ -696,11 +702,11 @@ Stop. 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.

+ targeting.

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.

+ a constant immediately, thus hard-wiring 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 @@ -708,9 +714,9 @@ Stop. -

+

Questions about code generated by the GCC front-end -

+

What is this llvm.global_ctors and @@ -764,7 +770,7 @@ Stop.

What is this "undef" thing that shows up in my - code?

+ code?

@@ -780,6 +786,143 @@ int X() { int i; return i; } value specified for it.

+ + +
+

Why does instcombine + simplifycfg turn + a call to a function with a mismatched calling convention into "unreachable"? + Why not make the verifier reject it?

+
+ +
+

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:

+ +
+define fastcc void @foo() {
+        ret void
+}
+define void @bar() {
+        call void @foo()
+        ret void
+}
+
+ +

Is optimized to:

+ +
+define fastcc void @foo() {
+	ret void
+}
+define void @bar() {
+	unreachable
+}
+
+ +

... 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.

+ +

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:

+ +
+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
+} 
+
+ +

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): +

+ +
+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
+}
+
+ +

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: +

+ +
+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
+}
+
+ +

The interesting thing about this is that %X must 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:

+ +
+define fastcc void @foo() {
+	ret void
+}
+define void @test(i1 %X) {
+F.i:
+	call fastcc void @foo()
+	ret void
+}
+
+ +
+
@@ -789,7 +932,7 @@ int X() { int i; return i; } Valid HTML 4.01 - LLVM Compiler Infrastructure
+ LLVM Compiler Infrastructure
Last modified: $Date$