For detailed case scenarios, such as debugging gccas, -gccld, or one of the LLVM code generators, see For detailed case scenarios, such as debugging opt, +llvm-ld, or one of the LLVM code generators, see How To Submit a Bug Report document.
@@ -114,7 +114,7 @@ Otherwise, there is no problem bugpoint can debug. as it can to reduce the list of passes (for optimizer crashes) and the size of the test program. First, bugpoint figures out which combination of optimizer passes triggers the bug. This is useful when debugging a problem -exposed by gccas, for example, because it runs over 38 passes. +exposed by opt, for example, because it runs over 38 passes.Next, bugpoint tries removing functions from the test program, to reduce its size. Usually it is able to reduce a test program to a single diff --git a/docs/CFEBuildInstrs.html b/docs/CFEBuildInstrs.html index 85d1ebd90ff..033edcc1f20 100644 --- a/docs/CFEBuildInstrs.html +++ b/docs/CFEBuildInstrs.html @@ -314,8 +314,8 @@ sh:
To work around this, perform the following steps:
--This will allow the gccld linker to create a native code executable instead of -a 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. -
+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.---
-- gccas
-- This tool is invoked by the llvm-gcc frontend as the - "assembler" part of the compiler. This tool actually assembles LLVM - assembly to LLVM bytecode, performs a variety of optimizations, and - outputs LLVM bytecode. Thus when you invoke - llvm-gcc -c x.c -o x.o, you are causing gccas to be - run, which writes the x.o file (which is an LLVM bytecode file - that can be disassembled or manipulated just like any other bytecode - file). The command line interface to gccas is designed to be - as close as possible to the system `as' utility so that - the gcc frontend itself did not have to be modified to interface to - a "weird" assembler.
- -- gccld
-- gccld links together several LLVM bytecode files into one - bytecode file and does some optimization. It is the linker invoked by - the GCC frontend when multiple .o files need to be linked together. - Like gccas, the command line interface of gccld is - designed to match the system linker, to aid interfacing with the GCC - frontend.
-
Next, compile the C file into a LLVM bytecode file:
-% llvm-gcc hello.c -o hello
+% llvm-gcc hello.c -emit-llvm -o hello.bc
-Note that you should have already built the tools and they have to be - in your path, at least gccas and gccld.
- -This will create two result files: hello and - hello.bc. The hello.bc is the LLVM bytecode that - corresponds the the compiled program and the library facilities that it - required. hello is a simple shell script that runs the bytecode - file with lli, making the result directly executable. Note that - all LLVM optimizations are enabled by default, so there is no need for a - "-O3" switch.
+This will create the result file hello.bc which is the LLVM + bytecode that corresponds the the compiled program and the library + facilities that it required. You can execute this file directly using + lli tool, compile it to native assembly with the llc, + optimize or analyze it further with the opt tool, etc.
Note: while you cannot do this step on Windows, you can do it on a Unix system and transfer hello.bc to Windows.