Compare commits

..

9 Commits

Author SHA1 Message Date
John Criswell
b094f912b0 Note that a work-around is available.
llvm-svn: 24237
2005-11-08 15:40:22 +00:00
John Criswell
358cb80e7d Add a note about the Solaris configure problem that Tanya's seen.
llvm-svn: 24236
2005-11-08 15:38:11 +00:00
John Criswell
ec29828344 Include the CVS tag for the 1.6 release.
llvm-svn: 24167
2005-11-03 18:26:14 +00:00
John Criswell
1ea1e7ac4d Merge in hack from Chris that discards libg.
llvm-svn: 24166
2005-11-03 15:42:27 +00:00
John Criswell
398d2e2c28 Updated the version number.
Get the UIUC copyright to actually print.

llvm-svn: 24165
2005-11-03 15:25:04 +00:00
John Criswell
072467d8a9 Merged in revision 1.60.
llvm-svn: 24160
2005-11-02 19:38:00 +00:00
John Criswell
39a12ac598 Don't use -q; this option is not available on Solaris grep (and probably
other, traditional UNIX greps).

llvm-svn: 24156
2005-11-02 18:06:28 +00:00
John Criswell
89d3246c03 Mark these as failing on sparc instead of sparcv9.
The configure script no longer tells us that we're configuring for SparcV9
specifically.
2004-06-17-UnorderedCompares may work on SparcV8, but it's experiental
anyway.
2005-02-20-AggregateSAVEEXPR should fail on any Solaris machine, as Solaris
doesn't provide complex number support.

llvm-svn: 24155
2005-11-02 18:05:50 +00:00
CVS to SVN Conversion
53bd0b0175 This commit was manufactured by cvs2svn to create branch 'release_16'.
llvm-svn: 24138
2005-11-01 18:04:06 +00:00
4197 changed files with 245740 additions and 319645 deletions

View File

@@ -5,6 +5,3 @@ config.status
cvs.out
autom4te.cache
configure.out
LLVM-*
_distcheckdir
llvm.spec

View File

@@ -13,21 +13,12 @@ E: vadve@cs.uiuc.edu
W: http://www.cs.uiuc.edu/~vadve/
D: The Sparc64 backend, provider of much wisdom, and motivator for LLVM
N: Owen Anderson
E: resistor@mac.com
D: LCSSA pass and related LoopUnswitch work, TargetData refactoring, random improvements
N: Henrik Bach
D: MingW Win32 API portability layer
N: Nate Begeman
E: natebegeman@mac.com
D: PowerPC backend developer
D: Target-independent code generator and analysis improvements
N: Daniel Berlin
E: dberlin@dberlin.org
D: ET-Forest implementation.
D: Primary PowerPC backend developer
N: Misha Brukman
E: brukman+llvm@uiuc.edu
@@ -39,22 +30,10 @@ N: Cameron Buschardt
E: buschard@uiuc.edu
D: The `mem2reg' pass - promotes values stored in memory to registers
N: Chandler Carruth
E: chandlerc@gmail.com
D: LinkTimeOptimizer for Linux, via binutils integration, and C API
N: Casey Carter
E: ccarter@uiuc.edu
D: Fixes to the Reassociation pass, various improvement patches
N: Evan Cheng
E: evan.cheng@apple.com
D: ARM and X86 backends
D: Instruction scheduler improvements
D: Register allocator improvements
D: Loop optimizer improvements
D: Target-independent code generator improvements
N: Jeff Cohen
E: jeffc@jolt-lang.org
W: http://jolt-lang.org
@@ -64,10 +43,6 @@ N: John T. Criswell
E: criswell@uiuc.edu
D: Autoconf support, QMTest database, documentation improvements
N: Rafael Avila de Espindola
E: rafael.espindola@gmail.com
D: The ARM backend
N: Alkis Evlogimenos
E: alkis@evlogimenos.com
D: Linear scan register allocator, many codegen improvements, Java frontend
@@ -75,67 +50,25 @@ D: Linear scan register allocator, many codegen improvements, Java frontend
N: Brian Gaeke
E: gaeke@uiuc.edu
W: http://www.students.uiuc.edu/~gaeke/
D: Portions of X86 static and JIT compilers; initial SparcV8 backend
D: Portions of X86 static and JIT compilers; SparcV8 backend
D: Dynamic trace optimizer
D: FreeBSD/X86 compatibility fixes, the llvm-nm tool
N: Nicolas Geoffray
E: nicolas.geoffray@lip6.fr
W: http://www-src.lip6.fr/homepages/Nicolas.Geoffray/
D: PPC backend fixes for Linux
N: Louis Gerbarg
D: Portions of the PowerPC backend
N: Saem Ghani
E: saemghani@gmail.com
D: Callgraph class cleanups
N: Dan Gohman
E: djg@cray.com
D: Miscellaneous bug fixes
N: Paolo Invernizzi
E: arathorn@fastwebnet.it
D: Visual C++ compatibility fixes
N: Patrick Jenkins
E: patjenk@wam.umd.edu
D: Nightly Tester
N: Brad Jones
E: kungfoomaster@nondot.org
D: Support for packed types
N: Dale Johannesen
E: dalej@apple.com
D: ARM constant islands improvements
N: Eric Kidd
W: http://randomhacks.net/
D: llvm-config script
N: Anton Korobeynikov
E: asl@math.spbu.ru
D: Mingw32 fixes, cross-compiling support, stdcall/fastcall calling conv.
D: x86/linux PIC codegen, aliases, regparm/visibility attributes
D: Switch lowering refactoring
N: Sumant Kowshik
E: kowshik@uiuc.edu
D: Author of the original C backend
N: Christopher Lamb
E: christopher.lamb@gmail.com
D: aligned load/store support
N: Jim Laskey
E: jlaskey@apple.com
D: Improvements to the PPC backend, instruction scheduling
D: Debug and Dwarf implementation
D: Auto upgrade mangler
D: llvm-gcc4 svn wrangler
N: Chris Lattner
E: sabre@nondot.org
W: http://nondot.org/~sabre/
@@ -146,17 +79,11 @@ E: tonic@nondot.org
W: http://nondot.org/~tonic/
D: The initial llvm-ar tool, converted regression testsuite to dejagnu
D: Modulo scheduling in the SparcV9 backend
D: Release manager (1.7+)
N: Andrew Lenharth
E: alenhar2@cs.uiuc.edu
W: http://www.lenharth.org/~andrewl/
D: Alpha backend
D: Sampling based profiling
N: Nick Lewycky
E: nicholas@mxc.ca
D: PredicateSimplifier pass
N: Duraid Madina
E: duraid@octopus.com.au
@@ -175,25 +102,10 @@ N: Morten Ofstad
E: morten@hue.no
D: Visual C++ compatibility fixes
N: Devang Patel
E: dpatel@apple.com
D: LTO tool, PassManager rewrite, Loop Pass Manager, Loop Rotate
D: GCC PCH Integration (llvm-gcc), llvm-gcc improvements
D: Optimizer improvements
N: Vladimir Prus
W: http://vladimir_prus.blogspot.com
E: ghost@cs.msu.su
D: Made inst_iterator behave like a proper iterator, LowerConstantExprs pass
N: Roman Samoilov
E: roman@codedgers.com
D: MSIL backend
N: Duncan Sands
E: baldrick@free.fr
D: Ada front-end
N: Ruchira Sasanka
E: sasanka@uiuc.edu
D: Graph coloring register allocator for the Sparc64 backend
@@ -203,20 +115,14 @@ E: ashukla@cs.uiuc.edu
D: The `paths' pass
N: Reid Spencer
E: rspencer@reidspencer.com
W: http://reidspencer.com/
D: http://wiki.llvm.org/index.php/User:Reid
E: rspencer@x10sys.com
W: http://llvm.x10sys.com/rspencer
D: Stacker, llvmc, bytecode, other. See web page for current notes.
N: Adam Treat
E: manyoso@yahoo.com
D: C++ bugs filed, and C++ front-end bug fixes.
N: Lauro Ramos Venancio
E: lauro.venancio@indt.org.br
D: ARM backend improvements
D: Thread Local Storage implementation
N: Bill Wendling
E: isanbard@gmail.com
W: http://web.mac.com/bwendling/
E: wendling@isanbard.org
D: The `Lower Setjmp/Longjmp' pass, improvements to the -lowerswitch pass.

View File

@@ -4,7 +4,7 @@ LLVM Release License
University of Illinois/NCSA
Open Source License
Copyright (c) 2003-2007 University of Illinois at Urbana-Champaign.
Copyright (c) 2003, 2004, 2005 University of Illinois at Urbana-Champaign.
All rights reserved.
Developed by:
@@ -13,7 +13,7 @@ Developed by:
University of Illinois at Urbana-Champaign
http://llvm.org
http://llvm.cs.uiuc.edu
Permission is hereby granted, free of charge, to any person obtaining a copy of
this software and associated documentation files (the "Software"), to deal with
@@ -63,7 +63,10 @@ Program Directory
------- ---------
System Library llvm/lib/System
Compiler Driver llvm/tools/llvmc
PowerPC Backend llvm/lib/Target/PowerPC
bzip2 llvm/lib/Support/bzip2/LICENSE
Autoconf llvm/autoconf
llvm/projects/ModuleMaker/autoconf
llvm/projects/sample/autoconf
Burg llvm/utils/Burg
GNU Libc llvm/runtime/GCCLibraries/libc

View File

@@ -6,51 +6,21 @@
# the University of Illinois Open Source License. See LICENSE.TXT for details.
#
#===------------------------------------------------------------------------===#
LEVEL := .
# Top-Level LLVM Build Stages:
# 1. Build lib/System and lib/Support, which are used by utils (tblgen).
# 2. Build utils, which is used by VMCore.
# 3. Build VMCore, which builds the Intrinsics.inc file used by libs.
# 4. Build libs, which are needed by llvm-config.
# 5. Build llvm-config, which determines inter-lib dependencies for tools.
# 6. Build tools, runtime, docs.
#
DIRS := lib/System lib/Support utils lib/VMCore lib tools/llvm-config \
tools runtime docs
OPTIONAL_DIRS := examples projects
EXTRA_DIST := test llvm.spec include win32 Xcode
include $(LEVEL)/Makefile.config
# llvm-gcc4 doesn't need runtime libs. llvm-gcc4 is the only supported one.
# FIXME: Remove runtime entirely once we have an understanding of where
# libprofile etc should go.
#ifeq ($(LLVMGCC_MAJVERS),4)
DIRS := $(filter-out runtime, $(DIRS))
#endif
ifeq ($(MAKECMDGOALS),libs-only)
DIRS := $(filter-out tools runtime docs, $(DIRS))
OPTIONAL_DIRS :=
endif
LEVEL = .
DIRS = lib/System lib/Support utils lib
ifeq ($(MAKECMDGOALS),tools-only)
DIRS := $(filter-out runtime docs, $(DIRS))
OPTIONAL_DIRS :=
DIRS += tools
else
ifneq ($(MAKECMDGOALS),libs-only)
DIRS += tools runtime docs
OPTIONAL_DIRS = examples projects
endif
endif
# Don't install utils, examples, or projects they are only used to
# build LLVM.
ifeq ($(MAKECMDGOALS),install)
DIRS := $(filter-out utils, $(DIRS))
OPTIONAL_DIRS :=
endif
EXTRA_DIST := test llvm.spec include
# Include the main makefile machinery.
include $(LLVM_SRC_ROOT)/Makefile.rules
include $(LEVEL)/Makefile.common
# Specify options to pass to configure script when we're
# running the dist-check target
@@ -99,33 +69,3 @@ $(FilesToConfigPATH) : $(LLVM_OBJ_ROOT)/% : $(LLVM_SRC_ROOT)/%.in
$(Echo) Regenerating $*
$(Verb) cd $(LLVM_OBJ_ROOT) && $(ConfigStatusScript) $*
.PRECIOUS: $(FilesToConfigPATH)
# NOTE: This needs to remain as the last target definition in this file so
# that it gets executed last.
all::
$(Echo) '*****' Completed $(BuildMode)$(AssertMode) Build
ifeq ($(BuildMode),Debug)
$(Echo) '*****' Note: Debug build can be 10 times slower than an
$(Echo) '*****' optimized build. Use 'make ENABLE_OPTIMIZED=1' to
$(Echo) '*****' make an optimized build.
endif
check-llvm2cpp:
$(Verb)$(MAKE) check TESTSUITE=Feature RUNLLVM2CPP=1
check-one:
$(Verb)$(MAKE) -C test check-one TESTONE=$(TESTONE)
srpm: $(LLVM_OBJ_ROOT)/llvm.spec
rpmbuild -bs $(LLVM_OBJ_ROOT)/llvm.spec
rpm: $(LLVM_OBJ_ROOT)/llvm.spec
rpmbuild -bb --target $(TARGET_TRIPLE) $(LLVM_OBJ_ROOT)/llvm.spec
show-footprint:
$(Verb) du -sk $(LibDir)
$(Verb) du -sk $(ToolDir)
$(Verb) du -sk $(ExmplDir)
$(Verb) du -sk $(ObjDir)
.PHONY: srpm rpm

View File

@@ -33,22 +33,28 @@ LLVM_CONFIGTIME := @LLVM_CONFIGTIME@
#
###########################################################################
PWD := @BINPWD@
# Set the project name to LLVM if its not defined
ifndef PROJECT_NAME
PROJECT_NAME := $(LLVMPackageName)
PROJECT_NAME := LLVM
endif
PROJ_OBJ_DIR := $(shell $(PWD))
PROJ_OBJ_ROOT := $(shell cd $(PROJ_OBJ_DIR)/$(LEVEL); $(PWD))
PROJ_OBJ_DIR := $(shell pwd)
PROJ_OBJ_ROOT := $(subst //,/,$(shell cd $(PROJ_OBJ_DIR)/$(LEVEL); pwd))
ifeq ($(PROJECT_NAME),llvm)
LLVM_SRC_ROOT := $(shell cd @abs_top_srcdir@; $(PWD))
LLVM_OBJ_ROOT := $(shell cd @abs_top_builddir@; $(PWD))
PROJ_SRC_ROOT := $(shell cd $(LLVM_SRC_ROOT); $(PWD))
PROJ_SRC_DIR := $(shell cd $(LLVM_SRC_ROOT)/$(patsubst $(PROJ_OBJ_ROOT)%,%,$(PROJ_OBJ_DIR)); $(PWD))
prefix := @prefix@
PROJ_prefix := $(prefix)
ifeq ($(PROJECT_NAME),LLVM)
LLVM_SRC_ROOT := @abs_top_srcdir@
LLVM_OBJ_ROOT := @abs_top_builddir@
PROJ_SRC_ROOT := $(LLVM_SRC_ROOT)
PROJ_SRC_DIR := $(subst //,/,$(LLVM_SRC_ROOT)/$(patsubst $(PROJ_OBJ_ROOT)%,%,$(PROJ_OBJ_DIR)))
PROJ_prefix := @prefix@
PROJ_bindir := @prefix@/bin
PROJ_libdir := @prefix@/lib
PROJ_datadir := @prefix@/share
PROJ_docsdir := @prefix@/docs/llvm
PROJ_etcdir := @prefix@/etc/llvm
PROJ_includedir := @prefix@/include
PROJ_infodir := @prefix@/info
PROJ_mandir := @prefix@/man
PROJ_VERSION := $(LLVMVersion)
else
ifndef PROJ_SRC_ROOT
@@ -66,25 +72,21 @@ endif
ifndef LLVM_OBJ_ROOT
$(error Projects must define LLVM_OBJ_ROOT)
endif
PROJ_SRC_DIR := $(shell cd $(PROJ_SRC_ROOT)/$(patsubst $(PROJ_OBJ_ROOT)%,%,$(PROJ_OBJ_DIR)); $(PWD))
prefix := $(PROJ_INSTALL_ROOT)
PROJ_prefix := $(prefix)
PROJ_SRC_DIR := $(subst //,/,$(PROJ_SRC_ROOT)/$(patsubst $(PROJ_OBJ_ROOT)%,%,$(PROJ_OBJ_DIR)))
PROJ_prefix := $(PROJ_INSTALL_ROOT)
PROJ_bindir := $(PROJ_INSTALL_ROOT)/bin
PROJ_libdir := $(PROJ_INSTALL_ROOT)/lib
PROJ_datadir := $(PROJ_INSTALL_ROOT)/share
PROJ_docsdir := $(PROJ_INSTALL_ROOT)/docs/llvm
PROJ_etcdir := $(PROJ_INSTALL_ROOT)/etc/llvm
PROJ_includedir := $(PROJ_INSTALL_ROOT)/include
PROJ_infodir := $(PROJ_INSTALL_ROOT)/info
PROJ_mandir := $(PROJ_INSTALL_ROOT)/man
ifndef PROJ_VERSION
PROJ_VERSION := 1.0
endif
endif
LLVMMAKE := $(LLVM_SRC_ROOT)/make
PROJ_bindir := $(DESTDIR)$(PROJ_prefix)/bin
PROJ_libdir := $(DESTDIR)$(PROJ_prefix)/lib
PROJ_datadir := $(DESTDIR)$(PROJ_prefix)/share
PROJ_docsdir := $(DESTDIR)$(PROJ_prefix)/docs/llvm
PROJ_etcdir := $(DESTDIR)$(PROJ_prefix)/etc/llvm
PROJ_includedir := $(DESTDIR)$(PROJ_prefix)/include
PROJ_infodir := $(DESTDIR)$(PROJ_prefix)/info
PROJ_mandir := $(DESTDIR)$(PROJ_prefix)/man
# Determine if we're on a unix type operating system
LLVM_ON_UNIX:=@LLVM_ON_UNIX@
LLVM_ON_WIN32:=@LLVM_ON_WIN32@
@@ -95,22 +97,12 @@ OS=@OS@
# Target hardware architecture
ARCH=@ARCH@
# Indicates, whether we're cross-compiling LLVM or not
LLVM_CROSS_COMPILING=@LLVM_CROSS_COMPILING@
# Executable file extension for build platform (mainly for
# tablegen call if we're cross-compiling).
BUILD_EXEEXT=@BUILD_EXEEXT@
# Target triple (cpu-vendor-os) for which we should generate code
TARGET_TRIPLE=@target@
# Targets that we should build
TARGETS_TO_BUILD=@TARGETS_TO_BUILD@
# Extra options to compile LLVM with
EXTRA_OPTIONS=@EXTRA_OPTIONS@
# Endian-ness of the target
ENDIAN=@ENDIAN@
@@ -127,9 +119,6 @@ LDFLAGS+=@LDFLAGS@
# Path to the library archiver program.
AR_PATH = @AR@
# Path to the nm program
NM_PATH = @NM@
# The pathnames of the programs we require to build
BISON := @BISON@
CMP := @CMP@
@@ -148,7 +137,6 @@ TAR := @TAR@
YACC := @YACC@
# Paths to miscellaneous programs we hope are present but might not be
PERL := @PERL@
BZIP2 := @BZIP2@
DOT := @DOT@
DOXYGEN := @DOXYGEN@
@@ -162,9 +150,6 @@ RUNTEST := @RUNTEST@
TCLSH := @TCLSH@
ZIP := @ZIP@
HAVE_PERL := @HAVE_PERL@
HAVE_PTHREAD := @HAVE_PTHREAD@
LIBS := @LIBS@
# Path to location for LLVM C/C++ front-end. You can modify this if you
@@ -172,23 +157,13 @@ LIBS := @LIBS@
LLVMGCCDIR := @LLVMGCCDIR@
# Determine the target for which LLVM should generate code.
ifeq (@LLVMGCC_MAJVERS@,3)
LLVMGCCARCH := @target@/3.4-llvm
else
LLVMGCCARCH := @target@/@LLVMGCC_VERSION@
endif
# Determine the path where the library executables are
LLVMGCCLIBEXEC := @LLVMGCCLIBEXEC@
# Full pathnames of LLVM C/C++ front-end 'cc1' and 'cc1plus' binaries:
LLVMGCC := @LLVMGCC@
LLVMGXX := @LLVMGXX@
LLVMCC1 := @LLVMCC1@
LLVMCC1PLUS := @LLVMCC1PLUS@
LLVMGCC_VERSION := @LLVMGCC_VERSION@
LLVMGCC_MAJVERS := @LLVMGCC_MAJVERS@
LLVMGCC_LANGS := @LLVMGCC_LANGS@
# Path to directory where object files should be stored during a build.
# Set OBJ_ROOT to "." if you do not want to use a separate place for
@@ -198,22 +173,11 @@ OBJ_ROOT := .
# These are options that can either be enabled here, or can be enabled on the
# make command line (ie, make ENABLE_PROFILING=1):
# When ENABLE_OPTIMIZED is enabled, LLVM code is optimized and output is put
# into the "Release" directories. Otherwise, LLVM code is not optimized and
# output is put in the "Debug" directories.
# When ENABLE_OPTIMIZED is enabled, Release builds of all of the LLVM code are
# turned on, and Debug builds are turned off.
#ENABLE_OPTIMIZED = 1
@ENABLE_OPTIMIZED@
# When DISABLE_ASSERTIONS is enabled, builds of all of the LLVM code will
# exclude assertion checks, otherwise they are included.
#DISABLE_ASSERTIONS = 1
@DISABLE_ASSERTIONS@
# When DEBUG_RUNTIME is enabled, the runtime libraries will retain debug
# symbols.
#DEBUG_RUNTIME = 1
@DEBUG_RUNTIME@
# When ENABLE_PROFILING is enabled, the llvm source base is built with profile
# information to allow gprof to be used to get execution frequencies.
#ENABLE_PROFILING = 1
@@ -221,35 +185,18 @@ OBJ_ROOT := .
# When ENABLE_DOXYGEN is enabled, the doxygen documentation will be built
ENABLE_DOXYGEN = @ENABLE_DOXYGEN@
# Do we want to enable threads?
ENABLE_THREADS := @ENABLE_THREADS@
# Do we want to build with position independent code?
ENABLE_PIC := @ENABLE_PIC@
# This option tells the Makefiles to produce verbose output.
# It essentially prints the commands that make is executing
#VERBOSE = 1
# Enable JIT for this platform
TARGET_HAS_JIT = @TARGET_HAS_JIT@
@JIT@
# Shared library extension for host platform.
# Shared library extension for this platform.
SHLIBEXT = @SHLIBEXT@
# Executable file extension for host platform.
# Executable file extension for this platform.
EXEEXT = @EXEEXT@
# Things we just assume are "there"
ECHO := echo
# Get the options for causing archives to link all their content instead of
# just missing symbols, and the inverse of that. This is used for certain LLVM
# tools that permit loadable modules. It ensures that the LLVM symbols will be
# available to those loadable modules.
LINKALL := @LINKALL@
NOLINKALL := @NOLINKALL@
# Get the value of HUGE_VAL_SANITY which will be either "yes" or "no" depending
# on the check.
HUGE_VAL_SANITY = @HUGE_VAL_SANITY@

File diff suppressed because it is too large Load Diff

View File

@@ -10,4 +10,3 @@ the license agreement found in LICENSE.txt.
Please see the HTML documentation provided in docs/index.html for further
assistance with LLVM.

File diff suppressed because it is too large Load Diff

View File

@@ -7,14 +7,22 @@ outfile=configure
configfile=configure.ac
test -d autoconf && test -f autoconf/$configfile && cd autoconf
test -f $configfile || die "Can't find 'autoconf' dir; please cd into it first"
autoconf --version | grep '2\.60' > /dev/null
test $? -eq 0 || die "Your autoconf was not detected as being 2.60"
aclocal --version | grep '^aclocal.*1\.9\.6' > /dev/null
test $? -eq 0 || die "Your aclocal was not detected as being 1.9.6"
autoheader --version | grep '^autoheader.*2\.60' > /dev/null
test $? -eq 0 || die "Your autoheader was not detected as being 2.60"
libtool --version | grep '1\.5\.22' > /dev/null
test $? -eq 0 || die "Your libtool was not detected as being 1.5.22"
autoconf --version | egrep '2\.59' > /dev/null
if test $? -ne 0 ; then
die "Your autoconf was not detected as being 2.59"
fi
aclocal --version | egrep '1\.9\.2' > /dev/null
if test $? -ne 0 ; then
die "Your aclocal was not detected as being 1.9.2"
fi
autoheader --version | egrep '2\.59' > /dev/null
if test $? -ne 0 ; then
die "Your autoheader was not detected as being 2.59"
fi
libtool --version | grep '1\.5\.10' > /dev/null
if test $? -ne 0 ; then
die "Your libtool was not detected as being 1.5.10"
fi
echo ""
echo "### NOTE: ############################################################"
echo "### If you get *any* warnings from autoconf below you MUST fix the"
@@ -24,12 +32,12 @@ echo "### commit any configure script that was generated with warnings"
echo "### present. You should get just three 'Regenerating..' lines."
echo "######################################################################"
echo ""
echo "Regenerating aclocal.m4 with aclocal 1.9.6"
echo "Regenerating aclocal.m4 with aclocal 1.9.2"
cwd=`pwd`
aclocal --force -I $cwd/m4 || die "aclocal failed"
echo "Regenerating configure with autoconf 2.60"
echo "Regenerating configure with autoconf 2.59"
autoconf --force --warnings=all -o ../$outfile $configfile || die "autoconf failed"
cd ..
echo "Regenerating config.h.in with autoheader 2.60"
echo "Regenerating config.h.in with autoheader 2.59"
autoheader --warnings=all -I autoconf -I autoconf/m4 autoconf/$configfile || die "autoheader failed"
exit 0

View File

@@ -8,28 +8,19 @@ If you are in the mood to upgrade libtool, you must do the following:
3. Copy <SRC>/ltdl.m4 to llvm/autoconf/m4
4. Copy <PFX>/share/aclocal/libtool.m4 to llvm/autoconf/m4/libtool.m4
5. Copy <PFX>/share/libtool/ltmain.sh to llvm/autoconf/ltmain.sh
6. Copy <PFX>/share/libtool/libltdl/ltdl.c to llvm/lib/System
7. Copy <PFX>/share/libtool/libltdl/ltdl.h to llvm/lib/System
8. Edit the ltdl.h file to #include "llvm/Config/config.h" at the very top. You
might also need to resolve some compiler warnings (typically about
comparison of signed vs. unsigned values). But, you won't find out about
those until you build LLVM (step 13).
9. Edit the llvm/autoconf/m4/libtool.m4 file so that:
a) in AC_PROB_LIBTOOL macro, the value of LIBTOOL is set to
$(top_builddir)/mklib, not $(top_builddir)/libtool
b) in AC_LIBTOOL_SETUP macro, the variable default_ofile is set to
"mklib" instead of "libtool"
c) s/AC_ENABLE_SHARED_DEFAULT/enable_shared_default/g
d) s/AC_ENABLE_STATIC_DEFAULT/enable_static_default/g
e) s/AC_ENABLE_FAST_INSTALL_DEFAULT/enable_fast_install_default/g
6. Run sed -e 's/output.exp/outputname.exp/g' on ltmain.sh
7. Copy <PFX>/share/libtool/libltdl/ltdl.c to llvm/lib/System
8. Copy <PFX>/share/libtool/libltdl/ltdl.h to llvm/lib/System
9. Adjust the llvm/autoconf/m4/libtool.m4 file to ensure that the variable
default_ofile is set to "mklib" instead of "libtool"
10. Run "autoupdate libtool.m4 ltdl.m4" in the llvm/autoconf/m4 directory.
This should correctly update the macro definitions in the libtool m4
files to match the version of autoconf that LLVM uses. This converts
AC_HELP_STRING to AS_HELP_STRING and AC_TRY_LINK to AC_LINK_IFELSE, amongst
other things. You may need to manually adjust the files.
11. Run AutoRegen.sh to get the new macros into configure script
12. If there are any warnings from AutoRegen.sh, go to step 9.
13. Rebuild LLVM, making sure it reconfigures
12. If there are any warnings from configure, go to step 9.
13. Rebuild LLVM, making sure it reconfigured
14. Test the JIT which uses libltdl
15. If it all works, only THEN commit the changes.
@@ -45,5 +36,5 @@ If you are in the mood to upgrade autoconf, you should:
5. Run autoupdate on all the m4 macros in llvm/autoconf/m4
6. Run autoupdate on llvm/autoconf/configure.ac
7. Regenerate configure script with AutoRegen.sh
8. If there are any warnings from AutoRegen.sh, fix them and go to step 7.
8. If there are any warnings from autoconf, fix them and go to step 7.
9. Test, test, test.

View File

@@ -31,12 +31,12 @@ dnl===
dnl===-----------------------------------------------------------------------===
dnl Initialize autoconf and define the package name, version number and
dnl email address for reporting bugs.
AC_INIT([[llvm]],[[2.0]],[llvmbugs@cs.uiuc.edu])
AC_INIT([[llvm]],[[1.6]],[llvmbugs@cs.uiuc.edu])
dnl Provide a copyright substitution and ensure the copyright notice is included
dnl in the output of --version option of the generated configure script.
AC_SUBST(LLVM_COPYRIGHT,["Copyright (c) 2003-2007 University of Illinois at Urbana-Champaign."])
AC_COPYRIGHT([Copyright (c) 2003-2007 University of Illinois at Urbana-Champaign.])
AC_SUBST(LLVM_COPYRIGHT,["Copyright (c) 2003-2005 University of Illinois at Urbana-Champaign."])
AC_COPYRIGHT([Copyright (c) 2003-2005 University of Illinois at Urbana-Champaign.])
dnl Indicate that we require autoconf 2.59 or later. Ths is needed because we
dnl use some autoconf macros only available in 2.59.
@@ -66,17 +66,15 @@ for i in `ls ${srcdir}/projects`
do
if test -d ${srcdir}/projects/${i} ; then
case ${i} in
CVS) ;;
sample) AC_CONFIG_SUBDIRS([projects/sample]) ;;
privbracket) AC_CONFIG_SUBDIRS([projects/privbracket]) ;;
llvm-stacker) AC_CONFIG_SUBDIRS([projects/llvm-stacker]) ;;
llvm-test) AC_CONFIG_SUBDIRS([projects/llvm-test]) ;;
llvm-reopt) AC_CONFIG_SUBDIRS([projects/llvm-reopt]);;
llvm-gcc) AC_CONFIG_SUBDIRS([projects/llvm-gcc]) ;;
llvm-java) AC_CONFIG_SUBDIRS([projects/llvm-java]) ;;
llvm-tv) AC_CONFIG_SUBDIRS([projects/llvm-tv]) ;;
llvm-poolalloc) AC_CONFIG_SUBDIRS([projects/llvm-poolalloc]) ;;
llvm-kernel) AC_CONFIG_SUBDIRS([projects/llvm-kernel]) ;;
"CVS") ;;
"sample") AC_CONFIG_SUBDIRS([projects/sample]) ;;
"Stacker") AC_CONFIG_SUBDIRS([projects/Stacker]) ;;
"llvm-test") AC_CONFIG_SUBDIRS([projects/llvm-test]) ;;
"llvm-reopt") AC_CONFIG_SUBDIRS([projects/llvm-reopt]);;
"llvm-gcc") AC_CONFIG_SUBDIRS([projects/llvm-gcc]) ;;
"llvm-java") AC_CONFIG_SUBDIRS([projects/llvm-java]) ;;
"llvm-tv") AC_CONFIG_SUBDIRS([projects/llvm-tv]) ;;
"llvm-poolalloc") AC_CONFIG_SUBDIRS([projects/llvm-poolalloc]) ;;
*)
AC_MSG_WARN([Unknown project (${i}) won't be configured automatically])
;;
@@ -98,77 +96,40 @@ AC_CANONICAL_TARGET
dnl Determine the platform type and cache its value. This helps us configure
dnl the System library to the correct build platform.
AC_CACHE_CHECK([type of operating system we're going to host on],
AC_CACHE_CHECK([type of operating system we're on],
[llvm_cv_os_type],
[case $host in
[case $build in
*-*-aix*)
llvm_cv_link_all_option="-Wl,--whole-archive"
llvm_cv_no_link_all_option="-Wl,--no-whole-archive"
llvm_cv_os_type="AIX"
llvm_cv_platform_type="Unix" ;;
*-*-irix*)
llvm_cv_link_all_option="-Wl,--whole-archive"
llvm_cv_no_link_all_option="-Wl,--no-whole-archive"
llvm_cv_os_type="IRIX"
llvm_cv_platform_type="Unix" ;;
*-*-cygwin*)
llvm_cv_link_all_option="-Wl,--whole-archive"
llvm_cv_no_link_all_option="-Wl,--no-whole-archive"
llvm_cv_os_type="Cygwin"
llvm_cv_platform_type="Unix" ;;
*-*-darwin*)
llvm_cv_link_all_option="-Wl,-all_load"
llvm_cv_link_all_option="-Wl,-noall_load"
llvm_cv_os_type="Darwin"
llvm_cv_platform_type="Unix" ;;
*-*-freebsd*)
llvm_cv_link_all_option="-Wl,--whole-archive"
llvm_cv_no_link_all_option="-Wl,--no-whole-archive"
llvm_cv_os_type="FreeBSD"
llvm_cv_platform_type="Unix" ;;
*-*-openbsd*)
llvm_cv_link_all_option="-Wl,--whole-archive"
llvm_cv_no_link_all_option="-Wl,--no-whole-archive"
llvm_cv_os_type="OpenBSD"
llvm_cv_platform_type="Unix" ;;
*-*-netbsd*)
llvm_cv_link_all_option="-Wl,--whole-archive"
llvm_cv_no_link_all_option="-Wl,--no-whole-archive"
llvm_cv_os_type="NetBSD"
llvm_cv_platform_type="Unix" ;;
*-*-hpux*)
llvm_cv_link_all_option="-Wl,--whole-archive"
llvm_cv_no_link_all_option="-Wl,--no-whole-archive"
llvm_cv_os_type="HP-UX"
llvm_cv_platform_type="Unix" ;;
*-*-interix*)
llvm_cv_link_all_option="-Wl,--whole-archive"
llvm_cv_no_link_all_option="-Wl,--no-whole-archive"
llvm_cv_os_type="Interix"
llvm_cv_platform_type="Unix" ;;
*-*-linux*)
llvm_cv_link_all_option="-Wl,--whole-archive"
llvm_cv_no_link_all_option="-Wl,--no-whole-archive"
llvm_cv_os_type="Linux"
llvm_cv_platform_type="Unix" ;;
*-*-solaris*)
llvm_cv_link_all_option="-Wl,-z,allextract"
llvm_cv_no_link_all_option="-Wl,-z,defaultextract"
llvm_cv_os_type="SunOS"
llvm_cv_platform_type="Unix" ;;
*-*-win32*)
llvm_cv_link_all_option="-Wl,--whole-archive"
llvm_cv_no_link_all_option="-Wl,--no-whole-archive"
llvm_cv_os_type="Win32"
llvm_cv_platform_type="Win32" ;;
*-*-mingw*)
llvm_cv_link_all_option="-Wl,--whole-archive"
llvm_cv_no_link_all_option="-Wl,--no-whole-archive"
llvm_cv_os_type="MingW"
llvm_cv_platform_type="Win32" ;;
*)
llvm_cv_link_all_option=""
llvm_cv_no_link_all_option=""
llvm_cv_os_type="Unknown"
llvm_cv_platform_type="Unknown" ;;
esac])
@@ -182,10 +143,6 @@ dnl Set the "OS" Makefile variable based on the platform type so the
dnl makefile can configure itself to specific build hosts
AC_SUBST(OS,$llvm_cv_os_type)
dnl Set the LINKALL and NOLINKALL Makefile variables based on the platform
AC_SUBST(LINKALL,$llvm_cv_link_all_option)
AC_SUBST(NOLINKALL,$llvm_cv_no_link_all_option)
dnl Set the "LLVM_ON_*" variables based on llvm_cvs_platform_type
dnl This is used by lib/System to determine the basic kind of implementation
dnl to use.
@@ -213,7 +170,6 @@ AC_CACHE_CHECK([target architecture],[llvm_cv_target_arch],
powerpc*-*) llvm_cv_target_arch="PowerPC" ;;
alpha*-*) llvm_cv_target_arch="Alpha" ;;
ia64-*) llvm_cv_target_arch="IA64" ;;
arm-*) llvm_cv_target_arch="ARM" ;;
*) llvm_cv_target_arch="Unknown" ;;
esac])
@@ -227,29 +183,6 @@ AC_SUBST(ARCH,$llvm_cv_target_arch)
dnl Check for the endianness of the target
AC_C_BIGENDIAN(AC_SUBST([ENDIAN],[big]),AC_SUBST([ENDIAN],[little]))
dnl Check for build platform executable suffix if we're crosscompiling
if test "$cross_compiling" = yes; then
AC_SUBST(LLVM_CROSS_COMPILING, [1])
AC_BUILD_EXEEXT
else
AC_SUBST(LLVM_CROSS_COMPILING, [0])
fi
dnl Check to see if there's a "CVS" (or .svn) directory indicating that this
dnl build is being done from a checkout. This sets up several defaults for the
dnl command line switches. When we build with a CVS directory, we get a
dnl debug with assertions turned on. Without, we assume a source release and we
dnl get an optimized build without assertions. See --enable-optimized and
dnl --enable-assertions below
if test -d "CVS" -o -d "${srcdir}/CVS" -o -d ".svn" -o -d "${srcdir}/.svn"; then
cvsbuild="yes"
optimize="no"
AC_SUBST(CVSBUILD,[[CVSBUILD=1]])
else
cvsbuild="no"
optimize="yes"
fi
dnl===-----------------------------------------------------------------------===
dnl===
dnl=== SECTION 3: Command line arguments for the configure script.
@@ -257,32 +190,14 @@ dnl===
dnl===-----------------------------------------------------------------------===
dnl --enable-optimized : check whether they want to do an optimized build:
AC_ARG_ENABLE(optimized, AS_HELP_STRING(
[--enable-optimized,Compile with optimizations enabled (default is NO)]),,enableval=$optimize)
AC_ARG_ENABLE(optimized,
AS_HELP_STRING([--enable-optimized,Compile with optimizations enabled (default is NO)]),,enableval=no)
if test ${enableval} = "no" ; then
AC_SUBST(ENABLE_OPTIMIZED,[[]])
else
AC_SUBST(ENABLE_OPTIMIZED,[[ENABLE_OPTIMIZED=1]])
fi
dnl --enable-assertions : check whether they want to turn on assertions or not:
AC_ARG_ENABLE(assertions,AS_HELP_STRING(
[--enable-assertions,Compile with assertion checks enabled (default is YES)]),, enableval="yes")
if test ${enableval} = "yes" ; then
AC_SUBST(DISABLE_ASSERTIONS,[[]])
else
AC_SUBST(DISABLE_ASSERTIONS,[[DISABLE_ASSERTIONS=1]])
fi
dnl --enable-debug-runtime : should runtime libraries have debug symbols?
AC_ARG_ENABLE(debug-runtime,
AS_HELP_STRING([--enable-debug-runtime,Build runtime libs with debug symbols (default is NO)]),,enableval=no)
if test ${enableval} = "no" ; then
AC_SUBST(DEBUG_RUNTIME,[[]])
else
AC_SUBST(DEBUG_RUNTIME,[[DEBUG_RUNTIME=1]])
fi
dnl --enable-jit: check whether they want to enable the jit
AC_ARG_ENABLE(jit,
AS_HELP_STRING(--enable-jit,
@@ -293,14 +208,13 @@ then
AC_SUBST(JIT,[[]])
else
case "$llvm_cv_target_arch" in
x86) AC_SUBST(TARGET_HAS_JIT,1) ;;
Sparc) AC_SUBST(TARGET_HAS_JIT,0) ;;
PowerPC) AC_SUBST(TARGET_HAS_JIT,1) ;;
x86_64) AC_SUBST(TARGET_HAS_JIT,1) ;;
Alpha) AC_SUBST(TARGET_HAS_JIT,1) ;;
IA64) AC_SUBST(TARGET_HAS_JIT,0) ;;
ARM) AC_SUBST(TARGET_HAS_JIT,0) ;;
*) AC_SUBST(TARGET_HAS_JIT,0) ;;
x86) AC_SUBST(JIT,[[TARGET_HAS_JIT=1]]) ;;
Sparc) AC_SUBST(JIT,[[TARGET_HAS_JIT=1]]) ;;
PowerPC) AC_SUBST(JIT,[[TARGET_HAS_JIT=1]]) ;;
x86_64) AC_SUBST(JIT,[[]]) ;;
Alpha) AC_SUBST(JIT,[[TARGET_HAS_JIT=1]]) ;;
IA64) AC_SUBST(JIT,[[]]) ;;
*) AC_SUBST(JIT,[[]]) ;;
esac
fi
@@ -320,45 +234,29 @@ dnl Allow disablement of threads
AC_ARG_ENABLE(threads,
AS_HELP_STRING([--enable-threads],
[Use threads if available (default is YES)]),,
enableval=default)
enableval=yes)
case "$enableval" in
yes) AC_SUBST(ENABLE_THREADS,[1]) ;;
no) AC_SUBST(ENABLE_THREADS,[0]) ;;
default) AC_SUBST(ENABLE_THREADS,[1]) ;;
*) AC_MSG_ERROR([Invalid setting for --enable-threads. Use "yes" or "no"]) ;;
esac
AC_DEFINE_UNQUOTED([ENABLE_THREADS],$ENABLE_THREADS,[Define if threads enabled])
dnl Allow building with position independent code
AC_ARG_ENABLE(pic,
AS_HELP_STRING([--enable-pic],
[Build LLVM with Position Independent Code (default is NO)]),,
enableval=default)
case "$enableval" in
yes) AC_SUBST(ENABLE_PIC,[1]) ;;
no) AC_SUBST(ENABLE_PIC,[0]) ;;
default) AC_SUBST(ENABLE_PIC,[0]) ;;
*) AC_MSG_ERROR([Invalid setting for --enable-pic. Use "yes" or "no"]) ;;
esac
AC_DEFINE_UNQUOTED([ENABLE_PIC],$ENABLE_PIC,
[Define if position independent code is enabled])
dnl Allow specific targets to be specified for building (or not)
TARGETS_TO_BUILD=""
AC_ARG_ENABLE([targets],AS_HELP_STRING([--enable-targets],
AC_ARG_ENABLE([targets],AS_HELP_STRING([--enable-target],
[Build specific host targets: all,host-only,{target-name} (default=all)]),,
enableval=all)
case "$enableval" in
all) TARGETS_TO_BUILD="X86 Sparc PowerPC Alpha IA64 ARM" ;;
all) TARGETS_TO_BUILD="X86 SparcV8 SparcV9 PowerPC Alpha IA64 Skeleton" ;;
host-only)
case "$llvm_cv_target_arch" in
x86) TARGETS_TO_BUILD="X86" ;;
x86_64) TARGETS_TO_BUILD="X86" ;;
Sparc) TARGETS_TO_BUILD="Sparc" ;;
Sparc) TARGETS_TO_BUILD="SparcV8 SparcV9" ;;
PowerPC) TARGETS_TO_BUILD="PowerPC" ;;
Alpha) TARGETS_TO_BUILD="Alpha" ;;
IA64) TARGETS_TO_BUILD="IA64" ;;
ARM) TARGETS_TO_BUILD="ARM" ;;
*) AC_MSG_ERROR([Can not set target to build]) ;;
esac
;;
@@ -366,34 +264,19 @@ case "$enableval" in
case "$a_target" in
x86) TARGETS_TO_BUILD="X86 $TARGETS_TO_BUILD" ;;
x86_64) TARGETS_TO_BUILD="X86 $TARGETS_TO_BUILD" ;;
sparc) TARGETS_TO_BUILD="Sparc $TARGETS_TO_BUILD" ;;
sparc) TARGETS_TO_BUILD="SparcV8 SparcV9 $TARGETS_TO_BUILD" ;;
powerpc) TARGETS_TO_BUILD="PowerPC $TARGETS_TO_BUILD" ;;
alpha) TARGETS_TO_BUILD="Alpha $TARGETS_TO_BUILD" ;;
ia64) TARGETS_TO_BUILD="IA64 $TARGETS_TO_BUILD" ;;
arm) TARGETS_TO_BUILD="ARM $TARGETS_TO_BUILD" ;;
skeleton)TARGETS_TO_BUILD="Skeleton $TARGETS_TO_BUILD";;
*) AC_MSG_ERROR([Unrecognized target $a_target]) ;;
esac
done
;;
esac
TARGETS_TO_BUILD="CBackend MSIL $TARGETS_TO_BUILD"
TARGETS_TO_BUILD="CBackend $TARGETS_TO_BUILD"
AC_SUBST(TARGETS_TO_BUILD,$TARGETS_TO_BUILD)
dnl Prevent the CBackend from using printf("%a") for floating point so older
dnl C compilers that cannot deal with the 0x0p+0 hex floating point format
dnl can still compile the CBE's output
AC_ARG_ENABLE([cbe-printf-a],AS_HELP_STRING([--enable-cbe-printf-a],
[Enable C Backend output with hex floating point via %a (default is YES)]),,
enableval=default)
case "$enableval" in
yes) AC_SUBST(ENABLE_CBE_PRINTF_A,[1]) ;;
no) AC_SUBST(ENABLE_CBE_PRINTF_A,[0]) ;;
default) AC_SUBST(ENABLE_CBE_PRINTF_A,[1]) ;;
*) AC_MSG_ERROR([Invalid setting for --enable-cbe-printf-a. Use "yes" or "no"]) ;;
esac
AC_DEFINE_UNQUOTED([ENABLE_CBE_PRINTF_A],$ENABLE_CBE_PRINTF_A,
[Define if CBE is enabled for printf %a output])
dnl Allow a specific llvm-gcc/llvm-g++ pair to be used with this LLVM config.
AC_ARG_WITH(llvmgccdir,
AS_HELP_STRING([--with-llvmgccdir],
@@ -401,20 +284,10 @@ AC_ARG_WITH(llvmgccdir,
withval=default)
case "$withval" in
default) WITH_LLVMGCCDIR=default ;;
/* | [[A-Za-z]]:[[\\/]]*) WITH_LLVMGCCDIR=$withval ;;
/*) WITH_LLVMGCCDIR=$withval ;;
*) AC_MSG_ERROR([Invalid path for --with-llvmgccdir. Provide full path]) ;;
esac
dnl Specify extra build options
AC_ARG_WITH(extra-options,
AS_HELP_STRING([--with-extra-options],
[Specify addtional options to compile LLVM with]),,
withval=default)
case "$withval" in
default) EXTRA_OPTIONS= ;;
*) EXTRA_OPTIONS=$withval ;;
esac
AC_SUBST(EXTRA_OPTIONS,$EXTRA_OPTIONS)
dnl===-----------------------------------------------------------------------===
dnl===
@@ -429,9 +302,6 @@ AC_PROG_CXX(g++)
AC_PROG_FLEX
AC_PROG_BISON
AC_PROG_NM
AC_SUBST(NM)
dnl Check for the tools that the makefiles require
AC_CHECK_GNU_MAKE
AC_PROG_LN_S
@@ -446,59 +316,18 @@ AC_PROG_RANLIB
AC_PATH_PROG(RM, [rm], [rm])
AC_PATH_PROG(SED, [sed], [sed])
AC_PATH_PROG(TAR, [tar], [gtar])
AC_PATH_PROG(BINPWD,[pwd], [pwd])
dnl Looking for misc. graph plotting software
AC_PATH_PROG(GRAPHVIZ, [Graphviz], [echo Graphviz])
if test "$GRAPHVIZ" != "echo Graphviz" ; then
AC_DEFINE([HAVE_GRAPHVIZ],[1],[Define if the Graphviz program is available])
dnl If we're targeting for mingw we should emit windows paths, not msys
if test "$llvm_cv_os_type" = "MingW" ; then
GRAPHVIZ=`echo $GRAPHVIZ | sed 's/^\/\([[A-Za-z]]\)\//\1:\//' `
fi
AC_DEFINE_UNQUOTED([LLVM_PATH_GRAPHVIZ],"$GRAPHVIZ${EXEEXT}",
AC_DEFINE_UNQUOTED([LLVM_PATH_GRAPHVIZ],"$GRAPHVIZ",
[Define to path to Graphviz program if found or 'echo Graphviz' otherwise])
fi
AC_PATH_PROG(DOT, [dot], [echo dot])
if test "$DOT" != "echo dot" ; then
AC_DEFINE([HAVE_DOT],[1],[Define if the dot program is available])
dnl If we're targeting for mingw we should emit windows paths, not msys
if test "$llvm_cv_os_type" = "MingW" ; then
DOT=`echo $DOT | sed 's/^\/\([[A-Za-z]]\)\//\1:\//' `
fi
AC_DEFINE_UNQUOTED([LLVM_PATH_DOT],"$DOT${EXEEXT}",
[Define to path to dot program if found or 'echo dot' otherwise])
fi
AC_PATH_PROGS(GV, [gv gsview32], [echo gv])
if test "$GV" != "echo gv" ; then
AC_PATH_PROG(GV, [gv], [echo gv])
if test "$GRAPHVIZ" != "echo gv" ; then
AC_DEFINE([HAVE_GV],[1],[Define if the gv program is available])
dnl If we're targeting for mingw we should emit windows paths, not msys
if test "$llvm_cv_os_type" = "MingW" ; then
GV=`echo $GV | sed 's/^\/\([[A-Za-z]]\)\//\1:\//' `
fi
AC_DEFINE_UNQUOTED([LLVM_PATH_GV],"$GV${EXEEXT}",
AC_DEFINE_UNQUOTED([LLVM_PATH_GV],"$GV",
[Define to path to gv program if found or 'echo gv' otherwise])
fi
AC_PATH_PROG(DOTTY, [dotty], [echo dotty])
if test "$DOTTY" != "echo dotty" ; then
AC_DEFINE([HAVE_DOTTY],[1],[Define if the dotty program is available])
dnl If we're targeting for mingw we should emit windows paths, not msys
if test "$llvm_cv_os_type" = "MingW" ; then
DOTTY=`echo $DOTTY | sed 's/^\/\([[A-Za-z]]\)\//\1:\//' `
fi
AC_DEFINE_UNQUOTED([LLVM_PATH_DOTTY],"$DOTTY${EXEEXT}",
[Define to path to dotty program if found or 'echo dotty' otherwise])
fi
dnl Look for a sufficiently recent version of Perl.
LLVM_PROG_PERL([5.006])
AC_SUBST(PERL)
if test x"$PERL" = xnone; then
AC_SUBST(HAVE_PERL,0)
AC_MSG_ERROR([perl is required but was not found, please install it])
else
AC_SUBST(HAVE_PERL,1)
fi
dnl Find the install program
AC_PROG_INSTALL
@@ -507,15 +336,17 @@ dnl Checks for documentation and testing tools that we can do without. If these
dnl are not found then they are set to "true" which always succeeds but does
dnl nothing. This just lets the build output show that we could have done
dnl something if the tool was available.
AC_PATH_PROG(BZIP2,[bzip2],[echo "Skipped: bzip2 not found"])
AC_PATH_PROG(DOXYGEN,[doxygen],[echo "Skipped: doxygen not found"])
AC_PATH_PROG(GROFF,[groff],[echo "Skipped: groff not found"])
AC_PATH_PROG(GZIP,[gzip],[echo "Skipped: gzip not found"])
AC_PATH_PROG(POD2HTML,[pod2html],[echo "Skipped: pod2html not found"])
AC_PATH_PROG(POD2MAN,[pod2man],[echo "Skipped: pod2man not found"])
AC_PATH_PROG(RUNTEST,[runtest],[echo "Skipped: runtest not found"])
AC_PATH_PROG(BZIP2,[bzip2],[true bzip2])
AC_PATH_PROG(DOT,[dot],[true dot])
AC_PATH_PROG(DOXYGEN,[doxygen],[true doxygen])
AC_PATH_PROG(ETAGS,[etags],[true etags])
AC_PATH_PROG(GROFF,[groff],[true groff])
AC_PATH_PROG(GZIP,[gzip],[true gzip])
AC_PATH_PROG(POD2HTML,[pod2html],[true pod2html])
AC_PATH_PROG(POD2MAN,[pod2man],[true pod2man])
AC_PATH_PROG(RUNTEST,[runtest],[true runtest])
DJ_AC_PATH_TCLSH
AC_PATH_PROG(ZIP,[zip],[echo "Skipped: zip not found"])
AC_PATH_PROG(ZIP,[zip],[true zip])
dnl Determine if the linker supports the -R option.
AC_LINK_USE_R
@@ -609,11 +440,7 @@ dnl===-----------------------------------------------------------------------===
dnl libelf is for sparc only; we can ignore it if we don't have it
AC_CHECK_LIB(elf, elf_begin)
AC_CHECK_LIB(m,sin)
if test "$llvm_cv_os_type" = "MingW" ; then
AC_CHECK_LIB(imagehlp, main)
AC_CHECK_LIB(psapi, main)
fi
dnl lt_dlopen may be required for plugin support.
AC_SEARCH_LIBS(lt_dlopen,ltdl,AC_DEFINE([HAVE_LT_DLOPEN],[1],
@@ -639,25 +466,6 @@ if test "$ENABLE_THREADS" -eq 1 ; then
[Have pthread_mutex_lock]))
fi
dnl Allow extra x86-disassembler library
AC_ARG_WITH(udis86,
AS_HELP_STRING([--with-udis86=<path>],
[Use udis86 external x86 disassembler library]),
[
AC_SUBST(USE_UDIS86, [1])
case "$withval" in
/usr/lib|yes) ;;
*) LDFLAGS="$LDFLAGS -L${withval}" ;;
esac
AC_CHECK_LIB(udis86, ud_init, [], [
echo "Error! You need to have libudis86 around."
exit -1
])
],
AC_SUBST(USE_UDIS86, [0]))
AC_DEFINE_UNQUOTED([USE_UDIS86],$USE_UDIS86,
[Define if use udis86 library])
dnl===-----------------------------------------------------------------------===
dnl===
dnl=== SECTION 6: Check for header files
@@ -676,15 +484,11 @@ AC_HEADER_SYS_WAIT
AC_HEADER_TIME
AC_CHECK_HEADERS([dlfcn.h execinfo.h fcntl.h inttypes.h limits.h link.h])
AC_CHECK_HEADERS([malloc.h setjmp.h signal.h stdint.h unistd.h utime.h])
AC_CHECK_HEADERS([windows.h sys/mman.h sys/param.h sys/resource.h sys/time.h])
AC_CHECK_HEADERS([sys/types.h malloc/malloc.h mach/mach.h])
AC_CHECK_HEADERS([malloc.h signal.h stdint.h unistd.h utime.h windows.h])
AC_CHECK_HEADERS([sys/mman.h sys/param.h sys/resource.h sys/time.h sys/types.h])
AC_CHECK_HEADERS([rw/stdex/hash_map.h rw/stdex/hash_set.h])
if test "$ENABLE_THREADS" -eq 1 ; then
AC_CHECK_HEADER(pthread.h,
AC_SUBST(HAVE_PTHREAD, 1),
AC_SUBST(HAVE_PTHREAD, 0))
else
AC_SUBST(HAVE_PTHREAD, 0)
AC_CHECK_HEADERS(pthread.h)
fi
dnl===-----------------------------------------------------------------------===
@@ -693,7 +497,6 @@ dnl=== SECTION 7: Check for types and structures
dnl===
dnl===-----------------------------------------------------------------------===
AC_HUGE_VAL_CHECK
AC_TYPE_PID_T
AC_TYPE_SIZE_T
AC_TYPE_SIGNAL
@@ -709,12 +512,10 @@ dnl=== SECTION 8: Check for specific functions needed
dnl===
dnl===-----------------------------------------------------------------------===
AC_CHECK_FUNCS([backtrace ceilf floorf roundf rintf nearbyintf getcwd ])
AC_CHECK_FUNCS([getpagesize getrusage getrlimit setrlimit gettimeofday])
AC_CHECK_FUNCS([isatty mkdtemp mkstemp ])
AC_CHECK_FUNCS([mktemp realpath sbrk setrlimit strdup strerror strerror_r ])
AC_CHECK_FUNCS([strtoll strtoq sysconf malloc_zone_statistics ])
AC_CHECK_FUNCS([setjmp longjmp sigsetjmp siglongjmp])
AC_CHECK_FUNCS([backtrace getcwd getpagesize getrusage gettimeofday ])
AC_CHECK_FUNCS([isatty mkdtemp mkstemp mktemp ])
AC_CHECK_FUNCS([realpath sbrk setrlimit strdup strerror strerror_r ])
AC_CHECK_FUNCS([strtoll strtoq sysconf])
AC_C_PRINTF_A
AC_FUNC_ALLOCA
AC_FUNC_RAND48
@@ -729,22 +530,22 @@ AC_CXX_HAVE_FWD_ITERATOR
AC_FUNC_ISNAN
AC_FUNC_ISINF
dnl Check for mmap support.We also need to know if /dev/zero is required to
dnl be opened for allocating RWX memory.
dnl Make sure we aren't attempting to configure for an unknown system
if test "$llvm_cv_platform_type" = "Unix" ; then
AC_FUNC_MMAP
AC_FUNC_MMAP_FILE
AC_NEED_DEV_ZERO_FOR_MMAP
dnl Check for mmap and mprotect support. We need both to do the JIT and for
dnl bytecode loading, etc. We also need to know if /dev/zero is required to
dnl be opened for allocating RWX memory.
AC_FUNC_MMAP
AC_FUNC_MMAP_FILE
AC_NEED_DEV_ZERO_FOR_MMAP
AC_CHECK_FUNC(mprotect,,
AC_MSG_ERROR([Function mprotect() required but not found]))
if test "$ac_cv_func_mmap_fixed_mapped" = "no"
then
AC_MSG_WARN([mmap() of a fixed address required but not supported])
fi
if test "$ac_cv_func_mmap_file" = "no"
then
AC_MSG_WARN([mmap() of files required but not found])
fi
if test "$ac_cv_func_mmap_fixed_mapped" = "no"
then
AC_MSG_WARN([mmap() of a fixed address required but not supported])
fi
if test "$ac_cv_func_mmap_file" = "no"
then
AC_MSG_WARN([mmap() of files required but not found])
fi
dnl===-----------------------------------------------------------------------===
@@ -758,8 +559,7 @@ AC_CACHE_CHECK([whether llvm-gcc is sane],[llvm_cv_llvmgcc_sanity],
[llvm_cv_llvmgcc_sanity="no"
if test -x "$LLVMGCC" ; then
cp /dev/null conftest.c
"$LLVMGCC" -emit-llvm -S -o - conftest.c | \
grep 'target datalayout =' > /dev/null 2>&1
"$LLVMGCC" -S -o - conftest.c | grep implementation > /dev/null 2>&1
if test $? -eq 0 ; then
llvm_cv_llvmgcc_sanity="yes"
fi
@@ -768,22 +568,12 @@ fi])
dnl Since we have a sane llvm-gcc, identify it and its sub-tools
if test "$llvm_cv_llvmgcc_sanity" = "yes" ; then
AC_MSG_CHECKING([llvm-gcc component support])
llvmcc1path=`"$LLVMGCC" --print-prog-name=cc1`
AC_SUBST(LLVMCC1,$llvmcc1path)
llvmcc1pluspath=`"$LLVMGCC" --print-prog-name=cc1plus`
AC_SUBST(LLVMCC1PLUS,$llvmcc1pluspath)
llvmgccdir=`echo "$llvmcc1path" | sed 's,/libexec/.*,,'`
AC_SUBST(LLVMGCCDIR,$llvmgccdir)
llvmgcclibexec=`echo "$llvmcc1path" | sed 's,/cc1,,'`
AC_SUBST(LLVMGCCLIBEXEC,$llvmgcclibexec)
llvmgccversion=[`"$LLVMGCC" -dumpversion 2>&1 | sed 's/^\([0-9.]*\).*/\1/'`]
llvmgccmajvers=[`echo $llvmgccversion | sed 's/^\([0-9]\).*/\1/'`]
AC_SUBST(LLVMGCC_VERSION,$llvmgccversion)
AC_SUBST(LLVMGCC_MAJVERS,$llvmgccmajvers)
llvmgcclangs=[`"$LLVMGCC" -v --help 2>&1 | grep '^Configured with:' | sed 's/^.*--enable-languages=\([^ -]*\).*/\1/'`]
AC_SUBST(LLVMGCC_LANGS,$llvmgcclangs)
AC_MSG_RESULT([ok])
fi
dnl Propagate the shared library extension that the libltdl checks did to
@@ -793,9 +583,6 @@ AC_SUBST(SHLIBEXT,$libltdl_cv_shlibext)
# Translate the various configuration directories and other basic
# information into substitutions that will end up in Makefile.config.in
# that these configured values can be used by the makefiles
if test "${prefix}" = "NONE" ; then
prefix="/usr/local"
fi
eval LLVM_PREFIX="${prefix}";
eval LLVM_BINDIR="${prefix}/bin";
eval LLVM_LIBDIR="${prefix}/lib";
@@ -860,15 +647,9 @@ AC_CONFIG_HEADERS([include/llvm/ADT/iterator])
dnl Configure the makefile's configuration data
AC_CONFIG_FILES([Makefile.config])
dnl Configure the RPM spec file for LLVM
AC_CONFIG_FILES([llvm.spec])
dnl Configure doxygen's configuration file
AC_CONFIG_FILES([docs/doxygen.cfg])
dnl Do the first stage of configuration for llvm-config.in.
AC_CONFIG_FILES([tools/llvm-config/llvm-config.in])
dnl Do special configuration of Makefiles
AC_CONFIG_COMMANDS([setup],,[llvm_src="${srcdir}"])
AC_CONFIG_MAKEFILE(Makefile)
@@ -885,3 +666,11 @@ AC_CONFIG_MAKEFILE(projects/Makefile)
dnl Finally, crank out the output
AC_OUTPUT
dnl Warn loudly if llvm-gcc was not obviously working
if test "$llvm_cv_llvmgcc_sanity" = "no" ; then
AC_MSG_WARN([***** llvm-gcc/llvm-g++ was not found, or does not appear to be ])
AC_MSG_WARN([***** working. Please make sure you have llvmgcc and llvmg++ in])
AC_MSG_WARN([***** your path before configuring LLVM. The runtime libraries])
AC_MSG_WARN([***** (llvm/runtime) will not be built but you should be able to])
AC_MSG_WARN([***** build the llvm tools.])
fi

File diff suppressed because it is too large Load Diff

View File

@@ -8,8 +8,7 @@
AC_DEFUN([AC_PROG_BISON],
[AC_CACHE_CHECK([],[llvm_cv_has_bison],[AC_PROG_YACC()])
if test "$YACC" != "bison -y"; then
AC_SUBST(BISON,[])
AC_MSG_WARN([bison not found, can't rebuild grammars])
AC_MSG_ERROR([bison not found but required])
else
AC_SUBST(BISON,[bison])
AC_SUBST(BISON,[bison],[location of bison])
fi])

View File

@@ -1,42 +0,0 @@
# Check for the extension used for executables on build platform.
# This is necessary for cross-compiling where the build platform
# may differ from the host platform.
AC_DEFUN([AC_BUILD_EXEEXT],
[
AC_MSG_CHECKING([for executable suffix on build platform])
AC_CACHE_VAL(ac_cv_build_exeext,
[if test "$CYGWIN" = yes || test "$MINGW32" = yes; then
ac_cv_build_exeext=.exe
else
ac_build_prefix=${build_alias}-
AC_CHECK_PROG(BUILD_CC, ${ac_build_prefix}gcc, ${ac_build_prefix}gcc)
if test -z "$BUILD_CC"; then
AC_CHECK_PROG(BUILD_CC, gcc, gcc)
if test -z "$BUILD_CC"; then
AC_CHECK_PROG(BUILD_CC, cc, cc, , , /usr/ucb/cc)
fi
fi
test -z "$BUILD_CC" && AC_MSG_ERROR([no acceptable cc found in \$PATH])
ac_build_link='${BUILD_CC-cc} -o conftest $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS 1>&AS_MESSAGE_LOG_FD'
rm -f conftest*
echo 'int main () { return 0; }' > conftest.$ac_ext
ac_cv_build_exeext=
if AC_TRY_EVAL(ac_build_link); then
for file in conftest.*; do
case $file in
*.c | *.o | *.obj) ;;
*) ac_cv_build_exeext=`echo $file | sed -e s/conftest//` ;;
esac
done
else
AC_MSG_ERROR([installation or configuration problem: compiler cannot create executables.])
fi
rm -f conftest*
test x"${ac_cv_build_exeext}" = x && ac_cv_build_exeext=blank
fi])
BUILD_EXEEXT=""
test x"${ac_cv_build_exeext}" != xblank && BUILD_EXEEXT=${ac_cv_build_exeext}
AC_MSG_RESULT(${ac_cv_build_exeext})
ac_build_exeext=$BUILD_EXEEXT
AC_SUBST(BUILD_EXEEXT)])

View File

@@ -4,11 +4,11 @@
AC_DEFUN([LLVM_CONFIG_PROJECT],
[AC_ARG_WITH([llvmsrc],
AS_HELP_STRING([--with-llvmsrc],[Location of LLVM Source Code]),
[llvm_src="$withval"],[llvm_src="]$1["])
[llvm_src="$withval"],[llvm_src=`cd ${srcdir}/../..; pwd`])
AC_SUBST(LLVM_SRC,$llvm_src)
AC_ARG_WITH([llvmobj],
AS_HELP_STRING([--with-llvmobj],[Location of LLVM Object Code]),
[llvm_obj="$withval"],[llvm_obj="]$2["])
[llvm_obj="$withval"],[llvm_obj=`cd ../..; pwd`])
AC_SUBST(LLVM_OBJ,$llvm_obj)
AC_CONFIG_COMMANDS([setup],,[llvm_src="${LLVM_SRC}"])
])

View File

@@ -51,7 +51,7 @@ AC_ARG_WITH($1[-inc],
eval pfxval=\$\{$1pfxdir\}
eval binval=\$\{$1bindir\}
eval incval=\$\{$1incdir\}
eval libval=\$\{$1libdir\}
eval libvar=\$\{$1libdir\}
if test "${pfxval}" != "nada" ; then
CHECK_STD_PROGRAM(${pfxval},$1,$2,$3)
elif test "${binval}" != "nada" ; then
@@ -64,7 +64,7 @@ elif test "${binval}" != "nada" ; then
AC_SUBST(allcapsname()[_BIN],${binval})
AC_SUBST(allcapsname()[_INC],${incval})
AC_SUBST(allcapsname()[_LIB],${libval})
AC_SUBST([USE_]allcapsname(),["USE_]allcapsname()[ = 1"])
AC_SUBST([USE_]allcapsname(),[1])
AC_MSG_RESULT([found via --with options])
else
AC_MSG_RESULT([failed])

View File

@@ -1,18 +0,0 @@
#
# This function determins if the the HUGE_VAL macro is compilable with the
# -pedantic switch or not. XCode < 2.4.1 doesn't get it right.
#
AC_DEFUN([AC_HUGE_VAL_CHECK],[
AC_CACHE_CHECK([for HUGE_VAL sanity], [ac_cv_huge_val_sanity],[
AC_LANG_PUSH([C++])
CXXFLAGS=-pedantic
AC_RUN_IFELSE(
AC_LANG_PROGRAM(
[#include <math.h>],
[double x = HUGE_VAL; return x != x; ]),
[ac_cv_huge_val_sanity=yes],[ac_cv_huge_val_sanity=no],
[ac_cv_huge_val_sanity=yes])
AC_LANG_POP([C++])
])
AC_SUBST(HUGE_VAL_SANITY,$ac_cv_huge_val_sanity)
])

File diff suppressed because it is too large Load Diff

View File

@@ -1,11 +1,26 @@
## ltdl.m4 - Configure ltdl for the target system. -*-Autoconf-*-
## Copyright (C) 1999-2000 Free Software Foundation, Inc.
##
## This file is free software; the Free Software Foundation gives
## unlimited permission to copy and/or distribute it, with or without
## modifications, as long as this notice is preserved.
## This program is free software; you can redistribute it and/or modify
## it under the terms of the GNU General Public License as published by
## the Free Software Foundation; either version 2 of the License, or
## (at your option) any later version.
##
## This program is distributed in the hope that it will be useful, but
## WITHOUT ANY WARRANTY; without even the implied warranty of
## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
## General Public License for more details.
##
## You should have received a copy of the GNU General Public License
## along with this program; if not, write to the Free Software
## Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
##
## As a special exception to the GNU General Public License, if you
## distribute this file as part of a program that contains a
## configuration script generated by Autoconf, you may include it under
## the same distribution terms that you use for the rest of that program.
# serial 7 AC_LIB_LTDL
# serial 6 AC_LIB_LTDL
# AC_WITH_LTDL
# ------------
@@ -42,7 +57,7 @@ fi
if test "x$with_included_ltdl" = xno; then
# If the included ltdl is not to be used. then Use the
# preinstalled libltdl we found.
AC_DEFINE([HAVE_LTDL], [1],
AC_DEFINE([HAVE_LTDL], 1,
[Define this if a modern libltdl is already installed])
LIBLTDL=-lltdl
fi
@@ -60,7 +75,7 @@ AC_CONFIG_SUBDIRS([libltdl])
# Perform all the checks necessary for compilation of the ltdl objects
# -- including compiler checks and header checks.
AC_DEFUN([AC_LIB_LTDL],
[AC_PREREQ(2.60)
[AC_PREREQ(2.59)
AC_REQUIRE([AC_PROG_CC])
AC_REQUIRE([AC_C_CONST])
AC_REQUIRE([AC_HEADER_STDC])
@@ -95,11 +110,11 @@ AC_CHECK_FUNCS([closedir opendir readdir])
# ----------------------
AC_DEFUN([AC_LTDL_ENABLE_INSTALL],
[AC_ARG_ENABLE([ltdl-install],
[AS_HELP_STRING([--enable-ltdl-install],[install libltdl])])
[AS_HELP_STRING([--enable-ltdl-install], [install libltdl])])
AM_CONDITIONAL(INSTALL_LTDL, test x"${enable_ltdl_install-no}" != xno)
AM_CONDITIONAL(CONVENIENCE_LTDL, test x"${enable_ltdl_convenience-no}" != xno)
])# AC_LTDL_ENABLE_INSTALL
])])# AC_LTDL_ENABLE_INSTALL
# AC_LTDL_SYS_DLOPEN_DEPLIBS
@@ -126,7 +141,7 @@ AC_CACHE_CHECK([whether deplibs are loaded by dlopen],
# Assuming the user has installed a libdl from somewhere, this is true
# If you are looking for one http://www.opendarwin.org/projects/dlcompat
libltdl_cv_sys_dlopen_deplibs=yes
;;
;;
gnu* | linux* | kfreebsd*-gnu | knetbsd*-gnu)
# GNU and its variants, using gnu ld.so (Glibc)
libltdl_cv_sys_dlopen_deplibs=yes
@@ -134,9 +149,6 @@ AC_CACHE_CHECK([whether deplibs are loaded by dlopen],
hpux10*|hpux11*)
libltdl_cv_sys_dlopen_deplibs=yes
;;
interix*)
libltdl_cv_sys_dlopen_deplibs=yes
;;
irix[[12345]]*|irix6.[[01]]*)
# Catch all versions of IRIX before 6.2, and indicate that we don't
# know how it worked for any of those versions.
@@ -178,9 +190,6 @@ AC_CACHE_CHECK([whether deplibs are loaded by dlopen],
solaris*)
libltdl_cv_sys_dlopen_deplibs=yes
;;
sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX* | sysv4*uw2*)
libltdl_cv_sys_dlopen_deplibs=yes
;;
esac
])
if test "$libltdl_cv_sys_dlopen_deplibs" != yes; then
@@ -201,7 +210,7 @@ module=yes
eval libltdl_cv_shlibext=$shrext_cmds
])
if test -n "$libltdl_cv_shlibext"; then
AC_DEFINE_UNQUOTED([LTDL_SHLIB_EXT], ["$libltdl_cv_shlibext"],
AC_DEFINE_UNQUOTED(LTDL_SHLIB_EXT, "$libltdl_cv_shlibext",
[Define to the extension used for shared libraries, say, ".so".])
fi
])# AC_LTDL_SHLIBEXT
@@ -214,7 +223,7 @@ AC_DEFUN([AC_LTDL_SHLIBPATH],
AC_CACHE_CHECK([which variable specifies run-time library path],
[libltdl_cv_shlibpath_var], [libltdl_cv_shlibpath_var="$shlibpath_var"])
if test -n "$libltdl_cv_shlibpath_var"; then
AC_DEFINE_UNQUOTED([LTDL_SHLIBPATH_VAR], ["$libltdl_cv_shlibpath_var"],
AC_DEFINE_UNQUOTED(LTDL_SHLIBPATH_VAR, "$libltdl_cv_shlibpath_var",
[Define to the name of the environment variable that determines the dynamic library search path.])
fi
])# AC_LTDL_SHLIBPATH
@@ -236,7 +245,7 @@ if test -n "$libltdl_cv_sys_search_path"; then
sys_search_path="$sys_search_path$PATH_SEPARATOR$dir"
fi
done
AC_DEFINE_UNQUOTED([LTDL_SYSSEARCHPATH], ["$sys_search_path"],
AC_DEFINE_UNQUOTED(LTDL_SYSSEARCHPATH, "$sys_search_path",
[Define to the system default library search path.])
fi
])# AC_LTDL_SYSSEARCHPATH
@@ -262,7 +271,7 @@ AC_DEFUN([AC_LTDL_OBJDIR],
rmdir .libs 2>/dev/null
fi
])
AC_DEFINE_UNQUOTED([LTDL_OBJDIR], ["$libltdl_cv_objdir/"],
AC_DEFINE_UNQUOTED(LTDL_OBJDIR, "$libltdl_cv_objdir/",
[Define to the sub-directory in which libtool stores uninstalled libraries.])
])# AC_LTDL_OBJDIR
@@ -280,7 +289,7 @@ AC_CACHE_CHECK([whether libtool supports -dlopen/-dlpreopen],
fi
])
if test x"$libltdl_cv_preloaded_symbols" = xyes; then
AC_DEFINE([HAVE_PRELOADED_SYMBOLS], [1],
AC_DEFINE(HAVE_PRELOADED_SYMBOLS, 1,
[Define if libtool can extract symbol lists from object files.])
fi
])# AC_LTDL_DLPREOPEN
@@ -360,15 +369,15 @@ EOF
if grep '^. nm_test_func ' "$ac_nlist" >/dev/null; then
:
else
echo "configure: cannot find nm_test_func in $ac_nlist" >&AS_MESSAGE_LOG_FD
echo "configure: cannot find nm_test_func in $ac_nlist" >&AS_MESSAGE_LOG_FD()
fi
fi
else
echo "configure: cannot run $lt_cv_sys_global_symbol_pipe" >&AS_MESSAGE_LOG_FD
echo "configure: cannot run $lt_cv_sys_global_symbol_pipe" >&AS_MESSAGE_LOG_FD()
fi
else
echo "configure: failed program was:" >&AS_MESSAGE_LOG_FD
cat conftest.c >&AS_MESSAGE_LOG_FD
echo "configure: failed program was:" >&AS_MESSAGE_LOG_FD()
cat conftest.c >&AS_MESSAGE_LOG_FD()
fi
rm -rf conftest*
])
@@ -396,7 +405,7 @@ if test x"$ac_cv_sys_symbol_underscore" = xyes; then
fi
if test x"$libltdl_cv_need_uscore" = xyes; then
AC_DEFINE([NEED_USCORE], [1],
AC_DEFINE(NEED_USCORE, 1,
[Define if dlsym() requires a leading underscore in symbol names.])
fi
])# AC_LTDL_DLSYM_USCORE

View File

@@ -1,16 +0,0 @@
dnl Check for a reasonable version of Perl.
dnl $1 - Minimum Perl version. Typically 5.006.
dnl
AC_DEFUN([LLVM_PROG_PERL], [
AC_PATH_PROG(PERL, [perl], [none])
if test "$PERL" != "none"; then
AC_MSG_CHECKING(for Perl $1 or newer)
if $PERL -e 'use $1;' 2>&1 > /dev/null; then
AC_MSG_RESULT(yes)
else
PERL=none
AC_MSG_RESULT(not found)
fi
fi
])

View File

@@ -5,26 +5,17 @@ dnl passes the sanity check.
dnl $1 - Name or full path of the program to run
dnl $2 - Argument to pass to print out identification string
dnl $3 - grep RE to match identification string
dnl $4 - set to 1 to make errors only a warning
AC_DEFUN([CHECK_PROGRAM_SANITY],
[
AC_MSG_CHECKING([sanity for program ]$1)
sanity="0"
sanity_path=`which $1 2>/dev/null`
if test "$?" -eq 0 -a -x "$sanity_path" ; then
sanity=`$1 $2 2>&1 | grep "$3"`
if test -z "$sanity" ; then
AC_MSG_RESULT([no])
sanity="0"
if test "$4" -eq 1 ; then
AC_MSG_WARN([Program ]$1[ failed to pass sanity check.])
else
AC_MSG_ERROR([Program ]$1[ failed to pass sanity check.])
fi
else
AC_MSG_RESULT([yes])
sanity="1"
AC_MSG_ERROR([Program ]$1[ failed to pass sanity check.])
fi
AC_MSG_RESULT([yes])
else
AC_MSG_RESULT([not found])
fi

23928
llvm/configure vendored

File diff suppressed because it is too large Load Diff

View File

@@ -70,12 +70,12 @@ memory. There are many different algorithms for alias analysis and many
different ways of classifying them: flow-sensitive vs flow-insensitive,
context-sensitive vs context-insensitive, field-sensitive vs field-insensitive,
unification-based vs subset-based, etc. Traditionally, alias analyses respond
to a query with a <a href="#MustMayNo">Must, May, or No</a> alias response,
to a query with a <a href="#MustNoMay">Must, May, or No</a> alias response,
indicating that two pointers always point to the same object, might point to the
same object, or are known to never point to the same object.</p>
<p>The LLVM <a
href="http://llvm.org/doxygen/classllvm_1_1AliasAnalysis.html"><tt>AliasAnalysis</tt></a>
href="http://llvm.cs.uiuc.edu/doxygen/classllvm_1_1AliasAnalysis.html"><tt>AliasAnalysis</tt></a>
class is the primary interface used by clients and implementations of alias
analyses in the LLVM system. This class is the common interface between clients
of alias analysis information and the implementations providing it, and is
@@ -102,7 +102,7 @@ know</a>.</p>
<div class="doc_text">
<p>The <a
href="http://llvm.org/doxygen/classllvm_1_1AliasAnalysis.html"><tt>AliasAnalysis</tt></a>
href="http://llvm.cs.uiuc.edu/doxygen/classllvm_1_1AliasAnalysis.html"><tt>AliasAnalysis</tt></a>
class defines the interface that the various alias analysis implementations
should support. This class exports two important enums: <tt>AliasResult</tt>
and <tt>ModRefResult</tt> which represent the result of an alias query or a
@@ -889,15 +889,9 @@ implementations. You can use them with commands like '<tt>opt -anders-aa -ds-aa
<div class="doc_text">
<p>The <tt>-print-alias-sets</tt> pass is exposed as part of the
<tt>opt</tt> tool to print out the Alias Sets formed by the <a
<tt>analyze</tt> tool to print out the Alias Sets formed by the <a
href="#ast"><tt>AliasSetTracker</tt></a> class. This is useful if you're using
the <tt>AliasSetTracker</tt> class. To use it, use something like:</p>
<div class="doc_code">
<pre>
% opt -ds-aa -print-alias-sets -disable-output
</pre>
</div>
the <tt>AliasSetTracker</tt> class.</p>
</div>
@@ -951,7 +945,7 @@ algorithm will have a lower number of may aliases).</p>
src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"></a>
<a href="mailto:sabre@nondot.org">Chris Lattner</a><br>
<a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
<a href="http://llvm.cs.uiuc.edu">LLVM Compiler Infrastructure</a><br>
Last modified: $Date$
</address>

View File

@@ -1,614 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>LLVM Bitcode File Format</title>
<link rel="stylesheet" href="llvm.css" type="text/css">
</head>
<body>
<div class="doc_title"> LLVM Bitcode File Format </div>
<ol>
<li><a href="#abstract">Abstract</a></li>
<li><a href="#overview">Overview</a></li>
<li><a href="#bitstream">Bitstream Format</a>
<ol>
<li><a href="#magic">Magic Numbers</a></li>
<li><a href="#primitives">Primitives</a></li>
<li><a href="#abbrevid">Abbreviation IDs</a></li>
<li><a href="#blocks">Blocks</a></li>
<li><a href="#datarecord">Data Records</a></li>
<li><a href="#abbreviations">Abbreviations</a></li>
<li><a href="#stdblocks">Standard Blocks</a></li>
</ol>
</li>
<li><a href="#llvmir">LLVM IR Encoding</a>
<ol>
<li><a href="#basics">Basics</a></li>
</ol>
</li>
</ol>
<div class="doc_author">
<p>Written by <a href="mailto:sabre@nondot.org">Chris Lattner</a>.
</p>
</div>
<!-- *********************************************************************** -->
<div class="doc_section"> <a name="abstract">Abstract</a></div>
<!-- *********************************************************************** -->
<div class="doc_text">
<p>This document describes the LLVM bitstream file format and the encoding of
the LLVM IR into it.</p>
</div>
<!-- *********************************************************************** -->
<div class="doc_section"> <a name="overview">Overview</a></div>
<!-- *********************************************************************** -->
<div class="doc_text">
<p>
What is commonly known as the LLVM bitcode file format (also, sometimes
anachronistically known as bytecode) is actually two things: a <a
href="#bitstream">bitstream container format</a>
and an <a href="#llvmir">encoding of LLVM IR</a> into the container format.</p>
<p>
The bitstream format is an abstract encoding of structured data, very
similar to XML in some ways. Like XML, bitstream files contain tags, and nested
structures, and you can parse the file without having to understand the tags.
Unlike XML, the bitstream format is a binary encoding, and unlike XML it
provides a mechanism for the file to self-describe "abbreviations", which are
effectively size optimizations for the content.</p>
<p>This document first describes the LLVM bitstream format, then describes the
record structure used by LLVM IR files.
</p>
</div>
<!-- *********************************************************************** -->
<div class="doc_section"> <a name="bitstream">Bitstream Format</a></div>
<!-- *********************************************************************** -->
<div class="doc_text">
<p>
The bitstream format is literally a stream of bits, with a very simple
structure. This structure consists of the following concepts:
</p>
<ul>
<li>A "<a href="#magic">magic number</a>" that identifies the contents of
the stream.</li>
<li>Encoding <a href="#primitives">primitives</a> like variable bit-rate
integers.</li>
<li><a href="#blocks">Blocks</a>, which define nested content.</li>
<li><a href="#datarecord">Data Records</a>, which describe entities within the
file.</li>
<li>Abbreviations, which specify compression optimizations for the file.</li>
</ul>
<p>Note that the <a
href="CommandGuide/html/llvm-bcanalyzer.html">llvm-bcanalyzer</a> tool can be
used to dump and inspect arbitrary bitstreams, which is very useful for
understanding the encoding.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection"><a name="magic">Magic Numbers</a>
</div>
<div class="doc_text">
<p>The first four bytes of the stream identify the encoding of the file. This
is used by a reader to know what is contained in the file.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection"><a name="primitives">Primitives</a>
</div>
<div class="doc_text">
<p>
A bitstream literally consists of a stream of bits. This stream is made up of a
number of primitive values that encode a stream of unsigned integer values.
These
integers are are encoded in two ways: either as <a href="#fixedwidth">Fixed
Width Integers</a> or as <a href="#variablewidth">Variable Width
Integers</a>.
</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection"> <a name="fixedwidth">Fixed Width Integers</a>
</div>
<div class="doc_text">
<p>Fixed-width integer values have their low bits emitted directly to the file.
For example, a 3-bit integer value encodes 1 as 001. Fixed width integers
are used when there are a well-known number of options for a field. For
example, boolean values are usually encoded with a 1-bit wide integer.
</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection"> <a name="variablewidth">Variable Width
Integers</a></div>
<div class="doc_text">
<p>Variable-width integer (VBR) values encode values of arbitrary size,
optimizing for the case where the values are small. Given a 4-bit VBR field,
any 3-bit value (0 through 7) is encoded directly, with the high bit set to
zero. Values larger than N-1 bits emit their bits in a series of N-1 bit
chunks, where all but the last set the high bit.</p>
<p>For example, the value 27 (0x1B) is encoded as 1011 0011 when emitted as a
vbr4 value. The first set of four bits indicates the value 3 (011) with a
continuation piece (indicated by a high bit of 1). The next word indicates a
value of 24 (011 << 3) with no continuation. The sum (3+24) yields the value
27.
</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection"> <a name="char6">6-bit characters</a></div>
<div class="doc_text">
<p>6-bit characters encode common characters into a fixed 6-bit field. They
represent the following characters with the following 6-bit values:</p>
<ul>
<li>'a' .. 'z' - 0 .. 25</li>
<li>'A' .. 'Z' - 26 .. 52</li>
<li>'0' .. '9' - 53 .. 61</li>
<li>'.' - 62</li>
<li>'_' - 63</li>
</ul>
<p>This encoding is only suitable for encoding characters and strings that
consist only of the above characters. It is completely incapable of encoding
characters not in the set.</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection"> <a name="wordalign">Word Alignment</a></div>
<div class="doc_text">
<p>Occasionally, it is useful to emit zero bits until the bitstream is a
multiple of 32 bits. This ensures that the bit position in the stream can be
represented as a multiple of 32-bit words.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection"><a name="abbrevid">Abbreviation IDs</a>
</div>
<div class="doc_text">
<p>
A bitstream is a sequential series of <a href="#blocks">Blocks</a> and
<a href="#datarecord">Data Records</a>. Both of these start with an
abbreviation ID encoded as a fixed-bitwidth field. The width is specified by
the current block, as described below. The value of the abbreviation ID
specifies either a builtin ID (which have special meanings, defined below) or
one of the abbreviation IDs defined by the stream itself.
</p>
<p>
The set of builtin abbrev IDs is:
</p>
<ul>
<li>0 - <a href="#END_BLOCK">END_BLOCK</a> - This abbrev ID marks the end of the
current block.</li>
<li>1 - <a href="#ENTER_SUBBLOCK">ENTER_SUBBLOCK</a> - This abbrev ID marks the
beginning of a new block.</li>
<li>2 - <a href="#DEFINE_ABBREV">DEFINE_ABBREV</a> - This defines a new
abbreviation.</li>
<li>3 - <a href="#UNABBREV_RECORD">UNABBREV_RECORD</a> - This ID specifies the
definition of an unabbreviated record.</li>
</ul>
<p>Abbreviation IDs 4 and above are defined by the stream itself, and specify
an <a href="#abbrev_records">abbreviated record encoding</a>.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection"><a name="blocks">Blocks</a>
</div>
<div class="doc_text">
<p>
Blocks in a bitstream denote nested regions of the stream, and are identified by
a content-specific id number (for example, LLVM IR uses an ID of 12 to represent
function bodies). Nested blocks capture the hierachical structure of the data
encoded in it, and various properties are associated with blocks as the file is
parsed. Block definitions allow the reader to efficiently skip blocks
in constant time if the reader wants a summary of blocks, or if it wants to
efficiently skip data they do not understand. The LLVM IR reader uses this
mechanism to skip function bodies, lazily reading them on demand.
</p>
<p>
When reading and encoding the stream, several properties are maintained for the
block. In particular, each block maintains:
</p>
<ol>
<li>A current abbrev id width. This value starts at 2, and is set every time a
block record is entered. The block entry specifies the abbrev id width for
the body of the block.</li>
<li>A set of abbreviations. Abbreviations may be defined within a block, or
they may be associated with all blocks of a particular ID.
</li>
</ol>
<p>As sub blocks are entered, these properties are saved and the new sub-block
has its own set of abbreviations, and its own abbrev id width. When a sub-block
is popped, the saved values are restored.</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection"> <a name="ENTER_SUBBLOCK">ENTER_SUBBLOCK
Encoding</a></div>
<div class="doc_text">
<p><tt>[ENTER_SUBBLOCK, blockid<sub>vbr8</sub>, newabbrevlen<sub>vbr4</sub>,
&lt;align32bits&gt;, blocklen<sub>32</sub>]</tt></p>
<p>
The ENTER_SUBBLOCK abbreviation ID specifies the start of a new block record.
The <tt>blockid</tt> value is encoded as a 8-bit VBR identifier, and indicates
the type of block being entered (which is application specific). The
<tt>newabbrevlen</tt> value is a 4-bit VBR which specifies the
abbrev id width for the sub-block. The <tt>blocklen</tt> is a 32-bit aligned
value that specifies the size of the subblock, in 32-bit words. This value
allows the reader to skip over the entire block in one jump.
</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection"> <a name="END_BLOCK">END_BLOCK
Encoding</a></div>
<div class="doc_text">
<p><tt>[END_BLOCK, &lt;align32bits&gt;]</tt></p>
<p>
The END_BLOCK abbreviation ID specifies the end of the current block record.
Its end is aligned to 32-bits to ensure that the size of the block is an even
multiple of 32-bits.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection"><a name="datarecord">Data Records</a>
</div>
<div class="doc_text">
<p>
Data records consist of a record code and a number of (up to) 64-bit integer
values. The interpretation of the code and values is application specific and
there are multiple different ways to encode a record (with an unabbrev record
or with an abbreviation). In the LLVM IR format, for example, there is a record
which encodes the target triple of a module. The code is MODULE_CODE_TRIPLE,
and the values of the record are the ascii codes for the characters in the
string.</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection"> <a name="UNABBREV_RECORD">UNABBREV_RECORD
Encoding</a></div>
<div class="doc_text">
<p><tt>[UNABBREV_RECORD, code<sub>vbr6</sub>, numops<sub>vbr6</sub>,
op0<sub>vbr6</sub>, op1<sub>vbr6</sub>, ...]</tt></p>
<p>An UNABBREV_RECORD provides a default fallback encoding, which is both
completely general and also extremely inefficient. It can describe an arbitrary
record, by emitting the code and operands as vbrs.</p>
<p>For example, emitting an LLVM IR target triple as an unabbreviated record
requires emitting the UNABBREV_RECORD abbrevid, a vbr6 for the
MODULE_CODE_TRIPLE code, a vbr6 for the length of the string (which is equal to
the number of operands), and a vbr6 for each character. Since there are no
letters with value less than 32, each letter would need to be emitted as at
least a two-part VBR, which means that each letter would require at least 12
bits. This is not an efficient encoding, but it is fully general.</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection"> <a name="abbrev_records">Abbreviated Record
Encoding</a></div>
<div class="doc_text">
<p><tt>[&lt;abbrevid&gt;, fields...]</tt></p>
<p>An abbreviated record is a abbreviation id followed by a set of fields that
are encoded according to the <a href="#abbreviations">abbreviation
definition</a>. This allows records to be encoded significantly more densely
than records encoded with the <a href="#UNABBREV_RECORD">UNABBREV_RECORD</a>
type, and allows the abbreviation types to be specified in the stream itself,
which allows the files to be completely self describing. The actual encoding
of abbreviations is defined below.
</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection"><a name="abbreviations">Abbreviations</a>
</div>
<div class="doc_text">
<p>
Abbreviations are an important form of compression for bitstreams. The idea is
to specify a dense encoding for a class of records once, then use that encoding
to emit many records. It takes space to emit the encoding into the file, but
the space is recouped (hopefully plus some) when the records that use it are
emitted.
</p>
<p>
Abbreviations can be determined dynamically per client, per file. Since the
abbreviations are stored in the bitstream itself, different streams of the same
format can contain different sets of abbreviations if the specific stream does
not need it. As a concrete example, LLVM IR files usually emit an abbreviation
for binary operators. If a specific LLVM module contained no or few binary
operators, the abbreviation does not need to be emitted.
</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection"><a name="DEFINE_ABBREV">DEFINE_ABBREV
Encoding</a></div>
<div class="doc_text">
<p><tt>[DEFINE_ABBREV, numabbrevops<sub>vbr5</sub>, abbrevop0, abbrevop1,
...]</tt></p>
<p>An abbreviation definition consists of the DEFINE_ABBREV abbrevid followed
by a VBR that specifies the number of abbrev operands, then the abbrev
operands themselves. Abbreviation operands come in three forms. They all start
with a single bit that indicates whether the abbrev operand is a literal operand
(when the bit is 1) or an encoding operand (when the bit is 0).</p>
<ol>
<li>Literal operands - <tt>[1<sub>1</sub>, litvalue<sub>vbr8</sub>]</tt> -
Literal operands specify that the value in the result
is always a single specific value. This specific value is emitted as a vbr8
after the bit indicating that it is a literal operand.</li>
<li>Encoding info without data - <tt>[0<sub>1</sub>, encoding<sub>3</sub>]</tt>
- Operand encodings that do not have extra data are just emitted as their code.
</li>
<li>Encoding info with data - <tt>[0<sub>1</sub>, encoding<sub>3</sub>,
value<sub>vbr5</sub>]</tt> - Operand encodings that do have extra data are
emitted as their code, followed by the extra data.
</li>
</ol>
<p>The possible operand encodings are:</p>
<ul>
<li>1 - Fixed - The field should be emitted as a <a
href="#fixedwidth">fixed-width value</a>, whose width
is specified by the encoding operand.</li>
<li>2 - VBR - The field should be emitted as a <a
href="#variablewidth">variable-width value</a>, whose width
is specified by the encoding operand.</li>
<li>3 - Array - This field is an array of values. The element type of the array
is specified by the next encoding operand.</li>
<li>4 - Char6 - This field should be emitted as a <a href="#char6">char6-encoded
value</a>.</li>
</ul>
<p>For example, target triples in LLVM modules are encoded as a record of the
form <tt>[TRIPLE, 'a', 'b', 'c', 'd']</tt>. Consider if the bitstream emitted
the following abbrev entry:</p>
<ul>
<li><tt>[0, Fixed, 4]</tt></li>
<li><tt>[0, Array]</tt></li>
<li><tt>[0, Char6]</tt></li>
</ul>
<p>When emitting a record with this abbreviation, the above entry would be
emitted as:</p>
<p><tt>[4<sub>abbrevwidth</sub>, 2<sub>4</sub>, 4<sub>vbr6</sub>,
0<sub>6</sub>, 1<sub>6</sub>, 2<sub>6</sub>, 3<sub>6</sub>]</tt></p>
<p>These values are:</p>
<ol>
<li>The first value, 4, is the abbreviation ID for this abbreviation.</li>
<li>The second value, 2, is the code for TRIPLE in LLVM IR files.</li>
<li>The third value, 4, is the length of the array.</li>
<li>The rest of the values are the char6 encoded values for "abcd".</li>
</ol>
<p>With this abbreviation, the triple is emitted with only 37 bits (assuming a
abbrev id width of 3). Without the abbreviation, significantly more space would
be required to emit the target triple. Also, since the TRIPLE value is not
emitted as a literal in the abbreviation, the abbreviation can also be used for
any other string value.
</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection"><a name="stdblocks">Standard Blocks</a>
</div>
<div class="doc_text">
<p>
In addition to the basic block structure and record encodings, the bitstream
also defines specific builtin block types. These block types specify how the
stream is to be decoded or other metadata. In the future, new standard blocks
may be added.
</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection"><a name="BLOCKINFO">#0 - BLOCKINFO
Block</a></div>
<div class="doc_text">
<p>The BLOCKINFO block allows the description of metadata for other blocks. The
currently specified records are:</p>
<ul>
<li><tt>[SETBID (#1), blockid]</tt></li>
<li><tt>[DEFINE_ABBREV, ...]</tt></li>
</ul>
<p>
The SETBID record indicates which block ID is being described. The standard
DEFINE_ABBREV record specifies an abbreviation. The abbreviation is associated
with the record ID, and any records with matching ID automatically get the
abbreviation.
</p>
</div>
<!-- *********************************************************************** -->
<div class="doc_section"> <a name="llvmir">LLVM IR Encoding</a></div>
<!-- *********************************************************************** -->
<div class="doc_text">
<p>LLVM IR is encoded into a bitstream by defining blocks and records. It uses
blocks for things like constant pools, functions, symbol tables, etc. It uses
records for things like instructions, global variable descriptors, type
descriptions, etc. This document does not describe the set of abbreviations
that the writer uses, as these are fully self-described in the file, and the
reader is not allowed to build in any knowledge of this.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection"><a name="basics">Basics</a>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection"><a name="ir_magic">LLVM IR Magic Number</a></div>
<div class="doc_text">
<p>
The magic number for LLVM IR files is:
</p>
<p><tt>['B'<sub>8</sub>, 'C'<sub>8</sub>, 0x0<sub>4</sub>, 0xC<sub>4</sub>,
0xE<sub>4</sub>, 0xD<sub>4</sub>]</tt></p>
<p>When viewed as bytes, this is "BC 0xC0DE".</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection"><a name="ir_signed_vbr">Signed VBRs</a></div>
<div class="doc_text">
<p>
<a href="#variablewidth">Variable Width Integers</a> are an efficient way to
encode arbitrary sized unsigned values, but is an extremely inefficient way to
encode signed values (as signed values are otherwise treated as maximally large
unsigned values).</p>
<p>As such, signed vbr values of a specific width are emitted as follows:</p>
<ul>
<li>Positive values are emitted as vbrs of the specified width, but with their
value shifted left by one.</li>
<li>Negative values are emitted as vbrs of the specified width, but the negated
value is shifted left by one, and the low bit is set.</li>
</ul>
<p>With this encoding, small positive and small negative values can both be
emitted efficiently.</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection"><a name="ir_blocks">LLVM IR Blocks</a></div>
<div class="doc_text">
<p>
LLVM IR is defined with the following blocks:
</p>
<ul>
<li>8 - MODULE_BLOCK - This is the top-level block that contains the
entire module, and describes a variety of per-module information.</li>
<li>9 - PARAMATTR_BLOCK - This enumerates the parameter attributes.</li>
<li>10 - TYPE_BLOCK - This describes all of the types in the module.</li>
<li>11 - CONSTANTS_BLOCK - This describes constants for a module or
function.</li>
<li>12 - FUNCTION_BLOCK - This describes a function body.</li>
<li>13 - TYPE_SYMTAB_BLOCK - This describes the type symbol table.</li>
<li>14 - VALUE_SYMTAB_BLOCK - This describes a value symbol table.</li>
</ul>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection"><a name="MODULE_BLOCK">MODULE_BLOCK Contents</a>
</div>
<div class="doc_text">
<p>
</p>
</div>
<!-- *********************************************************************** -->
<hr>
<address> <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a>
<a href="http://validator.w3.org/check/referer"><img
src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"></a>
<a href="mailto:sabre@nondot.org">Chris Lattner</a><br>
<a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br>
Last modified: $Date$
</address>
</body>
</html>

View File

@@ -38,13 +38,13 @@
passes. It can be used to debug three types of failures: optimizer crashes,
miscompilations by optimizers, or bad native code generation (including problems
in the static and JIT compilers). It aims to reduce large test cases to small,
useful ones. For example, if <tt>opt</tt> crashes while optimizing a
useful ones. For example, if <tt>gccas</tt> crashes while optimizing a
file, it will identify the optimization (or combination of optimizations) that
causes the crash, and reduce the file down to a small example which triggers the
crash.</p>
<p>For detailed case scenarios, such as debugging <tt>opt</tt>,
<tt>llvm-ld</tt>, or one of the LLVM code generators, see <a
<p>For detailed case scenarios, such as debugging <tt>gccas</tt>,
<tt>gccld</tt>, or one of the LLVM code generators, see <a
href="HowToSubmitABug.html">How To Submit a Bug Report document</a>.</p>
</div>
@@ -114,7 +114,7 @@ Otherwise, there is no problem <tt>bugpoint</tt> can debug.</p>
as it can to reduce the list of passes (for optimizer crashes) and the size of
the test program. First, <tt>bugpoint</tt> figures out which combination of
optimizer passes triggers the bug. This is useful when debugging a problem
exposed by <tt>opt</tt>, for example, because it runs over 38 passes.</p>
exposed by <tt>gccas</tt>, for example, because it runs over 38 passes.</p>
<p>Next, <tt>bugpoint</tt> tries removing functions from the test program, to
reduce its size. Usually it is able to reduce a test program to a single
@@ -124,7 +124,7 @@ flow graph, to reduce the size of the function as much as possible. Finally,
<tt>bugpoint</tt> deletes any individual LLVM instructions whose absence does
not eliminate the failure. At the end, <tt>bugpoint</tt> should tell you what
passes crash, give you a bytecode file, and give you instructions on how to
reproduce the failure with <tt>opt</tt> or <tt>llc</tt>.</p>
reproduce the failure with <tt>opt</tt>, <tt>analyze</tt>, or <tt>llc</tt>.</p>
</div>
@@ -215,12 +215,6 @@ non-obvious ways. Here are some hints and tips:<p>
confused. One way to deal with this is to cause bugpoint to ignore the exit
code from your program, by giving it the <tt>-check-exit-code=false</tt>
option.
<li><tt>bugpoint</tt> is useful for proactively finding bugs in LLVM.
Invoking <tt>bugpoint</tt> with the <tt>-find-bugs</tt> option will cause
the list of specified optimizations to be randomized and applied to the
program. This process will repeat until a bug is found or the user
kills <tt>bugpoint</tt>.
</ol>
@@ -236,7 +230,7 @@ non-obvious ways. Here are some hints and tips:<p>
src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"></a>
<a href="mailto:sabre@nondot.org">Chris Lattner</a><br>
<a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
<a href="http://llvm.cs.uiuc.edu">LLVM Compiler Infrastructure</a><br>
Last modified: $Date$
</address>

File diff suppressed because it is too large Load Diff

View File

@@ -4,65 +4,287 @@
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<link rel="stylesheet" href="llvm.css" type="text/css" media="screen">
<title>Building the LLVM C/C++ Front-End</title>
<title>Bootstrapping the LLVM C/C++ Front-End</title>
</head>
<body>
<div class="doc_title">
Building the LLVM C/C++ Front-End
Bootstrapping the LLVM C/C++ Front-End
</div>
<ol>
<li><a href="#instructions">Building llvm-gcc 4 from Source</a></li>
<li><a href="#cautionarynote">A Cautionary Note</a>
<ul>
<li><a href="#cygwin">Building under Cygwin</a></li>
<li><a href="#aix">Building under AIX</a></li>
</ul>
</li>
<li><a href="#instructions">Instructions</a></li>
<li><a href="#license">License Information</a></li>
</ol>
<div class="doc_author">
<p>Written by the LLVM Team</p>
<p>Written by Brian R. Gaeke and
<a href="http://nondot.org/sabre">Chris Lattner</a></p>
</div>
<!-- *********************************************************************** -->
<div class="doc_section">
<a name="instructions">Building llvm-gcc 4 from Source</a>
<a name="cautionarynote">A Cautionary Note</a>
</div>
<!-- *********************************************************************** -->
<div class="doc_text">
<p>This document is intended to explain the process of building the
LLVM C/C++ front-end, based on GCC 3.4, from its source code. You
would have to do this, for example, if you are porting LLVM to a new
architecture or operating system.</p>
<p>This section describes how to aquire and build llvm-gcc4, which is based on
the GCC 4.0.1 front-end. This front-end supports C, C++, Objective-C, and
Objective-C++. Note that the instructions for building this front-end are
completely different (and much easier!) than those for building llvm-gcc3 in
the past.</p>
<p><b>NOTE:</b> This is currently a somewhat fragile, error-prone
process, and you should <b>only</b> try to do it if:</p>
<ol>
<li><p>Retrieve the appropriate llvm-gcc4-x.y.source.tar.gz archive from the
<a href="http://llvm.org/releases/">llvm web site</a>.</p>
<p>It is also possible to download the sources of the llvm-gcc4 front end
from a read-only mirror using subversion. To check out the code the
first time use:</p>
<div class="doc_code">
<pre>
svn co svn://anonsvn.opensource.apple.com/svn/llvm/trunk <i>dst-directory</i>
</pre>
</div>
<p>After that, the code can be be updated in the destination directory
using:</p>
<div class="doc_code">
<pre>svn update</pre>
</div>
<p>The mirror is brought up to date every evening.</p></li>
<li>Follow the directions in the top-level <tt>README.LLVM</tt> file for
up-to-date instructions on how to build llvm-gcc4.</li>
<li>you really, really, really can't use the binaries we distribute</li>
<li>you are an elite GCC hacker.</li>
<li>you want to use the latest bits from CVS.</li>
</ol>
<p>We welcome patches to help make this process simpler.</p>
</div>
<!--=========================================================================-->
<div class="doc_subsection">
<a name="cygwin">Building under Cygwin</a>
</div>
<!--=========================================================================-->
<div class="doc_text">
<p>If you are building LLVM and the GCC front-end under Cygwin, please note that
the LLVM and GCC makefiles do not correctly handle spaces in paths. To deal
with this issue, make sure that your LLVM and GCC source and build trees are
located in a top-level directory (like <tt>/cygdrive/c/llvm</tt> and
<tt>/cygdrive/c/llvm-cfrontend</tt>), not in a directory that contains a space
(which includes your "home directory", because it lives under the "Documents
and Settings" directory). We welcome patches to fix this issue.
</p>
<p>It has been found that the GCC 3.3.3 compiler provided with recent Cygwin
versions is incapable of compiling the LLVM GCC front-end correctly. If your
Cygwin
installation includes GCC 3.3.3, we <i>strongly</i> recommend that you download
GCC 3.4.3, build it separately, and use it for compiling the LLVM GCC front-end. This has been
shown to work correctly.</p>
<p>Some versions of Cygwin utilize an experimental version of GNU binutils that
will cause the GNU <tt>ld</tt> linker to fail an assertion when linking
components of the libstdc++. It is recommended that you replace the entire
binutils package with version 2.15 such that "<tt>ld --version</tt>" responds
with</p>
<pre>GNU ld version 2.15</pre>
not with:<br/>
<pre>GNU ld version 2.15.91 20040725</pre>
</div>
<!--=========================================================================-->
<div class="doc_subsection"><a name="aix">Building under AIX</a></div>
<div class="doc_text">
<p>If you are building LLVM and the GCC front-end under AIX, do NOT use GNU
Binutils. They are not stable under AIX and may produce incorrect and/or
invalid code. Instead, use the system assembler and linker.
</p>
</div>
<!-- *********************************************************************** -->
<div class="doc_section">
<a name="instructions">Instructions</a>
</div>
<!-- *********************************************************************** -->
<div class="doc_text">
<p>
<ol>
<li><p>Configure and build the LLVM libraries and tools. There are two ways to
do this: either with <i>objdir</i> == <i>srcdir</i> or
<i>objdir</i> != <i>srcdir</i>. It is recommended
that <i>srcdir</i> be the same as <i>objdir</i> for your LLVM tree (but note
that you should always use <i>srcdir</i> != <i>objdir</i> for llvm-gcc):</p>
<ul>
<li>With <i>objdir</i> != <i>srcdir</i>:<pre>
% cd <i>objdir</i>
% <i>srcdir</i>/configure --prefix=/some/path/you/can/install/to [options...]
% gmake tools-only
</pre></li>
<li>With <i>objdir</i> == <i>srcdir</i>:<pre>
% cd llvm
% ./configure --prefix=/some/path/you/can/install/to [options...]
% gmake tools-only
</pre></li>
</ul>
<p>This will build all of the LLVM tools and libraries. The <tt>--prefix</tt>
option defaults to /usr/local (per configure standards) but unless you are a
system administrator, you probably won't be able to install LLVM there because
of permissions. Specify a path into which LLVM can be installed (e.g.
<tt>--prefix=/home/user/llvm</tt>).</p>
</li>
<li><p>Add the directory containing the tools to your PATH.</p>
<pre>
% set path = ( `cd llvm/Debug/bin &amp;&amp; pwd` $path )
</pre></li>
<li><p>Unpack the C/C++ front-end source into cfrontend/src, either by
untar'ing a cfrontend.source.tar.gz file or checking out CVS into this
directory.</p></li>
<li><p>Make "build" and "install" directories as siblings of the "src" tree:</p>
<pre>
% pwd
/usr/local/example/cfrontend/src
% cd ..
% mkdir build install
% set CFEINSTALL = `pwd`/install
</pre></li>
<li><p>Configure, build, and install the GCC front-end:</p>
<p>
<b>Linux/x86:</b><br>
<b>Linux/IA-64:</b><br>
<b>MacOS X/PowerPC</b> (requires dlcompat library):<br>
<b>AIX/PowerPC:</b>
</p>
<pre>
% cd build
% ../src/configure --prefix=$CFEINSTALL --disable-threads --disable-nls \
--disable-shared --enable-languages=c,c++ --program-prefix=llvm-
% gmake all; gmake install
</pre>
<p><b>Cygwin/x86:</b></p>
<pre>
% cd build
% ../src/configure --prefix=$CFEINSTALL --disable-threads --disable-nls \
--disable-shared --enable-languages=c,c++ --disable-c-mbchar \
--program-prefix=llvm-
% gmake all; gmake install
</pre>
<p><b>Solaris/SPARC:</b></p>
<p>
The GCC front-end can be configured for either SPARC V8 (32 bit) or SPARC V9 (64
bit). This changes, among other things, the sizes of integer types and the
macros defined for conditional compilation.
</p>
<p>
The SPARC V8 backend is still beta quality software. Unless you are working on
the SPARC V8 backend, you should specify sparcv9 on the configure command line,
as shown below. Also,
note that Solaris has trouble with various wide (multibyte) character
functions from C as referenced from C++, so we typically configure with
--disable-c-mbchar (cf. <a href="http://llvm.cs.uiuc.edu/PR206">Bug 206</a>).
</p>
<pre>
% cd build
% ../src/configure --prefix=$CFEINSTALL --disable-threads --disable-nls \
--disable-shared --enable-languages=c,c++ --host=sparcv9-sun-solaris2.8 \
--disable-c-mbchar --program-prefix=llvm-
% gmake all; gmake install
</pre>
<p><b>Common Problem:</b> You may get error messages regarding the fact
that LLVM does not support inline assembly. Here are two common
fixes:</p>
<ul>
<li><p><b>Fix 1:</b> If you have system header files that include
inline assembly, you may have to modify them to remove the inline
assembly and install the modified versions in
<code>$CFEINSTALL/lib/gcc/<i>target-triplet</i>/3.4-llvm/include</code>.</li>
<li><b>Fix 2:</b> If you are building the C++ front-end on a CPU we
haven't tried yet, you will probably have to edit the appropriate
version of atomicity.h under
<code>src/libstdc++-v3/config/cpu/<i>name-of-cpu</i>/atomicity.h</code>
and apply a patch so that it does not use inline assembly.</li>
</ul>
<p><b>Porting to a new architecture:</b> If you are porting the front-end
to a new architecture or compiling in a configuration that we have
not tried previously, there are probably several changes you will have to make
to the GCC target to get it to work correctly. These include:<p>
<ul>
<li>Often targets include special assembler or linker flags which
<tt>gccas</tt>/<tt>gccld</tt> does not understand. In general, these can
just be removed.</li>
<li>LLVM currently does not support any floating point values other than
32-bit and 64-bit IEEE floating point. The primary effect of this is
that you may have to map "long double" onto "double".</li>
<li>The profiling hooks in GCC do not apply at all to the LLVM front-end.
These may need to be disabled.</li>
<li>No inline assembly for position independent code. At the LLVM level,
everything is position independent.</li>
<li>We handle <tt>.init</tt> and <tt>.fini</tt> differently.</li>
<li>You may have to disable multilib support in your target. Using multilib
support causes the GCC compiler driver to add a lot of "<tt>-L</tt>"
options to the link line, which do not relate to LLVM and confuse
<tt>gccld</tt>. To disable multilibs, delete any
<tt>MULTILIB_OPTIONS</tt> lines from your target files.</li>
<li>Did we mention that we don't support inline assembly? You'll probably
have to add some fixinclude hacks to disable it in the system
headers.</li>
</ul>
</li>
<li><p>Put <tt>$CFEINSTALL/bin</tt> into your <tt>PATH</tt> environment
variable.</p>
<ul>
<li>sh: <tt>export PATH=$CFEINSTALL/bin:$PATH</tt></li>
<li>csh: <tt>setenv PATH $CFEINSTALL/bin:$PATH</tt></li>
</ul>
</li>
<li><p>Go back into the LLVM source tree proper. Rerun configure, using
the same options as the last time. This will cause the configuration to now find
the newly built llvm-gcc and llvm-g++ executables. </p></li>
<li><p>Rebuild your CVS tree. This shouldn't cause the whole thing to be
rebuilt, but it should build the runtime libraries. After the tree is
built, install the runtime libraries into your GCC front-end build tree.
These are the commands you need:</p>
<pre>
% gmake
% gmake -C runtime install-bytecode
</pre></li>
<li><p>Optionally, build a symbol table for the newly installed runtime
libraries. Although this step is optional, you are strongly encouraged to
do this as the symbol tables will make a significant difference in your
link times. Use the <tt>llvm-ranlib</tt> tool to do this, as follows:</p>
<pre>
% cd $CFEINSTALL/lib
% llvm-ranlib libiberty.a
% llvm-ranlib libstdc++.a
% llvm-ranlib libsupc++.a
% cd $CFEINSTALL/lib/gcc/<i>target-triplet</i>/3.4-llvm
% llvm-ranlib libgcc.a
% llvm-ranlib libgcov.a
</pre>
<li><p>Test the newly-installed C frontend by one or more of the
following means:</p>
<ul>
<li> running the feature &amp; regression tests via <tt>make check</tt></li>
<li> compiling and running a "hello, LLVM" program in C and C++.</li>
<li> running the tests found in the <tt>llvm-test</tt> CVS module</li>
</ul></li>
</ol>
</div>
<!-- *********************************************************************** -->
<div class="doc_section">
<a name="license">License Information</a>
@@ -76,8 +298,52 @@ COPYING.LIB for more details.
</p>
<p>
More information is <a href="FAQ.html#license">available in the FAQ</a>.
The software also has the following additional copyrights:
</p>
<pre>
Copyright (c) 2003, 2004, 2005 University of Illinois at Urbana-Champaign.
All rights reserved.
Developed by:
LLVM Team
University of Illinois at Urbana-Champaign
http://llvm.cs.uiuc.edu
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
CONTRIBUTORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS WITH THE
SOFTWARE.
Copyright (c) 1994
Hewlett-Packard Company
Permission to use, copy, modify, distribute and sell this software
and its documentation for any purpose is hereby granted without fee,
provided that the above copyright notice appear in all copies and
that both that copyright notice and this permission notice appear
in supporting documentation. Hewlett-Packard Company makes no
representations about the suitability of this software for any
purpose. It is provided "as is" without express or implied warranty.
Copyright (c) 1996, 1997, 1998, 1999
Silicon Graphics Computer Systems, Inc.
Permission to use, copy, modify, distribute and sell this software
and its documentation for any purpose is hereby granted without fee,
provided that the above copyright notice appear in all copies and
that both that copyright notice and this permission notice appear
in supporting documentation. Silicon Graphics makes no
representations about the suitability of this software for any
purpose. It is provided "as is" without express or implied warranty.
</pre>
</div>
<!-- *********************************************************************** -->
@@ -89,7 +355,8 @@ More information is <a href="FAQ.html#license">available in the FAQ</a>.
<a href="http://validator.w3.org/check/referer"><img
src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"></a>
<a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
Brian Gaeke<br>
<a href="http://llvm.cs.uiuc.edu">LLVM Compiler Infrastructure</a><br>
Last modified: $Date$
</address>

File diff suppressed because it is too large Load Diff

View File

@@ -41,25 +41,20 @@
<li><a href="#hl_dontinclude">#include as Little as Possible</a></li>
<li><a href="#hl_privateheaders">Keep "internal" Headers
Private</a></li>
<li><a href="#ll_iostream"><tt>#include &lt;iostream&gt;</tt> is
<em>forbidden</em></a></li>
</ol></li>
<li><a href="#micro">The Low Level Issues</a>
<ol>
<li><a href="#ll_assert">Assert Liberally</a></li>
<li><a href="#ll_ns_std">Do not use 'using namespace std'</a></li>
<li><a href="#ll_virtual_anch">Provide a virtual method anchor for
classes in headers</a></li>
<li><a href="#ll_preincrement">Prefer Preincrement</a></li>
<li><a href="#ll_avoidendl">Avoid <tt>std::endl</tt></a></li>
<li><a href="#hl_assert">Assert Liberally</a></li>
<li><a href="#hl_preincrement">Prefer Preincrement</a></li>
<li><a href="#hl_avoidendl">Avoid <tt>std::endl</tt></a></li>
<li><a href="#hl_exploitcpp">Exploit C++ to its Fullest</a></li>
</ol></li>
</ol></li>
<li><a href="#seealso">See Also</a></li>
</ol>
<div class="doc_author">
<p>Written by <a href="mailto:sabre@nondot.org">Chris Lattner</a> and
<a href="mailto:void@nondot.org">Bill Wendling</a></p>
<p>Written by <a href="mailto:sabre@nondot.org">Chris Lattner</a></p>
</div>
@@ -134,7 +129,7 @@ this:</p>
//
// The LLVM Compiler Infrastructure
//
// This file was developed by &lt;whoever started the file&gt; and is distributed under
// This file was developed by the LLVM research group and is distributed under
// the University of Illinois Open Source License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
@@ -146,9 +141,7 @@ this:</p>
</pre>
</div>
<p>A few things to note about this particular format: The 'developed by' line
should be the name of the person or organization who initially contributed the
file. The "<tt>-*- C++
<p>A few things to note about this particular format: The "<tt>-*- C++
-*-</tt>" string on the first line is there to tell Emacs that the source file
is a C++ file, not a C file (Emacs assumes .h files are C files by default).
Note that this tag is not necessary in .cpp files. The name of the file is also
@@ -167,7 +160,7 @@ included, as well as any notes or "gotchas" in the code to watch out for.</p>
<b>Class overviews</b>
<p>Classes are one fundamental part of a good object oriented design. As such,
<p>Classes are one fundemental part of a good object oriented design. As such,
a class definition should have a comment block that explains what the class is
used for... if it's not obvious. If it's so completely obvious your grandma
could figure it out, it's probably safe to leave it out. Naming classes
@@ -458,8 +451,7 @@ most cases, you simply don't need the definition of a class... and not
<tt>#include</tt>'ing speeds up compilation.</p>
<p>It is easy to try to go too overboard on this recommendation, however. You
<b>must</b> include all of the header files that you are using -- you can
include them either directly
<b>must</b> include all of the header files that you are using, either directly
or indirectly (through another header file). To make sure that you don't
accidently forget to include a header file in your module header, make sure to
include your module header <b>first</b> in the implementation file (as mentioned
@@ -489,87 +481,6 @@ class itself... just make them private (or protected), and all is well.</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<a name="ll_iostream"><tt>#include &lt;iostream&gt;</tt> is forbidden</a>
</div>
<div class="doc_text">
<p>The use of <tt>#include &lt;iostream&gt;</tt> in library files is
hereby <b><em>forbidden</em></b>. The primary reason for doing this is to
support clients using LLVM libraries as part of larger systems. In particular,
we statically link LLVM into some dynamic libraries. Even if LLVM isn't used,
the static c'tors are run whenever an application start up that uses the dynamic
library. There are two problems with this:</p>
<ol>
<li>The time to run the static c'tors impacts startup time of
applications&mdash;a critical time for gui apps.</li>
<li>The static c'tors cause the app to pull many extra pages of memory off the
disk: both the code for the static c'tors in each .o file and the small
amount of data that gets touched. In addition, touched/dirty pages put
more pressure on the VM system on low-memory machines.</li>
</ol>
<table align="center">
<tbody>
<tr>
<th>Old Way</th>
<th>New Way</th>
</tr>
<tr>
<td align="left"><pre>#include &lt;iostream&gt;</pre></td>
<td align="left"><pre>#include "llvm/Support/Streams.h"</pre></td>
</tr>
<tr>
<td align="left"><pre>DEBUG(std::cerr &lt;&lt; ...);
DEBUG(dump(std::cerr));</pre></td>
<td align="left"><pre>DOUT &lt;&lt; ...;
dump(DOUT);</pre></td>
</tr>
<tr>
<td align="left"><pre>std::cerr &lt;&lt; "Hello world\n";</pre></td>
<td align="left"><pre>llvm::cerr &lt;&lt; "Hello world\n";</pre></td>
</tr>
<tr>
<td align="left"><pre>std::cout &lt;&lt; "Hello world\n";</pre></td>
<td align="left"><pre>llvm::cout &lt;&lt; "Hello world\n";</pre></td>
</tr>
<tr>
<td align="left"><pre>std::cin &gt;&gt; Var;</pre></td>
<td align="left"><pre>llvm::cin &gt;&gt; Var;</pre></td>
</tr>
<tr>
<td align="left"><pre>std::ostream</pre></td>
<td align="left"><pre>llvm::OStream</pre></td>
</tr>
<tr>
<td align="left"><pre>std::istream</pre></td>
<td align="left"><pre>llvm::IStream</pre></td>
</tr>
<tr>
<td align="left"><pre>std::stringstream</pre></td>
<td align="left"><pre>llvm::StringStream</pre></td>
</tr>
<tr>
<td align="left"><pre>void print(std::ostream &Out);
// ...
print(std::cerr);</pre></td>
<td align="left"><pre>void print(std::ostream &Out);
void print(std::ostream *Out) { if (Out) print(*Out) }
// ...
print(llvm::cerr);</pre>
<ul><i>N.B.</i> The second <tt>print</tt> method is called by the <tt>print</tt>
expression. It prevents the execution of the first <tt>print</tt> method if the
stream is <tt>cnull</tt>.</ul></td>
</tbody>
</table>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="micro">The Low Level Issues</a>
@@ -578,7 +489,7 @@ stream is <tt>cnull</tt>.</ul></td>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<a name="ll_assert">Assert Liberally</a>
<a name="hl_assert">Assert Liberally</a>
</div>
<div class="doc_text">
@@ -624,62 +535,10 @@ assert(isa&lt;PHINode&gt;(Succ-&gt;front()) &amp;&amp; "Only works on PHId BBs!"
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<a name="ll_ns_std">Do not use '<tt>using namespace std</tt>'</a>
</div>
<div class="doc_text">
<p>In LLVM, we prefer to explicitly prefix all identifiers from the standard
namespace with an "<tt>std::</tt>" prefix, rather than rely on
"<tt>using namespace std;</tt>".</p>
<p> In header files, adding a '<tt>using namespace XXX</tt>' directive pollutes
the namespace of any source file that includes the header. This is clearly a
bad thing.</p>
<p>In implementation files (e.g. .cpp files), the rule is more of a stylistic
rule, but is still important. Basically, using explicit namespace prefixes
makes the code <b>clearer</b>, because it is immediately obvious what facilities
are being used and where they are coming from, and <b>more portable</b>, because
namespace clashes cannot occur between LLVM code and other namespaces. The
portability rule is important because different standard library implementations
expose different symbols (potentially ones they shouldn't), and future revisions
to the C++ standard will add more symbols to the <tt>std</tt> namespace. As
such, we never use '<tt>using namespace std;</tt>' in LLVM.</p>
<p>The exception to the general rule (i.e. it's not an exception for
the <tt>std</tt> namespace) is for implementation files. For example, all of
the code in the LLVM project implements code that lives in the 'llvm' namespace.
As such, it is ok, and actually clearer, for the .cpp files to have a '<tt>using
namespace llvm</tt>' directive at their top, after the <tt>#include</tt>s. The
general form of this rule is that any .cpp file that implements code in any
namespace may use that namespace (and its parents'), but should not use any
others.</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<a name="ll_virtual_anch">Provide a virtual method anchor for classes
in headers</a>
</div>
<div class="doc_text">
<p>If a class is defined in a header file and has a v-table (either it has
virtual methods or it derives from classes with virtual methods), it must
always have at least one out-of-line virtual method in the class. Without
this, the compiler will copy the vtable and RTTI into every .o file that
#includes the header, bloating .o file sizes and increasing link times.
</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<a name="ll_preincrement">Prefer Preincrement</a>
<a name="hl_preincrement">Prefer Preincrement</a>
</div>
<div class="doc_text">
@@ -699,7 +558,7 @@ get in the habit of always using preincrement, and you won't have a problem.</p>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<a name="ll_avoidendl">Avoid <tt>std::endl</tt></a>
<a name="hl_avoidendl">Avoid <tt>std::endl</tt></a>
</div>
<div class="doc_text">
@@ -720,6 +579,24 @@ it's better to use a literal <tt>'\n'</tt>.</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<a name="hl_exploitcpp">Exploit C++ to its Fullest</a>
</div>
<div class="doc_text">
<p>C++ is a powerful language. With a firm grasp on its capabilities, you can
make write effective, consise, readable and maintainable code all at the same
time. By staying consistent, you reduce the amount of special cases that need
to be remembered. Reducing the total number of lines of code you write is a
good way to avoid documentation, and avoid giving bugs a place to hide.</p>
<p>For these reasons, come to know and love the contents of your local
<tt>&lt;algorithm&gt;</tt> header file. Know about <tt>&lt;functional&gt;</tt>
and what it can do for you. C++ is just a tool that wants you to master it.</p>
</div>
<!-- *********************************************************************** -->
<div class="doc_section">
@@ -761,7 +638,7 @@ something.</p>
src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"></a>
<a href="mailto:sabre@nondot.org">Chris Lattner</a><br>
<a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
<a href="http://llvm.cs.uiuc.edu">LLVM Compiler Infrastructure</a><br>
Last modified: $Date$
</address>

View File

@@ -30,7 +30,7 @@ html/%.html: %.pod
--podpath=. --noindex --infile=$< --outfile=$@ --title=$*
man/man1/%.1: %.pod
pod2man --release=CVS --center="LLVM Command Guide" $< $@
pod2man --release=1.5 --center="LLVM Command Guide" $< $@
ps/%.ps: man/man1/%.1
groff -Tps -man $< > $@

View File

@@ -0,0 +1,75 @@
=pod
=head1 NAME
analyze - LLVM program analyzer
=head1 SYNOPSIS
B<analyze> [I<options>] [I<filename>]
=head1 DESCRIPTION
The B<analyze> command performs various analysis of LLVM assembly
code or bytecode. It will usually print the results on standard
output, but in a few cases, it will print output to standard error
or generate a file with the analysis output, which is usually done
when the output is meant for another program.
If filename is omitted or is I<->, B<analyze> reads its input from
standard input. It first attempts to interpret its input as LLVM
bytecode. If it encounters an error, it then attempts to parse the
input as LLVM assembly language.
=head1 OPTIONS
=over
=item B<-help>
Print a summary of command line options.
=item B<-q>
Quiet mode. With this option, analysis pass names are not printed.
=item B<-load> I<plugin>
Load the specified dynamic object with name I<plugin>. This file
should contain additional analysis passes that register themselves
with the B<analyze> program after being loaded.
After being loaded, additional command line options are made
available for running the passes made available by I<plugin>. Use
B<analyze -load> I<plugin> B<-help> to see the new list of available
analysis passes.
=item B<-profile-info-file> I<filename>
Specify the name of the file loaded by the -profile-loader option.
=item B<-stats>
Print statistics.
=item B<-time-passes>
Record the amount of time needed for each pass and print it to standard
error.
=back
=head1 EXIT STATUS
If B<analyze> succeeds, it will exit with 0. Otherwise, if an error
occurs, it will exit with a non-zero value.
=head1 SEE ALSO
L<opt|opt>
=head1 AUTHORS
Maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
=cut

View File

@@ -64,11 +64,6 @@ program. By default, B<bugpoint> uses these passes internally when attempting to
reduce test programs. If you're trying to find a bug in one of these passes,
B<bugpoint> may crash.
=item B<-find-bugs>
Continually randomize the specified passes and run them on the test program
until a bug is found or the user kills B<bugpoint>.
=item B<--help>
Print a summary of command line options.
@@ -105,12 +100,6 @@ using the specified code generator. These options allow you to choose the
interpreter, the JIT compiler, the static native code compiler, or the C
backend, respectively.
=item B<--enable-valgrind>
Use valgrind to find faults in the optimization phase. This will allow
bugpoint to find otherwise asymptomatic problems caused by memory
mis-management.
=back
=head1 EXIT STATUS
@@ -120,10 +109,10 @@ if an error occurs, it will exit with a non-zero value.
=head1 SEE ALSO
L<opt|opt>
L<opt|opt>, L<analyze|analyze>
=head1 AUTHOR
Maintained by the LLVM Team (L<http://llvm.org>).
Maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
=cut

View File

@@ -0,0 +1,76 @@
=pod
=head1 NAME
gccas - optimizing LLVM assembler
=head1 SYNOPSIS
B<gccas> [I<options>] I<filename>
=head1 DESCRIPTION
The B<gccas> utility takes an LLVM assembly file generated by the
L<llvmgcc|llvmgcc> or L<llvmg++|llvmgxx> front-ends and converts
it into an LLVM bytecode file. It is primarily used by the GCC
front end, and as such, attempts to mimic the interface provided
by the default system assembler so that it can act as a "drop-in"
replacement.
B<gccas> performs a number of optimizations on the input program,
including but not limited to: promotion of stack values to SSA
registers; elimination of dead globals, function arguments, code,
and types; tail-call elimination; loop-invariant code motion; global
common-subexpression elimination; and sparse conditional constant
propagation.
=head1 OPTIONS
=over
=item B<--help>
Print a summary of command line options.
=item B<-o> F<filename>
Specify the name of the output file which will hold the assembled bytecode.
=item B<--disable-inlining>
Disable the inlining pass. By default, it is enabled.
=item B<--disable-opt>
Disable all assembler-time optimization passes.
=item B<--stats>
Print statistics.
=item B<--time-passes>
Record the amount of time needed for each pass and print it to standard
error.
=item B<--verify>
Verify each pass result.
=back
=head1 EXIT STATUS
If B<gccas> succeeds, it will exit with an exit status of 0.
Otherwise, if an error occurs, it will exit with a non-zero exit
status.
=head1 SEE ALSO
L<llvm-as|llvm-as>, L<gccld|gccld>
=head1 AUTHORS
Maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
=cut

View File

@@ -0,0 +1,175 @@
=pod
=head1 NAME
gccld - optimizing LLVM linker
=head1 SYNOPSIS
B<gccld> [I<options>] I<filename ...>
=head1 DESCRIPTION
The B<gccld> utility takes a set of LLVM bytecode files and links them
together into a single LLVM bytecode file. The output bytecode file can be
another bytecode library or an executable bytecode program. Using additional
options, B<gccld> is able to produce native code executables.
The B<gccld> utility is primarily used by the L<llvmgcc> and
L<llvmg++|llvmgxx> front-ends, and as such, attempts to mimic the interface
provided by the default system linker so that it can act as a ``drop-in''
replacement.
The B<gccld> tool performs a small set of interprocedural, post-link
optimizations on the program.
=head2 Search Order
When looking for objects specified on the command line, B<gccld> will search for
the object first in the current directory and then in the directory specified by
the B<LLVM_LIB_SEARCH_PATH> environment variable. If it cannot find the object,
it fails.
When looking for a library specified with the B<-l> option, B<gccld> first
attempts to load a file with that name from the current directory. If that
fails, it looks for libI<library>.bc, libI<library>.a, or libI<library>.I<shared
library extension>, in that order, in each directory added to the library search
path with the B<-L> option. These directories are searched in the order they
were specified. If the library cannot be located, then B<gccld> looks in the
directory specified by the B<LLVM_LIB_SEARCH_PATH> environment variable. If it
does not find a library there, it fails.
The shared library extension may be I<.so>, I<.dyld>, I<.dll>, or something
different, depending upon the system.
The B<-L> option is global. It does not matter where it is specified in the
list of command line arguments; the directory is simply added to the search path
and is applied to all libraries, preceding or succeeding, in the command line.
=head2 Link order
All object files are linked first in the order they were specified on the
command line. All library files are linked next. Some libraries may not be
linked into the object program; see below.
=head2 Library Linkage
Object files and static bytecode objects are always linked into the output
file. Library archives (.a files) load only the objects within the archive
that define symbols needed by the output file. Hence, libraries should be
listed after the object files and libraries which need them; otherwise, the
library may not be linked in, and the dependent library will not have its
undefined symbols defined.
=head2 Native code generation
The B<gccld> program has limited support for native code generation, when
using the B<-native> or B<-native-cbe> options.
=head1 OPTIONS
=over
=item B<-help>
Print a summary of command line options.
=item B<-o> I<filename>
Specify the output filename which will hold the linked bytecode.
=item B<-stats>
Print statistics.
=item B<-time-passes>
Record the amount of time needed for each pass and print it to standard
error.
=item B<-verify>
Verify each pass result.
=item B<-disable-opt>
Disable all link-time optimization passes.
=item B<-disable-inlining>
Do not run the inliner pass.
=item B<-L>I<directory>
Add directory to the list of directories to search when looking for
libraries.
=item B<-disable-internalize>
Do not mark all symbols as internal.
=item B<-internalize-public-api-file> I<filename>
Preserve the list of symbol names in the file filename.
=item B<-internalize-public-api-list> I<list>
Preserve the symbol names in list.
=item B<-l>I<library>
Specify libraries to include when linking the output file. When linking,
B<gccld> will first attempt to load a file with the pathname B<library>. If
that fails, it will then attempt to load libI<library>.bc, libI<library>.a, and
libI<library>.I<shared library extension>, in that order.
=item B<-link-as-library>
Link the .bc files together as a library, not an executable.
=item B<-native>
Generate a native machine code executable.
When generating native executables, B<gccld> first checks for a bytecode
version of the library and links it in, if necessary. If the library is
missing, B<gccld> skips it. Then, B<gccld> links in the same
libraries as native code.
In this way, B<gccld> should be able to link in optimized bytecode
subsets of common libraries and then link in any part of the library that
hasn't been converted to bytecode.
=item B<-native-cbe>
Generate a native machine code executable with the LLVM C backend.
This option is identical to the B<-native> option, but uses the
C backend to generate code for the program instead of an LLVM native
code generator.
=item B<-s>
Strip symbol information from the generated executable.
=item B<-v>
Print information about actions taken.
=back
=head1 EXIT STATUS
If B<gccld> succeeds, it will exit with an exit status of 0.
Otherwise, if an error occurs, it will exit with a non-zero exit
status.
=head1 SEE ALSO
L<llvm-link|llvm-link>, L<gccas|gccas>
=head1 AUTHORS
Maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
=cut

View File

@@ -38,9 +38,6 @@ options) arguments to the tool you are interested in.</p>
<li><a href="html/llvm-dis.html"><b>llvm-dis</b></a> -
disassemble a bytecode file into a human-readable .ll file</li>
<li><a href="html/llvm-upgrade.html"><b>llvm-upgrade</b></a> -
upgrade LLVM assembly from previous version</li>
<li><a href="html/opt.html"><b>opt</b></a> -
run a series of LLVM-to-LLVM optimizations on a bytecode file</li>
@@ -54,6 +51,9 @@ options) arguments to the tool you are interested in.</p>
<li><a href="html/llvm-link.html"><b>llvm-link</b></a> -
link several bytecode files into one</li>
<li><a href="html/analyze.html"><b>analyze</b></a> -
run LLVM analyses on a bytecode file and print the results</li>
<li><a href="html/llvm-ar.html"><b>llvm-ar</b></a> -
archive bytecode files</li>
@@ -72,11 +72,6 @@ options) arguments to the tool you are interested in.</p>
<li><a href="html/llvm-ld.html"><b>llvm-ld</b></a> -
general purpose linker with loadable runtime optimization support</li>
<li><a href="html/llvm-config.html"><b>llvm-config</b></a> -
print out LLVM compilation options, libraries, etc. as configured.</li>
<li><a href="html/llvm2cpp.html"><b>llvm2cpp</b></a> - convert LLVM assembly
into the corresponding LLVM C++ API calls to produce it</li>
</ul>
</div>
@@ -96,6 +91,12 @@ options) arguments to the tool you are interested in.</p>
<li><a href="html/llvmgxx.html"><b>llvmg++</b></a> -
GCC-based C++ front-end for LLVM</li>
<li><a href="html/gccas.html"><b>gccas</b></a> -
compile-time optimizer used by llvm-g++ and llvm-gcc</li>
<li><a href="html/gccld.html"><b>gccld</b></a> -
linker and link-time optimizer used by llvm-g++ and llvm-gcc</li>
<li><a href="html/stkrc.html"><b>stkrc</b></a> -
front-end compiler for the <a href="../Stacker.html">Stacker</a>
language</li>
@@ -126,21 +127,7 @@ options) arguments to the tool you are interested in.</p>
represents)</li>
</ul>
</div>
<!-- *********************************************************************** -->
<div class="doc_section">
<a name="internal">Internal Tools</a>
</div>
<!-- *********************************************************************** -->
<div class="doc_text">
<ul>
<li><a href="html/tblgen.html"><b>tblgen</b></a> -
target description reader and generator</li>
</ul>
</div>
<!-- *********************************************************************** -->
@@ -152,7 +139,7 @@ options) arguments to the tool you are interested in.</p>
<a href="http://validator.w3.org/check/referer"><img
src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"></a>
<a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
<a href="http://llvm.cs.uiuc.edu">LLVM Compiler Infrastructure</a><br>
Last modified: $Date$
</address>

View File

@@ -46,31 +46,11 @@ Print a summary of command line options.
Overwrite output files. By default, B<llc> will refuse to overwrite
an output file which already exists.
=item B<-mtriple>=I<target triple>
Override the target triple specified in the input bytecode file with the
specified string.
=item B<-march>=I<arch>
Specify the architecture for which to generate assembly, overriding the target
encoded in the bytecode file. See the output of B<llc --help> for a list of
valid architectures. By default this is inferred from the target triple or
autodetected to the current architecture.
=item B<-mcpu>=I<cpuname>
Specify a specific chip in the current architecture to generate code for.
By default this is inferred from the target triple and autodetected to
the current architecture. For a list of available CPUs, use:
B<llvm-as E<lt> /dev/null | llc -march=xyz -mcpu=help>
=item B<-mattr>=I<a1,+a2,-a3,...>
Override or control specific attributes of the target, such as whether SIMD
operations are enabled or not. The default set of attributes is set by the
current CPU. For a list of available attributes, use:
B<llvm-as E<lt> /dev/null | llc -march=xyz -mattr=help>
valid architectures.
=item B<--disable-fp-elim>
@@ -175,6 +155,20 @@ syntax.
=back
=head2 SPARCV9-specific Options
=over
=item B<--disable-peephole>
Disable peephole optimization pass.
=item B<--disable-sched>
Disable local scheduling pass.
=back
=head1 EXIT STATUS
If B<llc> succeeds, it will exit with 0. Otherwise, if an error occurs,
@@ -186,6 +180,6 @@ L<lli|lli>
=head1 AUTHORS
Maintained by the LLVM Team (L<http://llvm.org>).
Maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
=cut

View File

@@ -40,32 +40,11 @@ the just-in-time compiler, at present.
Record the amount of time needed for each code-generation pass and print it to
standard error.
=item B<-mtriple>=I<target triple>
Override the target triple specified in the input bytecode file with the
specified string. This may result in a crash if you pick an
architecture which is not compatible with the current system.
=item B<-march>=I<arch>
Specify the architecture for which to generate assembly, overriding the target
encoded in the bytecode file. See the output of B<llc --help> for a list of
valid architectures. By default this is inferred from the target triple or
autodetected to the current architecture.
=item B<-mcpu>=I<cpuname>
Specify a specific chip in the current architecture to generate code for.
By default this is inferred from the target triple and autodetected to
the current architecture. For a list of available CPUs, use:
B<llvm-as E<lt> /dev/null | llc -march=xyz -mcpu=help>
=item B<-mattr>=I<a1,+a2,-a3,...>
Override or control specific attributes of the target, such as whether SIMD
operations are enabled or not. The default set of attributes is set by the
current CPU. For a list of available attributes, use:
B<llvm-as E<lt> /dev/null | llc -march=xyz -mattr=help>
Use the specified non-default architecture arch when selecting a code generator
for the just-in-time compiler. This may result in a crash if you pick an
architecture which is not compatible with the hardware you are running B<lli> on.
=item B<-force-interpreter>=I<{false,true}>
@@ -92,6 +71,6 @@ L<llc|llc>
=head1 AUTHOR
Maintained by the LLVM Team (L<http://llvm.org>).
Maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
=cut

View File

@@ -397,10 +397,10 @@ exit code of 3.
=head1 SEE ALSO
L<llvm-ranlib|llvm-ranlib>, ar(1)
L<llvm-ranlib|llvm-ranlib>, L<ar(1)>
=head1 AUTHORS
Maintained by the LLVM Team (L<http://llvm.org>).
Maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
=cut

View File

@@ -72,6 +72,6 @@ L<llvm-dis|llvm-dis>, L<gccas|gccas>
=head1 AUTHORS
Maintained by the LLVM Team (L<http://llvm.org>).
Maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
=cut

View File

@@ -306,10 +306,10 @@ Rate encoding scheme. The percentage is relative to # of VBR Expanded Bytes.
=head1 SEE ALSO
L<llvm-dis|llvm-dis>, L<http://llvm.org/docs/BytecodeFormat.html>
L<llvm-dis|llvm-dis>, L<http://llvm.cs.uiuc.edu/docs/BytecodeFormat.html>
=head1 AUTHORS
Maintained by the LLVM Team (L<http://llvm.org>).
Maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
=cut

View File

@@ -1,131 +0,0 @@
=pod
=head1 NAME
llvm-config - Print LLVM compilation options
=head1 SYNOPSIS
B<llvm-config> I<option> [I<components>...]
=head1 DESCRIPTION
B<llvm-config> makes it easier to build applications that use LLVM. It can
print the compiler flags, linker flags and object libraries needed to link
against LLVM.
=head1 EXAMPLES
To link against the JIT:
g++ `llvm-config --cxxflags` -o HowToUseJIT.o -c HowToUseJIT.cpp
g++ `llvm-config --ldflags` -o HowToUseJIT HowToUseJIT.o \
`llvm-config --libs engine bcreader scalaropts`
=head1 OPTIONS
=over
=item B<--version>
Print the version number of LLVM.
=item B<--help>
Print a summary of B<llvm-config> arguments.
=item B<--prefix>
Print the installation prefix for LLVM.
=item B<--src-root>
Print the source root from which LLVM was built.
=item B<--obj-root>
Print the object root used to build LLVM.
=item B<--bindir>
Print the installation directory for LLVM binaries.
=item B<--includedir>
Print the installation directory for LLVM headers.
=item B<--libdir>
Print the installation directory for LLVM libraries.
=item B<--cxxflags>
Print the C++ compiler flags needed to use LLVM headers.
=item B<--ldflags>
Print the flags needed to link against LLVM libraries.
=item B<--libs>
Print all the libraries needed to link against the specified LLVM
I<components>, including any dependencies.
=item B<--libnames>
Similar to B<--libs>, but prints the bare filenames of the libraries
without B<-l> or pathnames. Useful for linking against a not-yet-installed
copy of LLVM.
=item B<--libfiles>
Similar to B<--libs>, but print the full path to each library file. This is
useful when creating makefile dependencies, to ensure that a tool is relinked if
any library it uses changes.
=item B<--components>
Print all valid component names.
=item B<--targets-built>
Print the component names for all targets supported by this copy of LLVM.
=item B<--build-mode>
Print the build mode used when LLVM was built (e.g. Debug or Release)
=back
=head1 COMPONENTS
To print a list of all available components, run B<llvm-config
--components>. In most cases, components correspond directly to LLVM
libraries. Useful "virtual" components include:
=over
=item B<all>
Includes all LLVM libaries. The default if no components are specified.
=item B<backend>
Includes either a native backend or the C backend.
=item B<engine>
Includes either a native JIT or the bytecode interpreter.
=back
=head1 EXIT STATUS
If B<llvm-config> succeeds, it will exit with 0. Otherwise, if an error
occurs, it will exit with a non-zero value.
=head1 AUTHORS
Maintained by the LLVM Team (L<http://llvm.org>).
=cut

View File

@@ -7,10 +7,10 @@ llvm-db - LLVM debugger (alpha)
=head1 SYNOPSIS
Details coming soon. Please see
L<http://llvm.org/docs/SourceLevelDebugging.html> in the meantime.
L<http://llvm.cs.uiuc.edu/docs/SourceLevelDebugging.html> in the meantime.
=head1 AUTHORS
Maintained by the LLVM Team (L<http://llvm.org>).
Maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
=cut

View File

@@ -55,6 +55,6 @@ L<llvm-as|llvm-as>
=head1 AUTHORS
Maintained by the LLVM Team (L<http://llvm.org>).
Maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
=cut

View File

@@ -58,6 +58,6 @@ L<bugpoint|bugpoint>
=head1 AUTHORS
Maintained by the LLVM Team (L<http://llvm.org>).
Maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
=cut

View File

@@ -10,89 +10,11 @@ B<llvm-ld> <options> <files>
=head1 DESCRIPTION
The B<llvm-ld> tool takes a set of LLVM bytecode files and links them
together into a single LLVM bytecode file. The output bytecode file can be
another bytecode file or an executable bytecode program. Using additional
options, B<llvm-ld> is able to produce native code executables.
The B<llvm-ld> tool is the main linker for LLVM. It is used to link together
the output of LLVM front-end compilers and run "link time" optimizations (mostly
the inter-procedural kind).
The B<llvm-ld> tools attemps to mimic the interface provided by the default
system linker so that it can act as a I<drop-in> replacement.
=head2 Search Order
When looking for objects specified on the command line, B<llvm-ld> will search
for the object first in the current directory and then in the directory
specified by the B<LLVM_LIB_SEARCH_PATH> environment variable. If it cannot
find the object, it fails.
When looking for a library specified with the B<-l> option, B<llvm-ld> first
attempts to load a file with that name from the current directory. If that
fails, it looks for libI<library>.bc, libI<library>.a, or libI<library>.I<shared
library extension>, in that order, in each directory added to the library search
path with the B<-L> option. These directories are searched in the order they
are specified. If the library cannot be located, then B<llvm-ld> looks in the
directory specified by the B<LLVM_LIB_SEARCH_PATH> environment variable. If it
does not find a library there, it fails.
The I<shared library extension> may be I<.so>, I<.dyld>, I<.dll>, or something
different, depending upon the system.
The B<-L> option is global. It does not matter where it is specified in the
list of command line arguments; the directory is simply added to the search path
and is applied to all libraries, preceding or succeeding, in the command line.
=head2 Link order
All object and bytecode files are linked first in the order they were
specified on the command line. All library files are linked next.
Some libraries may not be linked into the object program; see below.
=head2 Library Linkage
Object files and static bytecode objects are always linked into the output
file. Library archives (.a files) load only the objects within the archive
that define symbols needed by the output file. Hence, libraries should be
listed after the object files and libraries which need them; otherwise, the
library may not be linked in, and the dependent library will not have its
undefined symbols defined.
=head2 Native code generation
The B<llvm-ld> program has limited support for native code generation, when
using the B<-native> or B<-native-cbe> options. Native code generation is
perfomed by converting the linked bytecode into native assembly (.s) or C code
and running the system compiler (typically gcc) on the result.
The B<llvm-ld> command is similar to the common Unix utility, C<ld>. It
links together bytecode modules to produce an executable program.
=head1 OPTIONS
=head2 General Options
=over
=item B<-help>
Print a summary of command line options.
=item B<-v>
Specifies verbose mode. In this mode the linker will print additional
information about the actions it takes, programs it executes, etc.
=item B<-stats>
Print statistics.
=item B<-time-passes>
Record the amount of time needed for each pass and print it to standard
error.
=back
=head2 Input/Output Options
=over
@@ -134,24 +56,16 @@ Specifies the kind of machine for which code or assembly should be generated.
=item B<-native>
Generate a native machine code executable.
When generating native executables, B<llvm-ld> first checks for a bytecode
version of the library and links it in, if necessary. If the library is
missing, B<llvm-ld> skips it. Then, B<llvm-ld> links in the same
libraries as native code.
In this way, B<llvm-ld> should be able to link in optimized bytecode
subsets of common libraries and then link in any part of the library that
hasn't been converted to bytecode.
Generate a native binary instead of a shell script that runs the JIT from
bytecode.
=item B<-native-cbe>
Generate a native machine code executable with the LLVM C backend.
This option is identical to the B<-native> option, but uses the
C backend to generate code for the program instead of an LLVM native
code generator.
Generate a native binary with the C back end and compilation with GCC.
=item B<-disable-compression>
Do not compress bytecode files.
=back
@@ -201,30 +115,18 @@ no link time optimization passes will be run.
Do not mark all symbols as internal.
=item B<-verify-each>
=item B<-verify>
Run the verification pass after each of the passes to verify intermediate
results.
=item B<-strip-all>
Strip all debug and symbol information from the executable to make it smaller.
=item B<-strip-debug>
Strip all debug information from the executable to make it smaller.
=item B<-s>
An alias for B<-strip-all>.
=item B<-S>
An alias for B<-strip-debug>.
Strip symbol info from the executable to make it smaller.
=item B<-export-dynamic>
An alias for B<-disable-internalize>
An alias for -disable-internalize
=item B<-load> F<module>
@@ -234,16 +136,16 @@ be passed the PassManager, and the optimization level (values 0-5 based on the
B<-On> option). This function may add passes to the PassManager that should be
run. This feature allows the optimization passes of B<llvm-ld> to be extended.
=item B<-post-link-opt>F<Path>
=back
Run post-link optimization program. After linking is completed a bytecode file
will be generated. It will be passed to the program specified by F<Path> as the
first argument. The second argument to the program will be the name of a
temporary file into which the program should place its optimized output. For
example, the "no-op optimization" would be a simple shell script:
=head2 Miscellaneous Options
#!/bin/bash
cp $1 $2
=over
=item B<-v>
Specifies verbose mode. In this mode the linker will print additional
information about the actions it takes, programs it executes, etc.
=back
@@ -260,10 +162,10 @@ options.
=head1 SEE ALSO
L<llvm-link|llvm-link>
L<llvm-ar|llvm-ar>
=head1 AUTHORS
Maintained by the LLVM Team (L<http://llvm.org>).
Maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
=cut

View File

@@ -69,6 +69,6 @@ L<gccld|gccld>
=head1 AUTHORS
Maintained by the LLVM Team (L<http://llvm.org>).
Maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
=cut

View File

@@ -113,10 +113,10 @@ B<llvm-nm> exits with an exit code of zero.
=head1 SEE ALSO
L<llvm-dis|llvm-dis>, ar(1), nm(1)
L<llvm-dis|llvm-dis>, L<ar(1)>, L<nm(1)>
=head1 AUTHOR
Maintained by the LLVM Team (L<http://llvm.org>).
Maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
=cut

View File

@@ -52,6 +52,6 @@ information. Otherwise, it exits with zero.
=head1 AUTHOR
B<llvm-prof> is maintained by the LLVM Team (L<http://llvm.org>).
B<llvm-prof> is maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
=cut

View File

@@ -47,6 +47,6 @@ L<llvm-ar|llvm-ar>, ranlib(1)
=head1 AUTHORS
Maintained by the LLVM Team (L<http://llvm.org>).
Maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
=cut

View File

@@ -1,66 +0,0 @@
=pod
=head1 NAME
llvm-upgrade - LLVM assembly upgrader
=head1 SYNOPSIS
B<llvm-upgrade> [I<options>] [I<filename>]
=head1 DESCRIPTION
B<llvm-upgrade> is the LLVM assembly upgrader. It reads a file containing
human-readable LLVM assembly language, and upgrades that assembly to the current
version of LLVM. If the input is in the form currently accepted by LLVM, then
no upgrades are performed.
The expected usage of this tool is as a filter, like this:
=over
B<llvm-1.9/bin/llvm-dis < 1.9.bc | llvm-upgrade | llvm-2.0/bin/llvm-as -o 2.0.bc>
=back
If F<filename> is omitted or is C<->, then B<llvm-upgrade> reads its input from
standard input.
If an output file is not specified with the B<-o> option, then
B<llvm-upgrade> sends its output to standard output.
=head1 OPTIONS
=over
=item B<-f>
Force overwrite. Normally, B<llvm-upgrade> will refuse to overwrite an
output file that already exists. With this option, B<llvm-upgrade>
will overwrite the output file.
=item B<--help>
Print a summary of command line options.
=item B<-o> F<filename>
Specify the output file name. If F<filename> is C<->, then B<llvm-upgrade>
sends its output to standard output.
=back
=head1 EXIT STATUS
If B<llvm-upgrade> succeeds, it will exit with 0. Otherwise, if an error
occurs, it will exit with a non-zero value.
=head1 SEE ALSO
L<llvm-as|llvm-as>, L<llvm-dis|llvm-dis>
=head1 AUTHORS
Maintained by the LLVM Team (L<http://llvm.org>).
=cut

View File

@@ -1,209 +0,0 @@
=pod
=head1 NAME
llvm2xpp - LLVM bytecode to LLVM C++ IR translator
=head1 SYNOPSIS
B<llvm2cpp> [I<options>] [I<filename>]
=head1 DESCRIPTION
B<llvm2cpp> translates from LLVM bytecode (.bc files) to a
corresponding C++ source file that will make calls against the LLVM C++ API to
build the same module as the input. By default, the C++ output is a complete
program that builds the module, verifies it and then emits the module as
LLVM assembly. This technique assists with testing because the input to
B<llvm2cpp> and the output of the generated C++ program should be identical.
If F<filename> is omitted or is C<->, then B<llvm2cpp> reads its input from
standard input.
If an output file is not specified with the B<-o> option, then
B<llvm2cpp> sends its output to a file or standard output by following
these rules:
=over
=item *
If the input is standard input, then the output is standard output.
=item *
If the input is a file that ends with C<.bc>, then the output file is of
the same name, except that the suffix is changed to C<.cpp>.
=item *
If the input is a file that does not end with the C<.bc> suffix, then the
output file has the same name as the input file, except that the C<.cpp>
suffix is appended.
=back
=head1 OPTIONS
=over
=item B<-f>
Force overwrite. Normally, B<llvm2cpp> will refuse to overwrite an
output file that already exists. With this option, B<llvm2cpp>
will overwrite the output file and replace it with new C++ source code.
=item B<--help>
Print a summary of command line options.
=item B<-f>
Normally, B<llvm2cpp> will not overwrite an existing output file. With this
option, that default behavior is changed and the program will overwrite existing
output files.
=item B<-o> F<filename>
Specify the output file name. If F<filename> is C<->, then B<llvm2cpp>
sends its output to standard output.
=item B<-funcname> F<functionName>
Specify the name of the function to be generated. The generated code contains a
single function that produces the input module. By default its name is
I<makeLLVMModule>. The B<-funcname> option overrides this default and allows
you to control the name of the generated function. This is handy in conjunction
with the B<-fragment> option when you only want B<llvm2cpp> to generate a
single function that produces the module. With both options, such generated code
could be I<#included> into another program.
=item B<-for>
Specify the name of the thing for which C++ code should be generated. By default
the entire input module is re-generated. However, use of the various B<-gen-*>
options can restrict what is produced. This option indicates what that
restriction is.
=item B<-gen-program>
Specify that the output should be a complete program. Such program will recreate
B<llvm2cpp>'s input as an LLVM module, verify that module, and then write out
the module in LLVM assembly format. This is useful for doing identity tests
where the output of the generated program is identical to the input to
B<llvm2cpp>. The LLVM DejaGnu test suite can make use of this fact. This is the
default form of generated output.
If the B<-for> option is given with this option, it specifies the module
identifier to use for the module created.
=item B<-gen-module>
Specify that the output should be a function that regenerates the module. It is
assumed that this output will be #included into another program that has already
arranged for the correct header files to be #included. The function generated
takes no arguments and returns a I<Module*>.
If the B<-for> option is given with this option, it specifies the module
identifier to use in creating the module returned by the generated function.
=item B<-gen-contents>
Specify that the output should be a function that adds the contents of the input
module to another module. It is assumed that the output will be #included into
another program that has already arranged for the correct header files to be
#included. The function generated takes a single argument of type I<Module*> and
returns that argument. Note that Module level attributes such as endianess,
pointer size, target triple and inline asm are not passed on from the input
module to the destination module. Only the sub-elements of the module (types,
constants, functions, global variables) will be added to the input module.
If the B<-for> option is given with this option, it specifies the module
identifier to set in the input module by the generated function.
=item B<-gen-function>
Specify that the output should be a function that produces the definitions
necessary for a specific function to be added to a module. It is assumed that
the output will be #included into another program that has already arranged
for the correct header files to be #included. The function generated takes a
single argument of type I<Module*> and returns the I<Function*> that it added to
the module. Note that only those things (types, constants, etc.) directly
needed in the definition of the function will be placed in the generated
function.
The B<-for> option must be given with this option or an error will be produced.
The value of the option must be the name of a function in the input module for
which code should be generated. If the named function does not exist an error
will be produced.
=item B<-gen-inline>
This option is very analagous to B<-gen-function> except that the generated
function will not re-produce the target function's definition. Instead, the body
of the target function is inserted into some other function passed as an
argument to the generated function. Similarly any arguments to the function must
be passed to the generated function. The result of the generated function is the
first basic block of the target function.
The B<-for> option works the same way as it does for B<-gen-function>.
=item B<-gen-variable>
Specify that the output should be a function that produces the definitions
necessary for a specific global variable to be added to a module. It is assumed
that the output will be #included into another program that has already arranged
for the correct header files to be #included. The function generated takes a
single argument of type I<Module*> and returns the I<GlobalVariable*> that it
added to the module. Note that only those things (types, constants, etc.)
directly needed in the definition of the global variable will be placed in the
generated function.
The B<-for> option must be given with this option or an error will be produced.
THe value of the option must be the name of a global variable in the input
module for which code should be generated. If the named global variable does not
exist an error will be produced.
=item B<-gen-type>
Specify that the output should be a function that produces the definitions
necessary for specific type to be added to a module. It is assumed that the
otuput will be #included into another program that has already arranged for the
correct header files to be #included. The function generated take a single
argument of type I<Module*> and returns the I<Type*> that it added to the
module. Note that the generated function will only add the necessary type
definitions to (possibly recursively) define the requested type.
The B<-for> option must be given with this option or an error will be produced.
The value of the option must be the name of a global type in the input module
for which code should be generated. If the named type does not exist an error
will be produced.
=item B<-stats>
Show pass statistics (not interesting in this program).
=item B<-time-passes>
Show pass timing statistics (not interesting in this program).
=item B<-version>
Show the version number of this program.
=back
=head1 EXIT STATUS
If B<llvm2cpp> succeeds, it will exit with 0. Otherwise, if an error
occurs, it will exit with a non-zero value.
=head1 SEE ALSO
L<llvm-as|llvm-as> L<tblgen|tblgen>
=head1 AUTHORS
Written by Reid Spencer (L<http://hlvm.org>).
=cut

View File

@@ -2,7 +2,7 @@
=head1 NAME
llvmc - The LLVM Compiler Driver (experimental)
llvmc - The LLVM Compiler Driver
=head1 SYNOPSIS
@@ -12,8 +12,8 @@ B<llvmc> [I<options>] [I<filenames>...]
B<llvmc> is a configurable driver for invoking other LLVM (and non-LLVM) tools
in order to compile, optimize and link software for multiple languages. For
those familiar with FSF's B<gcc> tool, it is very similar. Please note that
B<llvmc> is considered an experimental tool. B<llvmc> has the following goals:
those familiar with FSF's B<gcc> tool, it is very similar. B<llvmc> has the
following goals:
=over
@@ -337,8 +337,6 @@ been read. This allows users or groups of users to conveniently create
their own configuration directories in addition to the standard ones to which
they may not have write access.
=back
=head2 Unimplemented Options
@@ -395,37 +393,13 @@ will be taken. If one of the compilation tools returns a non-zero
status, pending actions will be discarded and B<llvmc> will return the
same result code as the failing compilation tool.
=head1 DEFICIENCIES
B<llvmc> is considered an experimental LLVM tool because it has these
deficiencies:
=over
=item Insufficient support for native linking
Because B<llvm-ld> doesn't handle native linking, neither can B<llvmc>
=item Poor configuration support
The support for configuring new languages, etc. is weak. There are many
command line configurations that cannot be achieved with the current
support. Furthermore the grammar is cumbersome for configuration files.
Please see L<http://llvm.org/PR686> for further details.
=item Does not handle target specific configurations
This is one of the major deficiencies, also addressed in
L<http://llvm.org/PR686>
=back
=head1 SEE ALSO
L<llvm-as|llvm-as>, L<llvm-dis|llvm-dis>, L<llc|llc>, L<llvm-link|llvm-link>
L<gccas|gccas>, L<gccld|gccld>, L<llvm-as|llvm-as>, L<llvm-dis|llvm-dis>,
L<llc|llc>, L<llvm-link|llvm-link>
=head1 AUTHORS
Maintained by the LLVM Team (L<http://llvm.org>).
Maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
=cut

View File

@@ -11,12 +11,15 @@ B<llvm-gcc> [I<options>] I<filename>
=head1 DESCRIPTION
The B<llvm-gcc> command is the LLVM C front end. It is a modified
version of gcc that compiles C/ObjC programs into native objects, LLVM
bytecode or LLVM assembly language, depending upon the options.
version of gcc that takes C programs and compiles them into LLVM
bytecode or assembly language, depending upon the options.
By default, B<llvm-gcc> compiles to native objects just like GCC does. If the
B<-emit-llvm> option is given then it will generate LLVM bytecode files instead.
If B<-S> (assembly) is also given, then it will generate LLVM assembly.
Unless the B<-S> option is specified, B<llvm-gcc> will use the
L<gccas|gccas> program to perform some optimizations and create an
LLVM bytecode file. Unless the B<-c> option is specified, B<llvm-gcc>
will also use the L<gccld|gccld> program to perform further
optimizations and link the resulting bytecode file(s) with support
libraries to create an executable program.
Being derived from the GNU Compiler Collection, B<llvm-gcc> has many
of gcc's features and accepts most of gcc's options. It handles a
@@ -61,10 +64,17 @@ repeated.
Link in the library libI<name>.[bc | a | so]. This library should
be a bytecode library.
=item B<-emit-llvm>
=item B<-Wa,>I<option>
Make the output be LLVM bytecode (or assembly) instead of native object (or
assembly).
Pass I<option> to gccas
=item B<-Wl,>I<option>
Pass I<option> to gccld
=item B<-Wa,-disable-inlining -Wl,-disable-inlining>
Fully disable all inlining
=back
@@ -75,11 +85,11 @@ occurs, it will exit with a non-zero value.
=head1 SEE ALSO
L<llvm-g++|llvmgxx>
L<llvm-g++|llvmgxx>, L<gccas|gccas>, L<gccld|gccld>
=head1 AUTHORS
Maintained by the LLVM Team (L<http://llvm.org>).
Maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
=cut

View File

@@ -11,12 +11,15 @@ B<llvm-g++> [I<options>] I<filename>
=head1 DESCRIPTION
The B<llvm-g++> command is the LLVM C++ front end. It is a modified
version of g++ that compiles C++/ObjC++ programs into native code,
LLVM bytecode or assembly language, depending upon the options.
version of g++ that takes C++ programs and compiles them into LLVM
bytecode or assembly language, depending upon the options.
By default, B<llvm-g++> compiles to native objects just like GCC does. If the
B<-emit-llvm> option is given then it will generate LLVM bytecode files instead.
If B<-S> (assembly) is also given, then it will generate LLVM assembly.
Unless the B<-S> option is specified, B<llvm-g++> will use the
L<gccas|gccas> program to perform some optimizations and create an
LLVM bytecode file. Unless the B<-c> option is specified, B<llvm-g++>
will also use the L<gccld|gccld> program to perform further
optimizations and link the resulting bytecode file(s) with support
libraries to create an executable program.
Being derived from the GNU Compiler Collection, B<llvm-g++> has many
of g++'s features and accepts most of g++'s options. It handles a
@@ -61,10 +64,17 @@ repeated.
Link in the library libI<name>.[bc | a | so]. This library should
be a bytecode library.
=item B<-emit-llvm>
=item B<-Wa,>I<option>
Make the output be LLVM bytecode (or assembly) instead of native object (or
assembly).
Pass I<option> to gccas
=item B<-Wl,>I<option>
Pass I<option> to gccld
=item B<-Wa,-disable-inlining -Wl,-disable-inlining>
Fully disable all inlining
=back
@@ -75,11 +85,11 @@ occurs, it will exit with a non-zero value.
=head1 SEE ALSO
L<llvm-gcc|llvmgcc>
L<llvm-gcc|llvmgcc>, L<gccas>, L<gccld>
=head1 AUTHORS
Maintained by the LLVM Team (L<http://llvm.org>).
Maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
=cut

View File

@@ -1,240 +0,0 @@
.\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.14
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sh \" Subsection heading
.br
.if t .Sp
.ne 5
.PP
\fB\\$1\fR
.PP
..
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings. \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote. | will give a
.\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used to
.\" do unbreakable dashes and therefore won't be available. \*(C` and \*(C'
.\" expand to `' in nroff, nothing in troff, for use with C<>.
.tr \(*W-|\(bv\*(Tr
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
. ds -- \(*W-
. ds PI pi
. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
. ds L" ""
. ds R" ""
. ds C` ""
. ds C' ""
'br\}
.el\{\
. ds -- \|\(em\|
. ds PI \(*p
. ds L" ``
. ds R" ''
'br\}
.\"
.\" If the F register is turned on, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
.\" entries marked with X<> in POD. Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.if \nF \{\
. de IX
. tm Index:\\$1\t\\n%\t"\\$2"
..
. nr % 0
. rr F
.\}
.\"
.\" For nroff, turn off justification. Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.hy 0
.if n .na
.\"
.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
.\" Fear. Run. Save yourself. No user-serviceable parts.
. \" fudge factors for nroff and troff
.if n \{\
. ds #H 0
. ds #V .8m
. ds #F .3m
. ds #[ \f1
. ds #] \fP
.\}
.if t \{\
. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
. ds #V .6m
. ds #F 0
. ds #[ \&
. ds #] \&
.\}
. \" simple accents for nroff and troff
.if n \{\
. ds ' \&
. ds ` \&
. ds ^ \&
. ds , \&
. ds ~ ~
. ds /
.\}
.if t \{\
. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
.\}
. \" troff and (daisy-wheel) nroff accents
.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
.ds ae a\h'-(\w'a'u*4/10)'e
.ds Ae A\h'-(\w'A'u*4/10)'E
. \" corrections for vroff
.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
. \" for low resolution devices (crt and lpr)
.if \n(.H>23 .if \n(.V>19 \
\{\
. ds : e
. ds 8 ss
. ds o a
. ds d- d\h'-1'\(ga
. ds D- D\h'-1'\(hy
. ds th \o'bp'
. ds Th \o'LP'
. ds ae ae
. ds Ae AE
.\}
.rm #[ #] #H #V #F C
.\" ========================================================================
.\"
.IX Title "BUGPOINT 1"
.TH BUGPOINT 1 "2006-09-13" "CVS" "LLVM Command Guide"
.SH "NAME"
bugpoint \- automatic test case reduction tool
.SH "SYNOPSIS"
.IX Header "SYNOPSIS"
\&\fBbugpoint\fR [\fIoptions\fR] [\fIinput \s-1LLVM\s0 ll/bc files\fR] [\fI\s-1LLVM\s0 passes\fR] \fB\-\-args\fR
\&\fIprogram arguments\fR
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
\&\fBbugpoint\fR narrows down the source of problems in \s-1LLVM\s0 tools and passes. It
can be used to debug three types of failures: optimizer crashes, miscompilations
by optimizers, or bad native code generation (including problems in the static
and \s-1JIT\s0 compilers). It aims to reduce large test cases to small, useful ones.
For more information on the design and inner workings of \fBbugpoint\fR, as well as
advice for using bugpoint, see \fIllvm/docs/Bugpoint.html\fR in the \s-1LLVM\s0
distribution.
.SH "OPTIONS"
.IX Header "OPTIONS"
.IP "\fB\-\-additional\-so\fR \fIlibrary\fR" 4
.IX Item "--additional-so library"
Load the dynamic shared object \fIlibrary\fR into the test program whenever it is
run. This is useful if you are debugging programs which depend on non-LLVM
libraries (such as the X or curses libraries) to run.
.IP "\fB\-\-args\fR \fIprogram args\fR" 4
.IX Item "--args program args"
Pass all arguments specified after \-args to the test program whenever it runs.
Note that if any of the \fIprogram args\fR start with a '\-', you should use:
.Sp
.Vb 1
\& bugpoint [bugpoint args] --args -- [program args]
.Ve
.Sp
The \*(L"\-\-\*(R" right after the \fB\-\-args\fR option tells \fBbugpoint\fR to consider any
options starting with \f(CW\*(C`\-\*(C'\fR to be part of the \fB\-\-args\fR option, not as options to
\&\fBbugpoint\fR itself.
.IP "\fB\-\-tool\-args\fR \fItool args\fR" 4
.IX Item "--tool-args tool args"
Pass all arguments specified after \-\-tool\-args to the \s-1LLVM\s0 tool under test
(\fBllc\fR, \fBlli\fR, etc.) whenever it runs. You should use this option in the
following way:
.Sp
.Vb 1
\& bugpoint [bugpoint args] --tool-args -- [tool args]
.Ve
.Sp
The \*(L"\-\-\*(R" right after the \fB\-\-tool\-args\fR option tells \fBbugpoint\fR to consider any
options starting with \f(CW\*(C`\-\*(C'\fR to be part of the \fB\-\-tool\-args\fR option, not as
options to \fBbugpoint\fR itself. (See \fB\-\-args\fR, above.)
.IP "\fB\-\-check\-exit\-code\fR=\fI{true,false}\fR" 4
.IX Item "--check-exit-code={true,false}"
Assume a non-zero exit code or core dump from the test program is a failure.
Defaults to true.
.IP "\fB\-\-disable\-{dce,simplifycfg}\fR" 4
.IX Item "--disable-{dce,simplifycfg}"
Do not run the specified passes to clean up and reduce the size of the test
program. By default, \fBbugpoint\fR uses these passes internally when attempting to
reduce test programs. If you're trying to find a bug in one of these passes,
\&\fBbugpoint\fR may crash.
.IP "\fB\-find\-bugs\fR" 4
.IX Item "-find-bugs"
Continually randomize the specified passes and run them on the test program
until a bug is found or the user kills \fBbugpoint\fR.
.IP "\fB\-\-help\fR" 4
.IX Item "--help"
Print a summary of command line options.
.IP "\fB\-\-input\fR \fIfilename\fR" 4
.IX Item "--input filename"
Open \fIfilename\fR and redirect the standard input of the test program, whenever
it runs, to come from that file.
.IP "\fB\-\-load\fR \fIplugin\fR" 4
.IX Item "--load plugin"
Load the dynamic object \fIplugin\fR into \fBbugpoint\fR itself. This object should
register new optimization passes. Once loaded, the object will add new command
line options to enable various optimizations. To see the new complete list of
optimizations, use the \fB\-\-help\fR and \fB\-\-load\fR options together; for example:
.Sp
.Vb 1
\& bugpoint --load myNewPass.so --help
.Ve
.IP "\fB\-\-output\fR \fIfilename\fR" 4
.IX Item "--output filename"
Whenever the test program produces output on its standard output stream, it
should match the contents of \fIfilename\fR (the \*(L"reference output\*(R"). If you
do not use this option, \fBbugpoint\fR will attempt to generate a reference output
by compiling the program with the C backend and running it.
.IP "\fB\-\-profile\-info\-file\fR \fIfilename\fR" 4
.IX Item "--profile-info-file filename"
Profile file loaded by \fB\-\-profile\-loader\fR.
.IP "\fB\-\-run\-{int,jit,llc,cbe}\fR" 4
.IX Item "--run-{int,jit,llc,cbe}"
Whenever the test program is compiled, \fBbugpoint\fR should generate code for it
using the specified code generator. These options allow you to choose the
interpreter, the \s-1JIT\s0 compiler, the static native code compiler, or the C
backend, respectively.
.IP "\fB\-\-enable\-valgrind\fR" 4
.IX Item "--enable-valgrind"
Use valgrind to find faults in the optimization phase. This will allow
bugpoint to find otherwise asymptomatic problems caused by memory
mis\-management.
.SH "EXIT STATUS"
.IX Header "EXIT STATUS"
If \fBbugpoint\fR succeeds in finding a problem, it will exit with 0. Otherwise,
if an error occurs, it will exit with a non-zero value.
.SH "SEE ALSO"
.IX Header "SEE ALSO"
opt
.SH "AUTHOR"
.IX Header "AUTHOR"
Maintained by the \s-1LLVM\s0 Team (<http://llvm.org>).

View File

@@ -1,277 +0,0 @@
.\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.14
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sh \" Subsection heading
.br
.if t .Sp
.ne 5
.PP
\fB\\$1\fR
.PP
..
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings. \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote. | will give a
.\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used to
.\" do unbreakable dashes and therefore won't be available. \*(C` and \*(C'
.\" expand to `' in nroff, nothing in troff, for use with C<>.
.tr \(*W-|\(bv\*(Tr
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
. ds -- \(*W-
. ds PI pi
. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
. ds L" ""
. ds R" ""
. ds C` ""
. ds C' ""
'br\}
.el\{\
. ds -- \|\(em\|
. ds PI \(*p
. ds L" ``
. ds R" ''
'br\}
.\"
.\" If the F register is turned on, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
.\" entries marked with X<> in POD. Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.if \nF \{\
. de IX
. tm Index:\\$1\t\\n%\t"\\$2"
..
. nr % 0
. rr F
.\}
.\"
.\" For nroff, turn off justification. Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.hy 0
.if n .na
.\"
.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
.\" Fear. Run. Save yourself. No user-serviceable parts.
. \" fudge factors for nroff and troff
.if n \{\
. ds #H 0
. ds #V .8m
. ds #F .3m
. ds #[ \f1
. ds #] \fP
.\}
.if t \{\
. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
. ds #V .6m
. ds #F 0
. ds #[ \&
. ds #] \&
.\}
. \" simple accents for nroff and troff
.if n \{\
. ds ' \&
. ds ` \&
. ds ^ \&
. ds , \&
. ds ~ ~
. ds /
.\}
.if t \{\
. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
.\}
. \" troff and (daisy-wheel) nroff accents
.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
.ds ae a\h'-(\w'a'u*4/10)'e
.ds Ae A\h'-(\w'A'u*4/10)'E
. \" corrections for vroff
.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
. \" for low resolution devices (crt and lpr)
.if \n(.H>23 .if \n(.V>19 \
\{\
. ds : e
. ds 8 ss
. ds o a
. ds d- d\h'-1'\(ga
. ds D- D\h'-1'\(hy
. ds th \o'bp'
. ds Th \o'LP'
. ds ae ae
. ds Ae AE
.\}
.rm #[ #] #H #V #F C
.\" ========================================================================
.\"
.IX Title "LLC 1"
.TH LLC 1 "2006-03-13" "CVS" "LLVM Command Guide"
.SH "NAME"
llc \- LLVM static compiler
.SH "SYNOPSIS"
.IX Header "SYNOPSIS"
\&\fBllc\fR [\fIoptions\fR] [\fIfilename\fR]
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
The \fBllc\fR command compiles \s-1LLVM\s0 bytecode into assembly language for a
specified architecture. The assembly language output can then be passed through
a native assembler and linker to generate a native executable.
.PP
The choice of architecture for the output assembly code is automatically
determined from the input bytecode file, unless the \fB\-march\fR option is used to
override the default.
.SH "OPTIONS"
.IX Header "OPTIONS"
If \fIfilename\fR is \- or omitted, \fBllc\fR reads \s-1LLVM\s0 bytecode from standard input.
Otherwise, it will read \s-1LLVM\s0 bytecode from \fIfilename\fR.
.PP
If the \fB\-o\fR option is omitted, then \fBllc\fR will send its output to standard
output if the input is from standard input. If the \fB\-o\fR option specifies \-,
then the output will also be sent to standard output.
.PP
If no \fB\-o\fR option is specified and an input file other than \- is specified,
then \fBllc\fR creates the output filename by taking the input filename,
removing any existing \fI.bc\fR extension, and adding a \fI.s\fR suffix.
.PP
Other \fBllc\fR options are as follows:
.Sh "End-user Options"
.IX Subsection "End-user Options"
.IP "\fB\-\-help\fR" 4
.IX Item "--help"
Print a summary of command line options.
.IP "\fB\-f\fR" 4
.IX Item "-f"
Overwrite output files. By default, \fBllc\fR will refuse to overwrite
an output file which already exists.
.IP "\fB\-mtriple\fR=\fItarget triple\fR" 4
.IX Item "-mtriple=target triple"
Override the target triple specified in the input bytecode file with the
specified string.
.IP "\fB\-march\fR=\fIarch\fR" 4
.IX Item "-march=arch"
Specify the architecture for which to generate assembly, overriding the target
encoded in the bytecode file. See the output of \fBllc \-\-help\fR for a list of
valid architectures. By default this is inferred from the target triple or
autodetected to the current architecture.
.IP "\fB\-mcpu\fR=\fIcpuname\fR" 4
.IX Item "-mcpu=cpuname"
Specify a specific chip in the current architecture to generate code for.
By default this is inferred from the target triple and autodetected to
the current architecture. For a list of available CPUs, use:
\&\fBllvm-as < /dev/null | llc \-march=xyz \-mcpu=help\fR
.IP "\fB\-mattr\fR=\fIa1,+a2,\-a3,...\fR" 4
.IX Item "-mattr=a1,+a2,-a3,..."
Override or control specific attributes of the target, such as whether \s-1SIMD\s0
operations are enabled or not. The default set of attributes is set by the
current \s-1CPU\s0. For a list of available attributes, use:
\&\fBllvm-as < /dev/null | llc \-march=xyz \-mattr=help\fR
.IP "\fB\-\-disable\-fp\-elim\fR" 4
.IX Item "--disable-fp-elim"
Disable frame pointer elimination optimization.
.IP "\fB\-\-disable\-excess\-fp\-precision\fR" 4
.IX Item "--disable-excess-fp-precision"
Disable optimizations that may produce excess precision for floating point.
Note that this option can dramatically slow down code on some systems
(e.g. X86).
.IP "\fB\-\-enable\-unsafe\-fp\-math\fR" 4
.IX Item "--enable-unsafe-fp-math"
Enable optimizations that make unsafe assumptions about \s-1IEEE\s0 math (e.g. that
addition is associative) or may not work for all input ranges. These
optimizations allow the code generator to make use of some instructions which
would otherwise not be usable (such as fsin on X86).
.IP "\fB\-\-enable\-correct\-eh\-support\fR" 4
.IX Item "--enable-correct-eh-support"
Instruct the \fBlowerinvoke\fR pass to insert code for correct exception handling
support. This is expensive and is by default omitted for efficiency.
.IP "\fB\-\-stats\fR" 4
.IX Item "--stats"
Print statistics recorded by code-generation passes.
.IP "\fB\-\-time\-passes\fR" 4
.IX Item "--time-passes"
Record the amount of time needed for each pass and print a report to standard
error.
.IP "\fB\-\-load\fR=\fIdso_path\fR" 4
.IX Item "--load=dso_path"
Dynamically load \fIdso_path\fR (a path to a dynamically shared object) that
implements an \s-1LLVM\s0 target. This will permit the target name to be used with the
\&\fB\-march\fR option so that code can be generated for that target.
.Sh "Tuning/Configuration Options"
.IX Subsection "Tuning/Configuration Options"
.IP "\fB\-\-print\-machineinstrs\fR" 4
.IX Item "--print-machineinstrs"
Print generated machine code between compilation phases (useful for debugging).
.IP "\fB\-\-regalloc\fR=\fIallocator\fR" 4
.IX Item "--regalloc=allocator"
Specify the register allocator to use. The default \fIallocator\fR is \fIlocal\fR.
Valid register allocators are:
.RS 4
.IP "\fIsimple\fR" 4
.IX Item "simple"
Very simple \*(L"always spill\*(R" register allocator
.IP "\fIlocal\fR" 4
.IX Item "local"
Local register allocator
.IP "\fIlinearscan\fR" 4
.IX Item "linearscan"
Linear scan global register allocator
.IP "\fIiterativescan\fR" 4
.IX Item "iterativescan"
Iterative scan global register allocator
.RE
.RS 4
.RE
.IP "\fB\-\-spiller\fR=\fIspiller\fR" 4
.IX Item "--spiller=spiller"
Specify the spiller to use for register allocators that support it. Currently
this option is used only by the linear scan register allocator. The default
\&\fIspiller\fR is \fIlocal\fR. Valid spillers are:
.RS 4
.IP "\fIsimple\fR" 4
.IX Item "simple"
Simple spiller
.IP "\fIlocal\fR" 4
.IX Item "local"
Local spiller
.RE
.RS 4
.RE
.Sh "Intel IA\-32\-specific Options"
.IX Subsection "Intel IA-32-specific Options"
.IP "\fB\-\-x86\-asm\-syntax=att|intel\fR" 4
.IX Item "--x86-asm-syntax=att|intel"
Specify whether to emit assembly code in \s-1AT&T\s0 syntax (the default) or intel
syntax.
.SH "EXIT STATUS"
.IX Header "EXIT STATUS"
If \fBllc\fR succeeds, it will exit with 0. Otherwise, if an error occurs,
it will exit with a non-zero value.
.SH "SEE ALSO"
.IX Header "SEE ALSO"
lli
.SH "AUTHORS"
.IX Header "AUTHORS"
Maintained by the \s-1LLVM\s0 Team (<http://llvm.org>).

View File

@@ -1,206 +0,0 @@
.\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.14
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sh \" Subsection heading
.br
.if t .Sp
.ne 5
.PP
\fB\\$1\fR
.PP
..
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings. \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote. | will give a
.\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used to
.\" do unbreakable dashes and therefore won't be available. \*(C` and \*(C'
.\" expand to `' in nroff, nothing in troff, for use with C<>.
.tr \(*W-|\(bv\*(Tr
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
. ds -- \(*W-
. ds PI pi
. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
. ds L" ""
. ds R" ""
. ds C` ""
. ds C' ""
'br\}
.el\{\
. ds -- \|\(em\|
. ds PI \(*p
. ds L" ``
. ds R" ''
'br\}
.\"
.\" If the F register is turned on, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
.\" entries marked with X<> in POD. Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.if \nF \{\
. de IX
. tm Index:\\$1\t\\n%\t"\\$2"
..
. nr % 0
. rr F
.\}
.\"
.\" For nroff, turn off justification. Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.hy 0
.if n .na
.\"
.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
.\" Fear. Run. Save yourself. No user-serviceable parts.
. \" fudge factors for nroff and troff
.if n \{\
. ds #H 0
. ds #V .8m
. ds #F .3m
. ds #[ \f1
. ds #] \fP
.\}
.if t \{\
. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
. ds #V .6m
. ds #F 0
. ds #[ \&
. ds #] \&
.\}
. \" simple accents for nroff and troff
.if n \{\
. ds ' \&
. ds ` \&
. ds ^ \&
. ds , \&
. ds ~ ~
. ds /
.\}
.if t \{\
. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
.\}
. \" troff and (daisy-wheel) nroff accents
.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
.ds ae a\h'-(\w'a'u*4/10)'e
.ds Ae A\h'-(\w'A'u*4/10)'E
. \" corrections for vroff
.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
. \" for low resolution devices (crt and lpr)
.if \n(.H>23 .if \n(.V>19 \
\{\
. ds : e
. ds 8 ss
. ds o a
. ds d- d\h'-1'\(ga
. ds D- D\h'-1'\(hy
. ds th \o'bp'
. ds Th \o'LP'
. ds ae ae
. ds Ae AE
.\}
.rm #[ #] #H #V #F C
.\" ========================================================================
.\"
.IX Title "LLI 1"
.TH LLI 1 "2006-03-13" "CVS" "LLVM Command Guide"
.SH "NAME"
lli \- directly execute programs from LLVM bytecode
.SH "SYNOPSIS"
.IX Header "SYNOPSIS"
\&\fBlli\fR [\fIoptions\fR] [\fIfilename\fR] [\fIprogram args\fR]
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
\&\fBlli\fR directly executes programs in \s-1LLVM\s0 bytecode format. It takes a program
in \s-1LLVM\s0 bytecode format and executes it using a just-in-time compiler, if one is
available for the current architecture, or an interpreter. \fBlli\fR takes all of
the same code generator options as llc, but they are only effective when
\&\fBlli\fR is using the just-in-time compiler.
.PP
If \fIfilename\fR is not specified, then \fBlli\fR reads the \s-1LLVM\s0 bytecode for the
program from standard input.
.PP
The optional \fIargs\fR specified on the command line are passed to the program as
arguments.
.SH "OPTIONS"
.IX Header "OPTIONS"
.IP "\fB\-help\fR" 4
.IX Item "-help"
Print a summary of command line options.
.IP "\fB\-stats\fR" 4
.IX Item "-stats"
Print statistics from the code-generation passes. This is only meaningful for
the just-in-time compiler, at present.
.IP "\fB\-time\-passes\fR" 4
.IX Item "-time-passes"
Record the amount of time needed for each code-generation pass and print it to
standard error.
.IP "\fB\-mtriple\fR=\fItarget triple\fR" 4
.IX Item "-mtriple=target triple"
Override the target triple specified in the input bytecode file with the
specified string. This may result in a crash if you pick an
architecture which is not compatible with the current system.
.IP "\fB\-march\fR=\fIarch\fR" 4
.IX Item "-march=arch"
Specify the architecture for which to generate assembly, overriding the target
encoded in the bytecode file. See the output of \fBllc \-\-help\fR for a list of
valid architectures. By default this is inferred from the target triple or
autodetected to the current architecture.
.IP "\fB\-mcpu\fR=\fIcpuname\fR" 4
.IX Item "-mcpu=cpuname"
Specify a specific chip in the current architecture to generate code for.
By default this is inferred from the target triple and autodetected to
the current architecture. For a list of available CPUs, use:
\&\fBllvm-as < /dev/null | llc \-march=xyz \-mcpu=help\fR
.IP "\fB\-mattr\fR=\fIa1,+a2,\-a3,...\fR" 4
.IX Item "-mattr=a1,+a2,-a3,..."
Override or control specific attributes of the target, such as whether \s-1SIMD\s0
operations are enabled or not. The default set of attributes is set by the
current \s-1CPU\s0. For a list of available attributes, use:
\&\fBllvm-as < /dev/null | llc \-march=xyz \-mattr=help\fR
.IP "\fB\-force\-interpreter\fR=\fI{false,true}\fR" 4
.IX Item "-force-interpreter={false,true}"
If set to true, use the interpreter even if a just-in-time compiler is available
for this architecture. Defaults to false.
.IP "\fB\-f\fR=\fIname\fR" 4
.IX Item "-f=name"
Call the function named \fIname\fR to start the program. Note: The
function is assumed to have the C signature \f(CW\*(C`int\*(C'\fR \fIname\fR \f(CW\*(C`(int,
char **, char **)\*(C'\fR. If you try to use this option to call a function of
incompatible type, undefined behavior may result. Defaults to \f(CW\*(C`main\*(C'\fR.
.SH "EXIT STATUS"
.IX Header "EXIT STATUS"
If \fBlli\fR fails to load the program, it will exit with an exit code of 1.
Otherwise, it will return the exit code of the program it executes.
.SH "SEE ALSO"
.IX Header "SEE ALSO"
llc
.SH "AUTHOR"
.IX Header "AUTHOR"
Maintained by the \s-1LLVM\s0 Team (<http://llvm.org>).

View File

@@ -1,461 +0,0 @@
.\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.14
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sh \" Subsection heading
.br
.if t .Sp
.ne 5
.PP
\fB\\$1\fR
.PP
..
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings. \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote. | will give a
.\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used to
.\" do unbreakable dashes and therefore won't be available. \*(C` and \*(C'
.\" expand to `' in nroff, nothing in troff, for use with C<>.
.tr \(*W-|\(bv\*(Tr
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
. ds -- \(*W-
. ds PI pi
. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
. ds L" ""
. ds R" ""
. ds C` ""
. ds C' ""
'br\}
.el\{\
. ds -- \|\(em\|
. ds PI \(*p
. ds L" ``
. ds R" ''
'br\}
.\"
.\" If the F register is turned on, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
.\" entries marked with X<> in POD. Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.if \nF \{\
. de IX
. tm Index:\\$1\t\\n%\t"\\$2"
..
. nr % 0
. rr F
.\}
.\"
.\" For nroff, turn off justification. Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.hy 0
.if n .na
.\"
.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
.\" Fear. Run. Save yourself. No user-serviceable parts.
. \" fudge factors for nroff and troff
.if n \{\
. ds #H 0
. ds #V .8m
. ds #F .3m
. ds #[ \f1
. ds #] \fP
.\}
.if t \{\
. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
. ds #V .6m
. ds #F 0
. ds #[ \&
. ds #] \&
.\}
. \" simple accents for nroff and troff
.if n \{\
. ds ' \&
. ds ` \&
. ds ^ \&
. ds , \&
. ds ~ ~
. ds /
.\}
.if t \{\
. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
.\}
. \" troff and (daisy-wheel) nroff accents
.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
.ds ae a\h'-(\w'a'u*4/10)'e
.ds Ae A\h'-(\w'A'u*4/10)'E
. \" corrections for vroff
.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
. \" for low resolution devices (crt and lpr)
.if \n(.H>23 .if \n(.V>19 \
\{\
. ds : e
. ds 8 ss
. ds o a
. ds d- d\h'-1'\(ga
. ds D- D\h'-1'\(hy
. ds th \o'bp'
. ds Th \o'LP'
. ds ae ae
. ds Ae AE
.\}
.rm #[ #] #H #V #F C
.\" ========================================================================
.\"
.IX Title "LLVM-AR 1"
.TH LLVM-AR 1 "2006-11-20" "CVS" "LLVM Command Guide"
.SH "NAME"
llvm\-ar \- LLVM archiver
.SH "SYNOPSIS"
.IX Header "SYNOPSIS"
\&\fBllvm-ar\fR [\-]{dmpqrtx}[Rabfikouz] [relpos] [count] <archive> [files...]
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
The \fBllvm-ar\fR command is similar to the common Unix utility, \f(CW\*(C`ar\*(C'\fR. It
archives several files together into a single file. The intent for this is
to produce archive libraries by \s-1LLVM\s0 bytecode that can be linked into an
\&\s-1LLVM\s0 program. However, the archive can contain any kind of file. By default,
\&\fBllvm-ar\fR generates a symbol table that makes linking faster because
only the symbol table needs to be consulted, not each individual file member
of the archive.
.PP
The \fBllvm-ar\fR command can be used to \fIread\fR both \s-1SVR4\s0 and \s-1BSD\s0 style archive
files. However, it cannot be used to write them. While the \fBllvm-ar\fR command
produces files that are \fIalmost\fR identical to the format used by other \f(CW\*(C`ar\*(C'\fR
implementations, it has two significant departures in order to make the
archive appropriate for \s-1LLVM\s0. The first departure is that \fBllvm-ar\fR only
uses \s-1BSD4\s0.4 style long path names (stored immediately after the header) and
never contains a string table for long names. The second departure is that the
symbol table is formated for efficient construction of an in-memory data
structure that permits rapid (red\-black tree) lookups. Consequently, archives
produced with \fBllvm-ar\fR usually won't be readable or editable with any
\&\f(CW\*(C`ar\*(C'\fR implementation or useful for linking. Using the \f(CW\*(C`f\*(C'\fR modifier to flatten
file names will make the archive readable by other \f(CW\*(C`ar\*(C'\fR implementations
but not for linking because the symbol table format for \s-1LLVM\s0 is unique. If an
\&\s-1SVR4\s0 or \s-1BSD\s0 style archive is used with the \f(CW\*(C`r\*(C'\fR (replace) or \f(CW\*(C`q\*(C'\fR (quick
update) operations, the archive will be reconstructed in \s-1LLVM\s0 format. This
means that the string table will be dropped (in deference to \s-1BSD\s0 4.4 long names)
and an \s-1LLVM\s0 symbol table will be added (by default). The system symbol table
will be retained.
.PP
Here's where \fBllvm-ar\fR departs from previous \f(CW\*(C`ar\*(C'\fR implementations:
.IP "\fISymbol Table\fR" 4
.IX Item "Symbol Table"
Since \fBllvm-ar\fR is intended to archive bytecode files, the symbol table
won't make much sense to anything but \s-1LLVM\s0. Consequently, the symbol table's
format has been simplified. It consists simply of a sequence of pairs
of a file member index number as an \s-1LSB\s0 4byte integer and a null-terminated
string.
.IP "\fILong Paths\fR" 4
.IX Item "Long Paths"
Some \f(CW\*(C`ar\*(C'\fR implementations (\s-1SVR4\s0) use a separate file member to record long
path names (> 15 characters). \fBllvm-ar\fR takes the \s-1BSD\s0 4.4 and Mac \s-1OS\s0 X
approach which is to simply store the full path name immediately preceding
the data for the file. The path name is null terminated and may contain the
slash (/) character.
.IP "\fICompression\fR" 4
.IX Item "Compression"
\&\fBllvm-ar\fR can compress the members of an archive to save space. The
compression used depends on what's available on the platform and what choices
the \s-1LLVM\s0 Compressor utility makes. It generally favors bzip2 but will select
between \*(L"no compression\*(R" or bzip2 depending on what makes sense for the
file's content.
.IP "\fIDirectory Recursion\fR" 4
.IX Item "Directory Recursion"
Most \f(CW\*(C`ar\*(C'\fR implementations do not recurse through directories but simply
ignore directories if they are presented to the program in the \fIfiles\fR
option. \fBllvm-ar\fR, however, can recurse through directory structures and
add all the files under a directory, if requested.
.IP "\fI\s-1TOC\s0 Verbose Output\fR" 4
.IX Item "TOC Verbose Output"
When \fBllvm-ar\fR prints out the verbose table of contents (\f(CW\*(C`tv\*(C'\fR option), it
precedes the usual output with a character indicating the basic kind of
content in the file. A blank means the file is a regular file. A 'Z' means
the file is compressed. A 'B' means the file is an \s-1LLVM\s0 bytecode file. An
\&'S' means the file is the symbol table.
.SH "OPTIONS"
.IX Header "OPTIONS"
The options to \fBllvm-ar\fR are compatible with other \f(CW\*(C`ar\*(C'\fR implementations.
However, there are a few modifiers (\fIzR\fR) that are not found in other
\&\f(CW\*(C`ar\*(C'\fRs. The options to \fBllvm-ar\fR specify a single basic operation to
perform on the archive, a variety of modifiers for that operation, the
name of the archive file, and an optional list of file names. These options
are used to determine how \fBllvm-ar\fR should process the archive file.
.PP
The Operations and Modifiers are explained in the sections below. The minimal
set of options is at least one operator and the name of the archive. Typically
archive files end with a \f(CW\*(C`.a\*(C'\fR suffix, but this is not required. Following
the \fIarchive-name\fR comes a list of \fIfiles\fR that indicate the specific members
of the archive to operate on. If the \fIfiles\fR option is not specified, it
generally means either \*(L"none\*(R" or \*(L"all\*(R" members, depending on the operation.
.Sh "Operations"
.IX Subsection "Operations"
.IP "d" 4
.IX Item "d"
Delete files from the archive. No modifiers are applicable to this operation.
The \fIfiles\fR options specify which members should be removed from the
archive. It is not an error if a specified file does not appear in the archive.
If no \fIfiles\fR are specified, the archive is not modified.
.IP "m[abi]" 4
.IX Item "m[abi]"
Move files from one location in the archive to another. The \fIa\fR, \fIb\fR, and
\&\fIi\fR modifiers apply to this operation. The \fIfiles\fR will all be moved
to the location given by the modifiers. If no modifiers are used, the files
will be moved to the end of the archive. If no \fIfiles\fR are specified, the
archive is not modified.
.IP "p[k]" 4
.IX Item "p[k]"
Print files to the standard output. The \fIk\fR modifier applies to this
operation. This operation simply prints the \fIfiles\fR indicated to the
standard output. If no \fIfiles\fR are specified, the entire archive is printed.
Printing bytecode files is ill-advised as they might confuse your terminal
settings. The \fIp\fR operation never modifies the archive.
.IP "q[Rfz]" 4
.IX Item "q[Rfz]"
Quickly append files to the end of the archive. The \fIR\fR, \fIf\fR, and \fIz\fR
modifiers apply to this operation. This operation quickly adds the
\&\fIfiles\fR to the archive without checking for duplicates that should be
removed first. If no \fIfiles\fR are specified, the archive is not modified.
Because of the way that \fBllvm-ar\fR constructs the archive file, its dubious
whether the \fIq\fR operation is any faster than the \fIr\fR operation.
.IP "r[Rabfuz]" 4
.IX Item "r[Rabfuz]"
Replace or insert file members. The \fIR\fR, \fIa\fR, \fIb\fR, \fIf\fR, \fIu\fR, and \fIz\fR
modifiers apply to this operation. This operation will replace existing
\&\fIfiles\fR or insert them at the end of the archive if they do not exist. If no
\&\fIfiles\fR are specified, the archive is not modified.
.IP "t[v]" 4
.IX Item "t[v]"
Print the table of contents. Without any modifiers, this operation just prints
the names of the members to the standard output. With the \fIv\fR modifier,
\&\fBllvm-ar\fR also prints out the file type (B=bytecode, Z=compressed, S=symbol
table, blank=regular file), the permission mode, the owner and group, the
size, and the date. If any \fIfiles\fR are specified, the listing is only for
those files. If no \fIfiles\fR are specified, the table of contents for the
whole archive is printed.
.IP "x[oP]" 4
.IX Item "x[oP]"
Extract archive members back to files. The \fIo\fR modifier applies to this
operation. This operation retrieves the indicated \fIfiles\fR from the archive
and writes them back to the operating system's file system. If no
\&\fIfiles\fR are specified, the entire archive is extract.
.Sh "Modifiers (operation specific)"
.IX Subsection "Modifiers (operation specific)"
The modifiers below are specific to certain operations. See the Operations
section (above) to determine which modifiers are applicable to which operations.
.IP "[a]" 4
.IX Item "[a]"
When inserting or moving member files, this option specifies the destination of
the new files as being \f(CW\*(C`a\*(C'\fRfter the \fIrelpos\fR member. If \fIrelpos\fR is not found,
the files are placed at the end of the archive.
.IP "[b]" 4
.IX Item "[b]"
When inserting or moving member files, this option specifies the destination of
the new files as being \f(CW\*(C`b\*(C'\fRefore the \fIrelpos\fR member. If \fIrelpos\fR is not
found, the files are placed at the end of the archive. This modifier is
identical to the the \fIi\fR modifier.
.IP "[f]" 4
.IX Item "[f]"
Normally, \fBllvm-ar\fR stores the full path name to a file as presented to it on
the command line. With this option, truncated (15 characters max) names are
used. This ensures name compatibility with older versions of \f(CW\*(C`ar\*(C'\fR but may also
thwart correct extraction of the files (duplicates may overwrite). If used with
the \fIR\fR option, the directory recursion will be performed but the file names
will all be \f(CW\*(C`f\*(C'\fRlattened to simple file names.
.IP "[i]" 4
.IX Item "[i]"
A synonym for the \fIb\fR option.
.IP "[k]" 4
.IX Item "[k]"
Normally, \fBllvm-ar\fR will not print the contents of bytecode files when the
\&\fIp\fR operation is used. This modifier defeats the default and allows the
bytecode members to be printed.
.IP "[N]" 4
.IX Item "[N]"
This option is ignored by \fBllvm-ar\fR but provided for compatibility.
.IP "[o]" 4
.IX Item "[o]"
When extracting files, this option will cause \fBllvm-ar\fR to preserve the
original modification times of the files it writes.
.IP "[P]" 4
.IX Item "[P]"
use full path names when matching
.IP "[R]" 4
.IX Item "[R]"
This modifier instructions the \fIr\fR option to recursively process directories.
Without \fIR\fR, directories are ignored and only those \fIfiles\fR that refer to
files will be added to the archive. When \fIR\fR is used, any directories specified
with \fIfiles\fR will be scanned (recursively) to find files to be added to the
archive. Any file whose name begins with a dot will not be added.
.IP "[u]" 4
.IX Item "[u]"
When replacing existing files in the archive, only replace those files that have
a time stamp than the time stamp of the member in the archive.
.IP "[z]" 4
.IX Item "[z]"
When inserting or replacing any file in the archive, compress the file first.
This
modifier is safe to use when (previously) compressed bytecode files are added to
the archive; the compressed bytecode files will not be doubly compressed.
.Sh "Modifiers (generic)"
.IX Subsection "Modifiers (generic)"
The modifiers below may be applied to any operation.
.IP "[c]" 4
.IX Item "[c]"
For all operations, \fBllvm-ar\fR will always create the archive if it doesn't
exist. Normally, \fBllvm-ar\fR will print a warning message indicating that the
archive is being created. Using this modifier turns off that warning.
.IP "[s]" 4
.IX Item "[s]"
This modifier requests that an archive index (or symbol table) be added to the
archive. This is the default mode of operation. The symbol table will contain
all the externally visible functions and global variables defined by all the
bytecode files in the archive. Using this modifier is more efficient that using
llvm-ranlib which also creates the symbol table.
.IP "[S]" 4
.IX Item "[S]"
This modifier is the opposite of the \fIs\fR modifier. It instructs \fBllvm-ar\fR to
not build the symbol table. If both \fIs\fR and \fIS\fR are used, the last modifier to
occur in the options will prevail.
.IP "[v]" 4
.IX Item "[v]"
This modifier instructs \fBllvm-ar\fR to be verbose about what it is doing. Each
editing operation taken against the archive will produce a line of output saying
what is being done.
.SH "STANDARDS"
.IX Header "STANDARDS"
The \fBllvm-ar\fR utility is intended to provide a superset of the \s-1IEEE\s0 Std 1003.2
(\s-1POSIX\s0.2) functionality for \f(CW\*(C`ar\*(C'\fR. \fBllvm-ar\fR can read both \s-1SVR4\s0 and \s-1BSD4\s0.4 (or
Mac \s-1OS\s0 X) archives. If the \f(CW\*(C`f\*(C'\fR modifier is given to the \f(CW\*(C`x\*(C'\fR or \f(CW\*(C`r\*(C'\fR operations
then \fBllvm-ar\fR will write \s-1SVR4\s0 compatible archives. Without this modifier,
\&\fBllvm-ar\fR will write \s-1BSD4\s0.4 compatible archives that have long names
immediately after the header and indicated using the \*(L"#1/ddd\*(R" notation for the
name in the header.
.SH "FILE FORMAT"
.IX Header "FILE FORMAT"
The file format for \s-1LLVM\s0 Archive files is similar to that of \s-1BSD\s0 4.4 or Mac \s-1OSX\s0
archive files. In fact, except for the symbol table, the \f(CW\*(C`ar\*(C'\fR commands on those
operating systems should be able to read \s-1LLVM\s0 archive files. The details of the
file format follow.
.PP
Each archive begins with the archive magic number which is the eight printable
characters \*(L"!<arch>\en\*(R" where \en represents the newline character (0x0A).
Following the magic number, the file is composed of even length members that
begin with an archive header and end with a \en padding character if necessary
(to make the length even). Each file member is composed of a header (defined
below), an optional newline-terminated \*(L"long file name\*(R" and the contents of
the file.
.PP
The fields of the header are described in the items below. All fields of the
header contain only \s-1ASCII\s0 characters, are left justified and are right padded
with space characters.
.IP "name \- char[16]" 4
.IX Item "name - char[16]"
This field of the header provides the name of the archive member. If the name is
longer than 15 characters or contains a slash (/) character, then this field
contains \f(CW\*(C`#1/nnn\*(C'\fR where \f(CW\*(C`nnn\*(C'\fR provides the length of the name and the \f(CW\*(C`#1/\*(C'\fR
is literal. In this case, the actual name of the file is provided in the \f(CW\*(C`nnn\*(C'\fR
bytes immediately following the header. If the name is 15 characters or less, it
is contained directly in this field and terminated with a slash (/) character.
.IP "date \- char[12]" 4
.IX Item "date - char[12]"
This field provides the date of modification of the file in the form of a
decimal encoded number that provides the number of seconds since the epoch
(since 00:00:00 Jan 1, 1970) per Posix specifications.
.IP "uid \- char[6]" 4
.IX Item "uid - char[6]"
This field provides the user id of the file encoded as a decimal \s-1ASCII\s0 string.
This field might not make much sense on non-Unix systems. On Unix, it is the
same value as the st_uid field of the stat structure returned by the \fIstat\fR\|(2)
operating system call.
.IP "gid \- char[6]" 4
.IX Item "gid - char[6]"
This field provides the group id of the file encoded as a decimal \s-1ASCII\s0 string.
This field might not make much sense on non-Unix systems. On Unix, it is the
same value as the st_gid field of the stat structure returned by the \fIstat\fR\|(2)
operating system call.
.IP "mode \- char[8]" 4
.IX Item "mode - char[8]"
This field provides the access mode of the file encoded as an octal \s-1ASCII\s0
string. This field might not make much sense on non-Unix systems. On Unix, it
is the same value as the st_mode field of the stat structure returned by the
\&\fIstat\fR\|(2) operating system call.
.IP "size \- char[10]" 4
.IX Item "size - char[10]"
This field provides the size of the file, in bytes, encoded as a decimal \s-1ASCII\s0
string. If the size field is negative (starts with a minus sign, 0x02D), then
the archive member is stored in compressed form. The first byte of the archive
member's data indicates the compression type used. A value of 0 (0x30) indicates
that no compression was used. A value of 2 (0x32) indicates that bzip2
compression was used.
.IP "fmag \- char[2]" 4
.IX Item "fmag - char[2]"
This field is the archive file member magic number. Its content is always the
two characters back tick (0x60) and newline (0x0A). This provides some measure
utility in identifying archive files that have been corrupted.
.PP
The \s-1LLVM\s0 symbol table has the special name \*(L"#_LLVM_SYM_TAB_#\*(R". It is presumed
that no regular archive member file will want this name. The \s-1LLVM\s0 symbol table
is simply composed of a sequence of triplets: byte offset, length of symbol,
and the symbol itself. Symbols are not null or newline terminated. Here are
the details on each of these items:
.IP "offset \- vbr encoded 32\-bit integer" 4
.IX Item "offset - vbr encoded 32-bit integer"
The offset item provides the offset into the archive file where the bytecode
member is stored that is associated with the symbol. The offset value is 0
based at the start of the first \*(L"normal\*(R" file member. To derive the actual
file offset of the member, you must add the number of bytes occupied by the file
signature (8 bytes) and the symbol tables. The value of this item is encoded
using variable bit rate encoding to reduce the size of the symbol table.
Variable bit rate encoding uses the high bit (0x80) of each byte to indicate
if there are more bytes to follow. The remaining 7 bits in each byte carry bits
from the value. The final byte does not have the high bit set.
.IP "length \- vbr encoded 32\-bit integer" 4
.IX Item "length - vbr encoded 32-bit integer"
The length item provides the length of the symbol that follows. Like this
\&\fIoffset\fR item, the length is variable bit rate encoded.
.IP "symbol \- character array" 4
.IX Item "symbol - character array"
The symbol item provides the text of the symbol that is associated with the
\&\fIoffset\fR. The symbol is not terminated by any character. Its length is provided
by the \fIlength\fR field. Note that is allowed (but unwise) to use non-printing
characters (even 0x00) in the symbol. This allows for multiple encodings of
symbol names.
.SH "EXIT STATUS"
.IX Header "EXIT STATUS"
If \fBllvm-ar\fR succeeds, it will exit with 0. A usage error, results
in an exit code of 1. A hard (file system typically) error results in an
exit code of 2. Miscellaneous or unknown errors result in an
exit code of 3.
.SH "SEE ALSO"
.IX Header "SEE ALSO"
llvm-ranlib, \fIar\fR\|(1)
.SH "AUTHORS"
.IX Header "AUTHORS"
Maintained by the \s-1LLVM\s0 Team (<http://llvm.org>).

View File

@@ -1,182 +0,0 @@
.\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.14
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sh \" Subsection heading
.br
.if t .Sp
.ne 5
.PP
\fB\\$1\fR
.PP
..
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings. \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote. | will give a
.\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used to
.\" do unbreakable dashes and therefore won't be available. \*(C` and \*(C'
.\" expand to `' in nroff, nothing in troff, for use with C<>.
.tr \(*W-|\(bv\*(Tr
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
. ds -- \(*W-
. ds PI pi
. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
. ds L" ""
. ds R" ""
. ds C` ""
. ds C' ""
'br\}
.el\{\
. ds -- \|\(em\|
. ds PI \(*p
. ds L" ``
. ds R" ''
'br\}
.\"
.\" If the F register is turned on, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
.\" entries marked with X<> in POD. Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.if \nF \{\
. de IX
. tm Index:\\$1\t\\n%\t"\\$2"
..
. nr % 0
. rr F
.\}
.\"
.\" For nroff, turn off justification. Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.hy 0
.if n .na
.\"
.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
.\" Fear. Run. Save yourself. No user-serviceable parts.
. \" fudge factors for nroff and troff
.if n \{\
. ds #H 0
. ds #V .8m
. ds #F .3m
. ds #[ \f1
. ds #] \fP
.\}
.if t \{\
. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
. ds #V .6m
. ds #F 0
. ds #[ \&
. ds #] \&
.\}
. \" simple accents for nroff and troff
.if n \{\
. ds ' \&
. ds ` \&
. ds ^ \&
. ds , \&
. ds ~ ~
. ds /
.\}
.if t \{\
. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
.\}
. \" troff and (daisy-wheel) nroff accents
.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
.ds ae a\h'-(\w'a'u*4/10)'e
.ds Ae A\h'-(\w'A'u*4/10)'E
. \" corrections for vroff
.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
. \" for low resolution devices (crt and lpr)
.if \n(.H>23 .if \n(.V>19 \
\{\
. ds : e
. ds 8 ss
. ds o a
. ds d- d\h'-1'\(ga
. ds D- D\h'-1'\(hy
. ds th \o'bp'
. ds Th \o'LP'
. ds ae ae
. ds Ae AE
.\}
.rm #[ #] #H #V #F C
.\" ========================================================================
.\"
.IX Title "LLVM-AS 1"
.TH LLVM-AS 1 "2006-03-13" "CVS" "LLVM Command Guide"
.SH "NAME"
llvm\-as \- LLVM assembler
.SH "SYNOPSIS"
.IX Header "SYNOPSIS"
\&\fBllvm-as\fR [\fIoptions\fR] [\fIfilename\fR]
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
\&\fBllvm-as\fR is the \s-1LLVM\s0 assembler. It reads a file containing human-readable
\&\s-1LLVM\s0 assembly language, translates it to \s-1LLVM\s0 bytecode, and writes the result
into a file or to standard output.
.PP
If \fIfilename\fR is omitted or is \f(CW\*(C`\-\*(C'\fR, then \fBllvm-as\fR reads its input from
standard input.
.PP
If an output file is not specified with the \fB\-o\fR option, then
\&\fBllvm-as\fR sends its output to a file or standard output by following
these rules:
.IP "\(bu" 4
If the input is standard input, then the output is standard output.
.IP "\(bu" 4
If the input is a file that ends with \f(CW\*(C`.ll\*(C'\fR, then the output file is of
the same name, except that the suffix is changed to \f(CW\*(C`.bc\*(C'\fR.
.IP "\(bu" 4
If the input is a file that does not end with the \f(CW\*(C`.ll\*(C'\fR suffix, then the
output file has the same name as the input file, except that the \f(CW\*(C`.bc\*(C'\fR
suffix is appended.
.SH "OPTIONS"
.IX Header "OPTIONS"
.IP "\fB\-f\fR" 4
.IX Item "-f"
Force overwrite. Normally, \fBllvm-as\fR will refuse to overwrite an
output file that already exists. With this option, \fBllvm-as\fR
will overwrite the output file and replace it with new bytecode.
.IP "\fB\-\-help\fR" 4
.IX Item "--help"
Print a summary of command line options.
.IP "\fB\-o\fR \fIfilename\fR" 4
.IX Item "-o filename"
Specify the output file name. If \fIfilename\fR is \f(CW\*(C`\-\*(C'\fR, then \fBllvm-as\fR
sends its output to standard output.
.SH "EXIT STATUS"
.IX Header "EXIT STATUS"
If \fBllvm-as\fR succeeds, it will exit with 0. Otherwise, if an error
occurs, it will exit with a non-zero value.
.SH "SEE ALSO"
.IX Header "SEE ALSO"
llvm-dis, gccas
.SH "AUTHORS"
.IX Header "AUTHORS"
Maintained by the \s-1LLVM\s0 Team (<http://llvm.org>).

View File

@@ -1,370 +0,0 @@
.\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.14
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sh \" Subsection heading
.br
.if t .Sp
.ne 5
.PP
\fB\\$1\fR
.PP
..
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings. \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote. | will give a
.\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used to
.\" do unbreakable dashes and therefore won't be available. \*(C` and \*(C'
.\" expand to `' in nroff, nothing in troff, for use with C<>.
.tr \(*W-|\(bv\*(Tr
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
. ds -- \(*W-
. ds PI pi
. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
. ds L" ""
. ds R" ""
. ds C` ""
. ds C' ""
'br\}
.el\{\
. ds -- \|\(em\|
. ds PI \(*p
. ds L" ``
. ds R" ''
'br\}
.\"
.\" If the F register is turned on, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
.\" entries marked with X<> in POD. Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.if \nF \{\
. de IX
. tm Index:\\$1\t\\n%\t"\\$2"
..
. nr % 0
. rr F
.\}
.\"
.\" For nroff, turn off justification. Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.hy 0
.if n .na
.\"
.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
.\" Fear. Run. Save yourself. No user-serviceable parts.
. \" fudge factors for nroff and troff
.if n \{\
. ds #H 0
. ds #V .8m
. ds #F .3m
. ds #[ \f1
. ds #] \fP
.\}
.if t \{\
. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
. ds #V .6m
. ds #F 0
. ds #[ \&
. ds #] \&
.\}
. \" simple accents for nroff and troff
.if n \{\
. ds ' \&
. ds ` \&
. ds ^ \&
. ds , \&
. ds ~ ~
. ds /
.\}
.if t \{\
. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
.\}
. \" troff and (daisy-wheel) nroff accents
.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
.ds ae a\h'-(\w'a'u*4/10)'e
.ds Ae A\h'-(\w'A'u*4/10)'E
. \" corrections for vroff
.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
. \" for low resolution devices (crt and lpr)
.if \n(.H>23 .if \n(.V>19 \
\{\
. ds : e
. ds 8 ss
. ds o a
. ds d- d\h'-1'\(ga
. ds D- D\h'-1'\(hy
. ds th \o'bp'
. ds Th \o'LP'
. ds ae ae
. ds Ae AE
.\}
.rm #[ #] #H #V #F C
.\" ========================================================================
.\"
.IX Title "LLVM-BCANALYZER 1"
.TH LLVM-BCANALYZER 1 "2006-03-13" "CVS" "LLVM Command Guide"
.SH "NAME"
llvm\-bcanalyzer \- LLVM bytecode analyzer
.SH "SYNOPSIS"
.IX Header "SYNOPSIS"
\&\fBllvm-bcanalyzer\fR [\fIoptions\fR] [\fIfilename\fR]
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
The \fBllvm-bcanalyzer\fR command is a small utility for analyzing bytecode files.
The tool reads a bytecode file (such as generated with the \fBllvm-as\fR tool) and
produces a statistical report on the contents of the byteocde file. The tool
can also dump a low level but human readable version of the bytecode file.
This tool is probably not of much interest or utility except for those working
directly with the bytecode file format. Most \s-1LLVM\s0 users can just ignore
this tool.
.PP
If \fIfilename\fR is omitted or is \f(CW\*(C`\-\*(C'\fR, then \fBllvm-bcanalyzer\fR reads its input
from standard input. This is useful for combining the tool into a pipeline.
Output is written to the standard output.
.SH "OPTIONS"
.IX Header "OPTIONS"
.IP "\fB\-nodetails\fR" 4
.IX Item "-nodetails"
Causes \fBllvm-bcanalyzer\fR to abbreviate its output by writing out only a module
level summary. The details for individual functions are not displayed.
.IP "\fB\-dump\fR" 4
.IX Item "-dump"
Causes \fBllvm-bcanalyzer\fR to dump the bytecode in a human readable format. This
format is significantly different from \s-1LLVM\s0 assembly and provides details about
the encoding of the bytecode file.
.IP "\fB\-verify\fR" 4
.IX Item "-verify"
Causes \fBllvm-bcanalyzer\fR to verify the module produced by reading the
bytecode. This ensures that the statistics generated are based on a consistent
module.
.IP "\fB\-\-help\fR" 4
.IX Item "--help"
Print a summary of command line options.
.SH "EXIT STATUS"
.IX Header "EXIT STATUS"
If \fBllvm-bcanalyzer\fR succeeds, it will exit with 0. Otherwise, if an error
occurs, it will exit with a non-zero value, usually 1.
.SH "SUMMARY OUTPUT DEFINITIONS"
.IX Header "SUMMARY OUTPUT DEFINITIONS"
The following items are always printed by llvm\-bcanalyzer. They comprize the
summary output.
.IP "\fBBytecode Analysis Of Module\fR" 4
.IX Item "Bytecode Analysis Of Module"
This just provides the name of the module for which bytecode analysis is being
generated.
.IP "\fBBytecode Version Number\fR" 4
.IX Item "Bytecode Version Number"
The bytecode version (not \s-1LLVM\s0 version) of the file read by the analyzer.
.IP "\fBFile Size\fR" 4
.IX Item "File Size"
The size, in bytes, of the entire bytecode file.
.IP "\fBModule Bytes\fR" 4
.IX Item "Module Bytes"
The size, in bytes, of the module block. Percentage is relative to File Size.
.IP "\fBFunction Bytes\fR" 4
.IX Item "Function Bytes"
The size, in bytes, of all the function blocks. Percentage is relative to File
Size.
.IP "\fBGlobal Types Bytes\fR" 4
.IX Item "Global Types Bytes"
The size, in bytes, of the Global Types Pool. Percentage is relative to File
Size. This is the size of the definitions of all types in the bytecode file.
.IP "\fBConstant Pool Bytes\fR" 4
.IX Item "Constant Pool Bytes"
The size, in bytes, of the Constant Pool Blocks Percentage is relative to File
Size.
.IP "\fBModule Globals Bytes\fR" 4
.IX Item "Module Globals Bytes"
Ths size, in bytes, of the Global Variable Definitions and their initializers.
Percentage is relative to File Size.
.IP "\fBInstruction List Bytes\fR" 4
.IX Item "Instruction List Bytes"
The size, in bytes, of all the instruction lists in all the functions.
Percentage is relative to File Size. Note that this value is also included in
the Function Bytes.
.IP "\fBCompaction Table Bytes\fR" 4
.IX Item "Compaction Table Bytes"
The size, in bytes, of all the compaction tables in all the functions.
Percentage is relative to File Size. Note that this value is also included in
the Function Bytes.
.IP "\fBSymbol Table Bytes\fR" 4
.IX Item "Symbol Table Bytes"
The size, in bytes, of all the symbol tables in all the functions. Percentage is
relative to File Size. Note that this value is also included in the Function
Bytes.
.IP "\fBDependent Libraries Bytes\fR" 4
.IX Item "Dependent Libraries Bytes"
The size, in bytes, of the list of dependent libraries in the module. Percentage
is relative to File Size. Note that this value is also included in the Module
Global Bytes.
.IP "\fBNumber Of Bytecode Blocks\fR" 4
.IX Item "Number Of Bytecode Blocks"
The total number of blocks of any kind in the bytecode file.
.IP "\fBNumber Of Functions\fR" 4
.IX Item "Number Of Functions"
The total number of function definitions in the bytecode file.
.IP "\fBNumber Of Types\fR" 4
.IX Item "Number Of Types"
The total number of types defined in the Global Types Pool.
.IP "\fBNumber Of Constants\fR" 4
.IX Item "Number Of Constants"
The total number of constants (of any type) defined in the Constant Pool.
.IP "\fBNumber Of Basic Blocks\fR" 4
.IX Item "Number Of Basic Blocks"
The total number of basic blocks defined in all functions in the bytecode file.
.IP "\fBNumber Of Instructions\fR" 4
.IX Item "Number Of Instructions"
The total number of instructions defined in all functions in the bytecode file.
.IP "\fBNumber Of Long Instructions\fR" 4
.IX Item "Number Of Long Instructions"
The total number of long instructions defined in all functions in the bytecode
file. Long instructions are those taking greater than 4 bytes. Typically long
instructions are GetElementPtr with several indices, \s-1PHI\s0 nodes, and calls to
functions with large numbers of arguments.
.IP "\fBNumber Of Operands\fR" 4
.IX Item "Number Of Operands"
The total number of operands used in all instructions in the bytecode file.
.IP "\fBNumber Of Compaction Tables\fR" 4
.IX Item "Number Of Compaction Tables"
The total number of compaction tables in all functions in the bytecode file.
.IP "\fBNumber Of Symbol Tables\fR" 4
.IX Item "Number Of Symbol Tables"
The total number of symbol tables in all functions in the bytecode file.
.IP "\fBNumber Of Dependent Libs\fR" 4
.IX Item "Number Of Dependent Libs"
The total number of dependent libraries found in the bytecode file.
.IP "\fBTotal Instruction Size\fR" 4
.IX Item "Total Instruction Size"
The total size of the instructions in all functions in the bytecode file.
.IP "\fBAverage Instruction Size\fR" 4
.IX Item "Average Instruction Size"
The average number of bytes per instruction across all functions in the bytecode
file. This value is computed by dividing Total Instruction Size by Number Of
Instructions.
.IP "\fBMaximum Type Slot Number\fR" 4
.IX Item "Maximum Type Slot Number"
The maximum value used for a type's slot number. Larger slot number values take
more bytes to encode.
.IP "\fBMaximum Value Slot Number\fR" 4
.IX Item "Maximum Value Slot Number"
The maximum value used for a value's slot number. Larger slot number values take
more bytes to encode.
.IP "\fBBytes Per Value\fR" 4
.IX Item "Bytes Per Value"
The average size of a Value definition (of any type). This is computed by
dividing File Size by the total number of values of any type.
.IP "\fBBytes Per Global\fR" 4
.IX Item "Bytes Per Global"
The average size of a global definition (constants and global variables).
.IP "\fBBytes Per Function\fR" 4
.IX Item "Bytes Per Function"
The average number of bytes per function definition. This is computed by
dividing Function Bytes by Number Of Functions.
.IP "\fB# of \s-1VBR\s0 32\-bit Integers\fR" 4
.IX Item "# of VBR 32-bit Integers"
The total number of 32\-bit integers encoded using the Variable Bit Rate
encoding scheme.
.IP "\fB# of \s-1VBR\s0 64\-bit Integers\fR" 4
.IX Item "# of VBR 64-bit Integers"
The total number of 64\-bit integers encoded using the Variable Bit Rate encoding
scheme.
.IP "\fB# of \s-1VBR\s0 Compressed Bytes\fR" 4
.IX Item "# of VBR Compressed Bytes"
The total number of bytes consumed by the 32\-bit and 64\-bit integers that use
the Variable Bit Rate encoding scheme.
.IP "\fB# of \s-1VBR\s0 Expanded Bytes\fR" 4
.IX Item "# of VBR Expanded Bytes"
The total number of bytes that would have been consumed by the 32\-bit and 64\-bit
integers had they not been compressed with the Variable Bit Rage encoding
scheme.
.IP "\fBBytes Saved With \s-1VBR\s0\fR" 4
.IX Item "Bytes Saved With VBR"
The total number of bytes saved by using the Variable Bit Rate encoding scheme.
The percentage is relative to # of \s-1VBR\s0 Expanded Bytes.
.SH "DETAILED OUTPUT DEFINITIONS"
.IX Header "DETAILED OUTPUT DEFINITIONS"
The following definitions occur only if the \-nodetails option was not given.
The detailed output provides additional information on a per-function basis.
.IP "\fBType\fR" 4
.IX Item "Type"
The type signature of the function.
.IP "\fBByte Size\fR" 4
.IX Item "Byte Size"
The total number of bytes in the function's block.
.IP "\fBBasic Blocks\fR" 4
.IX Item "Basic Blocks"
The number of basic blocks defined by the function.
.IP "\fBInstructions\fR" 4
.IX Item "Instructions"
The number of instructions defined by the function.
.IP "\fBLong Instructions\fR" 4
.IX Item "Long Instructions"
The number of instructions using the long instruction format in the function.
.IP "\fBOperands\fR" 4
.IX Item "Operands"
The number of operands used by all instructions in the function.
.IP "\fBInstruction Size\fR" 4
.IX Item "Instruction Size"
The number of bytes consumed by instructions in the function.
.IP "\fBAverage Instruction Size\fR" 4
.IX Item "Average Instruction Size"
The average number of bytes consumed by the instructions in the funtion. This
value is computed by dividing Instruction Size by Instructions.
.IP "\fBBytes Per Instruction\fR" 4
.IX Item "Bytes Per Instruction"
The average number of bytes used by the function per instruction. This value is
computed by dividing Byte Size by Instructions. Note that this is not the same
as Average Instruction Size. It computes a number relative to the total function
size not just the size of the instruction list.
.IP "\fBNumber of \s-1VBR\s0 32\-bit Integers\fR" 4
.IX Item "Number of VBR 32-bit Integers"
The total number of 32\-bit integers found in this function (for any use).
.IP "\fBNumber of \s-1VBR\s0 64\-bit Integers\fR" 4
.IX Item "Number of VBR 64-bit Integers"
The total number of 64\-bit integers found in this function (for any use).
.IP "\fBNumber of \s-1VBR\s0 Compressed Bytes\fR" 4
.IX Item "Number of VBR Compressed Bytes"
The total number of bytes in this function consumed by the 32\-bit and 64\-bit
integers that use the Variable Bit Rate encoding scheme.
.IP "\fBNumber of \s-1VBR\s0 Expanded Bytes\fR" 4
.IX Item "Number of VBR Expanded Bytes"
The total number of bytes in this function that would have been consumed by
the 32\-bit and 64\-bit integers had they not been compressed with the Variable
Bit Rate encoding scheme.
.IP "\fBBytes Saved With \s-1VBR\s0\fR" 4
.IX Item "Bytes Saved With VBR"
The total number of bytes saved in this function by using the Variable Bit
Rate encoding scheme. The percentage is relative to # of \s-1VBR\s0 Expanded Bytes.
.SH "SEE ALSO"
.IX Header "SEE ALSO"
llvm-dis, <http://llvm.org/docs/BytecodeFormat.html>
.SH "AUTHORS"
.IX Header "AUTHORS"
Maintained by the \s-1LLVM\s0 Team (<http://llvm.org>).

View File

@@ -1,227 +0,0 @@
.\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.14
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sh \" Subsection heading
.br
.if t .Sp
.ne 5
.PP
\fB\\$1\fR
.PP
..
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings. \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote. | will give a
.\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used to
.\" do unbreakable dashes and therefore won't be available. \*(C` and \*(C'
.\" expand to `' in nroff, nothing in troff, for use with C<>.
.tr \(*W-|\(bv\*(Tr
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
. ds -- \(*W-
. ds PI pi
. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
. ds L" ""
. ds R" ""
. ds C` ""
. ds C' ""
'br\}
.el\{\
. ds -- \|\(em\|
. ds PI \(*p
. ds L" ``
. ds R" ''
'br\}
.\"
.\" If the F register is turned on, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
.\" entries marked with X<> in POD. Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.if \nF \{\
. de IX
. tm Index:\\$1\t\\n%\t"\\$2"
..
. nr % 0
. rr F
.\}
.\"
.\" For nroff, turn off justification. Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.hy 0
.if n .na
.\"
.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
.\" Fear. Run. Save yourself. No user-serviceable parts.
. \" fudge factors for nroff and troff
.if n \{\
. ds #H 0
. ds #V .8m
. ds #F .3m
. ds #[ \f1
. ds #] \fP
.\}
.if t \{\
. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
. ds #V .6m
. ds #F 0
. ds #[ \&
. ds #] \&
.\}
. \" simple accents for nroff and troff
.if n \{\
. ds ' \&
. ds ` \&
. ds ^ \&
. ds , \&
. ds ~ ~
. ds /
.\}
.if t \{\
. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
.\}
. \" troff and (daisy-wheel) nroff accents
.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
.ds ae a\h'-(\w'a'u*4/10)'e
.ds Ae A\h'-(\w'A'u*4/10)'E
. \" corrections for vroff
.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
. \" for low resolution devices (crt and lpr)
.if \n(.H>23 .if \n(.V>19 \
\{\
. ds : e
. ds 8 ss
. ds o a
. ds d- d\h'-1'\(ga
. ds D- D\h'-1'\(hy
. ds th \o'bp'
. ds Th \o'LP'
. ds ae ae
. ds Ae AE
.\}
.rm #[ #] #H #V #F C
.\" ========================================================================
.\"
.IX Title "LLVM-CONFIG 1"
.TH LLVM-CONFIG 1 "2006-08-01" "CVS" "LLVM Command Guide"
.SH "NAME"
llvm\-config \- Print LLVM compilation options
.SH "SYNOPSIS"
.IX Header "SYNOPSIS"
\&\fBllvm-config\fR \fIoption\fR [\fIcomponents\fR...]
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
\&\fBllvm-config\fR makes it easier to build applications that use \s-1LLVM\s0. It can
print the compiler flags, linker flags and object libraries needed to link
against \s-1LLVM\s0.
.SH "EXAMPLES"
.IX Header "EXAMPLES"
To link against the \s-1JIT:\s0
.PP
.Vb 3
\& g++ `llvm-config --cxxflags` -o HowToUseJIT.o -c HowToUseJIT.cpp
\& g++ `llvm-config --ldflags` -o HowToUseJIT HowToUseJIT.o \e
\& `llvm-config --libs engine bcreader scalaropts`
.Ve
.SH "OPTIONS"
.IX Header "OPTIONS"
.IP "\fB\-\-version\fR" 4
.IX Item "--version"
Print the version number of \s-1LLVM\s0.
.IP "\fB\-\-help\fR" 4
.IX Item "--help"
Print a summary of \fBllvm-config\fR arguments.
.IP "\fB\-\-prefix\fR" 4
.IX Item "--prefix"
Print the installation prefix for \s-1LLVM\s0.
.IP "\fB\-\-src\-root\fR" 4
.IX Item "--src-root"
Print the source root from which \s-1LLVM\s0 was built.
.IP "\fB\-\-obj\-root\fR" 4
.IX Item "--obj-root"
Print the object root used to build \s-1LLVM\s0.
.IP "\fB\-\-bindir\fR" 4
.IX Item "--bindir"
Print the installation directory for \s-1LLVM\s0 binaries.
.IP "\fB\-\-includedir\fR" 4
.IX Item "--includedir"
Print the installation directory for \s-1LLVM\s0 headers.
.IP "\fB\-\-libdir\fR" 4
.IX Item "--libdir"
Print the installation directory for \s-1LLVM\s0 libraries.
.IP "\fB\-\-cxxflags\fR" 4
.IX Item "--cxxflags"
Print the \*(C+ compiler flags needed to use \s-1LLVM\s0 headers.
.IP "\fB\-\-ldflags\fR" 4
.IX Item "--ldflags"
Print the flags needed to link against \s-1LLVM\s0 libraries.
.IP "\fB\-\-libs\fR" 4
.IX Item "--libs"
Print all the libraries needed to link against the specified \s-1LLVM\s0
\&\fIcomponents\fR, including any dependencies.
.IP "\fB\-\-libnames\fR" 4
.IX Item "--libnames"
Similar to \fB\-\-libs\fR, but prints the bare filenames of the libraries
without \fB\-l\fR or pathnames. Useful for linking against a not-yet-installed
copy of \s-1LLVM\s0.
.IP "\fB\-\-libfiles\fR" 4
.IX Item "--libfiles"
Similar to \fB\-\-libs\fR, but print the full path to each library file. This is
useful when creating makefile dependencies, to ensure that a tool is relinked if
any library it uses changes.
.IP "\fB\-\-components\fR" 4
.IX Item "--components"
Print all valid component names.
.IP "\fB\-\-targets\-built\fR" 4
.IX Item "--targets-built"
Print the component names for all targets supported by this copy of \s-1LLVM\s0.
.IP "\fB\-\-build\-mode\fR" 4
.IX Item "--build-mode"
Print the build mode used when \s-1LLVM\s0 was built (e.g. Debug or Release)
.SH "COMPONENTS"
.IX Header "COMPONENTS"
To print a list of all available components, run \fBllvm-config
\&\-\-components\fR. In most cases, components correspond directly to \s-1LLVM\s0
libraries. Useful \*(L"virtual\*(R" components include:
.IP "\fBall\fR" 4
.IX Item "all"
Includes all \s-1LLVM\s0 libaries. The default if no components are specified.
.IP "\fBbackend\fR" 4
.IX Item "backend"
Includes either a native backend or the C backend.
.IP "\fBengine\fR" 4
.IX Item "engine"
Includes either a native \s-1JIT\s0 or the bytecode interpreter.
.SH "EXIT STATUS"
.IX Header "EXIT STATUS"
If \fBllvm-config\fR succeeds, it will exit with 0. Otherwise, if an error
occurs, it will exit with a non-zero value.
.SH "AUTHORS"
.IX Header "AUTHORS"
Maintained by the \s-1LLVM\s0 Team (<http://llvm.org>).

View File

@@ -1,141 +0,0 @@
.\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.14
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sh \" Subsection heading
.br
.if t .Sp
.ne 5
.PP
\fB\\$1\fR
.PP
..
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings. \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote. | will give a
.\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used to
.\" do unbreakable dashes and therefore won't be available. \*(C` and \*(C'
.\" expand to `' in nroff, nothing in troff, for use with C<>.
.tr \(*W-|\(bv\*(Tr
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
. ds -- \(*W-
. ds PI pi
. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
. ds L" ""
. ds R" ""
. ds C` ""
. ds C' ""
'br\}
.el\{\
. ds -- \|\(em\|
. ds PI \(*p
. ds L" ``
. ds R" ''
'br\}
.\"
.\" If the F register is turned on, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
.\" entries marked with X<> in POD. Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.if \nF \{\
. de IX
. tm Index:\\$1\t\\n%\t"\\$2"
..
. nr % 0
. rr F
.\}
.\"
.\" For nroff, turn off justification. Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.hy 0
.if n .na
.\"
.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
.\" Fear. Run. Save yourself. No user-serviceable parts.
. \" fudge factors for nroff and troff
.if n \{\
. ds #H 0
. ds #V .8m
. ds #F .3m
. ds #[ \f1
. ds #] \fP
.\}
.if t \{\
. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
. ds #V .6m
. ds #F 0
. ds #[ \&
. ds #] \&
.\}
. \" simple accents for nroff and troff
.if n \{\
. ds ' \&
. ds ` \&
. ds ^ \&
. ds , \&
. ds ~ ~
. ds /
.\}
.if t \{\
. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
.\}
. \" troff and (daisy-wheel) nroff accents
.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
.ds ae a\h'-(\w'a'u*4/10)'e
.ds Ae A\h'-(\w'A'u*4/10)'E
. \" corrections for vroff
.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
. \" for low resolution devices (crt and lpr)
.if \n(.H>23 .if \n(.V>19 \
\{\
. ds : e
. ds 8 ss
. ds o a
. ds d- d\h'-1'\(ga
. ds D- D\h'-1'\(hy
. ds th \o'bp'
. ds Th \o'LP'
. ds ae ae
. ds Ae AE
.\}
.rm #[ #] #H #V #F C
.\" ========================================================================
.\"
.IX Title "LLVM-DB 1"
.TH LLVM-DB 1 "2006-03-13" "CVS" "LLVM Command Guide"
.SH "NAME"
llvm\-db \- LLVM debugger (alpha)
.SH "SYNOPSIS"
.IX Header "SYNOPSIS"
Details coming soon. Please see
<http://llvm.org/docs/SourceLevelDebugging.html> in the meantime.
.SH "AUTHORS"
.IX Header "AUTHORS"
Maintained by the \s-1LLVM\s0 Team (<http://llvm.org>).

View File

@@ -1,175 +0,0 @@
.\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.14
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sh \" Subsection heading
.br
.if t .Sp
.ne 5
.PP
\fB\\$1\fR
.PP
..
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings. \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote. | will give a
.\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used to
.\" do unbreakable dashes and therefore won't be available. \*(C` and \*(C'
.\" expand to `' in nroff, nothing in troff, for use with C<>.
.tr \(*W-|\(bv\*(Tr
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
. ds -- \(*W-
. ds PI pi
. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
. ds L" ""
. ds R" ""
. ds C` ""
. ds C' ""
'br\}
.el\{\
. ds -- \|\(em\|
. ds PI \(*p
. ds L" ``
. ds R" ''
'br\}
.\"
.\" If the F register is turned on, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
.\" entries marked with X<> in POD. Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.if \nF \{\
. de IX
. tm Index:\\$1\t\\n%\t"\\$2"
..
. nr % 0
. rr F
.\}
.\"
.\" For nroff, turn off justification. Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.hy 0
.if n .na
.\"
.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
.\" Fear. Run. Save yourself. No user-serviceable parts.
. \" fudge factors for nroff and troff
.if n \{\
. ds #H 0
. ds #V .8m
. ds #F .3m
. ds #[ \f1
. ds #] \fP
.\}
.if t \{\
. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
. ds #V .6m
. ds #F 0
. ds #[ \&
. ds #] \&
.\}
. \" simple accents for nroff and troff
.if n \{\
. ds ' \&
. ds ` \&
. ds ^ \&
. ds , \&
. ds ~ ~
. ds /
.\}
.if t \{\
. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
.\}
. \" troff and (daisy-wheel) nroff accents
.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
.ds ae a\h'-(\w'a'u*4/10)'e
.ds Ae A\h'-(\w'A'u*4/10)'E
. \" corrections for vroff
.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
. \" for low resolution devices (crt and lpr)
.if \n(.H>23 .if \n(.V>19 \
\{\
. ds : e
. ds 8 ss
. ds o a
. ds d- d\h'-1'\(ga
. ds D- D\h'-1'\(hy
. ds th \o'bp'
. ds Th \o'LP'
. ds ae ae
. ds Ae AE
.\}
.rm #[ #] #H #V #F C
.\" ========================================================================
.\"
.IX Title "LLVM-DIS 1"
.TH LLVM-DIS 1 "2006-03-13" "CVS" "LLVM Command Guide"
.SH "NAME"
llvm\-dis \- LLVM disassembler
.SH "SYNOPSIS"
.IX Header "SYNOPSIS"
\&\fBllvm-dis\fR [\fIoptions\fR] [\fIfilename\fR]
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
The \fBllvm-dis\fR command is the \s-1LLVM\s0 disassembler. It takes an \s-1LLVM\s0
bytecode file and converts it into human-readable \s-1LLVM\s0 assembly language.
.PP
If filename is omitted or specified as \f(CW\*(C`\-\*(C'\fR, \fBllvm-dis\fR reads its
input from standard input.
.PP
If the input is being read from standard input, then \fBllvm-dis\fR
will send its output to standard output by default. Otherwise, the
output will be written to a file named after the input file, with
a \f(CW\*(C`.ll\*(C'\fR suffix added (any existing \f(CW\*(C`.bc\*(C'\fR suffix will first be
removed). You can override the choice of output file using the
\&\fB\-o\fR option.
.SH "OPTIONS"
.IX Header "OPTIONS"
.IP "\fB\-f\fR" 4
.IX Item "-f"
Force overwrite. Normally, \fBllvm-dis\fR will refuse to overwrite
an output file that already exists. With this option, \fBllvm-dis\fR
will overwrite the output file.
.IP "\fB\-\-help\fR" 4
.IX Item "--help"
Print a summary of command line options.
.IP "\fB\-o\fR \fIfilename\fR" 4
.IX Item "-o filename"
Specify the output file name. If \fIfilename\fR is \-, then the output is sent
to standard output.
.SH "EXIT STATUS"
.IX Header "EXIT STATUS"
If \fBllvm-dis\fR succeeds, it will exit with 0. Otherwise, if an error
occurs, it will exit with a non-zero value.
.SH "SEE ALSO"
.IX Header "SEE ALSO"
llvm-as
.SH "AUTHORS"
.IX Header "AUTHORS"
Maintained by the \s-1LLVM\s0 Team (<http://llvm.org>).

View File

@@ -1,177 +0,0 @@
.\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.14
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sh \" Subsection heading
.br
.if t .Sp
.ne 5
.PP
\fB\\$1\fR
.PP
..
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings. \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote. | will give a
.\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used to
.\" do unbreakable dashes and therefore won't be available. \*(C` and \*(C'
.\" expand to `' in nroff, nothing in troff, for use with C<>.
.tr \(*W-|\(bv\*(Tr
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
. ds -- \(*W-
. ds PI pi
. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
. ds L" ""
. ds R" ""
. ds C` ""
. ds C' ""
'br\}
.el\{\
. ds -- \|\(em\|
. ds PI \(*p
. ds L" ``
. ds R" ''
'br\}
.\"
.\" If the F register is turned on, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
.\" entries marked with X<> in POD. Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.if \nF \{\
. de IX
. tm Index:\\$1\t\\n%\t"\\$2"
..
. nr % 0
. rr F
.\}
.\"
.\" For nroff, turn off justification. Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.hy 0
.if n .na
.\"
.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
.\" Fear. Run. Save yourself. No user-serviceable parts.
. \" fudge factors for nroff and troff
.if n \{\
. ds #H 0
. ds #V .8m
. ds #F .3m
. ds #[ \f1
. ds #] \fP
.\}
.if t \{\
. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
. ds #V .6m
. ds #F 0
. ds #[ \&
. ds #] \&
.\}
. \" simple accents for nroff and troff
.if n \{\
. ds ' \&
. ds ` \&
. ds ^ \&
. ds , \&
. ds ~ ~
. ds /
.\}
.if t \{\
. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
.\}
. \" troff and (daisy-wheel) nroff accents
.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
.ds ae a\h'-(\w'a'u*4/10)'e
.ds Ae A\h'-(\w'A'u*4/10)'E
. \" corrections for vroff
.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
. \" for low resolution devices (crt and lpr)
.if \n(.H>23 .if \n(.V>19 \
\{\
. ds : e
. ds 8 ss
. ds o a
. ds d- d\h'-1'\(ga
. ds D- D\h'-1'\(hy
. ds th \o'bp'
. ds Th \o'LP'
. ds ae ae
. ds Ae AE
.\}
.rm #[ #] #H #V #F C
.\" ========================================================================
.\"
.IX Title "LLVM-EXTRACT 1"
.TH LLVM-EXTRACT 1 "2006-03-13" "CVS" "LLVM Command Guide"
.SH "NAME"
llvm\-extract \- extract a function from an LLVM module
.SH "SYNOPSIS"
.IX Header "SYNOPSIS"
\&\fBllvm-extract\fR [\fIoptions\fR] \fB\-\-func\fR \fIfunction-name\fR [\fIfilename\fR]
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
The \fBllvm-extract\fR command takes the name of a function and extracts it from
the specified \s-1LLVM\s0 bytecode file. It is primarily used as a debugging tool to
reduce test cases from larger programs that are triggering a bug.
.PP
In addition to extracting the bytecode of the specified function,
\&\fBllvm-extract\fR will also remove unreachable global variables, prototypes, and
unused types.
.PP
The \fBllvm-extract\fR command reads its input from standard input if filename is
omitted or if filename is \-. The output is always written to standard output,
unless the \fB\-o\fR option is specified (see below).
.SH "OPTIONS"
.IX Header "OPTIONS"
.IP "\fB\-f\fR" 4
.IX Item "-f"
Force overwrite. Normally, \fBllvm-extract\fR will refuse to overwrite an
output file that already exists. With this option, \fBllvm-extract\fR
will overwrite the output file and replace it with new bytecode.
.IP "\fB\-\-func\fR \fIfunction-name\fR" 4
.IX Item "--func function-name"
Extract the function named \fIfunction-name\fR from the \s-1LLVM\s0 bytecode.
.IP "\fB\-\-help\fR" 4
.IX Item "--help"
Print a summary of command line options.
.IP "\fB\-o\fR \fIfilename\fR" 4
.IX Item "-o filename"
Specify the output filename. If filename is \*(L"\-\*(R" (the default), then
\&\fBllvm-extract\fR sends its output to standard output.
.SH "EXIT STATUS"
.IX Header "EXIT STATUS"
If \fBllvm-extract\fR succeeds, it will exit with 0. Otherwise, if an error
occurs, it will exit with a non-zero value.
.SH "SEE ALSO"
.IX Header "SEE ALSO"
bugpoint
.SH "AUTHORS"
.IX Header "AUTHORS"
Maintained by the \s-1LLVM\s0 Team (<http://llvm.org>).

View File

@@ -1,348 +0,0 @@
.\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.14
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sh \" Subsection heading
.br
.if t .Sp
.ne 5
.PP
\fB\\$1\fR
.PP
..
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings. \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote. | will give a
.\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used to
.\" do unbreakable dashes and therefore won't be available. \*(C` and \*(C'
.\" expand to `' in nroff, nothing in troff, for use with C<>.
.tr \(*W-|\(bv\*(Tr
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
. ds -- \(*W-
. ds PI pi
. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
. ds L" ""
. ds R" ""
. ds C` ""
. ds C' ""
'br\}
.el\{\
. ds -- \|\(em\|
. ds PI \(*p
. ds L" ``
. ds R" ''
'br\}
.\"
.\" If the F register is turned on, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
.\" entries marked with X<> in POD. Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.if \nF \{\
. de IX
. tm Index:\\$1\t\\n%\t"\\$2"
..
. nr % 0
. rr F
.\}
.\"
.\" For nroff, turn off justification. Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.hy 0
.if n .na
.\"
.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
.\" Fear. Run. Save yourself. No user-serviceable parts.
. \" fudge factors for nroff and troff
.if n \{\
. ds #H 0
. ds #V .8m
. ds #F .3m
. ds #[ \f1
. ds #] \fP
.\}
.if t \{\
. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
. ds #V .6m
. ds #F 0
. ds #[ \&
. ds #] \&
.\}
. \" simple accents for nroff and troff
.if n \{\
. ds ' \&
. ds ` \&
. ds ^ \&
. ds , \&
. ds ~ ~
. ds /
.\}
.if t \{\
. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
.\}
. \" troff and (daisy-wheel) nroff accents
.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
.ds ae a\h'-(\w'a'u*4/10)'e
.ds Ae A\h'-(\w'A'u*4/10)'E
. \" corrections for vroff
.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
. \" for low resolution devices (crt and lpr)
.if \n(.H>23 .if \n(.V>19 \
\{\
. ds : e
. ds 8 ss
. ds o a
. ds d- d\h'-1'\(ga
. ds D- D\h'-1'\(hy
. ds th \o'bp'
. ds Th \o'LP'
. ds ae ae
. ds Ae AE
.\}
.rm #[ #] #H #V #F C
.\" ========================================================================
.\"
.IX Title "LLVM-LD 1"
.TH LLVM-LD 1 "2007-05-06" "CVS" "LLVM Command Guide"
.SH "NAME"
llvm\-ld \- LLVM linker
.SH "SYNOPSIS"
.IX Header "SYNOPSIS"
\&\fBllvm-ld\fR <options> <files>
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
The \fBllvm-ld\fR tool takes a set of \s-1LLVM\s0 bytecode files and links them
together into a single \s-1LLVM\s0 bytecode file. The output bytecode file can be
another bytecode file or an executable bytecode program. Using additional
options, \fBllvm-ld\fR is able to produce native code executables.
.PP
The \fBllvm-ld\fR tool is the main linker for \s-1LLVM\s0. It is used to link together
the output of \s-1LLVM\s0 front-end compilers and run \*(L"link time\*(R" optimizations (mostly
the inter-procedural kind).
.PP
The \fBllvm-ld\fR tools attemps to mimic the interface provided by the default
system linker so that it can act as a \fIdrop-in\fR replacement.
.Sh "Search Order"
.IX Subsection "Search Order"
When looking for objects specified on the command line, \fBllvm-ld\fR will search
for the object first in the current directory and then in the directory
specified by the \fB\s-1LLVM_LIB_SEARCH_PATH\s0\fR environment variable. If it cannot
find the object, it fails.
.PP
When looking for a library specified with the \fB\-l\fR option, \fBllvm-ld\fR first
attempts to load a file with that name from the current directory. If that
fails, it looks for lib\fIlibrary\fR.bc, lib\fIlibrary\fR.a, or lib\fIlibrary\fR.\fIshared
library extension\fR, in that order, in each directory added to the library search
path with the \fB\-L\fR option. These directories are searched in the order they
are specified. If the library cannot be located, then \fBllvm-ld\fR looks in the
directory specified by the \fB\s-1LLVM_LIB_SEARCH_PATH\s0\fR environment variable. If it
does not find a library there, it fails.
.PP
The \fIshared library extension\fR may be \fI.so\fR, \fI.dyld\fR, \fI.dll\fR, or something
different, depending upon the system.
.PP
The \fB\-L\fR option is global. It does not matter where it is specified in the
list of command line arguments; the directory is simply added to the search path
and is applied to all libraries, preceding or succeeding, in the command line.
.Sh "Link order"
.IX Subsection "Link order"
All object and bytecode files are linked first in the order they were
specified on the command line. All library files are linked next.
Some libraries may not be linked into the object program; see below.
.Sh "Library Linkage"
.IX Subsection "Library Linkage"
Object files and static bytecode objects are always linked into the output
file. Library archives (.a files) load only the objects within the archive
that define symbols needed by the output file. Hence, libraries should be
listed after the object files and libraries which need them; otherwise, the
library may not be linked in, and the dependent library will not have its
undefined symbols defined.
.Sh "Native code generation"
.IX Subsection "Native code generation"
The \fBllvm-ld\fR program has limited support for native code generation, when
using the \fB\-native\fR or \fB\-native\-cbe\fR options. Native code generation is
perfomed by converting the linked bytecode into native assembly (.s) or C code
and running the system compiler (typically gcc) on the result.
.SH "OPTIONS"
.IX Header "OPTIONS"
.Sh "General Options"
.IX Subsection "General Options"
.IP "\fB\-help\fR" 4
.IX Item "-help"
Print a summary of command line options.
.IP "\fB\-v\fR" 4
.IX Item "-v"
Specifies verbose mode. In this mode the linker will print additional
information about the actions it takes, programs it executes, etc.
.IP "\fB\-stats\fR" 4
.IX Item "-stats"
Print statistics.
.IP "\fB\-time\-passes\fR" 4
.IX Item "-time-passes"
Record the amount of time needed for each pass and print it to standard
error.
.Sh "Input/Output Options"
.IX Subsection "Input/Output Options"
.IP "\fB\-o\fR \fIfilename\fR" 4
.IX Item "-o filename"
This overrides the default output file and specifies the name of the file that
should be generated by the linker. By default, \fBllvm-ld\fR generates a file named
\&\fIa.out\fR for compatibility with \fBld\fR. The output will be written to
\&\fIfilename\fR.
.IP "\fB\-l\fR\fIname\fR" 4
.IX Item "-lname"
This option specifies the \fIname\fR of a library to search when resolving symbols
for the program. Only the base name should be specified as \fIname\fR, without a
\&\fIlib\fR prefix or any suffix.
.IP "\fB\-L\fR\fIPath\fR" 4
.IX Item "-LPath"
This option tells \fBllvm-ld\fR to look in \fIPath\fR to find any library subsequently
specified with the \fB\-l\fR option. The paths will be searched in the order in
which they are specified on the command line. If the library is still not found,
a small set of system specific directories will also be searched. Note that
libraries specified with the \fB\-l\fR option that occur \fIbefore\fR any \fB\-L\fR options
will not search the paths given by the \fB\-L\fR options following it.
.IP "\fB\-link\-as\-library\fR" 4
.IX Item "-link-as-library"
Link the bytecode files together as a library, not an executable. In this mode,
undefined symbols will be permitted.
.IP "\fB\-r\fR" 4
.IX Item "-r"
An alias for \-link\-as\-library.
.ie n .IP "\fB\-march=\fR""target""" 4
.el .IP "\fB\-march=\fR\f(CWtarget\fR" 4
.IX Item "-march=target"
Specifies the kind of machine for which code or assembly should be generated.
.IP "\fB\-native\fR" 4
.IX Item "-native"
Generate a native machine code executable.
.Sp
When generating native executables, \fBllvm-ld\fR first checks for a bytecode
version of the library and links it in, if necessary. If the library is
missing, \fBllvm-ld\fR skips it. Then, \fBllvm-ld\fR links in the same
libraries as native code.
.Sp
In this way, \fBllvm-ld\fR should be able to link in optimized bytecode
subsets of common libraries and then link in any part of the library that
hasn't been converted to bytecode.
.IP "\fB\-native\-cbe\fR" 4
.IX Item "-native-cbe"
Generate a native machine code executable with the \s-1LLVM\s0 C backend.
.Sp
This option is identical to the \fB\-native\fR option, but uses the
C backend to generate code for the program instead of an \s-1LLVM\s0 native
code generator.
.Sh "Optimization Options"
.IX Subsection "Optimization Options"
.IP "\fB\-O0\fR" 4
.IX Item "-O0"
An alias for the \-O1 option.
.IP "\fB\-O1\fR" 4
.IX Item "-O1"
Optimize for linking speed, not execution speed. The optimizer will attempt to
reduce the size of the linked program to reduce I/O but will not otherwise
perform any link-time optimizations.
.IP "\fB\-O2\fR" 4
.IX Item "-O2"
Perform only the minimal or required set of scalar optimizations.
.IP "\fB\-03\fR" 4
.IX Item "-03"
An alias for the \-O2 option.
.IP "\fB\-04\fR" 4
.IX Item "-04"
Perform the standard link time inter-procedural optimizations. This will
attempt to optimize the program taking the entire program into consideration.
.IP "\fB\-O5\fR" 4
.IX Item "-O5"
Perform aggressive link time optimizations. This is the same as \-O4 but works
more aggressively to optimize the program.
.IP "\fB\-disable\-inlining\fR" 4
.IX Item "-disable-inlining"
Do not run the inlining pass. Functions will not be inlined into other
functions.
.IP "\fB\-disable\-opt\fR" 4
.IX Item "-disable-opt"
Completely disable optimization. The various \fB\-On\fR options will be ignored and
no link time optimization passes will be run.
.IP "\fB\-disable\-internalize\fR" 4
.IX Item "-disable-internalize"
Do not mark all symbols as internal.
.IP "\fB\-verify\-each\fR" 4
.IX Item "-verify-each"
Run the verification pass after each of the passes to verify intermediate
results.
.IP "\fB\-strip\-all\fR" 4
.IX Item "-strip-all"
Strip all debug and symbol information from the executable to make it smaller.
.IP "\fB\-strip\-debug\fR" 4
.IX Item "-strip-debug"
Strip all debug information from the executable to make it smaller.
.IP "\fB\-s\fR" 4
.IX Item "-s"
An alias for \fB\-strip\-all\fR.
.IP "\fB\-S\fR" 4
.IX Item "-S"
An alias for \fB\-strip\-debug\fR.
.IP "\fB\-export\-dynamic\fR" 4
.IX Item "-export-dynamic"
An alias for \fB\-disable\-internalize\fR
.IP "\fB\-load\fR \fImodule\fR" 4
.IX Item "-load module"
Load an optimization module, \fImodule\fR, which is expected to be a dynamic
library that provides the function name \f(CW\*(C`RunOptimizations\*(C'\fR. This function will
be passed the PassManager, and the optimization level (values 0\-5 based on the
\&\fB\-On\fR option). This function may add passes to the PassManager that should be
run. This feature allows the optimization passes of \fBllvm-ld\fR to be extended.
.IP "\fB\-post\-link\-opt\fR\fIPath\fR" 4
.IX Item "-post-link-optPath"
Run post-link optimization program. After linking is completed a bytecode file
will be generated. It will be passed to the program specified by \fIPath\fR as the
first argument. The second argument to the program will be the name of a
temporary file into which the program should place its optimized output. For
example, the \*(L"no\-op optimization\*(R" would be a simple shell script:
.Sp
.Vb 2
\& #!/bin/bash
\& cp $1 $2
.Ve
.SH "EXIT STATUS"
.IX Header "EXIT STATUS"
If \fBllvm-ld\fR succeeds, it will exit with 0 return code. If an error occurs,
it will exit with a non-zero return code.
.SH "ENVIRONMENT"
.IX Header "ENVIRONMENT"
The \f(CW\*(C`LLVM_LIB_SEARCH_PATH\*(C'\fR environment variable is used to find bytecode
libraries. Any paths specified in this variable will be searched after the \f(CW\*(C`\-L\*(C'\fR
options.
.SH "SEE ALSO"
.IX Header "SEE ALSO"
llvm-link
.SH "AUTHORS"
.IX Header "AUTHORS"
Maintained by the \s-1LLVM\s0 Team (<http://llvm.org>).

View File

@@ -1,186 +0,0 @@
.\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.14
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sh \" Subsection heading
.br
.if t .Sp
.ne 5
.PP
\fB\\$1\fR
.PP
..
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings. \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote. | will give a
.\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used to
.\" do unbreakable dashes and therefore won't be available. \*(C` and \*(C'
.\" expand to `' in nroff, nothing in troff, for use with C<>.
.tr \(*W-|\(bv\*(Tr
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
. ds -- \(*W-
. ds PI pi
. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
. ds L" ""
. ds R" ""
. ds C` ""
. ds C' ""
'br\}
.el\{\
. ds -- \|\(em\|
. ds PI \(*p
. ds L" ``
. ds R" ''
'br\}
.\"
.\" If the F register is turned on, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
.\" entries marked with X<> in POD. Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.if \nF \{\
. de IX
. tm Index:\\$1\t\\n%\t"\\$2"
..
. nr % 0
. rr F
.\}
.\"
.\" For nroff, turn off justification. Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.hy 0
.if n .na
.\"
.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
.\" Fear. Run. Save yourself. No user-serviceable parts.
. \" fudge factors for nroff and troff
.if n \{\
. ds #H 0
. ds #V .8m
. ds #F .3m
. ds #[ \f1
. ds #] \fP
.\}
.if t \{\
. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
. ds #V .6m
. ds #F 0
. ds #[ \&
. ds #] \&
.\}
. \" simple accents for nroff and troff
.if n \{\
. ds ' \&
. ds ` \&
. ds ^ \&
. ds , \&
. ds ~ ~
. ds /
.\}
.if t \{\
. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
.\}
. \" troff and (daisy-wheel) nroff accents
.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
.ds ae a\h'-(\w'a'u*4/10)'e
.ds Ae A\h'-(\w'A'u*4/10)'E
. \" corrections for vroff
.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
. \" for low resolution devices (crt and lpr)
.if \n(.H>23 .if \n(.V>19 \
\{\
. ds : e
. ds 8 ss
. ds o a
. ds d- d\h'-1'\(ga
. ds D- D\h'-1'\(hy
. ds th \o'bp'
. ds Th \o'LP'
. ds ae ae
. ds Ae AE
.\}
.rm #[ #] #H #V #F C
.\" ========================================================================
.\"
.IX Title "LLVM-LINK 1"
.TH LLVM-LINK 1 "2006-03-13" "CVS" "LLVM Command Guide"
.SH "NAME"
llvm\-link \- LLVM linker
.SH "SYNOPSIS"
.IX Header "SYNOPSIS"
\&\fBllvm-link\fR [\fIoptions\fR] \fIfilename ...\fR
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
\&\fBllvm-link\fR takes several \s-1LLVM\s0 bytecode files and links them together into a
single \s-1LLVM\s0 bytecode file. It writes the output file to standard output, unless
the \fB\-o\fR option is used to specify a filename.
.PP
\&\fBllvm-link\fR attempts to load the input files from the current directory. If
that fails, it looks for each file in each of the directories specified by the
\&\fB\-L\fR options on the command line. The library search paths are global; each
one is searched for every input file if necessary. The directories are searched
in the order they were specified on the command line.
.SH "OPTIONS"
.IX Header "OPTIONS"
.IP "\fB\-L\fR \fIdirectory\fR" 4
.IX Item "-L directory"
Add the specified \fIdirectory\fR to the library search path. When looking for
libraries, \fBllvm-link\fR will look in pathname for libraries. This option can be
specified multiple times; \fBllvm-link\fR will search inside these directories in
the order in which they were specified on the command line.
.IP "\fB\-f\fR" 4
.IX Item "-f"
Overwrite output files. By default, \fBllvm-link\fR will not overwrite an output
file if it alreadys exists.
.IP "\fB\-o\fR \fIfilename\fR" 4
.IX Item "-o filename"
Specify the output file name. If \fIfilename\fR is \f(CW\*(C`\-\*(C'\fR, then \fBllvm-link\fR will
write its output to standard output.
.IP "\fB\-d\fR" 4
.IX Item "-d"
If specified, \fBllvm-link\fR prints a human-readable version of the output
bytecode file to standard error.
.IP "\fB\-\-help\fR" 4
.IX Item "--help"
Print a summary of command line options.
.IP "\fB\-v\fR" 4
.IX Item "-v"
Verbose mode. Print information about what \fBllvm-link\fR is doing. This
typically includes a message for each bytecode file linked in and for each
library found.
.SH "EXIT STATUS"
.IX Header "EXIT STATUS"
If \fBllvm-link\fR succeeds, it will exit with 0. Otherwise, if an error
occurs, it will exit with a non-zero value.
.SH "SEE ALSO"
.IX Header "SEE ALSO"
gccld
.SH "AUTHORS"
.IX Header "AUTHORS"
Maintained by the \s-1LLVM\s0 Team (<http://llvm.org>).

View File

@@ -1,219 +0,0 @@
.\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.14
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sh \" Subsection heading
.br
.if t .Sp
.ne 5
.PP
\fB\\$1\fR
.PP
..
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings. \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote. | will give a
.\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used to
.\" do unbreakable dashes and therefore won't be available. \*(C` and \*(C'
.\" expand to `' in nroff, nothing in troff, for use with C<>.
.tr \(*W-|\(bv\*(Tr
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
. ds -- \(*W-
. ds PI pi
. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
. ds L" ""
. ds R" ""
. ds C` ""
. ds C' ""
'br\}
.el\{\
. ds -- \|\(em\|
. ds PI \(*p
. ds L" ``
. ds R" ''
'br\}
.\"
.\" If the F register is turned on, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
.\" entries marked with X<> in POD. Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.if \nF \{\
. de IX
. tm Index:\\$1\t\\n%\t"\\$2"
..
. nr % 0
. rr F
.\}
.\"
.\" For nroff, turn off justification. Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.hy 0
.if n .na
.\"
.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
.\" Fear. Run. Save yourself. No user-serviceable parts.
. \" fudge factors for nroff and troff
.if n \{\
. ds #H 0
. ds #V .8m
. ds #F .3m
. ds #[ \f1
. ds #] \fP
.\}
.if t \{\
. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
. ds #V .6m
. ds #F 0
. ds #[ \&
. ds #] \&
.\}
. \" simple accents for nroff and troff
.if n \{\
. ds ' \&
. ds ` \&
. ds ^ \&
. ds , \&
. ds ~ ~
. ds /
.\}
.if t \{\
. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
.\}
. \" troff and (daisy-wheel) nroff accents
.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
.ds ae a\h'-(\w'a'u*4/10)'e
.ds Ae A\h'-(\w'A'u*4/10)'E
. \" corrections for vroff
.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
. \" for low resolution devices (crt and lpr)
.if \n(.H>23 .if \n(.V>19 \
\{\
. ds : e
. ds 8 ss
. ds o a
. ds d- d\h'-1'\(ga
. ds D- D\h'-1'\(hy
. ds th \o'bp'
. ds Th \o'LP'
. ds ae ae
. ds Ae AE
.\}
.rm #[ #] #H #V #F C
.\" ========================================================================
.\"
.IX Title "LLVM-NM 1"
.TH LLVM-NM 1 "2006-11-20" "CVS" "LLVM Command Guide"
.SH "NAME"
llvm\-nm \- list LLVM bytecode file's symbol table
.SH "SYNOPSIS"
.IX Header "SYNOPSIS"
\&\fBllvm-nm\fR [\fIoptions\fR] [\fIfilenames...\fR]
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
The \fBllvm-nm\fR utility lists the names of symbols from the \s-1LLVM\s0 bytecode files,
or \fBar\fR archives containing \s-1LLVM\s0 bytecode files, named on the command line.
Each symbol is listed along with some simple information about its provenance.
If no filename is specified, or \fI\-\fR is used as a filename, \fBllvm-nm\fR will
process a bytecode file on its standard input stream.
.PP
\&\fBllvm-nm\fR's default output format is the traditional \s-1BSD\s0 \fBnm\fR output format.
Each such output record consists of an (optional) 8\-digit hexadecimal address,
followed by a type code character, followed by a name, for each symbol. One
record is printed per line; fields are separated by spaces. When the address is
omitted, it is replaced by 8 spaces.
.PP
Type code characters currently supported, and their meanings, are as follows:
.IP "U" 4
.IX Item "U"
Named object is referenced but undefined in this bytecode file
.IP "C" 4
.IX Item "C"
Common (multiple defs link together into one def)
.IP "W" 4
.IX Item "W"
Weak reference (multiple defs link together into zero or one defs)
.IP "t" 4
.IX Item "t"
Local function (text) object
.IP "T" 4
.IX Item "T"
Global function (text) object
.IP "d" 4
.IX Item "d"
Local data object
.IP "D" 4
.IX Item "D"
Global data object
.IP "?" 4
Something unrecognizable
.PP
Because \s-1LLVM\s0 bytecode files typically contain objects that are not considered to
have addresses until they are linked into an executable image or dynamically
compiled \*(L"just\-in\-time\*(R", \fBllvm-nm\fR does not print an address for any symbol,
even symbols which are defined in the bytecode file.
.SH "OPTIONS"
.IX Header "OPTIONS"
.IP "\fB\-P\fR" 4
.IX Item "-P"
Use \s-1POSIX\s0.2 output format. Alias for \fB\-\-format=posix\fR.
.IP "\fB\-B\fR (default)" 4
.IX Item "-B (default)"
Use \s-1BSD\s0 output format. Alias for \fB\-\-format=bsd\fR.
.IP "\fB\-\-help\fR" 4
.IX Item "--help"
Print a summary of command-line options and their meanings.
.IP "\fB\-\-defined\-only\fR" 4
.IX Item "--defined-only"
Print only symbols defined in this bytecode file (as opposed to
symbols which may be referenced by objects in this file, but not
defined in this file.)
.IP "\fB\-\-extern\-only\fR, \fB\-g\fR" 4
.IX Item "--extern-only, -g"
Print only symbols whose definitions are external; that is, accessible
from other bytecode files.
.IP "\fB\-\-undefined\-only\fR, \fB\-u\fR" 4
.IX Item "--undefined-only, -u"
Print only symbols referenced but not defined in this bytecode file.
.IP "\fB\-\-format=\fR\fIfmt\fR, \fB\-f\fR" 4
.IX Item "--format=fmt, -f"
Select an output format; \fIfmt\fR may be \fIsysv\fR, \fIposix\fR, or \fIbsd\fR. The
default is \fIbsd\fR.
.SH "BUGS"
.IX Header "BUGS"
\&\fBllvm-nm\fR cannot demangle \*(C+ mangled names, like \s-1GNU\s0 \fBnm\fR can.
.SH "EXIT STATUS"
.IX Header "EXIT STATUS"
\&\fBllvm-nm\fR exits with an exit code of zero.
.SH "SEE ALSO"
.IX Header "SEE ALSO"
llvm-dis, \fIar\fR\|(1), \fInm\fR\|(1)
.SH "AUTHOR"
.IX Header "AUTHOR"
Maintained by the \s-1LLVM\s0 Team (<http://llvm.org>).

View File

@@ -1,173 +0,0 @@
.\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.14
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sh \" Subsection heading
.br
.if t .Sp
.ne 5
.PP
\fB\\$1\fR
.PP
..
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings. \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote. | will give a
.\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used to
.\" do unbreakable dashes and therefore won't be available. \*(C` and \*(C'
.\" expand to `' in nroff, nothing in troff, for use with C<>.
.tr \(*W-|\(bv\*(Tr
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
. ds -- \(*W-
. ds PI pi
. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
. ds L" ""
. ds R" ""
. ds C` ""
. ds C' ""
'br\}
.el\{\
. ds -- \|\(em\|
. ds PI \(*p
. ds L" ``
. ds R" ''
'br\}
.\"
.\" If the F register is turned on, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
.\" entries marked with X<> in POD. Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.if \nF \{\
. de IX
. tm Index:\\$1\t\\n%\t"\\$2"
..
. nr % 0
. rr F
.\}
.\"
.\" For nroff, turn off justification. Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.hy 0
.if n .na
.\"
.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
.\" Fear. Run. Save yourself. No user-serviceable parts.
. \" fudge factors for nroff and troff
.if n \{\
. ds #H 0
. ds #V .8m
. ds #F .3m
. ds #[ \f1
. ds #] \fP
.\}
.if t \{\
. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
. ds #V .6m
. ds #F 0
. ds #[ \&
. ds #] \&
.\}
. \" simple accents for nroff and troff
.if n \{\
. ds ' \&
. ds ` \&
. ds ^ \&
. ds , \&
. ds ~ ~
. ds /
.\}
.if t \{\
. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
.\}
. \" troff and (daisy-wheel) nroff accents
.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
.ds ae a\h'-(\w'a'u*4/10)'e
.ds Ae A\h'-(\w'A'u*4/10)'E
. \" corrections for vroff
.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
. \" for low resolution devices (crt and lpr)
.if \n(.H>23 .if \n(.V>19 \
\{\
. ds : e
. ds 8 ss
. ds o a
. ds d- d\h'-1'\(ga
. ds D- D\h'-1'\(hy
. ds th \o'bp'
. ds Th \o'LP'
. ds ae ae
. ds Ae AE
.\}
.rm #[ #] #H #V #F C
.\" ========================================================================
.\"
.IX Title "LLVM-PROF 1"
.TH LLVM-PROF 1 "2006-03-13" "CVS" "LLVM Command Guide"
.SH "NAME"
llvm\-prof \- print execution profile of LLVM program
.SH "SYNOPSIS"
.IX Header "SYNOPSIS"
\&\fBllvm-prof\fR [\fIoptions\fR] [\fIbytecode file\fR] [\fIllvmprof.out\fR]
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
The \fBllvm-prof\fR tool reads in an \fIllvmprof.out\fR file (which can
optionally use a specific file with the third program argument), a bytecode file
for the program, and produces a human readable report, suitable for determining
where the program hotspots are.
.PP
This program is often used in conjunction with the \fIutils/profile.pl\fR
script. This script automatically instruments a program, runs it with the \s-1JIT\s0,
then runs \fBllvm-prof\fR to format a report. To get more information about
\&\fIutils/profile.pl\fR, execute it with the \fB\-\-help\fR option.
.SH "OPTIONS"
.IX Header "OPTIONS"
.IP "\fB\-\-annotated\-llvm\fR or \fB\-A\fR" 4
.IX Item "--annotated-llvm or -A"
In addition to the normal report printed, print out the code for the
program, annotated with execution frequency information. This can be
particularly useful when trying to visualize how frequently basic blocks
are executed. This is most useful with basic block profiling
information or better.
.IP "\fB\-\-print\-all\-code\fR" 4
.IX Item "--print-all-code"
Using this option enables the \fB\-\-annotated\-llvm\fR option, but it
prints the entire module, instead of just the most commonly executed
functions.
.IP "\fB\-\-time\-passes\fR" 4
.IX Item "--time-passes"
Record the amount of time needed for each pass and print it to standard
error.
.SH "EXIT STATUS"
.IX Header "EXIT STATUS"
\&\fBllvm-prof\fR returns 1 if it cannot load the bytecode file or the profile
information. Otherwise, it exits with zero.
.SH "AUTHOR"
.IX Header "AUTHOR"
\&\fBllvm-prof\fR is maintained by the \s-1LLVM\s0 Team (<http://llvm.org>).

View File

@@ -1,167 +0,0 @@
.\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.14
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sh \" Subsection heading
.br
.if t .Sp
.ne 5
.PP
\fB\\$1\fR
.PP
..
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings. \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote. | will give a
.\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used to
.\" do unbreakable dashes and therefore won't be available. \*(C` and \*(C'
.\" expand to `' in nroff, nothing in troff, for use with C<>.
.tr \(*W-|\(bv\*(Tr
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
. ds -- \(*W-
. ds PI pi
. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
. ds L" ""
. ds R" ""
. ds C` ""
. ds C' ""
'br\}
.el\{\
. ds -- \|\(em\|
. ds PI \(*p
. ds L" ``
. ds R" ''
'br\}
.\"
.\" If the F register is turned on, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
.\" entries marked with X<> in POD. Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.if \nF \{\
. de IX
. tm Index:\\$1\t\\n%\t"\\$2"
..
. nr % 0
. rr F
.\}
.\"
.\" For nroff, turn off justification. Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.hy 0
.if n .na
.\"
.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
.\" Fear. Run. Save yourself. No user-serviceable parts.
. \" fudge factors for nroff and troff
.if n \{\
. ds #H 0
. ds #V .8m
. ds #F .3m
. ds #[ \f1
. ds #] \fP
.\}
.if t \{\
. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
. ds #V .6m
. ds #F 0
. ds #[ \&
. ds #] \&
.\}
. \" simple accents for nroff and troff
.if n \{\
. ds ' \&
. ds ` \&
. ds ^ \&
. ds , \&
. ds ~ ~
. ds /
.\}
.if t \{\
. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
.\}
. \" troff and (daisy-wheel) nroff accents
.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
.ds ae a\h'-(\w'a'u*4/10)'e
.ds Ae A\h'-(\w'A'u*4/10)'E
. \" corrections for vroff
.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
. \" for low resolution devices (crt and lpr)
.if \n(.H>23 .if \n(.V>19 \
\{\
. ds : e
. ds 8 ss
. ds o a
. ds d- d\h'-1'\(ga
. ds D- D\h'-1'\(hy
. ds th \o'bp'
. ds Th \o'LP'
. ds ae ae
. ds Ae AE
.\}
.rm #[ #] #H #V #F C
.\" ========================================================================
.\"
.IX Title "LLVM-RANLIB 1"
.TH LLVM-RANLIB 1 "2006-03-13" "CVS" "LLVM Command Guide"
.SH "NAME"
llvm\-ranlib \- Generate index for LLVM archive
.SH "SYNOPSIS"
.IX Header "SYNOPSIS"
\&\fBllvm-ranlib\fR [\-\-version] [\-\-help] <archive\-file>
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
The \fBllvm-ranlib\fR command is similar to the common Unix utility, \f(CW\*(C`ranlib\*(C'\fR. It
adds or updates the symbol table in an \s-1LLVM\s0 archive file. Note that using the
\&\fBllvm-ar\fR modifier \fIs\fR is usually more efficient than running \fBllvm-ranlib\fR
which is only provided only for completness and compatibility. Unlike other
implementations of \f(CW\*(C`ranlib\*(C'\fR, \fBllvm-ranlib\fR indexes \s-1LLVM\s0 bytecode files, not
native object modules. You can list the contents of the symbol table with the
\&\f(CW\*(C`llvm\-nm \-s\*(C'\fR command.
.SH "OPTIONS"
.IX Header "OPTIONS"
.IP "\fIarchive-file\fR" 4
.IX Item "archive-file"
Specifies the archive-file to which the symbol table is added or updated.
.IP "\fI\-\-version\fR" 4
.IX Item "--version"
Print the version of \fBllvm-ranlib\fR and exit without building a symbol table.
.IP "\fI\-\-help\fR" 4
.IX Item "--help"
Print usage help for \fBllvm-ranlib\fR and exit without building a symbol table.
.SH "EXIT STATUS"
.IX Header "EXIT STATUS"
If \fBllvm-ranlib\fR succeeds, it will exit with 0. If an error occurs, a non-zero
exit code will be returned.
.SH "SEE ALSO"
.IX Header "SEE ALSO"
llvm-ar, \fIranlib\fR\|(1)
.SH "AUTHORS"
.IX Header "AUTHORS"
Maintained by the \s-1LLVM\s0 Team (<http://llvm.org>).

View File

@@ -1,179 +0,0 @@
.\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.14
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sh \" Subsection heading
.br
.if t .Sp
.ne 5
.PP
\fB\\$1\fR
.PP
..
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings. \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote. | will give a
.\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used to
.\" do unbreakable dashes and therefore won't be available. \*(C` and \*(C'
.\" expand to `' in nroff, nothing in troff, for use with C<>.
.tr \(*W-|\(bv\*(Tr
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
. ds -- \(*W-
. ds PI pi
. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
. ds L" ""
. ds R" ""
. ds C` ""
. ds C' ""
'br\}
.el\{\
. ds -- \|\(em\|
. ds PI \(*p
. ds L" ``
. ds R" ''
'br\}
.\"
.\" If the F register is turned on, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
.\" entries marked with X<> in POD. Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.if \nF \{\
. de IX
. tm Index:\\$1\t\\n%\t"\\$2"
..
. nr % 0
. rr F
.\}
.\"
.\" For nroff, turn off justification. Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.hy 0
.if n .na
.\"
.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
.\" Fear. Run. Save yourself. No user-serviceable parts.
. \" fudge factors for nroff and troff
.if n \{\
. ds #H 0
. ds #V .8m
. ds #F .3m
. ds #[ \f1
. ds #] \fP
.\}
.if t \{\
. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
. ds #V .6m
. ds #F 0
. ds #[ \&
. ds #] \&
.\}
. \" simple accents for nroff and troff
.if n \{\
. ds ' \&
. ds ` \&
. ds ^ \&
. ds , \&
. ds ~ ~
. ds /
.\}
.if t \{\
. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
.\}
. \" troff and (daisy-wheel) nroff accents
.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
.ds ae a\h'-(\w'a'u*4/10)'e
.ds Ae A\h'-(\w'A'u*4/10)'E
. \" corrections for vroff
.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
. \" for low resolution devices (crt and lpr)
.if \n(.H>23 .if \n(.V>19 \
\{\
. ds : e
. ds 8 ss
. ds o a
. ds d- d\h'-1'\(ga
. ds D- D\h'-1'\(hy
. ds th \o'bp'
. ds Th \o'LP'
. ds ae ae
. ds Ae AE
.\}
.rm #[ #] #H #V #F C
.\" ========================================================================
.\"
.IX Title "LLVM-UPGRADE 1"
.TH LLVM-UPGRADE 1 "2006-12-02" "CVS" "LLVM Command Guide"
.SH "NAME"
llvm\-upgrade \- LLVM assembly upgrader
.SH "SYNOPSIS"
.IX Header "SYNOPSIS"
\&\fBllvm-upgrade\fR [\fIoptions\fR] [\fIfilename\fR]
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
\&\fBllvm-upgrade\fR is the \s-1LLVM\s0 assembly upgrader. It reads a file containing
human-readable \s-1LLVM\s0 assembly language, and upgrades that assembly to the current
version of \s-1LLVM\s0. If the input is in the form currently accepted by \s-1LLVM\s0, then
no upgrades are performed.
.PP
The expected usage of this tool is as a filter, like this:
.Sp
.RS 4
\&\fBllvm\-1.9/bin/llvm\-dis < 1.9.bc | llvm-upgrade | llvm\-2.0/bin/llvm\-as \-o 2.0.bc\fR
.RE
.PP
If \fIfilename\fR is omitted or is \f(CW\*(C`\-\*(C'\fR, then \fBllvm-upgrade\fR reads its input from
standard input.
.PP
If an output file is not specified with the \fB\-o\fR option, then
\&\fBllvm-upgrade\fR sends its output to standard output.
.SH "OPTIONS"
.IX Header "OPTIONS"
.IP "\fB\-f\fR" 4
.IX Item "-f"
Force overwrite. Normally, \fBllvm-upgrade\fR will refuse to overwrite an
output file that already exists. With this option, \fBllvm-upgrade\fR
will overwrite the output file.
.IP "\fB\-\-help\fR" 4
.IX Item "--help"
Print a summary of command line options.
.IP "\fB\-o\fR \fIfilename\fR" 4
.IX Item "-o filename"
Specify the output file name. If \fIfilename\fR is \f(CW\*(C`\-\*(C'\fR, then \fBllvm-upgrade\fR
sends its output to standard output.
.SH "EXIT STATUS"
.IX Header "EXIT STATUS"
If \fBllvm-upgrade\fR succeeds, it will exit with 0. Otherwise, if an error
occurs, it will exit with a non-zero value.
.SH "SEE ALSO"
.IX Header "SEE ALSO"
llvm-as, llvm-dis
.SH "AUTHORS"
.IX Header "AUTHORS"
Maintained by the \s-1LLVM\s0 Team (<http://llvm.org>).

View File

@@ -1,301 +0,0 @@
.\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.14
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sh \" Subsection heading
.br
.if t .Sp
.ne 5
.PP
\fB\\$1\fR
.PP
..
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings. \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote. | will give a
.\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used to
.\" do unbreakable dashes and therefore won't be available. \*(C` and \*(C'
.\" expand to `' in nroff, nothing in troff, for use with C<>.
.tr \(*W-|\(bv\*(Tr
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
. ds -- \(*W-
. ds PI pi
. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
. ds L" ""
. ds R" ""
. ds C` ""
. ds C' ""
'br\}
.el\{\
. ds -- \|\(em\|
. ds PI \(*p
. ds L" ``
. ds R" ''
'br\}
.\"
.\" If the F register is turned on, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
.\" entries marked with X<> in POD. Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.if \nF \{\
. de IX
. tm Index:\\$1\t\\n%\t"\\$2"
..
. nr % 0
. rr F
.\}
.\"
.\" For nroff, turn off justification. Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.hy 0
.if n .na
.\"
.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
.\" Fear. Run. Save yourself. No user-serviceable parts.
. \" fudge factors for nroff and troff
.if n \{\
. ds #H 0
. ds #V .8m
. ds #F .3m
. ds #[ \f1
. ds #] \fP
.\}
.if t \{\
. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
. ds #V .6m
. ds #F 0
. ds #[ \&
. ds #] \&
.\}
. \" simple accents for nroff and troff
.if n \{\
. ds ' \&
. ds ` \&
. ds ^ \&
. ds , \&
. ds ~ ~
. ds /
.\}
.if t \{\
. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
.\}
. \" troff and (daisy-wheel) nroff accents
.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
.ds ae a\h'-(\w'a'u*4/10)'e
.ds Ae A\h'-(\w'A'u*4/10)'E
. \" corrections for vroff
.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
. \" for low resolution devices (crt and lpr)
.if \n(.H>23 .if \n(.V>19 \
\{\
. ds : e
. ds 8 ss
. ds o a
. ds d- d\h'-1'\(ga
. ds D- D\h'-1'\(hy
. ds th \o'bp'
. ds Th \o'LP'
. ds ae ae
. ds Ae AE
.\}
.rm #[ #] #H #V #F C
.\" ========================================================================
.\"
.IX Title "LLVM2CPP 1"
.TH LLVM2CPP 1 "2006-08-10" "CVS" "LLVM Command Guide"
.SH "NAME"
llvm2xpp \- LLVM bytecode to LLVM C++ IR translator
.SH "SYNOPSIS"
.IX Header "SYNOPSIS"
\&\fBllvm2cpp\fR [\fIoptions\fR] [\fIfilename\fR]
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
\&\fBllvm2cpp\fR translates from \s-1LLVM\s0 bytecode (.bc files) to a
corresponding \*(C+ source file that will make calls against the \s-1LLVM\s0 \*(C+ \s-1API\s0 to
build the same module as the input. By default, the \*(C+ output is a complete
program that builds the module, verifies it and then emits the module as
\&\s-1LLVM\s0 assembly. This technique assists with testing because the input to
\&\fBllvm2cpp\fR and the output of the generated \*(C+ program should be identical.
.PP
If \fIfilename\fR is omitted or is \f(CW\*(C`\-\*(C'\fR, then \fBllvm2cpp\fR reads its input from
standard input.
.PP
If an output file is not specified with the \fB\-o\fR option, then
\&\fBllvm2cpp\fR sends its output to a file or standard output by following
these rules:
.IP "\(bu" 4
If the input is standard input, then the output is standard output.
.IP "\(bu" 4
If the input is a file that ends with \f(CW\*(C`.bc\*(C'\fR, then the output file is of
the same name, except that the suffix is changed to \f(CW\*(C`.cpp\*(C'\fR.
.IP "\(bu" 4
If the input is a file that does not end with the \f(CW\*(C`.bc\*(C'\fR suffix, then the
output file has the same name as the input file, except that the \f(CW\*(C`.cpp\*(C'\fR
suffix is appended.
.SH "OPTIONS"
.IX Header "OPTIONS"
.IP "\fB\-f\fR" 4
.IX Item "-f"
Force overwrite. Normally, \fBllvm2cpp\fR will refuse to overwrite an
output file that already exists. With this option, \fBllvm2cpp\fR
will overwrite the output file and replace it with new \*(C+ source code.
.IP "\fB\-\-help\fR" 4
.IX Item "--help"
Print a summary of command line options.
.IP "\fB\-f\fR" 4
.IX Item "-f"
Normally, \fBllvm2cpp\fR will not overwrite an existing output file. With this
option, that default behavior is changed and the program will overwrite existing
output files.
.IP "\fB\-o\fR \fIfilename\fR" 4
.IX Item "-o filename"
Specify the output file name. If \fIfilename\fR is \f(CW\*(C`\-\*(C'\fR, then \fBllvm2cpp\fR
sends its output to standard output.
.IP "\fB\-funcname\fR \fIfunctionName\fR" 4
.IX Item "-funcname functionName"
Specify the name of the function to be generated. The generated code contains a
single function that produces the input module. By default its name is
\&\fImakeLLVMModule\fR. The \fB\-funcname\fR option overrides this default and allows
you to control the name of the generated function. This is handy in conjunction
with the \fB\-fragment\fR option when you only want \fBllvm2cpp\fR to generate a
single function that produces the module. With both options, such generated code
could be \fI#included\fR into another program.
.IP "\fB\-for\fR" 4
.IX Item "-for"
Specify the name of the thing for which \*(C+ code should be generated. By default
the entire input module is re\-generated. However, use of the various \fB\-gen\-*\fR
options can restrict what is produced. This option indicates what that
restriction is.
.IP "\fB\-gen\-program\fR" 4
.IX Item "-gen-program"
Specify that the output should be a complete program. Such program will recreate
\&\fBllvm2cpp\fR's input as an \s-1LLVM\s0 module, verify that module, and then write out
the module in \s-1LLVM\s0 assembly format. This is useful for doing identity tests
where the output of the generated program is identical to the input to
\&\fBllvm2cpp\fR. The \s-1LLVM\s0 DejaGnu test suite can make use of this fact. This is the
default form of generated output.
.Sp
If the \fB\-for\fR option is given with this option, it specifies the module
identifier to use for the module created.
.IP "\fB\-gen\-module\fR" 4
.IX Item "-gen-module"
Specify that the output should be a function that regenerates the module. It is
assumed that this output will be #included into another program that has already
arranged for the correct header files to be #included. The function generated
takes no arguments and returns a \fIModule*\fR.
.Sp
If the \fB\-for\fR option is given with this option, it specifies the module
identifier to use in creating the module returned by the generated function.
.IP "\fB\-gen\-contents\fR" 4
.IX Item "-gen-contents"
Specify that the output should be a function that adds the contents of the input
module to another module. It is assumed that the output will be #included into
another program that has already arranged for the correct header files to be
#included. The function generated takes a single argument of type \fIModule*\fR and
returns that argument. Note that Module level attributes such as endianess,
pointer size, target triple and inline asm are not passed on from the input
module to the destination module. Only the sub-elements of the module (types,
constants, functions, global variables) will be added to the input module.
.Sp
If the \fB\-for\fR option is given with this option, it specifies the module
identifier to set in the input module by the generated function.
.IP "\fB\-gen\-function\fR" 4
.IX Item "-gen-function"
Specify that the output should be a function that produces the definitions
necessary for a specific function to be added to a module. It is assumed that
the output will be #included into another program that has already arranged
for the correct header files to be #included. The function generated takes a
single argument of type \fIModule*\fR and returns the \fIFunction*\fR that it added to
the module. Note that only those things (types, constants, etc.) directly
needed in the definition of the function will be placed in the generated
function.
.Sp
The \fB\-for\fR option must be given with this option or an error will be produced.
The value of the option must be the name of a function in the input module for
which code should be generated. If the named function does not exist an error
will be produced.
.IP "\fB\-gen\-inline\fR" 4
.IX Item "-gen-inline"
This option is very analagous to \fB\-gen\-function\fR except that the generated
function will not re-produce the target function's definition. Instead, the body
of the target function is inserted into some other function passed as an
argument to the generated function. Similarly any arguments to the function must
be passed to the generated function. The result of the generated function is the
first basic block of the target function.
.Sp
The \fB\-for\fR option works the same way as it does for \fB\-gen\-function\fR.
.IP "\fB\-gen\-variable\fR" 4
.IX Item "-gen-variable"
Specify that the output should be a function that produces the definitions
necessary for a specific global variable to be added to a module. It is assumed
that the output will be #included into another program that has already arranged
for the correct header files to be #included. The function generated takes a
single argument of type \fIModule*\fR and returns the \fIGlobalVariable*\fR that it
added to the module. Note that only those things (types, constants, etc.)
directly needed in the definition of the global variable will be placed in the
generated function.
.Sp
The \fB\-for\fR option must be given with this option or an error will be produced.
THe value of the option must be the name of a global variable in the input
module for which code should be generated. If the named global variable does not
exist an error will be produced.
.IP "\fB\-gen\-type\fR" 4
.IX Item "-gen-type"
Specify that the output should be a function that produces the definitions
necessary for specific type to be added to a module. It is assumed that the
otuput will be #included into another program that has already arranged for the
correct header files to be #included. The function generated take a single
argument of type \fIModule*\fR and returns the \fIType*\fR that it added to the
module. Note that the generated function will only add the necessary type
definitions to (possibly recursively) define the requested type.
.Sp
The \fB\-for\fR option must be given with this option or an error will be produced.
The value of the option must be the name of a global type in the input module
for which code should be generated. If the named type does not exist an error
will be produced.
.IP "\fB\-stats\fR" 4
.IX Item "-stats"
Show pass statistics (not interesting in this program).
.IP "\fB\-time\-passes\fR" 4
.IX Item "-time-passes"
Show pass timing statistics (not interesting in this program).
.IP "\fB\-version\fR" 4
.IX Item "-version"
Show the version number of this program.
.SH "EXIT STATUS"
.IX Header "EXIT STATUS"
If \fBllvm2cpp\fR succeeds, it will exit with 0. Otherwise, if an error
occurs, it will exit with a non-zero value.
.SH "SEE ALSO"
.IX Header "SEE ALSO"
llvm-as tblgen
.SH "AUTHORS"
.IX Header "AUTHORS"
Written by Reid Spencer (<http://hlvm.org>).

View File

@@ -1,455 +0,0 @@
.\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.14
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sh \" Subsection heading
.br
.if t .Sp
.ne 5
.PP
\fB\\$1\fR
.PP
..
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings. \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote. | will give a
.\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used to
.\" do unbreakable dashes and therefore won't be available. \*(C` and \*(C'
.\" expand to `' in nroff, nothing in troff, for use with C<>.
.tr \(*W-|\(bv\*(Tr
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
. ds -- \(*W-
. ds PI pi
. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
. ds L" ""
. ds R" ""
. ds C` ""
. ds C' ""
'br\}
.el\{\
. ds -- \|\(em\|
. ds PI \(*p
. ds L" ``
. ds R" ''
'br\}
.\"
.\" If the F register is turned on, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
.\" entries marked with X<> in POD. Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.if \nF \{\
. de IX
. tm Index:\\$1\t\\n%\t"\\$2"
..
. nr % 0
. rr F
.\}
.\"
.\" For nroff, turn off justification. Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.hy 0
.if n .na
.\"
.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
.\" Fear. Run. Save yourself. No user-serviceable parts.
. \" fudge factors for nroff and troff
.if n \{\
. ds #H 0
. ds #V .8m
. ds #F .3m
. ds #[ \f1
. ds #] \fP
.\}
.if t \{\
. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
. ds #V .6m
. ds #F 0
. ds #[ \&
. ds #] \&
.\}
. \" simple accents for nroff and troff
.if n \{\
. ds ' \&
. ds ` \&
. ds ^ \&
. ds , \&
. ds ~ ~
. ds /
.\}
.if t \{\
. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
.\}
. \" troff and (daisy-wheel) nroff accents
.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
.ds ae a\h'-(\w'a'u*4/10)'e
.ds Ae A\h'-(\w'A'u*4/10)'E
. \" corrections for vroff
.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
. \" for low resolution devices (crt and lpr)
.if \n(.H>23 .if \n(.V>19 \
\{\
. ds : e
. ds 8 ss
. ds o a
. ds d- d\h'-1'\(ga
. ds D- D\h'-1'\(hy
. ds th \o'bp'
. ds Th \o'LP'
. ds ae ae
. ds Ae AE
.\}
.rm #[ #] #H #V #F C
.\" ========================================================================
.\"
.IX Title "LLVMC 1"
.TH LLVMC 1 "2007-02-11" "CVS" "LLVM Command Guide"
.SH "NAME"
llvmc \- The LLVM Compiler Driver (experimental)
.SH "SYNOPSIS"
.IX Header "SYNOPSIS"
\&\fBllvmc\fR [\fIoptions\fR] [\fIfilenames\fR...]
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
\&\fBllvmc\fR is a configurable driver for invoking other \s-1LLVM\s0 (and non\-LLVM) tools
in order to compile, optimize and link software for multiple languages. For
those familiar with \s-1FSF\s0's \fBgcc\fR tool, it is very similar. Please note that
\&\fBllvmc\fR is considered an experimental tool. \fBllvmc\fR has the following goals:
.IP "* provide a single point of access to the \s-1LLVM\s0 tool set," 4
.IX Item "provide a single point of access to the LLVM tool set,"
.PD 0
.IP "* hide the complexities of the \s-1LLVM\s0 tools through a single interface," 4
.IX Item "hide the complexities of the LLVM tools through a single interface,"
.IP "* make integration of existing non-LLVM tools simple," 4
.IX Item "make integration of existing non-LLVM tools simple,"
.IP "* extend the capabilities of minimal front ends, and" 4
.IX Item "extend the capabilities of minimal front ends, and"
.IP "* make the interface for compiling consistent for all languages." 4
.IX Item "make the interface for compiling consistent for all languages."
.PD
.PP
The tool itself does nothing with a user's program. It merely invokes other
tools to get the compilation tasks done.
.PP
The options supported by \fBllvmc\fR generalize the compilation process and
provide a consistent and simple interface for multiple programming languages.
This makes it easier for developers to get their software compiled with \s-1LLVM\s0.
Without \fBllvmc\fR, developers would need to understand how to invoke the
front-end compiler, optimizer, assembler, and linker in order to compile their
programs. \fBllvmc\fR's sole mission is to trivialize that process.
.Sh "Basic Operation"
.IX Subsection "Basic Operation"
\&\fBllvmc\fR always takes the following basic actions:
.IP "* Command line options and filenames are collected." 4
.IX Item "Command line options and filenames are collected."
The command line options provide the marching orders to \fBllvmc\fR on what actions
it should perform. This is the \fIrequest\fR the user is making of \fBllvmc\fR and it
is interpreted first.
.IP "* Configuration files are read." 4
.IX Item "Configuration files are read."
Based on the options and the suffixes of the filenames presented, a set of
configuration files are read to configure the actions \fBllvmc\fR will take.
Configuration files are provided by either \s-1LLVM\s0 or the front end compiler tools
that \fBllvmc\fR invokes. Users generally don't need to be concerned with the
contents of the configuration files.
.IP "* Determine actions to take." 4
.IX Item "Determine actions to take."
The tool chain needed to complete the task is determined. This is the primary
work of \fBllvmc\fR. It breaks the request specified by the command line options
into a set of basic actions to be done:
.RS 4
.IP "* Pre\-processing: gathering/filtering compiler input (optional)." 4
.IX Item "Pre-processing: gathering/filtering compiler input (optional)."
.PD 0
.IP "* Translation: source language to bytecode conversion." 4
.IX Item "Translation: source language to bytecode conversion."
.IP "* Assembly: bytecode to native code conversion." 4
.IX Item "Assembly: bytecode to native code conversion."
.IP "* Optimization: conversion of bytecode to something that runs faster." 4
.IX Item "Optimization: conversion of bytecode to something that runs faster."
.IP "* Linking: combining multiple bytecodes to produce executable program." 4
.IX Item "Linking: combining multiple bytecodes to produce executable program."
.RE
.RS 4
.RE
.IP "* Execute actions." 4
.IX Item "Execute actions."
.PD
The actions determined previously are executed sequentially and then
\&\fBllvmc\fR terminates.
.SH "OPTIONS"
.IX Header "OPTIONS"
.Sh "Control Options"
.IX Subsection "Control Options"
Control options tell \fBllvmc\fR what to do at a high level. The
following control options are defined:
.IP "\fB\-c\fR or \fB\-\-compile\fR" 4
.IX Item "-c or --compile"
This option specifies that the linking phase is not to be run. All
previous phases, if applicable will run. This is generally how a given
bytecode file is compiled and optimized for a source language module.
.IP "\fB\-k\fR or \fB\-\-link\fR or default" 4
.IX Item "-k or --link or default"
This option (or the lack of any control option) specifies that all stages
of compilation, optimization, and linking should be attempted. Source files
specified on the command line will be compiled and linked with objects and
libraries also specified.
.IP "\fB\-S\fR" 4
.IX Item "-S"
This option specifies that compilation should end in the creation of
an \s-1LLVM\s0 assembly file that can be later converted to an \s-1LLVM\s0 object
file.
.IP "\fB\-E\fR" 4
.IX Item "-E"
This option specifies that no compilation or linking should be
performed. Only pre\-processing, if applicable to the language being
compiled, is performed. For languages that support it, this will
result in the output containing the raw input to the compiler.
.Sh "Optimization Options"
.IX Subsection "Optimization Options"
Optimization with \fBllvmc\fR is based on goals and specified with
the following \-O options. The specific details of which
optimizations run is controlled by the configuration files because
each source language will have different needs.
.IP "\fB\-O1\fR or \fB\-O0\fR (default, fast compilation)" 4
.IX Item "-O1 or -O0 (default, fast compilation)"
Only those optimizations that will hasten the compilation (mostly by reducing
the output) are applied. In general these are extremely fast and simple
optimizations that reduce emitted code size. The goal here is not to make the
resulting program fast but to make the compilation fast. If not specified,
this is the default level of optimization.
.IP "\fB\-O2\fR (basic optimization)" 4
.IX Item "-O2 (basic optimization)"
This level of optimization specifies a balance between generating good code
that will execute reasonably quickly and not spending too much time optimizing
the code to get there. For example, this level of optimization may include
things like global common subexpression elimination, aggressive dead code
elimination, and scalar replication.
.IP "\fB\-O3\fR (aggressive optimization)" 4
.IX Item "-O3 (aggressive optimization)"
This level of optimization aggressively optimizes each set of files compiled
together. However, no link-time inter-procedural optimization is performed.
This level implies all the optimizations of the \fB\-O1\fR and \fB\-O2\fR optimization
levels, and should also provide loop optimizations and compile time
inter-procedural optimizations. Essentially, this level tries to do as much
as it can with the input it is given but doesn't do any link time \s-1IPO\s0.
.IP "\fB\-O4\fR (link time optimization)" 4
.IX Item "-O4 (link time optimization)"
In addition to the previous three levels of optimization, this level of
optimization aggressively optimizes each program at link time. It employs
basic analysis and basic link-time inter-procedural optimizations,
considering the program as a whole.
.IP "\fB\-O5\fR (aggressive link time optimization)" 4
.IX Item "-O5 (aggressive link time optimization)"
This is the same as \fB\-O4\fR except it employs aggressive analyses and
aggressive inter-procedural optimization.
.IP "\fB\-O6\fR (profile guided optimization: not implemented)" 4
.IX Item "-O6 (profile guided optimization: not implemented)"
This is the same as \fB\-O5\fR except that it employs profile-guided
re-optimization of the program after it has executed. Note that this implies
a single level of re-optimization based on runtime profile analysis. Once
the re-optimization has completed, the profiling instrumentation is
removed and final optimizations are employed.
.IP "\fB\-O7\fR (lifelong optimization: not implemented)" 4
.IX Item "-O7 (lifelong optimization: not implemented)"
This is the same as \fB\-O5\fR and similar to \fB\-O6\fR except that re-optimization
is performed through the life of the program. That is, each run will update
the profile by which future re-optimizations are directed.
.Sh "Input Options"
.IX Subsection "Input Options"
.IP "\fB\-l\fR \fI\s-1LIBRARY\s0\fR" 4
.IX Item "-l LIBRARY"
This option instructs \fBllvmc\fR to locate a library named \fI\s-1LIBRARY\s0\fR and search
it for unresolved symbols when linking the program.
.IP "\fB\-L\fR \fIpath\fR" 4
.IX Item "-L path"
This option instructs \fBllvmc\fR to add \fIpath\fR to the list of places in which
the linker will
.IP "\fB\-x\fR \fI\s-1LANGUAGE\s0\fR" 4
.IX Item "-x LANGUAGE"
This option instructs \fBllvmc\fR to regard the following input files as
containing programs in the language \fI\s-1LANGUAGE\s0\fR. Normally, input file languages
are identified by their suffix but this option will override that default
behavior. The \fB\-x\fR option stays in effect until the end of the options or
a new \fB\-x\fR option is encountered.
.Sh "Output Options"
.IX Subsection "Output Options"
.IP "\fB\-m\fR\fIarch\fR" 4
.IX Item "-march"
This option selects the back end code generator to use. The \fIarch\fR portion
of the option names the back end to use.
.IP "\fB\-\-native\fR" 4
.IX Item "--native"
Normally, \fBllvmc\fR produces bytecode files at most stages of compilation.
With this option, \fBllvmc\fR will arrange for native object files to be
generated with the \fB\-c\fR option, native assembly files to be generated
with the \fB\-S\fR option, and native executables to be generated with the
\&\fB\-\-link\fR option. In the case of the \fB\-E\fR option, the output will not
differ as there is no \fInative\fR version of pre-processed output.
.IP "\fB\-o\fR \fIfilename\fR" 4
.IX Item "-o filename"
Specify the output file name. The contents of the file depend on other
options.
.Sh "Information Options"
.IX Subsection "Information Options"
.IP "\fB\-n\fR or \fB\-\-no\-op\fR" 4
.IX Item "-n or --no-op"
This option tells \fBllvmc\fR to do everything but actually execute the
resulting tools. In combination with the \fB\-v\fR option, this causes \fBllvmc\fR
to merely print out what it would have done.
.IP "\fB\-v\fR or \fB\-\-verbose\fR" 4
.IX Item "-v or --verbose"
This option will cause \fBllvmc\fR to print out (on standard output) each of the
actions it takes to accomplish the objective. The output will immediately
precede the invocation of other tools.
.IP "\fB\-\-stats\fR" 4
.IX Item "--stats"
Print all statistics gathered during the compilation to the standard error.
Note that this option is merely passed through to the sub-tools to do with
as they please.
.IP "\fB\-\-time\-passes\fR" 4
.IX Item "--time-passes"
Record the amount of time needed for each optimization pass and print it
to standard error. Like \fB\-\-stats\fR this option is just passed through to
the sub-tools to do with as they please.
.IP "\fB\-\-time\-programs\fR" 4
.IX Item "--time-programs"
Record the amount of time each program (compilation tool) takes and print
it to the standard error.
.Sh "Language Specific Options"
.IX Subsection "Language Specific Options"
.IP "\fB\-T,pre\fR=\fIoptions\fR" 4
.IX Item "-T,pre=options"
Pass an arbitrary option to the pre\-processor.
.IP "\fB\-T,opt\fR=\fIoptions\fR" 4
.IX Item "-T,opt=options"
Pass an arbitrary option to the optimizer.
.IP "\fB\-T,lnk\fR=\fIoptions\fR" 4
.IX Item "-T,lnk=options"
Pass an arbitrary option to the linker.
.IP "\fB\-T,asm\fR=\fIoptions\fR" 4
.IX Item "-T,asm=options"
Pass an arbitrary option to the code generator.
.Sh "C/\*(C+ Specific Options"
.IX Subsection "C/ Specific Options"
.IP "\fB\-I\fR\fIpath\fR" 4
.IX Item "-Ipath"
This option is just passed through to a C or \*(C+ front end compiler to tell it
where include files can be found.
.IP "\fB\-D\fR\fIsymbol\fR" 4
.IX Item "-Dsymbol"
This option is just passed through to a C or \*(C+ front end compiler to tell it
to define a symbol.
.Sh "Miscellaneous Options"
.IX Subsection "Miscellaneous Options"
.IP "\fB\-\-help\fR" 4
.IX Item "--help"
Print a summary of command line options.
.IP "\fB\-\-version\fR" 4
.IX Item "--version"
This option will cause \fBllvmc\fR to print out its version number and terminate.
.Sh "Advanced Options"
.IX Subsection "Advanced Options"
You better know what you're doing if you use these options. Improper use
of these options can produce drastically wrong results.
.IP "\fB\-\-config\-dir\fR \fIdirname\fR" 4
.IX Item "--config-dir dirname"
This option tells \fBllvmc\fR to read configuration data from the \fIdirectory\fR
named \fIdirname\fR. Data from such directories will be read in the order
specified on the command line after all other standard configuration files have
been read. This allows users or groups of users to conveniently create
their own configuration directories in addition to the standard ones to which
they may not have write access.
.Sh "Unimplemented Options"
.IX Subsection "Unimplemented Options"
The options below are not currently implemented in \fBllvmc\fR but will be
eventually. They are documented here as \*(L"future design\*(R".
.IP "\fB\-\-show\-config\fR \fI[suffixes...]\fR" 4
.IX Item "--show-config [suffixes...]"
When this option is given, the only action taken by \fBllvmc\fR is to show its
final configuration state in the form of a configuration file. No compilation
tasks will be conducted when this option is given; processing will stop once
the configuration has been printed. The optional (comma separated) list of
suffixes controls what is printed. Without any suffixes, the configuration
for all languages is printed. With suffixes, only the languages pertaining
to those file suffixes will be printed. The configuration information is
printed after all command line options and configuration files have been
read and processed. This allows the user to verify that the correct
configuration data has been read by \fBllvmc\fR.
.IP "\fB\-\-config\fR :\fIsection\fR:\fIname\fR=\fIvalue\fR" 4
.IX Item "--config :section:name=value"
This option instructs \fBllvmc\fR to accept \fIvalue\fR as the value for configuration
item \fIname\fR in the section named \fIsection\fR. This is a quick way to override
a configuration item on the command line without resorting to changing the
configuration files.
.IP "\fB\-\-config\-only\-from\fR \fIdirname\fR" 4
.IX Item "--config-only-from dirname"
This option tells \fBllvmc\fR to skip the normal processing of configuration
files and only configure from the contents of the \fIdirname\fR directory. Multiple
\&\fB\-\-config\-only\-from\fR options may be given in which case the directories are
read in the order given on the command line.
.IP "\fB\-\-emit\-raw\-code\fR" 4
.IX Item "--emit-raw-code"
No optimization is done whatsoever. The compilers invoked by \fBllvmc\fR with
this option given will be instructed to produce raw, unoptimized code. This
option is useful only to front end language developers and therefore does not
participate in the list of \fB\-O\fR options. This is distinctly different from
the \fB\-O0\fR option (a synonym for \fB\-O1\fR) because those optimizations will
reduce code size to make compilation faster. With \fB\-\-emit\-raw\-code\fR, only
the full raw code produced by the compiler will be generated.
.SH "EXIT STATUS"
.IX Header "EXIT STATUS"
If \fBllvmc\fR succeeds, it will exit with 0. Otherwise, if an error
occurs, it will exit with a non-zero value and no compilation actions
will be taken. If one of the compilation tools returns a non-zero
status, pending actions will be discarded and \fBllvmc\fR will return the
same result code as the failing compilation tool.
.SH "DEFICIENCIES"
.IX Header "DEFICIENCIES"
\&\fBllvmc\fR is considered an experimental \s-1LLVM\s0 tool because it has these
deficiencies:
.IP "Insufficient support for native linking" 4
.IX Item "Insufficient support for native linking"
Because \fBllvm-ld\fR doesn't handle native linking, neither can \fBllvmc\fR
.IP "Poor configuration support" 4
.IX Item "Poor configuration support"
The support for configuring new languages, etc. is weak. There are many
command line configurations that cannot be achieved with the current
support. Furthermore the grammar is cumbersome for configuration files.
Please see <http://llvm.org/PR686> for further details.
.IP "Does not handle target specific configurations" 4
.IX Item "Does not handle target specific configurations"
This is one of the major deficiencies, also addressed in
<http://llvm.org/PR686>
.SH "SEE ALSO"
.IX Header "SEE ALSO"
llvm-as, llvm-dis, llc, llvm-link
.SH "AUTHORS"
.IX Header "AUTHORS"
Maintained by the \s-1LLVM\s0 Team (<http://llvm.org>).

View File

@@ -1,194 +0,0 @@
.\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.14
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sh \" Subsection heading
.br
.if t .Sp
.ne 5
.PP
\fB\\$1\fR
.PP
..
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings. \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote. | will give a
.\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used to
.\" do unbreakable dashes and therefore won't be available. \*(C` and \*(C'
.\" expand to `' in nroff, nothing in troff, for use with C<>.
.tr \(*W-|\(bv\*(Tr
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
. ds -- \(*W-
. ds PI pi
. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
. ds L" ""
. ds R" ""
. ds C` ""
. ds C' ""
'br\}
.el\{\
. ds -- \|\(em\|
. ds PI \(*p
. ds L" ``
. ds R" ''
'br\}
.\"
.\" If the F register is turned on, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
.\" entries marked with X<> in POD. Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.if \nF \{\
. de IX
. tm Index:\\$1\t\\n%\t"\\$2"
..
. nr % 0
. rr F
.\}
.\"
.\" For nroff, turn off justification. Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.hy 0
.if n .na
.\"
.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
.\" Fear. Run. Save yourself. No user-serviceable parts.
. \" fudge factors for nroff and troff
.if n \{\
. ds #H 0
. ds #V .8m
. ds #F .3m
. ds #[ \f1
. ds #] \fP
.\}
.if t \{\
. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
. ds #V .6m
. ds #F 0
. ds #[ \&
. ds #] \&
.\}
. \" simple accents for nroff and troff
.if n \{\
. ds ' \&
. ds ` \&
. ds ^ \&
. ds , \&
. ds ~ ~
. ds /
.\}
.if t \{\
. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
.\}
. \" troff and (daisy-wheel) nroff accents
.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
.ds ae a\h'-(\w'a'u*4/10)'e
.ds Ae A\h'-(\w'A'u*4/10)'E
. \" corrections for vroff
.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
. \" for low resolution devices (crt and lpr)
.if \n(.H>23 .if \n(.V>19 \
\{\
. ds : e
. ds 8 ss
. ds o a
. ds d- d\h'-1'\(ga
. ds D- D\h'-1'\(hy
. ds th \o'bp'
. ds Th \o'LP'
. ds ae ae
. ds Ae AE
.\}
.rm #[ #] #H #V #F C
.\" ========================================================================
.\"
.IX Title "LLVMGCC 1"
.TH LLVMGCC 1 "2007-02-11" "CVS" "LLVM Command Guide"
.SH "NAME"
llvm\-gcc \- LLVM C front\-end
.SH "SYNOPSIS"
.IX Header "SYNOPSIS"
\&\fBllvm-gcc\fR [\fIoptions\fR] \fIfilename\fR
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
The \fBllvm-gcc\fR command is the \s-1LLVM\s0 C front end. It is a modified
version of gcc that compiles C/ObjC programs into native objects, \s-1LLVM\s0
bytecode or \s-1LLVM\s0 assembly language, depending upon the options.
.PP
By default, \fBllvm-gcc\fR compiles to native objects just like \s-1GCC\s0 does. If the
\&\fB\-emit\-llvm\fR option is given then it will generate \s-1LLVM\s0 bytecode files instead.
If \fB\-S\fR (assembly) is also given, then it will generate \s-1LLVM\s0 assembly.
.PP
Being derived from the \s-1GNU\s0 Compiler Collection, \fBllvm-gcc\fR has many
of gcc's features and accepts most of gcc's options. It handles a
number of gcc's extensions to the C programming language.
.SH "OPTIONS"
.IX Header "OPTIONS"
.IP "\fB\-\-help\fR" 4
.IX Item "--help"
Print a summary of command line options.
.IP "\fB\-S\fR" 4
.IX Item "-S"
Do not generate an \s-1LLVM\s0 bytecode file. Rather, compile the source
file into an \s-1LLVM\s0 assembly language file.
.IP "\fB\-c\fR" 4
.IX Item "-c"
Do not generate a linked executable. Rather, compile the source
file into an \s-1LLVM\s0 bytecode file. This bytecode file can then be
linked with other bytecode files later on to generate a full \s-1LLVM\s0
executable.
.IP "\fB\-o\fR \fIfilename\fR" 4
.IX Item "-o filename"
Specify the output file to be \fIfilename\fR.
.IP "\fB\-I\fR \fIdirectory\fR" 4
.IX Item "-I directory"
Add a directory to the header file search path. This option can be
repeated.
.IP "\fB\-L\fR \fIdirectory\fR" 4
.IX Item "-L directory"
Add \fIdirectory\fR to the library search path. This option can be
repeated.
.IP "\fB\-l\fR\fIname\fR" 4
.IX Item "-lname"
Link in the library lib\fIname\fR.[bc | a | so]. This library should
be a bytecode library.
.IP "\fB\-emit\-llvm\fR" 4
.IX Item "-emit-llvm"
Make the output be \s-1LLVM\s0 bytecode (or assembly) instead of native object (or
assembly).
.SH "EXIT STATUS"
.IX Header "EXIT STATUS"
If \fBllvm-gcc\fR succeeds, it will exit with 0. Otherwise, if an error
occurs, it will exit with a non-zero value.
.SH "SEE ALSO"
.IX Header "SEE ALSO"
llvm\-g++
.SH "AUTHORS"
.IX Header "AUTHORS"
Maintained by the \s-1LLVM\s0 Team (<http://llvm.org>).

View File

@@ -1,194 +0,0 @@
.\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.14
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sh \" Subsection heading
.br
.if t .Sp
.ne 5
.PP
\fB\\$1\fR
.PP
..
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings. \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote. | will give a
.\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used to
.\" do unbreakable dashes and therefore won't be available. \*(C` and \*(C'
.\" expand to `' in nroff, nothing in troff, for use with C<>.
.tr \(*W-|\(bv\*(Tr
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
. ds -- \(*W-
. ds PI pi
. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
. ds L" ""
. ds R" ""
. ds C` ""
. ds C' ""
'br\}
.el\{\
. ds -- \|\(em\|
. ds PI \(*p
. ds L" ``
. ds R" ''
'br\}
.\"
.\" If the F register is turned on, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
.\" entries marked with X<> in POD. Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.if \nF \{\
. de IX
. tm Index:\\$1\t\\n%\t"\\$2"
..
. nr % 0
. rr F
.\}
.\"
.\" For nroff, turn off justification. Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.hy 0
.if n .na
.\"
.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
.\" Fear. Run. Save yourself. No user-serviceable parts.
. \" fudge factors for nroff and troff
.if n \{\
. ds #H 0
. ds #V .8m
. ds #F .3m
. ds #[ \f1
. ds #] \fP
.\}
.if t \{\
. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
. ds #V .6m
. ds #F 0
. ds #[ \&
. ds #] \&
.\}
. \" simple accents for nroff and troff
.if n \{\
. ds ' \&
. ds ` \&
. ds ^ \&
. ds , \&
. ds ~ ~
. ds /
.\}
.if t \{\
. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
.\}
. \" troff and (daisy-wheel) nroff accents
.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
.ds ae a\h'-(\w'a'u*4/10)'e
.ds Ae A\h'-(\w'A'u*4/10)'E
. \" corrections for vroff
.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
. \" for low resolution devices (crt and lpr)
.if \n(.H>23 .if \n(.V>19 \
\{\
. ds : e
. ds 8 ss
. ds o a
. ds d- d\h'-1'\(ga
. ds D- D\h'-1'\(hy
. ds th \o'bp'
. ds Th \o'LP'
. ds ae ae
. ds Ae AE
.\}
.rm #[ #] #H #V #F C
.\" ========================================================================
.\"
.IX Title "LLVMGXX 1"
.TH LLVMGXX 1 "2007-02-11" "CVS" "LLVM Command Guide"
.SH "NAME"
llvm\-g++ \- LLVM C++ front\-end
.SH "SYNOPSIS"
.IX Header "SYNOPSIS"
\&\fBllvm\-g++\fR [\fIoptions\fR] \fIfilename\fR
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
The \fBllvm\-g++\fR command is the \s-1LLVM\s0 \*(C+ front end. It is a modified
version of g++ that compiles \*(C+/ObjC++ programs into native code,
\&\s-1LLVM\s0 bytecode or assembly language, depending upon the options.
.PP
By default, \fBllvm\-g++\fR compiles to native objects just like \s-1GCC\s0 does. If the
\&\fB\-emit\-llvm\fR option is given then it will generate \s-1LLVM\s0 bytecode files instead.
If \fB\-S\fR (assembly) is also given, then it will generate \s-1LLVM\s0 assembly.
.PP
Being derived from the \s-1GNU\s0 Compiler Collection, \fBllvm\-g++\fR has many
of g++'s features and accepts most of g++'s options. It handles a
number of g++'s extensions to the \*(C+ programming language.
.SH "OPTIONS"
.IX Header "OPTIONS"
.IP "\fB\-\-help\fR" 4
.IX Item "--help"
Print a summary of command line options.
.IP "\fB\-S\fR" 4
.IX Item "-S"
Do not generate an \s-1LLVM\s0 bytecode file. Rather, compile the source
file into an \s-1LLVM\s0 assembly language file.
.IP "\fB\-c\fR" 4
.IX Item "-c"
Do not generate a linked executable. Rather, compile the source
file into an \s-1LLVM\s0 bytecode file. This bytecode file can then be
linked with other bytecode files later on to generate a full \s-1LLVM\s0
executable.
.IP "\fB\-o\fR \fIfilename\fR" 4
.IX Item "-o filename"
Specify the output file to be \fIfilename\fR.
.IP "\fB\-I\fR \fIdirectory\fR" 4
.IX Item "-I directory"
Add a directory to the header file search path. This option can be
repeated.
.IP "\fB\-L\fR \fIdirectory\fR" 4
.IX Item "-L directory"
Add \fIdirectory\fR to the library search path. This option can be
repeated.
.IP "\fB\-l\fR\fIname\fR" 4
.IX Item "-lname"
Link in the library lib\fIname\fR.[bc | a | so]. This library should
be a bytecode library.
.IP "\fB\-emit\-llvm\fR" 4
.IX Item "-emit-llvm"
Make the output be \s-1LLVM\s0 bytecode (or assembly) instead of native object (or
assembly).
.SH "EXIT STATUS"
.IX Header "EXIT STATUS"
If \fBllvm\-g++\fR succeeds, it will exit with 0. Otherwise, if an error
occurs, it will exit with a non-zero value.
.SH "SEE ALSO"
.IX Header "SEE ALSO"
llvm-gcc
.SH "AUTHORS"
.IX Header "AUTHORS"
Maintained by the \s-1LLVM\s0 Team (<http://llvm.org>).

View File

@@ -1,246 +0,0 @@
.\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.14
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sh \" Subsection heading
.br
.if t .Sp
.ne 5
.PP
\fB\\$1\fR
.PP
..
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings. \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote. | will give a
.\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used to
.\" do unbreakable dashes and therefore won't be available. \*(C` and \*(C'
.\" expand to `' in nroff, nothing in troff, for use with C<>.
.tr \(*W-|\(bv\*(Tr
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
. ds -- \(*W-
. ds PI pi
. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
. ds L" ""
. ds R" ""
. ds C` ""
. ds C' ""
'br\}
.el\{\
. ds -- \|\(em\|
. ds PI \(*p
. ds L" ``
. ds R" ''
'br\}
.\"
.\" If the F register is turned on, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
.\" entries marked with X<> in POD. Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.if \nF \{\
. de IX
. tm Index:\\$1\t\\n%\t"\\$2"
..
. nr % 0
. rr F
.\}
.\"
.\" For nroff, turn off justification. Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.hy 0
.if n .na
.\"
.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
.\" Fear. Run. Save yourself. No user-serviceable parts.
. \" fudge factors for nroff and troff
.if n \{\
. ds #H 0
. ds #V .8m
. ds #F .3m
. ds #[ \f1
. ds #] \fP
.\}
.if t \{\
. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
. ds #V .6m
. ds #F 0
. ds #[ \&
. ds #] \&
.\}
. \" simple accents for nroff and troff
.if n \{\
. ds ' \&
. ds ` \&
. ds ^ \&
. ds , \&
. ds ~ ~
. ds /
.\}
.if t \{\
. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
.\}
. \" troff and (daisy-wheel) nroff accents
.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
.ds ae a\h'-(\w'a'u*4/10)'e
.ds Ae A\h'-(\w'A'u*4/10)'E
. \" corrections for vroff
.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
. \" for low resolution devices (crt and lpr)
.if \n(.H>23 .if \n(.V>19 \
\{\
. ds : e
. ds 8 ss
. ds o a
. ds d- d\h'-1'\(ga
. ds D- D\h'-1'\(hy
. ds th \o'bp'
. ds Th \o'LP'
. ds ae ae
. ds Ae AE
.\}
.rm #[ #] #H #V #F C
.\" ========================================================================
.\"
.IX Title "OPT 1"
.TH OPT 1 "2007-02-02" "CVS" "LLVM Command Guide"
.SH "NAME"
opt \- LLVM optimizer
.SH "SYNOPSIS"
.IX Header "SYNOPSIS"
\&\fBopt\fR [\fIoptions\fR] [\fIfilename\fR]
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
The \fBopt\fR command is the modular \s-1LLVM\s0 optimizer and analyzer. It takes \s-1LLVM\s0
bytecode as input, runs the specified optimizations or analyses on it, and then
outputs the optimized \s-1LLVM\s0 bytecode or the analysis results. The function of
\&\fBopt\fR depends on whether the \fB\-analyze\fR option is given.
.PP
When \fB\-analyze\fR is specified, \fBopt\fR performs various analyses of \s-1LLVM\s0
bytecode. It will usually print the results on standard output, but in a few
cases, it will print output to standard error or generate a file with the
analysis output, which is usually done when the output is meant for another
program.
.PP
While \fB\-analyze\fR is \fInot\fR given, \fBopt\fR attempts to produce an optimized
bytecode file. The optimizations available via \fBopt\fR depend upon what
libraries were linked into it as well as any additional libraries that have
been loaded with the \fB\-load\fR option. Use the \fB\-help\fR option to determine
what optimizations you can use.
.PP
If \fIfilename\fR is omitted from the command line or is \fI\-\fR, \fBopt\fR reads its
input from standard input. The input must be an \s-1LLVM\s0 bytecode file.
.PP
If an output filename is not specified with the \fB\-o\fR option, \fBopt\fR
writes its output to the standard output.
.SH "OPTIONS"
.IX Header "OPTIONS"
.IP "\fB\-f\fR" 4
.IX Item "-f"
Force overwrite. Normally, \fBopt\fR will refuse to overwrite an
output file that already exists. With this option, \fBopt\fR will
overwrite the output file and replace it with new bytecode.
.IP "\fB\-help\fR" 4
.IX Item "-help"
Print a summary of command line options.
.IP "\fB\-o\fR \fIfilename\fR" 4
.IX Item "-o filename"
Specify the output filename.
.IP "\fB\-{passname}\fR" 4
.IX Item "-{passname}"
\&\fBopt\fR provides the ability to run any of \s-1LLVM\s0's optimization or analysis passes
in any order. The \fB\-help\fR option lists all the passes available. The order in
which the options occur on the command line are the order in which they are
executed (within pass constraints).
.IP "\fB\-std\-compile\-opts\fR" 4
.IX Item "-std-compile-opts"
This is short hand for a standard list of \fIcompile time optimization\fR passes.
This is typically used to optimize the output from the llvm-gcc front end. It
might be useful for other front end compilers as well. To discover the full set
of options available, use the following command:
.Sp
.Vb 1
\& llvm-as < /dev/null | opt -std-compile-opts -disable-output -debug-pass=Arguments
.Ve
.IP "\fB\-disable\-inlining\fR" 4
.IX Item "-disable-inlining"
This option is only meaningful when \fB\-std\-compile\-opts\fR is given. It simply
removes the inlining pass from the standard list.
.IP "\fB\-disable\-opt\fR" 4
.IX Item "-disable-opt"
This option is only meaningful when \fB\-std\-compile\-opts\fR is given. It disables
most, but not all, of the \fB\-std\-compile\-opts\fR. The ones that remain are
\&\fB\-verify\fR, \fB\-lower\-setjmp\fR, and \fB\-funcresolve\fR.
.IP "\fB\-strip\-debug\fR" 4
.IX Item "-strip-debug"
This option causes opt to strip debug information from the module before
applying other optimizations. It is essentially the same as \fB\-strip\fR but it
ensures that stripping of debug information is done first.
.IP "\fB\-verify\-each\fR" 4
.IX Item "-verify-each"
This option causes opt to add a verify pass after every pass otherwise specified
on the command line (including \fB\-verify\fR). This is useful for cases where it
is suspected that a pass is creating an invalid module but it is not clear which
pass is doing it. The combination of \fB\-std\-compile\-opts\fR and \fB\-verify\-each\fR
can quickly track down this kind of problem.
.IP "\fB\-profile\-info\-file\fR \fIfilename\fR" 4
.IX Item "-profile-info-file filename"
Specify the name of the file loaded by the \-profile\-loader option.
.IP "\fB\-stats\fR" 4
.IX Item "-stats"
Print statistics.
.IP "\fB\-time\-passes\fR" 4
.IX Item "-time-passes"
Record the amount of time needed for each pass and print it to standard
error.
.IP "\fB\-debug\fR" 4
.IX Item "-debug"
If this is a debug build, this option will enable debug printouts
from passes which use the \fI\s-1\fIDEBUG\s0()\fI\fR macro. See the \fB\s-1LLVM\s0 Programmer's
Manual\fR, section \fI#DEBUG\fR for more information.
.IP "\fB\-load\fR=\fIplugin\fR" 4
.IX Item "-load=plugin"
Load the dynamic object \fIplugin\fR. This object should register new optimization
or analysis passes. Once loaded, the object will add new command line options to
enable various optimizations or analyses. To see the new complete list of
optimizations, use the \fB\-help\fR and \fB\-load\fR options together. For example:
.Sp
.Vb 1
\& opt -load=plugin.so -help
.Ve
.IP "\fB\-p\fR" 4
.IX Item "-p"
Print module after each transformation.
.SH "EXIT STATUS"
.IX Header "EXIT STATUS"
If \fBopt\fR succeeds, it will exit with 0. Otherwise, if an error
occurs, it will exit with a non-zero value.
.SH "AUTHORS"
.IX Header "AUTHORS"
Maintained by the \s-1LLVM\s0 Team (<http://llvm.org>).

View File

@@ -1,198 +0,0 @@
.\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.14
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sh \" Subsection heading
.br
.if t .Sp
.ne 5
.PP
\fB\\$1\fR
.PP
..
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings. \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote. | will give a
.\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used to
.\" do unbreakable dashes and therefore won't be available. \*(C` and \*(C'
.\" expand to `' in nroff, nothing in troff, for use with C<>.
.tr \(*W-|\(bv\*(Tr
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
. ds -- \(*W-
. ds PI pi
. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
. ds L" ""
. ds R" ""
. ds C` ""
. ds C' ""
'br\}
.el\{\
. ds -- \|\(em\|
. ds PI \(*p
. ds L" ``
. ds R" ''
'br\}
.\"
.\" If the F register is turned on, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
.\" entries marked with X<> in POD. Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.if \nF \{\
. de IX
. tm Index:\\$1\t\\n%\t"\\$2"
..
. nr % 0
. rr F
.\}
.\"
.\" For nroff, turn off justification. Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.hy 0
.if n .na
.\"
.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
.\" Fear. Run. Save yourself. No user-serviceable parts.
. \" fudge factors for nroff and troff
.if n \{\
. ds #H 0
. ds #V .8m
. ds #F .3m
. ds #[ \f1
. ds #] \fP
.\}
.if t \{\
. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
. ds #V .6m
. ds #F 0
. ds #[ \&
. ds #] \&
.\}
. \" simple accents for nroff and troff
.if n \{\
. ds ' \&
. ds ` \&
. ds ^ \&
. ds , \&
. ds ~ ~
. ds /
.\}
.if t \{\
. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
.\}
. \" troff and (daisy-wheel) nroff accents
.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
.ds ae a\h'-(\w'a'u*4/10)'e
.ds Ae A\h'-(\w'A'u*4/10)'E
. \" corrections for vroff
.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
. \" for low resolution devices (crt and lpr)
.if \n(.H>23 .if \n(.V>19 \
\{\
. ds : e
. ds 8 ss
. ds o a
. ds d- d\h'-1'\(ga
. ds D- D\h'-1'\(hy
. ds th \o'bp'
. ds Th \o'LP'
. ds ae ae
. ds Ae AE
.\}
.rm #[ #] #H #V #F C
.\" ========================================================================
.\"
.IX Title "STKRC 1"
.TH STKRC 1 "2006-03-13" "CVS" "LLVM Command Guide"
.SH "NAME"
stkrc \- Stacker Compiler
.SH "SYNOPSIS"
.IX Header "SYNOPSIS"
\&\fBstkrc\fR [\fIoptions\fR] [\fIfilename\fR]
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
The \fBstkrc\fR command is the compiler for the Stacker language. Stacker is a
simple stack based, Forth-like language that was written as a demonstration
language for \s-1LLVM\s0. For details on the language, please see
<http://llvm.org/docs/Stacker.html> . The \fBstkrc\fR compiler is fairly
minimal. It compiles to bytecode only and doesn't perform any optimizations.
The output of stkrc (a bytecode file) can be piped through other \s-1LLVM\s0 tools
for optimization and linking.
.PP
If \fIfilename\fR is omitted or is \f(CW\*(C`\-\*(C'\fR, then \fBstkrc\fR reads its input
from standard input. This is useful for combining the tool into a pipeline.
.PP
If an output file is not specified with the \fB\-o\fR option, then
\&\fBllvm-as\fR sends its output to a file or standard output by following
these rules:
.IP "\(bu" 4
If the input is standard input, then the output is standard output.
.IP "\(bu" 4
If the input is a file that ends with \f(CW\*(C`.st\*(C'\fR, then the output file is of
the same name, except that the suffix is changed to \f(CW\*(C`.bc\*(C'\fR.
.IP "\(bu" 4
If the input is a file that does not end with the \f(CW\*(C`.st\*(C'\fR suffix, then the
output file has the same name as the input file, except that the \f(CW\*(C`.bc\*(C'\fR
suffix is appended.
.SH "OPTIONS"
.IX Header "OPTIONS"
.IP "\fB\-o\fR \fIfilename\fR" 4
.IX Item "-o filename"
Specify the output file name. If \fIfilename\fR is \f(CW\*(C`\-\*(C'\fR, then \fBllvm-as\fR
sends its output to standard output.
.IP "\fB\-stats\fR" 4
.IX Item "-stats"
Print statistics acquired during compilation.
.IP "\fB\-time\-passes\fR" 4
.IX Item "-time-passes"
Record the amount of time needed for each pass and print it to standard
error.
.IP "\fB\-f\fR" 4
.IX Item "-f"
Force the output to be written. Normally, \fBstkrc\fR won't overwrite an existing
bytecode file. This option overrides that behavior.
.IP "\fB\-s\fR \fIstacksize\fR" 4
.IX Item "-s stacksize"
Specify the stack size for the program. The default stack size, 1024, should be
sufficient for most programs. For very large programs, especially those that
recurse a lot, you might want to provide a larger value. Each unit of this
value consumes 8 bytes of memory.
.IP "\fB\-help\fR" 4
.IX Item "-help"
Print a summary of command line options.
.SH "EXIT STATUS"
.IX Header "EXIT STATUS"
If \fBstkrc\fR succeeds, it will exit with 0. Otherwise, if an error
occurs, it will exit with a non-zero value, usually 1.
.SH "SEE ALSO"
.IX Header "SEE ALSO"
llvm-as, <http://llvm.org/docs/Stacker.html>
.SH "AUTHORS"
.IX Header "AUTHORS"
Maintained by the \s-1LLVM\s0 Team (<http://llvm.org>).

View File

@@ -1,215 +0,0 @@
.\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.14
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sh \" Subsection heading
.br
.if t .Sp
.ne 5
.PP
\fB\\$1\fR
.PP
..
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings. \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote. | will give a
.\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used to
.\" do unbreakable dashes and therefore won't be available. \*(C` and \*(C'
.\" expand to `' in nroff, nothing in troff, for use with C<>.
.tr \(*W-|\(bv\*(Tr
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
. ds -- \(*W-
. ds PI pi
. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
. ds L" ""
. ds R" ""
. ds C` ""
. ds C' ""
'br\}
.el\{\
. ds -- \|\(em\|
. ds PI \(*p
. ds L" ``
. ds R" ''
'br\}
.\"
.\" If the F register is turned on, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
.\" entries marked with X<> in POD. Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.if \nF \{\
. de IX
. tm Index:\\$1\t\\n%\t"\\$2"
..
. nr % 0
. rr F
.\}
.\"
.\" For nroff, turn off justification. Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.hy 0
.if n .na
.\"
.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
.\" Fear. Run. Save yourself. No user-serviceable parts.
. \" fudge factors for nroff and troff
.if n \{\
. ds #H 0
. ds #V .8m
. ds #F .3m
. ds #[ \f1
. ds #] \fP
.\}
.if t \{\
. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
. ds #V .6m
. ds #F 0
. ds #[ \&
. ds #] \&
.\}
. \" simple accents for nroff and troff
.if n \{\
. ds ' \&
. ds ` \&
. ds ^ \&
. ds , \&
. ds ~ ~
. ds /
.\}
.if t \{\
. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
.\}
. \" troff and (daisy-wheel) nroff accents
.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
.ds ae a\h'-(\w'a'u*4/10)'e
.ds Ae A\h'-(\w'A'u*4/10)'E
. \" corrections for vroff
.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
. \" for low resolution devices (crt and lpr)
.if \n(.H>23 .if \n(.V>19 \
\{\
. ds : e
. ds 8 ss
. ds o a
. ds d- d\h'-1'\(ga
. ds D- D\h'-1'\(hy
. ds th \o'bp'
. ds Th \o'LP'
. ds ae ae
. ds Ae AE
.\}
.rm #[ #] #H #V #F C
.\" ========================================================================
.\"
.IX Title "TBLGEN 1"
.TH TBLGEN 1 "2006-06-02" "CVS" "LLVM Command Guide"
.SH "NAME"
tblgen \- Target Description To C++ Code Generator
.SH "SYNOPSIS"
.IX Header "SYNOPSIS"
\&\fBtblgen\fR [\fIoptions\fR] [\fIfilename\fR]
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
\&\fBtblgen\fR translates from target description (.td) files into \*(C+ code that can
be included in the definition of an \s-1LLVM\s0 target library. Most users of \s-1LLVM\s0 will
not need to use this program. It is only for assisting with writing an \s-1LLVM\s0
target backend.
.PP
The input and output of \fBtblgen\fR is beyond the scope of this short
introduction. Please see the \fICodeGeneration\fR page in the \s-1LLVM\s0 documentation.
.PP
The \fIfilename\fR argument specifies the name of a Target Description (.td) file
to read as input.
.SH "OPTIONS"
.IX Header "OPTIONS"
.IP "\fB\-\-help\fR" 4
.IX Item "--help"
Print a summary of command line options.
.IP "\fB\-o\fR \fIfilename\fR" 4
.IX Item "-o filename"
Specify the output file name. If \fIfilename\fR is \f(CW\*(C`\-\*(C'\fR, then \fBtblgen\fR
sends its output to standard output.
.IP "\fB\-I\fR \fIdirectory\fR" 4
.IX Item "-I directory"
Specify where to find other target description files for inclusion. The
\&\fIdirectory\fR value should be a full or partial path to a directory that contains
target description files.
.IP "\fB\-asmwriternum\fR \fIN\fR" 4
.IX Item "-asmwriternum N"
Make \-gen\-asm\-writer emit assembly writer number \fIN\fR.
.IP "\fB\-class\fR \fIclass Name\fR" 4
.IX Item "-class class Name"
Print the enumeration list for this class.
.IP "\fB\-print\-records\fR" 4
.IX Item "-print-records"
Print all records to standard output (default).
.IP "\fB\-print\-enums\fR" 4
.IX Item "-print-enums"
Print enumeration values for a class
.IP "\fB\-gen\-emitter\fR" 4
.IX Item "-gen-emitter"
Generate machine code emitter.
.IP "\fB\-gen\-register\-enums\fR" 4
.IX Item "-gen-register-enums"
Generate the enumeration values for all registers.
.IP "\fB\-gen\-register\-desc\fR" 4
.IX Item "-gen-register-desc"
Generate a register info description for each register.
.IP "\fB\-gen\-register\-desc\-header\fR" 4
.IX Item "-gen-register-desc-header"
Generate a register info description header for each register.
.IP "\fB\-gen\-instr\-enums\fR" 4
.IX Item "-gen-instr-enums"
Generate enumeration values for instructions.
.IP "\fB\-gen\-instr\-desc\fR" 4
.IX Item "-gen-instr-desc"
Generate instruction descriptions.
.IP "\fB\-gen\-asm\-writer\fR" 4
.IX Item "-gen-asm-writer"
Generate the assembly writer.
.IP "\fB\-gen\-dag\-isel\fR" 4
.IX Item "-gen-dag-isel"
Generate a \s-1DAG\s0 (Directed Acycle Graph) instruction selector.
.IP "\fB\-gen\-subtarget\fR" 4
.IX Item "-gen-subtarget"
Generate subtarget enumerations.
.IP "\fB\-gen\-intrinsic\fR" 4
.IX Item "-gen-intrinsic"
Generate intrinsic information.
.IP "\fB\-version\fR" 4
.IX Item "-version"
Show the version number of this program.
.SH "EXIT STATUS"
.IX Header "EXIT STATUS"
If \fBtblgen\fR succeeds, it will exit with 0. Otherwise, if an error
occurs, it will exit with a non-zero value.
.SH "AUTHORS"
.IX Header "AUTHORS"
Maintained by The \s-1LLVM\s0 Team (<http://llvm.org>).

View File

@@ -10,25 +10,17 @@ B<opt> [I<options>] [I<filename>]
=head1 DESCRIPTION
The B<opt> command is the modular LLVM optimizer and analyzer. It takes LLVM
bytecode as input, runs the specified optimizations or analyses on it, and then
outputs the optimized LLVM bytecode or the analysis results. The function of
B<opt> depends on whether the B<-analyze> option is given.
The B<opt> command is the modular LLVM optimizer. It takes LLVM
bytecode as input, runs the specified optimizations on it, and then
outputs the optimized LLVM bytecode.
When B<-analyze> is specified, B<opt> performs various analyses of LLVM
bytecode. It will usually print the results on standard output, but in a few
cases, it will print output to standard error or generate a file with the
analysis output, which is usually done when the output is meant for another
program.
The optimizations available via B<opt> depend upon what libraries
were linked into it as well as any additional libraries that have
been loaded with the B<-load> option. Use the B<-help> option to
determine what optimizations you can use.
While B<-analyze> is I<not> given, B<opt> attempts to produce an optimized
bytecode file. The optimizations available via B<opt> depend upon what
libraries were linked into it as well as any additional libraries that have
been loaded with the B<-load> option. Use the B<-help> option to determine
what optimizations you can use.
If I<filename> is omitted from the command line or is I<->, B<opt> reads its
input from standard input. The input must be an LLVM bytecode file.
If no filename is specified on the command line, B<opt> reads its
input from standard input.
If an output filename is not specified with the B<-o> option, B<opt>
writes its output to the standard output.
@@ -45,53 +37,12 @@ overwrite the output file and replace it with new bytecode.
=item B<-help>
Print a summary of command line options.
Print a summary of command line options.
=item B<-o> I<filename>
Specify the output filename.
=item B<-{passname}>
B<opt> provides the ability to run any of LLVM's optimization or analysis passes
in any order. The B<-help> option lists all the passes available. The order in
which the options occur on the command line are the order in which they are
executed (within pass constraints).
=item B<-std-compile-opts>
This is short hand for a standard list of I<compile time optimization> passes.
This is typically used to optimize the output from the llvm-gcc front end. It
might be useful for other front end compilers as well. To discover the full set
of options available, use the following command:
llvm-as < /dev/null | opt -std-compile-opts -disable-output -debug-pass=Arguments
=item B<-disable-inlining>
This option is only meaningful when B<-std-compile-opts> is given. It simply
removes the inlining pass from the standard list.
=item B<-disable-opt>
This option is only meaningful when B<-std-compile-opts> is given. It disables
most, but not all, of the B<-std-compile-opts>. The ones that remain are
B<-verify>, B<-lower-setjmp>, and B<-funcresolve>.
=item B<-strip-debug>
This option causes opt to strip debug information from the module before
applying other optimizations. It is essentially the same as B<-strip> but it
ensures that stripping of debug information is done first.
=item B<-verify-each>
This option causes opt to add a verify pass after every pass otherwise specified
on the command line (including B<-verify>). This is useful for cases where it
is suspected that a pass is creating an invalid module but it is not clear which
pass is doing it. The combination of B<-std-compile-opts> and B<-verify-each>
can quickly track down this kind of problem.
=item B<-profile-info-file> I<filename>
Specify the name of the file loaded by the -profile-loader option.
@@ -113,12 +64,16 @@ Manual>, section I<#DEBUG> for more information.
=item B<-load>=I<plugin>
Load the dynamic object I<plugin>. This object should register new optimization
or analysis passes. Once loaded, the object will add new command line options to
enable various optimizations or analyses. To see the new complete list of
optimizations, use the B<-help> and B<-load> options together. For example:
Load the dynamic object I<plugin>. This object should register new
optimization passes. Once loaded, the object will add new command line
options to enable various optimizations. To see the new complete list
of optimizations, use the B<-help> and B<-load> options together:
opt -load=plugin.so -help
=over
B<opt -load>=I<plugin> B<-help>
=back
=item B<-p>
@@ -131,8 +86,12 @@ Print module after each transformation.
If B<opt> succeeds, it will exit with 0. Otherwise, if an error
occurs, it will exit with a non-zero value.
=head1 SEE ALSO
L<analyze|analyze>
=head1 AUTHORS
Maintained by the LLVM Team (L<http://llvm.org>).
Maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
=cut

View File

@@ -13,7 +13,7 @@ B<stkrc> [I<options>] [I<filename>]
The B<stkrc> command is the compiler for the Stacker language. Stacker is a
simple stack based, Forth-like language that was written as a demonstration
language for LLVM. For details on the language, please see
L<http://llvm.org/docs/Stacker.html> . The B<stkrc> compiler is fairly
L<http://llvm.cs.uiuc.edu/docs/Stacker.html> . The B<stkrc> compiler is fairly
minimal. It compiles to bytecode only and doesn't perform any optimizations.
The output of stkrc (a bytecode file) can be piped through other LLVM tools
for optimization and linking.
@@ -87,10 +87,10 @@ occurs, it will exit with a non-zero value, usually 1.
=head1 SEE ALSO
L<llvm-as>, L<http://llvm.org/docs/Stacker.html>
L<llvm-as>, L<http://llvm.cs.uiuc.edu/docs/Stacker.html>
=head1 AUTHORS
Maintained by the LLVM Team (L<http://llvm.org>).
Maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
=cut

View File

@@ -1,115 +0,0 @@
=pod
=head1 NAME
tblgen - Target Description To C++ Code Generator
=head1 SYNOPSIS
B<tblgen> [I<options>] [I<filename>]
=head1 DESCRIPTION
B<tblgen> translates from target description (.td) files into C++ code that can
be included in the definition of an LLVM target library. Most users of LLVM will
not need to use this program. It is only for assisting with writing an LLVM
target backend.
The input and output of B<tblgen> is beyond the scope of this short
introduction. Please see the I<CodeGeneration> page in the LLVM documentation.
The F<filename> argument specifies the name of a Target Description (.td) file
to read as input.
=head1 OPTIONS
=over
=item B<--help>
Print a summary of command line options.
=item B<-o> F<filename>
Specify the output file name. If F<filename> is C<->, then B<tblgen>
sends its output to standard output.
=item B<-I> F<directory>
Specify where to find other target description files for inclusion. The
F<directory> value should be a full or partial path to a directory that contains
target description files.
=item B<-asmwriternum> F<N>
Make -gen-asm-writer emit assembly writer number F<N>.
=item B<-class> F<class Name>
Print the enumeration list for this class.
=item B<-print-records>
Print all records to standard output (default).
=item B<-print-enums>
Print enumeration values for a class
=item B<-gen-emitter>
Generate machine code emitter.
=item B<-gen-register-enums>
Generate the enumeration values for all registers.
=item B<-gen-register-desc>
Generate a register info description for each register.
=item B<-gen-register-desc-header>
Generate a register info description header for each register.
=item B<-gen-instr-enums>
Generate enumeration values for instructions.
=item B<-gen-instr-desc>
Generate instruction descriptions.
=item B<-gen-asm-writer>
Generate the assembly writer.
=item B<-gen-dag-isel>
Generate a DAG (Directed Acycle Graph) instruction selector.
=item B<-gen-subtarget>
Generate subtarget enumerations.
=item B<-gen-intrinsic>
Generate intrinsic information.
=item B<-version>
Show the version number of this program.
=back
=head1 EXIT STATUS
If B<tblgen> succeeds, it will exit with 0. Otherwise, if an error
occurs, it will exit with a non-zero value.
=head1 AUTHORS
Maintained by The LLVM Team (L<http://llvm.org>).
=cut

View File

@@ -60,8 +60,6 @@
<tt>cl::ParseCommandLineOptions</tt> function</a></li>
<li><a href="#cl::ParseEnvironmentOptions">The
<tt>cl::ParseEnvironmentOptions</tt> function</a></li>
<li><a href="#cl::SetVersionPrinter">The cl::SetVersionPrinter
function</a></li>
<li><a href="#cl::opt">The <tt>cl::opt</tt> class</a></li>
<li><a href="#cl::list">The <tt>cl::list</tt> class</a></li>
<li><a href="#cl::bits">The <tt>cl::bits</tt> class</a></li>
@@ -197,7 +195,7 @@ can do.</p>
program:</p>
<div class="doc_code"><pre>
#include "llvm/Support/CommandLine.h"
#include "Support/CommandLine.h"
</pre></div>
<p>Additionally, you need to add this as the first line of your main
@@ -1042,7 +1040,7 @@ extern bool DebugFlag;
// debug build, then the code specified as the option to the macro will be
// executed. Otherwise it will not be. Example:
//
// DOUT &lt;&lt; "Bitset contains: " &lt;&lt; Bitset &lt;&lt; "\n";
// DEBUG(std::cerr &lt;&lt; "Bitset contains: " &lt;&lt; Bitset &lt;&lt; "\n");
//</i>
<span class="doc_hilite">#ifdef NDEBUG
#define DEBUG(X)
@@ -1507,27 +1505,6 @@ input.</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<a name="cl::SetVersionPrinter">The <tt>cl::SetVersionPrinter</tt>
function</a>
</div>
<div class="doc_text">
<p>The <tt>cl::SetVersionPrinter</tt> function is designed to be called
directly from <tt>main</tt>, and <i>before</i>
<tt>cl::ParseCommandLineOptions</tt>. Its use is optional. It simply arranges
for a function to be called in response to the <tt>--version</tt> option instead
of having the <tt>CommandLine</tt> library print out the usual version string
for LLVM. This is useful for programs that are not part of LLVM but wish to use
the <tt>CommandLine</tt> facilities. Such programs should just define a small
function that takes no arguments and returns <tt>void</tt> and that prints out
whatever version information is appropriate for the program. Pass the address
of that function to <tt>cl::SetVersionPrinter</tt> to arrange for it to be
called when the <tt>--version</tt> option is given by the user.</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<a name="cl::opt">The <tt>cl::opt</tt> class</a>
@@ -1763,7 +1740,7 @@ your custom data type.<p>
<p>This approach has the advantage that users of your custom data type will
automatically use your custom parser whenever they define an option with a value
type of your data type. The disadvantage of this approach is that it doesn't
work if your fundamental data type is something that is already supported.</p>
work if your fundemental data type is something that is already supported.</p>
</li>
@@ -1922,7 +1899,7 @@ tutorial.</p>
src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"></a>
<a href="mailto:sabre@nondot.org">Chris Lattner</a><br>
<a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
<a href="http://llvm.cs.uiuc.edu">LLVM Compiler Infrastructure</a><br>
Last modified: $Date$
</address>

View File

@@ -814,7 +814,7 @@ optimization.</p>
href="http://validator.w3.org/check/referer"><img
src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"></a><a
href="mailto:rspencer@x10sys.com">Reid Spencer</a><br>
<a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br>
<a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a><br>
Last modified: $Date$
</address>
<!-- vim: sw=2

View File

@@ -63,7 +63,6 @@ href="http://ftp.digital.com/pub/Digital/info/semiconductor/literature/dsc-libra
<li><a href="http://www.arm.com/documentation/">ARM documentation</a>
(<a href="http://www.arm.com/documentation/ARMProcessor_Cores/">Processor
Cores</a>)</li>
<li><a href="http://www.arm.com/products/DevTools/ABI.html">ABI</a></li>
</ul>
</div>
@@ -253,7 +252,7 @@ processors.</li>
src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"></a>
<a href="http://misha.brukman.net">Misha Brukman</a><br>
<a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
<a href="http://llvm.cs.uiuc.edu">LLVM Compiler Infrastructure</a><br>
Last modified: $Date$
</address>

View File

@@ -1,505 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>LLVM Developer Policy</title>
<link rel="stylesheet" href="llvm.css" type="text/css">
</head>
<body>
<div class="doc_title">LLVM Developer Policy</div>
<ol>
<li><a href="#introduction">Introduction</a></li>
<li><a href="#policies">Developer Policies</a>
<ol>
<li><a href="#informed">Stay Informed</a></li>
<li><a href="#patches">Making a Patch</a></li>
<li><a href="#reviews">Code Reviews</a></li>
<li><a href="#testcases">Test Cases</a></li>
<li><a href="#quality">Quality</a></li>
<li><a href="#commitaccess">Obtaining Commit Access</a></li>
<li><a href="#newwork">Making a Major Change</a></li>
<li><a href="#incremental">Incremental Development</a></li>
<li><a href="#attribution">Attribution of Changes</a></li>
</ol></li>
<li><a href="#clp">Copyright, License, and Patents</a>
<ol>
<li><a href="#copyright">Copyright</a></li>
<li><a href="#license">License</a></li>
<li><a href="#patents">Patents</a></li>
<li><a href="#devagree">Developer Agreements</a></li>
</ol></li>
</ol>
<div class="doc_author">Written by the LLVM Oversight Team</div>
<!--=========================================================================-->
<div class="doc_section"><a name="introduction">Introduction</a></div>
<!--=========================================================================-->
<div class="doc_text">
<p>This document contains the LLVM Developer Policy which defines the
project's policy towards developers and their contributions. The intent of
this policy is to eliminate mis-communication, rework, and confusion that
might arise from the distributed nature of LLVM's development. By stating
the policy in clear terms, we hope each developer can know ahead of time
what to expect when making LLVM contributions.</p>
<p>This policy is also designed to accomplish the following objectives:</p>
<ol>
<li>Attract both users and developers to the LLVM project.</li>
<li>Make life as simple and easy for contributors as possible.</li>
<li>Keep the top of tree CVS/SVN trees as stable as possible.</li>
</ol>
<p>This policy is aimed at frequent contributors to LLVM. People interested in
contributing one-off patches can do so in an informal way by sending them to
the <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">
llvm-commits mailing list</a> and engaging another developer to see it through
the process.</p>
</div>
<!--=========================================================================-->
<div class="doc_section"><a name="policies">Developer Policies</a></div>
<!--=========================================================================-->
<div class="doc_text">
<p>This section contains policies that pertain to frequent LLVM
developers. We always welcome <a href="#patches">one-off patches</a> from
people who do not routinely contribute to LLVM, but we expect more from
frequent contributors to keep the system as efficient as possible for
everyone.
Frequent LLVM contributors are expected to meet the following requirements in
order for LLVM to maintain a high standard of quality.<p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsection"> <a name="informed">Stay Informed</a> </div>
<div class="doc_text">
<p>Developers should stay informed by reading at least the
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">llvmdev</a>
email list. If you are doing anything more than just casual work on LLVM,
it is suggested that you also subscribe to the
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">llvm-commits</a>
list and pay attention to changes being made by others.</p>
<p>We recommend that active developers register an email account with
<a href="http://llvm.org/bugs/">LLVM Bugzilla</a> and preferably subscribe to
the <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs">llvm-bugs</a>
email list to keep track of bugs and enhancements occurring in LLVM.</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsection"> <a name="patches">Making a Patch</a></div>
<div class="doc_text">
<p>When making a patch for review, the goal is to make it as easy for the
reviewer to read it as possible. As such, we recommend that you:</p>
<ol>
<li>Make your patch against the CVS HEAD (main development trunk),
not a branch, and not an old version of LLVM. This makes it easy to
apply the patch.</li>
<li>Similarly, patches should be submitted soon after they are generated.
Old patches may not apply correctly if the underlying code changes between
the time the patch was created and the time it is applied.</li>
<li>Patches should be made with this command:
<pre>cvs diff -Ntdup -5</pre>
or with the utility <tt>utils/mkpatch</tt>, which makes it easy to read the
diff.</li>
<li>Patches should not include differences in generated code such as the
code generated by <tt>flex</tt>, <tt>bison</tt> or <tt>tblgen</tt>. The
<tt>utils/mkpatch</tt> utility takes care of this for you.</li>
</ol>
<p>When sending a patch to a mailing list, it is a good idea to send it as an
<em>attachment</em> to the message, not embedded into the text of the
message. This ensures that your mailer will not mangle the patch when it
sends it (e.g. by making whitespace changes or by wrapping lines).</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsection"> <a name="reviews">Code Reviews</a></div>
<div class="doc_text">
<p>LLVM has a code review policy. Code review is one way to increase the
quality of software. We generally follow these policies:</p>
<ol>
<li>All developers are required to have significant changes reviewed
before they are committed to the repository.</li>
<li>Code reviews are conducted by email, usually on the llvm-commits
list.</li>
<li>Code can be reviewed either before it is committed or after. We expect
major changes to be reviewed before being committed, but smaller
changes (or changes where the developer owns the component) can be
reviewed after commit.</li>
<li>The developer responsible for a code change is also responsible for
making all necessary review-related changes.</li>
<li>Code review can be an iterative process, which continues until the patch
is ready to be committed.</li>
</ol>
<p>Developers should participate in code reviews as both reviewers and
reviewees. If someone is kind enough to review your code, you should
return the favor for someone else. Note that anyone is welcome to review
and give feedback on a patch, but only people with CVS write access can
approve it.</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsection"> <a name="testcases">Test Cases</a></div>
<div class="doc_text">
<p>Developers are required to create test cases for any bugs fixed and any new
features added. Some tips for getting your testcase approved:</p>
<ol>
<li>All feature and regression test cases are added to the
<tt>llvm/test</tt> directory. The appropriate sub-directory should be
selected (see the <a href="TestingGuide.html">Testing Guide</a> for
details).</li>
<li>Test cases should be written in
<a href="LangRef.html">LLVM assembly language</a> unless the
feature or regression being tested requires another language (e.g. the
bug being fixed or feature being implemented is in the llvm-gcc C++
front-end, in which case it must be written in C++).</li>
<li>Test cases, especially for regressions, should be reduced as much as
possible, by <a href="Bugpoint.html">bugpoint</a> or
manually. It is unacceptable
to place an entire failing program into <tt>llvm/test</tt> as this creates
a <i>time-to-test</i> burden on all developers. Please keep them short.</li>
</ol>
<p>Note that llvm/test is designed for regression and small feature tests
only. More extensive test cases (e.g., entire applications, benchmarks,
etc) should be added to the <tt>llvm-test</tt> test suite. The llvm-test
suite is for coverage (correctness, performance, etc) testing, not feature
or regression testing.</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsection"> <a name="quality">Quality</a></div>
<div class="doc_text">
<p>The minimum quality standards that any change must satisfy before being
committed to the main development branch are:</p>
<ol>
<li>Code must adhere to the
<a href="CodingStandards.html">LLVM Coding Standards</a>.</li>
<li>Code must compile cleanly (no errors, no warnings) on at least one
platform.</li>
<li>Bug fixes and new features should <a href="#testcases">include a
testcase</a> so we know if the fix/feature ever regresses in the
future.</li>
<li>Code must pass the dejagnu (<tt>llvm/test</tt>) test suite.</li>
<li>The code must not cause regressions on a reasonable subset of llvm-test,
where "reasonable" depends on the contributor's judgement and the scope
of the change (more invasive changes require more testing). A reasonable
subset is "<tt>llvm-test/MultiSource/Benchmarks</tt>".</li>
</ol>
<p>Additionally, the committer is responsible for addressing any problems
found in the future that the change is responsible for. For example:</p>
<ul>
<li>The code should compile cleanly on all supported platforms.</li>
<li>The changes should not cause any correctness regressions in the
<tt>llvm-test</tt> suite and must not cause any major performance
regressions.</li>
<li>The change set should not cause performance or correctness regressions
for the LLVM tools.</li>
<li>The changes should not cause performance or correctness regressions in
code compiled by LLVM on all applicable targets.</li>
<li>You are expected to address any <a href="http://llvm.org/bugs/">bugzilla
bugs</a> that result from your change.</li>
</ul>
<p>We prefer for this to be handled before submission but understand that it
isn't possible to test all of this for every submission. Our nightly
testing
infrastructure normally finds these problems. A good rule of thumb is to
check the nightly testers for regressions the day after your change.</p>
<p>Commits that violate these quality standards (e.g. are very broken) may
be reverted. This is necessary when the change blocks other developers from
making progress. The developer is welcome to re-commit the change after
the problem has been fixed.</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsection">
<a name="commitaccess">Obtaining Commit Access</a></div>
<div class="doc_text">
<p>
We grant commit access to contributors with a track record of submitting high
quality patches. If you would like commit access, please send an email to the
<a href="mailto:llvm-oversight@cs.uiuc.edu">LLVM oversight group</a>.</p>
<p>If you have recently been granted commit access, these policies apply:</p>
<ol>
<li>You are granted <i>commit-after-approval</i> to all parts of LLVM.
To get approval, submit a <a href="#patches">patch</a> to
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">
llvm-commits</a>. When approved you may commit it yourself.</li>
<li>You are allowed to commit patches without approval which you think are
obvious. This is clearly a subjective decision &mdash; we simply expect you
to use good judgement. Examples include: fixing build breakage, reverting
obviously broken patches, documentation/comment changes, any other minor
changes.</li>
<li>You are allowed to commit patches without approval to those portions
of LLVM that you have contributed or maintain (i.e., have been assigned
responsibility for), with the proviso that such commits must not break the
build. This is a "trust but verify" policy and commits of this nature are
reviewed after they are committed.</li>
<li>Multiple violations of these policies or a single egregious violation
may cause commit access to be revoked.</li>
</ol>
<p>In any case, your changes are still subject to <a href="#reviews">code
review</a> (either before or after they are committed, depending on the nature
of the change). You are encouraged to review other peoples' patches as well,
but you aren't required to.</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsection"> <a name="newwork">Making a Major Change</a></div>
<div class="doc_text">
<p>When a developer begins a major new project with the aim of contributing
it back to LLVM, s/he should inform the community with an email to
the <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">llvmdev</a>
email list, to the extent possible. The reason for this is to:
<ol>
<li>keep the community informed about future changes to LLVM, </li>
<li>avoid duplication of effort by preventing multiple parties working on
the same thing and not knowing about it, and</li>
<li>ensure that any technical issues around the proposed work are
discussed and resolved before any significant work is done.</li>
</ol>
<p>The design of LLVM is carefully controlled to ensure that all the pieces
fit together well and are as consistent as possible. If you plan to make a
major change to the way LLVM works or want to add a major new extension, it
is a good idea to get consensus with the development
community before you start working on it.</p>
<p>Once the design of the new feature is finalized, the work itself should be
done as a series of <a href="#incremental">incremental changes</a>, not as
a long-term development branch.</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsection"> <a name="incremental">Incremental Development</a>
</div>
<div class="doc_text">
<p>In the LLVM project, we do all significant changes as a series of
incremental patches. We have a strong dislike for huge changes or
long-term development branches. Long-term development branches have a
number of drawbacks:</p>
<ol>
<li>Branches must have mainline merged into them periodically. If the branch
development and mainline development occur in the same pieces of code,
resolving merge conflicts can take a lot of time.</li>
<li>Other people in the community tend to ignore work on branches.</li>
<li>Huge changes (produced when a branch is merged back onto mainline) are
extremely difficult to <a href="#reviews">code review</a>.</li>
<li>Branches are not routinely tested by our nightly tester
infrastructure.</li>
<li>Changes developed as monolithic large changes often don't work until the
entire set of changes is done. Breaking it down into a set of smaller
changes increases the odds that any of the work will be committed to the
main repository.</li>
</ol>
<p>
To address these problems, LLVM uses an incremental development style and we
require contributors to follow this practice when making a large/invasive
change. Some tips:</p>
<ul>
<li>Large/invasive changes usually have a number of secondary changes that
are required before the big change can be made (e.g. API cleanup, etc).
These sorts of changes can often be done before the major change is done,
independently of that work.</li>
<li>The remaining inter-related work should be decomposed into unrelated
sets of changes if possible. Once this is done, define the first increment
and get consensus on what the end goal of the change is.</li>
<li>Each change in the set can be stand alone (e.g. to fix a bug), or part
of a planned series of changes that works towards the development goal.</li>
<li>Each change should be kept as small as possible. This simplifies your
work (into a logical progression), simplifies code review and reduces the
chance that you will get negative feedback on the change. Small increments
also facilitate the maintenance of a high quality code base.</li>
<li>Often, an independent precursor to a big change is to add a new API and
slowly migrate clients to use the new API. Each change to use the new
API is often "obvious" and can be committed without review. Once the
new API is in place and used, it is much easier to replace the
underlying implementation of the API. This implementation change is
logically separate from the API change.</li>
</ul>
<p>If you are interested in making a large change, and this scares you, please
make sure to first <a href="#newwork">discuss the change/gather
consensus</a> then ask about the best way to go about making
the change.</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsection"><a name="attribution">Attribution of
Changes</a></div>
<div class="doc_text">
<p>We believe in correct attribution of contributions to
their contributors. However, we do not want the source code to be littered
with random attributions (this is noisy/distracting and revision control
keeps a perfect history of this anyway). As such, we follow these rules:</p>
<ol>
<li>Developers who originate new files in LLVM should place their name at
the top of the file per the
<a href="CodingStandards.html#scf_commenting">Coding Standards</a>.</li>
<li>There should be only one name at the top of the file and it should be
the person who created the file.</li>
<li>Placing your name in the file does not imply <a
href="#clp">copyright</a>: it is only used to attribute the file to
its original author.</li>
<li>Developers should be aware that after some time has passed, the name at
the top of a file may become meaningless as maintenance/ownership of files
changes. Despite this, once set, the attribution of a file never changes.
Revision control keeps an accurate history of contributions.</li>
<li>Developers should maintain their entry in the
<a href="http://llvm.org/cvsweb/cvsweb.cgi/llvm/CREDITS.TXT?rev=HEAD&amp;content-type=text/x-cvsweb-markup">CREDITS.txt</a>
file to summarize their contributions.</li>
<li>Commit comments should contain correct attribution of the person who
submitted the patch if that person is not the committer (i.e. when a
developer with commit privileges commits a patch for someone else).</li>
</ol>
</div>
<!--=========================================================================-->
<div class="doc_section">
<a name="clp">Copyright, License, and Patents</a>
</div>
<!--=========================================================================-->
<div class="doc_text">
<p>This section addresses the issues of copyright, license and patents for
the LLVM project.
Currently, the University of Illinois is the LLVM copyright holder and the
terms of its license to LLVM users and developers is the
<a href="http://www.opensource.org/licenses/UoI-NCSA.php">University of
Illinois/NCSA Open Source License</a>.</p>
<div class="doc_notes">
<p><b>NOTE: This section deals with legal matters but does not provide
legal advice. We are not lawyers, please seek legal counsel from an
attorney.</b></p>
</div>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsection"><a name="copyright">Copyright</a></div>
<div class="doc_text">
<p>
<p>For consistency and ease of management, the project requires the
copyright for all LLVM software to be held by a single copyright holder:
the University of Illinois (UIUC).</p>
<p>
Although UIUC may eventually reassign the copyright of the software to another
entity (e.g. a dedicated non-profit "LLVM Organization", or something)
the intent for the project is to always have a single entity hold the
copyrights to LLVM at any given time.</p>
<p>We believe that having a single copyright
holder is in the best interests of all developers and users as it greatly
reduces the managerial burden for any kind of administrative or technical
decisions about LLVM. The goal of the LLVM project is to always keep the code
open and <a href="#license">licensed under a very liberal license</a>.</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsection"><a name="license">License</a></div>
<div class="doc_text">
<p>We intend to keep LLVM perpetually open source
and to use a liberal open source license. The current license is the
<a href="http://www.opensource.org/licenses/UoI-NCSA.php">
University of Illinois/NCSA Open Source License</a>, which boils
down to this:</p>
<ul>
<li>You can freely distribute LLVM.</li>
<li>You must retain the copyright notice if you redistribute LLVM.</li>
<li>Binaries derived from LLVM must reproduce the copyright notice.</li>
<li>You can't use our names to promote your LLVM derived products.</li>
<li>There's no warranty on LLVM at all.</li>
</ul>
<p>We believe this fosters the widest adoption of LLVM because it <b>allows
commercial products to be derived from LLVM</b> with few restrictions and
without a requirement for making any derived works also open source (i.e.
LLVM's license is not a "copyleft" license like the GPL). We suggest that you
read the <a href="http://www.opensource.org/licenses/UoI-NCSA.php">License</a>
if further clarification is needed.</p>
<p>Note that the LLVM Project does distribute llvm-gcc, <b>which is GPL.</b>
This means that anything "linked" into llvm-gcc must itself be compatible
with the GPL, and must be releasable under the terms of the GPL. This implies
that <b>any code linked into llvm-gcc and distributed to others may be subject
to the viral aspects of the GPL</b> (for example, a proprietary code generator
linked into llvm-gcc must be made available under the GPL). This is not a
problem for code already distributed under a more liberal license (like the
UIUC license), and does not affect code generated by llvm-gcc. It may be a
problem if you intend to base commercial development on llvm-gcc without
redistributing your source code.</p>
<p>We have no plans to change the license of LLVM. If you have questions
or comments about the license, please contact the <a
href="mailto:llvm-oversight@cs.uiuc.edu">LLVM Oversight Group</a>.</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsection"><a name="patents">Patents</a></div>
<div class="doc_text">
<p>To the best of our knowledge, LLVM does not infringe on any patents (we have
actually removed code from LLVM in the past that was found to infringe).
Having code in LLVM that infringes on patents would violate an important
goal of the project by making it hard or impossible to reuse the code for
arbitrary purposes (including commercial use).</p>
<p>When contributing code, we expect contributors to notify us of any potential
for patent-related trouble with their changes. If you own the rights to a
patent and would like to contribute code to LLVM that relies on it, we
require that you sign an agreement that allows any other user of LLVM to
freely use your patent. Please contact the <a
href="mailto:llvm-oversight@cs.uiuc.edu">oversight group</a> for more
details.</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsection"><a name="devagree">Developer Agreements</a></div>
<div class="doc_text">
<p>With regards to the LLVM copyright and licensing, developers agree to
assign their copyrights to UIUC for any contribution made so that
the entire software base can be managed by a single copyright holder. This
implies that any contributions can be licensed under the license that the
project uses.</p>
</div>
<!-- *********************************************************************** -->
<hr>
<address>
<a href="http://jigsaw.w3.org/css-validator/check/referer"><img
src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a>
<a href="http://validator.w3.org/check/referer"><img
src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /></a>
Written by the
<a href="mailto:llvm-oversight@cs.uiuc.edu">LLVM Oversight Group</a><br>
<a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br>
Last modified: $Date$
</address>
</body>
</html>

View File

@@ -1,460 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>Exception Handling in LLVM</title>
<link rel="stylesheet" href="llvm.css" type="text/css">
</head>
<body>
<div class="doc_title">Exception Handling in LLVM</div>
<table class="layout" style="width:100%">
<tr class="layout">
<td class="left">
<ul>
<li><a href="#introduction">Introduction</a>
<ol>
<li><a href="#itanium">Itanium ABI Zero-cost Exception Handling</a></li>
<li><a href="#overview">Overview</a></li>
</ol></li>
<li><a href="#codegen">LLVM Code Generation</a>
<ol>
<li><a href="#throw">Throw</a></li>
<li><a href="#try_catch">Try/Catch</a></li>
<li><a href="#finallys">Finallys</a></li>
<li><a href="#throw_filters">Throw Filters</a></li>
</ol></li>
<li><a href="#format_common_intrinsics">Exception Handling Intrinsics</a>
<ol>
<li><a href="#llvm_eh_exception"><tt>llvm.eh.exception</tt></a></li>
<li><a href="#llvm_eh_selector"><tt>llvm.eh.selector</tt></a></li>
<li><a href="#llvm_eh_filter"><tt>llvm.eh.filter</tt></a></li>
<li><a href="#llvm_eh_typeid_for"><tt>llvm.eh.typeid.for</tt></a></li>
</ol></li>
<li><a href="#asm">Asm Table Formats</a>
<ol>
<li><a href="#unwind_tables">Exception Handling Frame</a></li>
<li><a href="#exception_tables">Exception Tables</a></li>
</ol></li>
<li><a href="#todo">ToDo</a></li>
</ul>
</td>
</tr></table>
<div class="doc_author">
<p>Written by <a href="mailto:jlaskey@mac.com">Jim Laskey</a></p>
</div>
<!-- *********************************************************************** -->
<div class="doc_section"><a name="introduction">Introduction</a></div>
<!-- *********************************************************************** -->
<div class="doc_text">
<p>This document is the central repository for all information pertaining to
exception handling in LLVM. It describes the format that LLVM exception
handling information takes, which is useful for those interested in creating
front-ends or dealing directly with the information. Further, this document
provides specific examples of what exception handling information is used for
C/C++.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="itanium">Itanium ABI Zero-cost Exception Handling</a>
</div>
<div class="doc_text">
<p>Exception handling for most programming languages is designed to recover from
conditions that rarely occur during general use of an application. To that end,
exception handling should not interfere with the main flow of an
application&apos;s algorithm by performing checkpointing tasks such as saving
the current pc or register state.</p>
<p>The Itanium ABI Exception Handling Specification defines a methodology for
providing outlying data in the form of exception tables without inlining
speculative exception handling code in the flow of an application&apos;s main
algorithm. Thus, the specification is said to add "zero-cost" to the normal
execution of an application.</p>
<p>A more complete description of the Itanium ABI exception handling runtime
support of can be found at <a
href="http://www.codesourcery.com/cxx-abi/abi-eh.html">Itanium C++ ABI:
Exception Handling.</a> A description of the exception frame format can be
found at <a
href="http://refspecs.freestandards.org/LSB_3.0.0/LSB-Core-generic/LSB-
Core-generic/ehframechpt.html">Exception Frames</a>, with details of the Dwarf
specification at <a href="http://www.eagercon.com/dwarf/dwarf3std.htm">Dwarf 3
Standard.</a> A description for the C++ exception table formats can be found at
<a href="http://www.codesourcery.com/cxx-abi/exceptions.pdf">Exception Handling
Tables.</a></p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="overview">Overview</a>
</div>
<div class="doc_text">
<p>When an exception is thrown in llvm code, the runtime does a best effort to
find a handler suited to process the circumstance.</p>
<p>The runtime first attempts to find an <i>exception frame</i> corresponding to
the function where the exception was thrown. If the programming language (ex.
C++) supports exception handling, the exception frame contains a reference to an
exception table describing how to process the exception. If the language (ex.
C) does not support exception handling or if the exception needs to be forwarded
to a prior activation, the exception frame contains information about how to
unwind the current activation and restore the state of the prior activation.
This process is repeated until the exception is handled. If the exception is
not handled and no activations remain, then the application is terminated with
an appropriate error message.</p>
<p>Since different programming languages have different behaviors when handling
exceptions, the exception handling ABI provides a mechanism for supplying
<i>personalities.</i> An exception handling personality is defined by way of a
<i>personality function</i> (ex. for C++ <tt>__gxx_personality_v0</tt>) which
receives the context of the exception, an <i>exception structure</i> containing
the exception object type and value, and a reference to the exception table for
the current function. The personality function for the current compile unit is
specified in a <i>common exception frame</i>.</p>
<p>The organization of an exception table is language dependent. For C++, an
exception table is organized as a series of code ranges defining what to do if
an exception occurs in that range. Typically, the information associated with a
range defines which types of exception objects (using C++ <i>type info</i>) that
are handled in that range, and an associated action that should take place.
Actions typically pass control to a <i>landing pad</i>.</p>
<p>A landing pad corresponds to the code found in the catch portion of a
try/catch sequence. When execution resumes at a landing pad, it receives the
exception structure and a selector corresponding to the <i>type</i> of exception
thrown. The selector is then used to determine which catch should actually
process the exception.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_section">
<a name="codegen">LLVM Code Generation</a>
</div>
<div class="doc_text">
<p>At the time of this writing, only C++ exception handling support is available
in LLVM. So the remainder of this document will be somewhat C++-centric.</p>
<p>From the C++ developers perspective, exceptions are defined in terms of the
<tt>throw</tt> and <tt>try/catch</tt> statements. In this section we will
describe the implementation of llvm exception handling in terms of C++
examples.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="throw">Throw</a>
</div>
<div class="doc_text">
<p>Languages that support exception handling typically provide a <tt>throw</tt>
operation to initiate the exception process. Internally, a throw operation
breaks down into two steps. First, a request is made to allocate exception
space for an exception structure. This structure needs to survive beyond the
current activation. This structure will contain the type and value of the
object being thrown. Second, a call is made to the runtime to raise the
exception, passing the exception structure as an argument.</p>
<p>In C++, the allocation of the exception structure is done by the
<tt>__cxa_allocate_exception</tt> runtime function. The exception raising is
handled by <tt>__cxa_throw</tt>. The type of the exception is represented using
a C++ RTTI type info structure.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="try_catch">Try/Catch</a>
</div>
<div class="doc_text">
<p>A call within the scope of a try statement can potentially raise an exception.
In those circumstances, the LLVM C++ front-end replaces the call with an
<tt>invoke</tt> instruction. Unlike a call, the invoke has two potential
continuation points; where to continue when the call succeeds as per normal, and
where to continue if the call raises an exception, either by a throw or the
unwinding of a throw.</p>
<p>The term used to define a the place where an invoke continues after an
exception is called a <i>landing pad</i>. LLVM landing pads are conceptually
alternative function entry points where a exception structure reference and a type
info index are passed in as arguments. The landing pad saves the exception
structure reference and then proceeds to select the catch block that corresponds
to the type info of the exception object.</p>
<p>Two llvm intrinsic functions are used convey information about the landing
pad to the back end.</p>
<p><a href="#llvm_eh_exception"><tt>llvm.eh.exception</tt></a> takes no
arguments and returns the exception structure reference. The backend replaces
this intrinsic with the code that accesses the first argument of a call. The
LLVM C++ front end generates code to save this value in an alloca location for
further use in the landing pad and catch code.</p>
<p><a href="#llvm_eh_selector"><tt>llvm.eh.selector</tt></a> takes a minimum of
three arguments. The first argument is the reference to the exception
structure. The second argument is a reference to the personality function to be
used for this try catch sequence. The remaining arguments are references to the
type infos for each of the catch statements in the order they should be tested.
The <i>catch all</i> (...) is represented with a <tt>null i8*</tt>. The result
of the <a href="#llvm_eh_selector"><tt>llvm.eh.selector</tt></a> is the index of
the type info in the corresponding exception table. The LLVM C++ front end
generates code to save this value in an alloca location for further use in the
landing pad and catch code.</p>
<p>Once the landing pad has the type info selector, the code branches to the
code for the first catch. The catch then checks the value of the type info
selector against the index of type info for that catch. Since the type info
index is not known until all the type info have been gathered in the backend,
the catch code will call the <a
href="#llvm_eh_typeid_for"><tt>llvm.eh.typeid.for</tt></a> intrinsic to
determine the index for a given type info. If the catch fails to match the
selector then control is passed on to the next catch. Note: Since the landing
pad will not be used if there is no match in the list of type info on the call
to <a href="#llvm_eh_selector"><tt>llvm.eh.selector</tt></a>, then neither the
last catch nor <i>catch all</i> need to perform the the check against the
selector.</p>
<p>Finally, the entry and exit of catch code is bracketed with calls to
<tt>__cxa_begin_catch</tt> and <tt>__cxa_end_catch</tt>.
<tt>__cxa_begin_catch</tt> takes a exception structure reference as an argument
and returns the value of the exception object.</tt> <tt>__cxa_end_catch</tt>
takes a exception structure reference as an argument. This function clears the
exception from the exception space. Note: a rethrow from within the catch may
replace this call with a <tt>__cxa_rethrow</tt>.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="finallys">Finallys</a>
</div>
<div class="doc_text">
<p>To handle destructors and cleanups in try code, control may not run directly
from a landing pad to the first catch. Control may actually flow from the
landing pad to clean up code and then to the first catch. Since the required
clean up for each invoke in a try may be different (ex., intervening
constructor), there may be several landing pads for a given try.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="throw_filters">Throw Filters</a>
</div>
<div class="doc_text">
<p>C++ allows the specification of which exception types that can be thrown from
a function. To represent this a top level landing pad may exist to filter out
invalid types. To express this in LLVM code the landing pad will call <a
href="#llvm_eh_filter"><tt>llvm.eh.filter</tt></a> instead of <a
href="#llvm_eh_selector"><tt>llvm.eh.selector</tt></a>. The arguments are the
same, but what gets created in the exception table is different. <a
href="#llvm_eh_filter"><tt>llvm.eh.filter</tt></a> will return a negative value
if it doesn't find a match. If no match is found then a call to
<tt>__cxa_call_unexpected</tt> should be made, otherwise
<tt>_Unwind_Resume</tt>. Each of these functions require a reference to the
exception structure.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_section">
<a name="format_common_intrinsics">Exception Handling Intrinsics</a>
</div>
<div class="doc_text">
<p>LLVM uses several intrinsic functions (name prefixed with "llvm.eh") to
provide exception handling information at various points in generated code.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsubsection">
<a name="llvm_eh_exception">llvm.eh.exception</a>
</div>
<div class="doc_text">
<pre>
i8* %<a href="#llvm_eh_exception">llvm.eh.exception</a>( )
</pre>
<p>This intrinsic indicates that the exception structure is available at this
point in the code. The backend will replace this intrinsic with code to fetch
the first argument of a call. The effect is that the intrinsic result is the
exception structure reference.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsubsection">
<a name="llvm_eh_selector">llvm.eh.selector</a>
</div>
<div class="doc_text">
<pre>
i32 %<a href="#llvm_eh_selector">llvm.eh.selector</a>(i8*, i8*, i8*, ...)
</pre>
<p>This intrinsic indicates that the exception selector is available at this
point in the code. The backend will replace this intrinsic with code to fetch
the second argument of a call. The effect is that the intrinsic result is the
exception selector.</p>
<p><a href="#llvm_eh_selector"><tt>llvm.eh.selector</tt></a> takes a minimum of
three arguments. The first argument is the reference to the exception
structure. The second argument is a reference to the personality function to be
used for this try catch sequence. The remaining arguments are references to the
type infos for each of the catch statements in the order they should be tested.
The <i>catch all</i> (...) is represented with a <tt>null i8*</tt>.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsubsection">
<a name="llvm_eh_filter">llvm.eh.filter</a>
</div>
<div class="doc_text">
<pre>
i32 %<a href="#llvm_eh_filter">llvm.eh.filter</a>(i8*, i8*, i8*, ...)
</pre>
<p>This intrinsic indicates that the exception selector is available at this
point in the code. The backend will replace this intrinsic with code to fetch
the second argument of a call. The effect is that the intrinsic result is the
exception selector.</p>
<p><a href="#llvm_eh_filter"><tt>llvm.eh.filter</tt></a> takes a minimum of
three arguments. The first argument is the reference to the exception
structure. The second argument is a reference to the personality function to be
used for this function. The remaining arguments are references to the type infos
for each type that can be thrown by the current function.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsubsection">
<a name="llvm_eh_typeid_for">llvm.eh.typeid.for</a>
</div>
<div class="doc_text">
<pre>
i32 %<a href="#llvm_eh_typeid_for">llvm.eh.typeid.for</a>(i8*)
</pre>
<p>This intrinsic returns the type info index in the exception table of the
current function. This value can be used to compare against the result of <a
href="#llvm_eh_selector"><tt>llvm.eh.selector</tt></a>. The single argument is
a reference to a type info.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_section">
<a name="asm">Asm Table Formats</a>
</div>
<div class="doc_text">
<p>There are two tables that are used by the exception handling runtime to
determine which actions should take place when an exception is thrown.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="unwind_tables">Exception Handling Frame</a>
</div>
<div class="doc_text">
<p>An exception handling frame <tt>eh_frame</tt> is very similar to the unwind
frame used by dwarf debug info. The frame contains all the information
necessary to tear down the current frame and restore the state of the prior
frame. There is an exception handling frame for each function in a compile
unit, plus a common exception handling frame that defines information common to
all functions in the unit.</p>
<p>Todo - Table details here.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="exception_tables">Exception Tables</a>
</div>
<div class="doc_text">
<p>An exception table contains information about what actions to take when an
exception is thrown in a particular part of a function&apos;s code. There is
one exception table per function except leaf routines and functions that have
only calls to non-throwing functions will not need an exception table.</p>
<p>Todo - Table details here.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_section">
<a name="todo">ToDo</a>
</div>
<div class="doc_text">
<ol>
<li><p>Need to create landing pads for code in between explicit landing pads.
The landing pads will have a zero action and a NULL landing pad address and are
used to inform the runtime that the exception should be rethrown.</li></p>
<li><p>Actions for a given function should be folded to save space.</p></li>
<li><p>Filters for inlined functions need to be handled more extensively.
Currently it&apos;s hardwired for one filter per function.</li></p>
<li><p>Testing/Testing/Testing.</li></p>
</ol>
</div>
<!-- *********************************************************************** -->
<hr>
<address>
<a href="http://jigsaw.w3.org/css-validator/check/referer"><img
src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a>
<a href="http://validator.w3.org/check/referer"><img
src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"></a>
<a href="mailto:sabre@nondot.org">Chris Lattner</a><br>
<a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
Last modified: $Date$
</address>
</body>
</html>

View File

@@ -16,7 +16,6 @@
<li><a href="#introduction">Introduction and Warning</a></li>
<li><a href="#intrinsic">Adding a new intrinsic function</a></li>
<li><a href="#instruction">Adding a new instruction</a></li>
<li><a href="#sdnode">Adding a new SelectionDAG node</a></li>
<li><a href="#type">Adding a new type</a>
<ol>
<li><a href="#fund_type">Adding a new fundamental type</a></li>
@@ -26,8 +25,7 @@
<div class="doc_author">
<p>Written by <a href="http://misha.brukman.net">Misha Brukman</a>,
Brad Jones, Nate Begeman,
and <a href="http://nondot.org/sabre">Chris Lattner</a></p>
Brad Jones, and <a href="http://nondot.org/sabre">Chris Lattner</a></p>
</div>
<!-- *********************************************************************** -->
@@ -53,9 +51,9 @@ different passes that you intend to use with your extension, and there are
<em>many</em> LLVM analyses and transformations, so it may be quite a bit of
work.</p>
<p>Adding an <a href="#intrinsic">intrinsic function</a> is far easier than
adding an instruction, and is transparent to optimization passes. If your added
functionality can be expressed as a
<p>Adding an <a href="#intrinsic">intrinsic function</a> is easier than adding
an instruction, and is transparent to optimization passes which treat it as an
unanalyzable function. If your added functionality can be expressed as a
function call, an intrinsic function is the method of choice for LLVM
extension.</p>
@@ -85,19 +83,27 @@ function and then be turned into an instruction if warranted.</p>
what the restrictions are. Talk to other people about it so that you are
sure it's a good idea.</li>
<li><tt>llvm/include/llvm/Intrinsics*.td</tt>:
Add an entry for your intrinsic. Describe its memory access characteristics
for optimization (this controls whether it will be DCE'd, CSE'd, etc). Note
that any intrinsic using the <tt>llvm_int_ty</tt> type for an argument will
be deemed by <tt>tblgen</tt> as overloaded and the corresponding suffix
will be required on the intrinsic's name.</li>
<li><tt>llvm/include/llvm/Intrinsics.h</tt>:
add an enum in the <tt>llvm::Intrinsic</tt> namespace</li>
<li><tt>llvm/lib/Analysis/ConstantFolding.cpp</tt>: If it is possible to
constant fold your intrinsic, add support to it in the
<tt>canConstantFoldCallTo</tt> and <tt>ConstantFoldCall</tt> functions.</li>
<li><tt>llvm/lib/VMCore/Verifier.cpp</tt>:
Add code to check the invariants of the intrinsic are respected.</li>
<li><tt>llvm/test/Regression/*</tt>: Add test cases for your test cases to the
test suite</li>
<li><tt>llvm/lib/VMCore/Function.cpp (<tt>Function::getIntrinsicID()</tt>)</tt>:
Identify the new intrinsic function, returning the enum for the intrinsic
that you added.</li>
<li><tt>llvm/lib/Analysis/BasicAliasAnalysis.cpp</tt>: If the new intrinsic does
not access memory or does not write to memory, add it to the relevant list
of functions.</li>
<li><tt>llvm/lib/Transforms/Utils/Local.cpp</tt>: If it is possible to constant
fold your intrinsic, add support to it in the <tt>canConstantFoldCallTo</tt> and
<tt>ConstantFoldCall</tt> functions.</li>
<li>Test your intrinsic</li>
<li><tt>llvm/test/Regression/*</tt>: add your test cases to the test suite</li>
</ol>
<p>Once the intrinsic has been added to the system, you must add code generator
@@ -106,117 +112,48 @@ support for it. Generally you must do the following steps:</p>
<dl>
<dt>Add support to the C backend in <tt>lib/Target/CBackend/</tt></dt>
<dd>Depending on the intrinsic, there are a few ways to implement this. For
most intrinsics, it makes sense to add code to lower your intrinsic in
<tt>LowerIntrinsicCall</tt> in <tt>lib/CodeGen/IntrinsicLowering.cpp</tt>.
Second, if it makes sense to lower the intrinsic to an expanded sequence of C
code in all cases, just emit the expansion in <tt>visitCallInst</tt> in
<tt>Writer.cpp</tt>. If the intrinsic has some way to express it with GCC
(or any other compiler) extensions, it can be conditionally supported based on
the compiler compiling the CBE output (see <tt>llvm.prefetch</tt> for an
example).
Third, if the intrinsic really has no way to be lowered, just have the code
generator emit code that prints an error message and calls abort if executed.
<dd>Depending on the intrinsic, there are a few ways to implement this. First,
if it makes sense to lower the intrinsic to an expanded sequence of C code in
all cases, just emit the expansion in <tt>visitCallInst</tt>. Second, if the
intrinsic has some way to express it with GCC (or any other compiler)
extensions, it can be conditionally supported based on the compiler compiling
the CBE output (see llvm.prefetch for an example). Third, if the intrinsic
really has no way to be lowered, just have the code generator emit code that
prints an error message and calls abort if executed.
</dd>
<dl>
<dt>Add support to the .td file for the target(s) of your choice in
<tt>lib/Target/*/*.td</tt>.</dt>
<dt>Add a enum value for the SelectionDAG node in
<tt>include/llvm/CodeGen/SelectionDAGNodes.h</tt></dt>
<dd>This is usually a matter of adding a pattern to the .td file that matches
the intrinsic, though it may obviously require adding the instructions you
want to generate as well. There are lots of examples in the PowerPC and X86
backend to follow.</dd>
<dd>Also, add code to <tt>lib/CodeGen/SelectionDAG/SelectionDAG.cpp</tt> (and
<tt>SelectionDAGPrinter.cpp</tt>) to print the node.</dd>
</div>
<dt>Add code to <tt>SelectionDAG/SelectionDAGISel.cpp</tt> to recognize the
intrinsic.</dt>
<!-- *********************************************************************** -->
<div class="doc_section">
<a name="sdnode">Adding a new SelectionDAG node</a>
</div>
<!-- *********************************************************************** -->
<dd>Presumably the intrinsic should be recognized and turned into the node you
added above.</dd>
<div class="doc_text">
<dt>Add code to <tt>SelectionDAG/LegalizeDAG.cpp</tt> to <a
href="CodeGenerator.html#selectiondag_legalize">legalize, promote, and
expand</a> the node as necessary.</dt>
<p>As with intrinsics, adding a new SelectionDAG node to LLVM is much easier
than adding a new instruction. New nodes are often added to help represent
instructions common to many targets. These nodes often map to an LLVM
instruction (add, sub) or intrinsic (byteswap, population count). In other
cases, new nodes have been added to allow many targets to perform a common task
(converting between floating point and integer representation) or capture more
complicated behavior in a single node (rotate).</p>
<dd>If the intrinsic can be expanded to primitive operations, legalize can break
the node down into other elementary operations that are be supported.</dd>
<ol>
<li><tt>include/llvm/CodeGen/SelectionDAGNodes.h</tt>:
Add an enum value for the new SelectionDAG node.</li>
<li><tt>lib/CodeGen/SelectionDAG/SelectionDAG.cpp</tt>:
Add code to print the node to <tt>getOperationName</tt>. If your new node
can be evaluated at compile time when given constant arguments (such as an
add of a constant with another constant), find the <tt>getNode</tt> method
that takes the appropriate number of arguments, and add a case for your node
to the switch statement that performs constant folding for nodes that take
the same number of arguments as your new node.</li>
<li><tt>lib/CodeGen/SelectionDAG/LegalizeDAG.cpp</tt>:
Add code to <a href="CodeGenerator.html#selectiondag_legalize">legalize,
promote, and expand</a> the node as necessary. At a minimum, you will need
to add a case statement for your node in <tt>LegalizeOp</tt> which calls
LegalizeOp on the node's operands, and returns a new node if any of the
operands changed as a result of being legalized. It is likely that not all
targets supported by the SelectionDAG framework will natively support the
new node. In this case, you must also add code in your node's case
statement in <tt>LegalizeOp</tt> to Expand your node into simpler, legal
operations. The case for <tt>ISD::UREM</tt> for expanding a remainder into
a divide, multiply, and a subtract is a good example.</li>
<li><tt>lib/CodeGen/SelectionDAG/LegalizeDAG.cpp</tt>:
If targets may support the new node being added only at certain sizes, you
will also need to add code to your node's case statement in
<tt>LegalizeOp</tt> to Promote your node's operands to a larger size, and
perform the correct operation. You will also need to add code to
<tt>PromoteOp</tt> to do this as well. For a good example, see
<tt>ISD::BSWAP</tt>,
which promotes its operand to a wider size, performs the byteswap, and then
shifts the correct bytes right to emulate the narrower byteswap in the
wider type.</li>
<li><tt>lib/CodeGen/SelectionDAG/LegalizeDAG.cpp</tt>:
Add a case for your node in <tt>ExpandOp</tt> to teach the legalizer how to
perform the action represented by the new node on a value that has been
split into high and low halves. This case will be used to support your
node with a 64 bit operand on a 32 bit target.</li>
<li><tt>lib/CodeGen/SelectionDAG/DAGCombiner.cpp</tt>:
If your node can be combined with itself, or other existing nodes in a
peephole-like fashion, add a visit function for it, and call that function
from <tt></tt>. There are several good examples for simple combines you
can do; <tt>visitFABS</tt> and <tt>visitSRL</tt> are good starting places.
</li>
<li><tt>lib/Target/PowerPC/PPCISelLowering.cpp</tt>:
Each target has an implementation of the <tt>TargetLowering</tt> class,
usually in its own file (although some targets include it in the same
file as the DAGToDAGISel). The default behavior for a target is to
assume that your new node is legal for all types that are legal for
that target. If this target does not natively support your node, then
tell the target to either Promote it (if it is supported at a larger
type) or Expand it. This will cause the code you wrote in
<tt>LegalizeOp</tt> above to decompose your new node into other legal
nodes for this target.</li>
<li><tt>lib/Target/TargetSelectionDAG.td</tt>:
Most current targets supported by LLVM generate code using the DAGToDAG
method, where SelectionDAG nodes are pattern matched to target-specific
nodes, which represent individual instructions. In order for the targets
to match an instruction to your new node, you must add a def for that node
to the list in this file, with the appropriate type constraints. Look at
<tt>add</tt>, <tt>bswap</tt>, and <tt>fadd</tt> for examples.</li>
<li><tt>lib/Target/PowerPC/PPCInstrInfo.td</tt>:
Each target has a tablegen file that describes the target's instruction
set. For targets that use the DAGToDAG instruction selection framework,
add a pattern for your new node that uses one or more target nodes.
Documentation for this is a bit sparse right now, but there are several
decent examples. See the patterns for <tt>rotl</tt> in
<tt>PPCInstrInfo.td</tt>.</li>
<li>TODO: document complex patterns.</li>
<li><tt>llvm/test/Regression/CodeGen/*</tt>: Add test cases for your new node
to the test suite. <tt>llvm/test/Regression/CodeGen/X86/bswap.ll</tt> is
a good example.</li>
</ol>
<dt>Add target-specific support to specific code generators.</dt>
<dd>Extend the code generators you are interested in to recognize and support
the node, emitting the code you want.</dd>
</dl>
<p>
Unfortunately, the process of extending the code generator to support a new node
is not extremely well documented. As such, it is often helpful to look at other
intrinsics (e.g. <tt>llvm.ctpop</tt>) to see how they are recognized and turned
into a node by <tt>SelectionDAGISel.cpp</tt>, legalized by
<tt>LegalizeDAG.cpp</tt>, then finally emitted by the various code generators.
</p>
</div>
@@ -329,7 +266,7 @@ installations.</span> Only add new types if it is absolutely necessary.</p>
add enum for the new type; add a forward declaration of the type
also</li>
<li><tt>llvm/include/llvm/DerivedTypes.h</tt>:
<li><tt>llvm/include/llvm/DerivedType.h</tt>:
add new class to represent new class in the hierarchy; add forward
declaration to the TypeMap value type</li>
@@ -383,7 +320,7 @@ void calcTypeName(const Type *Ty,
<a href="http://validator.w3.org/check/referer"><img
src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /></a>
<a href="http://llvm.org">The LLVM Compiler Infrastructure</a>
<a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
<br>
Last modified: $Date$
</address>

View File

@@ -36,6 +36,7 @@
<li><a href="#build">Build Problems</a>
<ol>
<li>When I run configure, it finds the wrong C compiler.</li>
<li>I compile the code, and I get some error about <tt>/localhome</tt>.</li>
<li>The <tt>configure</tt> script finds the right C compiler, but it uses the
LLVM linker from a previous build. What do I do?</li>
<li>When creating a dynamic library, I get a strange GLIBC error.</li>
@@ -54,15 +55,6 @@
target".</li>
</ol></li>
<li><a href="#felangs">Source Languages</a>
<ol>
<li><a href="#langs">What source languages are supported?</a></li>
<li><a href="#langhlsupp">What support is there for higher level source
language constructs for building a compiler?</a></li>
<li><a href="GetElementPtr.html">I don't understand the GetElementPtr
instruction. Help!</a></li>
</ol>
<li><a href="#cfe">Using the GCC Front End</a>
<ol>
<li>
@@ -80,8 +72,6 @@
How can I disable all optimizations when compiling code using the LLVM GCC front end?
</li>
<li><a href="#translatec++">Can I use LLVM to convert C++ code to C code?</a></li>
</ol>
</li>
@@ -99,7 +89,7 @@
</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.cs.uiuc.edu">The LLVM Team</a></p>
</div>
@@ -139,7 +129,7 @@ Source Initiative (OSI).</p>
<div class="answer">
<p>Yes. The modified source distribution must retain the copyright notice and
follow the three bulletted conditions listed in the <a
href="http://llvm.org/releases/1.3/LICENSE.TXT">LLVM license</a>.</p>
href="http://llvm.cs.uiuc.edu/releases/1.3/LICENSE.TXT">LLVM license</a>.</p>
</div>
<div class="question">
@@ -214,6 +204,22 @@ explicitly.</p>
</div>
<div class="question">
<p>I compile the code, and I get some error about <tt>/localhome</tt>.</p>
</div>
<div class="answer">
<p>There are several possible causes for this. The first is that you didn't set
a pathname properly when using <tt>configure</tt>, and it defaulted to a
pathname that we use on our research machines.</p>
<p>Another possibility is that we hardcoded a path in our Makefiles. If you see
this, please email the LLVM bug mailing list with the name of the offending
Makefile and a description of what is wrong with it.</p>
</div>
<div class="question">
<p>The <tt>configure</tt> script finds the right C compiler, but it uses the
LLVM linker from a previous build. What do I do?</p>
@@ -377,49 +383,6 @@ which list dependencies for source files, and rebuild:</p>
rebuilding.</p>
</div>
<!-- *********************************************************************** -->
<div class="doc_section"><a name="felangs">Source Languages</a></div>
<div class="question"><p>
<a name="langs">What source languages are supported?</a></p>
</div>
<div class="answer">
<p>LLVM currently has full support for C and C++ source languages. These are
available through a special version of GCC that LLVM calls the
<a href="#cfe">C Front End</a></p>
<p>There is an incomplete version of a Java front end available in the
<tt>llvm-java</tt> CVS repository. There is no documentation on this yet so
you'll need to download the code, compile it, and try it.</p>
<p>In the <tt>examples/BFtoLLVM</tt> directory is a translator for the
BrainF*** language (2002 Language Specification).</p>
<p>In the <tt>projects/Stacker</tt> directory is a compiler and runtime
library for the Stacker language, a "toy" language loosely based on Forth.</p>
<p>The PyPy developers are working on integrating LLVM into the PyPy backend
so that PyPy language can translate to LLVM.</p>
</div>
<div class="question"><a name="langhlsupp">
<p>What support is there for a higher level source language constructs for
building a compiler?</a></p>
</div>
<div class="answer">
<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>
</div>
<div class="question"><a name="langhlsupp">
<p>I don't understand the GetElementPtr
instruction. Help!</a></p>
</div>
<div class="answer">
<p>See <a href="GetElementPtr.html">The Often Misunderstood GEP
Instruction</a>.</li>
</div>
<!-- *********************************************************************** -->
<div class="doc_section">
<a name="cfe">Using the GCC Front End</a>
@@ -443,21 +406,28 @@ or translation to the C back end). That is why configure thinks your system
<p>
To work around this, perform the following steps:
</p>
<ol>
<li>Make sure the CC and CXX environment variables contains the full path to
the LLVM GCC front end.</li>
<li>
Make sure the CC and CXX environment variables contains the full path to the
LLVM GCC front end.
</li>
<li>Make sure that the regular C compiler is first in your PATH. </li>
<li>
Make sure that the regular C compiler is first in your PATH.
</li>
<li>Add the string "-Wl,-native" to your CFLAGS environment variable.</li>
<li>
Add the string "-Wl,-native" to your CFLAGS environment variable.
</li>
</ol>
<p>
This will allow the <tt>llvm-ld</tt> 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.</p>
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.
</p>
</div>
<div class="question">
@@ -491,70 +461,6 @@ code that you desire.
</p>
</div>
<div class="question">
<p>
<a name="translatec++">Can I use LLVM to convert C++ code to C code?</a>
</p>
</div>
<div class="answer">
<p>Yes, you can use LLVM to convert code from any language LLVM supports to C.
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>
<p>Use commands like this:</p>
<ol>
<li><p>Compile your program as normal with llvm-g++:</p></li>
<div class="doc_code">$ llvm-g++ x.cpp -o program</div>
<p>or:</p>
<div class="doc_code">
llvm-g++ a.cpp -c<br>
llvm-g++ b.cpp -c<br>
llvm-g++ a.o b.o -o program
</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><p>Convert the LLVM code to C code, using the LLC tool with the C
backend:</p></li>
<div class="doc_code">$ llc -march=c program.bc -o program.c</div>
<li><p>Finally, compile the c file:</p></li>
<div class="doc_code">$ cc x.c</div>
</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>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.</p>
</div>
<!-- *********************************************************************** -->
<div class="doc_section">
<a name="cfe_code">Questions about code generated by the GCC front-end</a>
@@ -667,7 +573,7 @@ specified for it.
<a href="http://validator.w3.org/check/referer"><img
src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"></a>
<a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
<a href="http://llvm.cs.uiuc.edu">LLVM Compiler Infrastructure</a><br>
Last modified: $Date$
</address>

View File

@@ -65,9 +65,8 @@ conservative and accurate.</p>
<p>Conservative garbage collection often does not require any special support
from either the language or the compiler: it can handle non-type-safe
programming languages (such as C/C++) and does not require any special
information from the compiler. The
<a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/">Boehm collector</a> is
an example of a state-of-the-art conservative collector.</p>
information from the compiler. The [LINK] Boehm collector is an example of a
state-of-the-art conservative collector.</p>
<p>Accurate garbage collection requires the ability to identify all pointers in
the program at run-time (which requires that the source-language be type-safe in
@@ -388,7 +387,7 @@ The <tt>llvm_cg_walk_gcroots</tt> function is a function provided by the code
generator that iterates through all of the GC roots on the stack, calling the
specified function pointer with each record. For each GC root, the address of
the pointer and the meta-data (from the <a
href="#roots"><tt>llvm.gcroot</tt></a> intrinsic) are provided.
href="#gcroot"><tt>llvm.gcroot</tt></a> intrinsic) are provided.
</p>
</div>
@@ -526,7 +525,7 @@ conference on LISP and functional programming.</p>
src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"></a>
<a href="mailto:sabre@nondot.org">Chris Lattner</a><br>
<a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
<a href="http://llvm.cs.uiuc.edu">LLVM Compiler Infrastructure</a><br>
Last modified: $Date$
</address>

View File

@@ -1,311 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>The Often Misunderstood GEP Instruction</title>
<link rel="stylesheet" href="llvm.css" type="text/css">
<style type="text/css">
TABLE { text-align: left; border: 1px solid black; border-collapse: collapse; margin: 0 0 0 0; }
</style>
</head>
<body>
<div class="doc_title">
The Often Misunderstood GEP Instruction
</div>
<ol>
<li><a href="#intro">Introduction</a></li>
<li><a href="#questions">The Questions</a>
<ol>
<li><a href="#extra_index">Why is the extra 0 index required?</a></li>
<li><a href="#deref">What is dereferenced by GEP?</a></li>
<li><a href="#firstptr">Why can you index through the first pointer but not
subsequent ones?</a></li>
<li><a href="#lead0">Why don't GEP x,0,0,1 and GEP x,1 alias? </a></li>
<li><a href="#trail0">Why do GEP x,1,0,0 and GEP x,1 alias? </a></li>
</ol></li>
<li><a href="#summary">Summary</a></li>
</ol>
<div class="doc_author">
<p>Written by: <a href="mailto:rspencer@reidspencer.com">Reid Spencer</a>.</p>
</div>
<!-- *********************************************************************** -->
<div class="doc_section"><a name="intro"><b>Introduction</b></a></div>
<!-- *********************************************************************** -->
<div class="doc_text">
<p>This document seeks to dispel the mystery and confusion surrounding LLVM's
GetElementPtr (GEP) instruction. Questions about the wiley GEP instruction are
probably the most frequently occuring questions once a developer gets down to
coding with LLVM. Here we lay out the sources of confusion and show that the
GEP instruction is really quite simple.
</p>
</div>
<!-- *********************************************************************** -->
<div class="doc_section"><a name="questions"><b>The Questions</b></a></div>
<!-- *********************************************************************** -->
<div class="doc_text">
<p>When people are first confronted with the GEP instruction, they tend to
relate it to known concepts from other programming paradigms, most notably C
array indexing and field selection. However, GEP is a little different and
this leads to the following questions, all of which are answered in the
following sections.</p>
<ol>
<li><a href="#firstptr">What is the first index of the GEP instruction?</a>
</li>
<li><a href="#extra_index">Why is the extra 0 index required?</a></li>
<li><a href="#deref">What is dereferenced by GEP?</a></li>
<li><a href="#lead0">Why don't GEP x,0,0,1 and GEP x,1 alias? </a></li>
<li><a href="#trail0">Why do GEP x,1,0,0 and GEP x,1 alias? </a></li>
</ol>
</div>
<!-- *********************************************************************** -->
<div class="doc_subsection">
<a name="firstptr"><b>What is the first index of the GEP instruction?</b></a>
</div>
<div class="doc_text">
<p>Quick answer: The index stepping through the first operand.</p>
<p>The confusion with the first index usually arises from thinking about
the GetElementPtr instruction as if it was a C index operator. They aren't the
same. For example, when we write, in "C":</p>
<pre>
AType* Foo;
...
X = &amp;Foo-&gt;F;</pre>
<p>it is natural to think that there is only one index, the selection of the
field <tt>F</tt>. However, in this example, <tt>Foo</tt> is a pointer. That
pointer must be indexed explicitly in LLVM. C, on the other hand, indexs
through it transparently. To arrive at the same address location as the C
code, you would provide the GEP instruction with two index operands. The
first operand indexes through the pointer; the second operand indexes the
field <tt>F</tt> of the structure, just as if you wrote:</p>
<pre>
X = &amp;Foo[0].F;</pre>
<p>Sometimes this question gets rephrased as:</p>
<blockquote><p><i>Why is it okay to index through the first pointer, but
subsequent pointers won't be dereferenced?</i></p></blockquote>
<p>The answer is simply because memory does not have to be accessed to
perform the computation. The first operand to the GEP instruction must be a
value of a pointer type. The value of the pointer is provided directly to
the GEP instruction as an operand without any need for accessing memory. It
must, therefore be indexed and requires an index operand. Consider this
example:</p>
<pre>
struct munger_struct {
int f1;
int f2;
};
void munge(struct munger_struct *P)
{
P[0].f1 = P[1].f1 + P[2].f2;
}
...
munger_struct Array[3];
...
munge(Array);</pre>
<p>In this "C" example, the front end compiler (llvm-gcc) will generate three
GEP instructions for the three indices through "P" in the assignment
statement. The function argument <tt>P</tt> will be the first operand of each
of these GEP instructions. The second operand indexes through that pointer.
The third operand will be the field offset into the
<tt>struct munger_struct</tt> type, for either the <tt>f1</tt> or
<tt>f2</tt> field. So, in LLVM assembly the <tt>munge</tt> function looks
like:</p>
<pre>
void %munge(%struct.munger_struct* %P) {
entry:
%tmp = getelementptr %struct.munger_struct* %P, i32 1, i32 0
%tmp = load i32* %tmp
%tmp6 = getelementptr %struct.munger_struct* %P, i32 2, i32 1
%tmp7 = load i32* %tmp6
%tmp8 = add i32 %tmp7, %tmp
%tmp9 = getelementptr %struct.munger_struct* %P, i32 0, i32 0
store i32 %tmp8, i32* %tmp9
ret void
}</pre>
<p>In each case the first operand is the pointer through which the GEP
instruction starts. The same is true whether the first operand is an
argument, allocated memory, or a global variable. </p>
<p>To make this clear, let's consider a more obtuse example:</p>
<pre>
%MyVar = unintialized global i32
...
%idx1 = getelementptr i32* %MyVar, i64 0
%idx2 = getelementptr i32* %MyVar, i64 1
%idx3 = getelementptr i32* %MyVar, i64 2</pre>
<p>These GEP instructions are simply making address computations from the
base address of <tt>MyVar</tt>. They compute, as follows (using C syntax):
</p>
<ul>
<li> idx1 = (char*) &amp;MyVar + 0</li>
<li> idx2 = (char*) &amp;MyVar + 4</li>
<li> idx3 = (char*) &amp;MyVar + 8</li>
</ul>
<p>Since the type <tt>i32</tt> is known to be four bytes long, the indices
0, 1 and 2 translate into memory offsets of 0, 4, and 8, respectively. No
memory is accessed to make these computations because the address of
<tt>%MyVar</tt> is passed directly to the GEP instructions.</p>
<p>The obtuse part of this example is in the cases of <tt>%idx2</tt> and
<tt>%idx3</tt>. They result in the computation of addresses that point to
memory past the end of the <tt>%MyVar</tt> global, which is only one
<tt>i32</tt> long, not three <tt>i32</tt>s long. While this is legal in LLVM,
it is inadvisable because any load or store with the pointer that results
from these GEP instructions would produce undefined results.</p>
</div>
<!-- *********************************************************************** -->
<div class="doc_subsection">
<a name="extra_index"><b>Why is the extra 0 index required?</b></a>
</div>
<!-- *********************************************************************** -->
<div class="doc_text">
<p>Quick answer: there are no superfluous indices.</p>
<p>This question arises most often when the GEP instruction is applied to a
global variable which is always a pointer type. For example, consider
this:</p><pre>
%MyStruct = uninitialized global { float*, i32 }
...
%idx = getelementptr { float*, i32 }* %MyStruct, i64 0, i32 1</pre>
<p>The GEP above yields an <tt>i32*</tt> by indexing the <tt>i32</tt> typed
field of the structure <tt>%MyStruct</tt>. When people first look at it, they
wonder why the <tt>i64 0</tt> index is needed. However, a closer inspection
of how globals and GEPs work reveals the need. Becoming aware of the following
facts will dispell the confusion:</p>
<ol>
<li>The type of <tt>%MyStruct</tt> is <i>not</i> <tt>{ float*, i32 }</tt>
but rather <tt>{ float*, i32 }*</tt>. That is, <tt>%MyStruct</tt> is a
pointer to a structure containing a pointer to a <tt>float</tt> and an
<tt>i32</tt>.</li>
<li>Point #1 is evidenced by noticing the type of the first operand of
the GEP instruction (<tt>%MyStruct</tt>) which is
<tt>{ float*, i32 }*</tt>.</li>
<li>The first index, <tt>i64 0</tt> is required to step over the global
variable <tt>%MyStruct</tt>. Since the first argument to the GEP
instruction must always be a value of pointer type, the first index
steps through that pointer. A value of 0 means 0 elements offset from that
pointer.</li>
<li>The second index, <tt>i32 1</tt> selects the second field of the
structure (the <tt>i32</tt>). </li>
</ol>
</div>
<!-- *********************************************************************** -->
<div class="doc_subsection">
<a name="deref"><b>What is dereferenced by GEP?</b></a>
</div>
<div class="doc_text">
<p>Quick answer: nothing.</p>
<p>The GetElementPtr instruction dereferences nothing. That is, it doesn't
access memory in any way. That's what the Load and Store instructions are for.
GEP is only involved in the computation of addresses. For example, consider
this:</p>
<pre>
%MyVar = uninitialized global { [40 x i32 ]* }
...
%idx = getelementptr { [40 x i32]* }* %MyVar, i64 0, i32 0, i64 0, i64 17</pre>
<p>In this example, we have a global variable, <tt>%MyVar</tt> that is a
pointer to a structure containing a pointer to an array of 40 ints. The
GEP instruction seems to be accessing the 18th integer of the structure's
array of ints. However, this is actually an illegal GEP instruction. It
won't compile. The reason is that the pointer in the structure <i>must</i>
be dereferenced in order to index into the array of 40 ints. Since the
GEP instruction never accesses memory, it is illegal.</p>
<p>In order to access the 18th integer in the array, you would need to do the
following:</p>
<pre>
%idx = getelementptr { [40 x i32]* }* %, i64 0, i32 0
%arr = load [40 x i32]** %idx
%idx = getelementptr [40 x i32]* %arr, i64 0, i64 17</pre>
<p>In this case, we have to load the pointer in the structure with a load
instruction before we can index into the array. If the example was changed
to:</p>
<pre>
%MyVar = uninitialized global { [40 x i32 ] }
...
%idx = getelementptr { [40 x i32] }*, i64 0, i32 0, i64 17</pre>
<p>then everything works fine. In this case, the structure does not contain a
pointer and the GEP instruction can index through the global variable,
into the first field of the structure and access the 18th <tt>i32</tt> in the
array there.</p>
</div>
<!-- *********************************************************************** -->
<div class="doc_subsection">
<a name="lead0"><b>Why don't GEP x,0,0,1 and GEP x,1 alias?</b></a>
</div>
<div class="doc_text">
<p>Quick Answer: They compute different address locations.</p>
<p>If you look at the first indices in these GEP
instructions you find that they are different (0 and 1), therefore the address
computation diverges with that index. Consider this example:</p>
<pre>
%MyVar = global { [10 x i32 ] }
%idx1 = getlementptr { [10 x i32 ] }* %MyVar, i64 0, i32 0, i64 1
%idx2 = getlementptr { [10 x i32 ] }* %MyVar, i64 1</pre>
<p>In this example, <tt>idx1</tt> computes the address of the second integer
in the array that is in the structure in %MyVar, that is <tt>MyVar+4</tt>. The
type of <tt>idx1</tt> is <tt>i32*</tt>. However, <tt>idx2</tt> computes the
address of <i>the next</i> structure after <tt>%MyVar</tt>. The type of
<tt>idx2</tt> is <tt>{ [10 x i32] }*</tt> and its value is equivalent
to <tt>MyVar + 40</tt> because it indexes past the ten 4-byte integers
in <tt>MyVar</tt>. Obviously, in such a situation, the pointers don't
alias.</p>
</div>
<!-- *********************************************************************** -->
<div class="doc_subsection">
<a name="trail0"><b>Why do GEP x,1,0,0 and GEP x,1 alias?</b></a>
</div>
<div class="doc_text">
<p>Quick Answer: They compute the same address location.</p>
<p>These two GEP instructions will compute the same address because indexing
through the 0th element does not change the address. However, it does change
the type. Consider this example:</p>
<pre>
%MyVar = global { [10 x i32 ] }
%idx1 = getlementptr { [10 x i32 ] }* %MyVar, i64 1, i32 0, i64 0
%idx2 = getlementptr { [10 x i32 ] }* %MyVar, i64 1</pre>
<p>In this example, the value of <tt>%idx1</tt> is <tt>%MyVar+40</tt> and
its type is <tt>i32*</tt>. The value of <tt>%idx2</tt> is also
<tt>MyVar+40</tt> but its type is <tt>{ [10 x i32] }*</tt>.</p>
</div>
<!-- *********************************************************************** -->
<div class="doc_section"><a name="summary"><b>Summary</b></a></div>
<!-- *********************************************************************** -->
<div class="doc_text">
<p>In summary, here's some things to always remember about the GetElementPtr
instruction:</p>
<ol>
<li>The GEP instruction never accesses memory, it only provides pointer
computations.</li>
<li>The first operand to the GEP instruction is always a pointer and it must
be indexed.</li>
<li>There are no superfluous indices for the GEP instruction.</li>
<li>Trailing zero indices are superfluous for pointer aliasing, but not for
the types of the pointers.</li>
<li>Leading zero indices are not superfluous for pointer aliasing nor the
types of the pointers.</li>
</ol>
</div>
<!-- *********************************************************************** -->
<hr>
<address>
<a href="http://jigsaw.w3.org/css-validator/check/referer"><img
src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a>
<a href="http://validator.w3.org/check/referer"><img
src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /></a>
<a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br/>
Last modified: $Date$
</address>
</body>
</html>

View File

@@ -31,7 +31,6 @@
<li><a href="#installcf">Install the GCC Front End</a>
<li><a href="#config">Local LLVM Configuration</a>
<li><a href="#compile">Compiling the LLVM Suite Source Code</a>
<li><a href="#cross-compile">Cross-Compiling LLVM</a>
<li><a href="#objfiles">The Location of LLVM Object Files</a>
<li><a href="#optionalconfig">Optional Configuration Items</a>
</ol></li>
@@ -52,9 +51,6 @@
</ol></li>
<li><a href="#tutorial">An Example Using the LLVM Tool Chain</a>
<ol>
<li><a href="#tutorial4">Example with llvm-gcc4</a></li>
</ol>
<li><a href="#problems">Common Problems</a>
<li><a href="#links">Links</a>
</ul>
@@ -84,12 +80,12 @@ basic information.</p>
<p>First, LLVM comes in two pieces. The first piece is the LLVM suite. This
contains all of the tools, libraries, and header files needed to use the low
level virtual machine. It contains an assembler, disassembler, bytecode
analyzer and bytecode optimizer. It also contains a test suite that can be
analyzer, and bytecode optimizer. It also contains a test suite that can be
used to test the LLVM tools and the GCC front end.</p>
<p>The second piece is the GCC front end. This component provides a version of
GCC that compiles C and C++ code into LLVM bytecode. Currently, the GCC front
end uses the GCC parser to convert code to LLVM. Once
end is a modified version of GCC 3.4 (we track the GCC 3.4 development). Once
compiled into LLVM bytecode, a program can be manipulated with the LLVM tools
from the LLVM suite.</p>
@@ -118,11 +114,11 @@ and performance.
<li>Install the GCC front end if you intend to compile C or C++:
<ol>
<li><tt>cd <i>where-you-want-the-C-front-end-to-live</i></tt></li>
<li><tt>gunzip --stdout llvm-gcc.<i>platform</i>.tar.gz | tar -xvf -</tt>
<li><tt>gunzip --stdout cfrontend.<i>platform</i>.tar.gz | tar -xvf -</tt>
</li>
<li><tt>cd llvm-gcc3.4/<i>platform</i> (llvm-gcc3.4 only)<br>
<li><tt>cd cfrontend/<i>platform</i><br>
./fixheaders</tt></li>
<li>Add llvm-gcc's "bin" directory to your PATH variable.</li>
<li>Add the cfrontend's "bin" directory to your PATH variable.</li>
</ol></li>
<li>Get the LLVM Source Code
@@ -173,8 +169,7 @@ and performance.
<ol>
<li><tt>gmake -k |&amp; tee gnumake.out
&nbsp;&nbsp;&nbsp;# this is csh or tcsh syntax</tt></li>
<li>If you get an "internal compiler error (ICE)" or test failures, see
<a href="#brokengcc">below</a>.</li>
<li>If you get an "internal compiler error (ICE)" see <a href="#brokengcc">below</a>.</li>
</ol>
</ol>
@@ -210,7 +205,7 @@ software you will need.</p>
<p>LLVM is known to work on the following platforms:</p>
<table cellpadding="3" summary="Known LLVM platforms">
<table cellpadding="3">
<tr>
<th>OS</th>
<th>Arch</th>
@@ -236,20 +231,14 @@ software you will need.</p>
<td>PowerPC</td>
<td>GCC</td>
</tr>
<tr>
<td>MacOS X<sup><a href="#pf_2">2</a></sup></td>
<td>x86</td>
<td>GCC</td>
</tr>
<tr>
<td>Cygwin/Win32</td>
<td>x86<sup><a href="#pf_1">1</a>,<a href="#pf_8">8</a></sup></td>
<td>x86<sup><a href="#pf_1">1</a></sup></td>
<td>GCC 3.4.X, binutils 2.15</td>
</tr>
<tr>
<td>MinGW/Win32</td>
<td>x86<sup><a href="#pf_1">1</a>,<a href="#pf_6">6</a>,<a href="#pf_8">8</a></sup></td>
<td>x86<sup><a href="#pf_1">1</a>,<a href="#pf_6">6</a></sup></td>
<td>GCC 3.4.X, binutils 2.15</td>
</tr>
<tr>
@@ -261,7 +250,7 @@ software you will need.</p>
<p>LLVM has partial support for the following platforms:</p>
<table summary="LLVM partial platform support">
<table>
<tr>
<th>OS</th>
<th>Arch</th>
@@ -309,18 +298,11 @@ up</a></li>
<li><a name="pf_3">No native code generation</a></li>
<li><a name="pf_4">Build is not complete: one or more tools don't link</a></li>
<li><a name="pf_5">The GCC-based C/C++ frontend does not build</a></li>
<li><a name="pf_6">The port is done using the MSYS shell.</a>
<li><a name="pf_6">The port is done using the MSYS shell.
<a href="http://www.mingw.org/MinGWiki/">Download</a> and install
bison (excl. M4.exe) and flex in that order. Build binutils-2.15 from source,
if necessary. Bison &amp; flex can be also grabbed from GNUWin32 sf.net
project.</li>
bison (excl. M4.exe) and flex in that order. Build binutils-2.15 from source,
if necessary.</li>
<li><a name="pf_7">Native code generation exists but is not complete.</a></li>
<li><a name="pf_8">Binutils</a> up to post-2.17 has bug in bfd/cofflink.c
preventing LLVM from building correctly. Several workarounds have been
introduced into LLVM build system, but the bug can occur anytime in the
future. We highly recommend that you rebuild your current binutils with the
patch from <a href="http://sourceware.org/bugzilla/show_bug.cgi?id=2659">
Binutils bugzilla</a>, if it wasn't already applied.</li>
</ol>
</div>
@@ -351,7 +333,7 @@ href="CFEBuildInstrs.html">try to compile it</a> on your platform.</p>
is the usual name for the software package that LLVM depends on. The Version
column provides "known to work" versions of the package. The Notes column
describes how LLVM uses the package and provides other details.</p>
<table summary="Packages required to compile LLVM">
<table>
<tr><th>Package</th><th>Version</th><th>Notes</th></tr>
<tr>
@@ -380,7 +362,7 @@ href="CFEBuildInstrs.html">try to compile it</a> on your platform.</p>
<tr>
<td><a href="http://www.gnu.org/software/bison/bison.html">Bison</a></td>
<td>1.28, 1.35, 1.75, 1.875d, 2.0, or 2.1<br>(not 1.85 or 1.875)</td>
<td>1.35</td>
<td>YACC compiler</td>
</tr>
@@ -443,7 +425,7 @@ href="CFEBuildInstrs.html">try to compile it</a> on your platform.</p>
<p><b>Notes:</b></p>
<div class="doc_notes">
<ol>
<li><a name="sf1">Only the C and C++ languages are needed so there's no
<li><a name="sf3">Only the C and C++ languages are needed so there's no
need to build the other languages for LLVM's purposes.</a> See
<a href="#brokengcc">below</a> for specific version info.</li>
<li><a name="sf2">You only need CVS if you intend to build from the
@@ -498,9 +480,9 @@ href="CFEBuildInstrs.html">try to compile it</a> on your platform.</p>
<p>LLVM is very demanding of the host C++ compiler, and as such tends to expose
bugs in the compiler. In particular, several versions of GCC crash when trying
to compile LLVM. We routinely use GCC 3.3.3, 3.4.0, and Apple 4.0.1
successfully with them (however, see important notes below). Other versions
of GCC will probably work as well. GCC versions listed
to compile LLVM. We routinely use GCC 3.3.3 and GCC 3.4.0 and have had success
with them (however, see below). Other versions of GCC will probably
work as well. GCC versions listed
here are known to not work. If you are using one of these versions, please try
to upgrade your GCC to something more recent. If you run into a problem with a
version of GCC not listed here, please <a href="mailto:llvmdev@cs.uiuc.edu">let
@@ -525,34 +507,8 @@ the "<tt>convert_from_eh_region_ranges_1</tt>" GCC function.</p>
possibly others) does not compile LLVM correctly (it appears that exception
handling is broken in some cases). Please download the FSF 3.3.3 or upgrade
to a newer version of GCC.</p>
<p><b>GCC 3.4.0</b> on linux/x86 (32-bit)</b>: GCC miscompiles portions of the
code generator, causing an infinite loop in the llvm-gcc build when built
with optimizations enabled (i.e. a release build).</p>
<p><b>GCC 3.4.2</b> on linux/x86 (32-bit)</b>: GCC miscompiles portions of the
code generator at -O3, as with 3.4.0. However gcc 3.4.2 (unlike 3.4.0)
correctly compiles LLVM at -O2. A work around is to build release LLVM
builds with "make ENABLE_OPTIMIZED=1 OPTIMIZE_OPTION=-O2 ..."</p>
<p><b>GCC 3.4.x</b> on X86-64/amd64</b>: GCC <a href="http://llvm.org/PR1056">
miscompiles portions of LLVM</a>.</p>
<p><b>IA-64 GCC 4.0.0</b>: The IA-64 version of GCC 4.0.0 is known to
miscompile LLVM.</p>
<p><b>Apple Xcode 2.3</b>: GCC crashes when compiling LLVM at -O3 (which is the
default with ENABLE_OPTIMIZED=1. To work around this, build with
"ENABLE_OPTIMIZED=1 OPTIMIZE_OPTION=-O2".</p>
<p><b>GCC 4.1.1</b>: GCC fails to build LLVM with template concept check errors
compiling some files. At the time of this writing, GCC mainline (4.2)
did not share the problem.</p>
<p><b>GCC 4.1.1 on X86-64/amd64</b>: GCC <a href="http://llvm.org/PR1063">
miscompiles portions of LLVM</a> when compiling llvm itself into 64-bit
code. LLVM will appear to mostly work but will be buggy, e.g. failing
portions of its testsuite.</p>
<p><b>GCC 4.1.2 on OpenSUSE</b>: Seg faults during libstdc++ build and on x86_64
platforms compiling md5.c gets a mangled constant.</p>
<p><b>GNU ld 2.16.X</b>. Some 2.16.X versions of the ld linker will produce very
long warning messages complaining that some ".gnu.linkonce.t.*" symbol was
defined in a discarded section. You can safely ignore these messages as they are
erroneous and the linkage is correct. These messages disappear using ld
2.17.</p>
</div>
@@ -593,21 +549,21 @@ All these paths are absolute:</p>
<dt>SRC_ROOT
<dd>
This is the top level directory of the LLVM source tree.
<br><br>
<p>
<dt>OBJ_ROOT
<dd>
This is the top level directory of the LLVM object tree (i.e. the
tree where object files and compiled programs will be placed. It
can be the same as SRC_ROOT).
<br><br>
<p>
<dt>LLVMGCCDIR
<dd>
This is where the LLVM GCC Front End is installed.
<p>
For the pre-built GCC front end binaries, the LLVMGCCDIR is
<tt>llvm-gcc/<i>platform</i>/llvm-gcc</tt>.
<tt>cfrontend/<i>platform</i>/llvm-gcc</tt>.
</dl>
</div>
@@ -658,19 +614,23 @@ compressed with the gzip program.
<dt><tt>llvm-test-x.y.tar.gz</tt></dt>
<dd>Source release for the LLVM test suite.</dd>
<dt><tt>llvm-gcc4-x.y.source.tar.gz</tt></dt>
<dd>Source release of the llvm-gcc4 front end. See README.LLVM in the root
directory for build instructions.<br/></dd>
<dt><tt>cfrontend-x.y.source.tar.gz</tt></dt>
<dd>Source release of the GCC front end.<br/></dd>
<dt><tt>llvm-gcc4-x.y-platform.tar.gz</tt></dt>
<dd>Binary release of the llvm-gcc4 front end for a specific platform.<br/></dd>
<dt><tt>cfrontend-x.y.sparc-sun-solaris2.8.tar.gz</tt></dt>
<dd>Binary release of the GCC front end for Solaris/Sparc.
<br/></dd>
<dt><tt>cfrontend-x.y.i686-redhat-linux-gnu.tar.gz</tt></dt>
<dd>Binary release of the GCC front end for Linux/x86.<br/></dd>
<dt><tt>cfrontend-x.y.i386-unknown-freebsd5.1.tar.gz</tt></dt>
<dd>Binary release of the GCC front end for FreeBSD/x86.<br/></dd>
<dt><tt>cfrontend-x.y.powerpc-apple-darwin7.8.0.tar.gz</tt></dt>
<dd>Binary release of the GCC front end for MacOS X/PPC.<br/></dd>
</dl>
<p>It is also possible to download the sources of the llvm-gcc4 front end from a
read-only subversion mirror at
svn://anonsvn.opensource.apple.com/svn/llvm/trunk. </p>
</div>
<!-- ======================================================================= -->
@@ -686,9 +646,9 @@ follows:</p>
<ul>
<li><tt>cd <i>where-you-want-llvm-to-live</i></tt>
<li><tt>cvs -d :pserver:anon@llvm.org:/var/cvs/llvm login</tt>
<li><tt>cvs -d :pserver:anon@llvm-cvs.cs.uiuc.edu:/var/cvs/llvm login</tt>
<li>Hit the return key when prompted for the password.
<li><tt>cvs -z3 -d :pserver:anon@llvm.org:/var/cvs/llvm co
<li><tt>cvs -z3 -d :pserver:anon@llvm-cvs.cs.uiuc.edu:/var/cvs/llvm co
llvm</tt>
</ul>
@@ -701,9 +661,6 @@ revision), you can specify a label. The following releases have the following
labels:</p>
<ul>
<li>Release 1.9: <b>RELEASE_19</b></li>
<li>Release 1.8: <b>RELEASE_18</b></li>
<li>Release 1.7: <b>RELEASE_17</b></li>
<li>Release 1.6: <b>RELEASE_16</b></li>
<li>Release 1.5: <b>RELEASE_15</b></li>
<li>Release 1.4: <b>RELEASE_14</b></li>
@@ -717,16 +674,38 @@ labels:</p>
you get it from the CVS repository:</p>
<pre>
cd llvm/projects
cvs -z3 -d :pserver:anon@llvm.org:/var/cvs/llvm co llvm-test
cvs -z3 -d :pserver:anon@llvm-cvs.cs.uiuc.edu:/var/cvs/llvm co llvm-test
</pre>
<p>By placing it in the <tt>llvm/projects</tt>, it will be automatically
configured by the LLVM configure script as well as automatically updated when
you run <tt>cvs update</tt>.</p>
<p>If you would like to get the GCC front end source code, you can also get it
and build it yourself. Please follow <a href="CFEBuildInstrs.html">these
instructions</a> to successfully get and build the LLVM GCC front-end.</p>
<p>If you would like to get the GCC front end source code, you can also get it
from the CVS repository:</p>
<pre>
cvs -z3 -d :pserver:anon@llvm-cvs.cs.uiuc.edu:/var/cvs/llvm co llvm-gcc
</pre>
<p>Please note that you must follow <a href="CFEBuildInstrs.html">these
instructions</a> to successfully build the LLVM GCC front-end.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsubsection">
<a name="mirrors">LLVM CVS Mirrors</a>
</div>
<div class="doc_text">
<p>If the main CVS server is overloaded or inaccessible, you can try one of
these user-hosted mirrors:</p>
<ul>
<li><a href="http://llvm.x10sys.com/">Mirror hosted by eXtensible Systems
Inc.</a></li>
</ul>
</div>
<!-- ======================================================================= -->
@@ -736,27 +715,23 @@ instructions</a> to successfully get and build the LLVM GCC front-end.</p>
<div class="doc_text">
<p>Before configuring and compiling the LLVM suite, you can optionally extract the
LLVM GCC front end from the binary distribution. It is used for running the
llvm-test testsuite and for compiling C/C++ programs. Note that you can optionally
<a href="CFEBuildInstrs.html">build llvm-gcc yourself</a> after building the
main LLVM repository.</p>
<p>Before configuring and compiling the LLVM suite, you need to extract the LLVM
GCC front end from the binary distribution. It is used for building the
bytecode libraries later used by the GCC front end for linking programs, and its
location must be specified when the LLVM suite is configured.</p>
<p>To install the GCC front end, do the following:</p>
<ol>
<li><tt>cd <i>where-you-want-the-front-end-to-live</i></tt></li>
<li><tt>gunzip --stdout llvmgcc-<i>version</i>.<i>platform</i>.tar.gz | tar -xvf
<li><tt>gunzip --stdout cfrontend-<i>version</i>.<i>platform</i>.tar.gz | tar -xvf
-</tt></li>
</ol>
<p>Once the binary is uncompressed, you should add a symlink for llvm-gcc and
llvm-g++ to some directory in your path. When you configure LLVM, it will
automatically detect llvm-gcc's presence (if it is in your path) enabling its
use in llvm-test. Note that you can always build or install llvm-gcc at any
pointer after building the main LLVM repository: just reconfigure llvm and
llvm-test will pick it up.
</p>
<p>Next, you will need to fix your system header files:</p>
<p><tt>cd cfrontend/<i>platform</i><br>
./fixheaders</tt></p>
<p>The binary versions of the GCC front end may not suit all of your needs. For
example, the binary distribution may include an old version of a system header
@@ -765,7 +740,7 @@ linked with libraries not available on your system.</p>
<p>In cases like these, you may want to try <a
href="CFEBuildInstrs.html">building the GCC front end from source.</a> This is
much easier now than it was in the past.</p>
not for the faint of heart, so be forewarned.</p>
</div>
@@ -785,7 +760,7 @@ the Makefiles needed to begin building LLVM.</p>
<p>The following environment variables are used by the <tt>configure</tt>
script to configure the build system:</p>
<table summary="LLVM configure script environment variables">
<table>
<tr><th>Variable</th><th>Purpose</th></tr>
<tr>
<td>CC</td>
@@ -827,19 +802,14 @@ script to configure the build system:</p>
dejagnu based test suite in <tt>llvm/test</tt>. If you don't specify this
option, the LLVM configure script will search for the tcl 8.4 and 8.3
releases.
<br><br>
<p></p>
</dd>
<dt><i>--enable-optimized</i></dt>
<dd>
Enables optimized compilation by default (debugging symbols are removed
and GCC optimization flags are enabled). The default is to use an
unoptimized build (also known as a debug build).
<br><br>
</dd>
<dt><i>--enable-debug-runtime</i></dt>
<dd>
Enables debug symbols in the runtime libraries. The default is to strip
debug symbols from the runtime libraries.
<p></p>
</dd>
<dt><i>--enable-jit</i></dt>
<dd>
@@ -847,7 +817,7 @@ script to configure the build system:</p>
available
on all platforms. The default is dependent on platform, so it is best
to explicitly enable it if you want it.
<br><br>
<p></p>
</dd>
<dt><i>--enable-targets=</i><tt>target-option</tt></dt>
<dd>Controls which targets will be built and linked into llc. The default
@@ -858,17 +828,12 @@ script to configure the build system:</p>
separated list of target names that you want available in llc. The target
names use all lower case. The current set of targets is: <br/>
<tt>alpha, ia64, powerpc, skeleton, sparc, x86</tt>.
<br><br></dd>
<p></p></dd>
<dt><i>--enable-doxygen</i></dt>
<dd>Look for the doxygen program and enable construction of doxygen based
documentation from the source code. This is disabled by default because
generating the documentation can take a long time and producess 100s of
megabytes of output.</dd>
<dt><i>--with-udis86</i></dt>
<dd>LLVM can use external disassembler library for various purposes (now it's
used only for examining code produced by JIT). This option will enable usage
of <a href="http://udis86.sourceforge.net/">udis86</a> x86 (both 32 and 64
bits) disassembler library.</dd>
</dl>
<p>To configure LLVM, follow these steps:</p>
@@ -877,12 +842,12 @@ script to configure the build system:</p>
<li>Change directory into the object root directory:
<br>
<tt>cd <i>OBJ_ROOT</i></tt>
<br><br>
<p>
<li>Run the <tt>configure</tt> script located in the LLVM source tree:
<br>
<tt><i>SRC_ROOT</i>/configure --prefix=/install/path [other options]</tt>
<br><br>
<p>
</ol>
</div>
@@ -904,7 +869,7 @@ builds:</p>
<tt>--enable-optimized</tt> option was used during configuration). The
build system will compile the tools and libraries with debugging
information.
<br><br>
<p>
<dt>Release (Optimized) Builds
<dd>
@@ -913,7 +878,7 @@ builds:</p>
<tt>gmake</tt> command line. For these builds, the build system will
compile the tools and libraries with GCC optimizations enabled and strip
debugging information from the libraries and executables it generates.
<br><br>
<p>
<dt>Profile Builds
<dd>
@@ -946,14 +911,14 @@ source code:</p>
<dd>
Removes all files generated by the build. This includes object files,
generated C/C++ files, libraries, and executables.
<br><br>
<p>
<dt><tt>gmake dist-clean</tt>
<dd>
Removes everything that <tt>gmake clean</tt> does, but also removes files
generated by <tt>configure</tt>. It attempts to return the source tree to the
original state in which it was shipped.
<br><br>
<p>
<dt><tt>gmake install</tt>
<dd>
@@ -961,15 +926,15 @@ source code:</p>
hierarchy
under $PREFIX, specified with <tt>./configure --prefix=[dir]</tt>, which
defaults to <tt>/usr/local</tt>.
<br><br>
<p>
<dt><tt>gmake -C runtime install-bytecode</tt>
<dd>
Assuming you built LLVM into $OBJDIR, when this command is run, it will
install bytecode libraries into the GCC front end's bytecode library
directory. If you need to update your bytecode libraries,
this is the target to use once you've built them.
<br><br>
<p>
</dl>
<p>Please see the <a href="MakefileGuide.html">Makefile Guide</a> for further
@@ -983,27 +948,22 @@ declaring variables on the command line. The following are some examples:</p>
<dt><tt>gmake ENABLE_OPTIMIZED=1</tt>
<dd>
Perform a Release (Optimized) build.
<br><br>
<dt><tt>gmake ENABLE_OPTIMIZED=1 DISABLE_ASSERTIONS=1</tt>
<dd>
Perform a Release (Optimized) build without assertions enabled.
<br><br>
<p>
<dt><tt>gmake ENABLE_PROFILING=1</tt>
<dd>
Perform a Profiling build.
<br><br>
<p>
<dt><tt>gmake VERBOSE=1</tt>
<dd>
Print what <tt>gmake</tt> is doing on standard output.
<br><br>
<p>
<dt><tt>gmake TOOL_VERBOSE=1</tt></dt>
<dd>Ask each tool invoked by the makefiles to print out what it is doing on
the standard output. This also implies <tt>VERBOSE=1</tt>.
<br><br></dd>
<p></dd>
</dl>
<p>Every directory in the LLVM object tree includes a <tt>Makefile</tt> to build
@@ -1013,51 +973,6 @@ that directory that is out of date.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="cross-compile">Cross-Compiling LLVM</a>
</div>
<div class="doc_text">
<p>It is possible to cross-compile LLVM. That is, you can create LLVM
executables and libraries for a platform different than the one one which you
are compiling. To do this, a few additional steps are
required. <sup><a href="#ccn_1">1</a></sup> To cross-compile LLVM, use
these instructions:</p>
<ol>
<li>Configure and build LLVM as a native compiler. You will need
just <tt>TableGen</tt> from that build.
<ul>
<li>If you have <tt>$LLVM_OBJ_ROOT=$LLVM_SRC_ROOT</tt> just execute
<tt>make -C utils/TableGen</tt> after configuring.</li>
<li>Otherwise you will need to monitor building process and terminate
it just after <tt>TableGen</tt> was built.</li>
</ul>
</li>
<li>Copy the TableGen binary to somewhere safe (out of your build tree).
</li>
<li>Configure LLVM to build with a cross-compiler. To do this, supply the
configure script with <tt>--build</tt> and <tt>--host</tt> options that
are different. The values of these options must be legal target triples
that your GCC compiler supports.</li>
<li>Put the saved <tt>TableGen</tt> executable into the
into <tt>$LLVM_OBJ_ROOT/{BUILD_TYPE}/bin</tt> directory (e.g. into
<tt>.../Release/bin</tt> for a Release build).</li>
<li>Build LLVM as usual.</li>
</ol>
<p>The result of such a build will produce executables that are not executable
on your build host (--build option) but can be executed on your compile host
(--host option).</p>
<p><b>Notes:</b></p>
<div class="doc_notes">
<ol>
<li><a name="ccn_1">Cross-compiling</a> was tested only with Linux as
build platform and Windows as host using mingw32 cross-compiler. Other
combinations have not been tested.</li>
</ol>
</div>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="objfiles">The Location of LLVM Object Files</a>
@@ -1094,7 +1009,7 @@ named after the build type:</p>
<dt>Libraries
<dd><tt><i>OBJ_ROOT</i>/Debug/lib</tt>
</dl>
<br><br>
<p>
<dt>Release Builds
<dd>
@@ -1104,7 +1019,7 @@ named after the build type:</p>
<dt>Libraries
<dd><tt><i>OBJ_ROOT</i>/Release/lib</tt>
</dl>
<br><br>
<p>
<dt>Profile Builds
<dd>
@@ -1160,7 +1075,7 @@ Cummings for pointing this out!
<p>One useful source of information about the LLVM source base is the LLVM <a
href="http://www.doxygen.org">doxygen</a> documentation available at <tt><a
href="http://llvm.org/doxygen/">http://llvm.org/doxygen/</a></tt>.
href="http://llvm.cs.uiuc.edu/doxygen/">http://llvm.cs.uiuc.edu/doxygen/</a></tt>.
The following is a brief introduction to code layout:</p>
</div>
@@ -1240,8 +1155,8 @@ different <a href="#tools">tools</a>.</p>
<dt><tt><b>llvm/lib/Target/</b></tt></dt>
<dd> This directory contains files that describe various target architectures
for code generation. For example, the <tt>llvm/lib/Target/X86</tt>
directory holds the X86 machine description while
for code generation. For example, the <tt>llvm/lib/Target/SparcV9</tt>
directory holds the Sparc machine description while
<tt>llvm/lib/Target/CBackend</tt> implements the LLVM-to-C converter.</dd>
<dt><tt><b>llvm/lib/CodeGen/</b></tt></dt>
@@ -1324,6 +1239,11 @@ following is a brief introduction to the most important tools. More detailed
information is in the <a href="CommandGuide/index.html">Command Guide</a>.</p>
<dl>
<dt><tt><b>analyze</b></tt></dt>
<dd><tt>analyze</tt> is used to run a specific
analysis on an input LLVM bytecode file and print out the results. It is
primarily useful for debugging analyses, or familiarizing yourself with
what an analysis does.</dd>
<dt><tt><b>bugpoint</b></tt></dt>
<dd><tt>bugpoint</tt> is used to debug
@@ -1357,10 +1277,11 @@ information is in the <a href="CommandGuide/index.html">Command Guide</a>.</p>
LLVM assembly.</dd>
<dt><tt><b>llvm-ld</b></tt></dt>
<dd><tt>llvm-ld</tt> is a general purpose and extensible linker for LLVM.
This is the linker invoked by <tt>llvmc</tt>. It performsn standard link time
optimizations and allows optimization modules to be loaded and run so that
language specific optimizations can be applied at link time.</dd>
<dd><tt>llvm-ld</tt> is very similar to gccld and provides a general purpose
and extensible linker for LLVM. This is the linker invoked by <tt>llvmc</tt>.
It allows optimization modules to be loaded so that language specific
optimizations can be applied at link time. This tool is considered
experimental.</dd>
<dt><tt><b>llvm-link</b></tt></dt>
<dd><tt>llvm-link</tt>, not surprisingly, links multiple LLVM modules into
@@ -1382,22 +1303,43 @@ information is in the <a href="CommandGuide/index.html">Command Guide</a>.</p>
the -march=c option).</dd>
<dt><tt><b>llvm-gcc</b></tt></dt>
<dd><tt>llvm-gcc</tt> is a GCC-based C frontend that has been retargeted to
use LLVM as its backend instead of GCC's RTL backend. It can also emit LLVM
byte code or assembly (with the <tt>-emit-llvm</tt> option) instead of the
usual machine code output. It works just like any other GCC compiler,
taking the typical <tt>-c, -S, -E, -o</tt> options that are typically used.
Additionally, the the source code for <tt>llvm-gcc</tt> is available as a
separate CVS module.</dd>
<dd><tt>llvm-gcc</tt> is a GCC-based C frontend
that has been retargeted to emit LLVM code as the machine code output. It
works just like any other GCC compiler, taking the typical <tt>-c, -S, -E,
-o</tt> options that are typically used. The source code for the
<tt>llvm-gcc</tt> tool is available as a separate CVS module.
<blockquote>
<dl>
<dt><tt><b>gccas</b></tt></dt>
<dd>This tool is invoked by the <tt>llvm-gcc</tt> 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
<tt>llvm-gcc -c x.c -o x.o</tt>, you are causing <tt>gccas</tt> to be
run, which writes the <tt>x.o</tt> file (which is an LLVM bytecode file
that can be disassembled or manipulated just like any other bytecode
file). The command line interface to <tt>gccas</tt> is designed to be
as close as possible to the <b>system</b> `<tt>as</tt>' utility so that
the gcc frontend itself did not have to be modified to interface to
a "weird" assembler.</dd>
<dt><tt><b>gccld</b></tt></dt>
<dd><tt>gccld</tt> 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 <tt>gccas</tt>, the command line interface of <tt>gccld</tt> is
designed to match the system linker, to aid interfacing with the GCC
frontend.</dd>
</dl>
</blockquote>
</dd>
<dt><tt><b>opt</b></tt></dt>
<dd><tt>opt</tt> reads LLVM bytecode, applies a series of LLVM to LLVM
transformations (which are specified on the command line), and then outputs
the resultant bytecode. The '<tt>opt --help</tt>' command is a good way to
get a list of the program transformations available in LLVM.<br/>
<dd><tt>opt</tt> can also be used to run a specific analysis on an input
LLVM bytecode file and print out the results. It is primarily useful for
debugging analyses, or familiarizing yourself with what an analysis does.</dd>
<dd><tt>opt</tt> reads LLVM bytecode, applies a
series of LLVM to LLVM transformations (which are specified on the command
line), and then outputs the resultant bytecode. The '<tt>opt --help</tt>'
command is a good way to get a list of the program transformations
available in LLVM.</dd>
</dl>
</div>
@@ -1410,11 +1352,16 @@ of the utilities are actually required as part of the build process because they
are code generators for parts of LLVM infrastructure.</p>
<dl>
<dt><tt><b>Burg/</b></tt> <dd><tt>Burg</tt> is an instruction selector
generator -- it builds trees on which it then performs pattern-matching to
select instructions according to the patterns the user has specified. Burg
is currently used in the Sparc V9 backend.<p>
<dt><tt><b>codegen-diff</b></tt> <dd><tt>codegen-diff</tt> is a script
that finds differences between code that LLC generates and code that LLI
generates. This is a useful tool if you are debugging one of them,
assuming that the other generates correct output. For the full user
manual, run <tt>`perldoc codegen-diff'</tt>.<br><br>
manual, run <tt>`perldoc codegen-diff'</tt>.<p>
<dt><tt><b>cvsupdate</b></tt> <dd><tt>cvsupdate</tt> is a script that will
update your CVS tree, but produce a much cleaner and more organized output
@@ -1422,21 +1369,21 @@ are code generators for parts of LLVM infrastructure.</p>
together all the new and updated files and modified files in separate
sections, so you can see at a glance what has changed. If you are at the
top of your LLVM CVS tree, running <tt>utils/cvsupdate</tt> is the
preferred way of updating the tree.<br><br>
preferred way of updating the tree.<p>
<dt><tt><b>emacs/</b></tt> <dd>The <tt>emacs</tt> directory contains
syntax-highlighting files which will work with Emacs and XEmacs editors,
providing syntax highlighting support for LLVM assembly files and TableGen
description files. For information on how to use the syntax files, consult
the <tt>README</tt> file in that directory.<br><br>
the <tt>README</tt> file in that directory.<p>
<dt><tt><b>getsrcs.sh</b></tt> <dd>The <tt>getsrcs.sh</tt> script finds
and outputs all non-generated source files, which is useful if one wishes
to do a lot of development across directories and does not want to
individually find each file. One way to use it is to run, for example:
<tt>xemacs `utils/getsources.sh`</tt> from the top of your LLVM source
tree.<br><br>
tree.<p>
<dt><tt><b>llvmgrep</b></tt></dt>
<dd>This little tool performs an "egrep -H -n" on each source file in LLVM and
passes to it a regular expression provided on <tt>llvmgrep</tt>'s command
@@ -1449,24 +1396,24 @@ are code generators for parts of LLVM infrastructure.</p>
<tt>llvm/lib/Target/Sparc</tt>, if <tt>makellvm</tt> is in your path,
simply running <tt>makellvm llc</tt> will make a build of the current
directory, switch to directory <tt>llvm/tools/llc</tt> and build it,
causing a re-linking of LLC.<br><br>
causing a re-linking of LLC.<p>
<dt><tt><b>NightlyTest.pl</b></tt> and
<tt><b>NightlyTestTemplate.html</b></tt> <dd>These files are used in a
cron script to generate nightly status reports of the functionality of
tools, and the results can be seen by following the appropriate link on
the <a href="http://llvm.org/">LLVM homepage</a>.<br><br>
the <a href="http://llvm.cs.uiuc.edu/">LLVM homepage</a>.<p>
<dt><tt><b>TableGen/</b></tt> <dd>The <tt>TableGen</tt> directory contains
the tool used to generate register descriptions, instruction set
descriptions, and even assemblers from common TableGen description
files.<br><br>
files.<p>
<dt><tt><b>vim/</b></tt> <dd>The <tt>vim</tt> directory contains
syntax-highlighting files which will work with the VIM editor, providing
syntax highlighting support for LLVM assembly files and TableGen
description files. For information on how to use the syntax files, consult
the <tt>README</tt> file in that directory.<br><br>
the <tt>README</tt> file in that directory.<p>
</dl>
@@ -1487,22 +1434,6 @@ are code generators for parts of LLVM infrastructure.</p>
</div>
<!-- *********************************************************************** -->
<div class="doc_text">
<p>This section gives an example of using LLVM. llvm-gcc3 is now obsolete,
so we only include instructiosn for llvm-gcc4.
</p>
<p><b>Note:</b> The <i>gcc4</i> frontend's invocation is <b><i>considerably different</i></b>
from the previous <i>gcc3</i> frontend. In particular, the <i>gcc4</i> frontend <b><i>does not</i></b>
create bytecode by default: <i>gcc4</i> produces native code. As the example below illustrates,
the '--emit-llvm' flag is needed to produce LLVM bytecode output. For <i>makefiles</i> and
<i>configure</i> scripts, the CFLAGS variable needs '--emit-llvm' to produce bytecode
output.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection"><a name="tutorial4">Example with llvm-gcc4</a></div>
<div class="doc_text">
<ol>
@@ -1515,40 +1446,33 @@ output.</p>
}
</pre></li>
<li><p>Next, compile the C file into a native executable:</p>
<li><p>Next, compile the C file into a LLVM bytecode file:</p>
<p><tt>% llvm-gcc hello.c -o hello</tt></p>
<p>Note that llvm-gcc works just like GCC by default. The standard -S and
-c arguments work as usual (producing a native .s or .o file,
respectively). </p>
<p>Note that you should have already built the tools and they have to be
in your path, at least <tt>gccas</tt> and <tt>gccld</tt>.</p>
<li><p>Next, compile the C file into a LLVM bytecode file:</p>
<p><tt>% llvm-gcc -O3 -emit-llvm hello.c -c -o hello.bc</tt></p>
<p>This will create two result files: <tt>hello</tt> and
<tt>hello.bc</tt>. The <tt>hello.bc</tt> is the LLVM bytecode that
corresponds the the compiled program and the library facilities that it
required. <tt>hello</tt> is a simple shell script that runs the bytecode
file with <tt>lli</tt>, making the result directly executable. Note that
all LLVM optimizations are enabled by default, so there is no need for a
"-O3" switch.</p></li>
<p>The -emit-llvm option can be used with the -S or -c options to emit an
LLVM ".ll" or ".bc" file (respectively) for the code. This allows you
to use the <a href="CommandGuide/index.html">standard LLVM tools</a> on
the bytecode file.</p>
<p>Unlike llvm-gcc3, llvm-gcc4 correctly responds to -O[0123] arguments.
</p></li>
<li><p>Run the program in both forms. To run the program, use:</p>
<li><p>Run the program. To make sure the program ran, execute one of the
following commands:</p>
<p><tt>% ./hello</tt></p>
<p>and</p>
<p>or</p>
<p><tt>% lli hello.bc</tt></p>
<p>The second examples shows how to invoke the LLVM JIT, <a
href="CommandGuide/html/lli.html">lli</a>.</p></li>
<p><tt>% lli hello.bc</tt></p></li>
<li><p>Use the <tt>llvm-dis</tt> utility to take a look at the LLVM assembly
code:</p>
<p><tt>% llvm-dis &lt; hello.bc | less</tt><br><br></li>
<p><tt>% llvm-dis &lt; hello.bc | less</tt><p></li>
<li><p>Compile the program to native assembly using the LLC code
generator:</p>
@@ -1562,17 +1486,12 @@ output.</p>
<li><p>Execute the native code program:</p>
<p><tt>% ./hello.native</tt></p>
<p>Note that using llvm-gcc to compile directly to native code (i.e. when
the -emit-llvm option is not present) does steps 6/7/8 for you.</p>
</li>
<p><tt>% ./hello.native</tt></p></li>
</ol>
</div>
<!-- *********************************************************************** -->
<div class="doc_section">
<a name="problems">Common Problems</a>
@@ -1602,9 +1521,9 @@ if you want to write something up!). For more information about LLVM, check
out:</p>
<ul>
<li><a href="http://llvm.org/">LLVM homepage</a></li>
<li><a href="http://llvm.org/doxygen/">LLVM doxygen tree</a></li>
<li><a href="http://llvm.org/docs/Projects.html">Starting a Project
<li><a href="http://llvm.cs.uiuc.edu/">LLVM homepage</a></li>
<li><a href="http://llvm.cs.uiuc.edu/doxygen/">LLVM doxygen tree</a></li>
<li><a href="http://llvm.cs.uiuc.edu/docs/Projects.html">Starting a Project
that Uses LLVM</a></li>
</ul>
@@ -1621,7 +1540,7 @@ out:</p>
<a href="mailto:sabre@nondot.org">Chris Lattner</a><br>
<a href="http://llvm.x10sys.com/rspencer/">Reid Spencer</a><br>
<a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br>
<a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a><br>
Last modified: $Date$
</address>
</body>

View File

@@ -99,7 +99,7 @@
<li><tt>cd llvm</tt></li>
</ol></li>
<li>With anonymous CVS access:
<li>With anonymous CVS access (or use a <a href="#mirror">mirror</a>):
<ol>
<li><tt>cd <i>where-you-want-llvm-to-live</i></tt></li>
<li><tt>cvs -d
@@ -258,26 +258,26 @@ All these paths are absolute:</p>
</pre></li>
<li><p>Next, compile the C file into a LLVM bytecode file:</p>
<p><tt>% llvm-gcc -c hello.c -emit-llvm -o hello.bc</tt></p>
<p><tt>% llvm-gcc hello.c -o hello</tt></p>
<p>This will create the result file <tt>hello.bc</tt> 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
<tt>lli</tt> tool, compile it to native assembly with the <tt>llc</tt>,
optimize or analyze it further with the <tt>opt</tt> tool, etc.</p>
<p>Note that you should have already built the tools and they have to be
in your path, at least <tt>gccas</tt> and <tt>gccld</tt>.</p>
<p>This will create two result files: <tt>hello</tt> and
<tt>hello.bc</tt>. The <tt>hello.bc</tt> is the LLVM bytecode that
corresponds the the compiled program and the library facilities that it
required. <tt>hello</tt> is a simple shell script that runs the bytecode
file with <tt>lli</tt>, making the result directly executable. Note that
all LLVM optimizations are enabled by default, so there is no need for a
"-O3" switch.</p>
<p><b>Note: while you cannot do this step on Windows, you can do it on a
Unix system and transfer <tt>hello.bc</tt> to Windows. Important:
transfer as a binary file!</b></p></li>
Unix system and transfer <tt>hello.bc</tt> to Windows.</b></p></li>
<li><p>Run the program using the just-in-time compiler:</p>
<p><tt>% lli hello.bc</tt></p></li>
<p>Note: this will only work for trivial C programs. Non-trivial programs
(and any C++ program) will have dependencies on the GCC runtime that
won't be satisfied by the Microsoft runtime libraries.</p>
<li><p>Use the <tt>llvm-dis</tt> utility to take a look at the LLVM assembly
code:</p>
@@ -291,10 +291,6 @@ All these paths are absolute:</p>
<p><tt>% cl hello.cbe.c</tt></p></li>
<p>Note: this will only work for trivial C programs. Non-trivial programs
(and any C++ program) will have dependencies on the GCC runtime that
won't be satisfied by the Microsoft runtime libraries.</p>
<li><p>Execute the native code program:</p>
<p><tt>% hello.cbe.exe</tt></p></li>
@@ -332,9 +328,9 @@ if you want to write something up!). For more information about LLVM, check
out:</p>
<ul>
<li><a href="http://llvm.org/">LLVM homepage</a></li>
<li><a href="http://llvm.org/doxygen/">LLVM doxygen tree</a></li>
<li><a href="http://llvm.org/docs/Projects.html">Starting a Project
<li><a href="http://llvm.cs.uiuc.edu/">LLVM homepage</a></li>
<li><a href="http://llvm.cs.uiuc.edu/doxygen/">LLVM doxygen tree</a></li>
<li><a href="http://llvm.cs.uiuc.edu/docs/Projects.html">Starting a Project
that Uses LLVM</a></li>
</ul>
@@ -350,7 +346,7 @@ out:</p>
src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /></a>
<a href="mailto:jeffc@jolt-lang.org">Jeff Cohen</a><br>
<a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br>
<a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a><br>
Last modified: $Date$
</address>
</body>

View File

@@ -1,526 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>How To Release LLVM To The Public</title>
<link rel="stylesheet" href="llvm.css" type="text/css">
</head>
<body>
<div class="doc_title">How To Release LLVM To The Public</div>
<p class="doc_warning">NOTE: THIS DOCUMENT IS A WORK IN PROGRESS!</p>
<ol>
<li><a href="#introduction">Introduction</a></li>
<li><a href="#process">Release Process</a></li>
<li><a href="#dist_targets">Distribution Targets</a></li>
</ol>
<div class="doc_author">
<p>Written by <a href="mailto:rspencer@x10sys.com">Reid Spencer</a>,
<a href="mailto:criswell@cs.uiuc.edu">John Criswell</a></p>
</div>
<!-- *********************************************************************** -->
<div class="doc_section"><a name="introduction">Introduction</a></div>
<!-- *********************************************************************** -->
<div class="doc_text">
<p>This document collects information about successfully releasing LLVM to the
public. It is the release manager's guide to ensuring that a high quality build
of LLVM is released. Mostly, it's just a bunch of reminders of things to do at
release time so we don't inadvertently ship something that is utility
deficient.</p>
<p>
There are three main tasks for building a release of LLVM:
<ol>
<li>Create the LLVM source distribution.</li>
<li>Create the LLVM GCC source distribtuion.</li>
<li>Create a set of LLVM GCC binary distribtuions for each supported
platform. These binary distributions must include compiled versions
of the libraries found in <tt>llvm/runtime</tt> from the LLVM
source distribution created in Step 1.</li>
</ol>
</p>
</div>
<!-- *********************************************************************** -->
<div class="doc_section"><a name="process">Release Process</a></div>
<!-- *********************************************************************** -->
<!-- ======================================================================= -->
<div class="doc_subsection"><a name="overview">Process Overview</a></div>
<div class="doc_text">
<ol>
<li><a href="#updocs">Update Documentation</a></li>
<li><a href="#merge">Merge Branches</a></li>
<li><a href="#deps">Make LibDeps.txt</a></li>
<li><a href="#settle">Settle LLVM HEAD</a></li>
<li><a href="#tag">Tag LLVM and Create the Release Branch</a></li>
<li><a href="#verchanges">Update LLVM Version </a></li>
<li><a href="#build">Build LLVM</a></li>
<li><a href="#check">Run 'make check'</a></li>
<li><a href="#test">Run LLVM Test Suite</a></li>
<li><a href="#dist">Build the LLVM Source Distributions</a></li>
<li><a href="#rpm">Build RPM Packages (optional)</a></li>
<li><a href="#llvmgccbin">Build the LLVM GCC Binary Distribution</a></li>
<li><a href="#webupdates">Update the LLVM Website</a></li>
</ol>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection"><a name="updocs">Update Documentation</a></div>
<div class="doc_text">
<p>
Review the documentation and ensure that it is up to date. The Release Notes
must be updated to reflect bug fixes, new known issues, and changes in the
list of supported platforms. The Getting Started Guide should be updated to
reflect the new release version number tag avaiable from CVS and changes in
basic system requirements.
</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection"><a name="merge">Merge Branches</a></div>
<div class="doc_text">
<p>
Merge any work done on branches intended for release into mainline. Finish and
commit all new features or bug fixes that are scheduled to go into the release.
Work that is not to be incorporated into the release should not be merged from
branchs or commited from developer's working directories.
</p>
<p>
From this point until the release branch is created, developers should
<em>not</em>
commit changes to the llvm and llvm-gcc CVS repositories unless it is a bug
fix <em>for the release</em>.
</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection"><a name="deps">Make LibDeps.txt</a></div>
<div class="doc_text">
<p>Rebuild the <tt>LibDeps.txt</tt> target in <tt>utils/llvm-config</tt>. This
makes sure that the <tt>llvm-config</tt> utility remains relevant for the
release, reflecting any changes in the library dependencies.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection"><a name="settle">Settle CVS HEAD</a></div>
<div class="doc_text">
<p>
Use the nightly test reports and 'make check' (deja-gnu based tests) to
ensure that recent changes and merged branches have not destabilized LLVM.
Platforms which are used less often should be given special attention as they
are the most likely to break from commits from the previous step.
</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection"><a name="tag">CVS Tag And Branch</a></div>
<div class="doc_text">
<p>Tag and branch the CVS HEAD using the following procedure:</p>
<ol>
<li>
Request all developers to refrain from committing. Offenders get commit
rights taken away (temporarily).
</li>
<li>
The Release Manager updates his/her llvm, llvm-test, and llvm-gcc source
trees with the
latest sources from mainline CVS. The Release Manage may want to consider
using a new working directory for this to keep current uncommitted work
separate from release work.
</li>
<li>
The Release Manager tags his/her llvm, llvm-test, and llvm-gcc working
directories with
"ROOT_RELEASE_XX" where XX is the major and minor
release numbers (you can't have . in a cvs tag name). So, for Release 1.2,
XX=12 and for Release 1.10, XX=110.
<p>
<tt>cvs tag ROOT_RELEASE_XX</tt><br>
</p>
</li>
<li>
Immediately create cvs branches based on the ROOT_RELEASE_XX tag. The tag
should be "release_XX" (where XX matches that used for the ROOT_RELEASE_XX
tag). This is where the release distribution will be created.
<p>
cvs tag -b -r ROOT_RELEASE_XX release_XX
</p>
</li>
<li>
Advise developers they can work on CVS HEAD again.
</li>
<li>
The Release Manager and any developers working on the release should switch
to the release branch (as all changes to the release will now be done in
the branch). The easiest way to do this is to grab another working copy
using the following commands:
<p>
<tt>cvs -d &lt;CVS Repository&gt; co -r release_XX llvm</tt><br>
<tt>cvs -d &lt;CVS Repository&gt; co -r release_XX llvm-test</tt><br>
<tt>cvs -d &lt;CVS Repository&gt; co -r release_XX llvm-gcc</tt><br>
</p>
</li>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection"><a name="verchanges">Update LLVM Version</a></div>
<div class="doc_text">
<p>
After creating the llvm release branch, update the release branch's autoconf/configure.ac
version from X.Xcvs to just X.X. Update it on mainline as well to be the next version
(X.X+1cvs).
</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection"><a name="build">Build LLVM</a></div>
<div class="doc_text">
<p>
Build both debug and release (optimized) versions of LLVM on all
platforms. Ensure the build is warning and error free on each platform.
</p>
<p>
Build a new version of the LLVM GCC front-end after building the LLVM tools.
Once that is complete, go back to the LLVM source tree and build and install
the <tt>llvm/runtime</tt> libraries.
</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection"><a name="check">Run 'make check'</a></div>
<div class="doc_text">
<p>Run <tt>make check</tt> and ensure there are no unexpected failures. If
there are, resolve the failures, commit them back into the release branch,
and restart testing by <a href="#build">re-building LLVM</a>.
</p>
<p>
Ensure that 'make check' passes on all platforms for all targets. If certain
failures cannot be resolved before release time, determine if marking them
XFAIL is appropriate. If not, fix the bug and go back. The test suite must
complete with "0 unexpected failures" for release.
</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection"><a name="test">LLVM Test Suite</a></div>
<div class="doc_text">
<p>Run the llvm-test suite and ensure there are no unacceptable failures.
If there are, resolve the failures and go back to
<a href="#build">re-building LLVM</a>. The test suite
should be run in Nightly Test mode. All tests must pass.
</div>
<!-- ======================================================================= -->
<div class="doc_subsection"><a name="dist">Build the LLVM Source Distributions</a></div>
<div class="doc_text">
<p>
Create source distributions for LLVM, LLVM GCC, and the LLVM Test Suite by
exporting the source
from CVS and archiving it. This can be done with the following commands:
</p>
<p>
<tt>cvs -d &lt;CVS Repository&gt; export -r release_XX llvm</tt><br>
<tt>cvs -d &lt;CVS Repository&gt; export -r release_XX llvm-test</tt><br>
<tt>cvs -d &lt;CVS Repository&gt; export -r release_XX llvm-gcc</tt><br>
<tt>mkdir cfrontend; mv llvm-gcc cfrontend/src</tt><br>
<tt>tar -cvf - llvm | gzip &gt; llvm-X.X.tar.gz</tt><br>
<tt>tar -cvf - llvm-test | gzip &gt; llvm-test-X.X.tar.gz</tt><br>
<tt>tar -cvf - cfrontend/src | gzip &gt; cfrontend-X.X.source.tar.gz</tt><br>
</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection"><a name="rpm">Building RPM packages (optional)</a></div>
<div class="doc_text">
<p>You can, optionally, create source and binary RPM packages for LLVM. These
may make it easier to get LLVM into a distribution. This can be done with
the following commands:</p>
<pre>
make dist # Build the distribution source tarball
make dist-check # Check that the source tarball can build itself.
cp llvm-M.m.tar.gz /usr/src/redhat/SOURCES # Required by rpmbuild
make srpm # for source rpm
make rpm # for binary rpm
</pre>
<p>First, use "make dist" to simply build the distribution. Any
failures need to be corrected (on the branch). Once "make dist" can be
successful, do "make dist-check". This target will do the same thing as the
'dist' target but also test that distribution to make sure it can build itself
and runs "make check" as well. This ensures that needed files are not
missing and that the src tarball can be successfully unpacked, built,
installed, and cleaned. Once you have a reliable tarball, you need to copy
it to the /usr/src/redhat/SOURCES directory which is a requirement of the
rpmbuild tool. The last two "make" invocations just run rpmbuild to build
either a source (<tt>srpm</tt>) or binary (<tt>rpm</tt>) RPM package.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection"><a name="llvmgccbin">Build the LLVM GCC Binary Distribution</a></div>
<div class="doc_text">
<p>
Creating the LLVM GCC binary distribution requires performing the following
steps for each supported platform:
</p>
<ol>
<li>
Build the LLVM GCC front-end. The LLVM GCC front-end must be installed in
a directory named <tt>cfrontend/&lt;platform&gt;/llvm-gcc</tt>. For
example, the Sparc/Solaris directory is named
<tt>cfrontend/sparc/llvm-gcc</tt>.
</li>
<li>
Build the libraries in <tt>llvm/runtime</tt> and install them into the
created LLVM GCC installation directory.
</li>
<li>
For systems with non-distributable header files (e.g. Solaris), manually
remove header files that the GCC build process has "fixed." This process
is admittedly painful, but not as bad as it looks; these header files are
almost always easily identifiable with simple grep expressions and are
installed in only a few directories in the GCC installation directory.
</li>
<li>
Add the copyright files and header file fix script.
</li>
<li>
Archive and compress the installation directory. These can be found in
previous releases of the LLVM-GCC front-end.
</li>
</ol>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection"><a name="webupdates">Update the LLVM Website</a></div>
<div class="doc_text">
<p>
Check out the llvm-www module from cvs. Create a new subdirectory X.X in the
releases directory. Place the llvm, llvm-test, llvm-gcc source, and llvm-gcc
binaries in this new directory. Copy the llvm/docs and LICENSE.txt files
into this new directory. Update the releases/download.html file with the new release.
Update the releases/index.html with the new release. Finally, update the main page (
index.html and sidebar) to point to the new release and release announcement. Make
sure this all gets commited back into cvs.
</p>
</div>
<!--
<div class="doc_subsection"><a name="release">Release</a></div>
<div class="doc_text">
<p>Release the distribution tarball to the public. This consists of generating
several tarballs. The first set, the source distributions, are automatically
generated by the "make dist" and "make dist-check". There are gzip, bzip2, and
zip versions of these bundles.</p>
<p>The second set of tarballs is the binary release. When "make dist-check"
succeeds, it will have created an _install directory into which it installed
the binary release. You need to rename that directory as "llvm" and then
create tarballs from the contents of that "llvm" directory.</p>
<p>Finally, use rpm to make an rpm package based on the llvm.spec file. Don't
forget to update the version number, documentation, etc. in the llvm.spec
file.</p>
</div>
-->
<!-- *********************************************************************** -->
<div class="doc_section"><a name="dist_targets">Distribution Targets</a></div>
<!-- *********************************************************************** -->
<!-- ======================================================================= -->
<div class="doc_subsection">Overview</div>
<div class="doc_text">
<p>The first thing you need to understand is that there are multiple make
targets to support this feature. Here's an overview, we'll delve into the
details later.</p>
<ul>
<li><b>distdir</b> - builds the distribution directory from which the
distribution will be packaged</li>
<li><b>dist</b> - builds each of the distribution tarballs (tar.gz,
tar.bzip2, .zip). These can be built individually as well, with separate
targets.</li>
<li><b>dist-check</b> - this is identical to <tt>dist</tt> but includes a
check on the distribution that ensures the tarball can: unpack successfully,
compile correctly, pass 'make check', and pass 'make clean'.</li>
<li><b>dist-clean</b>- this just does a normal clean but also cleans up the
stuff generated by the other three <tt>dist</tt> targets (above).</li>
</ul>
<p>Okay, that's the basic functionality. When making a release, we want to
ensure that the tree you build the distribution from passes
<tt>dist-check</tt>. Beyond fixing the usual bugs, there is generally one
impediment to making the release in this fashion: missing files. The
<tt>dist-check</tt> process guards against that possibility. It will either
fail and that failure will indicate what's missing, or it will succeed
meaning that it has proved that the tarballs can actually succeed in
building LLVM correctly and that it passes <tt>make check</tt>.</p>
<!-- ======================================================================= -->
<div class="doc_subsection">distdir</div>
<p>This target builds the distribution directory which is the directory from
which the tarballs are generated. The distribution directory has the same
name as the release, e.g. LLVM-1.7). This target goes through the following
process:
<ol>
<li>First, if there was an old distribution directory (for the current
release), it is removed in its entirety and you see <tt>Removing old
LLVM-1.7</tt></li>
<li>Second, it issues a <tt>make all ENABLE_OPTIMIZED=3D1</tt> to ensure
that the everything in your tree can be built in release mode. Often times
there are discrepancies in building between debug and release modes so it
enforces release mode first. If that fails, the <tt>distdir</tt> target
fails too. This is preceded by the message <tt>Making 'all' to verify
build</tt>.</li>
<li>Next, it traverses your source tree and copies it to a new directory
that has the name of the release (<tt>LLVM-M.m</tt> in our current case).
This is the directory that will get tar'd. It contains all the software
that needs to be in the distribution. During the copying process, it omits
generated files, CVS directories, and any other "cruft" that's in your
build tree. This is done to eliminate the possibility of huge distribution
tarballs that include useless or irrelevant stuff in them. This is the
trickiest part of making the distribution. Done manually you will either
include stuff that shouldn't be in the distribution or exclude stuff that
should. This step is preceded by the message <tt>Building Distribution
Directory LLVM-1.7</tt></li>
<li>The distribution directory is then traversed and all <tt>CVS</tt> or
<tt>.svn</tt> directories are removed. You see: <tt>Eliminating CVS/.svn
directories from distribution</tt></li>
<li>The recursive <tt>dist-hook</tt> target is executed. This gives each
directory a chance to modify the distribution in some way (more on this
below).</li>
<li>The distribution directory is traversed and the correct file
permissions and modes are set based on the type of file.</li>
</ol>
<p>To control the process of making the distribution directory correctly,
each Makefile can utilize two features:</p>
<ol>
<li><b><tt>EXTRA_DIST</tt></B> - this make variable specifies which files
it should distribute. By default, all source files are automatically
included for distribution as well as certain <tt>well known</tt> files
(see DistAlways variable in Makefile.rules for details). Each Makefile
specifies, via the <tt>EXTRA_DIST</tt> variable, which additional files
need to be distributed. Only those files that are needed to build LLVM
should be added to <tt>EXTRA_DIST</tt>. <tt>EXTRA_DIST</tt> contains a
list of file or directory names that should be distributed. For example,
the top level Makefile contains
<tt>EXTRA_DIST := test llvm.spec include</tt>.
This means that in addition to regular things that are distributed at the
top level (<tt>CREDITS.txt, LICENSE.txt</tt>, etc.) the distribution should
contain the entire <tt>test</tt> and <tt>include</tt> directories as well
as the <tt>llvm.spec</tt> file.</li>
<li><b><tt>dist-hook</tt></B> - this make target can be used to alter the
content of the distribution directory. For example, in the top level
Makefile there is some logic to eliminate files in the <tt>include</tt>
subtree that are generated by the configure script. These should not be
distributed. Similarly, any <tt>dist-hook</tt> target found in any
directory can add or remove or modify things just before it gets packaged.
Any transformation is permitted. Generally, not much is needed.
</ol>
<p>You will see various messages if things go wrong:</p>
<ol>
<li>During the copying process, any files that are missing will be flagged
with: <tt>===== WARNING: Distribution Source 'dir/file' Not Found!</tt>
These must be corrected by either adding the file or removing it from
<tt>EXTRA_DIST</tt>.
<li>If you build the distribution with <tt>VERBOSE=1</tt>, then you might
also see: <tt>Skipping non-existent 'dir/file'</tt> in certain cases where
its okay to skip the file.</li>
<li>The target can fail if any of the things it does fail. Error messages
should indicate what went wrong.</li>
</ol>
<!-- ======================================================================= -->
<div class="doc_subsection">dist</div>
<p>This target does exactly what <tt>distdir</tt> target does, but also
includes assembling the tarballs. There are actually four related targets
here:<p>
<ul>
<li><b><tt>dist-gzip</tt></b>: package the gzipped distribution tar
file. The distribution directory is packaged into a single file ending in
<tt>.tar.gz</tt> which is gzip compressed.</li>
<li><b><tt>dist-bzip2</tt></b>: package the bzip2 distribution tar file.
The distribution directory is packaged into a single file ending in
<tt>.tar.bzip2</tt> which is bzip2 compressed.</li>
<li><b><tt>dist-zip</tt></b>: package the zip distribution file. The
distribution directory is packaged into a single file ending in
<tt>.zip</tt> which is zip compressed.</li>
<li><b><tt>dist</tt></b>: does all three, dist-gzip, dist-bzip2,
dist-zip</li>
</ul>
<!-- ======================================================================= -->
<div class="doc_subsection">dist-check</div>
<p>This target checks the distribution. The basic idea is that it unpacks the
distribution tarball and ensures that it can build. It takes the following
actions:</p>
<ol>
<li>It depends on the <tt>dist-gzip</tt> target which, if it hasn't already
been built, builds the gzip tar bundle (see dist and distdir above).</li>
<li>removes any pre-existing <tt>_distcheckdir</tt> at the top level.</li>
<li>creates a new <tt>_distcheckdir</tt> directory at the top level.</li>
<li>creates a <tt>build</tt> subdirectory and an <tt>install</tt>
subdirectory under <tt>_distcheckdir</tt>.</li>
<li>unzips and untars the release tarball into <tt>_distcheckdir</tt>,
creating <tt>LLVM-1.7</tt> directory (from the tarball).</li>
<li>in the build subdirectory, it configures with appropriate options to build
from the unpacked source tarball into the <tt>build</tt> directory with
installation in the <tt>install</tt> directory.</li>
<li>runs <tt>make all</tt></li>
<li>runs <tt>make </tt><tt>check</tt></li>
<li>runs <tt>make install</tt></li>
<li>runs <tt>make uninstall</tt></li>
<li>runs <tt>make dist</tt></li>
<li>runs <tt>make clean</tt></li>
<li>runs <tt>make dist-clean</tt></li>
</ol>
<p>If it can pass all that, the distribution will be deemed distribution
worth y and you will see:<p>
<pre>===== LLVM-1.7.tar.gz Ready For Distribution =====</pre>
<p>This means the tarball should then be tested on other platforms and have the
nightly test run against it. If those all pass, THEN it is ready for
distribution.</p>
<p>
A note about disk space: using <tt>dist-check</tt> will easily triple the
amount of disk space your build tree is using. You might want to check
available space before you begin.</p>
<!-- ======================================================================= -->
<div class="doc_subsection">dist-clean</div>
<h2>dist-clean</h2>
<p>In addition to doing a normal <tt>clean</tt>, this target will clean up the
files and directories created by the distribution targets. In particular the
distribution directory <tt>(LLVM-X.X</tt>), check directory
(<tt>_distcheckdir</tt>), and the various tarballs will be removed. You do
this after the release has shipped and you no longer need this stuff in your
build tree.</p>
</div>
<!-- *********************************************************************** -->
<hr>
<address>
<a href="http://jigsaw.w3.org/css-validator/check/referer"><img
src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a>
<a href="http://validator.w3.org/check/referer"><img
src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /></a>
<a href="mailto:rspencer@x10sys.com">Reid Spencer</a><br>
<a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
<br/>
Last modified: $Date$
</address>
</body>
</html>

View File

@@ -19,8 +19,9 @@
<li><a href="#crashers">Crashing Bugs</a>
<ul>
<li><a href="#front-end">Front-end bugs</a>
<li><a href="#ct_optimizer">Compile-time optimization bugs</a>
<li><a href="#ct_codegen">Code generator bugs</a>
<li><a href="#gccas">GCCAS bugs</a>
<li><a href="#gccld">GCCLD bugs</a>
<li><a href="#passes">Bugs in LLVM passes</a>
</ul></li>
<li><a href="#miscompilations">Miscompilations</a></li>
<li><a href="#codegen">Incorrect code generation (JIT and LLC)</a></li>
@@ -50,18 +51,15 @@ getting it fixed quickly.</p>
<p>Basically you have to do two things at a minimum. First, decide whether the
bug <a href="#crashers">crashes the compiler</a> (or an LLVM pass), or if the
compiler is <a href="#miscompilations">miscompiling</a> the program (i.e., the
compiler successfully produces an executable, but it doesn't run right). Based
on
compiler is <a href="#miscompilations">miscompiling</a> the program. Based on
what type of bug it is, follow the instructions in the linked section to narrow
down the bug so that the person who fixes it will be able to find the problem
more easily.</p>
<p>Once you have a reduced test-case, go to <a
href="http://llvm.org/bugs/enter_bug.cgi">the LLVM Bug Tracking
System</a> and fill out the form with the necessary details (note that you don't
need to pick a catagory, just use the "new-bugs" catagory if you're not sure).
The bug description should contain the following
href="http://llvm.cs.uiuc.edu/bugs/enter_bug.cgi">the LLVM Bug Tracking
System</a>, select the category in which the bug falls, and fill out the form
with the necessary details. The bug description should contain the following
information:</p>
<ul>
@@ -83,29 +81,35 @@ information:</p>
<div class="doc_text">
<p>More often than not, bugs in the compiler cause it to crash&mdash;often due
to an assertion failure of some sort. The most important
piece of the puzzle is to figure out if it is crashing in the GCC front-end
or if it is one of the LLVM libraries (e.g. the optimizer or code generator)
that has problems.</p>
<p>More often than not, bugs in the compiler cause it to crash - often due to an
assertion failure of some sort. If you are running <tt><b>opt</b></tt> or
<tt><b>analyze</b></tt> directly, and something crashes, jump to the section on
<a href="#passes">bugs in LLVM passes</a>. Otherwise, the most important
piece of the puzzle is to figure out if it is the GCC-based front-end that is
buggy or if it's one of the LLVM tools that has problems.</p>
<p>To figure out which component is crashing (the front-end,
optimizer or code generator), run the
<p>To figure out which program is crashing (the front-end,
<tt><b>gccas</b></tt>, or <tt><b>gccld</b></tt>), run the
<tt><b>llvm-gcc</b></tt> command line as you were when the crash occurred, but
with the following extra command line options:</p>
add a <tt>-v</tt> option to the command line. The compiler will print out a
bunch of stuff, and should end with telling you that one of
<tt><b>cc1</b>/<b>cc1plus</b></tt>, <tt><b>gccas</b></tt>, or
<tt><b>gccld</b></tt> crashed.</p>
<ul>
<li><tt><b>-O0 -emit-llvm</b></tt>: If <tt>llvm-gcc</tt> still crashes when
passed these options (which disable the optimizer and code generator), then
the crash is in the front-end. Jump ahead to the section on <a
href="#front-end">front-end bugs</a>.</li>
<li><tt><b>-emit-llvm</b></tt>: If <tt>llvm-gcc</tt> crashes with this option
(which disables the code generator), you found an optimizer bug. Jump ahead
to <a href="#ct_optimizer"> compile-time optimization bugs</a>.</li>
<li>If <tt><b>cc1</b></tt> or <tt><b>cc1plus</b></tt> crashed, you found a
problem with the front-end.
Jump ahead to the section on <a href="#front-end">front-end bugs</a>.</li>
<li>Otherwise, you have a code generator crash. Jump ahead to <a
href="#ct_codegen">code generator bugs</a>.</li>
<li>If <tt><b>gccas</b></tt> crashed, you found a bug in <a href="#gccas">one
of the passes in <tt><b>gccas</b></tt></a>.</li>
<li>If <tt><b>gccld</b></tt> crashed, you found a bug in <a href="#gccld">one
of the passes in <tt><b>gccld</b></tt></a>.</li>
<li>Otherwise, something really weird happened. Email the list with what you
have at this point.</li>
</ul>
@@ -122,96 +126,89 @@ with the following extra command line options:</p>
<tt>llvm-gcc</tt> command that resulted in the crash, but add the
<tt>-save-temps</tt> option. The compiler will crash again, but it will leave
behind a <tt><i>foo</i>.i</tt> file (containing preprocessed C source code) and
possibly <tt><i>foo</i>.s</tt> for each
possibly <tt><i>foo</i>.s</tt> (containing LLVM assembly code), for each
compiled <tt><i>foo</i>.c</tt> file. Send us the <tt><i>foo</i>.i</tt> file,
along with the options you passed to llvm-gcc, and a brief description of the
error it caused.</p>
<p>The <a href="http://delta.tigris.org/">delta</a> tool helps to reduce the
preprocessed file down to the smallest amount of code that still replicates the
problem. You're encouraged to use delta to reduce the code to make the
developers' lives easier. <a
href="http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction">This website</a>
has instructions on the best way to use delta.</p>
along with a brief description of the error it caused.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="ct_optimizer">Compile-time optimization bugs</a>
<a name="gccas">GCCAS bugs</a>
</div>
<div class="doc_text">
<p>If you find that a bug crashes in the optimizer, compile your test-case to a
<tt>.bc</tt> file by passing "<tt><b>-emit-llvm -O0 -c -o foo.bc</b></tt>".
Then run:</p>
<p>If you find that a bug crashes in the <tt><b>gccas</b></tt> stage of
compilation, compile your test-case to a <tt>.s</tt> file with the
<tt>-save-temps</tt> option to <tt><b>llvm-gcc</b></tt>. Then run:</p>
<div class="doc_code">
<p><tt><b>opt</b> -std-compile-opts -debug-pass=Arguments foo.bc
-disable-output</tt></p>
<p><tt><b>gccas</b> -debug-pass=Arguments &lt; /dev/null -o - &gt; /dev/null</tt></p>
</div>
<p>This command should do two things: it should print out a list of passes, and
then it should crash in the same was as llvm-gcc. If it doesn't crash, please
follow the instructions for a <a href="#front-end">front-end bug</a>.</p>
<p>If this does crash, then you should be able to debug this with the following
bugpoint command:</p>
<div class="doc_code">
<p><tt><b>bugpoint</b> foo.bc &lt;list of passes printed by
<b>opt</b>&gt;</tt></p>
</div>
<p>Please run this, then file a bug with the instructions and reduced .bc files
that bugpoint emits. If something goes wrong with bugpoint, please submit the
"foo.bc" file and the list of passes printed by <b>opt</b>.</p>
<p>... which will print a list of arguments, indicating the list of passes that
<tt><b>gccas</b></tt> runs. Once you have the input file and the list of
passes, go to the section on <a href="#passes">debugging bugs in LLVM
passes</a>.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="ct_codegen">Code generator bugs</a>
<a name="gccld">GCCLD bugs</a>
</div>
<div class="doc_text">
<p>If you find a bug that crashes llvm-gcc in the code generator, compile your
source file to a .bc file by passing "<tt><b>-emit-llvm -c -o foo.bc</b></tt>"
to llvm-gcc (in addition to the options you already pass). Once your have
foo.bc, one of the following commands should fail:</p>
<p>If you find that a bug crashes in the <tt><b>gccld</b></tt> stage of
compilation, gather all of the <tt>.o</tt> bytecode files and libraries that are
being linked together (the "<tt><b>llvm-gcc</b> -v</tt>" output should include
the full list of objects linked). Then run:</p>
<ol>
<li><tt><b>llc</b> foo.bc -f</tt></li>
<li><tt><b>llc</b> foo.bc -f -relocation-model=pic</tt></li>
<li><tt><b>llc</b> foo.bc -f -relocation-model=static</tt></li>
<li><tt><b>llc</b> foo.bc -f -enable-eh</tt></li>
<li><tt><b>llc</b> foo.bc -f -relocation-model=pic -enable-eh</tt></li>
<li><tt><b>llc</b> foo.bc -f -relocation-model=static -enable-eh</tt></li>
</ol>
<div class="doc_code">
<p><tt><b>llvm-as</b> &lt; /dev/null &gt; null.bc<br>
<b>gccld</b> -debug-pass=Arguments null.bc</tt>
</p>
</div>
<p>If none of these crash, please follow the instructions for a
<a href="#front-end">front-end bug</a>. If one of these do crash, you should
be able to reduce this with one of the following bugpoint command lines (use
the one corresponding to the command above that failed):</p>
<p>... which will print a list of arguments, indicating the list of passes that
<tt><b>gccld</b></tt> runs. Once you have the input files and the list of
passes, go to the section on <a href="#passes">debugging bugs in LLVM
passes</a>.</p>
<ol>
<li><tt><b>bugpoint</b> -run-llc foo.bc</tt></li>
<li><tt><b>bugpoint</b> -run-llc foo.bc --tool-args
-relocation-model=pic</tt></li>
<li><tt><b>bugpoint</b> -run-llc foo.bc --tool-args
-relocation-model=static</tt></li>
<li><tt><b>bugpoint</b> -run-llc foo.bc --tool-args -enable-eh</tt></li>
<li><tt><b>bugpoint</b> -run-llc foo.bc --tool-args
-relocation-model=pic -enable-eh</tt></li>
<li><tt><b>bugpoint</b> -run-llc foo.bc --tool-args
-relocation-model=static -enable-eh</tt></li>
</ol>
</div>
<p>Please run this, then file a bug with the instructions and reduced .bc file
that bugpoint emits. If something goes wrong with bugpoint, please submit the
"foo.bc" file and the option that llc crashes with.</p>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="passes">Bugs in LLVM passes</a>
</div>
<div class="doc_text">
<p>At this point, you should have some number of LLVM assembly files or bytecode
files and a list of passes which crash when run on the specified input. In
order to reduce the list of passes (which is probably large) and the input to
something tractable, use the <tt><b>bugpoint</b></tt> tool as follows:</p>
<div class="doc_code">
<p><tt><b>bugpoint</b> &lt;input files&gt; &lt;list of passes&gt;</tt></p>
</div>
<p><tt><b>bugpoint</b></tt> will print a bunch of output as it reduces the
test-case, but it should eventually print something like this:</p>
<div class="doc_code">
<p><tt>
...<br>
Emitted bytecode to 'bugpoint-reduced-simplified.bc'<br>
<br>
*** You can reproduce the problem with: opt bugpoint-reduced-simplified.bc -licm<br>
</tt></p>
</div>
<p>Once you complete this, please send the LLVM bytecode file and the command
line to reproduce the problem to the llvmbugs mailing list.</p>
</div>
@@ -223,14 +220,18 @@ that bugpoint emits. If something goes wrong with bugpoint, please submit the
<div class="doc_text">
<p>If llvm-gcc successfully produces an executable, but that executable doesn't
run right, this is either a bug in the code or a bug in the
compiler. The first thing to check is to make sure it is not using undefined
behavior (e.g. reading a variable before it is defined). In particular, check
to see if the program <a href="http://valgrind.org/">valgrind</a>s clean,
passes purify, or some other memory checker tool. Many of the "LLVM bugs" that
we have chased down ended up being bugs in the program being compiled, not
LLVM.</p>
<p>A miscompilation occurs when a pass does not correctly transform a program,
thus producing errors that are only noticed during execution. This is different
from producing invalid LLVM code (i.e., code not in SSA form, using values
before defining them, etc.) which the verifier will check for after a pass
finishes its run.</p>
<p>If it looks like the LLVM compiler is miscompiling a program, the very first
thing to check is to make sure it is not using undefined behavior. In
particular, check to see if the program <a
href="http://valgrind.kde.org/">valgrind</a>s clean, passes purify, or some
other memory checker tool. Many of the "LLVM bugs" that we have chased down
ended up being bugs in the program being compiled, not LLVM.</p>
<p>Once you determine that the program itself is not buggy, you should choose
which code generator you wish to compile the program with (e.g. C backend, the
@@ -346,7 +347,7 @@ the following:</p>
src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /></a>
<a href="mailto:sabre@nondot.org">Chris Lattner</a><br>
<a href="http://llvm.org">The LLVM Compiler Infrastructure</a>
<a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
<br>
Last modified: $Date$
</address>

View File

@@ -0,0 +1,180 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<link rel="stylesheet" href="llvm.css" type="text/css">
<title>LLVM vs. the World - Comparing Compilers to Compilers</title>
</head>
<body>
<div class="doc_title">
LLVM vs. the World - Comparing Compilers to Compilers
</div>
<ol>
<li><a href="#introduction">Introduction</a></li>
<li><a href="#generalapplicability">General Applicability</a></li>
<li><a href="#typesystem">Type System</a></li>
<li><a href="#dataflowinformation">Control-flow and Data-flow Information</a></li>
<li><a href="#registers">Registers</a></li>
<li><a href="#programmerinterface">Programmer Interface</a></li>
<li><a href="#codeemission">Machine Code Emission</a></li>
</ol>
<div class="doc_author">
<p>Written by Brian R. Gaeke</p>
</div>
<!-- *********************************************************************** -->
<div class="doc_section">
<a name="introduction">Introduction</a>
</div>
<!-- *********************************************************************** -->
<div class="doc_text">
<p>Whether you are a stranger to LLVM or not, and whether you are considering
using it for your projects or not, you may find it useful to understand how we
compare ourselves to other well-known compilers. The following list of points
should help you understand -- from our point of view -- some of the important
ways in which we see LLVM as different from other selected compilers and
code generation systems.</p>
<p>At the moment, we only compare ourselves below to <a
href="http://gcc.gnu.org/">GCC</a> and <a
href="http://www.gnu.org/software/lightning/">GNU lightning</a>, but we will try
to revise and expand it as our knowledge and experience permit. Contributions are
welcome.</p>
</div>
<!-- *********************************************************************** -->
<div class="doc_section">
<a name="generalapplicability">General Applicability</a>
</div>
<!-- *********************************************************************** -->
<div class="doc_text">
<p>GNU lightning: Only currently usable for dynamic runtime emission of binary
machine code to memory. Supports one backend at a time.</p>
<p>LLVM: Supports compilation of C and C++ (with more languages coming soon),
strong SSA-based optimization at compile-time, link-time, run-time, and
off-line, and multiple platform backends with Just-in-Time and ahead-of-time
compilation frameworks. (See our document on <a
href="http://llvm.cs.uiuc.edu/pubs/2004-01-30-CGO-LLVM.html">Lifelong
Code Optimization</a> for more.)</p>
<p>GCC: Many relatively mature platform backends support assembly-language code
generation from many source languages. No run-time compilation
support.</p>
</div>
<!-- *********************************************************************** -->
<div class="doc_section">
<a name="typesystem">Type System</a>
</div>
<!-- *********************************************************************** -->
<div class="doc_text">
<p>GNU lightning: C integer types and "void *" are supported. No type checking
is performed. Explicit type casts are not typically necessary unless the
underlying machine-specific types are distinct (e.g., sign- or zero-extension is
apparently necessary, but casting "int" to "void *" would not be.)
Floating-point support may not work on all platforms (it does not appear to be
documented in the latest release).</p>
<p>LLVM: Compositional type system based on C types, supporting structures,
opaque types, and C integer and floating point types. Explicit cast instructions
are required to transform a value from one type to another.</p>
<p>GCC: Union of high-level types including those used in Pascal, C, C++, Ada,
Java, and FORTRAN.</p>
</div>
<!-- *********************************************************************** -->
<div class="doc_section">
<a name="dataflowinformation">Control-flow and Data-flow Information</a>
</div>
<!-- *********************************************************************** -->
<div class="doc_text">
<p>GNU lightning: No data-flow information encoded in the generated program. No
support for calculating CFG or def-use chains over generated programs.</p>
<p>LLVM: Scalar values in Static Single-Assignment form; def-use chains and CFG
always implicitly available and automatically kept up to date.</p>
<p>GCC: Trees and RTL do not directly encode data-flow info; but def-use chains
and CFGs can be calculated on the side. They are not automatically kept up to
date.</p>
</div>
<!-- *********************************************************************** -->
<div class="doc_section">
<a name="registers">Registers</a>
</div>
<!-- *********************************************************************** -->
<div class="doc_text">
<p>GNU lightning: Very small fixed register set -- it takes the least common
denominator of supported platforms; basically it inherits its tiny register set
from IA-32, unnecessarily crippling targets like PowerPC with a large register
set.</p>
<p>LLVM: An infinite register set, reduced to a particular platform's finite
register set by register allocator.</p>
<p>GCC: Trees and RTL provide an arbitrarily large set of values. Reduced to a
particular platform's finite register set by register allocator.</p>
</div>
<!-- *********************************************************************** -->
<div class="doc_section">
<a name="programmerinterface">Programmer Interface</a>
</div>
<!-- *********************************************************************** -->
<div class="doc_text">
<p>GNU lightning: Library interface based on C preprocessor macros that emit
binary code for a particular instruction to memory. No support for manipulating
code before emission.</p>
<p>LLVM: Library interface based on classes representing platform-independent
intermediate code (Instruction) and platform-dependent code (MachineInstr) which
can be manipulated arbitrarily and then emitted to memory.</p>
<p>GCC: Internal header file interface (tree.h) to abstract syntax trees,
representing roughly the union of all possible supported source-language
constructs; also, an internal header file interface (rtl.h, rtl.def) to a
low-level IR called RTL which represents roughly the union of all possible
target machine instructions.</p>
</div>
<!-- *********************************************************************** -->
<div class="doc_section">
<a name="codeemission">Machine Code Emission</a>
</div>
<!-- *********************************************************************** -->
<div class="doc_text">
<p>GNU lightning: Only supports binary machine code emission to memory.</p>
<p>LLVM: Supports writing out assembly language to a file, and binary machine
code to memory, from the same back-end.</p>
<p>GCC: Supports writing out assembly language to a file. No support for
emitting machine code to memory.</p>
</div>
<!-- *********************************************************************** -->
<hr>
<div class="doc_footer">
<address>Brian R. Gaeke</address>
<a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
<br>
Last modified: $Date$
</div>
</body>
</html>

File diff suppressed because it is too large Load Diff

View File

@@ -40,7 +40,6 @@
</tr>
<tr><th colspan="8"><b>- <a href="#L">L</a> -</b></th></tr>
<tr>
<td><a href="#LCSSA">LCSSA</a></td>
<td><a href="#LICM">LICM</a></td>
<td><a href="#Load-VN">Load-VN</a></td>
</tr>
@@ -54,9 +53,7 @@
</tr>
<tr><th colspan="8"><b>- <a href="#S">S</a> -</b></th></tr>
<tr>
<td><a href="#SCC">SCC</a></td>
<td><a href="#SCCP">SCCP</a></td>
<td><a href="#SRoA">SRoA</a></td>
<td><a href="#SSA">SSA</a></td>
</tr>
</table>
@@ -122,8 +119,6 @@ href="http://www.program-transformation.org/Transform/BURG">BURG</a> tool.</dd>
<div class="doc_subsection"><a name="L">- L -</a></div>
<div class="doc_text">
<dl>
<dt><a name="LCSSA"><b>LCSSA</b></a></dt>
<dd>Loop-Closed Static Single Assignment Form</dd>
<dt><a name="LICM"><b>LICM</b></a></dt>
<dd>Loop Invariant Code Motion</dd>
<dt><a name="Load-VN"><b>Load-VN</b></a></dt>
@@ -155,12 +150,8 @@ href="http://www.program-transformation.org/Transform/BURG">BURG</a> tool.</dd>
<div class="doc_subsection"><a name="S">- S -</a></div>
<div class="doc_text">
<dl>
<dt><a name="SCC"><b>SCC</b></a></dt>
<dd>Strongly Connected Component</dd>
<dt><a name="SCCP"><b>SCCP</b></a></dt>
<dd>Sparse Conditional Constant Propagation</dd>
<dt><a name="SRoA"><b>SRoA</b></a></dt>
<dd>Scalar Replacement of Aggregates</dd>
<dd>Sparse Conditional Constant Propagation
<dt><a name="SSA"><b>SSA</b></a></dt>
<dd>Static Single Assignment</dd>
</dl>
@@ -171,8 +162,8 @@ href="http://www.program-transformation.org/Transform/BURG">BURG</a> tool.</dd>
src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a><a
href="http://validator.w3.org/check/referer"><img
src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"></a><a
href="http://llvm.org/">The LLVM Team</a><br>
<a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br>
href="http://llvm.cs.uiuc.edu/">The LLVM Team</a><br>
<a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a><br>
Last modified: $Date$
</address>
<!-- vim: sw=2

View File

@@ -1,392 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>LLVM Link Time Optimization: Design and Implementation</title>
<link rel="stylesheet" href="llvm.css" type="text/css">
</head>
<div class="doc_title">
LLVM Link Time Optimization: Design and Implementation
</div>
<ul>
<li><a href="#desc">Description</a></li>
<li><a href="#design">Design Philosophy</a>
<ul>
<li><a href="#example1">Example of link time optimization</a></li>
<li><a href="#alternative_approaches">Alternative Approaches</a></li>
</ul></li>
<li><a href="#multiphase">Multi-phase communication between LLVM and linker</a>
<ul>
<li><a href="#phase1">Phase 1 : Read LLVM Bytecode Files</a></li>
<li><a href="#phase2">Phase 2 : Symbol Resolution</a></li>
<li><a href="#phase3">Phase 3 : Optimize Bytecode Files</a></li>
<li><a href="#phase4">Phase 4 : Symbol Resolution after optimization</a></li>
</ul></li>
<li><a href="#lto">LLVMlto</a>
<ul>
<li><a href="#llvmsymbol">LLVMSymbol</a></li>
<li><a href="#readllvmobjectfile">readLLVMObjectFile()</a></li>
<li><a href="#optimizemodules">optimizeModules()</a></li>
<li><a href="#gettargettriple">getTargetTriple()</a></li>
<li><a href="#removemodule">removeModule()</a></li>
<li><a href="#getalignment">getAlignment()</a></li>
</ul></li>
<li><a href="#debug">Debugging Information</a></li>
</ul>
<div class="doc_author">
<p>Written by Devang Patel</p>
</div>
<!-- *********************************************************************** -->
<div class="doc_section">
<a name="desc">Description</a>
</div>
<!-- *********************************************************************** -->
<div class="doc_text">
<p>
LLVM features powerful intermodular optimizations which can be used at link
time. Link Time Optimization is another name for intermodular optimization
when performed during the link stage. This document describes the interface
and design between the LLVM intermodular optimizer and the linker.</p>
</div>
<!-- *********************************************************************** -->
<div class="doc_section">
<a name="design">Design Philosophy</a>
</div>
<!-- *********************************************************************** -->
<div class="doc_text">
<p>
The LLVM Link Time Optimizer provides complete transparency, while doing
intermodular optimization, in the compiler tool chain. Its main goal is to let
the developer take advantage of intermodular optimizations without making any
significant changes to the developer's makefiles or build system. This is
achieved through tight integration with the linker. In this model, the linker
treates LLVM bytecode files like native object files and allows mixing and
matching among them. The linker uses <a href="#lto">LLVMlto</a>, a dynamically
loaded library, to handle LLVM bytecode files. This tight integration between
the linker and LLVM optimizer helps to do optimizations that are not possible
in other models. The linker input allows the optimizer to avoid relying on
conservative escape analysis.
</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="example1">Example of link time optimization</a>
</div>
<div class="doc_text">
<p>The following example illustrates the advantages of LTO's integrated
approach and clean interface. This example requires a system linker which
supports LTO through the interface described in this document. Here,
llvm-gcc4 transparently invokes system linker. </p>
<ul>
<li> Input source file <tt>a.c</tt> is compiled into LLVM byte code form.
<li> Input source file <tt>main.c</tt> is compiled into native object code.
</ul>
<div class="doc_code"><pre>
--- a.h ---
extern int foo1(void);
extern void foo2(void);
extern void foo4(void);
--- a.c ---
#include "a.h"
static signed int i = 0;
void foo2(void) {
i = -1;
}
static int foo3() {
foo4();
return 10;
}
int foo1(void) {
int data = 0;
if (i &lt; 0) { data = foo3(); }
data = data + 42;
return data;
}
--- main.c ---
#include &lt;stdio.h&gt;
#include "a.h"
void foo4(void) {
printf ("Hi\n");
}
int main() {
return foo1();
}
--- command lines ---
$ llvm-gcc4 --emit-llvm -c a.c -o a.o # &lt;-- a.o is LLVM bytecode file
$ llvm-gcc4 -c main.c -o main.o # &lt;-- main.o is native object file
$ llvm-gcc4 a.o main.o -o main # &lt;-- standard link command without any modifications
</pre></div>
<p>In this example, the linker recognizes that <tt>foo2()</tt> is an
externally visible symbol defined in LLVM byte code file. This information
is collected using <a href="#readllvmobjectfile"> readLLVMObjectFile()</a>.
Based on this information, the linker completes its usual symbol resolution
pass and finds that <tt>foo2()</tt> is not used anywhere. This information
is used by the LLVM optimizer and it removes <tt>foo2()</tt>. As soon as
<tt>foo2()</tt> is removed, the optimizer recognizes that condition
<tt>i &lt; 0</tt> is always false, which means <tt>foo3()</tt> is never
used. Hence, the optimizer removes <tt>foo3()</tt>, also. And this in turn,
enables linker to remove <tt>foo4()</tt>. This example illustrates the
advantage of tight integration with the linker. Here, the optimizer can not
remove <tt>foo3()</tt> without the linker's input.
</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="alternative_approaches">Alternative Approaches</a>
</div>
<div class="doc_text">
<dl>
<dt><b>Compiler driver invokes link time optimizer separately.</b></dt>
<dd>In this model the link time optimizer is not able to take advantage of
information collected during the linker's normal symbol resolution phase.
In the above example, the optimizer can not remove <tt>foo2()</tt> without
the linker's input because it is externally visible. This in turn prohibits
the optimizer from removing <tt>foo3()</tt>.</dd>
<dt><b>Use separate tool to collect symbol information from all object
files.</b></dt>
<dd>In this model, a new, separate, tool or library replicates the linker's
capability to collect information for link time optimization. Not only is
this code duplication difficult to justify, but it also has several other
disadvantages. For example, the linking semantics and the features
provided by the linker on various platform are not unique. This means,
this new tool needs to support all such features and platforms in one
super tool or a separate tool per platform is required. This increases
maintance cost for link time optimizer significantly, which is not
necessary. This approach also requires staying synchronized with linker
developements on various platforms, which is not the main focus of the link
time optimizer. Finally, this approach increases end user's build time due
to the duplication of work done by this separate tool and the linker itself.
</dd>
</dl>
</div>
<!-- *********************************************************************** -->
<div class="doc_section">
<a name="multiphase">Multi-phase communication between LLVM and linker</a>
</div>
<div class="doc_text">
<p>The linker collects information about symbol defininitions and uses in
various link objects which is more accurate than any information collected
by other tools during typical build cycles. The linker collects this
information by looking at the definitions and uses of symbols in native .o
files and using symbol visibility information. The linker also uses
user-supplied information, such as a list of exported symbols. LLVM
optimizer collects control flow information, data flow information and knows
much more about program structure from the optimizer's point of view.
Our goal is to take advantage of tight intergration between the linker and
the optimizer by sharing this information during various linking phases.
</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="phase1">Phase 1 : Read LLVM Bytecode Files</a>
</div>
<div class="doc_text">
<p>The linker first reads all object files in natural order and collects
symbol information. This includes native object files as well as LLVM byte
code files. In this phase, the linker uses
<a href="#readllvmobjectfile"> readLLVMObjectFile() </a> to collect symbol
information from each LLVM bytecode files and updates its internal global
symbol table accordingly. The intent of this interface is to avoid overhead
in the non LLVM case, where all input object files are native object files,
by putting this code in the error path of the linker. When the linker sees
the first llvm .o file, it <tt>dlopen()</tt>s the dynamic library. This is
to allow changes to the LLVM LTO code without relinking the linker.
</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="phase2">Phase 2 : Symbol Resolution</a>
</div>
<div class="doc_text">
<p>In this stage, the linker resolves symbols using global symbol table
information to report undefined symbol errors, read archive members, resolve
weak symbols, etc. The linker is able to do this seamlessly even though it
does not know the exact content of input LLVM bytecode files because it uses
symbol information provided by
<a href="#readllvmobjectfile">readLLVMObjectFile()</a>. If dead code
stripping is enabled then the linker collects the list of live symbols.
</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="phase3">Phase 3 : Optimize Bytecode Files</a>
</div>
<div class="doc_text">
<p>After symbol resolution, the linker updates symbol information supplied
by LLVM bytecode files appropriately. For example, whether certain LLVM
bytecode supplied symbols are used or not. In the example above, the linker
reports that <tt>foo2()</tt> is not used anywhere in the program, including
native <tt>.o</tt> files. This information is used by the LLVM interprocedural
optimizer. The linker uses <a href="#optimizemodules">optimizeModules()</a>
and requests an optimized native object file of the LLVM portion of the
program.
</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="phase4">Phase 4 : Symbol Resolution after optimization</a>
</div>
<div class="doc_text">
<p>In this phase, the linker reads optimized a native object file and
updates the internal global symbol table to reflect any changes. The linker
also collects information about any changes in use of external symbols by
LLVM bytecode files. In the examle above, the linker notes that
<tt>foo4()</tt> is not used any more. If dead code stripping is enabled then
the linker refreshes the live symbol information appropriately and performs
dead code stripping.</p>
<p>After this phase, the linker continues linking as if it never saw LLVM
bytecode files.</p>
</div>
<!-- *********************************************************************** -->
<div class="doc_section">
<a name="lto">LLVMlto</a>
</div>
<div class="doc_text">
<p><tt>LLVMlto</tt> is a dynamic library that is part of the LLVM tools, and
is intended for use by a linker. <tt>LLVMlto</tt> provides an abstract C++
interface to use the LLVM interprocedural optimizer without exposing details
of LLVM's internals. The intention is to keep the interface as stable as
possible even when the LLVM optimizer continues to evolve.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="llvmsymbol">LLVMSymbol</a>
</div>
<div class="doc_text">
<p>The <tt>LLVMSymbol</tt> class is used to describe the externally visible
functions and global variables, defined in LLVM bytecode files, to the linker.
This includes symbol visibility information. This information is used by
the linker to do symbol resolution. For example: function <tt>foo2()</tt> is
defined inside an LLVM bytecode module and it is an externally visible symbol.
This helps the linker connect the use of <tt>foo2()</tt> in native object
files with a future definition of the symbol <tt>foo2()</tt>. The linker
will see the actual definition of <tt>foo2()</tt> when it receives the
optimized native object file in
<a href="#phase4">Symbol Resolution after optimization</a> phase. If the
linker does not find any uses of <tt>foo2()</tt>, it updates LLVMSymbol
visibility information to notify LLVM intermodular optimizer that it is dead.
The LLVM intermodular optimizer takes advantage of such information to
generate better code.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="readllvmobjectfile">readLLVMObjectFile()</a>
</div>
<div class="doc_text">
<p>The <tt>readLLVMObjectFile()</tt> function is used by the linker to read
LLVM bytecode files and collect LLVMSymbol information. This routine also
supplies a list of externally defined symbols that are used by LLVM bytecode
files. The linker uses this symbol information to do symbol resolution.
Internally, <a href="#lto">LLVMlto</a> maintains LLVM bytecode modules in
memory. This function also provides a list of external references used by
bytecode files.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="optimizemodules">optimizeModules()</a>
</div>
<div class="doc_text">
<p>The linker invokes <tt>optimizeModules</tt> to optimize already read
LLVM bytecode files by applying LLVM intermodular optimization techniques.
This function runs the LLVM intermodular optimizer and generates native
object code as <tt>.o</tt> files at the name and location provided by the
linker.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="gettargettriple">getTargetTriple()</a>
</div>
<div class="doc_text">
<p>The linker may use <tt>getTargetTriple()</tt> to query target architecture
while validating LLVM bytecode file.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="removemodule">removeModule()</a>
</div>
<div class="doc_text">
<p>Internally, <a href="#lto">LLVMlto</a> maintains LLVM bytecode modules in
memory. The linker may use <tt>removeModule()</tt> method to remove desired
modules from memory. </p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="getalignment">getAlignment()</a>
</div>
<div class="doc_text">
<p>The linker may use <a href="#llvmsymbol">LLVMSymbol</a> method
<tt>getAlignment()</tt> to query symbol alignment information.</p>
</div>
<!-- *********************************************************************** -->
<div class="doc_section">
<a name="debug">Debugging Information</a>
</div>
<!-- *********************************************************************** -->
<div class="doc_text">
<p><tt> ... To be completed ... </tt></p>
</div>
<!-- *********************************************************************** -->
<hr>
<address>
<a href="http://jigsaw.w3.org/css-validator/check/referer"><img
src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a>
<a href="http://validator.w3.org/check/referer"><img
src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"></a>
Devang Patel<br>
<a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
Last modified: $Date$
</address>
</body>
</html>

View File

@@ -10,22 +10,6 @@
LEVEL := ..
DIRS := CommandGuide
ifdef BUILD_FOR_WEBSITE
PROJ_OBJ_DIR = .
DOXYGEN = doxygen
# Extract version number from the AC_INT line in configure.ac
# AC_INIT([[llvm]],[[2.0cvs]],[llvmbugs@cs.uiuc.edu])
PACKAGE_VERSION = $(shell grep AC_INIT ../autoconf/configure.ac | sed -e 's/[^,]*,[[][[]//' -e 's/]],.*//')
$(warning VERSION=$(VERSION))
$(PROJ_OBJ_DIR)/doxygen.cfg: doxygen.cfg.in
cat $< | sed \
-e 's/@abs_top_srcdir@/../g' \
-e 's/@DOT@/dot/g' \
-e 's/@PACKAGE_VERSION@/$(PACKAGE_VERSION)/g' \
-e 's/@abs_top_builddir@/../g' > $@
endif
include $(LEVEL)/Makefile.common
HTML := $(wildcard $(PROJ_SRC_DIR)/*.html) \
@@ -67,21 +51,18 @@ install-doxygen: doxygen
$(FIND) . -type f -exec \
$(DataInstall) {} $(PROJ_docsdir)/html/doxygen \;
doxygen: regendoc $(PROJ_OBJ_DIR)/doxygen.tar.gz
doxygen: $(PROJ_OBJ_DIR)/doxygen.tar.gz
regendoc:
$(PROJ_OBJ_DIR)/doxygen.tar.gz: $(DOXYFILES) $(PROJ_OBJ_DIR)/doxygen.cfg
$(Echo) Building doxygen documentation
$(Verb) if test -e $(PROJ_OBJ_DIR)/doxygen ; then \
$(RM) -rf $(PROJ_OBJ_DIR)/doxygen ; \
fi
$(Verb) $(DOXYGEN) $(PROJ_OBJ_DIR)/doxygen.cfg
$(PROJ_OBJ_DIR)/doxygen.tar.gz: $(DOXYFILES) $(PROJ_OBJ_DIR)/doxygen.cfg
$(Echo) Packaging doxygen documentation
$(Verb) $(RM) -rf $@ $(PROJ_OBJ_DIR)/doxygen.tar
$(Verb) $(TAR) cf $(PROJ_OBJ_DIR)/doxygen.tar doxygen
$(Verb) $(GZIP) $(PROJ_OBJ_DIR)/doxygen.tar
$(Verb) $(CP) $(PROJ_OBJ_DIR)/doxygen.tar.gz $(PROJ_OBJ_DIR)/doxygen/html/
userloc: $(LLVM_SRC_ROOT)/docs/userloc.html

View File

@@ -30,8 +30,7 @@
<ol>
<li><a href="#libraries">Libraries</a>
<ol>
<li><a href="#BCModules">Bytecode Modules</a></li>
<li><a href="#LoadableModules">Loadable Modules</a></li>
<li><a href="#Modules">Bytecode Modules</a></li>
</ol>
</li>
<li><a href="#tools">Tools</a>
@@ -90,8 +89,8 @@
Make 3.79, a widely portable makefile processor. LLVM unabashedly makes heavy
use of the features of GNU Make so the dependency on GNU Make is firm. If
you're not familiar with <tt>make</tt>, it is recommended that you read the
<a href="http://www.gnu.org/software/make/manual/make.html">GNU Makefile
Manual</a>.</p>
<a href="http://www.gnu.org/software/make/manual/make.html">GNU Makefile Manual
</a>.</p>
<p>While this document is rightly part of the
<a href="ProgrammersManual.html">LLVM Programmer's Manual</a>, it is treated
separately here because of the volume of content and because it is often an
@@ -238,7 +237,7 @@
LIBRARYNAME = mylib
SHARED_LIBRARY = 1
ARCHIVE_LIBRARY = 1
DONT_BUILD_RELINKED = 1
DONT_BUILT_RELINKED = 1
</tt></pre>
<p>says to build a library named "mylib" with both a shared library
(<tt>mylib.so</tt>) and an archive library (<tt>mylib.a</tt>) version but
@@ -260,7 +259,7 @@
</div>
<!-- ======================================================================= -->
<div class="doc_subsubsection"><a name="BCModules">Bytecode Modules</a></div>
<div class="doc_subsubsection"><a name="Modules">Bytecode Modules</a></div>
<div class="doc_text">
<p>In some situations, it is desireable to build a single bytecode module from
a variety of sources, instead of an archive, shared library, or bytecode
@@ -280,40 +279,6 @@
</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsubsection">
<a name="LoadableModules">Loadable Modules</a>
</div>
<div class="doc_text">
<p>In some situations, you need to create a loadable module. Loadable modules
can be loaded into programs like <tt>opt</tt> or <tt>llc</tt> to specify
additional passes to run or targets to support. Loadable modules are also
useful for debugging a pass or providing a pass with another package if that
pass can't be included in LLVM.</p>
<p>LLVM provides complete support for building such a module. All you need to
do is use the LOADABLE_MODULE variable in your Makefile. For example, to
build a loadable module named <tt>MyMod</tt> that uses the LLVM libraries
<tt>LLVMSupport.a</tt> and <tt>LLVMSystem.a</tt>, you would specify:</p>
<pre><tt>
LIBRARYNAME := MyMod
LOADABLE_MODULE := 1
LINK_COMPONENTS := support system
</tt></pre>
<p>Use of the <tt>LOADABLE_MODULE</tt> facility implies several things:</p>
<ol>
<li>There will be no "lib" prefix on the module. This differentiates it from
a standard shared library of the same name.</li>
<li>The <a href="#SHARED_LIBRARY">SHARED_LIBRARY</a> variable is turned
on.</li>
<li>The <a href="#LINK_LIBS_IN_SHARED">LINK_LIBS_IN_SHARED</a> variable
is turned on.</li>
<li>The <a href="#DONT_BUILD_RELINKED">DONT_BUILD_RELINKED</a> variable
is turned on.</li>
</ol>
<p>A loadable module is loaded by LLVM via the facilities of libtool's libltdl
library which is part of <tt>lib/System</tt> implementation.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection"><a name="tools">Tools</a></div>
<div class="doc_text">
@@ -323,7 +288,7 @@
<pre><tt>
TOOLNAME = mytool
USEDLIBS = mylib
LINK_COMPONENTS = support system
LLVMLIBS = LLVMSupport.a LLVMSystem.a
</tt></pre>
<p>says that we are to build a tool name <tt>mytool</tt> and that it requires
three libraries: <tt>mylib</tt>, <tt>LLVMSupport.a</tt> and
@@ -352,22 +317,36 @@
<!-- ======================================================================= -->
<div class="doc_subsubsection"><a name="JIT">JIT Tools</a></div>
<div class="doc_text">
<p>Many tools will want to use the JIT features of LLVM. To do this, you
simply specify that you want an execution 'engine', and the makefiles will
automatically link in the appropriate JIT for the host or an interpreter
if none is available:</p>
<p>Many tools will want to use the JIT features of LLVM. However, getting the
right set of libraries to link with is tedious, platform specific, and error
prone. Additionally, the JIT has special linker switch options that it needs.
Consequently, to make it easier to build tools that use the JIT, you can
use a special value for the <tt>LLVMLIBS</tt> variable:</p>
<pre><tt>
TOOLNAME = my_jit_tool
USEDLIBS = mylib
LINK_COMPONENTS = engine
LLVMLIBS = JIT
</tt></pre>
<p>Of course, any additional libraries may be listed as other components. To
get a full understanding of how this changes the linker command, it is
recommended that you:</p>
<p>Using a value of <tt>JIT</tt> for <tt>LLVMLIBS</tt> tells the makefile
system to construct a special value for LLVMLIBS that gives the program all
the LLVM libraries needed to run the JIT. Any additional libraries needed can
still be specified with <tt>USEDLIBS</tt>. To get a full understanding of how
this changes the linker command, it is recommended that you:</p>
<pre><tt>
cd examples/Fibonacci
make VERBOSE=1
</tt></pre>
<p>By default, using <tt>LLVMLIBS=JIT</tt> will link in enough to support JIT
code generation for the architecture on which the tool is linked. If you need
additional target architectures linked in, you may specify them on the command
line or in your <tt>Makefile</tt>. For example:</p>
<pre><tt>
ENABLE_X86_JIT=1
ENABLE_SPARCV9_JIT=1
ENALBE_PPC_JIT=1
</tt></pre>
<p>will cause the tool to be able to generate code for all three platforms.
</p>
</div>
<!-- *********************************************************************** -->
@@ -653,11 +632,6 @@
to the compilers and linkers to ensure that profile data can be collected
from the tools built. Use the <tt>gprof</tt> tool to analyze the output from
the profiled tools (<tt>gmon.out</tt>).</dd>
<dt><a name="DISABLE_ASSERTIONS"><tt>DISABLE_ASSERTIONS</tt></a></dt>
<dd>If set to any value, causes the build to disable assertions, even if
building a release or profile build. This will exclude all assertion check
code from the build. LLVM will execute faster, but with little help when
things go wrong.</dd>
<dt><a name="EXPERIMENTAL_DIRS"><tt>EXPERIMENTAL_DIRS</tt></a></dt>
<dd>Specify a set of directories that should be built, but if they fail, it
should not cause the build to fail. Note that this should only be used
@@ -669,9 +643,17 @@
<dd>Specifies a set of symbols to be exported by the linker.</dd>
<dt><a name="EXTRA_DIST"><tt>EXTRA_DIST</tt></a></dt>
<dd>Specifies additional files that should be distributed with LLVM. All
source files, all built sources, all Makefiles, and most documentation files
source files, all built sources, all Makefiles, and most documentation files
will be automatically distributed. Use this variable to distribute any
files that are not automatically distributed.</dd>
<dt><a name="FAKE_SOURCES"><tt>FAKE_SOURCES</tt><small>(optional)</small>
</a></dt>
<dd>This variable is like <a href="#SOURCES"><tt>SOURCES</tt></a> except that
the source files don't need to exist. The makefiles only use
<tt>FAKE_SOURCES</tt> to create the names of derived objects that should be
included in the directory's result. It is assumed that the project's
<tt>Makefile</tt> will define how to build the derived objects
necessary.</dd>
<dt><a name="KEEP_SYMBOLS"><tt>KEEP_SYMBOLS</tt></a></dt>
<dd>If set to any value, specifies that when linking executables the
makefiles should retain debug symbols in the executable. Normally, symbols
@@ -683,22 +665,6 @@
<dt><a name="LIBRARYNAME"><tt>LIBRARYNAME</tt></a></dt>
<dd>Specify the name of the library to be built. (Required For
Libraries)</dd>
<dt><a name="LINK_COMPONENTS"><tt>LINK_COMPONENTS</tt></a></dt>
<dd>When specified for building a tool, the value of this variable will be
passed to the <tt>llvm-config</tt> tool to generate a link line for the
tool. Unlike <tt>USEDLIBS</tt> and <tt>LLVMLIBS</tt>, not all libraries need
to be specified. The <tt>llvm-config</tt> tool will figure out the library
dependencies and add any libraries that are needed. The <tt>USEDLIBS</tt>
variable can still be used in conjunction with <tt>LINK_COMPONENTS</tt> so
that additional project-specific libraries can be linked with the LLVM
libraries specified by <tt>LINK_COMPONENTS</tt></dd>
<dt><a name="LINK_LIBS_IN_SHARED"><tt>LINK_LIBS_IN_SHARED</tt></a></dt>
<dd>By default, shared library linking will ignore any libraries specified
with the <a href="LLVMLIBS">LLVMLIBS</a> or <a href="USEDLIBS">USEDLIBS</a>.
This prevents shared libs from including things that will be in the LLVM
tool the shared library will be loaded into. However, sometimes it is useful
to link certain libraries into your shared library and this option enables
that feature.</dd>
<dt><a name="LLVMLIBS"><tt>LLVMLIBS</tt></a></dt>
<dd>Specifies the set of libraries from the LLVM $(ObjDir) that will be
linked into the tool or library.</dd>
@@ -713,12 +679,6 @@
module can be specified in conjunction with other kinds of library builds
or by itself. It constructs from the sources a single linked bytecode
file.</dd>
<dt><a name="NO_INSTALL"><tt>NO_INSTALL</tt></a></dt>
<dd>Specifies that the build products of the directory should not be
installed but should be built even if the <tt>install</tt> target is given.
This is handy for directories that build libraries or tools that are only
used as part of the build process, such as code generators (e.g.
<tt>tblgen</tt>).</dd>
<dt><a name="OPTIONAL_DIRS"><tt>OPTIONAL_DIRS</tt></a></dt>
<dd>Specify a set of directories that may be built, if they exist, but its
not an error for them not to exist.</dd>
@@ -790,6 +750,8 @@
not.</dd>
<dt><a name="PROJ_SRC_DIR"><tt>PROJ_SRC_DIR</tt></a></dt>
<dd>The directory which contains the source files to be built.</dd>
<dt><a name="BURG"><tt>BURG</tt></a></dt>
<dd>Specifies the path to the <tt>burg</tt> tool.</dd>
<dt><a name="BZIP2"><tt>BZIP2</tt></a><small>(configured)</small></dt>
<dd>The path to the <tt>bzip2</tt> tool.</dd>
<dt><a name="CC"><tt>CC</tt></a><small>(configured)</small></dt>
@@ -810,8 +772,7 @@
<dd>Specifies the path to the <tt>echo</tt> tool for printing output.</dd>
<dt><a name="ETAGS"><tt>ETAGS</tt></a><small>(configured)</small></dt>
<dd>Specifies the path to the <tt>etags</tt> tool.</dd>
<dt><a name="ETAGSFLAGS"><tt>ETAGSFLAGS</tt></a><small>(configured)</small>
</dt>
<dt><a name="ETAGSFLAGS"><tt>ETAGSFLAGS</tt></a><small>(configured)</small></dt>
<dd>Provides flags to be passed to the <tt>etags</tt> tool.</dd>
<dt><a name="EXEEXT"><tt>EXEEXT</tt></a><small>(configured)</small></dt>
<dd>Provides the extension to be used on executables built by the makefiles.
@@ -819,6 +780,8 @@
executables (e.g. Unix).</dd>
<dt><a name="FLEX"><tt>FLEX</tt></a><small>(configured)</small></dt>
<dd>Specifies the path to the <tt>flex</tt> tool.</dd>
<dt><a name="GCCLD"><tt>GCCLD</tt></a><small>(defaulted)</small></dt>
<dd>Specifies the path to the <tt>gccld</tt> tool.</dd>
<dt><a name="INSTALL"><tt>INSTALL</tt></a><small>(configured)</small></dt>
<dd>Specifies the path to the <tt>install</tt> tool.</dd>
<dt><a name="LDFLAGS"><tt>LDFLAGS</tt></a><small>(configured)</small></dt>
@@ -834,17 +797,12 @@
<dd>Specifies the path to the LLVM version of the GCC 'C' Compiler</dd>
<dt><a name="LLVMGXX"><tt>LLVMGXX</tt></a><small>(defaulted)</small></dt>
<dd>Specifies the path to the LLVM version of the GCC C++ Compiler</dd>
<dt><a name="LLVMLD"><tt>LLVMLD</tt></a><small>(defaulted)</small></dt>
<dd>Specifies the path to the LLVM bytecode linker tool</dd>
<dt><a name="LLVM_OBJ_ROOT"><tt>LLVM_OBJ_ROOT</tt></a><small>(configured)
</small></dt>
<dt><a name="LLVM_OBJ_ROOT"><tt>LLVM_OBJ_ROOT</tt></a><small>(configured)</small></dt>
<dd>Specifies the top directory into which the output of the build is
placed.</dd>
<dt><a name="LLVM_SRC_ROOT"><tt>LLVM_SRC_ROOT</tt></a><small>(configured)
</small></dt>
<dt><a name="LLVM_SRC_ROOT"><tt>LLVM_SRC_ROOT</tt></a><small>(configured)</small></dt>
<dd>Specifies the top directory in which the sources are found.</dd>
<dt><a name="LLVM_TARBALL_NAME"><tt>LLVM_TARBALL_NAME</tt></a>
<small>(configured)</small></dt>
<dt><a name="LLVM_TARBALL_NAME"><tt>LLVM_TARBALL_NAME</tt></a><small>(configured)</small></dt>
<dd>Specifies the name of the distribution tarball to create. This is
configured from the name of the project and its version number.</dd>
<dt><a name="MKDIR"><tt>MKDIR</tt></a><small>(defaulted)</small></dt>
@@ -885,8 +843,8 @@
<dd>The name of the type of build being performed: Debug, Release, or
Profile</dd>
<dt><a name="bytecode_libdir"><tt>bytecode_libdir</tt></a></dt>
<dd>The directory into which bytecode libraries will ultimately be
installed. This value is derived from the <tt>--prefix</tt> option given to
<dd>The directory into which bytecode libraries will ultimately be installed.
This value is derived from the <tt>--prefix</tt> option given to
<tt>configure</tt>.</dd>
<dt><a name="ConfigureScriptFLAGS"><tt>ConfigureScriptFLAGS</tt></a></dt>
<dd>Additional flags given to the <tt>configure</tt> script when
@@ -954,6 +912,7 @@
BCCompile.C
BCCompile.CXX
BCLinkLib
Burg
C.Flags
Compile.C
CompileCommonOpts
@@ -1039,8 +998,9 @@
src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /></a>
<a href="mailto:rspencer@x10sys.com">Reid Spencer</a><br>
<a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br>
<a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a><br>
Last modified: $Date$
</address>
</body>
</html>

File diff suppressed because it is too large Load Diff

Some files were not shown because too many files have changed in this diff Show More