Add PR#566; something I should have done before.

llvm-svn: 22118

llvm/.cvsignore

@@ -3,3 +3,4 @@ Makefile.config
 config.log
 config.status
 cvs.out
+autom4te.cache

llvm/CREDITS.TXT

@@ -12,14 +12,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: Henrik Bach
+D: MingW Win32 API portability layer
+
 N: Nate Begeman
 E: natebegeman@mac.com
-D: Portions of the PowerPC backend
-
-N: Tanya Brethour
-E: tonic@nondot.org
-W: http://nondot.org/~tonic/
-D: The llvm-ar tool
+D: Primary PowerPC backend developer
 
 N: Misha Brukman
 E: brukman+llvm@uiuc.edu
@@ -35,28 +33,73 @@ N: Casey Carter
 E: ccarter@uiuc.edu
 D: Fixes to the Reassociation pass, various improvement patches
 
+N: Jeff Cohen
+E: jeffc@jolt-lang.org
+W: http://jolt-lang.org
+D: Native Win32 API portability layer
+
 N: John T. Criswell
 E: criswell@uiuc.edu
 D: Autoconf support, QMTest database, documentation improvements
 
+N: Alkis Evlogimenos
+E: alkis@evlogimenos.com
+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. 
+D: Portions of X86 static and JIT compilers; SparcV8 backend
 D: Dynamic trace optimizer 
 D: FreeBSD/X86 compatibility fixes, the llvm-nm tool
 
 N: Louis Gerbarg
 D: Portions of the PowerPC backend
 
+N: Paolo Invernizzi
+E: arathorn@fastwebnet.it
+D: Visual C++ compatibility fixes 
+
+N: Brad Jones
+E: kungfoomaster@nondot.org
+D: Support for packed types
+
+N: Sumant Kowshik
+E: kowshik@uiuc.edu
+D: Author of the original C backend
+
 N: Chris Lattner
 E: sabre@nondot.org
 W: http://nondot.org/~sabre/
 D: Primary architect of LLVM
 
+N: Tanya Lattner (formerly Tanya Brethour)
+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
+
+N: Andrew Lenharth
+E: alenhar2@cs.uiuc.edu
+W: http://www.lenharth.org/~andrewl/
+D: Alpha backend
+
+N: Duraid Madina
+E: duraid@octopus.com.au
+W: http://kinoko.c.u-tokyo.ac.jp/~duraid/
+D: IA64 backend
+
+N: Michael McCracken
+E: michael.mccracken@gmail.com
+D: Line number support for llvmgcc
+
 N: Vladimir Merzliakov
 E: wanderer@rsu.ru
-D: Test suite fixes for FreeBSD.
+D: Test suite fixes for FreeBSD
+
+N: Morten Ofstad
+E: morten@hue.no
+D: Visual C++ compatibility fixes 
 
 N: Vladimir Prus
 E: ghost@cs.msu.su
@@ -72,9 +115,12 @@ D: The `paths' pass
 
 N: Reid Spencer
 E: rspencer@x10sys.com
-W: http://extprosys.sourceforge.net/
-D: 'llvm' namespacification, Stacker FE, VMCore cleanup (SymbolTable, 
-D: Value != Type, CPR removal, bytecode improvements, llvmcs).
+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: Bill Wendling
 E: wendling@isanbard.org

llvm/LICENSE.TXT

@@ -4,7 +4,7 @@ LLVM Release License
 University of Illinois/NCSA
 Open Source License
 
-Copyright (c) 2003, 2004 University of Illinois at Urbana-Champaign.
+Copyright (c) 2003, 2004, 2005 University of Illinois at Urbana-Champaign.
 All rights reserved.
 
 Developed by:
@@ -61,41 +61,12 @@ licenses, and/or restrictions:
 
 Program             Directory
 -------             ---------
+System Library      llvm/lib/System
+Compiler Driver     llvm/tools/llvmc
 PowerPC Backend     llvm/lib/Target/PowerPC
-Autoconf:           llvm/autoconf
+bzip2               llvm/lib/Support/bzip2/LICENSE 
+Autoconf            llvm/autoconf
                     llvm/projects/ModuleMaker/autoconf
                     llvm/projects/sample/autoconf
-Burg:               llvm/utils/Burg
-                    llvm/test/Programs/MultiSource/Applications/Burg
-Aha:                llvm/test/Programs/MultiSource/Applications/aha
-SGEFA:              llvm/test/Programs/MultiSource/Applications/sgefa
-SIOD:               llvm/test/Programs/MultiSource/Applications/siod
-Spiff:              llvm/test/Programs/MultiSource/Applications/spiff
-D:                  llvm/test/Programs/MultiSource/Applications/d
-Lambda:             llvm/test/Programs/MultiSource/Applications/lambda-0.1.3
-hbd:                llvm/test/Programs/MultiSource/Applications/hbd
-treecc:             llvm/test/Programs/MultiSource/Applications/treecc
-kimwitu++:          llvm/test/Programs/MultiSource/Applications/kimwitu++
-obsequi:            llvm/test/Programs/MultiSource/Applications/obsequi
-Fhourstones:        llvm/test/Programs/MultiSource/Benchmarks/Fhourstones
-McCat:              llvm/test/Programs/MultiSource/Benchmarks/McCat
-Olden:              llvm/test/Programs/MultiSource/Benchmarks/Olden
-OptimizerEval:      llvm/test/Programs/MultiSource/Benchmarks/OptimizerEval
-Ptrdist:            llvm/test/Programs/MultiSource/Benchmarks/Ptrdist
-LLUBenchmark:       llvm/test/Programs/MultiSource/Benchmarks/llubenchmark
-SIM:                llvm/test/Programs/MultiSource/Benchmarks/sim
-cfrac:              llvm/test/Programs/MultiSource/Benchmarks/MallocBench/cfrac
-espresso:           llvm/test/Programs/MultiSource/Benchmarks/MallocBench/espresso
-gs:                 llvm/test/Programs/MultiSource/Benchmarks/MallocBench/gs
-p2c:                llvm/test/Programs/MultiSource/Benchmarks/MallocBench/p2c
-gawk:               llvm/test/Programs/MultiSource/Benchmarks/MallocBench/gawk
-make:               llvm/test/Programs/MultiSource/Benchmarks/MallocBench/make
-perl:               llvm/test/Programs/MultiSource/Benchmarks/MallocBench/perl
-Dhrystone:          llvm/test/Programs/SingleSource/Benchmarks/Dhrystone
-SingleSource Tests: llvm/test/Programs/SingleSource/Benchmarks/Misc
-                    llvm/test/Programs/SingleSource/CustomChecked
-                    llvm/test/Programs/SingleSource/Gizmos
-GNU Libc:           llvm/runtime/GCCLibraries/libc
-Zlib Library:       llvm/runtime/zlib
-PNG Library:        llvm/runtime/libpng
-
+Burg                llvm/utils/Burg
+GNU Libc            llvm/runtime/GCCLibraries/libc

llvm/Makefile

@@ -7,46 +7,38 @@
 # 
 #===------------------------------------------------------------------------===#
 LEVEL = .
-DIRS = lib/Support utils lib tools 
+DIRS = lib/System lib/Support utils lib tools 
 
 ifneq ($(MAKECMDGOALS),tools-only)
-DIRS += runtime
-OPTIONAL_DIRS = projects
+DIRS += runtime docs
+OPTIONAL_DIRS = examples projects
 endif
 
+EXTRA_DIST := test llvm.spec include
+
 include $(LEVEL)/Makefile.common
 
-test :: all
-	cd test; $(MAKE)
+.PHONY: debug-opt-prof
+debug-opt-prof:
+	$(Echo) Building Debug Version
+	$(Verb) $(MAKE)
+	$(Echo)
+	$(Echo) Building Optimized Version
+	$(Echo)
+	$(Verb) $(MAKE) ENABLE_OPTIMIZED=1
+	$(Echo)
+	$(Echo) Building Profiling Version
+	$(Echo)
+	$(Verb) $(MAKE) ENABLE_PROFILING=1
 
-distclean:: clean
-	$(VERB) $(RM) -rf $(LEVEL)/Makefile.config \
-	                  $(LEVEL)/include/Config/config.h \
-	                  $(LEVEL)/autoconf/autom4te.cache \
-	                  $(LEVEL)/config.log \
-	                  $(LEVEL)/TAGS
+dist-hook::
+	$(Echo) Eliminating files constructed by configure
+	$(Verb) $(RM) -f \
+	  $(TopDistDir)/include/llvm/ADT/hash_map  \
+	  $(TopDistDir)/include/llvm/ADT/hash_set  \
+	  $(TopDistDir)/include/llvm/ADT/iterator  \
+	  $(TopDistDir)/include/llvm/Config/config.h  \
+	  $(TopDistDir)/include/llvm/Support/DataTypes.h  \
+	  $(TopDistDir)/include/llvm/Support/ThreadSupport.h
 
 tools-only: all
-
-# Install support for llvm include files:
-.PHONY: install-includes
-
-install-includes:
-	$(MKDIR) $(DESTDIR)$(includedir)/llvm
-	cd include && find * -path '*/Internal' -prune -o '(' '!' '(' -name '*~' -o -name .cvsignore ')' -print ')' | grep -v CVS | pax -rwdvpe $(DESTDIR)$(includedir)/llvm
-ifneq ($(BUILD_SRC_ROOT),$(BUILD_OBJ_ROOT))
-	cd $(BUILD_SRC_ROOT)/include && find * -path '*/Internal' -prune -o '(' '!' '(' -name '*~' -o -name .cvsignore ')' -print ')' | grep -v CVS | pax -rwdvpe $(DESTDIR)$(includedir)/llvm
-endif
-
-install:: install-includes
-
-# Build tags database for Emacs/Xemacs:
-.PHONY: tags
-
-TAGS: tags
-
-all::
-
-tags:
-	find $(wildcard $(SourceDir)/include $(SourceDir)/lib $(SourceDir)/tools) -name '*.cpp' -o -name '*.h' | $(ETAGS) $(ETAGSFLAGS) -
-

llvm/Makefile.common

@@ -16,7 +16,7 @@
 # The variable $(LEVEL) *must* be set:
 #
 # 1. LEVEL - The level of the current subdirectory from the top of the 
-#    MagicStats view.  This level should be expressed as a path, for 
+#    source directory.  This level should be expressed as a path, for 
 #    example, ../.. for two levels deep.
 #
 # 2. DIRS - A list of subdirectories to be built.  Fake targets are set up
@@ -39,25 +39,29 @@
 #
 # 6. LLVM_SRC_ROOT - If specified, points to the top of the LLVM source tree.
 #
-# 8. BUILD_SRC_DIR - The directory which contains the current set of Makefiles
+# 8. PROJ_SRC_DIR - The directory which contains the current set of Makefiles
 #    and usually the source code too (unless SourceDir is set).
 #
-# 9. BUILD_SRC_ROOT - The root directory of the source code being compiled.
+# 9. PROJ_SRC_ROOT - The root directory of the source code being compiled.
 #
-# 10. BUILD_OBJ_DIR - The directory where object code should be placed.
+# 10. PROJ_OBJ_DIR - The directory where object code should be placed.
 #
-# 11. BUILD_OBJ_ROOT - The root directory for where object code should be
+# 11. PROJ_OBJ_ROOT - The root directory for where object code should be
 #     placed.
 #
 # For building,
-# 	LLVM, LLVM_SRC_ROOT = BUILD_SRC_ROOT
+# 	LLVM, LLVM_SRC_ROOT = PROJ_SRC_ROOT
 #
 #===-----------------------------------------------------------------------====
 
 #
 # Configuration file to set paths specific to local installation of LLVM
 # 
+ifndef LLVM_OBJ_ROOT
 include $(LEVEL)/Makefile.config
+else
+include $(LLVM_OBJ_ROOT)/Makefile.config
+endif
 
 #
 # Include all of the build rules used for making LLVM

llvm/Makefile.config.in

@@ -12,12 +12,97 @@
 #
 #===------------------------------------------------------------------------===#
 
+# Define LLVM specific info and directories based on the autoconf variables
+LLVMPackageName   := @PACKAGE_NAME@
+LLVMVersion       := @PACKAGE_VERSION@
+LLVM_CONFIGTIME   := @LLVM_CONFIGTIME@
+
+###########################################################################
+# Directory Configuration
+#	This section of the Makefile determines what is where.  To be
+#	specific, there are several locations that need to be defined:
+#
+#	o LLVM_SRC_ROOT  : The root directory of the LLVM source code.
+#	o LLVM_OBJ_ROOT  : The root directory containing the built LLVM code.
+#
+#	o PROJ_SRC_DIR  : The directory containing the code to build.
+#	o PROJ_SRC_ROOT : The root directory of the code to build.
+#
+#	o PROJ_OBJ_DIR  : The directory in which compiled code will be placed.
+#	o PROJ_OBJ_ROOT : The root directory in which compiled code is placed.
+#
+###########################################################################
+
+# Set the project name to LLVM if its not defined
+ifndef PROJECT_NAME
+PROJECT_NAME := LLVM
+endif
+
+PROJ_OBJ_DIR  := $(shell pwd)
+PROJ_OBJ_ROOT := $(subst //,/,$(shell cd $(PROJ_OBJ_DIR)/$(LEVEL); pwd))
+
+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
+$(error Projects must define PROJ_SRC_ROOT)
+endif
+ifndef PROJ_OBJ_ROOT
+$(error Projects must define PROJ_OBJ_ROOT)
+endif
+ifndef PROJ_INSTALL_ROOT
+$(error Projects must define PROJ_INSTALL_ROOT)
+endif
+ifndef LLVM_SRC_ROOT
+$(error Projects must define LLVM_SRC_ROOT)
+endif
+ifndef LLVM_OBJ_ROOT
+$(error Projects must define LLVM_OBJ_ROOT)
+endif
+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
+
+# Determine if we're on a unix type operating system
+LLVM_ON_UNIX:=@LLVM_ON_UNIX@
+LLVM_ON_WIN32:=@LLVM_ON_WIN32@
+
 # Target operating system for which LLVM will be compiled.
 OS=@OS@
 
 # Target hardware architecture
 ARCH=@ARCH@
 
+# 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@
+
 # Endian-ness of the target
 ENDIAN=@ENDIAN@
 
@@ -28,83 +113,62 @@ CXX = @CXX@
 # Path to the CC binary, which use used by testcases for native builds.
 CC := @CC@
 
-# Path to the Python interpreter
-PYTHON := @PYTHON@
-
 # Linker flags.
 LDFLAGS+=@LDFLAGS@
 
-# Libraries needed by tools
-TOOLLINKOPTS=@LIBS@
-
 # Path to the library archiver program.
 AR_PATH = @AR@
 
-# The pathnames of the Flex and Bison programs, respectively.
-YACC     = @YACC@
-BISON    = @BISON@
-FLEX     = @LEX@
+# The pathnames of the programs we require to build
+BISON      := @BISON@
+CMP        := @CMP@
+CP         := @CP@
+DATE       := @DATE@
+FIND       := @FIND@
+FLEX       := @LEX@
+GREP       := @GREP@
+INSTALL    := @INSTALL@
+MKDIR      := $(LLVM_SRC_ROOT)/autoconf/mkinstalldirs
+MV         := @MV@
+RANLIB     := @RANLIB@
+RM         := @RM@
+SED        := @SED@
+TAR        := @TAR@
+YACC       := @YACC@
 
-# Paths to miscellaneous programs.
-RPWD    = pwd
-SED     = sed
-RM      = rm
-ECHO    = echo
-MKDIR   = @abs_top_srcdir@/autoconf/mkinstalldirs
-DATE    = date
-MV      = mv
-INSTALL = @INSTALL@
-DOT     = @DOT@
-ETAGS   = @ETAGS@
-ETAGSFLAGS = @ETAGSFLAGS@
+# Paths to miscellaneous programs we hope are present but might not be
+BZIP2      := @BZIP2@
+DOT        := @DOT@
+DOXYGEN    := @DOXYGEN@
+ETAGS      := @ETAGS@
+ETAGSFLAGS := @ETAGSFLAGS@
+GROFF      := @GROFF@
+GZIP       := @GZIP@
+POD2HTML   := @POD2HTML@
+POD2MAN    := @POD2MAN@
+RUNTEST    := @RUNTEST@
+TCLSH      := @TCLSH@
+ZIP        := @ZIP@
 
-# Determine the target for which LLVM should generate code.
-LLVMGCCARCH := @target@/3.4-llvm
-
-# Full pathnames of LLVM C/C++ front-end 'cc1' and 'cc1plus' binaries:
-LCC1 = @LLVMCC1@
-LCC1XX = @LLVMCC1PLUS@
-
-# 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
-# object files.
-OBJ_ROOT := .
+LIBS       := @LIBS@
 
 # Path to location for LLVM C/C++ front-end. You can modify this if you
 # want to override the value set by configure.
 LLVMGCCDIR := @LLVMGCCDIR@
 
-# When this variable is set to 1, programs in the llvm/test/Programs hierarchy
-# are not recompiled from source code.  Instead, the bytecode for the file is
-# pulled from the BYTECODE_REPOSITORY directory.  This can be useful when disk
-# space is limited or when you just don't want to spend time running the C
-# frontend.
-#USE_PRECOMPILED_BYTECODE := 1
-@UPB@
+# Determine the target for which LLVM should generate code.
+LLVMGCCARCH := @target@/3.4-llvm
 
-# This path specifies the cannonical location of bytecode files for compiled
-# versions of the test/Programs/* programs.  This is used as the bytecode source
-# when USE_PRECOMPILED_BYTECODE is specified or when source code is not
-# available for the program (such as SPEC).
-BYTECODE_REPOSITORY := @BCR@
+# Full pathnames of LLVM C/C++ front-end 'cc1' and 'cc1plus' binaries:
+LLVMGCC  := @LLVMGCC@
+LLVMGXX  := @LLVMGXX@
+LLVMCC1  := @LLVMCC1@
+LLVMCC1PLUS := @LLVMCC1PLUS@
 
-# SPEC benchmarks:
-#	If these are set then run the SPEC benchmarks.
-#	You must provide the SPEC benchmarks on your own.
-@USE_SPEC2000@
-@USE_SPEC95@
-
-# Path to the SPEC benchmarks.
-SPEC2000_ROOT := @SPEC2000_ROOT@
-SPEC95_ROOT := @SPEC95_ROOT@
-
-# Path to the Povray source code.
-@USE_POVRAY@
-POVRAY_ROOT := @POVRAY_ROOT@
-
-# Path to the PAPI code.  This is used by the reoptimizer only.
-#PAPIDIR := /home/vadve/shared/papi-2.3.4.1
-PAPIDIR := @PAPIDIR@
+# 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
+# object files.
+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):
@@ -118,6 +182,9 @@ PAPIDIR := @PAPIDIR@
 # information to allow gprof to be used to get execution frequencies.
 #ENABLE_PROFILING = 1
 
+# When ENABLE_DOXYGEN is enabled, the doxygen documentation will be built
+ENABLE_DOXYGEN = @ENABLE_DOXYGEN@
+
 # This option tells the Makefiles to produce verbose output.
 # It essentially prints the commands that make is executing
 #VERBOSE = 1
@@ -125,88 +192,11 @@ PAPIDIR := @PAPIDIR@
 # Enable JIT for this platform
 @JIT@
 
-# Disable LLC diffs for testing.
-@DISABLE_LLC_DIFFS@
-
 # Shared library extension for this platform.
 SHLIBEXT = @SHLIBEXT@
 
 # Executable file extension for this platform.
 EXEEXT = @EXEEXT@
 
-###########################################################################
-# Directory Configuration
-#	This section of the Makefile determines what is where.  To be
-#	specific, there are several locations that need to be defined:
-#
-#	o LLVM_SRC_ROOT  : The root directory of the LLVM source code.
-#	o LLVM_OBJ_ROOT  : The root directory containing the built LLVM code.
-#
-#	o BUILD_SRC_DIR  : The directory containing the code to build.
-#	o BUILD_SRC_ROOT : The root directory of the code to build.
-#
-#	o BUILD_OBJ_DIR  : The directory in which compiled code will be placed.
-#	o BUILD_OBJ_ROOT : The root directory in which compiled code is placed.
-#
-###########################################################################
-
-# Set the object build directory.  By default, it is the current directory.
-ifndef BUILD_OBJ_DIR
-BUILD_OBJ_DIR := $(subst //,/,$(shell $(RPWD)))
-endif
-
-# Set the root of the object directory.
-ifndef BUILD_OBJ_ROOT
-BUILD_OBJ_ROOT := $(subst //,/,$(shell cd $(BUILD_OBJ_DIR)/$(LEVEL); $(RPWD)))
-endif
-
-# Set the source build directory.  That is almost always the current directory.
-ifndef BUILD_SRC_DIR
-BUILD_SRC_DIR := $(subst //,/,@abs_top_srcdir@/$(patsubst $(BUILD_OBJ_ROOT)%,%,$(BUILD_OBJ_DIR)))
-endif
-
-# Set the source root directory.
-ifndef BUILD_SRC_ROOT
-BUILD_SRC_ROOT := $(subst //,/,@abs_top_srcdir@)
-endif
-
-# Set the LLVM object directory.
-ifndef LLVM_OBJ_ROOT
-ifdef LLVM_SRC_ROOT
-LLVM_OBJ_ROOT := $(shell cd $(LLVM_SRC_ROOT); $(RPWD))
-else
-LLVM_OBJ_ROOT := $(BUILD_OBJ_ROOT)
-endif
-endif
-
-# Set the LLVM source directory.
-# It is typically the root directory of what we're compiling now.
-ifndef LLVM_SRC_ROOT
-LLVM_SRC_ROOT := $(BUILD_SRC_ROOT)
-endif
-
-# Set SourceDir for backwards compatbility.
-ifndef SourceDir
-SourceDir=$(BUILD_SRC_DIR)
-endif
-
-# Installation directories, as provided by the configure script.
-exec_prefix = @exec_prefix@
-prefix = @prefix@
-program_transform_name = @program_transform_name@
-bindir = @bindir@
-sbindir = @sbindir@
-libexecdir = @libexecdir@
-datadir = @datadir@
-sysconfdir = @sysconfdir@
-sharedstatedir = @sharedstatedir@ 
-localstatedir = @localstatedir@
-libdir = @libdir@
-bytecode_libdir = $(LLVMGCCDIR)/bytecode-libs
-includedir = @includedir@
-infodir = @infodir@
-mandir = @mandir@
-INSTALL_PROGRAM = @INSTALL_PROGRAM@
-INSTALL_SCRIPT = @INSTALL_SCRIPT@
-INSTALL_DATA = @INSTALL_DATA@
-
+# Things we just assume are "there"
+ECHO := echo

llvm/README.txt

@@ -1 +1,12 @@
-This file is a placeholder; see docs/index.html for documentation.
+Low Level Virtual Machine (LLVM)
+================================
+
+This directory and its subdirectories contain source code for the Low Level 
+Virtual Machine, a toolkit for the construction of highly optimized compilers,
+optimizers, and runtime environments. 
+
+LLVM is open source software. You may freely distribute it under the terms of
+the license agreement found in LICENSE.txt.
+
+Please see the HTML documentation provided in docs/index.html for further
+assistance with LLVM.

llvm/autoconf/.cvsignore

@@ -0,0 +1,2 @@
+aclocal.m4
+autom4te.cache

llvm/autoconf/AutoRegen.sh

@@ -3,19 +3,41 @@ die () {
 	echo "$@" 1>&2
 	exit 1
 }
-test -d autoconf && test -f autoconf/configure.ac && cd autoconf
-[ -f configure.ac ] || die "Can't find 'autoconf' dir; please cd into it first"
-echo "Regenerating aclocal.m4 with aclocal"
-aclocal || die "aclocal failed"
-autoconf --version | egrep '2\.5[0-9]' > /dev/null
-if test $? -ne 0
-then
-	die "Your autoconf was not detected as being 2.5x"
+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 | egrep '2\.59' > /dev/null
+if test $? -ne 0 ; then
+  die "Your autoconf was not detected as being 2.59"
 fi
-echo "Note: Warnings about 'AC_CONFIG_SUBDIRS: you should use literals' are ok"
-echo "Regenerating configure with autoconf 2.5x"
-autoconf -o ../configure configure.ac || die "autoconf failed"
+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"
+echo "### scripts in the m4 directory because there are future forward"
+echo "### compatibility or platform support issues at risk. Please do NOT"
+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.2"
+cwd=`pwd`
+aclocal --force -I $cwd/m4 || die "aclocal failed"
+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.5x"
-autoheader -I autoconf autoconf/configure.ac || die "autoheader failed"
+echo "Regenerating config.h.in with autoheader 2.59"
+autoheader --warnings=all -I autoconf -I autoconf/m4 autoconf/$configfile || die "autoheader failed"
 exit 0

llvm/autoconf/README.TXT

@@ -0,0 +1,40 @@
+Upgrading Libtool
+===============================================================================
+
+If you are in the mood to upgrade libtool, you must do the following:
+
+ 1. Get the new version of libtool and put it in <SRC>
+ 2. configure/build/install libtool with --prefix=<PFX>
+ 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. 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 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.
+
+Upgrading autoconf
+===============================================================================
+
+If you are in the mood to upgrade autoconf, you should:
+
+ 1. Consider not upgrading.
+ 2. No really, this is a hassle, you don't want to do it.
+ 3. Get the new version of autoconf and put it in <SRC>
+ 4. configure/build/install autoconf with --prefix=<PFX>
+ 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 autoconf, fix them and go to step 7.
+ 9. Test, test, test.

llvm/autoconf/config.guess

@@ -1,9 +1,9 @@
 #! /bin/sh
 # Attempt to guess a canonical system name.
 #   Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
-#   2000, 2001, 2002, 2003 Free Software Foundation, Inc.
+#   2000, 2001, 2002, 2003, 2004 Free Software Foundation, Inc.
 
-timestamp='2003-02-22'
+timestamp='2004-09-07'
 
 # This file is free software; you can redistribute it and/or modify it
 # under the terms of the GNU General Public License as published by
@@ -53,7 +53,7 @@ version="\
 GNU config.guess ($timestamp)
 
 Originally written by Per Bothner.
-Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001
+Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004
 Free Software Foundation, Inc.
 
 This is free software; see the source for copying conditions.  There is NO
@@ -106,6 +106,7 @@ trap "rm -f \$tmpfiles 2>/dev/null; rmdir \$tmp 2>/dev/null; exit 1" 1 2 13 15 ;
 : ${TMPDIR=/tmp} ;
  { tmp=`(umask 077 && mktemp -d -q "$TMPDIR/cgXXXXXX") 2>/dev/null` && test -n "$tmp" && test -d "$tmp" ; } ||
  { test -n "$RANDOM" && tmp=$TMPDIR/cg$$-$RANDOM && (umask 077 && mkdir $tmp) ; } ||
+ { tmp=$TMPDIR/cg-$$ && (umask 077 && mkdir $tmp) && echo "Warning: creating insecure temp directory" >&2 ; } ||
  { echo "$me: cannot create a temporary directory in $TMPDIR" >&2 ; exit 1 ; } ;
 dummy=$tmp/dummy ;
 tmpfiles="$dummy.c $dummy.o $dummy.rel $dummy" ;
@@ -196,15 +197,21 @@ case "${UNAME_MACHINE}:${UNAME_SYSTEM}:${UNAME_RELEASE}:${UNAME_VERSION}" in
 	# CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM is used.
 	echo "${machine}-${os}${release}"
 	exit 0 ;;
+    amd64:OpenBSD:*:*)
+	echo x86_64-unknown-openbsd${UNAME_RELEASE}
+	exit 0 ;;
     amiga:OpenBSD:*:*)
 	echo m68k-unknown-openbsd${UNAME_RELEASE}
 	exit 0 ;;
-    arc:OpenBSD:*:*)
-	echo mipsel-unknown-openbsd${UNAME_RELEASE}
+    cats:OpenBSD:*:*)
+	echo arm-unknown-openbsd${UNAME_RELEASE}
 	exit 0 ;;
     hp300:OpenBSD:*:*)
 	echo m68k-unknown-openbsd${UNAME_RELEASE}
 	exit 0 ;;
+    luna88k:OpenBSD:*:*)
+    	echo m88k-unknown-openbsd${UNAME_RELEASE}
+	exit 0 ;;
     mac68k:OpenBSD:*:*)
 	echo m68k-unknown-openbsd${UNAME_RELEASE}
 	exit 0 ;;
@@ -220,25 +227,33 @@ case "${UNAME_MACHINE}:${UNAME_SYSTEM}:${UNAME_RELEASE}:${UNAME_VERSION}" in
     mvmeppc:OpenBSD:*:*)
 	echo powerpc-unknown-openbsd${UNAME_RELEASE}
 	exit 0 ;;
-    pmax:OpenBSD:*:*)
-	echo mipsel-unknown-openbsd${UNAME_RELEASE}
-	exit 0 ;;
     sgi:OpenBSD:*:*)
-	echo mipseb-unknown-openbsd${UNAME_RELEASE}
+	echo mips64-unknown-openbsd${UNAME_RELEASE}
 	exit 0 ;;
     sun3:OpenBSD:*:*)
 	echo m68k-unknown-openbsd${UNAME_RELEASE}
 	exit 0 ;;
-    wgrisc:OpenBSD:*:*)
-	echo mipsel-unknown-openbsd${UNAME_RELEASE}
-	exit 0 ;;
     *:OpenBSD:*:*)
 	echo ${UNAME_MACHINE}-unknown-openbsd${UNAME_RELEASE}
 	exit 0 ;;
+    *:ekkoBSD:*:*)
+	echo ${UNAME_MACHINE}-unknown-ekkobsd${UNAME_RELEASE}
+	exit 0 ;;
+    macppc:MirBSD:*:*)
+	echo powerppc-unknown-mirbsd${UNAME_RELEASE}
+	exit 0 ;;
+    *:MirBSD:*:*)
+	echo ${UNAME_MACHINE}-unknown-mirbsd${UNAME_RELEASE}
+	exit 0 ;;
     alpha:OSF1:*:*)
-	if test $UNAME_RELEASE = "V4.0"; then
+	case $UNAME_RELEASE in
+	*4.0)
 		UNAME_RELEASE=`/usr/sbin/sizer -v | awk '{print $3}'`
-	fi
+		;;
+	*5.*)
+	        UNAME_RELEASE=`/usr/sbin/sizer -v | awk '{print $4}'`
+		;;
+	esac
 	# According to Compaq, /usr/sbin/psrinfo has been available on
 	# OSF/1 and Tru64 systems produced since 1995.  I hope that
 	# covers most systems running today.  This code pipes the CPU
@@ -276,11 +291,12 @@ case "${UNAME_MACHINE}:${UNAME_SYSTEM}:${UNAME_RELEASE}:${UNAME_VERSION}" in
 	    "EV7.9 (21364A)")
 		UNAME_MACHINE="alphaev79" ;;
 	esac
+	# A Pn.n version is a patched version.
 	# A Vn.n version is a released version.
 	# A Tn.n version is a released field test version.
 	# A Xn.n version is an unreleased experimental baselevel.
 	# 1.2 uses "1.2" for uname -r.
-	echo ${UNAME_MACHINE}-dec-osf`echo ${UNAME_RELEASE} | sed -e 's/^[VTX]//' | tr 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'abcdefghijklmnopqrstuvwxyz'`
+	echo ${UNAME_MACHINE}-dec-osf`echo ${UNAME_RELEASE} | sed -e 's/^[PVTX]//' | tr 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'abcdefghijklmnopqrstuvwxyz'`
 	exit 0 ;;
     Alpha\ *:Windows_NT*:*)
 	# How do we know it's Interix rather than the generic POSIX subsystem?
@@ -303,6 +319,9 @@ case "${UNAME_MACHINE}:${UNAME_SYSTEM}:${UNAME_RELEASE}:${UNAME_VERSION}" in
     *:OS/390:*:*)
 	echo i370-ibm-openedition
 	exit 0 ;;
+    *:OS400:*:*)
+        echo powerpc-ibm-os400
+	exit 0 ;;
     arm:RISC*:1.[012]*:*|arm:riscix:1.[012]*:*)
 	echo arm-acorn-riscix${UNAME_RELEASE}
 	exit 0;;
@@ -320,6 +339,9 @@ case "${UNAME_MACHINE}:${UNAME_SYSTEM}:${UNAME_RELEASE}:${UNAME_VERSION}" in
     NILE*:*:*:dcosx)
 	echo pyramid-pyramid-svr4
 	exit 0 ;;
+    DRS?6000:unix:4.0:6*)
+	echo sparc-icl-nx6
+	exit 0 ;;
     DRS?6000:UNIX_SV:4.2*:7*)
 	case `/usr/bin/uname -p` in
 	    sparc) echo sparc-icl-nx7 && exit 0 ;;
@@ -392,6 +414,9 @@ case "${UNAME_MACHINE}:${UNAME_SYSTEM}:${UNAME_RELEASE}:${UNAME_VERSION}" in
     *:*MiNT:*:* | *:*mint:*:* | *:*TOS:*:*)
         echo m68k-unknown-mint${UNAME_RELEASE}
         exit 0 ;;
+    m68k:machten:*:*)
+	echo m68k-apple-machten${UNAME_RELEASE}
+	exit 0 ;;
     powerpc:machten:*:*)
 	echo powerpc-apple-machten${UNAME_RELEASE}
 	exit 0 ;;
@@ -727,7 +752,7 @@ EOF
 	echo sv1-cray-unicos${UNAME_RELEASE} | sed -e 's/\.[^.]*$/.X/'
 	exit 0 ;;
     *:UNICOS/mp:*:*)
-	echo nv1-cray-unicosmp${UNAME_RELEASE} | sed -e 's/\.[^.]*$/.X/' 
+	echo craynv-cray-unicosmp${UNAME_RELEASE} | sed -e 's/\.[^.]*$/.X/'
 	exit 0 ;;
     F30[01]:UNIX_System_V:*:* | F700:UNIX_System_V:*:*)
 	FUJITSU_PROC=`uname -m | tr 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'abcdefghijklmnopqrstuvwxyz'`
@@ -735,6 +760,11 @@ EOF
         FUJITSU_REL=`echo ${UNAME_RELEASE} | sed -e 's/ /_/'`
         echo "${FUJITSU_PROC}-fujitsu-${FUJITSU_SYS}${FUJITSU_REL}"
         exit 0 ;;
+    5000:UNIX_System_V:4.*:*)
+        FUJITSU_SYS=`uname -p | tr 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'abcdefghijklmnopqrstuvwxyz' | sed -e 's/\///'`
+        FUJITSU_REL=`echo ${UNAME_RELEASE} | tr 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'abcdefghijklmnopqrstuvwxyz' | sed -e 's/ /_/'`
+        echo "sparc-fujitsu-${FUJITSU_SYS}${FUJITSU_REL}"
+	exit 0 ;;
     i*86:BSD/386:*:* | i*86:BSD/OS:*:* | *:Ascend\ Embedded/OS:*:*)
 	echo ${UNAME_MACHINE}-pc-bsdi${UNAME_RELEASE}
 	exit 0 ;;
@@ -745,18 +775,7 @@ EOF
 	echo ${UNAME_MACHINE}-unknown-bsdi${UNAME_RELEASE}
 	exit 0 ;;
     *:FreeBSD:*:*)
-	# Determine whether the default compiler uses glibc.
-	eval $set_cc_for_build
-	sed 's/^	//' << EOF >$dummy.c
-	#include <features.h>
-	#if __GLIBC__ >= 2
-	LIBC=gnu
-	#else
-	LIBC=
-	#endif
-EOF
-	eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep ^LIBC=`
-	echo ${UNAME_MACHINE}-unknown-freebsd`echo ${UNAME_RELEASE}|sed -e 's/[-(].*//'`${LIBC:+-$LIBC}
+	echo ${UNAME_MACHINE}-unknown-freebsd`echo ${UNAME_RELEASE}|sed -e 's/[-(].*//'`
 	exit 0 ;;
     i*:CYGWIN*:*)
 	echo ${UNAME_MACHINE}-pc-cygwin
@@ -767,8 +786,8 @@ EOF
     i*:PW*:*)
 	echo ${UNAME_MACHINE}-pc-pw32
 	exit 0 ;;
-    x86:Interix*:3*)
-	echo i586-pc-interix3
+    x86:Interix*:[34]*)
+	echo i586-pc-interix${UNAME_RELEASE}|sed -e 's/\..*//'
 	exit 0 ;;
     [345]86:Windows_95:* | [345]86:Windows_98:* | [345]86:Windows_NT:*)
 	echo i${UNAME_MACHINE}-pc-mks
@@ -789,17 +808,34 @@ EOF
 	echo powerpcle-unknown-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
 	exit 0 ;;
     *:GNU:*:*)
+	# the GNU system
 	echo `echo ${UNAME_MACHINE}|sed -e 's,[-/].*$,,'`-unknown-gnu`echo ${UNAME_RELEASE}|sed -e 's,/.*$,,'`
 	exit 0 ;;
+    *:GNU/*:*:*)
+	# other systems with GNU libc and userland
+	echo ${UNAME_MACHINE}-unknown-`echo ${UNAME_SYSTEM} | sed 's,^[^/]*/,,' | tr '[A-Z]' '[a-z]'``echo ${UNAME_RELEASE}|sed -e 's/[-(].*//'`-gnu
+	exit 0 ;;
     i*86:Minix:*:*)
 	echo ${UNAME_MACHINE}-pc-minix
 	exit 0 ;;
     arm*:Linux:*:*)
 	echo ${UNAME_MACHINE}-unknown-linux-gnu
 	exit 0 ;;
+    cris:Linux:*:*)
+	echo cris-axis-linux-gnu
+	exit 0 ;;
+    crisv32:Linux:*:*)
+	echo crisv32-axis-linux-gnu
+	exit 0 ;;
+    frv:Linux:*:*)
+    	echo frv-unknown-linux-gnu
+	exit 0 ;;
     ia64:Linux:*:*)
 	echo ${UNAME_MACHINE}-unknown-linux-gnu
 	exit 0 ;;
+    m32r*:Linux:*:*)
+	echo ${UNAME_MACHINE}-unknown-linux-gnu
+	exit 0 ;;
     m68*:Linux:*:*)
 	echo ${UNAME_MACHINE}-unknown-linux-gnu
 	exit 0 ;;
@@ -875,6 +911,9 @@ EOF
     s390:Linux:*:* | s390x:Linux:*:*)
 	echo ${UNAME_MACHINE}-ibm-linux
 	exit 0 ;;
+    sh64*:Linux:*:*)
+    	echo ${UNAME_MACHINE}-unknown-linux-gnu
+	exit 0 ;;
     sh*:Linux:*:*)
 	echo ${UNAME_MACHINE}-unknown-linux-gnu
 	exit 0 ;;
@@ -932,6 +971,9 @@ EOF
 	LIBC=gnuaout
 	#endif
 	#endif
+	#ifdef __dietlibc__
+	LIBC=dietlibc
+	#endif
 EOF
 	eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep ^LIBC=`
 	test x"${LIBC}" != x && echo "${UNAME_MACHINE}-pc-linux-${LIBC}" && exit 0
@@ -962,6 +1004,9 @@ EOF
     i*86:atheos:*:*)
 	echo ${UNAME_MACHINE}-unknown-atheos
 	exit 0 ;;
+	i*86:syllable:*:*)
+	echo ${UNAME_MACHINE}-pc-syllable
+	exit 0 ;;
     i*86:LynxOS:2.*:* | i*86:LynxOS:3.[01]*:* | i*86:LynxOS:4.0*:*)
 	echo i386-unknown-lynxos${UNAME_RELEASE}
 	exit 0 ;;
@@ -1031,9 +1076,9 @@ EOF
     M680?0:D-NIX:5.3:*)
 	echo m68k-diab-dnix
 	exit 0 ;;
-    M68*:*:R3V[567]*:*)
+    M68*:*:R3V[5678]*:*)
 	test -r /sysV68 && echo 'm68k-motorola-sysv' && exit 0 ;;
-    3[34]??:*:4.0:3.0 | 3[34]??A:*:4.0:3.0 | 3[34]??,*:*:4.0:3.0 | 3[34]??/*:*:4.0:3.0 | 4400:*:4.0:3.0 | 4850:*:4.0:3.0 | SKA40:*:4.0:3.0 | SDS2:*:4.0:3.0)
+    3[345]??:*:4.0:3.0 | 3[34]??A:*:4.0:3.0 | 3[34]??,*:*:4.0:3.0 | 3[34]??/*:*:4.0:3.0 | 4400:*:4.0:3.0 | 4850:*:4.0:3.0 | SKA40:*:4.0:3.0 | SDS2:*:4.0:3.0 | SHG2:*:4.0:3.0 | S7501*:*:4.0:3.0)
 	OS_REL=''
 	test -r /etc/.relid \
 	&& OS_REL=.`sed -n 's/[^ ]* [^ ]* \([0-9][0-9]\).*/\1/p' < /etc/.relid`
@@ -1131,9 +1176,10 @@ EOF
 	echo ${UNAME_MACHINE}-apple-rhapsody${UNAME_RELEASE}
 	exit 0 ;;
     *:Darwin:*:*)
-	case `uname -p` in
+	UNAME_PROCESSOR=`uname -p` || UNAME_PROCESSOR=unknown
+	case $UNAME_PROCESSOR in
 	    *86) UNAME_PROCESSOR=i686 ;;
-	    powerpc) UNAME_PROCESSOR=powerpc ;;
+	    unknown) UNAME_PROCESSOR=powerpc ;;
 	esac
 	echo ${UNAME_PROCESSOR}-apple-darwin${UNAME_RELEASE}
 	exit 0 ;;
@@ -1148,7 +1194,7 @@ EOF
     *:QNX:*:4*)
 	echo i386-pc-qnx
 	exit 0 ;;
-    NSR-[DGKLNPTVW]:NONSTOP_KERNEL:*:*)
+    NSR-?:NONSTOP_KERNEL:*:*)
 	echo nsr-tandem-nsk${UNAME_RELEASE}
 	exit 0 ;;
     *:NonStop-UX:*:*)
@@ -1189,6 +1235,19 @@ EOF
     *:ITS:*:*)
 	echo pdp10-unknown-its
 	exit 0 ;;
+    SEI:*:*:SEIUX)
+        echo mips-sei-seiux${UNAME_RELEASE}
+	exit 0 ;;
+    *:DragonFly:*:*)
+	echo ${UNAME_MACHINE}-unknown-dragonfly`echo ${UNAME_RELEASE}|sed -e 's/[-(].*//'`
+	exit 0 ;;
+    *:*VMS:*:*)
+    	UNAME_MACHINE=`(uname -p) 2>/dev/null`
+	case "${UNAME_MACHINE}" in
+	    A*) echo alpha-dec-vms && exit 0 ;;
+	    I*) echo ia64-dec-vms && exit 0 ;;
+	    V*) echo vax-dec-vms && exit 0 ;;
+	esac
 esac
 
 #echo '(No uname command or uname output not recognized.)' 1>&2

llvm/autoconf/config.sub

@@ -1,9 +1,9 @@
 #! /bin/sh
 # Configuration validation subroutine script.
 #   Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
-#   2000, 2001, 2002, 2003 Free Software Foundation, Inc.
+#   2000, 2001, 2002, 2003, 2004 Free Software Foundation, Inc.
 
-timestamp='2003-02-22'
+timestamp='2004-08-29'
 
 # This file is (in principle) common to ALL GNU software.
 # The presence of a machine in this file suggests that SOME GNU software
@@ -70,7 +70,7 @@ Report bugs and patches to <config-patches@gnu.org>."
 version="\
 GNU config.sub ($timestamp)
 
-Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001
+Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004
 Free Software Foundation, Inc.
 
 This is free software; see the source for copying conditions.  There is NO
@@ -118,7 +118,8 @@ esac
 # Here we must recognize all the valid KERNEL-OS combinations.
 maybe_os=`echo $1 | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\2/'`
 case $maybe_os in
-  nto-qnx* | linux-gnu* | freebsd*-gnu* | netbsd*-gnu* | storm-chaos* | os2-emx* | rtmk-nova*)
+  nto-qnx* | linux-gnu* | linux-dietlibc | linux-uclibc* | uclinux-uclibc* | uclinux-gnu* | \
+  kfreebsd*-gnu* | knetbsd*-gnu* | netbsd*-gnu* | storm-chaos* | os2-emx* | rtmk-nova*)
     os=-$maybe_os
     basic_machine=`echo $1 | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\1/'`
     ;;
@@ -144,7 +145,7 @@ case $os in
 	-convergent* | -ncr* | -news | -32* | -3600* | -3100* | -hitachi* |\
 	-c[123]* | -convex* | -sun | -crds | -omron* | -dg | -ultra | -tti* | \
 	-harris | -dolphin | -highlevel | -gould | -cbm | -ns | -masscomp | \
-	-apple | -axis)
+	-apple | -axis | -knuth | -cray)
 		os=
 		basic_machine=$1
 		;;
@@ -228,14 +229,15 @@ case $basic_machine in
 	| a29k \
 	| alpha | alphaev[4-8] | alphaev56 | alphaev6[78] | alphapca5[67] \
 	| alpha64 | alpha64ev[4-8] | alpha64ev56 | alpha64ev6[78] | alpha64pca5[67] \
+	| am33_2.0 \
 	| arc | arm | arm[bl]e | arme[lb] | armv[2345] | armv[345][lb] | avr \
-	| clipper \
+	| c4x | clipper \
 	| d10v | d30v | dlx | dsp16xx \
 	| fr30 | frv \
 	| h8300 | h8500 | hppa | hppa1.[01] | hppa2.0 | hppa2.0[nw] | hppa64 \
 	| i370 | i860 | i960 | ia64 \
-	| ip2k \
-	| m32r | m68000 | m68k | m88k | mcore \
+	| ip2k | iq2000 \
+	| m32r | m32rle | m68000 | m68k | m88k | mcore \
 	| mips | mipsbe | mipseb | mipsel | mipsle \
 	| mips16 \
 	| mips64 | mips64el \
@@ -247,6 +249,7 @@ case $basic_machine in
 	| mipsisa32 | mipsisa32el \
 	| mipsisa32r2 | mipsisa32r2el \
 	| mipsisa64 | mipsisa64el \
+	| mipsisa64r2 | mipsisa64r2el \
 	| mipsisa64sb1 | mipsisa64sb1el \
 	| mipsisa64sr71k | mipsisa64sr71kel \
 	| mipstx39 | mipstx39el \
@@ -259,9 +262,9 @@ case $basic_machine in
 	| pyramid \
 	| sh | sh[1234] | sh[23]e | sh[34]eb | shbe | shle | sh[1234]le | sh3ele \
 	| sh64 | sh64le \
-	| sparc | sparc64 | sparc86x | sparclet | sparclite | sparcv9 | sparcv9b \
+	| sparc | sparc64 | sparc86x | sparclet | sparclite | sparcv8 | sparcv9 | sparcv9b \
 	| strongarm \
-	| tahoe | thumb | tic80 | tron \
+	| tahoe | thumb | tic4x | tic80 | tron \
 	| v850 | v850e \
 	| we32k \
 	| x86 | xscale | xstormy16 | xtensa \
@@ -297,15 +300,15 @@ case $basic_machine in
 	| avr-* \
 	| bs2000-* \
 	| c[123]* | c30-* | [cjt]90-* | c4x-* | c54x-* | c55x-* | c6x-* \
-	| clipper-* | cydra-* \
+	| clipper-* | craynv-* | cydra-* \
 	| d10v-* | d30v-* | dlx-* \
 	| elxsi-* \
 	| f30[01]-* | f700-* | fr30-* | frv-* | fx80-* \
 	| h8300-* | h8500-* \
 	| hppa-* | hppa1.[01]-* | hppa2.0-* | hppa2.0[nw]-* | hppa64-* \
 	| i*86-* | i860-* | i960-* | ia64-* \
-	| ip2k-* \
-	| m32r-* \
+	| ip2k-* | iq2000-* \
+	| m32r-* | m32rle-* \
 	| m68000-* | m680[012346]0-* | m68360-* | m683?2-* | m68k-* \
 	| m88110-* | m88k-* | mcore-* \
 	| mips-* | mipsbe-* | mipseb-* | mipsel-* | mipsle-* \
@@ -319,11 +322,13 @@ case $basic_machine in
 	| mipsisa32-* | mipsisa32el-* \
 	| mipsisa32r2-* | mipsisa32r2el-* \
 	| mipsisa64-* | mipsisa64el-* \
+	| mipsisa64r2-* | mipsisa64r2el-* \
 	| mipsisa64sb1-* | mipsisa64sb1el-* \
 	| mipsisa64sr71k-* | mipsisa64sr71kel-* \
 	| mipstx39-* | mipstx39el-* \
+	| mmix-* \
 	| msp430-* \
-	| none-* | np1-* | nv1-* | ns16k-* | ns32k-* \
+	| none-* | np1-* | ns16k-* | ns32k-* \
 	| orion-* \
 	| pdp10-* | pdp11-* | pj-* | pjl-* | pn-* | power-* \
 	| powerpc-* | powerpc64-* | powerpc64le-* | powerpcle-* | ppcbe-* \
@@ -332,7 +337,7 @@ case $basic_machine in
 	| sh-* | sh[1234]-* | sh[23]e-* | sh[34]eb-* | shbe-* \
 	| shle-* | sh[1234]le-* | sh3ele-* | sh64-* | sh64le-* \
 	| sparc-* | sparc64-* | sparc86x-* | sparclet-* | sparclite-* \
-	| sparcv9-* | sparcv9b-* | strongarm-* | sv1-* | sx?-* \
+	| sparcv8-* | sparcv9-* | sparcv9b-* | strongarm-* | sv1-* | sx?-* \
 	| tahoe-* | thumb-* \
 	| tic30-* | tic4x-* | tic54x-* | tic55x-* | tic6x-* | tic80-* \
 	| tron-* \
@@ -359,6 +364,9 @@ case $basic_machine in
 		basic_machine=a29k-amd
 		os=-udi
 		;;
+    	abacus)
+		basic_machine=abacus-unknown
+		;;
 	adobe68k)
 		basic_machine=m68010-adobe
 		os=-scout
@@ -373,6 +381,12 @@ case $basic_machine in
 		basic_machine=a29k-none
 		os=-bsd
 		;;
+	amd64)
+		basic_machine=x86_64-pc
+		;;
+	amd64-*)
+		basic_machine=x86_64-`echo $basic_machine | sed 's/^[^-]*-//'`
+		;;
 	amdahl)
 		basic_machine=580-amdahl
 		os=-sysv
@@ -432,12 +446,27 @@ case $basic_machine in
 		basic_machine=j90-cray
 		os=-unicos
 		;;
+	craynv)
+		basic_machine=craynv-cray
+		os=-unicosmp
+		;;
+	cr16c)
+		basic_machine=cr16c-unknown
+		os=-elf
+		;;
 	crds | unos)
 		basic_machine=m68k-crds
 		;;
+	crisv32 | crisv32-* | etraxfs*)
+		basic_machine=crisv32-axis
+		;;
 	cris | cris-* | etrax*)
 		basic_machine=cris-axis
 		;;
+	crx)
+		basic_machine=crx-unknown
+		os=-elf
+		;;
 	da30 | da30-*)
 		basic_machine=m68k-da30
 		;;
@@ -638,10 +667,6 @@ case $basic_machine in
 	mips3*)
 		basic_machine=`echo $basic_machine | sed -e 's/mips3/mips64/'`-unknown
 		;;
-	mmix*)
-		basic_machine=mmix-knuth
-		os=-mmixware
-		;;
 	monitor)
 		basic_machine=m68k-rom68k
 		os=-coff
@@ -722,10 +747,6 @@ case $basic_machine in
 	np1)
 		basic_machine=np1-gould
 		;;
-	nv1)
-		basic_machine=nv1-cray
-		os=-unicosmp
-		;;
 	nsr-tandem)
 		basic_machine=nsr-tandem
 		;;
@@ -737,6 +758,10 @@ case $basic_machine in
 		basic_machine=or32-unknown
 		os=-coff
 		;;
+	os400)
+		basic_machine=powerpc-ibm
+		os=-os400
+		;;
 	OSE68000 | ose68000)
 		basic_machine=m68000-ericsson
 		os=-ose
@@ -768,18 +793,24 @@ case $basic_machine in
 	pentiumpro | p6 | 6x86 | athlon | athlon_*)
 		basic_machine=i686-pc
 		;;
-	pentiumii | pentium2)
+	pentiumii | pentium2 | pentiumiii | pentium3)
 		basic_machine=i686-pc
 		;;
+	pentium4)
+		basic_machine=i786-pc
+		;;
 	pentium-* | p5-* | k5-* | k6-* | nexgen-* | viac3-*)
 		basic_machine=i586-`echo $basic_machine | sed 's/^[^-]*-//'`
 		;;
 	pentiumpro-* | p6-* | 6x86-* | athlon-*)
 		basic_machine=i686-`echo $basic_machine | sed 's/^[^-]*-//'`
 		;;
-	pentiumii-* | pentium2-*)
+	pentiumii-* | pentium2-* | pentiumiii-* | pentium3-*)
 		basic_machine=i686-`echo $basic_machine | sed 's/^[^-]*-//'`
 		;;
+	pentium4-*)
+		basic_machine=i786-`echo $basic_machine | sed 's/^[^-]*-//'`
+		;;
 	pn)
 		basic_machine=pn-gould
 		;;
@@ -838,6 +869,10 @@ case $basic_machine in
 	sb1el)
 		basic_machine=mipsisa64sb1el-unknown
 		;;
+	sei)
+		basic_machine=mips-sei
+		os=-seiux
+		;;
 	sequent)
 		basic_machine=i386-sequent
 		;;
@@ -845,6 +880,9 @@ case $basic_machine in
 		basic_machine=sh-hitachi
 		os=-hms
 		;;
+	sh64)
+		basic_machine=sh64-unknown
+		;;
 	sparclite-wrs | simso-wrs)
 		basic_machine=sparclite-wrs
 		os=-vxworks
@@ -919,10 +957,6 @@ case $basic_machine in
 		basic_machine=t90-cray
 		os=-unicos
 		;;
-        tic4x | c4x*)
-		basic_machine=tic4x-unknown
-		os=-coff
-		;;
 	tic54x | c54x*)
 		basic_machine=tic54x-unknown
 		os=-coff
@@ -948,6 +982,10 @@ case $basic_machine in
 	tower | tower-32)
 		basic_machine=m68k-ncr
 		;;
+	tpf)
+		basic_machine=s390x-ibm
+		os=-tpf
+		;;
 	udi29k)
 		basic_machine=a29k-amd
 		os=-udi
@@ -1021,6 +1059,9 @@ case $basic_machine in
 	romp)
 		basic_machine=romp-ibm
 		;;
+	mmix)
+		basic_machine=mmix-knuth
+		;;
 	rs6000)
 		basic_machine=rs6000-ibm
 		;;
@@ -1043,7 +1084,7 @@ case $basic_machine in
 	sh64)
 		basic_machine=sh64-unknown
 		;;
-	sparc | sparcv9 | sparcv9b)
+	sparc | sparcv8 | sparcv9 | sparcv9b)
 		basic_machine=sparc-sun
 		;;
 	cydra)
@@ -1116,19 +1157,20 @@ case $os in
 	      | -aos* \
 	      | -nindy* | -vxsim* | -vxworks* | -ebmon* | -hms* | -mvs* \
 	      | -clix* | -riscos* | -uniplus* | -iris* | -rtu* | -xenix* \
-	      | -hiux* | -386bsd* | -netbsd* | -openbsd* | -freebsd* | -riscix* \
-	      | -lynxos* | -bosx* | -nextstep* | -cxux* | -aout* | -elf* | -oabi* \
+	      | -hiux* | -386bsd* | -knetbsd* | -mirbsd* | -netbsd* | -openbsd* \
+	      | -ekkobsd* | -kfreebsd* | -freebsd* | -riscix* | -lynxos* \
+	      | -bosx* | -nextstep* | -cxux* | -aout* | -elf* | -oabi* \
 	      | -ptx* | -coff* | -ecoff* | -winnt* | -domain* | -vsta* \
 	      | -udi* | -eabi* | -lites* | -ieee* | -go32* | -aux* \
 	      | -chorusos* | -chorusrdb* \
 	      | -cygwin* | -pe* | -psos* | -moss* | -proelf* | -rtems* \
-	      | -mingw32* | -linux-gnu* | -uxpv* | -beos* | -mpeix* | -udk* \
+	      | -mingw32* | -linux-gnu* | -linux-uclibc* | -uxpv* | -beos* | -mpeix* | -udk* \
 	      | -interix* | -uwin* | -mks* | -rhapsody* | -darwin* | -opened* \
 	      | -openstep* | -oskit* | -conix* | -pw32* | -nonstopux* \
 	      | -storm-chaos* | -tops10* | -tenex* | -tops20* | -its* \
 	      | -os2* | -vos* | -palmos* | -uclinux* | -nucleus* \
 	      | -morphos* | -superux* | -rtmk* | -rtmk-nova* | -windiss* \
-	      | -powermax* | -dnix*)
+	      | -powermax* | -dnix* | -nx6 | -nx7 | -sei* | -dragonfly*)
 	# Remember, each alternative MUST END IN *, to match a version number.
 		;;
 	-qnx*)
@@ -1152,6 +1194,9 @@ case $os in
 	-mac*)
 		os=`echo $os | sed -e 's|mac|macos|'`
 		;;
+	-linux-dietlibc)
+		os=-linux-dietlibc
+		;;
 	-linux*)
 		os=`echo $os | sed -e 's|linux|linux-gnu|'`
 		;;
@@ -1164,6 +1209,9 @@ case $os in
 	-opened*)
 		os=-openedition
 		;;
+        -os400*)
+		os=-os400
+		;;
 	-wince*)
 		os=-wince
 		;;
@@ -1185,6 +1233,9 @@ case $os in
 	-atheos*)
 		os=-atheos
 		;;
+	-syllable*)
+		os=-syllable
+		;;
 	-386bsd)
 		os=-bsd
 		;;
@@ -1207,6 +1258,9 @@ case $os in
 	-sinix*)
 		os=-sysv4
 		;;
+        -tpf*)
+		os=-tpf
+		;;
 	-triton*)
 		os=-sysv3
 		;;
@@ -1274,6 +1328,9 @@ case $basic_machine in
 	arm*-semi)
 		os=-aout
 		;;
+    c4x-* | tic4x-*)
+        os=-coff
+        ;;
 	# This must come before the *-dec entry.
 	pdp10-*)
 		os=-tops20
@@ -1320,6 +1377,9 @@ case $basic_machine in
 	*-ibm)
 		os=-aix
 		;;
+    	*-knuth)
+		os=-mmixware
+		;;
 	*-wec)
 		os=-proelf
 		;;
@@ -1452,9 +1512,15 @@ case $basic_machine in
 			-mvs* | -opened*)
 				vendor=ibm
 				;;
+			-os400*)
+				vendor=ibm
+				;;
 			-ptx*)
 				vendor=sequent
 				;;
+			-tpf*)
+				vendor=ibm
+				;;
 			-vxsim* | -vxworks* | -windiss*)
 				vendor=wrs
 				;;

llvm/autoconf/depcomp

@@ -0,0 +1,522 @@
+#! /bin/sh
+# depcomp - compile a program generating dependencies as side-effects
+
+scriptversion=2004-05-31.23
+
+# Copyright (C) 1999, 2000, 2003, 2004 Free Software Foundation, Inc.
+
+# 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, 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.
+
+# Originally written by Alexandre Oliva <oliva@dcc.unicamp.br>.
+
+case $1 in
+  '')
+     echo "$0: No command.  Try \`$0 --help' for more information." 1>&2
+     exit 1;
+     ;;
+  -h | --h*)
+    cat <<\EOF
+Usage: depcomp [--help] [--version] PROGRAM [ARGS]
+
+Run PROGRAMS ARGS to compile a file, generating dependencies
+as side-effects.
+
+Environment variables:
+  depmode     Dependency tracking mode.
+  source      Source file read by `PROGRAMS ARGS'.
+  object      Object file output by `PROGRAMS ARGS'.
+  DEPDIR      directory where to store dependencies.
+  depfile     Dependency file to output.
+  tmpdepfile  Temporary file to use when outputing dependencies.
+  libtool     Whether libtool is used (yes/no).
+
+Report bugs to <bug-automake@gnu.org>.
+EOF
+    exit 0
+    ;;
+  -v | --v*)
+    echo "depcomp $scriptversion"
+    exit 0
+    ;;
+esac
+
+if test -z "$depmode" || test -z "$source" || test -z "$object"; then
+  echo "depcomp: Variables source, object and depmode must be set" 1>&2
+  exit 1
+fi
+
+# Dependencies for sub/bar.o or sub/bar.obj go into sub/.deps/bar.Po.
+depfile=${depfile-`echo "$object" |
+  sed 's|[^\\/]*$|'${DEPDIR-.deps}'/&|;s|\.\([^.]*\)$|.P\1|;s|Pobj$|Po|'`}
+tmpdepfile=${tmpdepfile-`echo "$depfile" | sed 's/\.\([^.]*\)$/.T\1/'`}
+
+rm -f "$tmpdepfile"
+
+# Some modes work just like other modes, but use different flags.  We
+# parameterize here, but still list the modes in the big case below,
+# to make depend.m4 easier to write.  Note that we *cannot* use a case
+# here, because this file can only contain one case statement.
+if test "$depmode" = hp; then
+  # HP compiler uses -M and no extra arg.
+  gccflag=-M
+  depmode=gcc
+fi
+
+if test "$depmode" = dashXmstdout; then
+   # This is just like dashmstdout with a different argument.
+   dashmflag=-xM
+   depmode=dashmstdout
+fi
+
+case "$depmode" in
+gcc3)
+## gcc 3 implements dependency tracking that does exactly what
+## we want.  Yay!  Note: for some reason libtool 1.4 doesn't like
+## it if -MD -MP comes after the -MF stuff.  Hmm.
+  "$@" -MT "$object" -MD -MP -MF "$tmpdepfile"
+  stat=$?
+  if test $stat -eq 0; then :
+  else
+    rm -f "$tmpdepfile"
+    exit $stat
+  fi
+  mv "$tmpdepfile" "$depfile"
+  ;;
+
+gcc)
+## There are various ways to get dependency output from gcc.  Here's
+## why we pick this rather obscure method:
+## - Don't want to use -MD because we'd like the dependencies to end
+##   up in a subdir.  Having to rename by hand is ugly.
+##   (We might end up doing this anyway to support other compilers.)
+## - The DEPENDENCIES_OUTPUT environment variable makes gcc act like
+##   -MM, not -M (despite what the docs say).
+## - Using -M directly means running the compiler twice (even worse
+##   than renaming).
+  if test -z "$gccflag"; then
+    gccflag=-MD,
+  fi
+  "$@" -Wp,"$gccflag$tmpdepfile"
+  stat=$?
+  if test $stat -eq 0; then :
+  else
+    rm -f "$tmpdepfile"
+    exit $stat
+  fi
+  rm -f "$depfile"
+  echo "$object : \\" > "$depfile"
+  alpha=ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
+## The second -e expression handles DOS-style file names with drive letters.
+  sed -e 's/^[^:]*: / /' \
+      -e 's/^['$alpha']:\/[^:]*: / /' < "$tmpdepfile" >> "$depfile"
+## This next piece of magic avoids the `deleted header file' problem.
+## The problem is that when a header file which appears in a .P file
+## is deleted, the dependency causes make to die (because there is
+## typically no way to rebuild the header).  We avoid this by adding
+## dummy dependencies for each header file.  Too bad gcc doesn't do
+## this for us directly.
+  tr ' ' '
+' < "$tmpdepfile" |
+## Some versions of gcc put a space before the `:'.  On the theory
+## that the space means something, we add a space to the output as
+## well.
+## Some versions of the HPUX 10.20 sed can't process this invocation
+## correctly.  Breaking it into two sed invocations is a workaround.
+    sed -e 's/^\\$//' -e '/^$/d' -e '/:$/d' | sed -e 's/$/ :/' >> "$depfile"
+  rm -f "$tmpdepfile"
+  ;;
+
+hp)
+  # This case exists only to let depend.m4 do its work.  It works by
+  # looking at the text of this script.  This case will never be run,
+  # since it is checked for above.
+  exit 1
+  ;;
+
+sgi)
+  if test "$libtool" = yes; then
+    "$@" "-Wp,-MDupdate,$tmpdepfile"
+  else
+    "$@" -MDupdate "$tmpdepfile"
+  fi
+  stat=$?
+  if test $stat -eq 0; then :
+  else
+    rm -f "$tmpdepfile"
+    exit $stat
+  fi
+  rm -f "$depfile"
+
+  if test -f "$tmpdepfile"; then  # yes, the sourcefile depend on other files
+    echo "$object : \\" > "$depfile"
+
+    # Clip off the initial element (the dependent).  Don't try to be
+    # clever and replace this with sed code, as IRIX sed won't handle
+    # lines with more than a fixed number of characters (4096 in
+    # IRIX 6.2 sed, 8192 in IRIX 6.5).  We also remove comment lines;
+    # the IRIX cc adds comments like `#:fec' to the end of the
+    # dependency line.
+    tr ' ' '
+' < "$tmpdepfile" \
+    | sed -e 's/^.*\.o://' -e 's/#.*$//' -e '/^$/ d' | \
+    tr '
+' ' ' >> $depfile
+    echo >> $depfile
+
+    # The second pass generates a dummy entry for each header file.
+    tr ' ' '
+' < "$tmpdepfile" \
+   | sed -e 's/^.*\.o://' -e 's/#.*$//' -e '/^$/ d' -e 's/$/:/' \
+   >> $depfile
+  else
+    # The sourcefile does not contain any dependencies, so just
+    # store a dummy comment line, to avoid errors with the Makefile
+    # "include basename.Plo" scheme.
+    echo "#dummy" > "$depfile"
+  fi
+  rm -f "$tmpdepfile"
+  ;;
+
+aix)
+  # The C for AIX Compiler uses -M and outputs the dependencies
+  # in a .u file.  In older versions, this file always lives in the
+  # current directory.  Also, the AIX compiler puts `$object:' at the
+  # start of each line; $object doesn't have directory information.
+  # Version 6 uses the directory in both cases.
+  stripped=`echo "$object" | sed 's/\(.*\)\..*$/\1/'`
+  tmpdepfile="$stripped.u"
+  if test "$libtool" = yes; then
+    "$@" -Wc,-M
+  else
+    "$@" -M
+  fi
+  stat=$?
+
+  if test -f "$tmpdepfile"; then :
+  else
+    stripped=`echo "$stripped" | sed 's,^.*/,,'`
+    tmpdepfile="$stripped.u"
+  fi
+
+  if test $stat -eq 0; then :
+  else
+    rm -f "$tmpdepfile"
+    exit $stat
+  fi
+
+  if test -f "$tmpdepfile"; then
+    outname="$stripped.o"
+    # Each line is of the form `foo.o: dependent.h'.
+    # Do two passes, one to just change these to
+    # `$object: dependent.h' and one to simply `dependent.h:'.
+    sed -e "s,^$outname:,$object :," < "$tmpdepfile" > "$depfile"
+    sed -e "s,^$outname: \(.*\)$,\1:," < "$tmpdepfile" >> "$depfile"
+  else
+    # The sourcefile does not contain any dependencies, so just
+    # store a dummy comment line, to avoid errors with the Makefile
+    # "include basename.Plo" scheme.
+    echo "#dummy" > "$depfile"
+  fi
+  rm -f "$tmpdepfile"
+  ;;
+
+icc)
+  # Intel's C compiler understands `-MD -MF file'.  However on
+  #    icc -MD -MF foo.d -c -o sub/foo.o sub/foo.c
+  # ICC 7.0 will fill foo.d with something like
+  #    foo.o: sub/foo.c
+  #    foo.o: sub/foo.h
+  # which is wrong.  We want:
+  #    sub/foo.o: sub/foo.c
+  #    sub/foo.o: sub/foo.h
+  #    sub/foo.c:
+  #    sub/foo.h:
+  # ICC 7.1 will output
+  #    foo.o: sub/foo.c sub/foo.h
+  # and will wrap long lines using \ :
+  #    foo.o: sub/foo.c ... \
+  #     sub/foo.h ... \
+  #     ...
+
+  "$@" -MD -MF "$tmpdepfile"
+  stat=$?
+  if test $stat -eq 0; then :
+  else
+    rm -f "$tmpdepfile"
+    exit $stat
+  fi
+  rm -f "$depfile"
+  # Each line is of the form `foo.o: dependent.h',
+  # or `foo.o: dep1.h dep2.h \', or ` dep3.h dep4.h \'.
+  # Do two passes, one to just change these to
+  # `$object: dependent.h' and one to simply `dependent.h:'.
+  sed "s,^[^:]*:,$object :," < "$tmpdepfile" > "$depfile"
+  # Some versions of the HPUX 10.20 sed can't process this invocation
+  # correctly.  Breaking it into two sed invocations is a workaround.
+  sed 's,^[^:]*: \(.*\)$,\1,;s/^\\$//;/^$/d;/:$/d' < "$tmpdepfile" |
+    sed -e 's/$/ :/' >> "$depfile"
+  rm -f "$tmpdepfile"
+  ;;
+
+tru64)
+   # The Tru64 compiler uses -MD to generate dependencies as a side
+   # effect.  `cc -MD -o foo.o ...' puts the dependencies into `foo.o.d'.
+   # At least on Alpha/Redhat 6.1, Compaq CCC V6.2-504 seems to put
+   # dependencies in `foo.d' instead, so we check for that too.
+   # Subdirectories are respected.
+   dir=`echo "$object" | sed -e 's|/[^/]*$|/|'`
+   test "x$dir" = "x$object" && dir=
+   base=`echo "$object" | sed -e 's|^.*/||' -e 's/\.o$//' -e 's/\.lo$//'`
+
+   if test "$libtool" = yes; then
+      # Dependencies are output in .lo.d with libtool 1.4.
+      # With libtool 1.5 they are output both in $dir.libs/$base.o.d
+      # and in $dir.libs/$base.o.d and $dir$base.o.d.  We process the
+      # latter, because the former will be cleaned when $dir.libs is
+      # erased.
+      tmpdepfile1="$dir.libs/$base.lo.d"
+      tmpdepfile2="$dir$base.o.d"
+      tmpdepfile3="$dir.libs/$base.d"
+      "$@" -Wc,-MD
+   else
+      tmpdepfile1="$dir$base.o.d"
+      tmpdepfile2="$dir$base.d"
+      tmpdepfile3="$dir$base.d"
+      "$@" -MD
+   fi
+
+   stat=$?
+   if test $stat -eq 0; then :
+   else
+      rm -f "$tmpdepfile1" "$tmpdepfile2" "$tmpdepfile3"
+      exit $stat
+   fi
+
+   if test -f "$tmpdepfile1"; then
+      tmpdepfile="$tmpdepfile1"
+   elif test -f "$tmpdepfile2"; then
+      tmpdepfile="$tmpdepfile2"
+   else
+      tmpdepfile="$tmpdepfile3"
+   fi
+   if test -f "$tmpdepfile"; then
+      sed -e "s,^.*\.[a-z]*:,$object:," < "$tmpdepfile" > "$depfile"
+      # That's a tab and a space in the [].
+      sed -e 's,^.*\.[a-z]*:[	 ]*,,' -e 's,$,:,' < "$tmpdepfile" >> "$depfile"
+   else
+      echo "#dummy" > "$depfile"
+   fi
+   rm -f "$tmpdepfile"
+   ;;
+
+#nosideeffect)
+  # This comment above is used by automake to tell side-effect
+  # dependency tracking mechanisms from slower ones.
+
+dashmstdout)
+  # Important note: in order to support this mode, a compiler *must*
+  # always write the preprocessed file to stdout, regardless of -o.
+  "$@" || exit $?
+
+  # Remove the call to Libtool.
+  if test "$libtool" = yes; then
+    while test $1 != '--mode=compile'; do
+      shift
+    done
+    shift
+  fi
+
+  # Remove `-o $object'.
+  IFS=" "
+  for arg
+  do
+    case $arg in
+    -o)
+      shift
+      ;;
+    $object)
+      shift
+      ;;
+    *)
+      set fnord "$@" "$arg"
+      shift # fnord
+      shift # $arg
+      ;;
+    esac
+  done
+
+  test -z "$dashmflag" && dashmflag=-M
+  # Require at least two characters before searching for `:'
+  # in the target name.  This is to cope with DOS-style filenames:
+  # a dependency such as `c:/foo/bar' could be seen as target `c' otherwise.
+  "$@" $dashmflag |
+    sed 's:^[  ]*[^: ][^:][^:]*\:[    ]*:'"$object"'\: :' > "$tmpdepfile"
+  rm -f "$depfile"
+  cat < "$tmpdepfile" > "$depfile"
+  tr ' ' '
+' < "$tmpdepfile" | \
+## Some versions of the HPUX 10.20 sed can't process this invocation
+## correctly.  Breaking it into two sed invocations is a workaround.
+    sed -e 's/^\\$//' -e '/^$/d' -e '/:$/d' | sed -e 's/$/ :/' >> "$depfile"
+  rm -f "$tmpdepfile"
+  ;;
+
+dashXmstdout)
+  # This case only exists to satisfy depend.m4.  It is never actually
+  # run, as this mode is specially recognized in the preamble.
+  exit 1
+  ;;
+
+makedepend)
+  "$@" || exit $?
+  # Remove any Libtool call
+  if test "$libtool" = yes; then
+    while test $1 != '--mode=compile'; do
+      shift
+    done
+    shift
+  fi
+  # X makedepend
+  shift
+  cleared=no
+  for arg in "$@"; do
+    case $cleared in
+    no)
+      set ""; shift
+      cleared=yes ;;
+    esac
+    case "$arg" in
+    -D*|-I*)
+      set fnord "$@" "$arg"; shift ;;
+    # Strip any option that makedepend may not understand.  Remove
+    # the object too, otherwise makedepend will parse it as a source file.
+    -*|$object)
+      ;;
+    *)
+      set fnord "$@" "$arg"; shift ;;
+    esac
+  done
+  obj_suffix="`echo $object | sed 's/^.*\././'`"
+  touch "$tmpdepfile"
+  ${MAKEDEPEND-makedepend} -o"$obj_suffix" -f"$tmpdepfile" "$@"
+  rm -f "$depfile"
+  cat < "$tmpdepfile" > "$depfile"
+  sed '1,2d' "$tmpdepfile" | tr ' ' '
+' | \
+## Some versions of the HPUX 10.20 sed can't process this invocation
+## correctly.  Breaking it into two sed invocations is a workaround.
+    sed -e 's/^\\$//' -e '/^$/d' -e '/:$/d' | sed -e 's/$/ :/' >> "$depfile"
+  rm -f "$tmpdepfile" "$tmpdepfile".bak
+  ;;
+
+cpp)
+  # Important note: in order to support this mode, a compiler *must*
+  # always write the preprocessed file to stdout.
+  "$@" || exit $?
+
+  # Remove the call to Libtool.
+  if test "$libtool" = yes; then
+    while test $1 != '--mode=compile'; do
+      shift
+    done
+    shift
+  fi
+
+  # Remove `-o $object'.
+  IFS=" "
+  for arg
+  do
+    case $arg in
+    -o)
+      shift
+      ;;
+    $object)
+      shift
+      ;;
+    *)
+      set fnord "$@" "$arg"
+      shift # fnord
+      shift # $arg
+      ;;
+    esac
+  done
+
+  "$@" -E |
+    sed -n '/^# [0-9][0-9]* "\([^"]*\)".*/ s:: \1 \\:p' |
+    sed '$ s: \\$::' > "$tmpdepfile"
+  rm -f "$depfile"
+  echo "$object : \\" > "$depfile"
+  cat < "$tmpdepfile" >> "$depfile"
+  sed < "$tmpdepfile" '/^$/d;s/^ //;s/ \\$//;s/$/ :/' >> "$depfile"
+  rm -f "$tmpdepfile"
+  ;;
+
+msvisualcpp)
+  # Important note: in order to support this mode, a compiler *must*
+  # always write the preprocessed file to stdout, regardless of -o,
+  # because we must use -o when running libtool.
+  "$@" || exit $?
+  IFS=" "
+  for arg
+  do
+    case "$arg" in
+    "-Gm"|"/Gm"|"-Gi"|"/Gi"|"-ZI"|"/ZI")
+	set fnord "$@"
+	shift
+	shift
+	;;
+    *)
+	set fnord "$@" "$arg"
+	shift
+	shift
+	;;
+    esac
+  done
+  "$@" -E |
+  sed -n '/^#line [0-9][0-9]* "\([^"]*\)"/ s::echo "`cygpath -u \\"\1\\"`":p' | sort | uniq > "$tmpdepfile"
+  rm -f "$depfile"
+  echo "$object : \\" > "$depfile"
+  . "$tmpdepfile" | sed 's% %\\ %g' | sed -n '/^\(.*\)$/ s::	\1 \\:p' >> "$depfile"
+  echo "	" >> "$depfile"
+  . "$tmpdepfile" | sed 's% %\\ %g' | sed -n '/^\(.*\)$/ s::\1\::p' >> "$depfile"
+  rm -f "$tmpdepfile"
+  ;;
+
+none)
+  exec "$@"
+  ;;
+
+*)
+  echo "Unknown depmode $depmode" 1>&2
+  exit 1
+  ;;
+esac
+
+exit 0
+
+# Local Variables:
+# mode: shell-script
+# sh-indentation: 2
+# eval: (add-hook 'write-file-hooks 'time-stamp)
+# time-stamp-start: "scriptversion="
+# time-stamp-format: "%:y-%02m-%02d.%02H"
+# time-stamp-end: "$"
+# End:

llvm/autoconf/install-sh

@@ -1,19 +1,38 @@
 #!/bin/sh
-#
 # install - install a program, script, or datafile
-# This comes from X11R5 (mit/util/scripts/install.sh).
+
+scriptversion=2004-09-10.20
+
+# This originates from X11R5 (mit/util/scripts/install.sh), which was
+# later released in X11R6 (xc/config/util/install.sh) with the
+# following copyright and license.
 #
-# Copyright 1991 by the Massachusetts Institute of Technology
+# Copyright (C) 1994 X Consortium
 #
-# 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, and that the name of M.I.T. not be used in advertising or
-# publicity pertaining to distribution of the software without specific,
-# written prior permission.  M.I.T. makes no representations about the
-# suitability of this software for any purpose.  It is provided "as is"
-# without express or implied warranty.
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to
+# deal in the Software without restriction, including without limitation the
+# rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+# sell copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+#
+# 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
+# X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
+# AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNEC-
+# TION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+#
+# Except as contained in this notice, the name of the X Consortium shall not
+# be used in advertising or otherwise to promote the sale, use or other deal-
+# ings in this Software without prior written authorization from the X Consor-
+# tium.
+#
+#
+# FSF changes to this file are in the public domain.
 #
 # Calling this script install-sh is preferred over install.sh, to prevent
 # `make' implicit rules from creating a file called install from it
@@ -23,13 +42,11 @@
 # from scratch.  It can only install one file at a time, a restriction
 # shared with many OS's install programs.
 
-
 # set DOITPROG to echo to test this script
 
 # Don't use :- since 4.3BSD and earlier shells don't like it.
 doit="${DOITPROG-}"
 
-
 # put in absolute paths if you don't have them in your path; or use env. vars.
 
 mvprog="${MVPROG-mv}"
@@ -41,211 +58,265 @@ stripprog="${STRIPPROG-strip}"
 rmprog="${RMPROG-rm}"
 mkdirprog="${MKDIRPROG-mkdir}"
 
-transformbasename=""
-transform_arg=""
-instcmd="$mvprog"
 chmodcmd="$chmodprog 0755"
-chowncmd=""
-chgrpcmd=""
-stripcmd=""
+chowncmd=
+chgrpcmd=
+stripcmd=
 rmcmd="$rmprog -f"
 mvcmd="$mvprog"
-src=""
-dst=""
-dir_arg=""
+src=
+dst=
+dir_arg=
+dstarg=
+no_target_directory=
 
-while [ x"$1" != x ]; do
-    case $1 in
-	-c) instcmd="$cpprog"
-	    shift
-	    continue;;
+usage="Usage: $0 [OPTION]... [-T] SRCFILE DSTFILE
+   or: $0 [OPTION]... SRCFILES... DIRECTORY
+   or: $0 [OPTION]... -t DIRECTORY SRCFILES...
+   or: $0 [OPTION]... -d DIRECTORIES...
 
-	-d) dir_arg=true
-	    shift
-	    continue;;
+In the 1st form, copy SRCFILE to DSTFILE.
+In the 2nd and 3rd, copy all SRCFILES to DIRECTORY.
+In the 4th, create DIRECTORIES.
 
-	-m) chmodcmd="$chmodprog $2"
-	    shift
-	    shift
-	    continue;;
+Options:
+-c         (ignored)
+-d         create directories instead of installing files.
+-g GROUP   $chgrpprog installed files to GROUP.
+-m MODE    $chmodprog installed files to MODE.
+-o USER    $chownprog installed files to USER.
+-s         $stripprog installed files.
+-t DIRECTORY  install into DIRECTORY.
+-T         report an error if DSTFILE is a directory.
+--help     display this help and exit.
+--version  display version info and exit.
 
-	-o) chowncmd="$chownprog $2"
-	    shift
-	    shift
-	    continue;;
+Environment variables override the default commands:
+  CHGRPPROG CHMODPROG CHOWNPROG CPPROG MKDIRPROG MVPROG RMPROG STRIPPROG
+"
 
-	-g) chgrpcmd="$chgrpprog $2"
-	    shift
-	    shift
-	    continue;;
+while test -n "$1"; do
+  case $1 in
+    -c) shift
+        continue;;
 
-	-s) stripcmd="$stripprog"
-	    shift
-	    continue;;
+    -d) dir_arg=true
+        shift
+        continue;;
 
-	-t=*) transformarg=`echo $1 | sed 's/-t=//'`
-	    shift
-	    continue;;
+    -g) chgrpcmd="$chgrpprog $2"
+        shift
+        shift
+        continue;;
 
-	-b=*) transformbasename=`echo $1 | sed 's/-b=//'`
-	    shift
-	    continue;;
+    --help) echo "$usage"; exit 0;;
 
-	*)  if [ x"$src" = x ]
-	    then
-		src=$1
-	    else
-		# this colon is to work around a 386BSD /bin/sh bug
-		:
-		dst=$1
-	    fi
-	    shift
-	    continue;;
-    esac
-done
+    -m) chmodcmd="$chmodprog $2"
+        shift
+        shift
+        continue;;
 
-if [ x"$src" = x ]
-then
-	echo "install:	no input file specified"
-	exit 1
-else
-	:
-fi
+    -o) chowncmd="$chownprog $2"
+        shift
+        shift
+        continue;;
 
-if [ x"$dir_arg" != x ]; then
-	dst=$src
-	src=""
-	
-	if [ -d $dst ]; then
-		instcmd=:
-		chmodcmd=""
-	else
-		instcmd=$mkdirprog
-	fi
-else
+    -s) stripcmd=$stripprog
+        shift
+        continue;;
 
-# Waiting for this to be detected by the "$instcmd $src $dsttmp" command
-# might cause directories to be created, which would be especially bad 
-# if $src (and thus $dsttmp) contains '*'.
-
-	if [ -f $src -o -d $src ]
-	then
-		:
-	else
-		echo "install:  $src does not exist"
-		exit 1
-	fi
-	
-	if [ x"$dst" = x ]
-	then
-		echo "install:	no destination specified"
-		exit 1
-	else
-		:
-	fi
-
-# If destination is a directory, append the input filename; if your system
-# does not like double slashes in filenames, you may need to add some logic
-
-	if [ -d $dst ]
-	then
-		dst="$dst"/`basename $src`
-	else
-		:
-	fi
-fi
-
-## this sed command emulates the dirname command
-dstdir=`echo $dst | sed -e 's,[^/]*$,,;s,/$,,;s,^$,.,'`
-
-# Make sure that the destination directory exists.
-#  this part is taken from Noah Friedman's mkinstalldirs script
-
-# Skip lots of stat calls in the usual case.
-if [ ! -d "$dstdir" ]; then
-defaultIFS='
-	'
-IFS="${IFS-${defaultIFS}}"
-
-oIFS="${IFS}"
-# Some sh's can't handle IFS=/ for some reason.
-IFS='%'
-set - `echo ${dstdir} | sed -e 's@/@%@g' -e 's@^%@/@'`
-IFS="${oIFS}"
-
-pathcomp=''
-
-while [ $# -ne 0 ] ; do
-	pathcomp="${pathcomp}${1}"
+    -t) dstarg=$2
 	shift
+	shift
+	continue;;
 
-	if [ ! -d "${pathcomp}" ] ;
-        then
-		$mkdirprog "${pathcomp}"
-	else
-		:
-	fi
+    -T) no_target_directory=true
+	shift
+	continue;;
 
-	pathcomp="${pathcomp}/"
+    --version) echo "$0 $scriptversion"; exit 0;;
+
+    *)  # When -d is used, all remaining arguments are directories to create.
+	# When -t is used, the destination is already specified.
+	test -n "$dir_arg$dstarg" && break
+        # Otherwise, the last argument is the destination.  Remove it from $@.
+	for arg
+	do
+          if test -n "$dstarg"; then
+	    # $@ is not empty: it contains at least $arg.
+	    set fnord "$@" "$dstarg"
+	    shift # fnord
+	  fi
+	  shift # arg
+	  dstarg=$arg
+	done
+	break;;
+  esac
 done
+
+if test -z "$1"; then
+  if test -z "$dir_arg"; then
+    echo "$0: no input file specified." >&2
+    exit 1
+  fi
+  # It's OK to call `install-sh -d' without argument.
+  # This can happen when creating conditional directories.
+  exit 0
 fi
 
-if [ x"$dir_arg" != x ]
-then
-	$doit $instcmd $dst &&
+for src
+do
+  # Protect names starting with `-'.
+  case $src in
+    -*) src=./$src ;;
+  esac
 
-	if [ x"$chowncmd" != x ]; then $doit $chowncmd $dst; else : ; fi &&
-	if [ x"$chgrpcmd" != x ]; then $doit $chgrpcmd $dst; else : ; fi &&
-	if [ x"$stripcmd" != x ]; then $doit $stripcmd $dst; else : ; fi &&
-	if [ x"$chmodcmd" != x ]; then $doit $chmodcmd $dst; else : ; fi
-else
+  if test -n "$dir_arg"; then
+    dst=$src
+    src=
 
-# If we're going to rename the final executable, determine the name now.
+    if test -d "$dst"; then
+      mkdircmd=:
+      chmodcmd=
+    else
+      mkdircmd=$mkdirprog
+    fi
+  else
+    # Waiting for this to be detected by the "$cpprog $src $dsttmp" command
+    # might cause directories to be created, which would be especially bad
+    # if $src (and thus $dsttmp) contains '*'.
+    if test ! -f "$src" && test ! -d "$src"; then
+      echo "$0: $src does not exist." >&2
+      exit 1
+    fi
 
-	if [ x"$transformarg" = x ] 
-	then
-		dstfile=`basename $dst`
-	else
-		dstfile=`basename $dst $transformbasename | 
-			sed $transformarg`$transformbasename
-	fi
+    if test -z "$dstarg"; then
+      echo "$0: no destination specified." >&2
+      exit 1
+    fi
 
-# don't allow the sed command to completely eliminate the filename
+    dst=$dstarg
+    # Protect names starting with `-'.
+    case $dst in
+      -*) dst=./$dst ;;
+    esac
 
-	if [ x"$dstfile" = x ] 
-	then
-		dstfile=`basename $dst`
-	else
-		:
-	fi
+    # If destination is a directory, append the input filename; won't work
+    # if double slashes aren't ignored.
+    if test -d "$dst"; then
+      if test -n "$no_target_directory"; then
+	echo "$0: $dstarg: Is a directory" >&2
+	exit 1
+      fi
+      dst=$dst/`basename "$src"`
+    fi
+  fi
 
-# Make a temp file name in the proper directory.
+  # This sed command emulates the dirname command.
+  dstdir=`echo "$dst" | sed -e 's,[^/]*$,,;s,/$,,;s,^$,.,'`
 
-	dsttmp=$dstdir/#inst.$$#
+  # Make sure that the destination directory exists.
 
-# Move or copy the file name to the temp name
+  # Skip lots of stat calls in the usual case.
+  if test ! -d "$dstdir"; then
+    defaultIFS='
+	 '
+    IFS="${IFS-$defaultIFS}"
 
-	$doit $instcmd $src $dsttmp &&
+    oIFS=$IFS
+    # Some sh's can't handle IFS=/ for some reason.
+    IFS='%'
+    set - `echo "$dstdir" | sed -e 's@/@%@g' -e 's@^%@/@'`
+    IFS=$oIFS
 
-	trap "rm -f ${dsttmp}" 0 &&
+    pathcomp=
 
-# and set any options; do chmod last to preserve setuid bits
+    while test $# -ne 0 ; do
+      pathcomp=$pathcomp$1
+      shift
+      if test ! -d "$pathcomp"; then
+        $mkdirprog "$pathcomp"
+	# mkdir can fail with a `File exist' error in case several
+	# install-sh are creating the directory concurrently.  This
+	# is OK.
+	test -d "$pathcomp" || exit
+      fi
+      pathcomp=$pathcomp/
+    done
+  fi
 
-# If any of these fail, we abort the whole thing.  If we want to
-# ignore errors from any of these, just make sure not to ignore
-# errors from the above "$doit $instcmd $src $dsttmp" command.
+  if test -n "$dir_arg"; then
+    $doit $mkdircmd "$dst" \
+      && { test -z "$chowncmd" || $doit $chowncmd "$dst"; } \
+      && { test -z "$chgrpcmd" || $doit $chgrpcmd "$dst"; } \
+      && { test -z "$stripcmd" || $doit $stripcmd "$dst"; } \
+      && { test -z "$chmodcmd" || $doit $chmodcmd "$dst"; }
 
-	if [ x"$chowncmd" != x ]; then $doit $chowncmd $dsttmp; else :;fi &&
-	if [ x"$chgrpcmd" != x ]; then $doit $chgrpcmd $dsttmp; else :;fi &&
-	if [ x"$stripcmd" != x ]; then $doit $stripcmd $dsttmp; else :;fi &&
-	if [ x"$chmodcmd" != x ]; then $doit $chmodcmd $dsttmp; else :;fi &&
+  else
+    dstfile=`basename "$dst"`
 
-# Now rename the file to the real destination.
+    # Make a couple of temp file names in the proper directory.
+    dsttmp=$dstdir/_inst.$$_
+    rmtmp=$dstdir/_rm.$$_
 
-	$doit $rmcmd -f $dstdir/$dstfile &&
-	$doit $mvcmd $dsttmp $dstdir/$dstfile 
+    # Trap to clean up those temp files at exit.
+    trap 'ret=$?; rm -f "$dsttmp" "$rmtmp" && exit $ret' 0
+    trap '(exit $?); exit' 1 2 13 15
 
-fi &&
+    # Copy the file name to the temp name.
+    $doit $cpprog "$src" "$dsttmp" &&
 
+    # and set any options; do chmod last to preserve setuid bits.
+    #
+    # If any of these fail, we abort the whole thing.  If we want to
+    # ignore errors from any of these, just make sure not to ignore
+    # errors from the above "$doit $cpprog $src $dsttmp" command.
+    #
+    { test -z "$chowncmd" || $doit $chowncmd "$dsttmp"; } \
+      && { test -z "$chgrpcmd" || $doit $chgrpcmd "$dsttmp"; } \
+      && { test -z "$stripcmd" || $doit $stripcmd "$dsttmp"; } \
+      && { test -z "$chmodcmd" || $doit $chmodcmd "$dsttmp"; } &&
 
-exit 0
+    # Now rename the file to the real destination.
+    { $doit $mvcmd -f "$dsttmp" "$dstdir/$dstfile" 2>/dev/null \
+      || {
+	   # The rename failed, perhaps because mv can't rename something else
+	   # to itself, or perhaps because mv is so ancient that it does not
+	   # support -f.
+
+	   # Now remove or move aside any old file at destination location.
+	   # We try this two ways since rm can't unlink itself on some
+	   # systems and the destination file might be busy for other
+	   # reasons.  In this case, the final cleanup might fail but the new
+	   # file should still install successfully.
+	   {
+	     if test -f "$dstdir/$dstfile"; then
+	       $doit $rmcmd -f "$dstdir/$dstfile" 2>/dev/null \
+	       || $doit $mvcmd -f "$dstdir/$dstfile" "$rmtmp" 2>/dev/null \
+	       || {
+		 echo "$0: cannot unlink or rename $dstdir/$dstfile" >&2
+		 (exit 1); exit
+	       }
+	     else
+	       :
+	     fi
+	   } &&
+
+	   # Now rename the file to the real destination.
+	   $doit $mvcmd "$dsttmp" "$dstdir/$dstfile"
+	 }
+    }
+  fi || { (exit 1); exit; }
+done
+
+# The final little trick to "correctly" pass the exit status to the exit trap.
+{
+  (exit 0); exit
+}
+
+# Local variables:
+# eval: (add-hook 'write-file-hooks 'time-stamp)
+# time-stamp-start: "scriptversion="
+# time-stamp-format: "%:y-%02m-%02d.%02H"
+# time-stamp-end: "$"
+# End:

llvm/autoconf/m4/bison.m4

@@ -0,0 +1,14 @@
+#
+# Check for Bison. 
+#
+# This macro verifies that Bison is installed.  If successful, then
+# 1) YACC is set to bison -y (to emulate YACC calls)
+# 2) BISON is set to bison
+#
+AC_DEFUN([AC_PROG_BISON],
+[AC_CACHE_CHECK([],[llvm_cv_has_bison],[AC_PROG_YACC()])
+if test "$YACC" != "bison -y"; then
+  AC_MSG_ERROR([bison not found but required])
+else
+  AC_SUBST(BISON,[bison],[location of bison])
+fi])

llvm/autoconf/m4/c_printf_a.m4

@@ -0,0 +1,31 @@
+#
+# Determine if the printf() functions have the %a format character.
+# This is modified from:
+# http://www.gnu.org/software/ac-archive/htmldoc/ac_cxx_have_ext_slist.html
+AC_DEFUN([AC_C_PRINTF_A],
+[AC_CACHE_CHECK([if printf has the %a format character],[llvm_cv_c_printf_a],
+[AC_LANG_PUSH([C])
+ AC_RUN_IFELSE([
+  AC_LANG_PROGRAM([[
+#include <stdio.h>
+#include <stdlib.h>
+]],[[
+volatile double A, B;
+char Buffer[100];
+A = 1;
+A /= 10.0;
+sprintf(Buffer, "%a", A);
+B = atof(Buffer);
+if (A != B)
+  return (1);
+if (A != 0x1.999999999999ap-4)
+  return (1);
+return (0);]])],
+  llvm_cv_c_printf_a=yes,
+  llvmac_cv_c_printf_a=no,
+  llvmac_cv_c_printf_a=no)
+ AC_LANG_POP([C])])
+ if test "$llvm_cv_c_printf_a" = "yes"; then
+   AC_DEFINE([HAVE_PRINTF_A],[1],[Define to have the %a format string])
+ fi
+])

llvm/autoconf/m4/check_gnu_make.m4

@@ -0,0 +1,26 @@
+#
+# Check for GNU Make.  This is originally from
+# http://www.gnu.org/software/ac-archive/htmldoc/check_gnu_make.html
+#
+AC_DEFUN([AC_CHECK_GNU_MAKE],
+[AC_CACHE_CHECK([for GNU make],[llvm_cv_gnu_make_command],
+dnl Search all the common names for GNU make
+[llvm_cv_gnu_make_command=''
+ for a in "$MAKE" make gmake gnumake ; do
+  if test -z "$a" ; then continue ; fi ;
+  if  ( sh -c "$a --version" 2> /dev/null | grep GNU 2>&1 > /dev/null ) 
+  then
+   llvm_cv_gnu_make_command=$a ;
+   break;
+  fi
+ done])
+dnl If there was a GNU version, then set @ifGNUmake@ to the empty string, 
+dnl '#' otherwise
+ if test "x$llvm_cv_gnu_make_command" != "x"  ; then
+   ifGNUmake='' ;
+ else
+   ifGNUmake='#' ;
+   AC_MSG_RESULT("Not found");
+ fi
+ AC_SUBST(ifGNUmake)
+])

llvm/autoconf/m4/config_makefile.m4

@@ -0,0 +1,9 @@
+#
+# Configure a Makefile without clobbering it if it exists and is not out of
+# date.  This macro is unique to LLVM.
+#
+AC_DEFUN([AC_CONFIG_MAKEFILE],
+[AC_CONFIG_COMMANDS($1,
+  [${llvm_src}/autoconf/mkinstalldirs `dirname $1`
+   ${SHELL} ${llvm_src}/autoconf/install-sh -c ${srcdir}/$1 $1])
+])

llvm/autoconf/m4/config_project.m4

@@ -0,0 +1,14 @@
+#
+# Provide the arguments and other processing needed for an LLVM project
+#
+AC_DEFUN([LLVM_CONFIG_PROJECT],
+  [AC_ARG_WITH([llvmsrc],
+    AS_HELP_STRING([--with-llvmsrc],[Location of LLVM Source Code]),
+    [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=`cd ../..; pwd`])
+  AC_SUBST(LLVM_OBJ,$llvm_obj)
+  AC_CONFIG_COMMANDS([setup],,[llvm_src="${LLVM_SRC}"])
+])

llvm/autoconf/m4/cxx_bidi_iterator.m4

@@ -0,0 +1,22 @@
+#
+# Check for bidirectional iterator extension.  This is modified from
+# http://www.gnu.org/software/ac-archive/htmldoc/ac_cxx_have_ext_hash_set.html
+#
+AC_DEFUN([AC_CXX_HAVE_BI_ITERATOR],
+[AC_CACHE_CHECK(whether the compiler has the bidirectional iterator,
+ac_cv_cxx_have_bi_iterator,
+[AC_REQUIRE([AC_CXX_NAMESPACES])
+  AC_LANG_PUSH([C++])
+  AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <iterator>
+#ifdef HAVE_NAMESPACES
+using namespace std;
+#endif]], [[bidirectional_iterator<int,int> t; return 0;]])],[ac_cv_cxx_have_bi_iterator=yes],[ac_cv_cxx_have_bi_iterator=no])
+  AC_LANG_POP([C++])
+])
+if test "$ac_cv_cxx_have_bi_iterator" = yes
+then
+  AC_DEFINE(HAVE_BI_ITERATOR,1,[Have bi-directional iterator])
+else
+  AC_DEFINE(HAVE_BI_ITERATOR,0,[Does not have bi-directional iterator])
+fi
+])

llvm/autoconf/m4/cxx_fwd_iterator.m4

@@ -0,0 +1,22 @@
+# Check for forward iterator extension.  This is modified from
+# http://www.gnu.org/software/ac-archive/htmldoc/ac_cxx_have_ext_hash_set.html
+AC_DEFUN([AC_CXX_HAVE_FWD_ITERATOR],
+[AC_CACHE_CHECK(whether the compiler has forward iterators,
+ac_cv_cxx_have_fwd_iterator,
+[AC_REQUIRE([AC_CXX_NAMESPACES])
+  AC_LANG_PUSH([C++])
+  AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <iterator>
+#ifdef HAVE_NAMESPACES
+using namespace std;
+#endif]], [[forward_iterator<int,int> t; return 0;]])],[ac_cv_cxx_have_fwd_iterator=yes],[ac_cv_cxx_have_fwd_iterator=no])
+  AC_LANG_POP([C++])
+])
+if test "$ac_cv_cxx_have_fwd_iterator" = yes
+then
+   AC_DEFINE(HAVE_FWD_ITERATOR,1,[Have forward iterator])
+else
+   AC_DEFINE(HAVE_FWD_ITERATOR,0,[Does not have forward iterator])
+fi
+])
+
+

llvm/autoconf/m4/cxx_hash_map.m4

@@ -0,0 +1,59 @@
+# Check for hash_map extension.  This is from
+# http://www.gnu.org/software/ac-archive/htmldoc/ac_cxx_have_ext_hash_map.html
+AC_DEFUN([AC_CXX_HAVE_STD_EXT_HASH_MAP],
+[AC_CACHE_CHECK([whether the compiler has <ext/hash_map> defining template class std::hash_map],
+ ac_cv_cxx_have_std_ext_hash_map,
+ [AC_REQUIRE([AC_CXX_NAMESPACES])
+  AC_LANG_PUSH([C++])
+  AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <ext/hash_map>
+#ifdef HAVE_NAMESPACES
+using namespace std;
+#endif]], [[hash_map<int, int> t;]])],[ac_cv_cxx_have_std_ext_hash_map=yes],[ac_cv_cxx_have_std_ext_hash_map=no])
+  AC_LANG_POP([C++])])
+ if test "$ac_cv_cxx_have_std_ext_hash_map" = yes
+ then
+   AC_DEFINE(HAVE_STD_EXT_HASH_MAP,1,[Have ext/hash_map>])
+ else
+   AC_DEFINE(HAVE_STD_EXT_HASH_MAP,0,[Does not have ext/hash_map>])
+ fi
+ ])
+
+AC_DEFUN([AC_CXX_HAVE_GNU_EXT_HASH_MAP],
+[AC_CACHE_CHECK([whether the compiler has <ext/hash_map> defining template class __gnu_cxx::hash_map],
+ ac_cv_cxx_have_gnu_ext_hash_map,
+ [AC_REQUIRE([AC_CXX_NAMESPACES])
+  AC_LANG_PUSH([C++])
+  AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <ext/hash_map>
+#ifdef HAVE_NAMESPACES
+using namespace __gnu_cxx;
+#endif]], [[hash_map<int,int> t; ]])],[ac_cv_cxx_have_gnu_ext_hash_map=yes],[ac_cv_cxx_have_gnu_ext_hash_map=no])
+  AC_LANG_POP([C++])])
+ if test "$ac_cv_cxx_have_gnu_ext_hash_map" = yes
+ then
+   AC_DEFINE(HAVE_GNU_EXT_HASH_MAP,1,[Have ext/hash_map])
+ else
+   AC_DEFINE(HAVE_GNU_EXT_HASH_MAP,0,[Does not have ext/hash_map])
+ fi
+ ])
+
+AC_DEFUN([AC_CXX_HAVE_GLOBAL_HASH_MAP],
+[AC_CACHE_CHECK([whether the compiler has <hash_map> defining template class ::hash_map],
+ ac_cv_cxx_have_global_hash_map,
+ [AC_REQUIRE([AC_CXX_NAMESPACES])
+  AC_LANG_PUSH([C++])
+  AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <hash_map>]], [[hash_map<int,int> t; ]])],[ac_cv_cxx_have_global_hash_map=yes],[ac_cv_cxx_have_global_hash_map=no])
+  AC_LANG_POP([C++])])
+ if test "$ac_cv_cxx_have_global_hash_map" = yes
+ then
+   AC_DEFINE(HAVE_GLOBAL_HASH_MAP,1,[Have <hash_map>])
+ else
+   AC_DEFINE(HAVE_GLOBAL_HASH_MAP,0,[Does not have <hash_map>])
+ fi
+ ])
+
+AC_DEFUN([AC_CXX_HAVE_HASH_MAP],
+[AC_CXX_HAVE_STD_EXT_HASH_MAP
+ AC_CXX_HAVE_GNU_EXT_HASH_MAP
+ AC_CXX_HAVE_GLOBAL_HASH_MAP])
+
+

llvm/autoconf/m4/cxx_hash_set.m4

@@ -0,0 +1,60 @@
+# Check for hash_set extension.  This is modified from
+# http://www.gnu.org/software/ac-archive/htmldoc/ac_cxx_have_ext_hash_set.html
+AC_DEFUN([AC_CXX_HAVE_STD_EXT_HASH_SET],
+[AC_CACHE_CHECK([whether the compiler has <ext/hash_set> defining template class std::hash_set],
+ ac_cv_cxx_have_std_ext_hash_set,
+ [AC_REQUIRE([AC_CXX_NAMESPACES])
+  AC_LANG_PUSH([C++])
+  AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <ext/hash_set>
+#ifdef HAVE_NAMESPACES
+using namespace std;
+#endif]], [[hash_set<int> t; ]])],[ac_cv_cxx_have_std_ext_hash_set=yes],[ac_cv_cxx_have_std_ext_hash_set=no])
+  AC_LANG_POP([C++])])
+ if test "$ac_cv_cxx_have_std_ext_hash_set" = yes
+ then
+   AC_DEFINE(HAVE_STD_EXT_HASH_SET,1,[Have hash_set in std namespace])
+ else
+   AC_DEFINE(HAVE_STD_EXT_HASH_SET,0,[Does not have hash_set in std namespace])
+ fi
+ ])
+
+AC_DEFUN([AC_CXX_HAVE_GNU_EXT_HASH_SET],
+[AC_CACHE_CHECK(
+ [whether the compiler has <ext/hash_set> defining template class __gnu_cxx::hash_set],
+ ac_cv_cxx_have_gnu_ext_hash_set,
+ [AC_REQUIRE([AC_CXX_NAMESPACES])
+  AC_LANG_PUSH([C++])
+  AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <ext/hash_set>
+#ifdef HAVE_NAMESPACES
+using namespace __gnu_cxx;
+#endif]], [[hash_set<int> t; ]])],[ac_cv_cxx_have_gnu_ext_hash_set=yes],[ac_cv_cxx_have_gnu_ext_hash_set=no])
+  AC_LANG_POP([C++])])
+ if test "$ac_cv_cxx_have_gnu_ext_hash_set" = yes
+ then
+   AC_DEFINE(HAVE_GNU_EXT_HASH_SET,1,[Have hash_set in gnu namespace])
+ else
+   AC_DEFINE(HAVE_GNU_EXT_HASH_SET,0,[Does not have hash_set in gnu namespace])
+ fi
+ ])
+
+AC_DEFUN([AC_CXX_HAVE_GLOBAL_HASH_SET],
+[AC_CACHE_CHECK([whether the compiler has <hash_set> defining template class ::hash_set],
+ ac_cv_cxx_have_global_hash_set,
+ [AC_REQUIRE([AC_CXX_NAMESPACES])
+  AC_LANG_PUSH([C++])
+  AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <hash_set>]], [[hash_set<int> t; return 0;]])],[ac_cv_cxx_have_global_hash_set=yes],[ac_cv_cxx_have_global_hash_set=no])
+  AC_LANG_POP([C++])])
+ if test "$ac_cv_cxx_have_global_hash_set" = yes
+ then
+   AC_DEFINE(HAVE_GLOBAL_HASH_SET,1,[Have hash_set in global namespace])
+ else
+   AC_DEFINE(HAVE_GLOBAL_HASH_SET,0,[Does not have hash_set in global namespace])
+ fi
+ ])
+
+AC_DEFUN([AC_CXX_HAVE_HASH_SET],
+[AC_CXX_HAVE_STD_EXT_HASH_SET
+ AC_CXX_HAVE_GNU_EXT_HASH_SET
+ AC_CXX_HAVE_GLOBAL_HASH_SET])
+
+

llvm/autoconf/m4/cxx_namespaces.m4

@@ -0,0 +1,19 @@
+# Check for C++ namespace support.  This is from
+# http://www.gnu.org/software/ac-archive/htmldoc/ac_cxx_namespaces.html
+#
+AC_DEFUN([AC_CXX_NAMESPACES],
+[AC_CACHE_CHECK(whether the compiler implements namespaces,
+ac_cv_cxx_namespaces,
+[AC_LANG_PUSH([C++])
+ AC_COMPILE_IFELSE([AC_LANG_PROGRAM(
+   [[namespace Outer { namespace Inner { int i = 0; }}]],
+   [[using namespace Outer::Inner; return i;]])], 
+   ac_cv_cxx_namespaces=yes, 
+   ac_cv_cxx_namespaces=no)
+ AC_LANG_POP([C++])
+])
+if test "$ac_cv_cxx_namespaces" = yes; then
+  AC_DEFINE(HAVE_NAMESPACES,,[define if the compiler implements namespaces])
+fi
+])
+

llvm/autoconf/m4/cxx_std_iterator.m4

@@ -0,0 +1,26 @@
+# Check for standard iterator extension.  This is modified from
+# http://www.gnu.org/software/ac-archive/htmldoc/ac_cxx_have_ext_hash_set.html
+AC_DEFUN([AC_CXX_HAVE_STD_ITERATOR],
+[AC_CACHE_CHECK(whether the compiler has the standard iterator,
+ac_cv_cxx_have_std_iterator,
+[AC_REQUIRE([AC_CXX_NAMESPACES])
+  AC_LANG_PUSH([C++])
+  AC_COMPILE_IFELSE([AC_LANG_PROGRAM(
+    [[#include <iterator>
+#ifdef HAVE_NAMESPACES
+using namespace std;
+#endif]],
+  [[iterator<int,int,int> t; return 0;]])],
+  ac_cv_cxx_have_std_iterator=yes, 
+  ac_cv_cxx_have_std_iterator=no)
+  AC_LANG_POP([C++])
+])
+if test "$ac_cv_cxx_have_std_iterator" = yes
+then
+   AC_DEFINE(HAVE_STD_ITERATOR,1,[Have std namespace iterator])
+else
+   AC_DEFINE(HAVE_STD_ITERATOR,0,[Does not have std namespace iterator])
+fi
+])
+
+

llvm/autoconf/m4/flex.m4

@@ -0,0 +1,17 @@
+#
+# Check for FLEX.  
+#
+# This macro verifies that flex is installed.  If successful, then
+# 1) $LEX is set to "flex" (to emulate lex calls)
+# 2) BISON is set to bison
+AC_DEFUN([AC_PROG_FLEX],
+[AC_CACHE_CHECK(,
+ac_cv_has_flex,
+[AC_PROG_LEX()
+])
+if test "$LEX" != "flex"; then
+  AC_MSG_ERROR([flex not found but required])
+else
+  AC_SUBST(FLEX,[flex],[location of flex])
+fi
+])

llvm/autoconf/m4/func_isinf.m4

@@ -0,0 +1,36 @@
+#
+# This function determins if the the isinf function isavailable on this
+# platform.
+#
+AC_DEFUN([AC_FUNC_ISINF],[
+AC_SINGLE_CXX_CHECK([ac_cv_func_isinf_in_math_h],   
+                    [isinf], [<math.h>],
+                    [float f; isinf(f);])
+if test "$ac_cv_func_isinf_in_math_h" = "yes" ; then 
+  AC_DEFINE([HAVE_ISINF_IN_MATH_H],1,[Set to 1 if the isinf function is found in <math.h>])
+fi
+
+AC_SINGLE_CXX_CHECK([ac_cv_func_isinf_in_cmath],    
+                    [isinf], [<cmath>],
+                    [float f; isinf(f);])
+if test "$ac_cv_func_isinf_in_cmath" = "yes" ; then
+  AC_DEFINE([HAVE_ISINF_IN_CMATH],1,[Set to 1 if the isinf function is found in <cmath>])
+fi
+
+AC_SINGLE_CXX_CHECK([ac_cv_func_std_isinf_in_cmath],
+                    [std::isinf], [<cmath>],
+                    [float f; std::isinf(f)}])
+if test "$ac_cv_func_std_isinf_in_cmath" = "yes" ; then 
+  AC_DEFINE([HAVE_STD_ISINF_IN_CMATH],1,[Set to 1 if the std::isinf function is found in <cmath>])
+fi
+
+AC_SINGLE_CXX_CHECK([ac_cv_func_finite_in_ieeefp_h],
+                    [finite], [<ieeefp.h>],
+                    [float f; finite(f);])
+if test "$ac_cv_func_finite_in_ieeefp_h" = "yes" ; then
+  AC_DEFINE([HAVE_FINITE_IN_IEEEFP_H],1,[Set to 1 if the finite function is found in <ieeefp.h>])
+fi
+
+])
+
+

llvm/autoconf/m4/func_isnan.m4

@@ -0,0 +1,27 @@
+#
+# This function determines if the isnan function is available on this
+# platform.
+#
+AC_DEFUN([AC_FUNC_ISNAN],[
+AC_SINGLE_CXX_CHECK([ac_cv_func_isnan_in_math_h],   
+                    [isnan], [<math.h>],
+                    [float f; isnan(f);])
+
+if test "$ac_cv_func_isnan_in_math_h" = "yes" ; then
+  AC_DEFINE([HAVE_ISNAN_IN_MATH_H],1,[Set to 1 if the isnan function is found in <math.h>])
+fi
+
+AC_SINGLE_CXX_CHECK([ac_cv_func_isnan_in_cmath],    
+                    [isnan], [<cmath>],
+                    [float f; isnan(f);])
+if test "$ac_cv_func_isnan_in_cmath" = "yes" ; then
+  AC_DEFINE([HAVE_ISNAN_IN_CMATH],1,[Set to 1 if the isnan function is found in <cmath>])
+fi
+
+AC_SINGLE_CXX_CHECK([ac_cv_func_std_isnan_in_cmath],
+                    [std::isnan], [<cmath>],
+                    [float f; std::isnan(f);])
+if test "$ac_cv_func_std_isnan_in_cmath" = "yes" ; then
+  AC_DEFINE([HAVE_STD_ISNAN_IN_CMATH],1,[Set to 1 if the std::isnan function is found in <cmath>])
+fi
+])

llvm/autoconf/m4/func_mmap_file.m4

@@ -0,0 +1,26 @@
+#
+# Check for the ability to mmap a file.  
+#
+AC_DEFUN([AC_FUNC_MMAP_FILE],
+[AC_CACHE_CHECK(for mmap of files,
+ac_cv_func_mmap_file,
+[ AC_LANG_PUSH([C])
+  AC_RUN_IFELSE([
+    AC_LANG_PROGRAM([[
+#include <sys/types.h>
+#include <sys/mman.h>
+#include <fcntl.h>
+]],[[
+  int fd;
+  fd = creat ("foo",0777); 
+  fd = (int) mmap (0, 1, PROT_READ, MAP_SHARED, fd, 0);
+  unlink ("foo"); 
+  return (fd != (int) MAP_FAILED);]])],
+  [ac_cv_func_mmap_file=yes],[ac_cv_func_mmap_file=no],[ac_cv_func_mmap_file=no])
+  AC_LANG_POP([C])
+])
+if test "$ac_cv_func_mmap_file" = yes; then
+   AC_DEFINE([HAVE_MMAP_FILE],[],[Define if mmap() can map files into memory])
+   AC_SUBST(MMAP_FILE,[yes])
+fi
+])

llvm/autoconf/m4/header_mmap_anonymous.m4

@@ -0,0 +1,21 @@
+#
+# Check for anonymous mmap macros.  This is modified from
+# http://www.gnu.org/software/ac-archive/htmldoc/ac_cxx_have_ext_slist.html
+#
+AC_DEFUN([AC_HEADER_MMAP_ANONYMOUS],
+[AC_CACHE_CHECK(for MAP_ANONYMOUS vs. MAP_ANON,
+ac_cv_header_mmap_anon,
+[ AC_LANG_PUSH([C])
+  AC_COMPILE_IFELSE([AC_LANG_PROGRAM(
+    [[#include <sys/mman.h>
+#include <unistd.h>
+#include <fcntl.h>]],
+  [[mmap (0, 1, PROT_READ, MAP_ANONYMOUS, -1, 0); return (0);]])],
+  ac_cv_header_mmap_anon=yes, 
+  ac_cv_header_mmap_anon=no)
+  AC_LANG_POP([C])
+])
+if test "$ac_cv_header_mmap_anon" = yes; then
+   AC_DEFINE([HAVE_MMAP_ANONYMOUS],[1],[Define if mmap() uses MAP_ANONYMOUS to map anonymous pages, or undefine if it uses MAP_ANON])
+fi
+])

llvm/autoconf/m4/link_use_r.m4

@@ -0,0 +1,19 @@
+#
+# Determine if the system can handle the -R option being passed to the linker.
+#
+# This macro is specific to LLVM.
+#
+AC_DEFUN([AC_LINK_USE_R],
+[AC_CACHE_CHECK([for compiler -Wl,-R<path> option],[llvm_cv_link_use_r],
+[ AC_LANG_PUSH([C])
+  oldcflags="$CFLAGS"
+  CFLAGS="$CFLAGS -Wl,-R."
+  AC_LINK_IFELSE([AC_LANG_PROGRAM([[]],[[int main() { return 0; }]])],
+    [llvm_cv_link_use_r=yes],[llvm_cv_link_use_r=no])
+  CFLAGS="$oldcflags"
+  AC_LANG_POP([C])
+])
+if test "$llvm_cv_link_use_r" = yes ; then
+  AC_DEFINE([HAVE_LINK_R],[1],[Define if you can use -Wl,-R. to pass -R. to the linker, in order to add the current directory to the dynamic linker search path.])
+  fi
+])

llvm/autoconf/m4/ltdl.m4

@@ -0,0 +1,427 @@
+## ltdl.m4 - Configure ltdl for the target system. -*-Autoconf-*-
+## Copyright (C) 1999-2000 Free Software Foundation, Inc.
+##
+## 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 6 AC_LIB_LTDL
+
+# AC_WITH_LTDL
+# ------------
+# Clients of libltdl can use this macro to allow the installer to
+# choose between a shipped copy of the ltdl sources or a preinstalled
+# version of the library.
+AC_DEFUN([AC_WITH_LTDL],
+[AC_REQUIRE([AC_LIB_LTDL])
+AC_SUBST([LIBLTDL])
+AC_SUBST([INCLTDL])
+
+# Unless the user asks us to check, assume no installed ltdl exists.
+use_installed_libltdl=no
+
+AC_ARG_WITH([included_ltdl],
+    [  --with-included-ltdl    use the GNU ltdl sources included here])
+
+if test "x$with_included_ltdl" != xyes; then
+  # We are not being forced to use the included libltdl sources, so
+  # decide whether there is a useful installed version we can use.
+  AC_CHECK_HEADER([ltdl.h],
+      [AC_CHECK_LIB([ltdl], [lt_dlcaller_register],
+          [with_included_ltdl=no],
+          [with_included_ltdl=yes])
+  ])
+fi
+
+if test "x$enable_ltdl_install" != xyes; then
+  # If the user did not specify an installable libltdl, then default
+  # to a convenience lib.
+  AC_LIBLTDL_CONVENIENCE
+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,
+    [Define this if a modern libltdl is already installed])
+  LIBLTDL=-lltdl
+fi
+
+# Report our decision...
+AC_MSG_CHECKING([whether to use included libltdl])
+AC_MSG_RESULT([$with_included_ltdl])
+
+AC_CONFIG_SUBDIRS([libltdl])
+])# AC_WITH_LTDL
+
+
+# AC_LIB_LTDL
+# -----------
+# 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.59)
+AC_REQUIRE([AC_PROG_CC])
+AC_REQUIRE([AC_C_CONST])
+AC_REQUIRE([AC_HEADER_STDC])
+AC_REQUIRE([AC_HEADER_DIRENT])
+AC_REQUIRE([_LT_AC_CHECK_DLFCN])
+AC_REQUIRE([AC_LTDL_ENABLE_INSTALL])
+AC_REQUIRE([AC_LTDL_SHLIBEXT])
+AC_REQUIRE([AC_LTDL_SHLIBPATH])
+AC_REQUIRE([AC_LTDL_SYSSEARCHPATH])
+AC_REQUIRE([AC_LTDL_OBJDIR])
+AC_REQUIRE([AC_LTDL_DLPREOPEN])
+AC_REQUIRE([AC_LTDL_DLLIB])
+AC_REQUIRE([AC_LTDL_SYMBOL_USCORE])
+AC_REQUIRE([AC_LTDL_DLSYM_USCORE])
+AC_REQUIRE([AC_LTDL_SYS_DLOPEN_DEPLIBS])
+AC_REQUIRE([AC_LTDL_FUNC_ARGZ])
+
+AC_CHECK_HEADERS([assert.h ctype.h errno.h malloc.h memory.h stdlib.h \
+		  stdio.h unistd.h])
+AC_CHECK_HEADERS([dl.h sys/dl.h dld.h mach-o/dyld.h])
+AC_CHECK_HEADERS([string.h strings.h], [break])
+
+AC_CHECK_FUNCS([strchr index], [break])
+AC_CHECK_FUNCS([strrchr rindex], [break])
+AC_CHECK_FUNCS([memcpy bcopy], [break])
+AC_CHECK_FUNCS([memmove strcmp])
+AC_CHECK_FUNCS([closedir opendir readdir])
+])# AC_LIB_LTDL
+
+
+# AC_LTDL_ENABLE_INSTALL
+# ----------------------
+AC_DEFUN([AC_LTDL_ENABLE_INSTALL],
+[AC_ARG_ENABLE([ltdl-install],
+    [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_SYS_DLOPEN_DEPLIBS
+# --------------------------
+AC_DEFUN([AC_LTDL_SYS_DLOPEN_DEPLIBS],
+[AC_REQUIRE([AC_CANONICAL_HOST])
+AC_CACHE_CHECK([whether deplibs are loaded by dlopen],
+  [libltdl_cv_sys_dlopen_deplibs],
+  [# PORTME does your system automatically load deplibs for dlopen?
+  # or its logical equivalent (e.g. shl_load for HP-UX < 11)
+  # For now, we just catch OSes we know something about -- in the
+  # future, we'll try test this programmatically.
+  libltdl_cv_sys_dlopen_deplibs=unknown
+  case "$host_os" in
+  aix3*|aix4.1.*|aix4.2.*)
+    # Unknown whether this is true for these versions of AIX, but
+    # we want this `case' here to explicitly catch those versions.
+    libltdl_cv_sys_dlopen_deplibs=unknown
+    ;;
+  aix[[45]]*)
+    libltdl_cv_sys_dlopen_deplibs=yes
+    ;;
+  darwin*)
+    # 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
+    ;;
+  hpux10*|hpux11*)
+    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.
+    libltdl_cv_sys_dlopen_deplibs=unknown
+    ;;
+  irix*)
+    # The case above catches anything before 6.2, and it's known that
+    # at 6.2 and later dlopen does load deplibs.
+    libltdl_cv_sys_dlopen_deplibs=yes
+    ;;
+  netbsd*)
+    libltdl_cv_sys_dlopen_deplibs=yes
+    ;;
+  openbsd*)
+    libltdl_cv_sys_dlopen_deplibs=yes
+    ;;
+  osf[[1234]]*)
+    # dlopen did load deplibs (at least at 4.x), but until the 5.x series,
+    # it did *not* use an RPATH in a shared library to find objects the
+    # library depends on, so we explictly say `no'.
+    libltdl_cv_sys_dlopen_deplibs=no
+    ;;
+  osf5.0|osf5.0a|osf5.1)
+    # dlopen *does* load deplibs and with the right loader patch applied
+    # it even uses RPATH in a shared library to search for shared objects
+    # that the library depends on, but there's no easy way to know if that
+    # patch is installed.  Since this is the case, all we can really
+    # say is unknown -- it depends on the patch being installed.  If
+    # it is, this changes to `yes'.  Without it, it would be `no'.
+    libltdl_cv_sys_dlopen_deplibs=unknown
+    ;;
+  osf*)
+    # the two cases above should catch all versions of osf <= 5.1.  Read
+    # the comments above for what we know about them.
+    # At > 5.1, deplibs are loaded *and* any RPATH in a shared library
+    # is used to find them so we can finally say `yes'.
+    libltdl_cv_sys_dlopen_deplibs=yes
+    ;;
+  solaris*)
+    libltdl_cv_sys_dlopen_deplibs=yes
+    ;;
+  esac
+  ])
+if test "$libltdl_cv_sys_dlopen_deplibs" != yes; then
+ AC_DEFINE([LTDL_DLOPEN_DEPLIBS], [1],
+    [Define if the OS needs help to load dependent libraries for dlopen().])
+fi
+])# AC_LTDL_SYS_DLOPEN_DEPLIBS
+
+
+# AC_LTDL_SHLIBEXT
+# ----------------
+AC_DEFUN([AC_LTDL_SHLIBEXT],
+[AC_REQUIRE([AC_LIBTOOL_SYS_DYNAMIC_LINKER])
+AC_CACHE_CHECK([which extension is used for loadable modules],
+  [libltdl_cv_shlibext],
+[
+module=yes
+eval libltdl_cv_shlibext=$shrext_cmds
+  ])
+if test -n "$libltdl_cv_shlibext"; then
+  AC_DEFINE_UNQUOTED(LTDL_SHLIB_EXT, "$libltdl_cv_shlibext",
+    [Define to the extension used for shared libraries, say, ".so".])
+fi
+])# AC_LTDL_SHLIBEXT
+
+
+# AC_LTDL_SHLIBPATH
+# -----------------
+AC_DEFUN([AC_LTDL_SHLIBPATH],
+[AC_REQUIRE([AC_LIBTOOL_SYS_DYNAMIC_LINKER])
+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",
+    [Define to the name of the environment variable that determines the dynamic library search path.])
+fi
+])# AC_LTDL_SHLIBPATH
+
+
+# AC_LTDL_SYSSEARCHPATH
+# ---------------------
+AC_DEFUN([AC_LTDL_SYSSEARCHPATH],
+[AC_REQUIRE([AC_LIBTOOL_SYS_DYNAMIC_LINKER])
+AC_CACHE_CHECK([for the default library search path],
+  [libltdl_cv_sys_search_path],
+  [libltdl_cv_sys_search_path="$sys_lib_dlsearch_path_spec"])
+if test -n "$libltdl_cv_sys_search_path"; then
+  sys_search_path=
+  for dir in $libltdl_cv_sys_search_path; do
+    if test -z "$sys_search_path"; then
+      sys_search_path="$dir"
+    else
+      sys_search_path="$sys_search_path$PATH_SEPARATOR$dir"
+    fi
+  done
+  AC_DEFINE_UNQUOTED(LTDL_SYSSEARCHPATH, "$sys_search_path",
+    [Define to the system default library search path.])
+fi
+])# AC_LTDL_SYSSEARCHPATH
+
+
+# AC_LTDL_OBJDIR
+# --------------
+AC_DEFUN([AC_LTDL_OBJDIR],
+[AC_CACHE_CHECK([for objdir],
+  [libltdl_cv_objdir],
+  [libltdl_cv_objdir="$objdir"
+  if test -n "$objdir"; then
+    :
+  else
+    rm -f .libs 2>/dev/null
+    mkdir .libs 2>/dev/null
+    if test -d .libs; then
+      libltdl_cv_objdir=.libs
+    else
+      # MS-DOS does not allow filenames that begin with a dot.
+      libltdl_cv_objdir=_libs
+    fi
+  rmdir .libs 2>/dev/null
+  fi
+  ])
+AC_DEFINE_UNQUOTED(LTDL_OBJDIR, "$libltdl_cv_objdir/",
+  [Define to the sub-directory in which libtool stores uninstalled libraries.])
+])# AC_LTDL_OBJDIR
+
+
+# AC_LTDL_DLPREOPEN
+# -----------------
+AC_DEFUN([AC_LTDL_DLPREOPEN],
+[AC_REQUIRE([AC_LIBTOOL_SYS_GLOBAL_SYMBOL_PIPE])
+AC_CACHE_CHECK([whether libtool supports -dlopen/-dlpreopen],
+  [libltdl_cv_preloaded_symbols],
+  [if test -n "$lt_cv_sys_global_symbol_pipe"; then
+    libltdl_cv_preloaded_symbols=yes
+  else
+    libltdl_cv_preloaded_symbols=no
+  fi
+  ])
+if test x"$libltdl_cv_preloaded_symbols" = xyes; then
+  AC_DEFINE(HAVE_PRELOADED_SYMBOLS, 1,
+    [Define if libtool can extract symbol lists from object files.])
+fi
+])# AC_LTDL_DLPREOPEN
+
+
+# AC_LTDL_DLLIB
+# -------------
+AC_DEFUN([AC_LTDL_DLLIB],
+[LIBADD_DL=
+AC_SUBST(LIBADD_DL)
+AC_LANG_PUSH([C])
+
+AC_CHECK_FUNC([shl_load],
+      [AC_DEFINE([HAVE_SHL_LOAD], [1],
+		 [Define if you have the shl_load function.])],
+  [AC_CHECK_LIB([dld], [shl_load],
+	[AC_DEFINE([HAVE_SHL_LOAD], [1],
+		   [Define if you have the shl_load function.])
+	LIBADD_DL="$LIBADD_DL -ldld"],
+    [AC_CHECK_LIB([dl], [dlopen],
+	  [AC_DEFINE([HAVE_LIBDL], [1],
+		     [Define if you have the libdl library or equivalent.])
+	        LIBADD_DL="-ldl" libltdl_cv_lib_dl_dlopen="yes"],
+      [AC_LINK_IFELSE([AC_LANG_PROGRAM([[#if HAVE_DLFCN_H
+#  include <dlfcn.h>
+#endif
+      ]], [[dlopen(0, 0);]])],[AC_DEFINE([HAVE_LIBDL], [1],
+		             [Define if you have the libdl library or equivalent.]) libltdl_cv_func_dlopen="yes"],[AC_CHECK_LIB([svld], [dlopen],
+	      [AC_DEFINE([HAVE_LIBDL], [1],
+			 [Define if you have the libdl library or equivalent.])
+	            LIBADD_DL="-lsvld" libltdl_cv_func_dlopen="yes"],
+	  [AC_CHECK_LIB([dld], [dld_link],
+	        [AC_DEFINE([HAVE_DLD], [1],
+			   [Define if you have the GNU dld library.])
+	 	LIBADD_DL="$LIBADD_DL -ldld"],
+	 	[AC_CHECK_FUNC([_dyld_func_lookup],
+	 	       [AC_DEFINE([HAVE_DYLD], [1],
+	 	          [Define if you have the _dyld_func_lookup function.])])
+          ])
+        ])
+      ])
+    ])
+  ])
+])
+
+if test x"$libltdl_cv_func_dlopen" = xyes || test x"$libltdl_cv_lib_dl_dlopen" = xyes
+then
+  lt_save_LIBS="$LIBS"
+  LIBS="$LIBS $LIBADD_DL"
+  AC_CHECK_FUNCS([dlerror])
+  LIBS="$lt_save_LIBS"
+fi
+AC_LANG_POP
+])# AC_LTDL_DLLIB
+
+
+# AC_LTDL_SYMBOL_USCORE
+# ---------------------
+# does the compiler prefix global symbols with an underscore?
+AC_DEFUN([AC_LTDL_SYMBOL_USCORE],
+[AC_REQUIRE([AC_LIBTOOL_SYS_GLOBAL_SYMBOL_PIPE])
+AC_CACHE_CHECK([for _ prefix in compiled symbols],
+  [ac_cv_sys_symbol_underscore],
+  [ac_cv_sys_symbol_underscore=no
+  cat > conftest.$ac_ext <<EOF
+void nm_test_func(){}
+int main(){nm_test_func;return 0;}
+EOF
+  if AC_TRY_EVAL(ac_compile); then
+    # Now try to grab the symbols.
+    ac_nlist=conftest.nm
+    if AC_TRY_EVAL(NM conftest.$ac_objext \| $lt_cv_sys_global_symbol_pipe \> $ac_nlist) && test -s "$ac_nlist"; then
+      # See whether the symbols have a leading underscore.
+      if grep '^. _nm_test_func' "$ac_nlist" >/dev/null; then
+        ac_cv_sys_symbol_underscore=yes
+      else
+        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()
+        fi
+      fi
+    else
+      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()
+  fi
+  rm -rf conftest*
+  ])
+])# AC_LTDL_SYMBOL_USCORE
+
+
+# AC_LTDL_DLSYM_USCORE
+# --------------------
+AC_DEFUN([AC_LTDL_DLSYM_USCORE],
+[AC_REQUIRE([AC_LTDL_SYMBOL_USCORE])
+if test x"$ac_cv_sys_symbol_underscore" = xyes; then
+  if test x"$libltdl_cv_func_dlopen" = xyes ||
+     test x"$libltdl_cv_lib_dl_dlopen" = xyes ; then
+	AC_CACHE_CHECK([whether we have to add an underscore for dlsym],
+	  [libltdl_cv_need_uscore],
+	  [libltdl_cv_need_uscore=unknown
+          save_LIBS="$LIBS"
+          LIBS="$LIBS $LIBADD_DL"
+	  _LT_AC_TRY_DLOPEN_SELF(
+	    [libltdl_cv_need_uscore=no], [libltdl_cv_need_uscore=yes],
+	    [],				 [libltdl_cv_need_uscore=cross])
+	  LIBS="$save_LIBS"
+	])
+  fi
+fi
+
+if test x"$libltdl_cv_need_uscore" = xyes; then
+  AC_DEFINE(NEED_USCORE, 1,
+    [Define if dlsym() requires a leading underscore in symbol names.])
+fi
+])# AC_LTDL_DLSYM_USCORE
+
+# AC_LTDL_FUNC_ARGZ
+# -----------------
+AC_DEFUN([AC_LTDL_FUNC_ARGZ],
+[AC_CHECK_HEADERS([argz.h])
+
+AC_CHECK_TYPES([error_t],
+  [],
+  [AC_DEFINE([error_t], [int],
+    [Define to a type to use for `error_t' if it is not otherwise available.])],
+  [#if HAVE_ARGZ_H
+#  include <argz.h>
+#endif])
+
+AC_CHECK_FUNCS([argz_append argz_create_sep argz_insert argz_next argz_stringify])
+])# AC_LTDL_FUNC_ARGZ

llvm/autoconf/m4/need_dev_zero_for_mmap.m4

@@ -0,0 +1,17 @@
+#
+# When allocating RWX memory, check whether we need to use /dev/zero
+# as the file descriptor or not.
+#
+AC_DEFUN([AC_NEED_DEV_ZERO_FOR_MMAP],
+[AC_CACHE_CHECK([if /dev/zero is needed for mmap],
+ac_cv_need_dev_zero_for_mmap,
+[if test "$llvm_cv_os_type" = "Interix" ; then
+   ac_cv_need_dev_zero_for_mmap=yes
+ else
+   ac_cv_need_dev_zero_for_mmap=no
+ fi
+])
+if test "$ac_cv_need_dev_zero_for_mmap" = yes; then
+  AC_DEFINE([NEED_DEV_ZERO_FOR_MMAP],[1],
+   [Define if /dev/zero should be used when mapping RWX memory, or undefine if its not necessary])
+fi])

llvm/autoconf/m4/path_tclsh.m4

@@ -0,0 +1,39 @@
+dnl This macro checks for tclsh which is required to run dejagnu. On some 
+dnl platforms (notably FreeBSD), tclsh is named tclshX.Y - this handles
+dnl that for us so we can get the latest installed tclsh version.
+dnl 
+AC_DEFUN([DJ_AC_PATH_TCLSH], [
+no_itcl=true
+AC_MSG_CHECKING(for the tclsh program in tclinclude directory)
+AC_ARG_WITH(tclinclude,
+  AS_HELP_STRING([--with-tclinclude],
+                [directory where tcl headers are]), 
+  [with_tclinclude=${withval}],[with_tclinclude=''])
+AC_CACHE_VAL(ac_cv_path_tclsh,[
+dnl first check to see if --with-itclinclude was specified
+if test x"${with_tclinclude}" != x ; then
+  if test -f ${with_tclinclude}/tclsh ; then
+    ac_cv_path_tclsh=`(cd ${with_tclinclude}; pwd)`
+  elif test -f ${with_tclinclude}/src/tclsh ; then
+    ac_cv_path_tclsh=`(cd ${with_tclinclude}/src; pwd)`
+  else
+    AC_MSG_ERROR([${with_tclinclude} directory doesn't contain tclsh])
+  fi
+fi
+
+dnl see if one is installed
+if test x"${ac_cv_path_tclsh}" = x ; then
+  AC_MSG_RESULT(none)
+  AC_PATH_PROGS([TCLSH],[tclsh8.4 tclsh8.4.8 tclsh8.4.7 tclsh8.4.6 tclsh8.4.5 tclsh8.4.4 tclsh8.4.3 tclsh8.4.2 tclsh8.4.1 tclsh8.4.0 tclsh8.3 tclsh8.3.5 tclsh8.3.4 tclsh8.3.3 tclsh8.3.2 tclsh8.3.1 tclsh8.3.0 tclsh])
+  if test x"${TCLSH}" = x ; then
+    ac_cv_path_tclsh='';
+  else
+    ac_cv_path_tclsh="${TCLSH}";
+  fi
+else
+  AC_MSG_RESULT(${ac_cv_path_tclsh})
+  TCLSH="${ac_cv_path_tclsh}"
+  AC_SUBST(TCLSH)
+fi
+])])
+

llvm/autoconf/m4/rand48.m4

@@ -0,0 +1,12 @@
+#
+# This function determins if the the srand48,drand48,lrand48 functions are
+# available on this platform.
+#
+AC_DEFUN([AC_FUNC_RAND48],[
+AC_SINGLE_CXX_CHECK([ac_cv_func_rand48],   
+                    [srand48/lrand48/drand48], [<stdlib.h>],
+                    [srand48(0);lrand48();drand48();])
+if test "$ac_cv_func_rand48" = "yes" ; then
+AC_DEFINE([HAVE_RAND48],1,[Define to 1 if srand48/lrand48/drand48 exist in <stdlib.h>])
+fi
+])

llvm/autoconf/m4/single_cxx_check.m4

@@ -0,0 +1,10 @@
+dnl AC_SINGLE_CXX_CHECK(CACHEVAR, FUNCTION, HEADER, PROGRAM)
+dnl                     $1,       $2,       $3,     $4,     
+dnl 
+AC_DEFUN([AC_SINGLE_CXX_CHECK],
+ [AC_CACHE_CHECK([for $2 in $3], [$1],
+  [AC_LANG_PUSH([C++])
+   AC_COMPILE_IFELSE(AC_LANG_PROGRAM([#include $3],[$4]),[$1=yes],[$1=no])
+  AC_LANG_POP([C++])])
+ ])
+

llvm/autoconf/missing

@@ -0,0 +1,353 @@
+#! /bin/sh
+# Common stub for a few missing GNU programs while installing.
+
+scriptversion=2004-09-07.08
+
+# Copyright (C) 1996, 1997, 1999, 2000, 2002, 2003, 2004
+#   Free Software Foundation, Inc.
+# Originally by Fran,cois Pinard <pinard@iro.umontreal.ca>, 1996.
+
+# 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, 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.
+
+if test $# -eq 0; then
+  echo 1>&2 "Try \`$0 --help' for more information"
+  exit 1
+fi
+
+run=:
+
+# In the cases where this matters, `missing' is being run in the
+# srcdir already.
+if test -f configure.ac; then
+  configure_ac=configure.ac
+else
+  configure_ac=configure.in
+fi
+
+msg="missing on your system"
+
+case "$1" in
+--run)
+  # Try to run requested program, and just exit if it succeeds.
+  run=
+  shift
+  "$@" && exit 0
+  # Exit code 63 means version mismatch.  This often happens
+  # when the user try to use an ancient version of a tool on
+  # a file that requires a minimum version.  In this case we
+  # we should proceed has if the program had been absent, or
+  # if --run hadn't been passed.
+  if test $? = 63; then
+    run=:
+    msg="probably too old"
+  fi
+  ;;
+
+  -h|--h|--he|--hel|--help)
+    echo "\
+$0 [OPTION]... PROGRAM [ARGUMENT]...
+
+Handle \`PROGRAM [ARGUMENT]...' for when PROGRAM is missing, or return an
+error status if there is no known handling for PROGRAM.
+
+Options:
+  -h, --help      display this help and exit
+  -v, --version   output version information and exit
+  --run           try to run the given command, and emulate it if it fails
+
+Supported PROGRAM values:
+  aclocal      touch file \`aclocal.m4'
+  autoconf     touch file \`configure'
+  autoheader   touch file \`config.h.in'
+  automake     touch all \`Makefile.in' files
+  bison        create \`y.tab.[ch]', if possible, from existing .[ch]
+  flex         create \`lex.yy.c', if possible, from existing .c
+  help2man     touch the output file
+  lex          create \`lex.yy.c', if possible, from existing .c
+  makeinfo     touch the output file
+  tar          try tar, gnutar, gtar, then tar without non-portable flags
+  yacc         create \`y.tab.[ch]', if possible, from existing .[ch]
+
+Send bug reports to <bug-automake@gnu.org>."
+    exit 0
+    ;;
+
+  -v|--v|--ve|--ver|--vers|--versi|--versio|--version)
+    echo "missing $scriptversion (GNU Automake)"
+    exit 0
+    ;;
+
+  -*)
+    echo 1>&2 "$0: Unknown \`$1' option"
+    echo 1>&2 "Try \`$0 --help' for more information"
+    exit 1
+    ;;
+
+esac
+
+# Now exit if we have it, but it failed.  Also exit now if we
+# don't have it and --version was passed (most likely to detect
+# the program).
+case "$1" in
+  lex|yacc)
+    # Not GNU programs, they don't have --version.
+    ;;
+
+  tar)
+    if test -n "$run"; then
+       echo 1>&2 "ERROR: \`tar' requires --run"
+       exit 1
+    elif test "x$2" = "x--version" || test "x$2" = "x--help"; then
+       exit 1
+    fi
+    ;;
+
+  *)
+    if test -z "$run" && ($1 --version) > /dev/null 2>&1; then
+       # We have it, but it failed.
+       exit 1
+    elif test "x$2" = "x--version" || test "x$2" = "x--help"; then
+       # Could not run --version or --help.  This is probably someone
+       # running `$TOOL --version' or `$TOOL --help' to check whether
+       # $TOOL exists and not knowing $TOOL uses missing.
+       exit 1
+    fi
+    ;;
+esac
+
+# If it does not exist, or fails to run (possibly an outdated version),
+# try to emulate it.
+case "$1" in
+  aclocal*)
+    echo 1>&2 "\
+WARNING: \`$1' is $msg.  You should only need it if
+         you modified \`acinclude.m4' or \`${configure_ac}'.  You might want
+         to install the \`Automake' and \`Perl' packages.  Grab them from
+         any GNU archive site."
+    touch aclocal.m4
+    ;;
+
+  autoconf)
+    echo 1>&2 "\
+WARNING: \`$1' is $msg.  You should only need it if
+         you modified \`${configure_ac}'.  You might want to install the
+         \`Autoconf' and \`GNU m4' packages.  Grab them from any GNU
+         archive site."
+    touch configure
+    ;;
+
+  autoheader)
+    echo 1>&2 "\
+WARNING: \`$1' is $msg.  You should only need it if
+         you modified \`acconfig.h' or \`${configure_ac}'.  You might want
+         to install the \`Autoconf' and \`GNU m4' packages.  Grab them
+         from any GNU archive site."
+    files=`sed -n 's/^[ ]*A[CM]_CONFIG_HEADER(\([^)]*\)).*/\1/p' ${configure_ac}`
+    test -z "$files" && files="config.h"
+    touch_files=
+    for f in $files; do
+      case "$f" in
+      *:*) touch_files="$touch_files "`echo "$f" |
+				       sed -e 's/^[^:]*://' -e 's/:.*//'`;;
+      *) touch_files="$touch_files $f.in";;
+      esac
+    done
+    touch $touch_files
+    ;;
+
+  automake*)
+    echo 1>&2 "\
+WARNING: \`$1' is $msg.  You should only need it if
+         you modified \`Makefile.am', \`acinclude.m4' or \`${configure_ac}'.
+         You might want to install the \`Automake' and \`Perl' packages.
+         Grab them from any GNU archive site."
+    find . -type f -name Makefile.am -print |
+	   sed 's/\.am$/.in/' |
+	   while read f; do touch "$f"; done
+    ;;
+
+  autom4te)
+    echo 1>&2 "\
+WARNING: \`$1' is needed, but is $msg.
+         You might have modified some files without having the
+         proper tools for further handling them.
+         You can get \`$1' as part of \`Autoconf' from any GNU
+         archive site."
+
+    file=`echo "$*" | sed -n 's/.*--output[ =]*\([^ ]*\).*/\1/p'`
+    test -z "$file" && file=`echo "$*" | sed -n 's/.*-o[ ]*\([^ ]*\).*/\1/p'`
+    if test -f "$file"; then
+	touch $file
+    else
+	test -z "$file" || exec >$file
+	echo "#! /bin/sh"
+	echo "# Created by GNU Automake missing as a replacement of"
+	echo "#  $ $@"
+	echo "exit 0"
+	chmod +x $file
+	exit 1
+    fi
+    ;;
+
+  bison|yacc)
+    echo 1>&2 "\
+WARNING: \`$1' $msg.  You should only need it if
+         you modified a \`.y' file.  You may need the \`Bison' package
+         in order for those modifications to take effect.  You can get
+         \`Bison' from any GNU archive site."
+    rm -f y.tab.c y.tab.h
+    if [ $# -ne 1 ]; then
+        eval LASTARG="\${$#}"
+	case "$LASTARG" in
+	*.y)
+	    SRCFILE=`echo "$LASTARG" | sed 's/y$/c/'`
+	    if [ -f "$SRCFILE" ]; then
+	         cp "$SRCFILE" y.tab.c
+	    fi
+	    SRCFILE=`echo "$LASTARG" | sed 's/y$/h/'`
+	    if [ -f "$SRCFILE" ]; then
+	         cp "$SRCFILE" y.tab.h
+	    fi
+	  ;;
+	esac
+    fi
+    if [ ! -f y.tab.h ]; then
+	echo >y.tab.h
+    fi
+    if [ ! -f y.tab.c ]; then
+	echo 'main() { return 0; }' >y.tab.c
+    fi
+    ;;
+
+  lex|flex)
+    echo 1>&2 "\
+WARNING: \`$1' is $msg.  You should only need it if
+         you modified a \`.l' file.  You may need the \`Flex' package
+         in order for those modifications to take effect.  You can get
+         \`Flex' from any GNU archive site."
+    rm -f lex.yy.c
+    if [ $# -ne 1 ]; then
+        eval LASTARG="\${$#}"
+	case "$LASTARG" in
+	*.l)
+	    SRCFILE=`echo "$LASTARG" | sed 's/l$/c/'`
+	    if [ -f "$SRCFILE" ]; then
+	         cp "$SRCFILE" lex.yy.c
+	    fi
+	  ;;
+	esac
+    fi
+    if [ ! -f lex.yy.c ]; then
+	echo 'main() { return 0; }' >lex.yy.c
+    fi
+    ;;
+
+  help2man)
+    echo 1>&2 "\
+WARNING: \`$1' is $msg.  You should only need it if
+	 you modified a dependency of a manual page.  You may need the
+	 \`Help2man' package in order for those modifications to take
+	 effect.  You can get \`Help2man' from any GNU archive site."
+
+    file=`echo "$*" | sed -n 's/.*-o \([^ ]*\).*/\1/p'`
+    if test -z "$file"; then
+	file=`echo "$*" | sed -n 's/.*--output=\([^ ]*\).*/\1/p'`
+    fi
+    if [ -f "$file" ]; then
+	touch $file
+    else
+	test -z "$file" || exec >$file
+	echo ".ab help2man is required to generate this page"
+	exit 1
+    fi
+    ;;
+
+  makeinfo)
+    echo 1>&2 "\
+WARNING: \`$1' is $msg.  You should only need it if
+         you modified a \`.texi' or \`.texinfo' file, or any other file
+         indirectly affecting the aspect of the manual.  The spurious
+         call might also be the consequence of using a buggy \`make' (AIX,
+         DU, IRIX).  You might want to install the \`Texinfo' package or
+         the \`GNU make' package.  Grab either from any GNU archive site."
+    file=`echo "$*" | sed -n 's/.*-o \([^ ]*\).*/\1/p'`
+    if test -z "$file"; then
+      file=`echo "$*" | sed 's/.* \([^ ]*\) *$/\1/'`
+      file=`sed -n '/^@setfilename/ { s/.* \([^ ]*\) *$/\1/; p; q; }' $file`
+    fi
+    touch $file
+    ;;
+
+  tar)
+    shift
+
+    # We have already tried tar in the generic part.
+    # Look for gnutar/gtar before invocation to avoid ugly error
+    # messages.
+    if (gnutar --version > /dev/null 2>&1); then
+       gnutar "$@" && exit 0
+    fi
+    if (gtar --version > /dev/null 2>&1); then
+       gtar "$@" && exit 0
+    fi
+    firstarg="$1"
+    if shift; then
+	case "$firstarg" in
+	*o*)
+	    firstarg=`echo "$firstarg" | sed s/o//`
+	    tar "$firstarg" "$@" && exit 0
+	    ;;
+	esac
+	case "$firstarg" in
+	*h*)
+	    firstarg=`echo "$firstarg" | sed s/h//`
+	    tar "$firstarg" "$@" && exit 0
+	    ;;
+	esac
+    fi
+
+    echo 1>&2 "\
+WARNING: I can't seem to be able to run \`tar' with the given arguments.
+         You may want to install GNU tar or Free paxutils, or check the
+         command line arguments."
+    exit 1
+    ;;
+
+  *)
+    echo 1>&2 "\
+WARNING: \`$1' is needed, and is $msg.
+         You might have modified some files without having the
+         proper tools for further handling them.  Check the \`README' file,
+         it often tells you about the needed prerequisites for installing
+         this package.  You may also peek at any GNU archive site, in case
+         some other package would contain this missing \`$1' program."
+    exit 1
+    ;;
+esac
+
+exit 0
+
+# Local variables:
+# eval: (add-hook 'write-file-hooks 'time-stamp)
+# time-stamp-start: "scriptversion="
+# time-stamp-format: "%:y-%02m-%02d.%02H"
+# time-stamp-end: "$"
+# End:

llvm/autoconf/mkinstalldirs

@@ -1,31 +1,56 @@
 #! /bin/sh
 # mkinstalldirs --- make directory hierarchy
-# Author: Noah Friedman <friedman@prep.ai.mit.edu>
-# Created: 1993-05-16
-# Public domain
 
-# $Id$
+scriptversion=2004-02-15.20
+
+# Original author: Noah Friedman <friedman@prep.ai.mit.edu>
+# Created: 1993-05-16
+# Public domain.
+#
+# This file is maintained in Automake, please report
+# bugs to <bug-automake@gnu.org> or send patches to
+# <automake-patches@gnu.org>.
 
 errstatus=0
 dirmode=""
 
 usage="\
-Usage: mkinstalldirs [-h] [--help] [-m mode] dir ..."
+Usage: mkinstalldirs [-h] [--help] [--version] [-m MODE] DIR ...
+
+Create each directory DIR (with mode MODE, if specified), including all
+leading file name components.
+
+Report bugs to <bug-automake@gnu.org>."
 
 # process command line arguments
 while test $# -gt 0 ; do
-   case "${1}" in
-     -h | --help | --h* )			# -h for help
-	echo "${usage}" 1>&2; exit 0 ;;
-     -m )					# -m PERM arg
-	shift
-	test $# -eq 0 && { echo "${usage}" 1>&2; exit 1; }
-	dirmode="${1}"
-	shift ;;
-     -- ) shift; break ;;			# stop option processing
-     -* ) echo "${usage}" 1>&2; exit 1 ;;	# unknown option
-     * )  break ;;				# first non-opt arg
-   esac
+  case $1 in
+    -h | --help | --h*)         # -h for help
+      echo "$usage"
+      exit 0
+      ;;
+    -m)                         # -m PERM arg
+      shift
+      test $# -eq 0 && { echo "$usage" 1>&2; exit 1; }
+      dirmode=$1
+      shift
+      ;;
+    --version)
+      echo "$0 $scriptversion"
+      exit 0
+      ;;
+    --)                         # stop option processing
+      shift
+      break
+      ;;
+    -*)                         # unknown option
+      echo "$usage" 1>&2
+      exit 1
+      ;;
+    *)                          # first non-opt arg
+      break
+      ;;
+  esac
 done
 
 for file
@@ -38,64 +63,88 @@ do
 done
 
 case $# in
-0) exit 0 ;;
+  0) exit 0 ;;
 esac
 
+# Solaris 8's mkdir -p isn't thread-safe.  If you mkdir -p a/b and
+# mkdir -p a/c at the same time, both will detect that a is missing,
+# one will create a, then the other will try to create a and die with
+# a "File exists" error.  This is a problem when calling mkinstalldirs
+# from a parallel make.  We use --version in the probe to restrict
+# ourselves to GNU mkdir, which is thread-safe.
 case $dirmode in
-'')
-  if mkdir -p -- . 2>/dev/null; then
-    echo "mkdir -p -- $*"
-    exec mkdir -p -- "$@"
-  fi ;;
-*)
-  if mkdir -m "$dirmode" -p -- . 2>/dev/null; then
-    echo "mkdir -m $dirmode -p -- $*"
-    exec mkdir -m "$dirmode" -p -- "$@"
-  fi ;;
+  '')
+    if mkdir -p --version . >/dev/null 2>&1 && test ! -d ./--version; then
+      # echo "mkdir -p -- $*"
+      exec mkdir -p -- "$@"
+    else
+      # On NextStep and OpenStep, the `mkdir' command does not
+      # recognize any option.  It will interpret all options as
+      # directories to create, and then abort because `.' already
+      # exists.
+      test -d ./-p && rmdir ./-p
+      test -d ./--version && rmdir ./--version
+    fi
+    ;;
+  *)
+    if mkdir -m "$dirmode" -p --version . >/dev/null 2>&1 &&
+       test ! -d ./--version; then
+      # echo "mkdir -m $dirmode -p -- $*"
+      exec mkdir -m "$dirmode" -p -- "$@"
+    else
+      # Clean up after NextStep and OpenStep mkdir.
+      for d in ./-m ./-p ./--version "./$dirmode";
+      do
+        test -d $d && rmdir $d
+      done
+    fi
+    ;;
 esac
 
 for file
 do
-   set fnord `echo ":$file" | sed -ne 's/^:\//#/;s/^://;s/\// /g;s/^#/\//;p'`
-   shift
+  set fnord `echo ":$file" | sed -ne 's/^:\//#/;s/^://;s/\// /g;s/^#/\//;p'`
+  shift
 
-   pathcomp=
-   for d
-   do
-     pathcomp="$pathcomp$d"
-     case "$pathcomp" in
-       -* ) pathcomp=./$pathcomp ;;
-     esac
+  pathcomp=
+  for d
+  do
+    pathcomp="$pathcomp$d"
+    case $pathcomp in
+      -*) pathcomp=./$pathcomp ;;
+    esac
 
-     if test ! -d "$pathcomp"; then
-	echo "mkdir $pathcomp"
+    if test ! -d "$pathcomp"; then
+      # echo "mkdir $pathcomp"
 
-	mkdir "$pathcomp" || lasterr=$?
+      mkdir "$pathcomp" || lasterr=$?
 
-	if test ! -d "$pathcomp"; then
-	  errstatus=$lasterr
-	else
-	  if test ! -z "$dirmode"; then
-	     echo "chmod $dirmode $pathcomp"
+      if test ! -d "$pathcomp"; then
+	errstatus=$lasterr
+      else
+	if test ! -z "$dirmode"; then
+	  # echo "chmod $dirmode $pathcomp"
+	  lasterr=""
+	  chmod "$dirmode" "$pathcomp" || lasterr=$?
 
-	     lasterr=""
-	     chmod "$dirmode" "$pathcomp" || lasterr=$?
-
-	     if test ! -z "$lasterr"; then
-	       errstatus=$lasterr
-	     fi
+	  if test ! -z "$lasterr"; then
+	    errstatus=$lasterr
 	  fi
 	fi
-     fi
+      fi
+    fi
 
-     pathcomp="$pathcomp/"
-   done
+    pathcomp="$pathcomp/"
+  done
 done
 
 exit $errstatus
 
 # Local Variables:
 # mode: shell-script
-# sh-indentation: 3
+# sh-indentation: 2
+# eval: (add-hook 'write-file-hooks 'time-stamp)
+# time-stamp-start: "scriptversion="
+# time-stamp-format: "%:y-%02m-%02d.%02H"
+# time-stamp-end: "$"
 # End:
-# mkinstalldirs ends here

llvm/docs/.cvsignore

@@ -0,0 +1,2 @@
+doxygen.cfg
+

llvm/docs/AliasAnalysis.html

@@ -274,7 +274,6 @@ memory location to be modified.</p>
 
 </div>
 
-
 <!-- _______________________________________________________________________ -->
 <div class="doc_subsubsection">
   <a name="simplemodref">The <tt>doesNotAccessMemory</tt> and
@@ -304,8 +303,6 @@ functions that satisfy the <tt>doesNotAccessMemory</tt> method also satisfies
 
 </div>
 
-
-
 <!-- *********************************************************************** -->
 <div class="doc_section">
   <a name="writingnew">Writing a new <tt>AliasAnalysis</tt> Implementation</a>

llvm/docs/Bugpoint.html

@@ -1,33 +1,63 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" 
+                      "http://www.w3.org/TR/html4/strict.dtd">
 <html>
-<title>LLVM: bugpoint tool</title>
+<head>
+  <title>LLVM bugpoint tool: design and usage</title>
+  <link rel="stylesheet" href="llvm.css" type="text/css">
+</head>
 
-<body bgcolor=white>
+<div class="doc_title">
+  LLVM bugpoint tool: design and usage
+</div>
 
-<center><h1>LLVM: <tt>bugpoint</tt> tool</h1></center>
-<HR>
+<ul>
+  <li><a href="#desc">Description</a></li>
+  <li><a href="#design">Design Philosophy</a>
+  <ul>
+    <li><a href="#autoselect">Automatic Debugger Selection</a></li>
+    <li><a href="#crashdebug">Crash debugger</a></li>
+    <li><a href="#codegendebug">Code generator debugger</a></li>
+    <li><a href="#miscompilationdebug">Miscompilation debugger</a></li>
+  </ul></li>
+  <li><a href="#advice">Advice for using <tt>bugpoint</tt></a></li>
+</ul>
 
-<h3>NAME</h3>
-<tt>bugpoint</tt>
+<div class="doc_author">
+<p>Written by <a href="mailto:sabre@nondot.org">Chris Lattner</a></p>
+</div>
 
-<h3>SYNOPSIS</h3>
-<tt>bugpoint [options] [input LLVM ll/bc files] [LLVM passes] --args &lt;program arguments&gt;...</tt>
+<!-- *********************************************************************** -->
+<div class="doc_section">
+<a name="desc">Description</a>
+</div>
+<!-- *********************************************************************** -->
 
-<img src="img/Debugging.gif" width=444 height=314 align=right>
-<h3>DESCRIPTION</h3>
+<div class="doc_text">
 
-The <tt>bugpoint</tt> tool narrows down the source of
-problems in LLVM 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 JIT compilers).  It aims 
-to reduce large test cases to small, useful ones.  For example,
-if <tt><a href="CommandGuide/gccas.html">gccas</a></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><tt>bugpoint</tt> narrows down the source of problems in LLVM 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 JIT compilers).  It aims to reduce large test cases to small,
+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>
 
-<a name="designphilosophy">
-<h4>Design Philosophy</h4>
+<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>
 
-<tt>bugpoint</tt> is designed to be a useful tool without requiring any
+</div>
+
+<!-- *********************************************************************** -->
+<div class="doc_section">
+<a name="design">Design Philosophy</a>
+</div>
+<!-- *********************************************************************** -->
+
+<div class="doc_text">
+
+<p><tt>bugpoint</tt> is designed to be a useful tool without requiring any
 hooks into the LLVM infrastructure at all.  It works with any and all LLVM
 passes and code generators, and does not need to "know" how they work.  Because
 of this, it may appear to do stupid things or miss obvious
@@ -36,47 +66,57 @@ time for computer time in the compiler-debugging process; consequently, it may
 take a long period of (unattended) time to reduce a test case, but we feel it
 is still worth it. Note that <tt>bugpoint</tt> is generally very quick unless
 debugging a miscompilation where each test of the program (which requires 
-executing it) takes a long time.<p>
+executing it) takes a long time.</p>
 
-<a name="automaticdebuggerselection">
-<h4>Automatic Debugger Selection</h4>
+</div>
 
-<tt>bugpoint</tt> reads each <tt>.bc</tt> or <tt>.ll</tt> file
-specified on the command line and links them together into a single module,
-called the test program.  If any LLVM passes are
-specified on the command line, it runs these passes on the test program.  If
-any of the passes crash, or if they produce malformed output (which causes the 
-verifier to abort),
-<tt>bugpoint</tt> starts the <a href="#crashdebug">crash debugger</a>.<p>
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+  <a name="autoselect">Automatic Debugger Selection</a>
+</div>
 
-Otherwise, if the <a href="#opt_output"><tt>-output</tt></a> option was not
-specified, <tt>bugpoint</tt> runs the test program with the C backend (which is
-assumed to generate good code) to generate a reference output.  Once
-<tt>bugpoint</tt> has a reference output for the test program, it tries
-executing it with the <a href="#opt_run-">selected</a> code generator.  If the
-selected code generator crashes, <tt>bugpoint</tt> starts the <a
-href="#crashdebug">crash debugger</a> on the code generator.  Otherwise, if the
-resulting output differs from the reference output, it assumes the difference
-resulted from a code generator failure, and starts the <a
-href="#codegendebug">code generator debugger</a>.<p>
+<div class="doc_text">
 
-Finally, if the output of the selected code generator matches the reference
+<p><tt>bugpoint</tt> reads each <tt>.bc</tt> or <tt>.ll</tt> file specified on
+the command line and links them together into a single module, called the test
+program.  If any LLVM passes are specified on the command line, it runs these
+passes on the test program.  If any of the passes crash, or if they produce
+malformed output (which causes the verifier to abort), <tt>bugpoint</tt> starts
+the <a href="#crashdebug">crash debugger</a>.</p>
+
+<p>Otherwise, if the <tt>-output</tt> option was not specified,
+<tt>bugpoint</tt> runs the test program with the C backend (which is assumed to
+generate good code) to generate a reference output.  Once <tt>bugpoint</tt> has
+a reference output for the test program, it tries executing it with the
+selected code generator.  If the selected code generator crashes,
+<tt>bugpoint</tt> starts the <a href="#crashdebug">crash debugger</a> on the
+code generator.  Otherwise, if the resulting output differs from the reference
+output, it assumes the difference resulted from a code generator failure, and
+starts the <a href="#codegendebug">code generator debugger</a>.</p>
+
+<p>Finally, if the output of the selected code generator matches the reference
 output, <tt>bugpoint</tt> runs the test program after all of the LLVM passes
 have been applied to it.  If its output differs from the reference output, it
 assumes the difference resulted from a failure in one of the LLVM passes, and
-enters the <a href="#miscompilationdebug">miscompilation
-debugger</a>. Otherwise, there is no problem <tt>bugpoint</tt> can debug.<p>
+enters the <a href="#miscompilationdebug">miscompilation debugger</a>.
+Otherwise, there is no problem <tt>bugpoint</tt> can debug.</p>
 
-<a name="crashdebug">
-<h4>Crash debugger</h4>
+</div>
 
-If an optimizer or code generator crashes, <tt>bugpoint</tt> will try as hard 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
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+  <a name="crashdebug">Crash debugger</a>
+</div>
+
+<div class="doc_text">
+
+<p>If an optimizer or code generator crashes, <tt>bugpoint</tt> will try as hard
+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>gccas</tt>, for example, because it runs over 38 passes.<p>
+exposed by <tt>gccas</tt>, for example, because it runs over 38 passes.</p>
 
-Next, <tt>bugpoint</tt> tries removing functions from the test program, to
+<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
 function, when debugging intraprocedural optimizations.  Once the number of
 functions has been reduced, it attempts to delete various edges in the control
@@ -84,38 +124,55 @@ 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><a href="CommandGuide/opt.html">opt</a></tt>, <tt><a
-href="CommandGuide/analyze.html">analyze</a></tt>, or <tt><a href="CommandGuide/llc.html">llc</a></tt>.<p>
+reproduce the failure with <tt>opt</tt>, <tt>analyze</tt>, or <tt>llc</tt>.</p>
 
-<a name="codegendebug">
-<h4>Code generator debugger</h4>
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+  <a name="codegendebug">Code generator debugger</a>
+</div>
+
+<div class="doc_text">
 
 <p>The code generator debugger attempts to narrow down the amount of code that
-is being miscompiled by the <a href="#opt_run-">selected</a> code generator.  To
-do this, it takes the test program and partitions it into two pieces: one piece
-which it compiles with the C backend (into a shared object), and one piece which
-it runs with either the JIT or the static LLC compiler.  It uses several
-techniques to reduce the amount of code pushed through the LLVM code generator,
-to reduce the potential scope of the problem.  After it is finished, it emits
-two bytecode files (called "test" [to be compiled with the code generator] and
-"safe" [to be compiled with the C backend], respectively), and instructions for
-reproducing the problem.  The code generator debugger assumes that the C backend
-produces good code.</p>
+is being miscompiled by the selected code generator.  To do this, it takes the
+test program and partitions it into two pieces: one piece which it compiles
+with the C backend (into a shared object), and one piece which it runs with
+either the JIT or the static LLC compiler.  It uses several techniques to
+reduce the amount of code pushed through the LLVM code generator, to reduce the
+potential scope of the problem.  After it is finished, it emits two bytecode
+files (called "test" [to be compiled with the code generator] and "safe" [to be
+compiled with the C backend], respectively), and instructions for reproducing
+the problem.  The code generator debugger assumes that the C backend produces
+good code.</p>
 
-<a name="miscompilationdebug">
-<h4>Miscompilation debugger</h4>
+</div>
 
-The miscompilation debugger works similarly to the code generator
-debugger.  It works by splitting the test program into two pieces, running the
-optimizations specified on one piece, linking the two pieces back together,
-and then executing the result.
-It attempts to narrow down the list of passes to the one (or few) which are
-causing the miscompilation, then reduce the portion of the test program which is
-being miscompiled.  The miscompilation debugger assumes that the selected
-code generator is working properly.<p>
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+  <a name="miscompilationdebug">Miscompilation debugger</a>
+</div>
 
-<a name="bugpoint notes">
-<h4>Advice for using <tt>bugpoint</tt></h4>
+<div class="doc_text">
+
+<p>The miscompilation debugger works similarly to the code generator debugger.
+It works by splitting the test program into two pieces, running the
+optimizations specified on one piece, linking the two pieces back together, and
+then executing the result.  It attempts to narrow down the list of passes to
+the one (or few) which are causing the miscompilation, then reduce the portion
+of the test program which is being miscompiled.  The miscompilation debugger
+assumes that the selected code generator is working properly.</p>
+
+</div>
+
+<!-- *********************************************************************** -->
+<div class="doc_section">
+  <a name="advice">Advice for using bugpoint</a>
+</div>
+<!-- *********************************************************************** -->
+
+<div class="doc_text">
 
 <tt>bugpoint</tt> can be a remarkably useful tool, but it sometimes works in
 non-obvious ways.  Here are some hints and tips:<p>
@@ -123,10 +180,10 @@ non-obvious ways.  Here are some hints and tips:<p>
 <ol>
 <li>In the code generator and miscompilation debuggers, <tt>bugpoint</tt> only
     works with programs that have deterministic output.  Thus, if the program
-    outputs <tt>argv[0]</tt>, the date, time, or any other "random" data, <tt>bugpoint</tt> may
-    misinterpret differences in these data, when output, as the result of a
-    miscompilation.  Programs should be temporarily modified to disable
-    outputs that are likely to vary from run to run.
+    outputs <tt>argv[0]</tt>, the date, time, or any other "random" data,
+    <tt>bugpoint</tt> may misinterpret differences in these data, when output,
+    as the result of a miscompilation.  Programs should be temporarily modified
+    to disable outputs that are likely to vary from run to run.
 
 <li>In the code generator and miscompilation debuggers, debugging will go
     faster if you manually modify the program or its inputs to reduce the
@@ -135,15 +192,19 @@ non-obvious ways.  Here are some hints and tips:<p>
 <li><tt>bugpoint</tt> is extremely useful when working on a new optimization:
     it helps track down regressions quickly.  To avoid having to relink
     <tt>bugpoint</tt> every time you change your optimization however, have
-    <tt>bugpoint</tt> dynamically load your optimization with the <a
-    href="#opt_load"><tt>-load</tt></a> option.
+    <tt>bugpoint</tt> dynamically load your optimization with the
+    <tt>-load</tt> option.
 
-<li><tt>bugpoint</tt> can generate a lot of output and run for a long period of
-    time.  It is often useful to capture the output of the program to file.  For
-    example, in the C shell, you can type:<br>
-    <tt>bugpoint  ..... |&amp; tee bugpoint.log</tt>
-    <br>to get a copy of <tt>bugpoint</tt>'s output in the file
-    <tt>bugpoint.log</tt>, as well as on your terminal.
+<li><p><tt>bugpoint</tt> can generate a lot of output and run for a long period
+    of time.  It is often useful to capture the output of the program to file.
+    For example, in the C shell, you can run:</p>
+
+<div class="doc_code">
+<p><tt>bugpoint  ... |&amp; tee bugpoint.log</tt></p>
+</div>
+
+    <p>to get a copy of <tt>bugpoint</tt>'s output in the file
+    <tt>bugpoint.log</tt>, as well as on your terminal.</p>
 
 <li><tt>bugpoint</tt> cannot debug problems with the LLVM linker. If
     <tt>bugpoint</tt> crashes before you see its "All input ok" message,
@@ -157,89 +218,21 @@ non-obvious ways.  Here are some hints and tips:<p>
     
 </ol>
 
-<h3>OPTIONS</h3>
+</div>
 
-<ul>
-	<li><tt>-additional-so &lt;library&gt;</tt><br>
-    Load <tt>&lt;library&gt;</tt> 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.<p>
+<!-- *********************************************************************** -->
 
-	<li><tt>-args &lt;program args&gt;</tt><br>
-	Pass all arguments specified after <tt>-args</tt> to the
-	test program whenever it runs.  Note that if any of
-	the <tt>&lt;program args&gt;</tt> start with a '-', you should use:
-        <p>
-        <tt>bugpoint &lt;bugpoint args&gt; -args -- &lt;program args&gt;</tt>
-        <p>
-        The "<tt>--</tt>" right after the <tt>-args</tt> option tells
-        <tt>bugpoint</tt> to consider any options starting with <tt>-</tt> to be
-        part of the <tt>-args</tt> option, not as options to <tt>bugpoint</tt>
-        itself.<p>
+<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>
 
-	<li><tt>-tool-args &lt;tool args&gt;</tt><br>
-	Pass all arguments specified after <tt>-tool-args</tt> to the
-	LLVM tool under test (llc, lli, etc.) whenever it runs.
-	You should use this option in the following way:
-        <p>
-        <tt>bugpoint &lt;bugpoint args&gt; -tool-args -- &lt;tool args&gt;</tt>
-        <p>
-        The "<tt>--</tt>" right after the <tt>-tool-args</tt> option tells
-        <tt>bugpoint</tt> to consider any options starting with <tt>-</tt> to be
-        part of the <tt>-tool-args</tt> option, not as options to
-        <tt>bugpoint</tt> itself. (See <tt>-args</tt>, above.)<p>
+  <a href="mailto:sabre@nondot.org">Chris Lattner</a><br>
+  <a href="http://llvm.cs.uiuc.edu">LLVM Compiler Infrastructure</a><br>
+  Last modified: $Date$
+</address>
 
-	<li><tt>-check-exit-code={true,false}</tt><br>
-    Assume a non-zero exit code or core dump from the test program is
-    a failure. Defaults to true.<p>
-
-	<li><tt>-disable-{dce,simplifycfg}</tt><br>
-    Do not run the specified passes to clean up and reduce the size of the
-    test program. By default, <tt>bugpoint</tt> uses these passes internally
-    when attempting to reduce test programs.  If you're trying to find
-    a bug in one of these passes, <tt>bugpoint</tt> may crash.<p>
-
-	<li> <tt>-help</tt><br>
-	Print a summary of command line options.<p>
-
-	<a name="opt_input"><li><tt>-input &lt;filename&gt;</tt><br>
-	Open <tt>&lt;filename&gt;</tt> and redirect the standard input of the
-    test program, whenever it runs, to come from that file.
-	<p>
-
-	<a name="opt_load"><li> <tt>-load &lt;plugin&gt;</tt><br>
-	Load the dynamic object <tt>&lt;plugin&gt;</tt> into <tt>bugpoint</tt>
-    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 -help and -load options together:
-	<p>
-	<tt>bugpoint -load &lt;plugin&gt; -help</tt>
-	<p>
-
-	<a name="opt_output"><li><tt>-output &lt;filename&gt;</tt><br>
-    Whenever the test program produces output on its standard output
-    stream, it should match the contents of <tt>&lt;filename&gt;</tt>
-    (the "reference output"). If you do not use this option,
-    <tt>bugpoint</tt> will attempt to generate a reference output by
-    compiling the program with the C backend and running it.<p>
-
-	<li><tt>-profile-info-file &lt;filename&gt;</tt><br>
-    Profile file loaded by -profile-loader.<p>
-
-	<a name="opt_run-"><li><tt>-run-{int,jit,llc,cbe}</tt><br>
-    Whenever the test program is compiled, <tt>bugpoint</tt> should generate
-    code for it 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.<p>
-</ul>
-
-<h3>EXIT STATUS</h3>
-
-If <tt>bugpoint</tt> succeeds in finding a problem, it will exit with 0.
-Otherwise, if an error occurs, it will exit with a non-zero value.
-
-<HR>
-Maintained by the <a href="http://llvm.cs.uiuc.edu">LLVM Team</a>.
 </body>
 </html>

llvm/docs/BytecodeFormat.html

@@ -1,6 +1,7 @@
 <!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 Bytecode File Format</title>
   <link rel="stylesheet" href="llvm.css" type="text/css">
   <style type="text/css">
@@ -39,11 +40,13 @@
       <li><a href="#functiondefs">Function Definition</a></li>
       <li><a href="#compactiontable">Compaction Table</a></li>
       <li><a href="#instructionlist">Instruction List</a></li>
+      <li><a href="#opcodes">Instruction Opcodes</a></li>
       <li><a href="#symtab">Symbol Table</a></li>
     </ol>
   </li>
   <li><a href="#versiondiffs">Version Differences</a>
     <ol>
+      <li><a href="#vers13">Version 1.3 Differences From 1.4</a></li>
       <li><a href="#vers12">Version 1.2 Differences From 1.3</a></li>
       <li><a href="#vers11">Version 1.1 Differences From 1.2</a></li>
       <li><a href="#vers10">Version 1.0 Differences From 1.1</a></li>
@@ -397,10 +400,9 @@ slot numbers with their "type plane". That is, Values of the same type
 are written to the bytecode file in a list (sequentially). Their order in 
 that list determines their slot number. This means that slot #1 doesn't mean
 anything unless you also specify for which type you want slot #1. Types are
-handled specially and are always written to the file first (in the <a
- href="#globaltypes">Global Type Pool</a>) and in such a way that both forward 
-and backward references of the types can often be resolved with a single pass 
-through the type pool. </p>
+always written to the file first (in the <a href="#globaltypes">Global Type 
+Pool</a>) and in such a way that both forward and backward references of the 
+types can often be resolved with a single pass through the type pool. </p>
 <p>Slot numbers are also kept small by rearranging their order. Because
 of the structure of LLVM, certain values are much more likely to be used
 frequently in the body of a function. For this reason, a compaction table is
@@ -409,6 +411,10 @@ smaller.  Suppose you have a function body that uses just the types "int*" and
 "{double}" but uses them thousands of time. Its worthwhile to ensure that the 
 slot number for these types are low so they can be encoded in a single byte 
 (via vbr). This is exactly what the compaction table does.</p>
+<p>In summary then, a slot number can be though of as just a vbr encoded index 
+into a list of Type* or Value*. To keep slot numbers low, Value* are indexed by
+two slot numbers: the "type plane index" (type slot) and the "value index"
+(value slot).</p>
 </div>
 <!-- *********************************************************************** -->
 <div class="doc_section"> <a name="general">General Structure</a> </div>
@@ -574,30 +580,57 @@ bytecode file. This block is always four bytes in length and differs from the
 other blocks because there is no identifier and no block length at the start
 of the block. Essentially, this block is just the "magic number" for the file.
 </p>
+<p>There are two types of signatures for LLVM bytecode: uncompressed and
+compressed as shown in the table below. </p>
 <table>
   <tbody>
     <tr>
       <th><b>Type</b></th>
-      <th class="td_left"><b>Field Description</b></th>
+      <th class="td_left"><b>Uncompressed</b></th>
+      <th class="td_left"><b>Compressed</b></th>
     </tr>
     <tr>
       <td><a href="#char">char</a></td>
       <td class="td_left">Constant "l" (0x6C)</td>
+      <td class="td_left">Constant "l" (0x6C)</td>
     </tr>
     <tr>
       <td><a href="#char">char</a></td>
       <td class="td_left">Constant "l" (0x6C)</td>
+      <td class="td_left">Constant "l" (0x6C)</td>
     </tr>
     <tr>
       <td><a href="#char">char</a></td>
       <td class="td_left">Constant "v" (0x76)</td>
+      <td class="td_left">Constant "v" (0x76)</td>
     </tr>
     <tr>
       <td><a href="#char">char</a></td>
       <td class="td_left">Constant "m" (0x6D)</td>
+      <td class="td_left">Constant "c" (0x63)</td>
+    </tr>
+    <tr>
+      <td><a href="#char">char</a></td>
+      <td class="td_left">N/A</td>
+      <td class="td_left">'0'=null,'1'=gzip,'2'=bzip2</td>
     </tr>
   </tbody>
 </table>
+<p>In other words, the uncompressed signature is just the characters 'llvm'
+while the compressed signature is the characters 'llvc' followed by an ascii
+digit ('0', '1', or '2') that indicates the kind of compression used. A value of
+'0' indicates that null compression was used. This can happen when compression
+was requested on a platform that wasn't configured for gzip or bzip2. A value of
+'1' means that the rest of the file is compressed using the gzip algorithm and
+should be uncompressed before interpretation. A value of '2' means that the rest
+of the file is compressed using the bzip2 algorithm and should be uncompressed
+before interpretation. In all cases, the data resulting from uncompression
+should be interpreted as if it occurred immediately after the 'llvm'
+signature (i.e. the uncompressed data begins with the 
+<a href="#module">Module Block</a></p>
+<p><b>NOTE:</b> As of LLVM 1.4, all bytecode files produced by the LLVM tools
+are compressed by default. To disable compression, pass the 
+<tt>--disable-compression</tt> option to the tool, if it supports it.
 </div>
 <!-- _______________________________________________________________________ -->
 <div class="doc_subsection"><a name="module">Module Block</a> </div>
@@ -614,10 +647,13 @@ sections.</p>
       <th class="td_left"><b>Field Description</b></th>
     </tr>
     <tr>
-      <td><a href="#block">block</a><br>
-      </td>
-      <td class="td_left">Module Block Identifier (0x01) and Size<br>
-      </td>
+      <td><a href="#unsigned">unsigned</a><br></td>
+      <td class="td_left"><a href="#mod_header">Module Block Identifier
+          (0x01)</a></td>
+    </tr>
+    <tr>
+      <td><a href="#unsigned">unsigned</a></td>
+      <td class="td_left"><a href="#mod_header">Module Block Size</a></td>
     </tr>
     <tr>
       <td><a href="#uint32_vbr">uint32_vbr</a></td>
@@ -641,11 +677,26 @@ sections.</p>
     </tr>
     <tr>
       <td><a href="#block">block</a></td>
-      <td class="td_left"><a href="#symboltable">Module Symbol Table</a></td>
+      <td class="td_left"><a href="#symtab">Module Symbol Table</a></td>
     </tr>
   </tbody>
 </table>
 </div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection"><a name="mod_header">Module Block Header</a></div>
+<div class="doc_text">
+  <p>The block header for the module block uses a longer format than the other
+  blocks in a bytecode file. Specifically, instead of encoding the type and size
+  of the block into a 32-bit integer with 5-bits for type and 27-bits for size,
+  the module block header uses two 32-bit unsigned values, one for type, and one
+  for size. While the 2<sup>27</sup> byte limit on block size is sufficient for the blocks
+  contained in the module, it isn't sufficient for the module block itself
+  because we want to ensure that bytecode files as large as 2<sup>32</sup> bytes
+  are possible. For this reason, the module block (and only the module block)
+  uses a long format header.</p>
+</div>
+
 <!-- _______________________________________________________________________ -->
 <div class="doc_subsubsection"><a name="format">Format Information</a></div>
 <div class="doc_text">
@@ -702,7 +753,7 @@ triples</a>.
 <div class="doc_subsection"><a name="globaltypes">Global Type Pool</a> </div>
 <div class="doc_text">
 <p>The global type pool consists of type definitions. Their order of appearance
-in the file determines their slot number (0 based). Slot numbers are
+in the file determines their type slot number (0 based). Slot numbers are
 used to replace pointers in the intermediate representation. Each slot number 
 uniquely identifies one entry in a type plane (a collection of values of the
 same type).  Since all values have types and are associated with the order in 
@@ -736,7 +787,7 @@ table below.</p>
 of type, as given in the following sections.</p>
 <h3>Primitive Types</h3>
 <p>The primitive types encompass the basic integer and floating point
-types</p>
+types. They are encoded simply as their TypeID.</p>
 <table>
   <tbody>
     <tr>
@@ -784,11 +835,11 @@ following mapping:
     </tr>
     <tr>
       <td><a href="#uint24_vbr">uint24_vbr</a></td>
-      <td class="td_left">Slot number of function's return type.</td>
+      <td class="td_left">Type slot number of function's return type.</td>
     </tr>
     <tr>
       <td><a href="#llist">llist</a>(<a href="#uint24_vbr">uint24_vbr</a>)</td>
-      <td class="td_left">Slot number of each argument's type.</td>
+      <td class="td_left">Type slot number of each argument's type.</td>
     </tr>
     <tr>
       <td><a href="#uint32_vbr">uint32_vbr</a>?</td>
@@ -827,7 +878,7 @@ missing otherwise.</td>
     </tr>
     <tr>
       <td><a href="#uint24_vbr">uint24_vbr</a></td>
-      <td class="td_left">Slot number of array's element type.</td>
+      <td class="td_left">Type slot number of array's element type.</td>
     </tr>
     <tr>
       <td><a href="#uint32_vbr">uint32_vbr</a></td>
@@ -848,7 +899,7 @@ missing otherwise.</td>
     </tr>
     <tr>
       <td><a href="#uint24_vbr">uint24_vbr</a></td>
-      <td class="td_left">Slot number of pointer's element type.</td>
+      <td class="td_left">Type slot number of pointer's element type.</td>
     </tr>
   </tbody>
 </table>
@@ -865,6 +916,27 @@ missing otherwise.</td>
     </tr>
   </tbody>
 </table>
+<h3>Packed Types</h3>
+<table>
+  <tbody>
+    <tr>
+      <th><b>Type</b></th>
+      <th class="td_left"><b>Description</b></th>
+    </tr>
+    <tr>
+      <td><a href="#uint24_vbr">uint24_vbr</a></td>
+      <td class="td_left">Type ID for Packed Types (18)</td>
+    </tr>
+    <tr>
+      <td><a href="#uint24_vbr">uint24_vbr</a></td>
+      <td class="td_left">Slot number of packed vector's element type.</td>
+    </tr>
+    <tr>
+      <td><a href="#uint32_vbr">uint32_vbr</a></td>
+      <td class="td_left">The number of elements in the packed vector.</td>
+    </tr>
+  </tbody>
+</table>
 </div>
 <!-- _______________________________________________________________________ -->
 <div class="doc_subsection"><a name="globalinfo">Module Global Info</a>
@@ -887,12 +959,12 @@ all functions. The format is shown in the table below:</p>
     <tr>
       <td><a href="#zlist">zlist</a>(<a href="#globalvar">globalvar</a>)</td>
       <td class="td_left">A zero terminated list of global var
-definitions occuring in the module.</td>
+definitions occurring in the module.</td>
     </tr>
     <tr>
-      <td><a href="#zlist">zlist</a>(<a href="#uint24_vbr">uint24_vbr</a>)</td>
-      <td class="td_left">A zero terminated list of function types
-occuring in the module.</td>
+      <td><a href="#zlist">zlist</a>(<a href="#funcfield">funcfield</a>)</td>
+      <td class="td_left">A zero terminated list of function definitions
+occurring in the module.</td>
     </tr>
     <tr>
       <td style="vertical-align: top;"><a href="#llist">llist</a>(<a
@@ -914,6 +986,7 @@ platform independent module).<br>
   </tbody>
 </table>
 </div>
+
 <!-- _______________________________________________________________________ -->
 <div class="doc_subsubsection"><a name="globalvar">Global Variable Field</a>
 </div>
@@ -946,7 +1019,7 @@ follows. </td>
     </tr>
     <tr>
       <td><a href="#bit">bit(5-31)</a></td>
-      <td class="td_left">Slot number of type for the global variable.</td>
+      <td class="td_left">Type slot number of type for the global variable.</td>
     </tr>
   </tbody>
 </table>
@@ -961,12 +1034,52 @@ the global variable field, if it has one.</p>
     <tr>
       <td>(<a href="#zlist">zlist</a>(<a href="#uint32_vbr">uint32_vbr</a>))?
       </td>
-      <td class="td_left">An optional zero-terminated list of slot
+      <td class="td_left">An optional zero-terminated list of value slot
 numbers of the global variable's constant initializer.</td>
     </tr>
   </tbody>
 </table>
 </div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection"><a name="funcfield">Function Field</a>
+</div>
+<div class="doc_text">
+<p>Functions are written using an <a href="#uint32_vbr">uint32_vbr</a>
+that encodes information about the function and a set of flags.</p>
+
+<p>The table below provides the bit layout of the <a
+href="#uint32_vbr">uint32_vbr</a> that describes the function.</p>
+
+<table>
+  <tbody>
+    <tr>
+      <th><b>Type</b></th>
+      <th class="td_left"><b>Description</b></th>
+    </tr>
+    <tr>
+      <td><a href="#bit">bit(0-3)</a></td>
+      <td class="td_left">
+      Encodes the calling convention number of the function.  If this number is
+      zero, this field is followed by a vbr indicating the CC#.  Otherwise, the
+      CC number of the function is the value of this field minus one.
+      </td>
+    </tr>
+    <tr>
+      <td><a href="#bit">bit(4)</a></td>
+      <td class="td_left">If this bit is set to 1, the indicated function is
+      external, and there is no <a href="#functiondefs">Function Definiton
+      Block</a> in the bytecode file for the function.</td>
+    </tr>
+    <tr>
+      <td><a href="#bit">bit(5-)</a></td>
+      <td class="td_left">Type slot number of type for the function.</td>
+    </tr>
+  </tbody>
+</table>
+
+</div>
+
 <!-- _______________________________________________________________________ -->
 <div class="doc_subsection"><a name="constantpool">Constant Pool</a> </div>
 <div class="doc_text">
@@ -1011,7 +1124,7 @@ uniquely from other constant planes that follow. </td>
     </tr>
     <tr>
       <td><a href="#uint24_vbr">uint24_vbr</a>+</td>
-      <td class="td_left">Slot number of the constant string's type.
+      <td class="td_left">Type slot number of the constant string's type.
 Note that the constant string's type implicitly defines the length of
 the string. </td>
     </tr>
@@ -1046,7 +1159,7 @@ for the details. </p>
 <!-- _______________________________________________________________________ -->
 <div class="doc_subsubsection"><a name="constant">Constant Field</a></div>
 <div class="doc_text">
-<p>Constants come in many shapes and flavors. The sections that followe
+<p>Constants come in many shapes and flavors. The sections that follow
 define the format for each of them. All constants start with a <a
  href="#uint32_vbr">uint32_vbr</a> encoded integer that provides the
 number of operands for the constant. For primitive, structure, and
@@ -1064,14 +1177,19 @@ corresponding value. </li>
   <li><b>Floating Point</b>. Both the float and double types are
 written literally in binary format.</li>
   <li><b>Arrays</b>. Arrays are written simply as a list of <a
- href="#uint32_vbr">uint32_vbr</a> encoded slot numbers to the constant
+ href="#uint32_vbr">uint32_vbr</a> encoded value slot numbers to the constant
 element values.</li>
   <li><b>Structures</b>. Structures are written simply as a list of <a
- href="#uint32_vbr">uint32_vbr</a> encoded slot numbers to the constant
+ href="#uint32_vbr">uint32_vbr</a> encoded value slot numbers to the constant
 field values of the structure.</li>
 </ul>
-<p>When the number of operands to the constant is non-zero, we have a
-constant expression and its field format is provided in the table below.</p>
+
+<p>When the number of operands to the constant is one, we have an 'undef' value
+of the specified type.</p>
+
+<p>When the number of operands to the constant is greater than one, we have a
+constant expression and its field format is provided in the table below, and the
+number is equal to the number of operands+1.</p>
 <table>
   <tbody>
     <tr>
@@ -1085,12 +1203,12 @@ expression.</td>
     </tr>
     <tr>
       <td><a href="#uint32_vbr">uint32_vbr</a></td>
-      <td class="td_left">The slot number of the constant value for an
+      <td class="td_left">The value slot number of the constant value for an
 operand.<sup>1</sup></td>
     </tr>
     <tr>
       <td><a href="#uint24_vbr">uint24_vbr</a></td>
-      <td class="td_left">The slot number for the type of the constant
+      <td class="td_left">The type slot number for the type of the constant
 value for an operand.<sup>1</sup></td>
     </tr>
   </tbody>
@@ -1141,7 +1259,7 @@ list</a> for the function.</td>
     </tr>
     <tr>
       <td><a href="#block">block</a></td>
-      <td class="td_left">The function's <a href="#symboltable">symbol
+      <td class="td_left">The function's <a href="#symtab">symbol
 table</a> containing only those symbols pertinent to the function
 (mostly block labels).</td>
     </tr>
@@ -1162,7 +1280,7 @@ save bytecode space. If not, then a regular constant pool is written.</li>
 <div class="doc_text">
 <p>Compaction tables are part of a function definition. They are merely
 a device for reducing the size of bytecode files. The size of a
-bytecode file is dependent on the <em>value</em> of the slot numbers
+bytecode file is dependent on the <em>values</em> of the slot numbers
 used because larger values use more bytes in the variable bit rate
 encoding scheme. Furthermore, the compressed instruction format
 reserves only six bits for the type of the instruction. In large
@@ -1185,7 +1303,7 @@ both. Compaction tables have the format shown in the table below.</p>
     </tr>
     <tr>
       <td><a href="#uint24_vbr">uint24_vbr</a>+</td>
-      <td class="td_left">The slot number in the global type plane of
+      <td class="td_left">The type slot number in the global types of
 the type that will be referenced in the function with the index of this
 entry in the compaction table.</td>
     </tr>
@@ -1198,9 +1316,9 @@ details.</td>
     </tr>
     <tr>
       <td><a href="#uint32_vbr">uint32_vbr</a>+</td>
-      <td class="td_left">The slot number in the globals of the value
+      <td class="td_left">The value slot number in the global values
 that will be referenced in the function with the index of this entry in
-the compaction table</td>
+the compaction table.</td>
     </tr>
   </tbody>
 </table>
@@ -1218,8 +1336,7 @@ encoding uses a <a href="#uint32_vbr">uint32_vbr</a> for each of the
 length and type, in that order.</p>
 </div>
 <!-- _______________________________________________________________________ -->
-<div class="doc_subsection"><a name="instructionlist">Instruction List</a>
-</div>
+<div class="doc_subsection"><a name="instructionlist">Instruction List</a></div>
 <div class="doc_text">
 <p>The instructions in a function are written as a simple list. Basic
 blocks are inferred by the terminating instruction types. The format of
@@ -1251,11 +1368,11 @@ of formats. See <a href="#instruction">Instructions</a> for details.</td>
 depending on the number of operands to the instruction. Each
 instruction begins with a <a href="#uint32_vbr">uint32_vbr</a> that
 encodes the type of the instruction as well as other things. The tables
-that follow describe the format of this first word of each instruction.</p>
+that follow describe the format of this first part of each instruction.</p>
 <p><b>Instruction Format 0</b></p>
 <p>This format is used for a few instructions that can't easily be
-optimized because they have large numbers of operands (e.g. PHI Node or
-getelementptr). Each of the opcode, type, and operand fields is as
+shortened because they have large numbers of operands (e.g. PHI Node or
+getelementptr). Each of the opcode, type, and operand fields is found in
 successive fields.</p>
 <table>
   <tbody>
@@ -1272,8 +1389,8 @@ format.</td>
     </tr>
     <tr>
       <td><a href="#uint24_vbr">uint24_vbr</a></td>
-      <td class="td_left">Provides the slot number of the result type
-of the instruction</td>
+      <td class="td_left">Provides the type slot number of the result type of
+        the instruction.</td>
     </tr>
     <tr>
       <td><a href="#uint32_vbr">uint32_vbr</a></td>
@@ -1281,8 +1398,8 @@ of the instruction</td>
     </tr>
     <tr>
       <td><a href="#uint32_vbr">uint32_vbr</a>+</td>
-      <td class="td_left">The slot number of the value(s) for the
-operand(s). <sup>1</sup></td>
+      <td class="td_left">The slot number of the value(s) for the operand(s).
+        <sup>1</sup></td>
     </tr>
   </tbody>
 </table>
@@ -1306,27 +1423,27 @@ single <a href="#uint32_vbr">uint32_vbr</a> as follows:</p>
     <tr>
       <td>0-1</td>
       <td>constant "1"</td>
-      <td class="td_left">These two bits must be the value 1 which
-identifies this as an instruction of format 1.</td>
+      <td class="td_left">These two bits must be the value 1 which identifies 
+        this as an instruction of format 1.</td>
     </tr>
     <tr>
       <td>2-7</td>
-      <td><a href="#opcodes">opcode</a></td>
-      <td class="td_left">Specifies the opcode of the instruction. Note
-that the maximum opcode value is 63.</td>
+      <td><a href="#opcode">opcode</a></td>
+      <td class="td_left">Specifies the opcode of the instruction. Note that 
+        the maximum opcode value is 63.</td>
     </tr>
     <tr>
       <td>8-19</td>
       <td><a href="#unsigned">unsigned</a></td>
-      <td class="td_left">Specifies the slot number of the type for
-this instruction. Maximum slot number is 2<sup>12</sup>-1=4095.</td>
+      <td class="td_left">Specifies the slot number of the type for this 
+        instruction. Maximum slot number is 2<sup>12</sup>-1=4095.</td>
     </tr>
     <tr>
       <td>20-31</td>
       <td><a href="#unsigned">unsigned</a></td>
-      <td class="td_left">Specifies the slot number of the value for
-the first operand. Maximum slot number is 2<sup>12</sup>-1=4095. Note
-that the value 2<sup>12</sup>-1 denotes zero operands.</td>
+      <td class="td_left">Specifies the slot number of the value for the 
+        first operand. Maximum slot number is 2<sup>12</sup>-1=4095. Note that 
+        the value 2<sup>12</sup>-1 denotes zero operands.</td>
     </tr>
   </tbody>
 </table>
@@ -1343,32 +1460,32 @@ that the value 2<sup>12</sup>-1 denotes zero operands.</td>
     <tr>
       <td>0-1</td>
       <td>constant "2"</td>
-      <td class="td_left">These two bits must be the value 2 which
-identifies this as an instruction of format 2.</td>
+      <td class="td_left">These two bits must be the value 2 which identifies 
+        this as an instruction of format 2.</td>
     </tr>
     <tr>
       <td>2-7</td>
       <td><a href="#opcodes">opcode</a></td>
-      <td class="td_left">Specifies the opcode of the instruction. Note
-that the maximum opcode value is 63.</td>
+      <td class="td_left">Specifies the opcode of the instruction. Note that 
+        the maximum opcode value is 63.</td>
     </tr>
     <tr>
       <td>8-15</td>
       <td><a href="#unsigned">unsigned</a></td>
-      <td class="td_left">Specifies the slot number of the type for
-this instruction. Maximum slot number is 2<sup>8</sup>-1=255.</td>
+      <td class="td_left">Specifies the slot number of the type for this 
+        instruction. Maximum slot number is 2<sup>8</sup>-1=255.</td>
     </tr>
     <tr>
       <td>16-23</td>
       <td><a href="#unsigned">unsigned</a></td>
-      <td class="td_left">Specifies the slot number of the value for
-the first operand. Maximum slot number is 2<sup>8</sup>-1=255.</td>
+      <td class="td_left">Specifies the slot number of the value for the first 
+        operand. Maximum slot number is 2<sup>8</sup>-1=255.</td>
     </tr>
     <tr>
       <td>24-31</td>
       <td><a href="#unsigned">unsigned</a></td>
-      <td class="td_left">Specifies the slot number of the value for
-the second operand. Maximum slot number is 2<sup>8</sup>-1=255.</td>
+      <td class="td_left">Specifies the slot number of the value for the second 
+        operand. Maximum slot number is 2<sup>8</sup>-1=255.</td>
     </tr>
   </tbody>
 </table>
@@ -1385,51 +1502,154 @@ single <a href="#uint32_vbr">uint32_vbr</a> as follows:</p>
     <tr>
       <td>0-1</td>
       <td>constant "3"</td>
-      <td class="td_left">These two bits must be the value 3 which
-identifies this as an instruction of format 3.</td>
+      <td class="td_left">These two bits must be the value 3 which identifies 
+        this as an instruction of format 3.</td>
     </tr>
     <tr>
       <td>2-7</td>
       <td><a href="#opcodes">opcode</a></td>
-      <td class="td_left">Specifies the opcode of the instruction. Note
-that the maximum opcode value is 63.</td>
+      <td class="td_left">Specifies the opcode of the instruction. Note that 
+        the maximum opcode value is 63.</td>
     </tr>
     <tr>
       <td>8-13</td>
       <td><a href="#unsigned">unsigned</a></td>
-      <td class="td_left">Specifies the slot number of the type for
-this instruction. Maximum slot number is 2<sup>6</sup>-1=63.</td>
+      <td class="td_left">Specifies the slot number of the type for this 
+        instruction. Maximum slot number is 2<sup>6</sup>-1=63.</td>
     </tr>
     <tr>
       <td>14-19</td>
       <td><a href="#unsigned">unsigned</a></td>
-      <td class="td_left">Specifies the slot number of the value for
-the first operand. Maximum slot number is 2<sup>6</sup>-1=63.</td>
+      <td class="td_left">Specifies the slot number of the value for the first 
+        operand. Maximum slot number is 2<sup>6</sup>-1=63.</td>
     </tr>
     <tr>
       <td>20-25</td>
       <td><a href="#unsigned">unsigned</a></td>
-      <td class="td_left">Specifies the slot number of the value for
-the second operand. Maximum slot number is 2<sup>6</sup>-1=63.</td>
+      <td class="td_left">Specifies the slot number of the value for the second
+        operand. Maximum slot number is 2<sup>6</sup>-1=63.</td>
     </tr>
     <tr>
       <td>26-31</td>
       <td><a href="#unsigned">unsigned</a></td>
-      <td class="td_left">Specifies the slot number of the value for
-the third operand. Maximum slot number is 2<sup>6</sup>-1=63.</td>
+      <td class="td_left">Specifies the slot number of the value for the third
+        operand. Maximum slot number is 2<sup>6</sup>-1=63.</td>
     </tr>
   </tbody>
 </table>
 </div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"><a name="opcodes">Instruction Opcodes</a></div>
+<div class="doc_text">
+  <p>Instructions encode an opcode that identifies the kind of instruction.
+  Opcodes are an enumerated integer value. The specific values used depend on
+  the version of LLVM you're using. The opcode values are defined in the
+  <a href="http://llvm.cs.uiuc.edu/cvsweb/cvsweb.cgi/llvm/include/llvm/Instruction.def">
+  <tt>include/llvm/Instruction.def</tt></a> file. You should check there for the
+  most recent definitions. The table below provides the opcodes defined as of
+  the writing of this document. The table associates each opcode mnemonic with
+  its enumeration value and the bytecode and LLVM version numbers in which the
+  opcode was introduced.</p>
+  <table>
+    <tbody>
+      <tr>
+        <th>Opcode</th>
+        <th>Number</th>
+        <th>Bytecode Version</th>
+        <th>LLVM Version</th>
+      </tr>
+      <tr><td colspan="4"><b>Terminator Instructions</b></td></tr>
+      <tr><td>Ret</td><td>1</td><td>1</td><td>1.0</td></tr>
+      <tr><td>Br</td><td>2</td><td>1</td><td>1.0</td></tr>
+      <tr><td>Switch</td><td>3</td><td>1</td><td>1.0</td></tr>
+      <tr><td>Invoke</td><td>4</td><td>1</td><td>1.0</td></tr>
+      <tr><td>Unwind</td><td>5</td><td>1</td><td>1.0</td></tr>
+      <tr><td>Unreachable</td><td>6</td><td>1</td><td>1.4</td></tr>
+      <tr><td colspan="4"><b>Binary Operators</b></td></tr>
+      <tr><td>Add</td><td>7</td><td>1</td><td>1.0</td></tr>
+      <tr><td>Sub</td><td>8</td><td>1</td><td>1.0</td></tr>
+      <tr><td>Mul</td><td>9</td><td>1</td><td>1.0</td></tr>
+      <tr><td>Div</td><td>10</td><td>1</td><td>1.0</td></tr>
+      <tr><td>Rem</td><td>11</td><td>1</td><td>1.0</td></tr>
+      <tr><td colspan="4"><b>Logical Operators</b></td></tr>
+      <tr><td>And</td><td>12</td><td>1</td><td>1.0</td></tr>
+      <tr><td>Or</td><td>13</td><td>1</td><td>1.0</td></tr>
+      <tr><td>Xor</td><td>14</td><td>1</td><td>1.0</td></tr>
+      <tr><td colspan="4"><b>Binary Comparison Operators</b></td></tr>
+      <tr><td>SetEQ</td><td>15</td><td>1</td><td>1.0</td></tr>
+      <tr><td>SetNE</td><td>16</td><td>1</td><td>1.0</td></tr>
+      <tr><td>SetLE</td><td>17</td><td>1</td><td>1.0</td></tr>
+      <tr><td>SetGE</td><td>18</td><td>1</td><td>1.0</td></tr>
+      <tr><td>SetLT</td><td>19</td><td>1</td><td>1.0</td></tr>
+      <tr><td>SetGT</td><td>20</td><td>1</td><td>1.0</td></tr>
+      <tr><td colspan="4"><b>Memory Operators</b></td></tr>
+      <tr><td>Malloc</td><td>21</td><td>1</td><td>1.0</td></tr>
+      <tr><td>Free</td><td>22</td><td>1</td><td>1.0</td></tr>
+      <tr><td>Alloca</td><td>23</td><td>1</td><td>1.0</td></tr>
+      <tr><td>Load</td><td>24</td><td>1</td><td>1.0</td></tr>
+      <tr><td>Store</td><td>25</td><td>1</td><td>1.0</td></tr>
+      <tr><td>GetElementPtr</td><td>26</td><td>1</td><td>1.0</td></tr>
+      <tr><td colspan="4"><b>Other Operators</b></td></tr>
+      <tr><td>PHI</td><td>27</td><td>1</td><td>1.0</td></tr>
+      <tr><td>Cast</td><td>28</td><td>1</td><td>1.0</td></tr>
+      <tr><td>Call</td><td>29</td><td>1</td><td>1.0</td></tr>
+      <tr><td>Shl</td><td>30</td><td>1</td><td>1.0</td></tr>
+      <tr><td>Shr</td><td>31</td><td>1</td><td>1.0</td></tr>
+      <tr><td>VANext</td><td>32</td><td>1</td><td>1.0</td></tr>
+      <tr><td>VAArg</td><td>33</td><td>1</td><td>1.0</td></tr>
+      <tr><td>Select</td><td>34</td><td>2</td><td>1.2</td></tr>
+      <tr><td colspan="4">
+          <b>Pseudo Instructions<a href="#pi_note">*</a></b>
+      </td></tr>
+      <tr><td>Invoke+CC </td><td>56</td><td>5</td><td>1.5</td></tr>
+      <tr><td>Invoke+FastCC</td><td>57</td><td>5</td><td>1.5</td></tr>
+      <tr><td>Call+CC</td><td>58</td><td>5</td><td>1.5</td></tr>
+      <tr><td>Call+FastCC+TailCall</td><td>59</td><td>5</td><td>1.5</td></tr>
+      <tr><td>Call+FastCC</td><td>60</td><td>5</td><td>1.5</td></tr>
+      <tr><td>Call+CCC+TailCall</td><td>61</td><td>5</td><td>1.5</td></tr>
+      <tr><td>Load+Volatile</td><td>62</td><td>3</td><td>1.3</td></tr>
+      <tr><td>Store+Volatile</td><td>63</td><td>3</td><td>1.3</td></tr>
+    </tbody>
+  </table>
+</div>
+
+<p><b><a name="pi_note">* Note: </a></b>
+These aren't really opcodes from an LLVM language prespeective. They encode
+information into other opcodes without reserving space for that information. 
+For example, opcode=63 is a Volatile Store. The opcode for this
+instruction is 25 (Store) but we encode it as 63 to indicate that is a Volatile
+Store. The same is done for the calling conventions and tail calls.
+In each of these entries in range 56-63, the opcode is documented as the base
+opcode (Invoke, Call, Store) plus some set of modifiers, as follows:</p>
+<dl>
+  <dt>CC</dt>
+  <dd>This means an arbitrary calling convention is specified
+  in a VBR that follows the opcode. This is used when the instruction cannot
+  be encoded with one of the more compact forms.
+  </dd>
+  <dt>FastCC</dt>
+  <dd>This indicates that the Call or Invoke is using the FastCC calling 
+  convention.</dd>
+  <dt>CCC</dt>
+  <dd>This indicates that the Call or Invoke is using the native "C" calling 
+  convention.</dd>
+  <dt>TailCall</dt>
+  <dd>This indicates that the Call has the 'tail' modifier.</dd>
+</dl>
+
 <!-- _______________________________________________________________________ -->
 <div class="doc_subsection"><a name="symtab">Symbol Table</a> </div>
 <div class="doc_text">
-<p>A symbol table can be put out in conjunction with a module or a function.
-A symbol table is a list of type planes. Each type plane starts with the number
-of entries in the plane and the type plane's slot number (so the type
-can be looked up in the global type pool). For each entry in a type
-plane, the slot number of the value and the name associated with that
-value are written. The format is given in the table below. </p>
+<p>A symbol table can be put out in conjunction with a module or a function. A
+symbol table has a list of name/type associations followed by a list of
+name/value associations. The name/value associations are organized into "type
+planes" so that all values of a common type are listed together.  Each type 
+plane starts with the number of entries in the plane and the type slot number
+for all the values in that plane (so the type can be looked up in the global 
+type pool). For each entry in a type plane, the slot number of the value and 
+the name associated with that value are written. The format is given in the 
+table below. </p>
 <table>
   <tbody>
     <tr>
@@ -1441,19 +1661,48 @@ value are written. The format is given in the table below. </p>
       </td>
       <td class="td_left">Symbol Table Identifier (0x04)</td>
     </tr>
+    <tr>
+      <td><a href="#llist">llist</a>(<a href="#symtab_entry">type_entry</a>)</td>
+      <td class="td_left">A length list of symbol table entries for
+        <tt>Type</tt>s
+      </td>
+    </tr>
+    <tr>
+      <td><a href="#zlist">llist</a>(<a href="#symtab_plane">symtab_plane</a>)</td>
+      <td class="td_left">A length list of "type planes" of symbol table
+        entries for <tt>Value</tt>s</td>
+    </tr>
+  </tbody>
+</table>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection"> <a name="type_entry">Symbol Table Type
+Entry</a>
+</div>
+<div class="doc_text">
+<p>A symbol table type entry associates a name with a type. The name is provided
+simply as an array of chars. The type is provided as a type slot number (index)
+into the global type pool. The format is given in the following table:</p>
+<table>
+  <tbody>
+    <tr>
+      <th><b>Type</b></th>
+      <th class="td_left"><b>Field Description</b></th>
+    </tr>
+    <tr>
+      <td><a href="#uint32_vbr">uint24_vbr</a></td>
+      <td class="td_left">Type slot number of the type being given a
+        name relative to the global type pool.
+      </td>
+    </tr>
     <tr>
       <td><a href="#uint32_vbr">uint32_vbr</a></td>
-      <td class="td_left">Number of entries in type plane</td>
+      <td class="td_left">Length of the character array that follows.</td>
     </tr>
     <tr>
-      <td><a href="#symtab_entry">symtab_entry</a>*</td>
-      <td class="td_left">Provides the slot number of the type and its
-name.</td>
-    </tr>
-    <tr>
-      <td><a href="#symtab_plane">symtab_plane</a>*</td>
-      <td class="td_left">A type plane containing value slot number and
-name for all values of the same type.</td>
+      <td><a href="#char">char</a>+</td>
+      <td class="td_left">The characters of the name.</td>
     </tr>
   </tbody>
 </table>
@@ -1477,22 +1726,23 @@ values of a common type. The encoding is given in the following table:</p>
     </tr>
     <tr>
       <td><a href="#uint32_vbr">uint32_vbr</a></td>
-      <td class="td_left">Slot number of type for this plane.</td>
+      <td class="td_left">Type slot number of type for all values in this plane..</td>
     </tr>
     <tr>
-      <td><a href="#symtab_entry">symtab_entry</a>+</td>
-      <td class="td_left">The symbol table entries for this plane.</td>
+      <td><a href="#value_entry">value_entry</a>+</td>
+      <td class="td_left">The symbol table entries for to associate values with
+        names.</td>
     </tr>
   </tbody>
 </table>
 </div>
 <!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"> <a name="symtab_entry">Symbol Table
+<div class="doc_subsubsection"><a name="value_entry">Symbol Table Value
 Entry</a>
 </div>
 <div class="doc_text">
-<p>A symbol table entry provides the assocation between a type or
-value's slot number and the name given to that type or value. The
+<p>A symbol table value entry provides the assocation between a value and the
+name given to the value. The value is referenced by its slot number. The
 format is given in the following table:</p>
 <table>
   <tbody>
@@ -1502,8 +1752,8 @@ format is given in the following table:</p>
     </tr>
     <tr>
       <td><a href="#uint32_vbr">uint24_vbr</a></td>
-      <td class="td_left">Slot number of the type or value being given
-a name. </td>
+      <td class="td_left">Value slot number of the value being given a name.
+      </td>
     </tr>
     <tr>
       <td><a href="#uint32_vbr">uint32_vbr</a></td>
@@ -1516,6 +1766,7 @@ a name. </td>
   </tbody>
 </table>
 </div>
+
 <!-- *********************************************************************** -->
 <div class="doc_section"> <a name="versiondiffs">Version Differences</a>
 </div>
@@ -1529,10 +1780,64 @@ section here
 describes the differences between that version and the one that <i>follows</i>.
 </p>
 </div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"><a name="vers13">Version 1.3 Differences From 
+    1.4</a></div>
+<!-- _______________________________________________________________________ -->
+
+<div class="doc_subsubsection">Unreachable Instruction</div>
+<div class="doc_text">
+  <p>The LLVM <a href="LangRef.html#i_unreachable">Unreachable</a> instruction
+  was added in version 1.4 of LLVM.  This caused all instruction numbers after
+  it to shift down by one.</p>
+</div>
+
+<div class="doc_subsubsection">Function Flags</div>
+<div class="doc_text">
+  <p>LLVM bytecode versions prior to 1.4 did not include the 5 bit offset 
+     in <a href="#funcfield">the function list</a> in the <a
+     href="#globalinfo">Module Global Info</a> block.</p>
+</div>
+
+<div class="doc_subsubsection">Function Flags</div>
+<div class="doc_text">
+  <p>LLVM bytecode versions prior to 1.4 did not include the 'undef' constant
+     value, which affects the encoding of <a href="#constant">Constant
+     Fields</a>.</p>
+</div>
+
+<!--
+<div class="doc_subsubsection">Aligned Data</div>
+<div class="doc_text">
+  <p>In version 1.3, certain data items were aligned to 32-bit boundaries. In
+  version 1.4, alignment of data was done away with completely. The need for
+  alignment has gone away and the only thing it adds is bytecode file size
+  overhead. In most cases this overhead was small. However, in functions with
+  large numbers of format 0 instructions (GEPs and PHIs with lots of parameters)
+  or regular instructions with large valued operands (e.g. because there's just
+  a lot of instructions in the function) the overhead can be extreme. In one
+  test case, the overhead was 44,000 bytes (34% of the total file size).
+  Consequently in release 1.4, the decision was made to eliminate alignment
+  altogether.</p>
+  <p>In version 1.3 format, the following bytecode constructs were aligned (i.e.
+  they were followed by one to three bytes of padding):</p>
+  <ul>
+    <li>All blocks.</li>
+    <li>Instructions using the long format (format 0).</li>
+    <li>All call instructions that called a var args function.</li>
+    <li>The target triple (a string field at the end of the module block).</li>
+    <li>The version field (immediately following the signature).</li>
+  </ul>
+  <p>None of these constructs are aligned in version 1.4</p>
+</div>
+-->
+
 <!-- _______________________________________________________________________ -->
 <div class="doc_subsection"><a name="vers12">Version 1.2 Differences
 From 1.3</a></div>
 <!-- _______________________________________________________________________ -->
+
 <div class="doc_subsubsection">Type Derives From Value</div>
 <div class="doc_text">
 <p>In version 1.2, the Type class in the LLVM IR derives from the Value
@@ -1632,7 +1937,5 @@ From 1.1</a></div>
 <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a><br>
 Last modified: $Date$
 </address>
-<!-- vim: sw=2
--->
 </body>
 </html>

llvm/docs/CFEBuildInstrs.html

@@ -16,6 +16,7 @@
   <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>
@@ -44,8 +45,8 @@ process, and you should <b>only</b> try to do it if:</p>
 
 <ol>
   <li>you really, really, really can't use the binaries we distribute</li>
-  <li>you need GCC to fix some of the header files on your system</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>
@@ -58,7 +59,7 @@ process, and you should <b>only</b> try to do it if:</p>
 <!--=========================================================================-->
 
 <div class="doc_text">
-<p>If you are building LLVM and the C front-end under Cygwin, please note that
+<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 
@@ -66,6 +67,28 @@ located in a top-level directory (like <tt>/cygdrive/c/llvm</tt> and
 (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 CFE 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 LLVM CFE. 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>
 
 <!-- *********************************************************************** -->
@@ -77,25 +100,39 @@ and Settings" directory).  We welcome patches to fix this issue.
 <div class="doc_text">
 <p>
 <ol>
-<li><p>Configure and build the LLVM libraries and tools using:</p>
-<pre>
+<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> not be the same as <i>objdir</i>:</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 [options...]
- % gmake 
-</pre>
-    <p>This will build all of the LLVM tools and libraries, but you will see 
-       warnings about missing the C front-end (certain runtime libraries can't
-       be built without it).  Ignore these warnings for now.</p></li>
+ % ./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/tools/Debug &amp;&amp; pwd` $path )
+ % set path = ( `cd llvm/Debug/bin &amp;&amp; pwd` $path )
 </pre></li>
 
-<li><p>Unpack the C/C++ front-end source into cfrontend/src.</p></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>
+<li><p>Make "build" and "install" directories as siblings of the "src" tree:</p>
 <pre>
  % pwd
  /usr/local/example/cfrontend/src
@@ -105,19 +142,18 @@ and Settings" directory).  We welcome patches to fix this issue.
 </pre></li>
 
 
-<li><p>Configure, build, and install the C front-end:</p>
+<li><p>Configure, build, and install the GCC front-end:</p>
 
 <p>
 <b>Linux/x86:</b><br>
-<b>MacOS X/PowerPC</b> (requires dlcompat library):
+<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++
- % gmake
- % setenv LLVM_LIB_SEARCH_PATH `pwd`/gcc 
+ % ../src/configure --prefix=$CFEINSTALL --disable-threads --disable-nls \
+   --disable-shared --enable-languages=c,c++ --program-prefix=llvm-
  % gmake all; gmake install
 </pre>
 
@@ -125,18 +161,24 @@ and Settings" directory).  We welcome patches to fix this issue.
 
 <pre>
  % cd build
- % ../src/configure --prefix=$CFEINSTALL --disable-threads --disable-nls --disable-shared \
-   --enable-languages=c,c++ --disable-c-mbchar
- % gmake
- % setenv LLVM_LIB_SEARCH_PATH `pwd`/gcc 
+ % ../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>
-For Solaris/SPARC, LLVM only supports the SPARC V9.  Therefore, the
-configure command line should specify sparcv9, as shown below. Also,
+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>).
@@ -146,9 +188,7 @@ functions from C as referenced from C++, so we typically configure with
  % cd build
  % ../src/configure --prefix=$CFEINSTALL --disable-threads --disable-nls \
    --disable-shared --enable-languages=c,c++ --host=sparcv9-sun-solaris2.8 \
-   --disable-c-mbchar
- % gmake
- % setenv LLVM_LIB_SEARCH_PATH `pwd`/gcc 
+   --disable-c-mbchar --program-prefix=llvm-
  % gmake all; gmake install
 </pre>
 
@@ -159,8 +199,8 @@ functions from C as referenced from C++, so we typically configure with
  <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/<i>target-triplet</i>/sys-include</code>.</li>
+   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
@@ -169,13 +209,13 @@ functions from C as referenced from C++, so we typically configure with
    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 new front-end
- to a new architecture, or compiling in a different configuration that we have
- previously, there are probably several changes you will have to make to the GCC
- target to get it to work correctly.  These include:<p>
+ <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 or assembler linker flags which
+  <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 
@@ -197,35 +237,47 @@ functions from C as referenced from C++, so we typically configure with
  </ul>
 </li>
 
-<li><p>Go back into the LLVM source tree proper.  Rerun configure, using
-the <code>--with-llvmgccdir=$CFEINSTALL</code> option to specify the path
-to the newly built C front-end.</p></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>If you edited header files during the C/C++ front-end build as
-described in "Fix 1" above, you must now copy those header files from
-<code>$CFEINSTALL/<i>target-triplet</i>/sys-include</code> to
-<code>$CFEINSTALL/lib/gcc/<i>target-triplet</i>/3.4-llvm/include</code>.
-(This should be the "include" directory in the same directory as the
-libgcc.a library, which you can find by running
-<code>$CFEINSTALL/bin/gcc --print-libgcc-file-name</code>.)</p></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 C front-end build tree.
-  These are the commands you need.</p>
+  built, install the runtime libraries into your GCC front-end build tree.
+  These are the commands you need:</p>
 <pre>
  % gmake
- % mkdir $CFEINSTALL/bytecode-libs
  % gmake -C runtime install-bytecode
- % setenv LLVM_LIB_SEARCH_PATH $CFEINSTALL/bytecode-libs
 </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 under <tt>test/Programs</tt> using <code>gmake -C
-   test/Programs</code></li>
+  <li> running the tests found in the <tt>llvm-test</tt> CVS module</li>
  </ul></li>
 </ol>
 </div>
@@ -248,7 +300,7 @@ The software also has the following additional copyrights:
 
 <pre>
 
-Copyright (c) 2003, 2004 University of Illinois at Urbana-Champaign.
+Copyright (c) 2003, 2004, 2005 University of Illinois at Urbana-Champaign.
 All rights reserved.
 
 Developed by:

llvm/docs/CodeGenerator.html

@@ -23,6 +23,7 @@
     <ul>
       <li><a href="#targetmachine">The <tt>TargetMachine</tt> class</a></li>
       <li><a href="#targetdata">The <tt>TargetData</tt> class</a></li>
+      <li><a href="#targetlowering">The <tt>TargetLowering</tt> class</a></li>
       <li><a href="#mregisterinfo">The <tt>MRegisterInfo</tt> class</a></li>
       <li><a href="#targetinstrinfo">The <tt>TargetInstrInfo</tt> class</a></li>
       <li><a href="#targetframeinfo">The <tt>TargetFrameInfo</tt> class</a></li>
@@ -31,14 +32,30 @@
   </li>
   <li><a href="#codegendesc">Machine code description classes</a>
     <ul>
-      <li><a href="#machineinstr">The <tt>MachineInstr</tt> class</a></li>
+    <li><a href="#machineinstr">The <tt>MachineInstr</tt> class</a></li>
     </ul>
   </li>
   <li><a href="#codegenalgs">Target-independent code generation algorithms</a>
+    <ul>
+    <li><a href="#instselect">Instruction Selection</a>
+      <ul>
+      <li><a href="#selectiondag_intro">Introduction to SelectionDAGs</a></li>
+      <li><a href="#selectiondag_process">SelectionDAG Code Generation
+                                          Process</a></li>
+      <li><a href="#selectiondag_build">Initial SelectionDAG
+                                        Construction</a></li>
+      <li><a href="#selectiondag_legalize">SelectionDAG Legalize Phase</a></li>
+      <li><a href="#selectiondag_optimize">SelectionDAG Optimization
+                                           Phase</a></li>
+      <li><a href="#selectiondag_select">SelectionDAG Select Phase</a></li>
+      <li><a href="#selectiondag_future">Future directions for the
+                                         SelectionDAG</a></li>
+      </ul></li>
+    </ul>
   </li>
   <li><a href="#targetimpls">Target description implementations</a>
     <ul>
-      <li><a href="#x86">The X86 backend</a></li>
+    <li><a href="#x86">The X86 backend</a></li>
     </ul>
   </li>
 
@@ -120,7 +137,7 @@ classes, ensuring that it is portable.
 code generator and the set of reusable components that can be used to build
 target-specific backends.  The two most important interfaces (<a
 href="#targetmachine"><tt>TargetMachine</tt></a> and <a
-href="#targetdata"><tt>TargetData</tt></a> classes) are the only ones that are
+href="#targetdata"><tt>TargetData</tt></a>) are the only ones that are
 required to be defined for a backend to fit into the LLVM system, but the others
 must be defined if the reusable code generator components are going to be
 used.</p>
@@ -159,41 +176,43 @@ predictable completion date.</p>
 
 <div class="doc_text">
 
-<p>The LLVM target-indendent code generator is designed to support efficient and
+<p>The LLVM target-independent code generator is designed to support efficient and
 quality code generation for standard register-based microprocessors.  Code
 generation in this model is divided into the following stages:</p>
 
 <ol>
-<li><b>Instruction Selection</b> - Determining an efficient implementation of the
-input LLVM code in the target instruction set.  This stage produces the initial
-code for the program in the target instruction set, then makes use of virtual
-registers in SSA form and physical registers that represent any required
-register assignments due to target constraints or calling conventions.</li>
+<li><b><a href="#instselect">Instruction Selection</a></b> - Determining an
+efficient implementation of the input LLVM code in the target instruction set.
+This stage produces the initial code for the program in the target instruction
+set, then makes use of virtual registers in SSA form and physical registers that
+represent any required register assignments due to target constraints or calling
+conventions.</li>
 
-<li><b>SSA-based Machine Code Optimizations</b> - This (optional) stage consists
-of a series of machine-code optimizations that operate on the SSA-form produced
-by the instruction selector.  Optimizations like modulo-scheduling, normal
-scheduling, or peephole optimization work here.</li>
+<li><b><a href="#ssamco">SSA-based Machine Code Optimizations</a></b> - This 
+optional stage consists of a series of machine-code optimizations that 
+operate on the SSA-form produced by the instruction selector.  Optimizations 
+like modulo-scheduling, normal scheduling, or peephole optimization work here.
+</li>
 
-<li><b>Register Allocation</b> - The target code is transformed from an infinite
-virtual register file in SSA form to the concrete register file used by the
-target.  This phase introduces spill code and eliminates all virtual register
-references from the program.</li>
+<li><b><a name="#regalloc">Register Allocation</a></b> - The
+target code is transformed from an infinite virtual register file in SSA form 
+to the concrete register file used by the target.  This phase introduces spill 
+code and eliminates all virtual register references from the program.</li>
 
-<li><b>Prolog/Epilog Code Insertion</b> - Once the machine code has been
-generated for the function and the amount of stack space required is known (used
-for LLVM alloca's and spill slots), the prolog and epilog code for the function
-can be inserted and "abstract stack location references" can be eliminated.
-This stage is responsible for implementing optimizations like frame-pointer
-elimination and stack packing.</li>
+<li><b><a name="#proepicode">Prolog/Epilog Code Insertion</a></b> - Once the 
+machine code has been generated for the function and the amount of stack space 
+required is known (used for LLVM alloca's and spill slots), the prolog and 
+epilog code for the function can be inserted and "abstract stack location 
+references" can be eliminated.  This stage is responsible for implementing 
+optimizations like frame-pointer elimination and stack packing.</li>
 
-<li><b>Late Machine Code Optimizations</b> - Optimizations that operate on
-"final" machine code can go here, such as spill code scheduling and peephole
-optimizations.</li>
+<li><b><a name="latemco">Late Machine Code Optimizations</a></b> - Optimizations
+that operate on "final" machine code can go here, such as spill code scheduling
+and peephole optimizations.</li>
 
-<li><b>Code Emission</b> - The final stage actually outputs the code for
-the current function, either in the target assembler format or in machine
-code.</li>
+<li><b><a name="codemission">Code Emission</a></b> - The final stage actually 
+puts out the code for the current function, either in the target assembler 
+format or in machine code.</li>
 
 </ol>
 
@@ -205,7 +224,7 @@ expansion and
 aggressive iterative peephole optimization are much slower.  This design 
 permits efficient compilation (important for JIT environments) and
 aggressive optimization (used when generating code offline) by allowing 
-components of varying levels of sophisication to be used for any step of 
+components of varying levels of sophistication to be used for any step of 
 compilation.</p>
 
 <p>
@@ -227,11 +246,13 @@ targets with unusual requirements can be supported with custom passes as needed.
 
 <p>The target description classes require a detailed description of the target
 architecture.  These target descriptions often have a large amount of common
-information (e.g., an add instruction is almost identical to a sub instruction).
+information (e.g., an <tt>add</tt> instruction is almost identical to a 
+<tt>sub</tt> instruction).
 In order to allow the maximum amount of commonality to be factored out, the LLVM
 code generator uses the <a href="TableGenFundamentals.html">TableGen</a> tool to
-describe big chunks of the target machine, which allows the use of domain- and 
-target-specific abstractions to reduce the amount of repetition.
+describe big chunks of the target machine, which allows the use of
+domain-specific and target-specific abstractions to reduce the amount of 
+repetition.
 </p>
 
 </div>
@@ -246,11 +267,11 @@ target-specific abstractions to reduce the amount of repetition.
 
 <p>The LLVM target description classes (which are located in the
 <tt>include/llvm/Target</tt> directory) provide an abstract description of the
-target machine, independent of any particular client.  These classes are
-designed to capture the <i>abstract</i> properties of the target (such as what
-instruction and registers it has), and do not incorporate any particular pieces
-of code generation algorithms (these interfaces do not take interference graphs
-as inputs or other algorithm-specific data structures).</p>
+target machine; independent of any particular client.  These classes are
+designed to capture the <i>abstract</i> properties of the target (such as the
+instructions and registers it has), and do not incorporate any particular pieces
+of code generation algorithms. These interfaces do not take interference graphs
+as inputs or other algorithm-specific data structures.</p>
 
 <p>All of the target description classes (except the <tt><a
 href="#targetdata">TargetData</a></tt> class) are designed to be subclassed by
@@ -270,8 +291,9 @@ should be implemented by the target.</p>
 
 <p>The <tt>TargetMachine</tt> class provides virtual methods that are used to
 access the target-specific implementations of the various target description
-classes (with the <tt>getInstrInfo</tt>, <tt>getRegisterInfo</tt>,
-<tt>getFrameInfo</tt>, ... methods).  This class is designed to be specialized by
+classes via the <tt>get*Info</tt> methods (<tt>getInstrInfo</tt>,
+<tt>getRegisterInfo</tt>, <tt>getFrameInfo</tt>, etc.).  This class is 
+designed to be specialized by
 a concrete target implementation (e.g., <tt>X86TargetMachine</tt>) which
 implements the various virtual methods.  The only required target description
 class is the <a href="#targetdata"><tt>TargetData</tt></a> class, but if the
@@ -289,13 +311,35 @@ implemented as well.</p>
 <div class="doc_text">
 
 <p>The <tt>TargetData</tt> class is the only required target description class,
-and it is the only class that is not extensible (it cannot be derived from).  It
-specifies information about how the target lays out memory for structures, the
-alignment requirements for various data types, the size of pointers in the
-target, and whether the target is little- or big-endian.</p>
+and it is the only class that is not extensible. You cannot derived  a new 
+class from it.  <tt>TargetData</tt> specifies information about how the target 
+lays out memory for structures, the alignment requirements for various data 
+types, the size of pointers in the target, and whether the target is 
+little-endian or big-endian.</p>
 
 </div>
 
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+  <a name="targetlowering">The <tt>TargetLowering</tt> class</a>
+</div>
+
+<div class="doc_text">
+
+<p>The <tt>TargetLowering</tt> class is used by SelectionDAG based instruction
+selectors primarily to describe how LLVM code should be lowered to SelectionDAG
+operations.  Among other things, this class indicates:
+<ul><li>an initial register class to use for various ValueTypes,</li>
+  <li>which operations are natively supported by the target machine,</li>
+  <li>the return type of setcc operations, and</li>
+  <li>the type to use for shift amounts, etc</li>.
+</ol></p>
+
+</div>
+
+
+    
+
 
 <!-- ======================================================================= -->
 <div class="doc_subsection">
@@ -378,14 +422,14 @@ representation for machine code, as well as a register allocated, non-SSA form.
 
 <p>Target machine instructions are represented as instances of the
 <tt>MachineInstr</tt> class.  This class is an extremely abstract way of
-representing machine instructions.  In particular, all it keeps track of is 
-an opcode number and some number of operands.</p>
+representing machine instructions.  In particular, it only keeps track of 
+an opcode number and a set of operands.</p>
 
-<p>The opcode number is an simple unsigned number that only has meaning to a 
+<p>The opcode number is a simple unsigned number that only has meaning to a 
 specific backend.  All of the instructions for a target should be defined in 
-the <tt>*InstrInfo.td</tt> file for the target, and the opcode enum values
-are autogenerated from this description.  The <tt>MachineInstr</tt> class does
-not have any information about how to intepret the instruction (i.e., what the 
+the <tt>*InstrInfo.td</tt> file for the target. The opcode enum values
+are auto-generated from this description.  The <tt>MachineInstr</tt> class does
+not have any information about how to interpret the instruction (i.e., what the 
 semantics of the instruction are): for that you must refer to the 
 <tt><a href="#targetinstrinfo">TargetInstrInfo</a></tt> class.</p> 
 
@@ -396,15 +440,15 @@ In addition, a machine operand should be marked as a def or a use of the value
 
 <p>By convention, the LLVM code generator orders instruction operands so that
 all register definitions come before the register uses, even on architectures
-that are normally printed in other orders.  For example, the sparc add 
+that are normally printed in other orders.  For example, the SPARC add 
 instruction: "<tt>add %i1, %i2, %i3</tt>" adds the "%i1", and "%i2" registers
 and stores the result into the "%i3" register.  In the LLVM code generator,
 the operands should be stored as "<tt>%i3, %i1, %i2</tt>": with the destination
 first.</p>
 
-<p>Keeping destination operands at the beginning of the operand list has several
-advantages.  In particular, the debugging printer will print the instruction 
-like this:</p>
+<p>Keeping destination (definition) operands at the beginning of the operand 
+list has several advantages.  In particular, the debugging printer will print 
+the instruction like this:</p>
 
 <pre>
   %r3 = add %i1, %i2
@@ -453,17 +497,18 @@ instructions.  Usage of the <tt>BuildMI</tt> functions look like this:
 
 <p>
 The key thing to remember with the <tt>BuildMI</tt> functions is that you have
-to specify the number of operands that the machine instruction will take 
-(allowing efficient memory allocation).  Also, if operands default to be uses
-of values, not definitions.  If you need to add a definition operand (other 
-than the optional destination register), you must explicitly mark it as such.
+to specify the number of operands that the machine instruction will take. This
+allows for efficient memory allocation.  You also need to specify if operands 
+default to be uses of values, not definitions.  If you need to add a definition
+operand (other than the optional destination register), you must explicitly 
+mark it as such.
 </p>
 
 </div>
 
 <!-- _______________________________________________________________________ -->
 <div class="doc_subsubsection">
-  <a name="fixedregs">Fixed (aka preassigned) registers</a>
+  <a name="fixedregs">Fixed (preassigned) registers</a>
 </div>
 
 <div class="doc_text">
@@ -472,7 +517,7 @@ than the optional destination register), you must explicitly mark it as such.
 presence of fixed registers.  In particular, there are often places in the 
 instruction stream where the register allocator <em>must</em> arrange for a
 particular value to be in a particular register.  This can occur due to 
-limitations in the instruction set (e.g., the X86 can only do a 32-bit divide 
+limitations of the instruction set (e.g., the X86 can only do a 32-bit divide 
 with the <tt>EAX</tt>/<tt>EDX</tt> registers), or external factors like calling
 conventions.  In any case, the instruction selector should emit code that 
 copies a virtual register into or out of a physical register when needed.</p>
@@ -503,7 +548,7 @@ and ret (use
         ret
 </pre>
 
-<p>By the end of code generation, the register allocator has coallesced
+<p>By the end of code generation, the register allocator has coalesced
 the registers and deleted the resultant identity moves, producing the
 following code:</p>
 
@@ -533,7 +578,7 @@ register.</p>
 
 <div class="doc_text">
 
-<p><tt>MachineInstr</tt>'s are initially instruction selected in SSA-form, and
+<p><tt>MachineInstr</tt>'s are initially selected in SSA-form, and
 are maintained in SSA-form until register allocation happens.  For the most 
 part, this is trivially simple since LLVM is already in SSA form: LLVM PHI nodes
 become machine code PHI nodes, and virtual registers are only allowed to have a
@@ -544,6 +589,318 @@ are no virtual registers left in the code.</p>
 
 </div>
 
+<!-- *********************************************************************** -->
+<div class="doc_section">
+  <a name="codegenalgs">Target-independent code generation algorithms</a>
+</div>
+<!-- *********************************************************************** -->
+
+<div class="doc_text">
+
+<p>This section documents the phases described in the <a
+href="high-level-design">high-level design of the code generator</a>.  It
+explains how they work and some of the rationale behind their design.</p>
+
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+  <a name="instselect">Instruction Selection</a>
+</div>
+
+<div class="doc_text">
+<p>
+Instruction Selection is the process of translating LLVM code presented to the
+code generator into target-specific machine instructions.  There are several
+well-known ways to do this in the literature.  In LLVM there are two main forms:
+the old-style 'simple' instruction selector (which effectively peephole selects
+each LLVM instruction into a series of machine instructions), and the new
+SelectionDAG based instruction selector.
+</p>
+
+<p>The 'simple' instruction selectors are tedious to write, require a lot of
+boiler plate code, and are difficult to get correct.  Additionally, any
+optimizations written for a simple instruction selector cannot be used by other
+targets.  For this reason, LLVM is moving to a new SelectionDAG based
+instruction selector, which is described in this section.  If you are starting a
+new port, we recommend that you write the instruction selector using the
+SelectionDAG infrastructure.</p>
+
+<p>In time, most of the target-specific code for instruction selection will be
+auto-generated from the target description (<tt>*.td</tt>) files.  For now, 
+however, the <a href="#selectiondag_select">Select Phase</a> must still be 
+written by hand.</p>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+  <a name="selectiondag_intro">Introduction to SelectionDAGs</a>
+</div>
+
+<div class="doc_text">
+
+<p>
+The SelectionDAG provides an abstraction for code representation in a way that 
+is amenable to instruction selection using automatic techniques
+(e.g. dynamic-programming based optimal pattern matching selectors), It is also
+well suited to other phases of code generation; in particular, instruction scheduling.  Additionally, the SelectionDAG provides a host representation where a 
+large variety of very-low-level (but target-independent) 
+<a href="#selectiondag_optimize">optimizations</a> may be
+performed: ones which require extensive information about the instructions
+efficiently supported by the target.
+</p>
+
+<p>
+The SelectionDAG is a Directed-Acyclic-Graph whose nodes are instances of the
+<tt>SDNode</tt> class.  The primary payload of the <tt>SDNode</tt> is its 
+operation code (Opcode) that indicates what operation the node performs.  
+The various operation node types are described at the top of the
+<tt>include/llvm/CodeGen/SelectionDAGNodes.h</tt> file.  Depending on the 
+operation, nodes may contain additional information (e.g. the condition code
+for a SETCC node) contained in a derived class.</p>
+
+<p>Although most operations define a single value, each node in the graph may 
+define multiple values.  For example, a combined div/rem operation will define
+both the dividend and the remainder. Many other situations require multiple
+values as well.  Each node also has some number of operands, which are edges 
+to the node defining the used value.  Because nodes may define multiple values,
+edges are represented by instances of the <tt>SDOperand</tt> class, which is 
+a &lt;SDNode, unsigned&gt; pair, indicating the node and result
+value being used, respectively.  Each value produced by an SDNode has an 
+associated MVT::ValueType, indicating what type the value is.
+</p>
+
+<p>
+SelectionDAGs contain two different kinds of values: those that represent data
+flow and those that represent control flow dependencies.  Data values are simple
+edges with an integer or floating point value type.  Control edges are
+represented as "chain" edges which are of type MVT::Other.  These edges provide
+an ordering between nodes that have side effects (such as
+loads/stores/calls/return/etc).  All nodes that have side effects should take a
+token chain as input and produce a new one as output.  By convention, token
+chain inputs are always operand #0, and chain results are always the last
+value produced by an operation.</p>
+
+<p>
+A SelectionDAG has designated "Entry" and "Root" nodes.  The Entry node is
+always a marker node with an Opcode of ISD::EntryToken.  The Root node is the
+final side-effecting node in the token chain. For example, in a single basic
+block function, this would be the return node.
+</p>
+
+<p>
+One important concept for SelectionDAGs is the notion of a "legal" vs. "illegal"
+DAG.  A legal DAG for a target is one that only uses supported operations and
+supported types.  On PowerPC, for example, a DAG with any values of i1, i8, i16,
+or i64 type would be illegal.  The <a href="#selectiondag_legalize">legalize</a>
+phase is responsible for turning an illegal DAG into a legal DAG.
+</p>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+  <a name="selectiondag_process">SelectionDAG Instruction Selection Process</a>
+</div>
+
+<div class="doc_text">
+
+<p>
+SelectionDAG-based instruction selection consists of the following steps:
+</p>
+
+<ol>
+<li><a href="#selectiondag_build">Build initial DAG</a> - This stage performs
+    a simple translation from the input LLVM code to an illegal SelectionDAG.
+    </li>
+<li><a href="#selectiondag_optimize">Optimize SelectionDAG</a> - This stage
+    performs simple optimizations on the SelectionDAG to simplify it and
+    recognize meta instructions (like rotates and div/rem pairs) for
+    targets that support these meta operations.  This makes the resultant code
+    more efficient and the 'select instructions from DAG' phase (below) simpler.
+</li>
+<li><a href="#selectiondag_legalize">Legalize SelectionDAG</a> - This stage
+    converts the illegal SelectionDAG to a legal SelectionDAG, by eliminating
+    unsupported operations and data types.</li>
+<li><a href="#selectiondag_optimize">Optimize SelectionDAG (#2)</a> - This
+    second run of the SelectionDAG optimized the newly legalized DAG, to
+    eliminate inefficiencies introduced by legalization.</li>
+<li><a href="#selectiondag_select">Select instructions from DAG</a> - Finally,
+    the target instruction selector matches the DAG operations to target
+    instructions, emitting them and building the MachineFunction being
+    compiled.</li>
+</ol>
+
+<p>After all of these steps are complete, the SelectionDAG is destroyed and the
+rest of the code generation passes are run.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+  <a name="selectiondag_build">Initial SelectionDAG Construction</a>
+</div>
+
+<div class="doc_text">
+
+<p>
+The initial SelectionDAG is naively peephole expanded from the LLVM input by
+the <tt>SelectionDAGLowering</tt> class in the SelectionDAGISel.cpp file.  The 
+intent of  this pass is to expose as much low-level, target-specific details 
+to the SelectionDAG as possible.  This pass is mostly hard-coded (e.g. an LLVM 
+add turns into an SDNode add while a geteelementptr is expanded into the obvious
+arithmetic). This pass requires target-specific hooks to lower calls and
+returns, varargs, etc.  For these features, the TargetLowering interface is
+used.
+</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+  <a name="selectiondag_legalize">SelectionDAG Legalize Phase</a>
+</div>
+
+<div class="doc_text">
+
+<p>The Legalize phase is in charge of converting a DAG to only use the types and
+operations that are natively supported by the target.  This involves two major
+tasks:</p>
+
+<ol>
+<li><p>Convert values of unsupported types to values of supported types.</p>
+    <p>There are two main ways of doing this: promoting a small type to a larger
+       type (e.g. f32 -&gt; f64, or i16 -&gt; i32), and breaking up large 
+       integer types
+       to smaller ones (e.g. implementing i64 with i32 operations where
+       possible).  Type conversions can insert sign and zero extensions as 
+       needed to make sure that the final code has the same behavior as the 
+       input.</p>
+</li>
+
+<li><p>Eliminate operations that are not supported by the target in a supported
+       type.</p>
+    <p>Targets often have wierd constraints, such as not supporting every
+       operation on every supported datatype (e.g. X86 does not support byte
+       conditional moves).  Legalize takes care of either open-coding another 
+       sequence of operations to emulate the operation (this is known as
+       expansion), promoting to a larger type that supports the operation
+       (promotion), or using a target-specific hook to implement the
+       legalization.</p>
+</li>
+</ol>
+
+<p>
+Instead of using a Legalize pass, we could require that every target-specific 
+<a href="#selectiondag_optimize">selector</a> supports and expands every 
+operator and type even if they are not supported and may require many 
+instructions to implement (in fact, this is the approach taken by the 
+"simple" selectors).  However, using a Legalize pass allows all of the 
+cannonicalization patterns to be shared across targets which makes it very 
+easy to optimize the cannonicalized code because it is still in the form of 
+a DAG.
+</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+  <a name="selectiondag_optimize">SelectionDAG Optimization Phase</a>
+</div>
+
+<div class="doc_text">
+
+<p>
+The SelectionDAG optimization phase is run twice for code generation: once
+immediately after the DAG is built and once after legalization.  The first run
+of the pass allows the initial code to be cleaned up (e.g. performing 
+optimizations that depend on knowing that the operators have restricted type 
+inputs).  The second run of the pass cleans up the messy code generated by the 
+Legalize pass, allowing Legalize to be very simple since it can ignore many 
+special cases. 
+</p>
+
+<p>
+One important class of optimizations that this pass will do in the future is
+optimizing inserted sign and zero extension instructions.  Here are some good
+papers on the subject:</p>
+
+<p>
+"<a href="http://www.eecs.harvard.edu/~nr/pubs/widen-abstract.html">Widening
+integer arithmetic</a>"<br>
+Kevin Redwine and Norman Ramsey<br>
+International Conference on Compiler Construction (CC) 2004
+</p>
+
+
+<p>
+ "<a href="http://portal.acm.org/citation.cfm?doid=512529.512552">Effective
+ sign extension elimination</a>"<br>
+ Motohiro Kawahito, Hideaki Komatsu, and Toshio Nakatani<br>
+ Proceedings of the ACM SIGPLAN 2002 Conference on Programming Language Design
+ and Implementation.
+</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+  <a name="selectiondag_select">SelectionDAG Select Phase</a>
+</div>
+
+<div class="doc_text">
+
+<p>The Select phase is the bulk of the target-specific code for instruction
+selection.  This phase takes a legal SelectionDAG as input, and does simple
+pattern matching on the DAG to generate code.  In time, the Select phase will
+be automatically generated from the target's InstrInfo.td file, which is why we
+want to make the Select phase as simple and mechanical as possible.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+  <a name="selectiondag_future">Future directions for the SelectionDAG</a>
+</div>
+
+<div class="doc_text">
+
+<ol>
+<li>Optional whole-function selection.</li>
+<li>Select is a graph translation phase.</li>
+<li>Place the machine instructions resulting from Select according to register 
+pressure or a schedule.</li>
+<li>DAG Scheduling.</li>
+<li>Auto-generate the Select phase from the target description (*.td) files.
+</li>
+</ol>
+
+</div>
+ 
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+  <a name="ssamco">SSA-based Machine Code Optimizations</a>
+</div>
+<div class="doc_text"><p>To Be Written</p></div>
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+  <a name="regalloc">Register Allocation</a>
+</div>
+<div class="doc_text"><p>To Be Written</p></div>
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+  <a name="proepicode">Prolog/Epilog Code Insertion</a>
+</div>
+<div class="doc_text"><p>To Be Written</p></div>
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+  <a name="latemco">Late Machine Code Optimizations</a>
+</div>
+<div class="doc_text"><p>To Be Written</p></div>
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+  <a name="codemission">Code Emission</a>
+</div>
+
 <!-- *********************************************************************** -->
 <div class="doc_section">
   <a name="targetimpls">Target description implementations</a>
@@ -552,7 +909,7 @@ are no virtual registers left in the code.</p>
 
 <div class="doc_text">
 
-<p>This section of the document explains any features or design decisions that
+<p>This section of the document explains features or design decisions that
 are specific to the code generator for a particular target.</p>
 
 </div>
@@ -570,7 +927,7 @@ The X86 code generator lives in the <tt>lib/Target/X86</tt> directory.  This
 code generator currently targets a generic P6-like processor.  As such, it
 produces a few P6-and-above instructions (like conditional moves), but it does
 not make use of newer features like MMX or SSE.  In the future, the X86 backend
-will have subtarget support added for specific processor families and 
+will have sub-target support added for specific processor families and 
 implementations.</p>
 
 </div>
@@ -582,8 +939,7 @@ implementations.</p>
 
 <div class="doc_text">
 
-<p>
-The x86 has a very, uhm, flexible, way of accessing memory.  It is capable of
+<p>The x86 has a very flexible way of accessing memory.  It is capable of
 forming memory addresses of the following expression directly in integer
 instructions (which use ModR/M addressing):</p>
 
@@ -591,9 +947,9 @@ instructions (which use ModR/M addressing):</p>
    Base+[1,2,4,8]*IndexReg+Disp32
 </pre>
 
-<p>Wow, that's crazy.  In order to represent this, LLVM tracks no less that 4
-operands for each memory operand of this form.  This means that the "load" form
-of 'mov' has the following "Operands" in this order:</p>
+<p>In order to represent this, LLVM tracks no less than 4 operands for each
+memory operand of this form.  This means that the "load" form of 'mov' has the
+following <tt>MachineOperand</tt>s in this order:</p>
 
 <pre>
 Index:        0     |    1        2       3           4
@@ -601,8 +957,8 @@ Meaning:   DestReg, | BaseReg,  Scale, IndexReg, Displacement
 OperandTy: VirtReg, | VirtReg, UnsImm, VirtReg,   SignExtImm
 </pre>
 
-<p>Stores and all other instructions treat the four memory operands in the same
-way, in the same order.</p>
+<p>Stores, and all other instructions, treat the four memory operands in the 
+same way, in the same order.</p>
 
 </div>
 
@@ -614,9 +970,8 @@ way, in the same order.</p>
 <div class="doc_text">
 
 <p>
-An instruction name consists of the base name, a default operand size
-followed by a character per operand with an optional special size. For
-example:</p>
+An instruction name consists of the base name, a default operand size, and a
+a character per operand with an optional special size. For example:</p>
 
 <p>
 <tt>ADD8rr</tt> -&gt; add, 8-bit register, 8-bit register<br>

llvm/docs/CodingStandards.html

@@ -19,7 +19,7 @@
         <ol>
           <li><a href="#scf_commenting">Commenting</a></li>
           <li><a href="#scf_commentformat">Comment Formatting</a></li>
-          <li><a href="#scf_includes">#include Style</a></li>
+          <li><a href="#scf_includes"><tt>#include</tt> Style</a></li>
           <li><a href="#scf_codewidth">Source Code Width</a></li>
           <li><a href="#scf_spacestabs">Use Spaces Instead of Tabs</a></li>
           <li><a href="#scf_indentation">Indent Code Consistently</a></li>
@@ -29,6 +29,7 @@
           <li><a href="#ci_warningerrors">Treat Compiler Warnings Like
               Errors</a></li>
           <li><a href="#ci_portable_code">Write Portable Code</a></li>
+          <li><a href="#ci_class_struct">Use of class/struct Keywords</a></li>
         </ol></li>
     </ol></li>
   <li><a href="#styleissues">Style Issues</a>
@@ -45,7 +46,7 @@
         <ol>
           <li><a href="#hl_assert">Assert Liberally</a></li>
           <li><a href="#hl_preincrement">Prefer Preincrement</a></li>
-          <li><a href="#hl_avoidendl">Avoid std::endl</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>
@@ -110,7 +111,7 @@ href="mailto:sabre@nondot.org">Chris</a>.</p>
 <div class="doc_text">
 
 <p>Comments are one critical part of readability and maintainability.  Everyone
-knows they should comment, so should you.  :)  Although we all should probably
+knows they should comment, so should you.  Although we all should probably
 comment our code more than we do, there are a few very critical places that
 documentation is very useful:</p>
 
@@ -163,7 +164,7 @@ included, as well as any notes or "gotchas" in the code to watch out for.</p>
 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
-something sane goes a long ways towards avoiding writing documentation. :)</p>
+something sane goes a long ways towards avoiding writing documentation.</p>
 
 
 <b>Method information</b>
@@ -193,8 +194,9 @@ when it is useful to use C style (<tt>/* */</tt>) comments however:</p>
 
 <ol>
   <li>When writing a C code: Obviously if you are writing C code, use C style
-      comments.  :)</li>
-  <li>When writing a header file that may be #included by a C source file.</li>
+      comments.</li>
+  <li>When writing a header file that may be <tt>#include</tt>d by a C source
+      file.</li>
   <li>When writing a source file that is used by a tool that only accepts C
       style comments.</li>
 </ol>
@@ -206,7 +208,7 @@ These nest properly and are better behaved in general than C style comments.</p>
 
 <!-- _______________________________________________________________________ -->
 <div class="doc_subsubsection">
-  <a name="scf_includes">#include Style</a>
+  <a name="scf_includes"><tt>#include</tt> Style</a>
 </div>
 
 <div class="doc_text">
@@ -234,13 +236,13 @@ order:</p>
 <p>... and each catagory should be sorted by name.</p>
 
 <p><a name="mmheader">The "Main Module Header"</a> file applies to .cpp file
-which implement an interface defined by a .h file.  This #include should always
-be included <b>first</b> regardless of where it lives on the file system.  By
-including a header file first in the .cpp files that implement the interfaces,
-we ensure that the header does not have any hidden dependencies which are not
-explicitly #included in the header, but should be.  It is also a form of
-documentation in the .cpp file to indicate where the interfaces it implements
-are defined.</p>
+which implement an interface defined by a .h file.  This <tt>#include</tt>
+should always be included <b>first</b> regardless of where it lives on the file
+system.  By including a header file first in the .cpp files that implement the
+interfaces, we ensure that the header does not have any hidden dependencies
+which are not explicitly #included in the header, but should be.  It is also a
+form of documentation in the .cpp file to indicate where the interfaces it
+implements are defined.</p>
 
 </div>
 
@@ -366,6 +368,26 @@ to support it.</p>
 
 </div>
 
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+<a name="ci_class_struct">Use of <tt>class</tt> and <tt>struct</tt> Keywords</a>
+</div>
+<div class="doc_text">
+
+<p>In C++, the <tt>class</tt> and <tt>struct</tt> keywords can be used almost
+interchangeably. The only difference is when they are used to declare a class:
+<tt>class</tt> makes all members private by default while <tt>struct</tt> makes
+all members public by default.</p>
+
+<p>Unfortunately, not all compilers follow the rules and some will generate
+different symbols based on whether <tt>class</tt> or <tt>struct</tt> was used to
+declare the symbol.  This can lead to problems at link time.</p> 
+
+<p>So, the rule for LLVM is to always use the <tt>class</tt> keyword, unless
+<b>all</b> members are public, in which case <tt>struct</tt> is allowed.</p>
+
+</div>
+
 <!-- *********************************************************************** -->
 <div class="doc_section">
   <a name="styleissues">Style Issues</a>
@@ -411,7 +433,7 @@ translation unit.</p>
 
 <!-- _______________________________________________________________________ -->
 <div class="doc_subsubsection">
-  <a name="hl_dontinclude">#include as Little as Possible</a>
+  <a name="hl_dontinclude"><tt>#include</tt> as Little as Possible</a>
 </div>
 
 <div class="doc_text">
@@ -420,13 +442,13 @@ translation unit.</p>
 have to, especially in header files.</p>
 
 <p>But wait, sometimes you need to have the definition of a class to use it, or
-to inherit from it.  In these cases go ahead and #include that header file.  Be
-aware however that there are many cases where you don't need to have the full
-definition of a class.  If you are using a pointer or reference to a class, you
-don't need the header file.  If you are simply returning a class instance from a
-prototyped function or method, you don't need it.  In fact, for most cases, you
-simply don't need the definition of a class... and not <tt>#include</tt>'ing
-speeds up compilation.</p>
+to inherit from it.  In these cases go ahead and <tt>#include</tt> that header
+file.  Be aware however that there are many cases where you don't need to have
+the full definition of a class.  If you are using a pointer or reference to a
+class, you don't need the header file.  If you are simply returning a class
+instance from a prototyped function or method, you don't need it.  In fact, for
+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, either directly
@@ -448,7 +470,7 @@ about later...</p>
 <p>Many modules have a complex implementation that causes them to use more than
 one implementation (<tt>.cpp</tt>) file.  It is often tempting to put the
 internal communication interface (helper classes, extra functions, etc) in the
-public module header file.  Don't do this.  :)</p>
+public module header file.  Don't do this.</p>
 
 <p>If you really need to do something like this, put a private header file in
 the same directory as the source files, and include it locally.  This ensures
@@ -536,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="hl_avoidendl">Avoid std::endl</a>
+  <a name="hl_avoidendl">Avoid <tt>std::endl</tt></a>
 </div>
 
 <div class="doc_text">
@@ -571,8 +593,8 @@ 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
-&lt;algorithm&gt; header file.  Know about &lt;functional&gt; and what it can do
-for you.  C++ is just a tool that wants you to master it. :)</p>
+<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>
 
@@ -602,7 +624,7 @@ Software Design</a> by John Lakos</li>
 </ol>
 
 <p>If you get some free time, and you haven't read them: do so, you might learn
-something. :)</p>
+something.</p>
 
 </div>
 

llvm/docs/CommandGuide/.cvsignore

@@ -0,0 +1 @@
+pod2htm?.tmp

llvm/docs/CommandGuide/Makefile

@@ -1,7 +1,24 @@
-POD = $(wildcard *.pod)
-HTML = $(patsubst %.pod, html/%.html, $(POD))
-MAN = $(patsubst %.pod, man/man1/%.1, $(POD))
-PS = $(patsubst %.pod, ps/%.ps, $(POD))
+##===- docs/CommandGuide/Makefile --------------------------*- Makefile -*-===##
+# 
+#                     The LLVM Compiler Infrastructure
+#
+# 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.
+# 
+##===----------------------------------------------------------------------===##
+
+ifdef BUILD_FOR_WEBSITE
+
+# This special case is for keeping the CommandGuide on the LLVM web site
+# up to date automatically as the documents are checked in. It must build
+# the POD files to HTML only and keep them in the src directories. It must also
+# build in an unconfigured tree, hence the ifdef. To use this, run
+# make -s BUILD_FOR_WEBSITE=1 inside the cvs commit script.
+
+POD  := $(wildcard *.pod)
+HTML := $(patsubst %.pod, html/%.html, $(POD))
+MAN  := $(patsubst %.pod, man/man1/%.1, $(POD))
+PS   := $(patsubst %.pod, ps/%.ps, $(POD))
 
 all: $(HTML) $(MAN) $(PS)
 
@@ -10,10 +27,10 @@ all: $(HTML) $(MAN) $(PS)
 
 html/%.html: %.pod
 	pod2html --css=manpage.css --htmlroot=. \
-		--podpath=. --noindex --infile=$< --outfile=$@
+	  --podpath=. --noindex --infile=$< --outfile=$@ --title=$*
 
 man/man1/%.1: %.pod
-	pod2man --release=1.3 --center="LLVM Command Guide" $< $@
+	pod2man --release=1.5 --center="LLVM Command Guide" $< $@
 
 ps/%.ps: man/man1/%.1
 	groff -Tps -man $< > $@
@@ -21,3 +38,64 @@ ps/%.ps: man/man1/%.1
 clean:
 	rm -f pod2htm*.*~~ $(HTML) $(MAN) $(PS)
 
+else 
+
+LEVEL := ../..
+
+include $(LEVEL)/Makefile.common
+
+POD := $(wildcard $(PROJ_SRC_DIR)/*.pod)
+
+EXTRA_DIST := $(POD) index.html
+
+HTML = $(patsubst $(PROJ_SRC_DIR)/%.pod, $(PROJ_OBJ_DIR)/%.html, $(POD))
+MAN = $(patsubst $(PROJ_SRC_DIR)/%.pod, $(PROJ_OBJ_DIR)/%.1, $(POD))
+PS = $(patsubst $(PROJ_SRC_DIR)/%.pod, $(PROJ_OBJ_DIR)/%.ps, $(POD))
+
+.SUFFIXES:
+.SUFFIXES: .html .pod .1 .ps
+
+$(HTML) : html/.dir man/.dir man/man1/.dir ps/.dir
+
+html: $(HTML)
+
+$(PROJ_OBJ_DIR)/%.html: %.pod
+	$(POD2HTML) --css=manpage.css --htmlroot=. --podpath=. \
+	  --noindex --infile=$< --outfile=$@ --title=$*
+
+$(PROJ_OBJ_DIR)/%.1: %.pod
+	$(POD2MAN) --release=$(LLVMVersion) \
+	  --center="LLVM Command Guide" $< $@
+
+$(PROJ_OBJ_DIR)/%.ps: $(PROJ_OBJ_DIR)/%.1
+	$(GROFF) -Tps -man $< > $@
+
+clean-local::
+	$(Verb) $(RM) -f pod2htm*.*~~ $(HTML) $(MAN) $(PS)
+
+HTML_DIR := $(PROJ_docsdir)/html/CommandGuide
+MAN_DIR  := $(PROJ_mandir)/man1
+PS_DIR   := $(PROJ_docsdir)/ps
+
+install-local:: $(HTML) $(MAN) $(PS)
+	$(Echo) Installing HTML CommandGuide Documentation
+	$(Verb) $(MKDIR) $(HTML_DIR)
+	$(Verb) $(DataInstall) $(HTML) $(HTML_DIR)
+	$(Verb) $(DataInstall) $(PROJ_SRC_DIR)/index.html $(HTML_DIR)
+	$(Verb) $(DataInstall) $(PROJ_SRC_DIR)/manpage.css $(HTML_DIR)
+	$(Echo) Installing MAN CommandGuide Documentation
+	$(Verb) $(MKDIR) $(MAN_DIR)
+	$(Verb) $(DataInstall) $(MAN) $(MAN_DIR)
+	$(Echo) Installing PS CommandGuide Documentation
+	$(Verb) $(MKDIR) $(PS_DIR)
+	$(Verb) $(DataInstall) $(PS) $(PS_DIR)
+
+uninstall-local::
+	$(Echo) Uninstalling Documentation
+	$(Verb) $(RM) -rf $(LLVM_DOCSDIR)
+
+printvars::
+	$(Echo) "POD            : " '$(POD)'
+	$(Echo) "HTML           : " '$(HTML)'
+
+endif

llvm/docs/CommandGuide/bugpoint.pod

@@ -15,140 +15,9 @@ B<bugpoint> narrows down the source of problems in LLVM 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 JIT compilers).  It aims to reduce large test cases to small, useful ones.
-For example, if B<gccas> 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.
-
-=head2 Design Philosophy
-
-B<bugpoint> is designed to be a useful tool without requiring any hooks into the
-LLVM infrastructure at all.  It works with any and all LLVM passes and code
-generators, and does not need to "know" how they work.  Because of this, it may
-appear to do stupid things or miss obvious simplifications.  B<bugpoint> is also
-designed to trade off programmer time for computer time in the
-compiler-debugging process; consequently, it may take a long period of
-(unattended) time to reduce a test case, but we feel it is still worth it. Note
-that B<bugpoint> is generally very quick unless debugging a miscompilation where
-each test of the program (which requires executing it) takes a long time.
-
-=head2 Automatic Debugger Selection
-
-B<bugpoint> reads each F<.bc> or F<.ll> file specified on the command line and
-links them together into a single module, called the test program.  If any LLVM
-passes are specified on the command line, it runs these passes on the test
-program.  If any of the passes crash, or if they produce malformed output (which
-causes the verifier to abort), B<bugpoint> starts the crash debugger.
-
-Otherwise, if the B<-output> option was not specified, B<bugpoint> runs the test
-program with the C backend (which is assumed to generate good code) to generate
-a reference output.  Once B<bugpoint> has a reference output for the test
-program, it tries executing it with the selected code generator.  If the
-selected code generator crashes, B<bugpoint> starts the L</Crash debugger> on
-the code generator.  Otherwise, if the resulting output differs from the
-reference output, it assumes the difference resulted from a code generator
-failure, and starts the L</Code generator debugger>.
-
-Finally, if the output of the selected code generator matches the reference
-output, B<bugpoint> runs the test program after all of the LLVM passes have been
-applied to it.  If its output differs from the reference output, it assumes the
-difference resulted from a failure in one of the LLVM passes, and enters the
-miscompilation debugger. Otherwise, there is no problem B<bugpoint> can debug.
-
-=head2 Crash debugger
-
-If an optimizer or code generator crashes, B<bugpoint> will try as hard as it
-can to reduce the list of passes (for optimizer crashes) and the size of the
-test program.  First, B<bugpoint> figures out which combination of optimizer
-passes triggers the bug. This is useful when debugging a problem exposed by
-B<gccas>, for example, because it runs over 38 passes.
-
-Next, B<bugpoint> tries removing functions from the test program, to reduce its
-size.  Usually it is able to reduce a test program to a single function, when
-debugging intraprocedural optimizations.  Once the number of functions has been
-reduced, it attempts to delete various edges in the control flow graph, to
-reduce the size of the function as much as possible.  Finally, B<bugpoint>
-deletes any individual LLVM instructions whose absence does not eliminate the
-failure.  At the end, B<bugpoint> should tell you what passes crash, give you a
-bytecode file, and give you instructions on how to reproduce the failure with
-B<opt>, B<analyze>, or B<llc>.
-
-=head2 Code generator debugger
-
-The code generator debugger attempts to narrow down the amount of code that is
-being miscompiled by the selected code generator.  To do this, it takes the test
-program and partitions it into two pieces: one piece which it compiles with the
-C backend (into a shared object), and one piece which it runs with either the
-JIT or the static compiler (B<llc>).  It uses several techniques to reduce the
-amount of code pushed through the LLVM code generator, to reduce the potential
-scope of the problem.  After it is finished, it emits two bytecode files (called
-"test" [to be compiled with the code generator] and "safe" [to be compiled with
-the C backend], respectively), and instructions for reproducing the problem.
-The code generator debugger assumes that the C backend produces good code.
-
-=head2 Miscompilation debugger
-
-The miscompilation debugger works similarly to the code generator debugger.  It
-works by splitting the test program into two pieces, running the optimizations
-specified on one piece, linking the two pieces back together, and then executing
-the result.  It attempts to narrow down the list of passes to the one (or few)
-which are causing the miscompilation, then reduce the portion of the test
-program which is being miscompiled.  The miscompilation debugger assumes that
-the selected code generator is working properly.
-
-=head2 Advice for using bugpoint
-
-B<bugpoint> can be a remarkably useful tool, but it sometimes works in
-non-obvious ways.  Here are some hints and tips:
-
-=over
-
-=item *
-
-In the code generator and miscompilation debuggers, B<bugpoint> only
-works with programs that have deterministic output.  Thus, if the program
-outputs C<argv[0]>, the date, time, or any other "random" data, B<bugpoint> may
-misinterpret differences in these data, when output, as the result of a
-miscompilation.  Programs should be temporarily modified to disable outputs that
-are likely to vary from run to run.
-
-=item *
-
-In the code generator and miscompilation debuggers, debugging will go faster if
-you manually modify the program or its inputs to reduce the runtime, but still
-exhibit the problem.
-
-=item *
-
-B<bugpoint> is extremely useful when working on a new optimization: it helps
-track down regressions quickly.  To avoid having to relink B<bugpoint> every
-time you change your optimization, make B<bugpoint> dynamically load
-your optimization by using the B<-load> option.
-
-=item *
-
-B<bugpoint> can generate a lot of output and run for a long period of time.  It
-is often useful to capture the output of the program to file.  For example, in
-the C shell, you can type:
-
-    bugpoint ... |& tee bugpoint.log
-
-to get a copy of B<bugpoint>'s output in the file F<bugpoint.log>, as well as on
-your terminal.
-
-=item *
-
-B<bugpoint> cannot debug problems with the LLVM linker. If B<bugpoint> crashes
-before you see its C<All input ok> message, you might try running C<llvm-link
--v> on the same set of input files. If that also crashes, you may be
-experiencing a linker bug.
-
-=item *
-
-If your program is supposed to crash, B<bugpoint> will be confused. One way to
-deal with this is to cause B<bugpoint> to ignore the exit code from your
-program, by giving it the B<-check-exit-code=false> option.
-
-=back
+For more information on the design and inner workings of B<bugpoint>, as well as
+advice for using bugpoint, see F<llvm/docs/Bugpoint.html> in the LLVM
+distribution.
 
 =head1 OPTIONS
 

llvm/docs/CommandGuide/gccld.pod

@@ -112,7 +112,7 @@ Do not mark all symbols as internal.
 
 Preserve the list of symbol names in the file filename.
 
-=item B<-internalize-public-api-list &lt;list&gt;>
+=item B<-internalize-public-api-list> I<list>
 
 Preserve the symbol names in list.
 

llvm/docs/CommandGuide/html/.cvsignore

@@ -1 +1,2 @@
 *html
+.dir

llvm/docs/CommandGuide/index.html

@@ -48,18 +48,30 @@ options) arguments to the tool you are interested in.</p>
     directly run a program compiled to bytecode using a JIT compiler or 
     interpreter</li>
 
-<li><a href="html/llvm-link.html"><b>llvm-link</b></A>
+<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-nm.html"><b>llvm-nm</b></a>
+<li><a href="html/llvm-ar.html"><b>llvm-ar</b></a> - 
+    archive bytecode files</li>
+
+<li><a href="html/llvm-ranlib.html"><b>llvm-ranlib</b></a> - 
+    create an index for archives made with llvm-ar</li>
+
+<li><a href="html/llvm-nm.html"><b>llvm-nm</b></a> -
     print out the names and types of symbols in a bytecode file</li>
 
 <li><a href="html/llvm-prof.html"><b>llvm-prof</b></a> -
     format raw `<tt>llvmprof.out</tt>' data into a human-readable report</li>
 
+<li><a href="html/llvmc.html"><b>llvmc</b></a> -
+  generic and configurable compiler driver</li>
+
+<li><a href="html/llvm-ld.html"><b>llvm-ld</b></a> -
+  general purpose linker with loadable runtime optimization support</li>
+
 </ul>
 
 </div>
@@ -107,7 +119,7 @@ options) arguments to the tool you are interested in.</p>
 <li><a href="html/bugpoint.html"><b>bugpoint</b></a> -
     automatic test-case reducer</li>
 
-<li><a href="html/extract.html"><b>extract</b></a> -
+<li><a href="html/llvm-extract.html"><b>llvm-extract</b></a> -
     extract a function from an LLVM bytecode file</li>
 
 <li><a href="html/llvm-bcanalyzer.html"><b>llvm-bcanalyzer</b></a> -

llvm/docs/CommandGuide/llc.pod

@@ -12,36 +12,11 @@ B<llc> [I<options>] [I<filename>]
 
 The B<llc> command compiles LLVM bytecode into assembly language for a
 specified architecture.  The assembly language output can then be passed through
-a native assembler and linker to generate native code.
+a native assembler and linker to generate a native executable.
 
-The choice of architecture for the output assembly code is determined as
-follows, by attempting to satisfy each of the following rules in turn (first
-one wins):
-
-=over
-
-=item *
-
-If the user has specified an architecture with the -m option, use that
-architecture.
-
-=item *
-
-Examine the input LLVM bytecode file: if it is little endian and has a
-pointer size of 32 bits, select the Intel IA-32 architecture.  If it is big
-endian and has a pointer size of 64 bits, select the SparcV9 architecture.
-
-=item *
-
-If B<llc> was compiled on an architecture for which it can generate code, select
-the architecture upon which B<llc> was compiled.
-
-=item *
-
-Exit with an error message telling the user to specify the output
-architecture explicitly.
-
-=back
+The choice of architecture for the output assembly code is automatically
+determined from the input bytecode file, unless the B<-march> option is used to
+override the default.
 
 =head1 OPTIONS
 
@@ -58,8 +33,14 @@ removing any existing F<.bc> extension, and adding a F<.s> suffix.
 
 Other B<llc> options are as follows:
 
+=head2 End-user Options
+
 =over
 
+=item B<--help>
+
+Print a summary of command line options.
+
 =item B<-f>
 
 Overwrite output files. By default, B<llc> will refuse to overwrite
@@ -67,60 +48,56 @@ an output file which already exists.
 
 =item B<-march>=I<arch>
 
-Specify the architecture for which to generate assembly.  Valid
-architectures are:
-
-=over
-
-=item I<x86>
-
-Intel IA-32 (Pentium and above)
-
-=item I<sparcv9>
-
-64-bit SPARC V9
-
-=item I<c>
-
-Emit C code, not assembly
-
-=back
-
-=item B<-enable-correct-eh-support>
-
-Instruct the B<-lowerinvoke> pass to insert code for correct exception handling
-support.  This is expensive and is by default omitted for efficiency.
-
-=item B<-help>
-
-Print a summary of command line options.
-
-=item B<-stats>
-
-Print statistics recorded by code-generation passes.
-
-=item B<-time-passes>
-
-Record the amount of time needed for each pass and print a report to standard
-error.
-
-=back
-
-=head2 Intel IA-32-specific Options
-
-=over
+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.
 
 =item B<--disable-fp-elim>
 
 Disable frame pointer elimination optimization.
 
-=item B<--disable-pattern-isel>
+=item B<--disable-excess-fp-precision>
 
-Use the 'simple' X86 instruction selector (the default).
+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).
+
+=item B<--enable-unsafe-fp-math>
+
+Enable optimizations that make unsafe assumptions about IEEE 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).
+
+=item B<--enable-correct-eh-support>
+
+Instruct the B<lowerinvoke> pass to insert code for correct exception handling
+support.  This is expensive and is by default omitted for efficiency.
+
+=item B<--stats>
+
+Print statistics recorded by code-generation passes.
+
+=item B<--time-passes>
+
+Record the amount of time needed for each pass and print a report to standard
+error.
+
+=item B<--load>=F<dso_path>
+
+Dynamically load F<dso_path> (a path to a dynamically shared object) that
+implements an LLVM target. This will permit the target name to be used with the
+B<-march> option so that code can be generated for that target.
+
+=back
+
+=head2 Tuning/Configuration Options
+
+=over
 
 =item B<--print-machineinstrs>
 
-Print generated machine code.
+Print generated machine code between compilation phases (useful for debugging).
 
 =item B<--regalloc>=I<allocator>
 
@@ -167,6 +144,17 @@ Local spiller
 
 =back
 
+=head2 Intel IA-32-specific Options
+
+=over
+
+=item B<--x86-asm-syntax=att|intel>
+
+Specify whether to emit assembly code in AT&T syntax (the default) or intel
+syntax.
+
+=back
+
 =head2 SPARCV9-specific Options
 
 =over
@@ -179,15 +167,6 @@ Disable peephole optimization pass.
 
 Disable local scheduling pass.
 
-=item B<--disable-strip>
-
-The Sparc backend embeds the LLVM bytecode into the assembly output.  This
-option requests that symbol names be retained; by default, they are stripped out.
-
-=item B<--enable-maps>
-
-Emit LLVM-to-machine code mapping information into the assembly output.
-
 =back
 
 =head1 EXIT STATUS

llvm/docs/CommandGuide/llvm-ar.pod

@@ -0,0 +1,406 @@
+=pod
+
+=head1 NAME
+
+llvm-ar - LLVM archiver
+
+=head1 SYNOPSIS
+
+B<llvm-ar> [-]{dmpqrtx}[Rabfikouz] [relpos] [count] <archive> [files...]
+
+
+=head1 DESCRIPTION
+
+The B<llvm-ar> command is similar to the common Unix utility, C<ar>. It 
+archives several files together into a single file. The intent for this is
+to produce archive libraries by LLVM bytecode that can be linked into an
+LLVM program. However, the archive can contain any kind of file. By default,
+B<llvm-ar> 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. 
+
+The B<llvm-ar> command can be used to I<read> both SVR4 and BSD style archive
+files. However, it cannot be used to write them.  While the B<llvm-ar> command 
+produces files that are I<almost> identical to the format used by other C<ar> 
+implementations, it has two significant departures in order to make the 
+archive appropriate for LLVM. The first departure is that B<llvm-ar> only
+uses BSD4.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 B<llvm-ar> usually won't be readable or editable with any
+C<ar> implementation or useful for linking.  Using the C<f> modifier to flatten
+file names will make the archive readable by other C<ar> implementations
+but not for linking because the symbol table format for LLVM is unique. If an
+SVR4 or BSD style archive is used with the C<r> (replace) or C<q> (quick
+update) operations, the archive will be reconstructed in LLVM format. This 
+means that the string table will be dropped (in deference to BSD 4.4 long names)
+and an LLVM symbol table will be added (by default). The system symbol table
+will be retained.
+
+Here's where B<llvm-ar> departs from previous C<ar> implementations:
+
+=over
+
+=item I<Symbol Table>
+
+Since B<llvm-ar> is intended to archive bytecode files, the symbol table
+won't make much sense to anything but LLVM. 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 LSB 4byte integer and a null-terminated 
+string.
+
+=item I<Long Paths>
+
+Some C<ar> implementations (SVR4) use a separate file member to record long
+path names (> 15 characters). B<llvm-ar> takes the BSD 4.4 and Mac OS 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. 
+
+=item I<Compression>
+
+B<llvm-ar> 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 LLVM Compressor utility makes. It generally favors bzip2 but will select
+between "no compression" or bzip2 depending on what makes sense for the
+file's content.
+
+=item I<Directory Recursion>
+
+Most C<ar> implementations do not recurse through directories but simply
+ignore directories if they are presented to the program in the F<files> 
+option. B<llvm-ar>, however, can recurse through directory structures and
+add all the files under a directory, if requested.
+
+=item I<TOC Verbose Output>
+
+When B<llvm-ar> prints out the verbose table of contents (C<tv> 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 LLVM bytecode file. An
+'S' means the file is the symbol table.
+
+=back
+
+=head1 OPTIONS
+
+The options to B<llvm-ar> are compatible with other C<ar> implementations.
+However, there are a few modifiers (F<zR>) that are not found in other
+C<ar>s. The options to B<llvm-ar> 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 B<llvm-ar> should process the archive file.
+
+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 C<.a> suffix, but this is not required. Following
+the F<archive-name> comes a list of F<files> that indicate the specific members
+of the archive to operate on. If the F<files> option is not specified, it
+generally means either "none" or "all" members, depending on the operation.
+
+=head2 Operations
+
+=over
+
+=item d
+
+Delete files from the archive. No modifiers are applicable to this operation.
+The F<files> 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 F<files> are specified, the archive is not modified.
+
+=item m[abi]
+
+Move files from one location in the archive to another. The F<a>, F<b>, and 
+F<i> modifiers apply to this operation. The F<files> 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 F<files> are specified, the
+archive is not modified.
+
+=item p[k]
+
+Print files to the standard output. The F<k> modifier applies to this
+operation. This operation simply prints the F<files> indicated to the
+standard output. If no F<files> are specified, the entire archive is printed.
+Printing bytecode files is ill-advised as they might confuse your terminal
+settings. The F<p> operation never modifies the archive.
+
+=item q[Rfz]
+
+Quickly append files to the end of the archive. The F<R>, F<f>, and F<z>
+modifiers apply to this operation.  This operation quickly adds the 
+F<files> to the archive without checking for duplicates that should be 
+removed first. If no F<files> are specified, the archive is not modified. 
+Because of the way that B<llvm-ar> constructs the archive file, its dubious 
+whether the F<q> operation is any faster than the F<r> operation.
+
+=item r[Rabfuz]
+
+Replace or insert file members. The F<R>, F<a>, F<b>, F<f>, F<u>, and F<z>
+modifiers apply to this operation. This operation will replace existing
+F<files> or insert them at the end of the archive if they do not exist. If no
+F<files> are specified, the archive is not modified.
+
+=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 F<v> modifier,
+B<llvm-ar> 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 F<files> are specified, the listing is only for
+those files. If no F<files> are specified, the table of contents for the
+whole archive is printed.
+
+=item x[oP]
+
+Extract archive members back to files. The F<o> modifier applies to this
+operation. This operation retrieves the indicated F<files> from the archive 
+and writes them back to the operating system's file system. If no 
+F<files> are specified, the entire archive is extract. 
+
+=back
+
+=head2 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.
+
+=over
+
+=item [a] 
+
+When inserting or moving member files, this option specifies the destination of
+the new files as being C<a>fter the F<relpos> member. If F<relpos> is not found,
+the files are placed at the end of the archive.
+
+=item [b] 
+
+When inserting or moving member files, this option specifies the destination of
+the new files as being C<b>efore the F<relpos> member. If F<relpos> is not 
+found, the files are placed at the end of the archive. This modifier is 
+identical to the the F<i> modifier.
+
+=item [f] 
+
+Normally, B<llvm-ar> 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 C<ar> but may also
+thwart correct extraction of the files (duplicates may overwrite). If used with
+the F<R> option, the directory recursion will be performed but the file names
+will all be C<f>lattened to simple file names.
+
+=item [i] 
+
+A synonym for the F<b> option.
+
+=item [k] 
+
+Normally, B<llvm-ar> will not print the contents of bytecode files when the 
+F<p> operation is used. This modifier defeats the default and allows the 
+bytecode members to be printed.
+
+=item [N] 
+
+This option is ignored by B<llvm-ar> but provided for compatibility.
+
+=item [o] 
+
+When extracting files, this option will cause B<llvm-ar> to preserve the
+original modification times of the files it writes. 
+
+=item [P] 
+
+use full path names when matching
+
+=item [R]
+
+This modifier instructions the F<r> option to recursively process directories.
+Without F<R>, directories are ignored and only those F<files> that refer to
+files will be added to the archive. When F<R> is used, any directories specified
+with F<files> 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.
+
+=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.
+
+=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.
+
+=back
+
+=head2 Modifiers (generic)
+
+The modifiers below may be applied to any operation.
+
+=over
+
+=item [c]
+
+For all operations, B<llvm-ar> will always create the archive if it doesn't 
+exist. Normally, B<llvm-ar> will print a warning message indicating that the
+archive is being created. Using this modifier turns off that warning.
+
+=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
+L<llvm-ranlib|llvm-ranlib> which also creates the symbol table.
+
+=item [S]
+
+This modifier is the opposite of the F<s> modifier. It instructs B<llvm-ar> to
+not build the symbol table. If both F<s> and F<S> are used, the last modifier to
+occur in the options will prevail. 
+
+=item [v]
+
+This modifier instructs B<llvm-ar> 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.
+
+=back
+
+=head1 STANDARDS
+
+The B<llvm-ar> utility is intended to provide a superset of the IEEE Std 1003.2
+(POSIX.2) functionality for C<ar>. B<llvm-ar> can read both SVR4 and BSD4.4 (or
+Mac OS X) archives. If the C<f> modifier is given to the C<x> or C<r> operations
+then B<llvm-ar> will write SVR4 compatible archives. Without this modifier, 
+B<llvm-ar> will write BSD4.4 compatible archives that have long names
+immediately after the header and indicated using the "#1/ddd" notation for the
+name in the header.
+
+=head1 FILE FORMAT
+
+The file format for LLVM Archive files is similar to that of BSD 4.4 or Mac OSX
+archive files. In fact, except for the symbol table, the C<ar> commands on those
+operating systems should be able to read LLVM archive files. The details of the
+file format follow.
+
+Each archive begins with the archive magic number which is the eight printable
+characters "!<arch>\n" where \n 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 \n padding character if necessary 
+(to make the length even). Each file member is composed of a header (defined 
+below), an optional newline-terminated "long file name" and the contents of 
+the file. 
+
+The fields of the header are described in the items below. All fields of the
+header contain only ASCII characters, are left justified and are right padded 
+with space characters.
+
+=over
+
+=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 C<#1/nnn> where C<nnn> provides the length of the name and the C<#1/>
+is literal.  In this case, the actual name of the file is provided in the C<nnn>
+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.
+
+=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.
+
+=item uid - char[6]
+
+This field provides the user id of the file encoded as a decimal ASCII 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 stat(2)
+operating system call.
+
+=item gid - char[6]
+
+This field provides the group id of the file encoded as a decimal ASCII 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 stat(2)
+operating system call.
+
+=item mode - char[8]
+
+This field provides the access mode of the file encoded as an octal ASCII 
+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 
+stat(2) operating system call.
+
+=item size - char[10]
+
+This field provides the size of the file, in bytes, encoded as a decimal ASCII
+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.
+
+=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.
+
+=back 
+
+The LLVM symbol table has the special name "#_LLVM_SYM_TAB_#". It is presumed
+that no regular archive member file will want this name. The LLVM 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:
+
+=over
+
+=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 "normal" 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.
+
+=item length - vbr encoded 32-bit integer
+
+The length item provides the length of the symbol that follows. Like this
+I<offset> item, the length is variable bit rate encoded.
+
+=item symbol - character array
+
+The symbol item provides the text of the symbol that is associated with the
+I<offset>. The symbol is not terminated by any character. Its length is provided
+by the I<length> 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.
+
+=back
+
+=head1 EXIT STATUS
+
+If B<llvm-ar> 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.
+
+=head1 SEE ALSO
+
+L<llvm-ranlib|llvm-ranlib>, L<ar(1)>
+
+=head1 AUTHORS
+
+Maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
+
+=cut

llvm/docs/CommandGuide/llvm-as.pod

@@ -10,9 +10,9 @@ B<llvm-as> [I<options>] [I<filename>]
 
 =head1 DESCRIPTION
 
-The B<llvm-as> command invokes the LLVM assembler.  It reads a file containing
-human-readable LLVM assembly language, translates it to LLVM bytecode, and
-writes the result into a file or to standard output.
+B<llvm-as> is the LLVM assembler.  It reads a file containing human-readable
+LLVM assembly language, translates it to LLVM bytecode, and writes the result
+into a file or to standard output.
 
 If F<filename> is omitted or is C<->, then B<llvm-as> reads its input from
 standard input.
@@ -59,15 +59,6 @@ Print a summary of command line options.
 Specify the output file name.  If F<filename> is C<->, then B<llvm-as>
 sends its output to standard output.
 
-=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

llvm/docs/CommandGuide/llvm-bcanalyzer.pod

@@ -6,21 +6,20 @@ llvm-bcanalyzer - LLVM bytecode analyzer
 
 =head1 SYNOPSIS
 
-B<llvm-bcanalyzer> [I<options>] [I<filename>]
+B<llvm-bcanalyzer> [I<options>] [F<filename>]
 
 =head1 DESCRIPTION
 
 The B<llvm-bcanalyzer> command is a small utility for analyzing bytecode files.
 The tool reads a bytecode file (such as generated with the B<llvm-as> tool) and
 produces a statistical report on the contents of the byteocde file.  The tool
-will also dump a low level but human readable version of the bytecode file. 
+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 LLVM users can just ignore
 this tool.
 
 If F<filename> is omitted or is C<->, then B<llvm-bcanalyzer> reads its input 
 from standard input. This is useful for combining the tool into a pipeline.
-
 Output is written to the standard output.
 
 =head1 OPTIONS
@@ -36,11 +35,11 @@ level summary. The details for individual functions are not displayed.
 
 Causes B<llvm-bcanalyzer> to dump the bytecode in a human readable format. This 
 format is significantly different from LLVM assembly and provides details about 
-the encoding of the bytecode file. 
+the encoding of the bytecode file.
 
 =item B<-verify>
 
-Causes B<llvm-bcanalyzer> to verify the module produced by by reading the 
+Causes B<llvm-bcanalyzer> to verify the module produced by reading the 
 bytecode. This ensures that the statistics generated are based on a consistent
 module.
 
@@ -55,6 +54,256 @@ Print a summary of command line options.
 If B<llvm-bcanalyzer> succeeds, it will exit with 0.  Otherwise, if an error
 occurs, it will exit with a non-zero value, usually 1.
 
+=head1 SUMMARY OUTPUT DEFINITIONS
+
+The following items are always printed by llvm-bcanalyzer. They comprize the
+summary output.
+
+=over
+
+=item B<Bytecode Analysis Of Module>
+
+This just provides the name of the module for which bytecode analysis is being
+generated.
+
+=item B<Bytecode Version Number>
+
+The bytecode version (not LLVM version) of the file read by the analyzer.
+
+=item B<File Size>
+
+The size, in bytes, of the entire bytecode file.
+
+=item B<Module Bytes>
+
+The size, in bytes, of the module block. Percentage is relative to File Size.
+
+=item B<Function Bytes>
+
+The size, in bytes, of all the function blocks. Percentage is relative to File
+Size.
+
+=item B<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.
+
+=item B<Constant Pool Bytes>
+
+The size, in bytes, of the Constant Pool Blocks Percentage is relative to File
+Size.
+
+=item B<Module Globals Bytes>
+
+Ths size, in bytes, of the Global Variable Definitions and their initializers.
+Percentage is relative to File Size.
+
+=item B<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.
+
+=item B<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.
+
+=item B<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.
+
+=item B<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.
+
+=item B<Number Of Bytecode Blocks>
+
+The total number of blocks of any kind in the bytecode file.
+
+=item B<Number Of Functions>
+
+The total number of function definitions in the bytecode file.
+
+=item B<Number Of Types>
+
+The total number of types defined in the Global Types Pool.
+
+=item B<Number Of Constants>
+
+The total number of constants (of any type) defined in the Constant Pool.
+
+=item B<Number Of Basic Blocks>
+
+The total number of basic blocks defined in all functions in the bytecode file.
+
+=item B<Number Of Instructions>
+
+The total number of instructions defined in all functions in the bytecode file.
+
+=item B<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, PHI nodes, and calls to
+functions with large numbers of arguments.
+
+=item B<Number Of Operands>
+
+The total number of operands used in all instructions in the bytecode file.
+
+=item B<Number Of Compaction Tables>
+
+The total number of compaction tables in all functions in the bytecode file.
+
+=item B<Number Of Symbol Tables>
+
+The total number of symbol tables in all functions in the bytecode file.
+
+=item B<Number Of Dependent Libs>
+
+The total number of dependent libraries found in the bytecode file.
+
+=item B<Total Instruction Size>
+
+The total size of the instructions in all functions in the bytecode file.
+
+=item B<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.
+
+=item B<Maximum Type Slot Number>
+
+The maximum value used for a type's slot number. Larger slot number values take 
+more bytes to encode.
+
+=item B<Maximum Value Slot Number>
+
+The maximum value used for a value's slot number. Larger slot number values take 
+more bytes to encode.
+
+=item B<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.
+
+=item B<Bytes Per Global>
+
+The average size of a global definition (constants and global variables).
+
+=item B<Bytes Per Function>
+
+The average number of bytes per function definition. This is computed by
+dividing Function Bytes by Number Of Functions.
+
+=item B<# of VBR 32-bit Integers>
+
+The total number of 32-bit integers encoded using the Variable Bit Rate
+encoding scheme.
+
+=item B<# of VBR 64-bit Integers>
+
+The total number of 64-bit integers encoded using the Variable Bit Rate encoding
+scheme.
+
+=item B<# 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.
+
+=item B<# 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.
+
+=item B<Bytes Saved With VBR>
+
+The total number of bytes saved by using the Variable Bit Rate encoding scheme.
+The percentage is relative to # of VBR Expanded Bytes.
+
+=back
+
+=head1 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.
+
+=over
+
+=item B<Type>
+
+The type signature of the function.
+
+=item B<Byte Size>
+
+The total number of bytes in the function's block.
+
+=item B<Basic Blocks>
+
+The number of basic blocks defined by the function.
+
+=item B<Instructions>
+
+The number of instructions defined by the function.
+
+=item B<Long Instructions>
+
+The number of instructions using the long instruction format in the function.
+
+=item B<Operands>
+
+The number of operands used by all instructions in the function.
+
+=item B<Instruction Size>
+
+The number of bytes consumed by instructions in the function.
+
+=item B<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.
+
+=item B<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.
+
+=item B<Number of VBR 32-bit Integers>
+
+The total number of 32-bit integers found in this function (for any use).
+
+=item B<Number of VBR 64-bit Integers>
+
+The total number of 64-bit integers found in this function (for any use).
+
+=item B<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.
+
+=item B<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.
+
+=item B<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 VBR Expanded Bytes.
+
+=back
+
 =head1 SEE ALSO
 
 L<llvm-dis|llvm-dis>, L<http://llvm.cs.uiuc.edu/docs/BytecodeFormat.html>

llvm/docs/CommandGuide/llvm-dis.pod

@@ -42,11 +42,6 @@ Print a summary of command line options.
 Specify the output file name.  If F<filename> is -, then the output is sent
 to standard output.
 
-=item B<-time-passes>
-
-Record the amount of time needed for each pass and print it to standard
-error.
-
 =back
 
 =head1 EXIT STATUS

llvm/docs/CommandGuide/llvm-extract.pod

@@ -2,23 +2,23 @@
 
 =head1 NAME
 
-extract - extract a function from an LLVM module
+llvm-extract - extract a function from an LLVM module
 
 =head1 SYNOPSIS
 
-B<extract> [I<options>] B<--func> I<function-name> [I<filename>]
+B<llvm-extract> [I<options>] B<--func> I<function-name> [I<filename>]
 
 =head1 DESCRIPTION
 
-The B<extract> command takes the name of a function and extracts it from
+The B<llvm-extract> command takes the name of a function and extracts it from
 the specified LLVM bytecode file.  It is primarily used as a debugging tool to
 reduce test cases from larger programs that are triggering a bug.
 
 In addition to extracting the bytecode of the specified function,
-B<extract> will also remove unreachable global variables, prototypes, and
+B<llvm-extract> will also remove unreachable global variables, prototypes, and
 unused types.
 
-The B<extract> command reads its input from standard input if filename is
+The B<llvm-extract> 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 B<-o> option is specified (see below).
 
@@ -28,8 +28,8 @@ unless the B<-o> option is specified (see below).
 
 =item B<-f>
 
-Force overwrite.  Normally, B<extract> will refuse to overwrite an
-output file that already exists.  With this option, B<extract>
+Force overwrite.  Normally, B<llvm-extract> will refuse to overwrite an
+output file that already exists.  With this option, B<llvm-extract>
 will overwrite the output file and replace it with new bytecode.
 
 =item B<--func> I<function-name>
@@ -43,22 +43,13 @@ Print a summary of command line options.
 =item B<-o> I<filename>
 
 Specify the output filename.  If filename is "-" (the default), then
-B<extract> sends its output to standard output.
-
-=item B<--stats>
-
-Print statistics.
-
-=item B<--time-passes>
-
-Record the amount of time needed for each pass and print it to standard
-error.
+B<llvm-extract> sends its output to standard output.
 
 =back
 
 =head1 EXIT STATUS
 
-If B<extract> succeeds, it will exit with 0.  Otherwise, if an error
+If B<llvm-extract> succeeds, it will exit with 0.  Otherwise, if an error
 occurs, it will exit with a non-zero value.
 
 =head1 SEE ALSO

llvm/docs/CommandGuide/llvm-ld.pod

@@ -0,0 +1,171 @@
+=pod
+
+=head1 NAME
+
+llvm-ld - LLVM linker
+
+=head1 SYNOPSIS
+
+B<llvm-ld> <options> <files>
+
+=head1 DESCRIPTION
+
+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 Input/Output Options
+
+=over
+
+=item B<-o> F<filename>
+
+This overrides the default output file and specifies the name of the file that
+should be generated by the linker. By default, B<llvm-ld> generates a file named
+F<a.out> for compatibility with B<ld>. The output will be written to
+F<filename>.
+
+=item B<-l>F<name>
+
+This option specifies the F<name> of a library to search when resolving symbols
+for the program. Only the base name should be specified as F<name>, without a
+F<lib> prefix or any suffix. 
+
+=item B<-L>F<Path>
+
+This option tells B<llvm-ld> to look in F<Path> to find any library subsequently
+specified with the B<-l> 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 B<-l> option that occur I<before> any B<-L> options
+will not search the paths given by the B<-L> options following it.
+
+=item B<-link-as-library>
+
+Link the bytecode files together as a library, not an executable. In this mode,
+undefined symbols will be permitted.
+
+=item B<-r>
+
+An alias for -link-as-library.
+
+=item B<-march=>C<target>
+
+Specifies the kind of machine for which code or assembly should be generated.
+
+=item B<-native>
+
+Generate a native binary instead of a shell script that runs the JIT from
+bytecode.
+
+=item B<-native-cbe>
+
+Generate a native binary with the C back end and compilation with GCC.
+
+=item B<-disable-compression>
+
+Do not compress bytecode files.
+
+=back
+
+=head2 Optimization Options
+
+=over 
+
+=item B<-O0>
+
+An alias for the -O1 option.
+
+=item B<-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.
+
+=item B<-O2>
+
+Perform only the minimal or required set of scalar optimizations.
+
+=item B<-03>
+
+An alias for the -O2 option.
+
+=item B<-04>
+
+Perform the standard link time inter-procedural optimizations. This will 
+attempt to optimize the program taking the entire program into consideration.
+
+=item B<-O5>
+
+Perform aggressive link time optimizations. This is the same as -O4 but works
+more aggressively to optimize the program.
+
+=item B<-disable-inlining>
+
+Do not run the inlining pass. Functions will not be inlined into other
+functions.
+
+=item B<-disable-opt>
+
+Completely disable optimization. The various B<-On> options will be ignored and
+no link time optimization passes will be run.
+
+=item B<-disable-internalize>
+
+Do not mark all symbols as internal.
+
+=item B<-verify>
+
+Run the verification pass after each of the passes to verify intermediate
+results.
+
+=item B<-s>
+
+Strip symbol info from the executable to make it smaller.
+
+=item B<-export-dynamic>
+
+An alias for -disable-internalize
+
+=item B<-load> F<module>
+
+Load an optimization module, F<module>, which is expected to be a dynamic
+library that provides the function name C<RunOptimizations>. This function will
+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.
+
+=back
+
+=head2 Miscellaneous Options
+
+=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
+
+=head1 EXIT STATUS
+
+If B<llvm-ld> succeeds, it will exit with 0 return code.  If an error occurs,
+it will exit with a non-zero return code.
+
+=head1 ENVIRONMENT
+
+The C<LLVM_LIB_SEARCH_PATH> environment variable is used to find bytecode
+libraries. Any paths specified in this variable will be searched after the C<-L>
+options.
+
+=head1 SEE ALSO
+
+L<llvm-ar|llvm-ar>
+
+=head1 AUTHORS
+
+Maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
+
+=cut

llvm/docs/CommandGuide/llvm-link.pod

@@ -10,15 +10,15 @@ B<llvm-link> [I<options>] I<filename ...>
 
 =head1 DESCRIPTION
 
-The B<llvm-link> command takes several LLVM bytecode files and links them
-together into a single LLVM bytecode file.  It writes the output file to
-standard output, unless the B<-o> option is used to specify a filename.
+B<llvm-link> takes several LLVM bytecode files and links them together into a
+single LLVM bytecode file.  It writes the output file to standard output, unless
+the B<-o> option is used to specify a filename.
 
-The B<llvm-link> command 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 B<-L> 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.
+B<llvm-link> 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
+B<-L> 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.
 
 =head1 OPTIONS
 
@@ -65,11 +65,10 @@ occurs, it will exit with a non-zero value.
 
 =head1 SEE ALSO
 
-L<gccld>
+L<gccld|gccld>
 
 =head1 AUTHORS
 
 Maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
 
 =cut
-

llvm/docs/CommandGuide/llvm-prof.pod

@@ -47,8 +47,8 @@ error.
 
 =head1 EXIT STATUS
 
-B<llvm-prof|llvm-prof> returns 1 if it cannot load the bytecode file or the
-profile information. Otherwise, it exits with zero.
+B<llvm-prof> returns 1 if it cannot load the bytecode file or the profile
+information. Otherwise, it exits with zero.
 
 =head1 AUTHOR
 

llvm/docs/CommandGuide/llvm-ranlib.pod

@@ -0,0 +1,52 @@
+=pod
+
+=head1 NAME
+
+llvm-ranlib - Generate index for LLVM archive
+
+=head1 SYNOPSIS
+
+B<llvm-ranlib> [--version] [--help] <archive-file>
+
+=head1 DESCRIPTION
+
+The B<llvm-ranlib> command is similar to the common Unix utility, C<ranlib>. It
+adds or updates the symbol table in an LLVM archive file. Note that using the
+B<llvm-ar> modifier F<s> is usually more efficient than running B<llvm-ranlib>
+which is only provided only for completness and compatibility. Unlike other 
+implementations of C<ranlib>, B<llvm-ranlib> indexes LLVM bytecode files, not
+native object modules. You can list the contents of the symbol table with the
+C<llvm-nm -s> command.
+
+=head1 OPTIONS
+
+=over
+
+=item F<archive-file>
+
+Specifies the archive-file to which the symbol table is added or updated.
+
+=item F<--version>
+
+Print the version of B<llvm-ranlib> and exit without building a symbol table.
+
+=item F<--help>
+
+Print usage help for B<llvm-ranlib> and exit without building a symbol table.
+
+=back
+
+=head1 EXIT STATUS
+
+If B<llvm-ranlib> succeeds, it will exit with 0.  If an error occurs, a non-zero
+exit code will be returned.
+
+=head1 SEE ALSO
+
+L<llvm-ar|llvm-ar>, ranlib(1)
+
+=head1 AUTHORS
+
+Maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
+
+=cut

llvm/docs/CommandGuide/llvmc.pod

@@ -0,0 +1,406 @@
+=pod
+
+=head1 NAME
+
+llvmc - The LLVM Compiler Driver
+
+=head1 SYNOPSIS
+
+B<llvmc> [I<options>] [I<filenames>...]
+
+=head1 DESCRIPTION
+
+The B<llvmc> command 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 the GNU Compiler 
+Collection's B<gcc> tool, it is very similar. This tool has the
+following main goals or purposes:
+
+=over
+
+=item * A Single point of access to the LLVM tool set.
+
+=item * Hide the complexities of the LLVM tools through a single interface.
+
+=item * Make integration of existing non-LLVM tools simple.
+
+=item * Extend the capabilities of minimal front ends.
+
+=item * Make the interface for compiling consistent for all languages.
+
+=back
+
+The tool itself does nothing with a user's program. It merely invokes other
+tools to get the compilation tasks done.
+
+The options supported by B<llvmc> 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 LLVM.
+Without B<llvmc>, developers would need to understand how to invoke the 
+front-end compiler, optimizer, assembler, and linker in order to compile their 
+programs. B<llvmc>'s sole mission is to trivialize that process.
+
+=head2 Basic Operation
+
+B<llvmc> always takes the following basic actions:
+
+=over
+
+=item * Command line options and filenames are collected.
+
+The command line options provide the marching orders to B<llvmc> on what actions
+it should perform. This is the I<request> the user is making of B<llvmc> and it
+is interpreted first.
+
+=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 B<llvmc> will take. 
+Configuration files are provided by either LLVM or the front end compiler tools
+that B<llvmc> invokes. Users generally don't need to be concerned with the
+contents of the configuration files. 
+
+=item * Determine actions to take.
+
+The tool chain needed to complete the task is determined. This is the primary 
+work of B<llvmc>. It breaks the request specified by the command line options 
+into a set of basic actions to be done: 
+
+=over
+
+=item * Pre-processing: gathering/filtering compiler input (optional).
+
+=item * Translation: source language to bytecode conversion.
+
+=item * Assembly: bytecode to native code conversion.
+
+=item * Optimization: conversion of bytecode to something that runs faster.
+
+=item * Linking: combining multiple bytecodes to produce executable program.
+
+=back
+
+=item * Execute actions.
+
+The actions determined previously are executed sequentially and then
+B<llvmc> terminates.
+
+=back
+
+=head1 OPTIONS
+
+=head2 Control Options
+
+Control options tell B<llvmc> what to do at a high level. The 
+following control options are defined:
+
+=over
+
+=item B<-c> or B<--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.
+
+=item B<-k> or B<--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. 
+
+=item B<-S>
+
+This option specifies that compilation should end in the creation of
+an LLVM assembly file that can be later converted to an LLVM object
+file.
+
+=item B<-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.
+
+=back
+
+=head2 Optimization Options
+
+Optimization with B<llvmc> 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. 
+
+=over
+
+=item B<-O1> or B<-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.
+
+=item B<-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.
+
+=item B<-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 B<-O1> and B<-O2> 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 IPO.
+
+=item B<-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.
+
+=item B<-O5> (aggressive link time optimization)
+
+This is the same as B<-O4> except it employs aggressive analyses and
+aggressive inter-procedural optimization. 
+
+=item B<-O6> (profile guided optimization: not implemented)
+
+This is the same as B<-O5> 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.
+
+=item B<-O7> (lifelong optimization: not implemented)
+
+This is the same as B<-O5> and similar to B<-O6> 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.
+
+=back
+
+=head2 Input Options
+
+=over
+
+=item B<-l> I<LIBRARY>
+
+This option instructs B<llvmc> to locate a library named I<LIBRARY> and search
+it for unresolved symbols when linking the program.
+
+=item B<-L> F<path>
+
+This option instructs B<llvmc> to add F<path> to the list of places in which
+the linker will
+
+=item B<-x> I<LANGUAGE>
+
+This option instructs B<llvmc> to regard the following input files as 
+containing programs in the language I<LANGUAGE>. Normally, input file languages
+are identified by their suffix but this option will override that default
+behavior. The B<-x> option stays in effect until the end of the options or
+a new B<-x> option is encountered.
+
+=back
+
+=head2 Output Options
+
+=over
+
+=item B<-m>I<arch>
+
+This option selects the back end code generator to use. The I<arch> portion
+of the option names the back end to use.
+
+=item B<--native>
+
+Normally, B<llvmc> produces bytecode files at most stages of compilation.
+With this option, B<llvmc> will arrange for native object files to be
+generated with the B<-c> option, native assembly files to be generated
+with the B<-S> option, and native executables to be generated with the
+B<--link> option. In the case of the B<-E> option, the output will not
+differ as there is no I<native> version of pre-processed output.
+
+=item B<-o> F<filename>
+
+Specify the output file name.  The contents of the file  depend on other 
+options. 
+
+=back
+
+=head2 Information Options
+
+=over
+
+=item B<-n> or B<--no-op>
+
+This option tells B<llvmc> to do everything but actually execute the
+resulting tools. In combination with the B<-v> option, this causes B<llvmc>
+to merely print out what it would have done.
+
+=item B<-v> or B<--verbose>
+
+This option will cause B<llvmc> 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.
+
+=item B<--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.
+
+=item B<--time-passes>
+
+Record the amount of time needed for each optimization pass and print it 
+to standard error. Like B<--stats> this option is just passed through to
+the sub-tools to do with as they please.
+
+=item B<--time-programs>
+
+Record the amount of time each program (compilation tool) takes and print
+it to the standard error. 
+
+=back
+
+=head2 Language Specific Options
+
+=over
+
+=item B<-T,pre>=I<options>
+
+Pass an arbitrary option to the pre-processor.
+
+=item B<-T,opt>=I<options>
+
+Pass an arbitrary option to the optimizer.
+
+=item B<-T,lnk>=I<options>
+
+Pass an arbitrary option to the linker.
+
+=item B<-T,asm>=I<options>
+
+Pass an arbitrary option to the code generator.
+
+=back
+
+=head2 C/C++ Specific Options
+
+=over
+
+=item B<-I>F<path>
+
+This option is just passed through to a C or C++ front end compiler to tell it
+where include files can be found.
+
+=item B<-D>F<symbol>
+
+This option is just passed through to a C or C++ front end compiler to tell it
+to define a symbol.
+
+=back
+
+=head2 Miscellaneous Options
+
+=over
+
+=item B<--help>
+
+Print a summary of command line options.
+
+=item B<--version>
+
+This option will cause B<llvmc> to print out its version number and terminate.
+
+=back
+
+=head2 Advanced Options
+
+You better know what you're doing if you use these options. Improper use
+of these options can produce drastically wrong results.
+
+=over 
+
+=item B<--config-dir> F<dirname>
+
+This option tells B<llvmc> to read configuration data from the I<directory>
+named F<dirname>. 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.
+
+
+=head2 Unimplemented Options
+
+The options below are not currently implemented in B<llvmc> but will be
+eventually. They are documented here as "future design".
+
+=over
+
+=item B<--show-config> I<[suffixes...]>
+
+When this option is given, the only action taken by B<llvmc> 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 B<llvmc>.
+
+=item B<--config> :I<section>:I<name>=I<value>
+
+This option instructs B<llvmc> to accept I<value> as the value for configuration
+item I<name> in the section named I<section>. This is a quick way to override
+a configuration item on the command line without resorting to changing the
+configuration files. 
+
+=item B<--config-only-from> F<dirname>
+
+This option tells B<llvmc> to skip the normal processing of configuration
+files and only configure from the contents of the F<dirname> directory. Multiple
+B<--config-only-from> options may be given in which case the directories are
+read in the order given on the command line.
+
+=item B<--emit-raw-code>
+
+No optimization is done whatsoever. The compilers invoked by B<llvmc> 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 B<-O> options. This is distinctly different from
+the B<-O0> option (a synonym for B<-O1>) because those optimizations will
+reduce code size to make compilation faster. With B<--emit-raw-code>, only
+the full raw code produced by the compiler will be generated.
+
+=back
+
+
+=head1 EXIT STATUS
+
+If B<llvmc> 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 B<llvmc> will return the
+same result code as the failing compilation tool.
+
+=head1 SEE ALSO
+
+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.cs.uiuc.edu>).
+
+=cut

llvm/docs/CommandGuide/llvmgcc.pod

@@ -2,26 +2,26 @@
 
 =head1 NAME
 
-llvmgcc - LLVM C front-end
+llvm-gcc - LLVM C front-end
 
 =head1 SYNOPSIS
 
-B<llvmgcc> [I<options>] I<filename>
+B<llvm-gcc> [I<options>] I<filename>
 
 =head1 DESCRIPTION
 
-The B<llvmgcc> command is the LLVM C front end.  It is a modified
+The B<llvm-gcc> command is the LLVM C front end.  It is a modified
 version of gcc that takes C programs and compiles them into LLVM
 bytecode or assembly language, depending upon the options.
 
-Unless the B<-S> option is specified, B<llvmgcc> will use the
+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<llvmgcc>
+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<llvmgcc> has many
+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
 number of gcc's extensions to the C programming language.
 
@@ -64,20 +64,28 @@ repeated.
 Link in the library libI<name>.[bc | a | so].  This library should
 be a bytecode library.
 
+=item B<-Wa,>I<option>
+
+Pass I<option> to gccas
+
 =item B<-Wl,>I<option>
 
-Pass I<option> to the linker (usually gccld).
+Pass I<option> to gccld
+
+=item B<-Wa,-disable-inlining -Wl,-disable-inlining>
+
+Fully disable all inlining
 
 =back
 
 =head1 EXIT STATUS
 
-If B<llvmgcc> succeeds, it will exit with 0.  Otherwise, if an error
+If B<llvm-gcc> succeeds, it will exit with 0.  Otherwise, if an error
 occurs, it will exit with a non-zero value.
 
 =head1 SEE ALSO
 
-L<llvmg++|llvmgxx>, L<gccas|gccas>, L<gccld|gccld>
+L<llvm-g++|llvmgxx>, L<gccas|gccas>, L<gccld|gccld>
 
 =head1 AUTHORS
 

llvm/docs/CommandGuide/llvmgxx.pod

@@ -2,26 +2,26 @@
 
 =head1 NAME
 
-llvmg++ - LLVM C++ front-end
+llvm-g++ - LLVM C++ front-end
 
 =head1 SYNOPSIS
 
-B<llvmg++> [I<options>] I<filename>
+B<llvm-g++> [I<options>] I<filename>
 
 =head1 DESCRIPTION
 
-The B<llvmg++> command is the LLVM C++ front end.  It is a modified
+The B<llvm-g++> command is the LLVM C++ front end.  It is a modified
 version of g++ that takes C++ programs and compiles them into LLVM
 bytecode or assembly language, depending upon the options.
 
-Unless the B<-S> option is specified, B<llvmg++> will use the
+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<llvmg++>
+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<llvmg++> has many
+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
 number of g++'s extensions to the C++ programming language.
 
@@ -64,20 +64,28 @@ repeated.
 Link in the library libI<name>.[bc | a | so].  This library should
 be a bytecode library.
 
+=item B<-Wa,>I<option>
+
+Pass I<option> to gccas
+
 =item B<-Wl,>I<option>
 
-Pass I<option> to the linker (usually gccld).
+Pass I<option> to gccld
+
+=item B<-Wa,-disable-inlining -Wl,-disable-inlining>
+
+Fully disable all inlining
 
 =back
 
 =head1 EXIT STATUS
 
-If B<llvmg++> succeeds, it will exit with 0.  Otherwise, if an error
+If B<llvm-g++> succeeds, it will exit with 0.  Otherwise, if an error
 occurs, it will exit with a non-zero value.
 
 =head1 SEE ALSO
 
-L<llvmgcc>, L<gccas>, L<gccld>
+L<llvm-gcc|llvmgcc>, L<gccas>, L<gccld>
 
 =head1 AUTHORS
 

llvm/docs/CommandGuide/man/.cvsignore

@@ -0,0 +1 @@
+.dir

llvm/docs/CommandGuide/man/man1/.cvsignore

@@ -1 +1,2 @@
 *.1
+.dir

llvm/docs/CommandGuide/ps/.cvsignore

@@ -1 +1,2 @@
 *ps
+.dir

llvm/docs/CommandLine.html

@@ -2,6 +2,7 @@
                       "http://www.w3.org/TR/html4/strict.dtd">
 <html>
 <head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
   <title>CommandLine 2.0 Library Manual</title>
   <link rel="stylesheet" href="llvm.css" type="text/css">
 </head>
@@ -30,6 +31,8 @@
       <li><a href="#positional">Positional Arguments</a>
         <ul>
         <li><a href="#--">Specifying positional options with hyphens</a></li>
+        <li><a href="#getPosition">Determining absolute position with
+          getPosition</a></li>
         <li><a href="#cl::ConsumeAfter">The <tt>cl::ConsumeAfter</tt>
              modifier</a></li>
         </ul></li>
@@ -59,6 +62,7 @@
         <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::alias">The <tt>cl::alias</tt> class</a></li>
+        <li><a href="#cl::extrahelp">The <tt>cl::extrahelp</tt> class</a></li>
         </ul></li>
 
       <li><a href="#builtinparsers">Builtin parsers</a>
@@ -188,19 +192,19 @@ can do.</p>
 <p>To start out, you need to include the CommandLine header file into your
 program:</p>
 
-<pre>
+<div class="doc_code"><pre>
   #include "Support/CommandLine.h"
-</pre>
+</pre></div>
 
 <p>Additionally, you need to add this as the first line of your main
 program:</p>
 
-<pre>
+<div class="doc_code"><pre>
 int main(int argc, char **argv) {
   <a href="#cl::ParseCommandLineOptions">cl::ParseCommandLineOptions</a>(argc, argv);
   ...
 }
-</pre>
+</pre></div>
 
 <p>... which actually parses the arguments and fills in the variable
 declarations.</p>
@@ -216,9 +220,9 @@ to specify where to put the output.  With the CommandLine library, this is
 represented like this:</p>
 
 <a name="value_desc_example"></a>
-<pre>
+<div class="doc_code"><pre>
 <a href="#cl::opt">cl::opt</a>&lt;string&gt; OutputFilename("<i>o</i>", <a href="#cl::desc">cl::desc</a>("<i>Specify output filename</i>"), <a href="#cl::value_desc">cl::value_desc</a>("<i>filename</i>"));
-</pre>
+</pre></div>
 
 <p>This declares a global variable "<tt>OutputFilename</tt>" that is used to
 capture the result of the "<tt>o</tt>" argument (first parameter).  We specify
@@ -231,25 +235,25 @@ that the data type that we are parsing is a string.</p>
 to output for the "<tt>--help</tt>" option.  In this case, we get a line that
 looks like this:</p>
 
-<pre>
+<div class="doc_code"><pre>
 USAGE: compiler [options]
 
 OPTIONS:
   -help             - display available options (--help-hidden for more)
   <b>-o &lt;filename&gt;     - Specify output filename</b>
-</pre>
+</pre></div>
 
 <p>Because we specified that the command line option should parse using the
 <tt>string</tt> data type, the variable declared is automatically usable as a
 real string in all contexts that a normal C++ string object may be used.  For
 example:</p>
 
-<pre>
+<div class="doc_code"><pre>
   ...
   ofstream Output(OutputFilename.c_str());
   if (Out.good()) ...
   ...
-</pre>
+</pre></div>
 
 <p>There are many different options that you can use to customize the command
 line option handling library, but the above example shows the general interface
@@ -266,9 +270,9 @@ href="#positional">positional</a> arguments to be specified for the program.
 These positional arguments are filled with command line parameters that are not
 in option form.  We use this feature like this:</p>
 
-<pre>
+<div class="doc_code"><pre>
 <a href="#cl::opt">cl::opt</a>&lt;string&gt; InputFilename(<a href="#cl::Positional">cl::Positional</a>, <a href="#cl::desc">cl::desc</a>("<i>&lt;input file&gt;</i>"), <a href="#cl::init">cl::init</a>("<i>-</i>"));
-</pre>
+</pre></div>
 
 <p>This declaration indicates that the first positional argument should be
 treated as the input filename.  Here we use the <tt><a
@@ -281,16 +285,16 @@ that the user always specify an input filename, we would add the <tt><a
 href="#cl::Required">cl::Required</a></tt> flag, and we could eliminate the
 <tt><a href="#cl::init">cl::init</a></tt> modifier, like this:</p>
 
-<pre>
+<div class="doc_code"><pre>
 <a href="#cl::opt">cl::opt</a>&lt;string&gt; InputFilename(<a href="#cl::Positional">cl::Positional</a>, <a href="#cl::desc">cl::desc</a>("<i>&lt;input file&gt;</i>"), <b><a href="#cl::Required">cl::Required</a></b>);
-</pre>
+</pre></div>
 
 <p>Again, the CommandLine library does not require the options to be specified
 in any particular order, so the above declaration is equivalent to:</p>
 
-<pre>
+<div class="doc_code"><pre>
 <a href="#cl::opt">cl::opt</a>&lt;string&gt; InputFilename(<a href="#cl::Positional">cl::Positional</a>, <a href="#cl::Required">cl::Required</a>, <a href="#cl::desc">cl::desc</a>("<i>&lt;input file&gt;</i>"));
-</pre>
+</pre></div>
 
 <p>By simply adding the <tt><a href="#cl::Required">cl::Required</a></tt> flag,
 the CommandLine library will automatically issue an error if the argument is not
@@ -300,13 +304,13 @@ can alter the default behaviour of the library, on a per-option basis.  By
 adding one of the declarations above, the <tt>--help</tt> option synopsis is now
 extended to:</p>
 
-<pre>
+<div class="doc_code"><pre>
 USAGE: compiler [options] <b>&lt;input file&gt;</b>
 
 OPTIONS:
   -help             - display available options (--help-hidden for more)
   -o &lt;filename&gt;     - Specify output filename
-</pre>
+</pre></div>
 
 <p>... indicating that an input filename is expected.</p>
 
@@ -325,11 +329,11 @@ file, "<tt>--quiet</tt>" to enable quiet mode, and "<tt>-q</tt>" for backwards
 compatibility with some of our users.  We can support these by declaring options
 of boolean type like this:</p>
 
-<pre>
+<div class="doc_code"><pre>
 <a href="#cl::opt">cl::opt</a>&lt;bool&gt; Force ("<i>f</i>", <a href="#cl::desc">cl::desc</a>("<i>Overwrite output files</i>"));
 <a href="#cl::opt">cl::opt</a>&lt;bool&gt; Quiet ("<i>quiet</i>", <a href="#cl::desc">cl::desc</a>("<i>Don't print informational messages</i>"));
 <a href="#cl::opt">cl::opt</a>&lt;bool&gt; Quiet2("<i>q</i>", <a href="#cl::desc">cl::desc</a>("<i>Don't print informational messages</i>"), <a href="#cl::Hidden">cl::Hidden</a>);
-</pre>
+</pre></div>
 
 <p>This does what you would expect: it declares three boolean variables
 ("<tt>Force</tt>", "<tt>Quiet</tt>", and "<tt>Quiet2</tt>") to recognize these
@@ -347,12 +351,12 @@ it assigns the value of true to the variable), or it allows the values
 "<tt>true</tt>" or "<tt>false</tt>" to be specified, allowing any of the
 following inputs:</p>
 
-<pre>
+<div class="doc_code"><pre>
  compiler -f          # No value, 'Force' == true
  compiler -f=true     # Value specified, 'Force' == true
  compiler -f=TRUE     # Value specified, 'Force' == true
  compiler -f=FALSE    # Value specified, 'Force' == false
-</pre>
+</pre></div>
 
 <p>... you get the idea.  The <a href="#boolparser">bool parser</a> just turns
 the string values into boolean values, and rejects things like '<tt>compiler
@@ -363,7 +367,7 @@ library calls to parse the string value into the specified data type.</p>
 
 <p>With the declarations above, "<tt>compiler --help</tt>" emits this:</p>
 
-<pre>
+<div class="doc_code"><pre>
 USAGE: compiler [options] &lt;input file&gt;
 
 OPTIONS:
@@ -371,11 +375,11 @@ OPTIONS:
   -o     - Override output filename
   <b>-quiet - Don't print informational messages</b>
   -help  - display available options (--help-hidden for more)
-</pre>
+</pre></div>
 
 <p>and "<tt>opt --help-hidden</tt>" prints this:</p>
 
-<pre>
+<div class="doc_code"><pre>
 USAGE: compiler [options] &lt;input file&gt;
 
 OPTIONS:
@@ -384,7 +388,7 @@ OPTIONS:
   <b>-q     - Don't print informational messages</b>
   -quiet - Don't print informational messages
   -help  - display available options (--help-hidden for more)
-</pre>
+</pre></div>
 
 <p>This brief example has shown you how to use the '<tt><a
 href="#cl::opt">cl::opt</a></tt>' class to parse simple scalar command line
@@ -404,22 +408,22 @@ and <a href="#list">lists</a> of options.</p>
 <p>So far, the example works well, except for the fact that we need to check the
 quiet condition like this now:</p>
 
-<pre>
+<div class="doc_code"><pre>
 ...
   if (!Quiet &amp;&amp; !Quiet2) printInformationalMessage(...);
 ...
-</pre>
+</pre></div>
 
 <p>... which is a real pain!  Instead of defining two values for the same
 condition, we can use the "<tt><a href="#cl::alias">cl::alias</a></tt>" class to make the "<tt>-q</tt>"
 option an <b>alias</b> for the "<tt>-quiet</tt>" option, instead of providing
 a value itself:</p>
 
-<pre>
+<div class="doc_code"><pre>
 <a href="#cl::opt">cl::opt</a>&lt;bool&gt; Force ("<i>f</i>", <a href="#cl::desc">cl::desc</a>("<i>Overwrite output files</i>"));
 <a href="#cl::opt">cl::opt</a>&lt;bool&gt; Quiet ("<i>quiet</i>", <a href="#cl::desc">cl::desc</a>("<i>Don't print informational messages</i>"));
 <a href="#cl::alias">cl::alias</a>     QuietA("<i>q</i>", <a href="#cl::desc">cl::desc</a>("<i>Alias for -quiet</i>"), <a href="#cl::aliasopt">cl::aliasopt</a>(Quiet));
-</pre>
+</pre></div>
 
 <p>The third line (which is the only one we modified from above) defines a
 "<tt>-q</tt> alias that updates the "<tt>Quiet</tt>" variable (as specified by
@@ -432,11 +436,11 @@ output</tt>).</p>
 
 <p>Now the application code can simply use:</p>
 
-<pre>
+<div class="doc_code"><pre>
 ...
   if (!Quiet) printInformationalMessage(...);
 ...
-</pre>
+</pre></div>
 
 <p>... which is much nicer!  The "<tt><a href="#cl::alias">cl::alias</a></tt>"
 can be used to specify an alternative name for any variable type, and has many
@@ -458,10 +462,10 @@ things it doesn't know about, like enums or '<tt>int*</tt>'s?</p>
 
 <p>The answer is that it uses a table driven generic parser (unless you specify
 your own parser, as described in the <a href="#extensionguide">Extension
-Guide</a>).  This parser maps literal strings to whatever type is required, are
+Guide</a>).  This parser maps literal strings to whatever type is required, and
 requires you to tell it what this mapping should be.</p>
 
-<p>Lets say that we would like to add four optimizations levels to our
+<p>Lets say that we would like to add four optimization levels to our
 optimizer, using the standard flags "<tt>-g</tt>", "<tt>-O0</tt>",
 "<tt>-O1</tt>", and "<tt>-O2</tt>".  We could easily implement this with boolean
 options like above, but there are several problems with this strategy:</p>
@@ -482,7 +486,7 @@ see if some level &gt;= "<tt>-O1</tt>" is enabled.</li>
 CommandLine library fill it in with the appropriate level directly, which is
 used like this:</p>
 
-<pre>
+<div class="doc_code"><pre>
 enum OptLevel {
   g, O1, O2, O3
 };
@@ -498,7 +502,7 @@ enum OptLevel {
 ...
   if (OptimizationLevel &gt;= O2) doPartialRedundancyElimination(...);
 ...
-</pre>
+</pre></div>
 
 <p>This declaration defines a variable "<tt>OptimizationLevel</tt>" of the
 "<tt>OptLevel</tt>" enum type.  This variable can be assigned any of the values
@@ -510,7 +514,7 @@ enum values can be specified.  The "<tt>clEnumVal</tt>" macros ensure that the
 command line arguments matched the enum values.  With this option added, our
 help output now is:</p>
 
-<pre>
+<div class="doc_code"><pre>
 USAGE: compiler [options] &lt;input file&gt;
 
 OPTIONS:
@@ -523,14 +527,14 @@ OPTIONS:
   -help         - display available options (--help-hidden for more)
   -o &lt;filename&gt; - Specify output filename
   -quiet        - Don't print informational messages
-</pre>
+</pre></div>
 
 <p>In this case, it is sort of awkward that flag names correspond directly to
 enum names, because we probably don't want a enum definition named "<tt>g</tt>"
 in our program.  Because of this, we can alternatively write this example like
 this:</p>
 
-<pre>
+<div class="doc_code"><pre>
 enum OptLevel {
   Debug, O1, O2, O3
 };
@@ -546,7 +550,7 @@ enum OptLevel {
 ...
   if (OptimizationLevel == Debug) outputDebugInfo(...);
 ...
-</pre>
+</pre></div>
 
 <p>By using the "<tt>clEnumValN</tt>" macro instead of "<tt>clEnumVal</tt>", we
 can directly specify the name that the flag should get.  In general a direct
@@ -571,7 +575,7 @@ following options, of which only one can be specified at a time:
 our optimization level flags, but we also specify an option name.  For this
 case, the code looks like this:</p>
 
-<pre>
+<div class="doc_code"><pre>
 enum DebugLev {
   nodebuginfo, quick, detailed
 };
@@ -583,14 +587,14 @@ enum DebugLev {
      clEnumVal(quick,               "<i>enable quick debug information</i>"),
      clEnumVal(detailed,            "<i>enable detailed debug information</i>"),
     clEnumValEnd));
-</pre>
+</pre></div>
 
 <p>This definition defines an enumerated command line variable of type "<tt>enum
 DebugLev</tt>", which works exactly the same way as before.  The difference here
 is just the interface exposed to the user of your program and the help output by
 the "<tt>--help</tt>" option:</p>
 
-<pre>
+<div class="doc_code"><pre>
 USAGE: compiler [options] &lt;input file&gt;
 
 OPTIONS:
@@ -607,10 +611,10 @@ OPTIONS:
   -help         - display available options (--help-hidden for more)
   -o &lt;filename&gt; - Specify output filename
   -quiet        - Don't print informational messages
-</pre>
+</pre></div>
 
 <p>Again, the only structural difference between the debug level declaration and
-the optimiation level declaration is that the debug level declaration includes
+the optimization level declaration is that the debug level declaration includes
 an option name (<tt>"debug_level"</tt>), which automatically changes how the
 library processes the argument.  The CommandLine library supports both forms so
 that you can choose the form most appropriate for your application.</p>
@@ -633,16 +637,16 @@ important.  This is what the "<tt><a href="#cl::list">cl::list</a></tt>"
 template is for.  First, start by defining an enum of the optimizations that you
 would like to perform:</p>
 
-<pre>
+<div class="doc_code"><pre>
 enum Opts {
   // 'inline' is a C++ keyword, so name it 'inlining'
   dce, constprop, inlining, strip
 };
-</pre>
+</pre></div>
 
 <p>Then define your "<tt><a href="#cl::list">cl::list</a></tt>" variable:</p>
 
-<pre>
+<div class="doc_code"><pre>
 <a href="#cl::list">cl::list</a>&lt;Opts&gt; OptimizationList(<a href="#cl::desc">cl::desc</a>("<i>Available Optimizations:</i>"),
   <a href="#cl::values">cl::values</a>(
     clEnumVal(dce               , "<i>Dead Code Elimination</i>"),
@@ -650,17 +654,17 @@ enum Opts {
    clEnumValN(inlining, "<i>inline</i>", "<i>Procedure Integration</i>"),
     clEnumVal(strip             , "<i>Strip Symbols</i>"),
   clEnumValEnd));
-</pre>
+</pre></div>
 
 <p>This defines a variable that is conceptually of the type
 "<tt>std::vector&lt;enum Opts&gt;</tt>".  Thus, you can access it with standard
 vector methods:</p>
 
-<pre>
+<div class="doc_code"><pre>
   for (unsigned i = 0; i != OptimizationList.size(); ++i)
     switch (OptimizationList[i])
        ...
-</pre>
+</pre></div>
 
 <p>... to iterate through the list of options specified.</p>
 
@@ -672,11 +676,11 @@ arguments together if there may be more than one specified.  In the case of a
 linker, for example, the linker takes several '<tt>.o</tt>' files, and needs to
 capture them into a list.  This is naturally specified as:</p>
 
-<pre>
+<div class="doc_code"><pre>
 ...
 <a href="#cl::list">cl::list</a>&lt;std::string&gt; InputFilenames(<a href="#cl::Positional">cl::Positional</a>, <a href="#cl::desc">cl::desc</a>("&lt;Input files&gt;"), <a href="#cl::OneOrMore">cl::OneOrMore</a>);
 ...
-</pre>
+</pre></div>
 
 <p>This variable works just like a "<tt>vector&lt;string&gt;</tt>" object.  As
 such, accessing the list is simple, just like above.  In this example, we used
@@ -705,17 +709,17 @@ call in main.  This additional argument is then printed as the overview
 information for your program, allowing you to include any additional information
 that you want.  For example:</p>
 
-<pre>
+<div class="doc_code"><pre>
 int main(int argc, char **argv) {
   <a href="#cl::ParseCommandLineOptions">cl::ParseCommandLineOptions</a>(argc, argv, " CommandLine compiler example\n\n"
                               "  This program blah blah blah...\n");
   ...
 }
-</pre>
+</pre></div>
 
-<p>Would yield the help output:</p>
+<p>would yield the help output:</p>
 
-<pre>
+<div class="doc_code"><pre>
 <b>OVERVIEW: CommandLine compiler example
 
   This program blah blah blah...</b>
@@ -726,7 +730,7 @@ OPTIONS:
   ...
   -help             - display available options (--help-hidden for more)
   -o &lt;filename&gt;     - Specify output filename
-</pre>
+</pre></div>
 
 </div>
 
@@ -760,27 +764,27 @@ tool takes a regular expression argument, and an optional filename to search
 through (which defaults to standard input if a filename is not specified).
 Using the CommandLine library, this would be specified as:</p>
 
-<pre>
+<div class="doc_code"><pre>
 <a href="#cl::opt">cl::opt</a>&lt;string&gt; Regex   (<a href="#cl::Positional">cl::Positional</a>, <a href="#cl::desc">cl::desc</a>("<i>&lt;regular expression&gt;</i>"), <a href="#cl::Required">cl::Required</a>);
 <a href="#cl::opt">cl::opt</a>&lt;string&gt; Filename(<a href="#cl::Positional">cl::Positional</a>, <a href="#cl::desc">cl::desc</a>("<i>&lt;input file&gt;</i>"), <a href="#cl::init">cl::init</a>("<i>-</i>"));
-</pre>
+</pre></div>
 
 <p>Given these two option declarations, the <tt>--help</tt> output for our grep
 replacement would look like this:</p>
 
-<pre>
+<div class="doc_code"><pre>
 USAGE: spiffygrep [options] <b>&lt;regular expression&gt; &lt;input file&gt;</b>
 
 OPTIONS:
   -help - display available options (--help-hidden for more)
-</pre>
+</pre></div>
 
 <p>... and the resultant program could be used just like the standard
 <tt>grep</tt> tool.</p>
 
 <p>Positional arguments are sorted by their order of construction.  This means
 that command line options will be ordered according to how they are listed in a
-.cpp file, but will not have an ordering defined if they positional arguments
+.cpp file, but will not have an ordering defined if the positional arguments
 are defined in multiple .cpp files.  The fix for this problem is simply to
 define all of your positional arguments in one .cpp file.</p>
 
@@ -800,7 +804,7 @@ first, you will have trouble doing this, because it will try to find an argument
 named '<tt>-foo</tt>', and will fail (and single quotes will not save you).
 Note that the system <tt>grep</tt> has the same problem:</p>
 
-<pre>
+<div class="doc_code"><pre>
   $ spiffygrep '-foo' test.txt
   Unknown command line argument '-foo'.  Try: spiffygrep --help'
 
@@ -809,7 +813,7 @@ Note that the system <tt>grep</tt> has the same problem:</p>
   grep: illegal option -- o
   grep: illegal option -- o
   Usage: grep -hblcnsviw pattern file . . .
-</pre>
+</pre></div>
 
 <p>The solution for this problem is the same for both your tool and the system
 version: use the '<tt>--</tt>' marker.  When the user specifies '<tt>--</tt>' on
@@ -817,13 +821,72 @@ the command line, it is telling the program that all options after the
 '<tt>--</tt>' should be treated as positional arguments, not options.  Thus, we
 can use it like this:</p>
 
-<pre>
+<div class="doc_code"><pre>
   $ spiffygrep -- -foo test.txt
     ...output...
-</pre>
+</pre></div>
 
 </div>
 
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+  <a name="getPosition">Determining absolute position with getPosition()</a>
+</div>
+<div class="doc_text">
+  <p>Sometimes an option can affect or modify the meaning of another option. For
+  example, consider <tt>gcc</tt>'s <tt>-x LANG</tt> option. This tells
+  <tt>gcc</tt> to ignore the suffix of subsequent positional arguments and force
+  the file to be interpreted as if it contained source code in language
+  <tt>LANG</tt>. In order to handle this properly , you need to know the 
+  absolute position of each argument, especially those in lists, so their 
+  interaction(s) can be applied correctly. This is also useful for options like 
+  <tt>-llibname</tt> which is actually a positional argument that starts with 
+  a dash.</p>
+  <p>So, generally, the problem is that you have two <tt>cl::list</tt> variables
+  that interact in some way. To ensure the correct interaction, you can use the
+  <tt>cl::list::getPosition(optnum)</tt> method. This method returns the
+  absolute position (as found on the command line) of the <tt>optnum</tt>
+  item in the <tt>cl::list</tt>.</p>
+  <p>The idiom for usage is like this:</p>
+  
+  <div class="doc_code"><pre>
+  static cl::list&lt;std::string&gt; Files(cl::Positional, cl::OneOrMore);
+  static cl::listlt;std::string&gt; Libraries("l", cl::ZeroOrMore);
+
+  int main(int argc, char**argv) {
+    // ...
+    std::vector&lt;std::string&gt;::iterator fileIt = Files.begin();
+    std::vector&lt;std::string&gt;::iterator libIt  = Libraries.begin();
+    unsigned libPos = 0, filePos = 0;
+    while ( 1 ) {
+      if ( libIt != Libraries.end() )
+        libPos = Libraries.getPosition( libIt - Libraries.begin() );
+      else
+        libPos = 0;
+      if ( fileIt != Files.end() )
+        filePos = Files.getPosition( fileIt - Files.begin() );
+      else
+        filePos = 0;
+
+      if ( filePos != 0 &amp;&amp; (libPos == 0 || filePos &lt; libPos) ) {
+        // Source File Is next
+        ++fileIt;
+      }
+      else if ( libPos != 0 &amp;&amp; (filePos == 0 || libPos &lt; filePos) ) {
+        // Library is next
+        ++libIt;
+      }
+      else
+        break; // we're done with the list
+    }
+  }</pre></div>
+
+  <p>Note that, for compatibility reasons, the <tt>cl::opt</tt> also supports an
+  <tt>unsigned getPosition()</tt> option that will provide the absolute position
+  of that option. You can apply the same approach as above with a 
+  <tt>cl::opt</tt> and a <tt>cl::list</tt> option as you can with two lists.</p>
+</div>
+
 <!-- _______________________________________________________________________ -->
 <div class="doc_subsubsection">
   <a name="cl::ConsumeAfter">The <tt>cl::ConsumeAfter</tt> modifier</a>
@@ -845,23 +908,23 @@ arguments to the script.  These arguments to the script are parsed by the bourne
 shell command line option processor, but are not interpreted as options to the
 shell itself.  Using the CommandLine library, we would specify this as:</p>
 
-<pre>
+<div class="doc_code"><pre>
 <a href="#cl::opt">cl::opt</a>&lt;string&gt; Script(<a href="#cl::Positional">cl::Positional</a>, <a href="#cl::desc">cl::desc</a>("<i>&lt;input script&gt;</i>"), <a href="#cl::init">cl::init</a>("-"));
 <a href="#cl::list">cl::list</a>&lt;string&gt;  Argv(<a href="#cl::ConsumeAfter">cl::ConsumeAfter</a>, <a href="#cl::desc">cl::desc</a>("<i>&lt;program arguments&gt;...</i>"));
 <a href="#cl::opt">cl::opt</a>&lt;bool&gt;    Trace("<i>x</i>", <a href="#cl::desc">cl::desc</a>("<i>Enable trace output</i>"));
-</pre>
+</pre></div>
 
 <p>which automatically provides the help output:</p>
 
-<pre>
+<div class="doc_code"><pre>
 USAGE: spiffysh [options] <b>&lt;input script&gt; &lt;program arguments&gt;...</b>
 
 OPTIONS:
   -help - display available options (--help-hidden for more)
   <b>-x    - Enable trace output</b>
-</pre>
+</pre></div>
 
-<p>At runtime, if we run our new shell replacement as '<tt>spiffysh -x test.sh
+<p>At runtime, if we run our new shell replacement as `<tt>spiffysh -x test.sh
 -a -x -y bar</tt>', the <tt>Trace</tt> variable will be set to true, the
 <tt>Script</tt> variable will be set to "<tt>test.sh</tt>", and the
 <tt>Argv</tt> list will contain <tt>["-a", "-x", "-y", "bar"]</tt>, because they
@@ -900,6 +963,7 @@ all of these clients (requiring lots of .cpp files to #include
 
 <p>To do this, set up your .h file with your option, like this for example:</p>
 
+<div class="doc_code">
 <pre>
 <i>// DebugFlag.h - Get access to the '-debug' command line option
 //
@@ -915,15 +979,15 @@ extern bool DebugFlag;
 // debug build, then the code specified as the option to the macro will be
 // executed.  Otherwise it will not be.  Example:
 //
-// DEBUG(cerr << "Bitset contains: " << Bitset << "\n");
+// DEBUG(std::cerr &lt;&lt; "Bitset contains: " &lt;&lt; Bitset &lt;&lt; "\n");
 //</i>
-<span class="doc_red">#ifdef NDEBUG
+<span class="doc_hilite">#ifdef NDEBUG
 #define DEBUG(X)
 #else
-#define DEBUG(X)</span> \
-  do { if (DebugFlag) { X; } } while (0)
-<span class="doc_red">#endif</span>
+#define DEBUG(X)</span> do { if (DebugFlag) { X; } } while (0)
+<span class="doc_hilite">#endif</span>
 </pre>
+</div>
 
 <p>This allows clients to blissfully use the <tt>DEBUG()</tt> macro, or the
 <tt>DebugFlag</tt> explicitly if they want to.  Now we just need to be able to
@@ -932,18 +996,19 @@ an additial argument to our command line argument processor, and we specify
 where to fill in with the <a href="#cl::location">cl::location</a>
 attribute:</p>
 
+<div class="doc_code">
 <pre>
-bool DebugFlag;      <i>// the actual value</i>
+bool DebugFlag;                  <i>// the actual value</i>
 static <a href="#cl::opt">cl::opt</a>&lt;bool, true&gt;       <i>// The parser</i>
-Debug("<i>debug</i>", <a href="#cl::desc">cl::desc</a>("<i>Enable debug output</i>"), <a href="#cl::Hidden">cl::Hidden</a>,
-      <a href="#cl::location">cl::location</a>(DebugFlag));
+Debug("<i>debug</i>", <a href="#cl::desc">cl::desc</a>("<i>Enable debug output</i>"), <a href="#cl::Hidden">cl::Hidden</a>, <a href="#cl::location">cl::location</a>(DebugFlag));
 </pre>
+</div>
 
 <p>In the above example, we specify "<tt>true</tt>" as the second argument to
-the <a href="#cl::opt">cl::opt</a> template, indicating that the template should
-not maintain a copy of the value itself.  In addition to this, we specify the <a
-href="#cl::location">cl::location</a> attribute, so that <tt>DebugFlag</tt> is
-automatically set.</p>
+the <tt><a href="#cl::opt">cl::opt</a></tt> template, indicating that the
+template should not maintain a copy of the value itself.  In addition to this,
+we specify the <tt><a href="#cl::location">cl::location</a></tt> attribute, so
+that <tt>DebugFlag</tt> is automatically set.</p>
 
 </div>
 
@@ -994,8 +1059,8 @@ the section on <a href="#storage">Internal vs External Storage</a> for more
 information.</li>
 
 <li><a name="cl::aliasopt">The <b><tt>cl::aliasopt</tt></b></a> attribute
-specifies which option a <a href="#cl::alias">cl::alias</a> option is an alias
-for.</li>
+specifies which option a <tt><a href="#cl::alias">cl::alias</a></tt> option is
+an alias for.</li>
 
 <li><a name="cl::values">The <b><tt>cl::values</tt></b></a> attribute specifies
 the string-to-value mapping to be used by the generic parser.  It takes a
@@ -1215,35 +1280,39 @@ Arguments</a> section for more information.</li>
 specifies that this option is used to capture "interpreter style" arguments.  See <a href="#cl::ConsumeAfter">this section for more information</a>.</li>
 
 <li><a name="cl::Prefix">The <b><tt>cl::Prefix</tt></b></a> modifier specifies
-that this option prefixes its value.  With 'Prefix' options, there is no equal
-sign that separates the value from the option name specified.  This is useful
-for processing odd arguments like '<tt>-lmalloc -L/usr/lib'</tt> in a linker
-tool.  Here, the '<tt>l</tt>' and '<tt>L</tt>' options are normal string (list)
-options, that have the <a href="#cl::Prefix">cl::Prefix</a> modifier added to
-allow the CommandLine library to recognize them.  Note that <a
-href="#cl::Prefix">cl::Prefix</a> options must not have the <a
-href="#cl::ValueDisallowed">cl::ValueDisallowed</a> modifier specified.</li>
+that this option prefixes its value.  With 'Prefix' options, the equal sign does
+not separate the value from the option name specified. Instead, the value is
+everything after the prefix, including any equal sign if present. This is useful
+for processing odd arguments like <tt>-lmalloc</tt> and <tt>-L/usr/lib</tt> in a
+linker tool or <tt>-DNAME=value</tt> in a compiler tool.   Here, the
+'<tt>l</tt>', '<tt>D</tt>' and '<tt>L</tt>' options are normal string (or list)
+options, that have the <b><tt><a href="#cl::Prefix">cl::Prefix</a></tt></b>
+modifier added to allow the CommandLine library to recognize them.  Note that
+<b><tt><a href="#cl::Prefix">cl::Prefix</a></tt></b> options must not have the
+<b><tt><a href="#cl::ValueDisallowed">cl::ValueDisallowed</a></tt></b> modifier
+specified.</li>
 
 <li><a name="cl::Grouping">The <b><tt>cl::Grouping</tt></b></a> modifier is used
 to implement unix style tools (like <tt>ls</tt>) that have lots of single letter
 arguments, but only require a single dash.  For example, the '<tt>ls -labF</tt>'
 command actually enables four different options, all of which are single
-letters.  Note that <a href="#cl::Grouping">cl::Grouping</a> options cannot have
-values.</li>
+letters.  Note that <b><tt><a href="#cl::Grouping">cl::Grouping</a></tt></b>
+options cannot have values.</li>
 
 </ul>
 
-<p>The CommandLine library does not restrict how you use the <a
-href="#cl::Prefix">cl::Prefix</a> or <a href="#cl::Grouping">cl::Grouping</a>
-modifiers, but it is possible to specify ambiguous argument settings.  Thus, it
-is possible to have multiple letter options that are prefix or grouping options,
-and they will still work as designed.</p>
+<p>The CommandLine library does not restrict how you use the <b><tt><a
+href="#cl::Prefix">cl::Prefix</a></tt></b> or <b><tt><a
+href="#cl::Grouping">cl::Grouping</a></tt></b> modifiers, but it is possible to
+specify ambiguous argument settings.  Thus, it is possible to have multiple
+letter options that are prefix or grouping options, and they will still work as
+designed.</p>
 
 <p>To do this, the CommandLine library uses a greedy algorithm to parse the
 input option into (potentially multiple) prefix and grouping options.  The
 strategy basically looks like this:</p>
 
-<p><tt>parse(string OrigInput) {</tt>
+<div class="doc_code"><tt>parse(string OrigInput) {</tt>
 
 <ol>
 <li><tt>string input = OrigInput;</tt>
@@ -1259,10 +1328,10 @@ strategy basically looks like this:</p>
 &nbsp;&nbsp;while (!isOption(input) &amp;&amp; !input.empty()) input.pop_back();<br>
 }</tt>
 <li><tt>if (!OrigInput.empty()) error();</tt></li>
-
 </ol>
 
 <p><tt>}</tt></p>
+</div>
 
 </div>
 
@@ -1387,13 +1456,13 @@ options, and is the one used most of the time.  It is a templated class which
 can take up to three arguments (all except for the first have default values
 though):</p>
 
-<pre>
+<div class="doc_code"><pre>
 <b>namespace</b> cl {
   <b>template</b> &lt;<b>class</b> DataType, <b>bool</b> ExternalStorage = <b>false</b>,
             <b>class</b> ParserClass = parser&lt;DataType&gt; &gt;
   <b>class</b> opt;
 }
-</pre>
+</pre></div>
 
 <p>The first template argument specifies what underlying data type the command
 line argument is, and is used to select a default parser implementation.  The
@@ -1421,13 +1490,13 @@ href="#customparser">custom parser</a>.</p>
 line options.  It too is a templated class which can take up to three
 arguments:</p>
 
-<pre>
+<div class="doc_code"><pre>
 <b>namespace</b> cl {
   <b>template</b> &lt;<b>class</b> DataType, <b>class</b> Storage = <b>bool</b>,
             <b>class</b> ParserClass = parser&lt;DataType&gt; &gt;
   <b>class</b> list;
 }
-</pre>
+</pre></div>
 
 <p>This class works the exact same as the <a
 href="#cl::opt"><tt>cl::opt</tt></a> class, except that the second argument is
@@ -1447,11 +1516,11 @@ be used.</p>
 <p>The <tt>cl::alias</tt> class is a nontemplated class that is used to form
 aliases for other arguments.</p>
 
-<pre>
+<div class="doc_code"><pre>
 <b>namespace</b> cl {
   <b>class</b> alias;
 }
-</pre>
+</pre></div>
 
 <p>The <a href="#cl::aliasopt"><tt>cl::aliasopt</tt></a> attribute should be
 used to specify which option this is an alias for.  Alias arguments default to
@@ -1460,6 +1529,34 @@ the conversion from string to data.</p>
 
 </div>
 
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+  <a name="cl::extrahelp">The <tt>cl::extrahelp</tt> class</a>
+</div>
+
+<div class="doc_text">
+
+<p>The <tt>cl::extrahelp</tt> class is a nontemplated class that allows extra
+help text to be printed out for the <tt>--help</tt> option.</p>
+
+<div class="doc_code"><pre>
+<b>namespace</b> cl {
+  <b>struct</b> extrahelp;
+}
+</pre></div>
+
+<p>To use the extrahelp, simply construct one with a <tt>const char*</tt> 
+parameter to the constructor. The text passed to the constructor will be printed
+at the bottom of the help message, verbatim. Note that multiple
+<tt>cl::extrahelp</tt> <b>can</b> be used, but this practice is discouraged. If
+your tool needs to print additional help information, put all that help into a
+single <tt>cl::extrahelp</tt> instance.</p>
+<p>For example:</p>
+<div class="doc_code"><pre>
+  cl::extrahelp("\nADDITIONAL HELP:\n\n  This is the extra help\n");
+</pre></div>
+</div>
+
 <!-- ======================================================================= -->
 <div class="doc_subsection">
   <a name="builtinparsers">Builtin parsers</a>
@@ -1584,13 +1681,13 @@ this the default for all <tt>unsigned</tt> options.</p>
 
 <p>To start out, we declare our new <tt>FileSizeParser</tt> class:</p>
 
-<pre>
+<div class="doc_code"><pre>
 <b>struct</b> FileSizeParser : <b>public</b> cl::basic_parser&lt;<b>unsigned</b>&gt; {
   <i>// parse - Return true on error.</i>
   <b>bool</b> parse(cl::Option &amp;O, <b>const char</b> *ArgName, <b>const</b> std::string &amp;ArgValue,
              <b>unsigned</b> &amp;Val);
 };
-</pre>
+</pre></div>
 
 <p>Our new class inherits from the <tt>cl::basic_parser</tt> template class to
 fill in the default, boiler plate, code for us.  We give it the data type that
@@ -1606,7 +1703,7 @@ is not well formed, the parser should output an error message and return true.
 Otherwise it should return false and set '<tt>Val</tt>' to the parsed value.  In
 our example, we implement <tt>parse</tt> as:</p>
 
-<pre>
+<div class="doc_code"><pre>
 <b>bool</b> FileSizeParser::parse(cl::Option &amp;O, <b>const char</b> *ArgName,
                            <b>const</b> std::string &amp;Arg, <b>unsigned</b> &amp;Val) {
   <b>const char</b> *ArgStart = Arg.c_str();
@@ -1632,7 +1729,7 @@ our example, we implement <tt>parse</tt> as:</p>
     }
   }
 }
-</pre>
+</pre></div>
 
 <p>This function implements a very simple parser for the kinds of strings we are
 interested in.  Although it has some holes (it allows "<tt>123KKK</tt>" for
@@ -1641,25 +1738,25 @@ itself to print out the error message (the <tt>error</tt> method always returns
 true) in order to get a nice error message (shown below).  Now that we have our
 parser class, we can use it like this:</p>
 
-<pre>
+<div class="doc_code"><pre>
 <b>static</b> <a href="#cl::opt">cl::opt</a>&lt;<b>unsigned</b>, <b>false</b>, FileSizeParser&gt;
 MFS(<i>"max-file-size"</i>, <a href="#cl::desc">cl::desc</a>(<i>"Maximum file size to accept"</i>),
     <a href="#cl::value_desc">cl::value_desc</a>("<i>size</i>"));
-</pre>
+</pre></div>
 
 <p>Which adds this to the output of our program:</p>
 
-<pre>
+<div class="doc_code"><pre>
 OPTIONS:
   -help                 - display available options (--help-hidden for more)
   ...
   <b>-max-file-size=&lt;size&gt; - Maximum file size to accept</b>
-</pre>
+</pre></div>
 
 <p>And we can test that our parse works correctly now (the test program just
 prints out the max-file-size argument value):</p>
 
-<pre>
+<div class="doc_code"><pre>
 $ ./test
 MFS: 0
 $ ./test -max-file-size=123MB
@@ -1668,7 +1765,7 @@ $ ./test -max-file-size=3G
 MFS: 3221225472
 $ ./test -max-file-size=dog
 -max-file-size option: 'dog' value invalid for file size argument!
-</pre>
+</pre></div>
 
 <p>It looks like it works.  The error message that we get is nice and helpful,
 and we seem to accept reasonable file sizes.  This wraps up the "custom parser"
@@ -1682,8 +1779,16 @@ tutorial.</p>
 </div>
 
 <div class="doc_text">
+  <p>Several of the LLVM libraries define static <tt>cl::opt</tt> instances that
+  will automatically be included in any program that links with that library.
+  This is a feature. However, sometimes it is necessary to know the value of the
+  command line option outside of the library. In these cases the library does or
+  should provide an external storage location that is accessible to users of the
+  library. Examples of this include the <tt>llvm::DebugFlag</tt> exported by the
+  <tt>lib/Support/Debug.cpp</tt> file and the <tt>llvm::TimePassesIsEnabled</tt>
+  flag exported by the <tt>lib/VMCore/Pass.cpp</tt> file.</p>
 
-<p>TODO: fill in this section</p>
+<p>TODO: complete this section</p>
 
 </div>
 

llvm/docs/CompilerDriver.html

@@ -0,0 +1,823 @@
+<!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 LLVM Compiler Driver (llvmc)</title>
+  <link rel="stylesheet" href="llvm.css" type="text/css">
+  <meta name="author" content="Reid Spencer">
+  <meta name="description" 
+  content="A description of the use and design of the LLVM Compiler Driver.">
+</head>
+<body>
+<div class="doc_title">The LLVM Compiler Driver (llvmc)</div>
+<p class="doc_warning">NOTE: This document is a work in progress!</p>
+<ol>
+  <li><a href="#abstract">Abstract</a></li>
+  <li><a href="#introduction">Introduction</a>
+    <ol>
+      <li><a href="#purpose">Purpose</a></li>
+      <li><a href="#operation">Operation</a></li>
+      <li><a href="#phases">Phases</a></li>
+      <li><a href="#actions">Actions</a></li>
+    </ol>
+  </li>
+  <li><a href="#configuration">Configuration</a>
+    <ol>
+      <li><a href="#overview">Overview</a></li>
+      <li><a href="#filetypes">Configuration Files</a></li>
+      <li><a href="#syntax">Syntax</a></li>
+      <li><a href="#substitutions">Substitutions</a></li>
+      <li><a href="#sample">Sample Config File</a></li>
+    </ol>
+  <li><a href="#glossary">Glossary</a>
+</ol>
+<div class="doc_author">
+<p>Written by <a href="mailto:rspencer@x10sys.com">Reid Spencer</a>
+</p>
+</div>
+
+<!-- *********************************************************************** -->
+<div class="doc_section"> <a name="abstract">Abstract</a></div>
+<!-- *********************************************************************** -->
+<div class="doc_text">
+  <p>This document describes the requirements, design, and configuration of the
+  LLVM compiler driver, <tt>llvmc</tt>.  The compiler driver knows about LLVM's 
+  tool set and can be configured to know about a variety of compilers for 
+  source languages.  It uses this knowledge to execute the tools necessary 
+  to accomplish general compilation, optimization, and linking tasks. The main 
+  purpose of <tt>llvmc</tt> is to provide a simple and consistent interface to 
+  all compilation tasks. This reduces the burden on the end user who can just 
+  learn to use <tt>llvmc</tt> instead of the entire LLVM tool set and all the
+  source language compilers compatible with LLVM.</p>
+</div>
+<!-- *********************************************************************** -->
+<div class="doc_section"> <a name="introduction">Introduction</a></div>
+<!-- *********************************************************************** -->
+<div class="doc_text">
+  <p>The <tt>llvmc</tt> <a href="#def_tool">tool</a> is a configurable compiler 
+  <a href="#def_driver">driver</a>. As such, it isn't a compiler, optimizer, 
+  or a linker itself but it drives (invokes) other software that perform those 
+  tasks. If you are familiar with the GNU Compiler Collection's <tt>gcc</tt> 
+  tool, <tt>llvmc</tt> is very similar.</p>
+  <p>The following introductory sections will help you understand why this tool
+  is necessary and what it does.</p>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"><a name="purpose">Purpose</a></div>
+<div class="doc_text">
+  <p><tt>llvmc</tt> was invented to make compilation of user programs with 
+  LLVM-based tools easier. To accomplish this, <tt>llvmc</tt> strives to:</p>
+  <ul>
+    <li>Be the single point of access to most of the LLVM tool set.</li>
+    <li>Hide the complexities of the LLVM tools through a single interface.</li>
+    <li>Provide a consistent interface for compiling all languages.</li>
+  </ul>
+  <p>Additionally, <tt>llvmc</tt> makes it easier to write a compiler for use
+  with LLVM, because it:</p>
+  <ul>
+    <li>Makes integration of existing non-LLVM tools simple.</li>
+    <li>Extends the capabilities of minimal compiler tools by optimizing their
+    output.</li>
+    <li>Reduces the number of interfaces a compiler writer must know about
+    before a working compiler can be completed (essentially only the VMCore
+    interfaces need to be understood).</li>
+    <li>Supports source language translator invocation via both dynamically
+    loadable shared objects and invocation of an executable.</li>
+  </ul>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"><a name="operation">Operation</a></div>
+<div class="doc_text">
+  <p>At a high level, <tt>llvmc</tt> operation is very simple.  The basic action
+  taken by <tt>llvmc</tt> is to simply invoke some tool or set of tools to fill 
+  the user's request for compilation. Every execution of <tt>llvmc</tt>takes the 
+  following sequence of steps:</p>
+  <dl>
+    <dt><b>Collect Command Line Options</b></dt>
+    <dd>The command line options provide the marching orders to <tt>llvmc</tt> 
+    on what actions it should perform. This is the request the user is making 
+    of <tt>llvmc</tt> and it is interpreted first. See the <tt>llvmc</tt>
+    <a href="CommandGuide/html/llvmc.html">manual page</a> for details on the
+    options.</dd>
+    <dt><b>Read Configuration Files</b></dt>
+    <dd>Based on the options and the suffixes of the filenames presented, a set 
+    of configuration files are read to configure the actions <tt>llvmc</tt> will 
+    take.  Configuration files are provided by either LLVM or the 
+    compiler tools that <tt>llvmc</tt> invokes. These files determine what 
+    actions <tt>llvmc</tt> will take in response to the user's request. See 
+    the section on <a href="#configuration">configuration</a> for more details.
+    </dd>
+    <dt><b>Determine Phases To Execute</b></dt>
+    <dd>Based on the command line options and configuration files,
+    <tt>llvmc</tt> determines the compilation <a href="#phases">phases</a> that
+    must be executed by the user's request. This is the primary work of
+    <tt>llvmc</tt>.</dd>
+    <dt><b>Determine Actions To Execute</b></dt>
+    <dd>Each <a href="#phases">phase</a> to be executed can result in the
+    invocation of one or more <a href="#actions">actions</a>. An action is
+    either a whole program or a function in a dynamically linked shared library. 
+    In this step, <tt>llvmc</tt> determines the sequence of actions that must be 
+    executed. Actions will always be executed in a deterministic order.</dd>
+    <dt><b>Execute Actions</b></dt>
+    <dd>The <a href="#actions">actions</a> necessary to support the user's
+    original request are executed sequentially and deterministically. All 
+    actions result in either the invocation of a whole program to perform the 
+    action or the loading of a dynamically linkable shared library and invocation 
+    of a standard interface function within that library.</dd> 
+    <dt><b>Termination</b></dt>
+    <dd>If any action fails (returns a non-zero result code), <tt>llvmc</tt>
+    also fails and returns the result code from the failing action. If
+    everything succeeds, <tt>llvmc</tt> will return a zero result code.</dd>
+  </dl>
+  <p><tt>llvmc</tt>'s operation must be simple, regular and predictable. 
+  Developers need to be able to rely on it to take a consistent approach to
+  compilation. For example, the invocation:</p>
+  <code>
+    llvmc -O2 x.c y.c z.c -o xyz</code>
+  <p>must produce <i>exactly</i> the same results as:</p>
+  <pre><tt>
+    llvmc -O2 x.c -o x.o
+    llvmc -O2 y.c -o y.o
+    llvmc -O2 z.c -o z.o
+    llvmc -O2 x.o y.o z.o -o xyz</tt></pre>
+  <p>To accomplish this, <tt>llvmc</tt> uses a very simple goal oriented
+  procedure to do its work. The overall goal is to produce a functioning
+  executable. To accomplish this, <tt>llvmc</tt> always attempts to execute a 
+  series of compilation <a href="#def_phase">phases</a> in the same sequence. 
+  However, the user's options to <tt>llvmc</tt> can cause the sequence of phases 
+  to start in the middle or finish early.</p>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"><a name="phases"></a>Phases </div>
+<div class="doc_text">
+  <p><tt>llvmc</tt> breaks every compilation task into the following five 
+  distinct phases:</p>
+  <dl><dt><b>Preprocessing</b></dt><dd>Not all languages support preprocessing; 
+    but for those that do, this phase can be invoked. This phase is for 
+    languages that provide combining, filtering, or otherwise altering with the 
+    source language input before the translator parses it. Although C and C++ 
+    are the most common users of this phase, other languages may provide their 
+    own preprocessor (whether its the C pre-processor or not).</dd>
+  </dl>
+  <dl><dt><b>Translation</b></dt><dd>The translation phase converts the source 
+    language input into something that LLVM can interpret and use for 
+    downstream phases. The translation is essentially from "non-LLVM form" to
+    "LLVM form".</dd>
+  </dl>
+  <dl><dt><b>Optimization</b></dt><dd>Once an LLVM Module has been obtained from 
+    the translation phase, the program enters the optimization phase. This phase 
+    attempts to optimize all of the input provided on the command line according 
+    to the options provided.</dd>
+  </dl>
+  <dl><dt><b>Linking</b></dt><dd>The inputs are combined to form a complete
+    program.</dd>
+  </dl>
+  <p>The following table shows the inputs, outputs, and command line options
+  applicable to each phase.</p>
+  <table>
+    <tr>
+      <th style="width: 10%">Phase</th>
+      <th style="width: 25%">Inputs</th>
+      <th style="width: 25%">Outputs</th>
+      <th style="width: 40%">Options</th>
+    </tr>
+    <tr><td><b>Preprocessing</b></td>
+      <td class="td_left"><ul><li>Source Language File</li></ul></td>
+      <td class="td_left"><ul><li>Source Language File</li></ul></td>
+      <td class="td_left"><dl>
+          <dt><tt>-E</tt></dt>
+          <dd>Stops the compilation after preprocessing</dd>
+      </dl></td>
+    </tr>
+    <tr>
+      <td><b>Translation</b></td>
+      <td class="td_left"><ul>
+          <li>Source Language File</li>
+      </ul></td>
+      <td class="td_left"><ul>
+          <li>LLVM Assembly</li>
+          <li>LLVM Bytecode</li>
+          <li>LLVM C++ IR</li>
+      </ul></td>
+      <td class="td_left"><dl>
+          <dt><tt>-c</tt></dt>
+          <dd>Stops the compilation after translation so that optimization and 
+          linking are not done.</dd>
+          <dt><tt>-S</tt></dt>
+          <dd>Stops the compilation before object code is written so that only
+          assembly code remains.</dd>
+      </dl></td>
+    </tr>
+    <tr>
+      <td><b>Optimization</b></td>
+      <td class="td_left"><ul>
+          <li>LLVM Assembly</li>
+          <li>LLVM Bytecode</li>
+      </ul></td>
+      <td class="td_left"><ul>
+          <li>LLVM Bytecode</li>
+      </ul></td>
+      <td class="td_left"><dl>
+          <dt><tt>-Ox</tt>
+          <dd>This group of options controls the amount of optimization 
+          performed.</dd>
+      </dl></td>
+    </tr>
+    <tr>
+      <td><b>Linking</b></td>
+      <td class="td_left"><ul>
+          <li>LLVM Bytecode</li>
+          <li>Native Object Code</li>
+          <li>LLVM Library</li>
+          <li>Native Library</li>
+      </ul></td>
+      <td class="td_left"><ul>
+          <li>LLVM Bytecode Executable</li>
+          <li>Native Executable</li>
+      </ul></td>
+      <td class="td_left"><dl>
+          <dt><tt>-L</tt></dt><dd>Specifies a path for library search.</dd>
+          <dt><tt>-l</tt></dt><dd>Specifies a library to link in.</dd>
+      </dl></td>
+    </tr>
+  </table>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"><a name="actions"></a>Actions</div>
+<div class="doc_text">
+  <p>An action, with regard to <tt>llvmc</tt> is a basic operation that it takes
+  in order to fulfill the user's request. Each phase of compilation will invoke
+  zero or more actions in order to accomplish that phase.</p>
+  <p>Actions come in two forms:</p>
+  <ul>
+    <li>Invokable Executables</li>
+    <li>Functions in a shared library</li>
+  </ul>
+</div>
+
+<!-- *********************************************************************** -->
+<div class="doc_section"><a name="configuration">Configuration</a></div>
+<!-- *********************************************************************** -->
+<div class="doc_text">
+  <p>This section of the document describes the configuration files used by
+  <tt>llvmc</tt>.  Configuration information is relatively static for a 
+  given release of LLVM and a compiler tool. However, the details may 
+  change from release to release of either.  Users are encouraged to simply use 
+  the various options of the <tt>llvmc</tt> command and ignore the configuration 
+  of the tool. These configuration files are for compiler writers and LLVM 
+  developers. Those wishing to simply use <tt>llvmc</tt> don't need to understand 
+  this section but it may be instructive on how the tool works.</p>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"><a name="overview"></a>Overview</div>
+<div class="doc_text">
+<p><tt>llvmc</tt> is highly configurable both on the command line and in 
+configuration files. The options it understands are generic, consistent and 
+simple by design.  Furthermore, the <tt>llvmc</tt> options apply to the 
+compilation of any LLVM enabled programming language. To be enabled as a 
+supported source language compiler, a compiler writer must provide a 
+configuration file that tells <tt>llvmc</tt> how to invoke the compiler 
+and what its capabilities are. The purpose of the configuration files then 
+is to allow compiler writers to specify to <tt>llvmc</tt> how the compiler 
+should be invoked. Users may but are not advised to alter the compiler's 
+<tt>llvmc</tt> configuration.</p>
+
+<p>Because <tt>llvmc</tt> just invokes other programs, it must deal with the
+available command line options for those programs regardless of whether they
+were written for LLVM or not. Furthermore, not all compiler tools will
+have the same capabilities. Some compiler tools will simply generate LLVM assembly
+code, others will be able to generate fully optimized byte code. In general,
+<tt>llvmc</tt> doesn't make any assumptions about the capabilities or command 
+line options of a sub-tool. It simply uses the details found in the 
+configuration files and leaves it to the compiler writer to specify the 
+configuration correctly.</p>
+
+<p>This approach means that new compiler tools can be up and working very
+quickly. As a first cut, a tool can simply compile its source to raw
+(unoptimized) bytecode or LLVM assembly and <tt>llvmc</tt> can be configured 
+to pick up the slack (translate LLVM assembly to bytecode, optimize the 
+bytecode, generate native assembly, link, etc.).   In fact, the compiler tools 
+need not use any LLVM libraries, and it could be written in any language 
+(instead of C++).  The configuration data will allow the full range of 
+optimization, assembly, and linking capabilities that LLVM provides to be added 
+to these kinds of tools.  Enabling the rapid development of front-ends is one 
+of the primary goals of <tt>llvmc</tt>.</p>
+
+<p>As a compiler tool matures, it may utilize the LLVM libraries and tools 
+to more efficiently produce optimized bytecode directly in a single compilation 
+and optimization program. In these cases, multiple tools would not be needed 
+and the configuration data for the compiler would change.</p>
+
+<p>Configuring <tt>llvmc</tt> to the needs and capabilities of a source language 
+compiler is relatively straight-forward.  A compiler writer must provide a 
+definition of what to do for each of the five compilation phases for each of 
+the optimization levels. The specification consists simply of prototypical 
+command lines into which <tt>llvmc</tt> can substitute command line
+arguments and file names. Note that any given phase can be completely blank if
+the source language's compiler combines multiple phases into a single program.
+For example, quite often pre-processing, translation, and optimization are
+combined into a single program. The specification for such a compiler would have
+blank entries for pre-processing and translation but a full command line for
+optimization.</p>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"><a name="filetypes">Configuration Files</a></div>
+<div class="doc_subsubsection"><a name="filecontents">File Contents</a></div>
+<div class="doc_text">
+  <p>Each configuration file provides the details for a single source language
+  that is to be compiled.  This configuration information tells <tt>llvmc</tt> 
+  how to invoke the language's pre-processor, translator, optimizer, assembler
+  and linker. Note that a given source language needn't provide all these tools
+  as many of them exist in llvm currently.</p>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection"><a name="dirsearch">Directory Search</a></div>
+<div class="doc_text">
+  <p><tt>llvmc</tt> always looks for files of a specific name. It uses the
+  first file with the name its looking for by searching directories in the
+  following order:<br/>
+  <ol>
+    <li>Any directory specified by the <tt>-config-dir</tt> option will be
+    checked first.</li>
+    <li>If the environment variable LLVM_CONFIG_DIR is set, and it contains
+    the name of a valid directory, that directory will be searched next.</li>
+    <li>If the user's home directory (typically <tt>/home/user</tt> contains 
+    a sub-directory named <tt>.llvm</tt> and that directory contains a 
+    sub-directory named <tt>etc</tt> then that directory will be tried 
+    next.</li>
+    <li>If the LLVM installation directory (typically <tt>/usr/local/llvm</tt>
+    contains a sub-directory named <tt>etc</tt> then that directory will be
+    tried last.</li>
+    <li>A standard "system" directory will be searched next. This is typically
+    <tt>/etc/llvm</tt> on UNIX&trade; and <tt>C:\WINNT</tt> on Microsoft
+    Windows&trade;.</li>
+    <li>If the configuration file sought still can't be found, <tt>llvmc</tt>
+    will print an error message and exit.</li>
+  </ol>
+  <p>The first file found in this search will be used. Other files with the 
+  same name will be ignored even if they exist in one of the subsequent search
+  locations.</p>
+</div>
+
+<div class="doc_subsubsection"><a name="filenames">File Names</a></div>
+<div class="doc_text">
+  <p>In the directories searched, each configuration file is given a specific
+  name to foster faster lookup (so llvmc doesn't have to do directory searches).
+  The name of a given language specific configuration file is simply the same 
+  as the suffix used to identify files containing source in that language. 
+  For example, a configuration file for C++ source might be named 
+  <tt>cpp</tt>, <tt>C</tt>, or <tt>cxx</tt>. For languages that support multiple
+  file suffixes, multiple (probably identical) files (or symbolic links) will
+  need to be provided.</p>
+</div>
+
+<div class="doc_subsubsection"><a name="whatgetsread">What Gets Read</a></div>
+<div class="doc_text">
+  <p>Which configuration files are read depends on the command line options and 
+  the suffixes of the file names provided on <tt>llvmc</tt>'s command line. Note
+  that the <tt>-x LANGUAGE</tt> option alters the language that <tt>llvmc</tt>
+  uses for the subsequent files on the command line.  Only the configuration 
+  files actually needed to complete <tt>llvmc</tt>'s task are read. Other 
+  language specific files will be ignored.</p>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"><a name="syntax"></a>Syntax</div>
+<div class="doc_text">
+  <p>The syntax of the configuration files is very simple and somewhat
+  compatible with Java's property files. Here are the syntax rules:</p>
+  <ul>
+    <li>The file encoding is ASCII.</li>
+    <li>The file is line oriented. There should be one configuration definition 
+    per line. Lines are terminated by the newline (0x0A) and/or carriage return
+    characters (0x0D)</li>
+    <li>A backslash (<tt>\</tt>) before a newline causes the newline to be
+    ignored. This is useful for line continuation of long definitions. A
+    backslash anywhere else is recognized as a backslash.</li>
+    <li>A configuration item consists of a name, an <tt>=</tt> and a value.</li>
+    <li>A name consists of a sequence of identifiers separated by period.</li>
+    <li>An identifier consists of specific keywords made up of only lower case
+    and upper case letters (e.g. <tt>lang.name</tt>).</li>
+    <li>Values come in four flavors: booleans, integers, commands and 
+    strings.</li>
+    <li>Valid "false" boolean values are <tt>false False FALSE no No NO
+      off Off</tt> and <tt>OFF</tt>.</li>
+    <li>Valid "true" boolean values are <tt>true True TRUE yes Yes YES
+      on On</tt> and <tt>ON</tt>.</li>
+    <li>Integers are simply sequences of digits.</li>
+    <li>Commands start with a program name and are followed by a sequence of
+    words that are passed to that program as command line arguments. Program
+    arguments that begin and end with the <tt>%</tt> sign will have their value
+    substituted. Program names beginning with <tt>/</tt> are considered to be
+    absolute. Otherwise the <tt>PATH</tt> will be applied to find the program to
+    execute.</li>
+    <li>Strings are composed of multiple sequences of characters from the
+    character class <tt>[-A-Za-z0-9_:%+/\\|,]</tt> separated by white
+    space.</li>
+    <li>White space on a line is folded. Multiple blanks or tabs will be
+    reduced to a single blank.</li>
+    <li>White space before the configuration item's name is ignored.</li>
+    <li>White space on either side of the <tt>=</tt> is ignored.</li>
+    <li>White space in a string value is used to separate the individual
+    components of the string value but otherwise ignored.</li>
+    <li>Comments are introduced by the <tt>#</tt> character. Everything after a
+    <tt>#</tt> and before the end of line is ignored.</li>
+  </ul>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"><a name="items">Configuration Items</a></div>
+<div class="doc_text">
+  <p>The table below provides definitions of the allowed configuration items
+  that may appear in a configuration file. Every item has a default value and
+  does not need to appear in the configuration file. Missing items will have the 
+  default value. Each identifier may appear as all lower case, first letter
+  capitalized or all upper case.</p>
+  <table>
+    <tbody>
+      <tr>
+        <th>Name</th>
+        <th>Value Type</th>
+        <th>Description</th>
+        <th>Default</th>
+      </tr>
+      <tr><td colspan="4"><h4>LLVMC ITEMS</h4></td></tr>
+      <tr>
+        <td><b>version</b></td>
+        <td>string</td>
+        <td class="td_left">Provides the version string for the contents of this
+          configuration file. What is accepted as a legal configuration file
+          will change over time and this item tells <tt>llvmc</tt> which version
+          should be expected.</td>
+        <td><i>b</i></td>
+      </tr>
+      <tr><td colspan="4"><h4>LANG ITEMS</h4></td></tr>
+      <tr>
+        <td><b>lang.name</b></td>
+        <td>string</td>
+        <td class="td_left">Provides the common name for a language definition. 
+          For example "C++", "Pascal", "FORTRAN", etc.</td>
+        <td><i>blank</i></td>
+      </tr>
+      <tr>
+        <td><b>lang.opt1</b></td>
+        <td>string</td>
+        <td class="td_left">Specifies the parameters to give the optimizer when
+          <tt>-O1</tt> is specified on the <tt>llvmc</tt> command line.</td>
+        <td><tt>-simplifycfg -instcombine -mem2reg</tt></td>
+      </tr>
+      <tr>
+        <td><b>lang.opt2</b></td>
+        <td>string</td>
+        <td class="td_left">Specifies the parameters to give the optimizer when
+          <tt>-O2</tt> is specified on the <tt>llvmc</tt> command line.</td>
+        <td><i>TBD</i></td>
+      </tr>
+      <tr>
+        <td><b>lang.opt3</b></td>
+        <td>string</td>
+        <td class="td_left">Specifies the parameters to give the optimizer when
+          <tt>-O3</tt> is specified on the <tt>llvmc</tt> command line.</td>
+        <td><i>TBD</i></td>
+      </tr>
+      <tr>
+        <td><b>lang.opt4</b></td>
+        <td>string</td>
+        <td class="td_left">Specifies the parameters to give the optimizer when
+          <tt>-O4</tt> is specified on the <tt>llvmc</tt> command line.</td>
+        <td><i>TBD</i></td>
+      </tr>
+      <tr>
+        <td><b>lang.opt5</b></td>
+        <td>string</td>
+        <td class="td_left">Specifies the parameters to give the optimizer when 
+          <tt>-O5</tt> is specified on the <tt>llvmc</tt> command line.</td>
+        <td><i>TBD</i></td>
+      </tr>
+      <tr><td colspan="4"><h4>PREPROCESSOR ITEMS</h4></td></tr>
+      <tr>
+        <td><b>preprocessor.command</b></td>
+        <td>command</td>
+        <td class="td_left">This provides the command prototype that will be used
+          to run the preprocessor.  This is generally only used with the 
+          <tt>-E</tt> option.</td>
+        <td>&lt;blank&gt;</td>
+      </tr>
+      <tr>
+        <td><b>preprocessor.required</b></td>
+        <td>boolean</td>
+        <td class="td_left">This item specifies whether the pre-processing phase
+          is required by the language. If the value is true, then the
+          <tt>preprocessor.command</tt> value must not be blank. With this option,
+          <tt>llvmc</tt> will always run the preprocessor as it assumes that the
+          translation and optimization phases don't know how to pre-process their
+          input.</td>
+        <td>false</td>
+      </tr>
+      <tr><td colspan="4"><h4>TRANSLATOR ITEMS</h4></td></tr>
+      <tr>
+        <td><b>translator.command</b></td>
+        <td>command</td>
+        <td class="td_left">This provides the command prototype that will be used 
+          to run the translator. Valid substitutions are <tt>%in%</tt> for the 
+          input file and <tt>%out%</tt> for the output file.</td>
+        <td>&lt;blank&gt;</td>
+      </tr>
+      <tr>
+        <td><b>translator.output</b></td>
+        <td><tt>bytecode</tt> or <tt>assembly</tt></td>
+        <td class="td_left">This item specifies the kind of output the language's 
+          translator generates.</td>
+        <td><tt>bytecode</tt></td>
+      </tr>
+      <tr>
+        <td><b>translator.preprocesses</b></td>
+        <td>boolean</td>
+        <td class="td_left">Indicates that the translator also preprocesses. If
+          this is true, then <tt>llvmc</tt> will skip the pre-processing phase
+          whenever the final phase is not pre-processing.</td>
+        <td><tt>false</tt></td>
+      </tr>
+      <tr><td colspan="4"><h4>OPTIMIZER ITEMS</h4></td></tr>
+      <tr>
+        <td><b>optimizer.command</b></td>
+        <td>command</td>
+        <td class="td_left">This provides the command prototype that will be used 
+          to run the optimizer. Valid substitutions are <tt>%in%</tt> for the 
+          input file and <tt>%out%</tt> for the output file.</td>
+        <td>&lt;blank&gt;</td>
+      </tr>
+      <tr>
+        <td><b>optimizer.output</b></td>
+        <td><tt>bytecode</tt> or <tt>assembly</tt></td>
+        <td class="td_left">This item specifies the kind of output the language's 
+          optimizer generates. Valid values are "assembly" and "bytecode"</td>
+        <td><tt>bytecode</tt></td>
+      </tr>
+      <tr>
+        <td><b>optimizer.preprocesses</b></td>
+        <td>boolean</td>
+        <td class="td_left">Indicates that the optimizer also preprocesses. If
+          this is true, then <tt>llvmc</tt> will skip the pre-processing phase
+          whenever the final phase is optimization or later.</td>
+        <td><tt>false</tt></td>
+      </tr>
+      <tr>
+        <td><b>optimizer.translates</b></td>
+        <td>boolean</td>
+        <td class="td_left">Indicates that the optimizer also translates. If
+          this is true, then <tt>llvmc</tt> will skip the translation phase
+          whenever the final phase is optimization or later.</td>
+        <td><tt>false</tt></td>
+      </tr>
+      <tr><td colspan="4"><h4>ASSEMBLER ITEMS</h4></td></tr>
+      <tr>
+        <td><b>assembler.command</b></td>
+        <td>command</td>
+        <td class="td_left">This provides the command prototype that will be used 
+          to run the assembler. Valid substitutions are <tt>%in%</tt> for the 
+          input file and <tt>%out%</tt> for the output file.</td>
+        <td>&lt;blank&gt;</td>
+      </tr>
+    </tbody>
+  </table>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"><a name="substitutions">Substitutions</a></div>
+<div class="doc_text">
+  <p>On any configuration item that ends in <tt>command</tt>, you must
+  specify substitution tokens.  Substitution tokens begin and end with a percent
+  sign (<tt>%</tt>) and are replaced by the corresponding text. Any substitution
+  token may be given on any <tt>command</tt> line but some are more useful than
+  others. In particular each command <em>should</em> have both an <tt>%in%</tt>
+  and an <tt>%out%</tt> substitution. The table below provides definitions of
+  each of the allowed substitution tokens.</p>
+  <table>
+    <tbody>
+      <tr>
+        <th>Substitution Token</th>
+        <th>Replacement Description</th>
+      </tr>
+      <tr>
+        <td><tt>%args%</tt></td>
+        <td class="td_left">Replaced with all the tool-specific arguments given
+          to <tt>llvmc</tt> via the <tt>-T</tt> set of options. This just allows
+          you to place these arguments in the correct place on the command line.
+          If the <tt>%args%</tt> option does not appear on your command line, 
+          then you are explicitly disallowing the <tt>-T</tt> option for your 
+          tool.
+        </td>
+      <tr>
+        <td><tt>%force%</tt></td>
+        <td class="td_left">Replaced with the <tt>-f</tt> option if it was
+          specified on the <tt>llvmc</tt> command line. This is intended to tell
+          the compiler tool to force the overwrite of output files. 
+        </td>
+      </tr>
+      <tr>
+        <td><tt>%in%</tt></td>
+        <td class="td_left">Replaced with the full path of the input file. You
+          needn't worry about the cascading of file names. <tt>llvmc</tt> will
+          create temporary files and ensure that the output of one phase is the
+          input to the next phase.</td>
+      </tr>
+      <tr>
+        <td><tt>%opt%</tt></td>
+        <td class="td_left">Replaced with the optimization options for the
+          tool. If the tool understands the <tt>-O</tt> options then that will
+          be passed. Otherwise, the <tt>lang.optN</tt> series of configuration
+          items will specify which arguments are to be given.</td>
+      </tr>
+      <tr>
+        <td><tt>%out%</tt></td>
+        <td class="td_left">Replaced with the full path of the output file.
+          Note that this is not necessarily the output file specified with the
+          <tt>-o</tt> option on <tt>llvmc</tt>'s command line. It might be a
+          temporary file that will be passed to a subsequent phase's input.
+        </td>
+      </tr>
+      <tr>
+        <td><tt>%stats%</tt></td>
+        <td class="td_left">If your command accepts the <tt>-stats</tt> option,
+          use this substitution token. If the user requested <tt>-stats</tt> 
+          from the <tt>llvmc</tt> command line then this token will be replaced
+          with <tt>-stats</tt>, otherwise it will be ignored.
+        </td>
+      </tr>
+      <tr>
+        <td><tt>%target%</tt></td>
+        <td class="td_left">Replaced with the name of the target "machine" for 
+          which code should be generated. The value used here is taken from the
+          <tt>llvmc</tt> option <tt>-march</tt>.
+        </td>
+      </tr>
+      <tr>
+        <td><tt>%time%</tt></td>
+        <td class="td_left">If your command accepts the <tt>-time-passes</tt> 
+          option, use this substitution token. If the user requested 
+          <tt>-time-passes</tt> from the <tt>llvmc</tt> command line then this 
+          token will be replaced with <tt>-time-passes</tt>, otherwise it will 
+          be ignored.
+        </td>
+      </tr>
+    </tbody>
+  </table>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"><a name="sample">Sample Config File</a></div>
+<div class="doc_text">
+  <p>Since an example is always instructive, here's how the Stacker language
+  configuration file looks.</p>
+  <pre><tt>
+# Stacker Configuration File For llvmc
+
+##########################################################
+# Language definitions
+##########################################################
+  lang.name=Stacker 
+  lang.opt1=-simplifycfg -instcombine -mem2reg
+  lang.opt2=-simplifycfg -instcombine -mem2reg -load-vn \
+    -gcse -dse -scalarrepl -sccp 
+  lang.opt3=-simplifycfg -instcombine -mem2reg -load-vn \
+    -gcse -dse -scalarrepl -sccp -branch-combine -adce \
+    -globaldce -inline -licm 
+  lang.opt4=-simplifycfg -instcombine -mem2reg -load-vn \
+    -gcse -dse -scalarrepl -sccp -ipconstprop \
+    -branch-combine -adce -globaldce -inline -licm 
+  lang.opt5=-simplifycfg -instcombine -mem2reg --load-vn \
+    -gcse -dse scalarrepl -sccp -ipconstprop \
+    -branch-combine -adce -globaldce -inline -licm \
+    -block-placement
+
+##########################################################
+# Pre-processor definitions
+##########################################################
+
+  # Stacker doesn't have a preprocessor but the following
+  # allows the -E option to be supported
+  preprocessor.command=cp %in% %out%
+  preprocessor.required=false
+
+##########################################################
+# Translator definitions
+##########################################################
+
+  # To compile stacker source, we just run the stacker
+  # compiler with a default stack size of 2048 entries.
+  translator.command=stkrc -s 2048 %in% -o %out% %time% \
+    %stats% %force% %args%
+
+  # stkrc doesn't preprocess but we set this to true so
+  # that we don't run the cp command by default.
+  translator.preprocesses=true
+
+  # The translator is required to run.
+  translator.required=true
+
+  # stkrc doesn't handle the -On options
+  translator.output=bytecode
+
+##########################################################
+# Optimizer definitions
+##########################################################
+  
+  # For optimization, we use the LLVM "opt" program
+  optimizer.command=opt %in% -o %out% %opt% %time% %stats% \
+    %force% %args%
+
+  optimizer.required = true
+
+  # opt doesn't translate
+  optimizer.translates = no
+
+  # opt doesn't preprocess
+  optimizer.preprocesses=no
+
+  # opt produces bytecode
+  optimizer.output = bc
+
+##########################################################
+# Assembler definitions
+##########################################################
+  assembler.command=llc %in% -o %out% %target% %time% %stats%
+</tt></pre>
+</div> 
+
+<!-- *********************************************************************** -->
+<div class="doc_section"><a name="glossary">Glossary</a></div>
+<!-- *********************************************************************** -->
+<div class="doc_text">
+  <p>This document uses precise terms in reference to the various artifacts and
+  concepts related to compilation. The terms used throughout this document are
+  defined below.</p>
+  <dl>
+    <dt><a name="def_assembly"><b>assembly</b></a></dt> 
+    <dd>A compilation <a href="#def_phase">phase</a> in which LLVM bytecode or 
+    LLVM assembly code is assembled to a native code format (either target 
+    specific aseembly language or the platform's native object file format).
+    </dd>
+
+    <dt><a name="def_compiler"><b>compiler</b></a></dt>
+    <dd>Refers to any program that can be invoked by <tt>llvmc</tt> to accomplish 
+    the work of one or more compilation <a href="#def_phase">phases</a>.</dd>
+
+    <dt><a name="def_driver"><b>driver</b></a></dt>
+    <dd>Refers to <tt>llvmc</tt> itself.</dd>
+
+    <dt><a name="def_linking"><b>linking</b></a></dt>
+    <dd>A compilation <a href="#def_phase">phase</a> in which LLVM bytecode files 
+    and (optionally) native system libraries are combined to form a complete 
+    executable program.</dd>
+
+    <dt><a name="def_optimization"><b>optimization</b></a></dt>
+    <dd>A compilation <a href="#def_phase">phase</a> in which LLVM bytecode is 
+    optimized.</dd>
+
+    <dt><a name="def_phase"><b>phase</b></a></dt>
+    <dd>Refers to any one of the five compilation phases that that 
+    <tt>llvmc</tt> supports. The five phases are:
+    <a href="#def_preprocessing">preprocessing</a>, 
+    <a href="#def_translation">translation</a>,
+    <a href="#def_optimization">optimization</a>,
+    <a href="#def_assembly">assembly</a>,
+    <a href="#def_linking">linking</a>.</dd>
+
+    <dt><a name="def_sourcelanguage"><b>source language</b></a></dt>
+    <dd>Any common programming language (e.g. C, C++, Java, Stacker, ML,
+    FORTRAN).  These languages are distinguished from any of the lower level
+    languages (such as LLVM or native assembly), by the fact that a 
+    <a href="#def_translation">translation</a> <a href="#def_phase">phase</a> 
+    is required before LLVM can be applied.</dd> 
+
+    <dt><a name="def_tool"><b>tool</b></a></dt>
+    <dd>Refers to any program in the LLVM tool set.</dd>
+
+    <dt><a name="def_translation"><b>translation</b></a></dt>
+    <dd>A compilation <a href="#def_phase">phase</a> in which 
+    <a href="#def_sourcelanguage">source language</a> code is translated into 
+    either LLVM assembly language or LLVM bytecode.</dd>
+  </dl>
+</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>
+<!-- vim: sw=2
+-->
+</body>
+</html>

llvm/docs/CompilerWriterInfo.html

@@ -0,0 +1,260 @@
+<!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>Architecture/platform information for compiler writers</title>
+  <link rel="stylesheet" href="llvm.css" type="text/css">
+</head>
+
+<div class="doc_title">
+  Architecture/platform information for compiler writers
+</div>
+
+<div class="doc_warning">
+  <p>Note: This document is a work-in-progress.  Additions and clarifications
+  are welcome.</p>
+</div>
+
+<ol>
+  <li><a href="#hw">Hardware</a>
+  <ol>
+    <li><a href="#alpha">Alpha</a></li>
+    <li><a href="#arm">ARM</a></li>
+    <li><a href="#ia64">Itanium</a></li>
+    <li><a href="#mips">MIPS</a></li>
+    <li><a href="#ppc">PowerPC</a></li>
+    <li><a href="#sparc">SPARC</a></li>
+    <li><a href="#x86">X86</a></li>
+    <li><a href="#other">Other lists</a></li>
+  </ol></li>
+  <li><a href="#abi">Application Binary Interface (ABI)</a>
+  <ol>
+    <li><a href="#linux">Linux</a></li>
+    <li><a href="#osx">OS X</a></li>
+  </ol></li>
+  <li><a href="#misc">Miscellaneous resources</a></li>
+</ol>
+
+<div class="doc_author">
+  <p>Compiled by <a href="http://misha.brukman.net">Misha Brukman</a></p>
+</div>
+
+<!-- *********************************************************************** -->
+<div class="doc_section"><a name="hw">Hardware</a></div>
+<!-- *********************************************************************** -->
+
+<!-- ======================================================================= -->
+<div class="doc_subsection"><a name="alpha">Alpha</a></div>
+
+<div class="doc_text">
+<ul>
+<li><a
+href="http://ftp.digital.com/pub/Digital/info/semiconductor/literature/dsc-library.html">Alpha manuals</a> 
+</li>
+</ul>
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection"><a name="arm">ARM</a></div>
+
+<div class="doc_text">
+<ul>
+<li><a href="http://www.arm.com/documentation/">ARM documentation</a> 
+(<a href="http://www.arm.com/documentation/ARMProcessor_Cores/">Processor
+Cores</a>)</li>
+</ul>
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection"><a name="ia64">Itanium (ia64)</a></div>
+
+<div class="doc_text">
+<ul>
+<li><a
+href="http://developer.intel.com/design/itanium2/documentation.htm">Itanium documentation</a> 
+</li>
+</ul>
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection"><a name="mips">MIPS</a></div>
+
+<div class="doc_text">
+<ul>
+<li><a
+href="http://mips.com/content/Documentation/MIPSDocumentation/ProcessorArchitecture/doclibrary">MIPS
+Processor Architecture</a></li>
+</ul>
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection"><a name="ppc">PowerPC</a></div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">IBM - Official manuals and docs</div>
+
+<div class="doc_text">
+
+<ul>
+<li><a
+href="http://www-106.ibm.com/developerworks/eserver/articles/archguide.html">PowerPC
+Architecture Book</a>
+<ul>
+  <li>Book I: <a
+  href="http://www-106.ibm.com/developerworks/eserver/pdfs/archpub1.pdf">PowerPC
+  User Instruction Set Architecture</a></li>
+  <li>Book II: <a
+  href="http://www-106.ibm.com/developerworks/eserver/pdfs/archpub2.pdf">PowerPC
+  Virtual Environment Architecture</a></li>
+  <li>Book III: <a
+  href="http://www-106.ibm.com/developerworks/eserver/pdfs/archpub3.pdf">PowerPC
+  Operating Environment Architecture</a></li>
+</ul></li>
+<li><a
+href="http://www-3.ibm.com/chips/techlib/techlib.nsf/techdocs/852569B20050FF7785256996007558C6">PowerPC
+Compiler Writer's Guide</a></li>
+<li><A
+href="http://www-3.ibm.com/chips/techlib/techlib.nsf/products/PowerPC">PowerPC
+Processor Manuals</a></li>
+<li><a
+href="http://www-106.ibm.com/developerworks/linux/library/l-powarch/">Intro to
+PowerPC architecture</a></li>
+<li><a href="http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixassem/alangref/alangreftfrm.htm">IBM AIX/5L for POWER Assembly reference</a></li>
+</ul>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">Other documents, collections, notes</div>
+
+<div class="doc_text">
+
+<ul>
+<li><a href="http://penguinppc.org/dev/#library">PowerPC ABI documents</a></li>
+<li><a href="http://gcc.gnu.org/ml/gcc-patches/2003-09/msg00997.html">PowerPC64
+alignment of long doubles (from GCC)</a></li>
+<li><a href="http://sources.redhat.com/ml/binutils/2002-04/msg00573.html">Long
+branch stubs for powerpc64-linux (from binutils)</a></li>
+</ul>
+
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection"><a name="sparc">SPARC</a></div>
+
+<div class="doc_text">
+
+<ul>
+<li><a href="http://www.sparc.org/resource.htm">SPARC resources</a></li>
+<li><a href="http://www.sparc.org/standards.html">SPARC standards</a></li>
+</ul>
+
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection"><a name="x86">X86</a></div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">AMD - Official manuals and docs</div>
+
+<div class="doc_text">
+<ul>
+<li><a
+href="http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_739,00.html">AMD processor manuals</a></li>
+<li><a href="http://www.x86-64.org/documentation">X86-64 ABI</a></li>
+</ul>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">Intel - Official manuals and docs</div>
+
+<div class="doc_text">
+<ul>
+<li><a
+href="http://developer.intel.com/design/pentium4/manuals/index_new.htm">IA-32
+manuals</a></li>
+<li><a
+href="http://www.intel.com/design/itanium/documentation.htm?iid=ipp_srvr_proc_itanium2+techdocs">Intel
+Itanium documentation</a></li>
+</ul>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">Other x86-specific information</div>
+
+<div class="doc_text">
+<ul>
+<li><a href="http://www.agner.org/assem/calling_conventions.pdf">Calling
+conventions for different C++ compilers and operating systems</a></li>
+</ul>
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection"><a name="other">Other relevant lists</a></div>
+
+<div class="doc_text">
+
+<ul>
+<li><a href="http://gcc.gnu.org/readings.html">GCC reading list</a></li>
+</ul>
+
+</div>
+
+<!-- *********************************************************************** -->
+<div class="doc_section"><a name="abi">ABI</a></div>
+<!-- *********************************************************************** -->
+
+<!-- ======================================================================= -->
+<div class="doc_subsection"><a name="linux">Linux</a></div>
+
+<div class="doc_text">
+<ol>
+<li><a href="http://www.linuxbase.org/spec/ELF/ppc64/">PowerPC 64-bit ELF ABI
+Supplement</a></li>
+</ol>
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection"><a name="osx">OS X</a></div>
+
+<div class="doc_text">
+<ol>
+<li><a
+href="http://developer.apple.com/documentation/Darwin/RuntimeArchitecture-date.html">Mach-O
+Runtime Architecture</a></li>
+<li><a href="http://www.unsanity.org/archives/000044.php">Notes on Mach-O
+ABI</a></li>
+</ol>
+
+</div>
+
+<!-- *********************************************************************** -->
+<div class="doc_section"><a name="misc">Miscellaneous resources</a></div>
+<!-- *********************************************************************** -->
+
+<ul>
+<li><a
+href="http://www.nondot.org/sabre/os/articles/ExecutableFileFormats/">Executable
+File Format library</a></li>
+<li><a href="http://gcc.gnu.org/projects/prefetch.html">GCC prefetch project</a>
+page has a good survey of the prefetching capabilities of a variety of modern
+processors.</li>
+</ul>
+
+<!-- *********************************************************************** -->
+
+<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://misha.brukman.net">Misha Brukman</a><br>
+  <a href="http://llvm.cs.uiuc.edu">LLVM Compiler Infrastructure</a><br>
+  Last modified: $Date$
+</address>
+
+</body>
+</html>

llvm/docs/ExtendingLLVM.html

@@ -24,7 +24,8 @@
 </ol>
 
 <div class="doc_author">    
-  <p>Written by <a href="http://misha.brukman.net">Misha Brukman</a></p>
+  <p>Written by <a href="http://misha.brukman.net">Misha Brukman</a>,
+  Brad Jones, and <a href="http://nondot.org/sabre">Chris Lattner</a></p>
 </div>
 
 <!-- *********************************************************************** -->
@@ -62,11 +63,6 @@ looking to do can be done with already-existing infrastructure, or if maybe
 someone else is already working on it. You will save yourself a lot of time and
 effort by doing so.</p>
 
-<p>Finally, these are my notes, and since my extensions are not complete, I may
-be missing steps. If you find some omissions, please let me know <a
-href="http://misha.brukman.net/contact.html">directly</a> or post on <a
-href="http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVM-dev</a>.</p>
-
 </div>
 
 <!-- *********************************************************************** -->
@@ -90,9 +86,6 @@ function and then be turned into an instruction if warranted.</p>
 <li><tt>llvm/include/llvm/Intrinsics.h</tt>:
     add an enum in the <tt>llvm::Intrinsic</tt> namespace</li>
 
-<li><tt>llvm/lib/CodeGen/IntrinsicLowering.cpp</tt>:
-    implement the lowering for this intrinsic</li>
-
 <li><tt>llvm/lib/VMCore/Verifier.cpp</tt>:
     Add code to check the invariants of the intrinsic are respected.</li>
 
@@ -105,15 +98,62 @@ function and then be turned into an instruction if warranted.</p>
     of functions.</li>
 
 <li><tt>llvm/lib/Transforms/Utils/Local.cpp</tt>: If it is possible to constant
-    propagate your intrinsic, add support to it in the
-    <tt>canConstantFoldCallTo</tt> and <tt>ConstantFoldCall</tt> functions.</li>
+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>
+
+<li><tt>llvm/test/Regression/*</tt>: add your test cases to the test suite</li>
 </ol>
 
-<p>If this intrinsic requires code generator support (ie, it cannot be lowered).
-You should also add support to the code generator in question.</p>
+<p>Once the intrinsic has been added to the system, you must add code generator
+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.  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>
+
+<dt>Add a enum value for the SelectionDAG node in
+<tt>include/llvm/CodeGen/SelectionDAGNodes.h</tt></dt>
+
+<dd>Also, add code to <tt>lib/CodeGen/SelectionDAG/SelectionDAG.cpp</tt> (and
+<tt>SelectionDAGPrinter.cpp</tt>) to print the node.</dd>
+
+<dt>Add code to <tt>SelectionDAG/SelectionDAGISel.cpp</tt> to recognize the
+intrinsic.</dt>
+
+<dd>Presumably the intrinsic should be recognized and turned into the node you
+added above.</dd>
+
+<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>
+
+<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>
+
+<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>
 
@@ -148,14 +188,23 @@ necessary.</p>
     add the grammar on how your instruction can be read and what it will
     construct as a result</li>
 
-<li><tt>llvm/lib/Bytecode/Reader/InstructionReader.cpp</tt>:
+<li><tt>llvm/lib/Bytecode/Reader/Reader.cpp</tt>:
     add a case for your instruction and how it will be parsed from bytecode</li>
 
 <li><tt>llvm/lib/VMCore/Instruction.cpp</tt>:
     add a case for how your instruction will be printed out to assembly</li>
 
 <li><tt>llvm/lib/VMCore/Instructions.cpp</tt>:
-    implement the class you defined in <tt>llvm/include/llvm/Instructions.h</tt></li>
+    implement the class you defined in
+    <tt>llvm/include/llvm/Instructions.h</tt></li>
+
+<li>Test your instruction</li>
+
+<li><tt>llvm/lib/Target/*</tt>: 
+    Add support for your instruction to code generators, or add a lowering
+    pass.</li>
+
+<li><tt>llvm/test/Regression/*</tt>: add your test cases to the test suite.</li>
 
 </ol>
 
@@ -188,11 +237,8 @@ installations.</span> Only add new types if it is absolutely necessary.</p>
 
 <ol>
 
-<li><tt>llvm/include/llvm/Type.def</tt>:
-    add enum for the type</li>
-
 <li><tt>llvm/include/llvm/Type.h</tt>:
-    add ID number for the new type; add static <tt>Type*</tt> for this type</li>
+    add enum for the new type; add static <tt>Type*</tt> for this type</li>
 
 <li><tt>llvm/lib/VMCore/Type.cpp</tt>:
     add mapping from <tt>TypeID</tt> =&gt; <tt>Type*</tt>;
@@ -215,7 +261,53 @@ installations.</span> Only add new types if it is absolutely necessary.</p>
 
 <div class="doc_text">
 
-<p>TODO</p>
+<ol>
+<li><tt>llvm/include/llvm/Type.h</tt>:
+    add enum for the new type; add a forward declaration of the type
+    also</li>
+
+<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>
+
+<li><tt>llvm/lib/VMCore/Type.cpp</tt>:
+    add support for derived type to: 
+<div class="doc_code">
+<pre>
+std::string getTypeDescription(const Type &amp;Ty,
+  std::vector&lt;const Type*&gt; &amp;TypeStack)
+bool TypesEqual(const Type *Ty, const Type *Ty2,
+  std::map&lt;const Type*, const Type*&gt; &amp; EqTypes)
+</pre>
+</div>
+    add necessary member functions for type, and factory methods</li>
+
+<li><tt>llvm/lib/AsmReader/Lexer.l</tt>:
+    add ability to parse in the type from text assembly</li>
+
+<li><tt>llvm/lib/ByteCode/Writer/Writer.cpp</tt>:
+    modify <tt>void BytecodeWriter::outputType(const Type *T)</tt> to serialize
+    your type</li>
+
+<li><tt>llvm/lib/ByteCode/Reader/Reader.cpp</tt>:
+    modify <tt>const Type *BytecodeReader::ParseType()</tt> to read your data
+    type</li> 
+
+<li><tt>llvm/lib/VMCore/AsmWriter.cpp</tt>:
+    modify
+<div class="doc_code">
+<pre>
+void calcTypeName(const Type *Ty,
+                  std::vector&lt;const Type*&gt; &amp;TypeStack,
+                  std::map&lt;const Type*,std::string&gt; &amp;TypeNames,
+                  std::string &amp; Result)
+</pre>
+</div>
+    to output the new derived type
+</li>  
+ 
+
+</ol>
 
 </div>
 
@@ -228,7 +320,6 @@ installations.</span> Only add new types if it is absolutely necessary.</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://misha.brukman.net">Misha Brukman</a><br>
   <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
   <br>
   Last modified: $Date$

llvm/docs/FAQ.html

@@ -51,6 +51,8 @@
   <li>Compiling LLVM with GCC 3.3.2 fails, what should I do?</li>
   <li>When I use the test suite, all of the C Backend tests fail.  What is
       wrong?</li>
+  <li>After CVS update, rebuilding gives the error "No rule to make
+  target".</li>
   </ol></li>
 
   <li><a href="#cfe">Using the GCC Front End</a>
@@ -65,17 +67,23 @@
     When I compile code using the LLVM GCC front end, it complains that it
     cannot find libcrtend.a.
     </li>
+
+    <li>
+    How can I disable all optimizations when compiling code using the LLVM GCC front end?
+    </li>
+
   </ol>
   </li>
 
   <li><a href="#cfe_code">Questions about code generated by the GCC front-end</a>
   <ol>
-     <li>What is this <tt>__main()</tt> call that gets inserted into
-         <tt>main()</tt>?</li>
-     <li>Where did all of my code go??</li>
-     <li>What is this <tt>llvm.global_ctors</tt> and
+     <li><a href="#__main">What is this <tt>__main()</tt> call that gets inserted into
+         <tt>main()</tt>?</a></li>
+     <li><a href="#iosinit">What is this <tt>llvm.global_ctors</tt> and
           <tt>_GLOBAL__I__tmp_webcompile...</tt> stuff that happens when I
-          #include &lt;iostream&gt;?</li>
+          #include &lt;iostream&gt;?</a></li>
+     <li><a href="#codedce">Where did all of my code go??</a></li>
+     <li><a href="#undef">What is this "<tt>undef</tt>" thing that shows up in my code?</a></li>
   </ol>
   </li>
 </ol>
@@ -121,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.cs.uiuc.edu/releases/1.2/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">
@@ -166,10 +174,6 @@ LLVM have been ported to a plethora of platforms.</p>
   <li>The GCC front end code is not as portable as the LLVM suite, so it may not
   compile as well on unsupported platforms.</li>
 
-  <li>The Python test classes are more UNIX-centric than they should be, so
-  porting to non-UNIX like platforms (i.e. Windows, MacOS 9) will require some
-  effort.</li>
-
   <li>The LLVM build system relies heavily on UNIX shell tools, like the Bourne
   Shell and sed.  Porting to systems without these tools (MacOS 9, Plan 9) will
   require more effort.</li>
@@ -349,28 +353,34 @@ build.</p>
 </div>
 
 <div class="question">
-<p>
-When I use the test suite, all of the C Backend tests fail.  What is
-wrong?
-</p>
+<p>After CVS update, rebuilding gives the error "No rule to make target".</p>
 </div>
 
 <div class="answer">
-<p>
-If you build LLVM and the C Backend tests fail in <tt>llvm/test/Programs</tt>,
-then chances are good that the directory pointed to by the LLVM_LIB_SEARCH_PATH
-environment variable does not contain the libcrtend.a library.
-</p>
+<p>If the error is of the form:</p>
 
-<p>
-To fix it, verify that LLVM_LIB_SEARCH_PATH points to the correct directory
-and that libcrtend.a is inside.  For pre-built LLVM GCC front ends, this
-should be the absolute path to
-<tt>cfrontend/&lt;<i>platform</i>&gt;/llvm-gcc/bytecode-libs</tt>.  If you've
-built your own LLVM GCC front end, then ensure that you've built and installed
-the libraries in <tt>llvm/runtime</tt> and have LLVM_LIB_SEARCH_PATH pointing
-to the <tt>LLVMGCCDIR/bytecode-libs</tt> subdirectory.
-</p>
+<div class="doc_code">
+<tt>
+gmake[2]: *** No rule to make target `/path/to/somefile', needed by
+`/path/to/another/file.d'.<br>
+Stop.
+</tt>
+</div>
+
+<p>This may occur anytime files are moved within the CVS repository or removed
+entirely.  In this case, the best solution is to erase all <tt>.d</tt> files,
+which list dependencies for source files, and rebuild:</p>
+
+<div class="doc_code">
+<pre>
+% cd $LLVM_OBJ_DIR
+% rm -f `find . -name \*\.d` 
+% gmake 
+</pre>
+</div>
+
+<p>In other cases, it may be necessary to run <tt>make clean</tt> before
+rebuilding.</p>
 </div>
 
 <!-- *********************************************************************** -->
@@ -429,13 +439,27 @@ find libcrtend.a.
 
 <div class="answer">
 <p>
-In order to find libcrtend.a, you must have the directory in which it lives in
-your LLVM_LIB_SEARCH_PATH environment variable.  For the binary distribution of
-the LLVM GCC front end, this will be the full path of the bytecode-libs
-directory inside of the LLVM GCC distribution.
+The only way this can happen is if you haven't installed the runtime library. To
+correct this, do:</p>
+<pre>
+  % cd llvm/runtime
+  % make clean ; make install-bytecode
+</pre>
+</div>
+
+<div class="question">
+<p>
+How can I disable all optimizations when compiling code using the LLVM GCC front end?
 </p>
 </div>
 
+<div class="answer">
+<p>
+Passing "-Wa,-disable-opt -Wl,-disable-opt" will disable *all* cleanup and
+optimizations done at the llvm level, leaving you with the truly horrible
+code that you desire.
+</p>
+</div>
 
 <!-- *********************************************************************** -->
 <div class="doc_section">
@@ -443,6 +467,7 @@ directory inside of the LLVM GCC distribution.
 </div>
 
 <div class="question"><p>
+<a name="__main"></a>
 What is this <tt>__main()</tt> call that gets inserted into <tt>main()</tt>?
 </p></div>
 
@@ -464,7 +489,40 @@ linked in automatically when you link the program.
 
 <!--=========================================================================-->
 
+<div class="question">
+<a name="iosinit"></a>
+<p> What is this <tt>llvm.global_ctors</tt> and
+<tt>_GLOBAL__I__tmp_webcompile...</tt> stuff that happens when I #include
+&lt;iostream&gt;?</p>
+</div>
+
+<div class="answer">
+
+<p>If you #include the &lt;iostream&gt; header into a C++ translation unit, the
+file will probably use the <tt>std::cin</tt>/<tt>std::cout</tt>/... global
+objects.  However, C++ does not guarantee an order of initialization between
+static objects in different translation units, so if a static ctor/dtor in your
+.cpp file used <tt>std::cout</tt>, for example, the object would not necessarily
+be automatically initialized before your use.</p>
+
+<p>To make <tt>std::cout</tt> and friends work correctly in these scenarios, the
+STL that we use declares a static object that gets created in every translation
+unit that includes <tt>&lt;iostream&gt;</tt>.  This object has a static
+constructor and destructor that initializes and destroys the global iostream
+objects before they could possibly be used in the file.  The code that you see
+in the .ll file corresponds to the constructor and destructor registration code.
+</p>
+
+<p>If you would like to make it easier to <b>understand</b> the LLVM code
+generated by the compiler in the demo page, consider using <tt>printf()</tt>
+instead of <tt>iostream</tt>s to print values.</p>
+
+</div>
+
+<!--=========================================================================-->
+
 <div class="question"><p>
+<a name="codedce"></a>
 Where did all of my code go??
 </p></div>
 
@@ -487,32 +545,22 @@ you can read from and assign to <tt>volatile</tt> global variables.
 <!--=========================================================================-->
 
 <div class="question"><p>
-What is this <tt>llvm.global_ctors</tt> and <tt>_GLOBAL__I__tmp_webcompile...</tt> stuff that happens when I #include &lt;iostream&gt;?
+<a name="undef"></a>
+<p>What is this "<tt>undef</tt>" thing that shows up in my code?
 </p></div>
 
 <div class="answer">
 <p>
-If you #include the &lt;iostream&gt; header into a C++ translation unit, the
-file will probably use the <tt>std::cin</tt>/<tt>std::cout</tt>/... global
-objects.  However, C++ does not guarantee an order of initialization between
-static objects in different translation units, so if a static ctor/dtor in your
-.cpp file used <tt>std::cout</tt>, for example, the object would not necessarily
-be automatically initialized before your use.
-</p>
+<a href="LangRef.html#undef"><tt>undef</tt></a> is the LLVM way of representing
+a value that is not defined.  You can get these if you do not initialize a 
+variable before you use it.  For example, the C function:</p>
 
-<p>
-To make <tt>std::cout</tt> and friends work correctly in these scenarios, the
-STL that we use declares a static object that gets created in every translation
-unit that includes &lt;iostream&gt;.  This object has a static constructor and
-destructor that initializes and destroys the global iostream objects before they
-could possibly be used in the file.  The code that you see in the .ll file
-corresponds to the constructor and destructor registration code.
-</p>
+<div class="doc_code">
+  <tt>int X() { int i; return i; }</tt>
+</div>
 
-<p>
-If you would like to make it easier to <b>understand</b> the LLVM code generated
-by the compiler in the demo page, consider using printf instead of iostreams to
-print values.
+<p>Is compiled to "<tt>ret int undef</tt>" because "i" never has a value 
+specified for it.
 </p>
 </div>
 

llvm/docs/GettingStartedVS.html

@@ -0,0 +1,360 @@
+<!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>Getting Started with LLVM System for Microsoft Visual Studio</title>
+  <link rel="stylesheet" href="llvm.css" type="text/css">
+</head>
+<body>
+
+<div class="doc_title">
+  Getting Started with the LLVM System using Microsoft Visual Studio
+</div>
+
+<ul>
+  <li><a href="#overview">Overview</a>
+  <li><a href="#quickstart">Getting Started Quickly (A Summary)</a>
+  <li><a href="#requirements">Requirements</a>
+    <ol>
+      <li><a href="#hardware">Hardware</a>
+      <li><a href="#software">Software</a>
+    </ol></li>
+
+  <li><a href="#starting">Getting Started with LLVM</a>
+    <ol>
+      <li><a href="#terminology">Terminology and Notation</a>
+      <li><a href="#objfiles">The Location of LLVM Object Files</a>
+    </ol></li>
+
+  <li><a href="#tutorial">An Example Using the LLVM Tool Chain</a>
+  <li><a href="#problems">Common Problems</a>
+  <li><a href="#links">Links</a>
+</ul>
+
+<div class="doc_author">
+  <p>Written by: 
+    <a href="mailto:jeffc@jolt-lang.org">Jeff Cohen</a>
+  </p>
+</div>
+
+
+<!-- *********************************************************************** -->
+<div class="doc_section">
+  <a name="overview"><b>Overview</b></a>
+</div>
+<!-- *********************************************************************** -->
+
+<div class="doc_text">
+
+  <p>The Visual Studio port at this time is experimental.  It is suitable for
+  use only if you are writing your own compiler front end or otherwise have a
+  need to dynamically generate machine code.  The JIT and interpreter are
+  functional, but it is currently not possible to generate assembly code which
+  is then assembled into an executable.  You can indirectly create executables
+  by using the C back end.</p>
+
+  <p>To emphasize, there is no C/C++ front end currently available.
+  <tt>llvm-gcc</tt> is based on GCC, which cannot be bootstrapped using VC++.
+  Eventually there should be a <tt>llvm-gcc</tt> based on Cygwin or MinGW that
+  is usable.  There is also the option of generating bytecode files on Unix and
+  copying them over to Windows.  But be aware the odds of linking C++ code
+  compiled with <tt>llvm-gcc</tt> with code compiled with VC++ is essentially
+  zero.</p>
+
+  <p>The LLVM test suite cannot be run on the Visual Studio port at this
+  time.</p>
+
+  <p>Most of the tools build and work.  <tt>llvm-db</tt> does not build at this
+  time.  <tt>bugpoint</tt> does build, but does not work.
+
+  <p>Additional information about the LLVM directory structure and tool chain
+  can be found on the main <a href="GettingStarted.html">Getting Started</a>
+  page.</P>
+
+</div>
+
+<!-- *********************************************************************** -->
+<div class="doc_section">
+  <a name="quickstart"><b>Getting Started Quickly (A Summary)</b></a>
+</div>
+<!-- *********************************************************************** -->
+
+<div class="doc_text">
+
+<p>Here's the short story for getting up and running quickly with LLVM:</p>
+
+<ol>
+  <li>Read the documentation.</li>
+  <li>Read the documentation.</li>
+  <li>Remember that you were warned twice about reading the documentation.</li>
+
+  <li>Get the Source Code
+  <ul>
+    <li>With the distributed files:
+    <ol>
+      <li><tt>cd <i>where-you-want-llvm-to-live</i></tt>
+      <li><tt>gunzip --stdout llvm-<i>version</i>.tar.gz | tar -xvf -</tt>
+      <i>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;or use WinZip</i>
+      <li><tt>cd llvm</tt></li>
+    </ol></li>
+
+    <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
+          :pserver:anon@llvm-cvs.cs.uiuc.edu:/var/cvs/llvm login</tt></li>
+      <li>Hit the return key when prompted for the password.
+      <li><tt>cvs -z3 -d :pserver:anon@llvm-cvs.cs.uiuc.edu:/var/cvs/llvm 
+          co llvm</tt></li>
+      <li><tt>cd llvm</tt></li>
+      <li><tt>cvs up -P -d</tt></li>
+    </ol></li>
+  </ul></li>
+
+  <li>Start Visual Studio
+  <ol>
+    <li>Simply double click on the solution file <tt>llvm/win32/llvm.sln</tt>.
+    </li>
+  </ol></li>
+
+  <li>Build the LLVM Suite:
+  <ol>
+    <li>Simply build the solution.</li>
+    <li>The Fibonacci project is a sample program that uses the JIT.  Modify
+    the project's debugging properties to provide a numeric command line
+    argument.  The program will print the corresponding fibonacci value.</li>
+  </ol></li>
+
+</ol>
+
+<p>It is strongly encouraged that you get the latest version from CVS.  Much
+progress has been made since the 1.4 release.</p>
+
+</div>
+
+<!-- *********************************************************************** -->
+<div class="doc_section">
+  <a name="requirements"><b>Requirements</b></a>
+</div>
+<!-- *********************************************************************** -->
+
+<div class="doc_text">
+
+  <p>Before you begin to use the LLVM system, review the requirements given
+  below.  This may save you some trouble by knowing ahead of time what hardware
+  and software you will need.</p>
+
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+  <a name="hardware"><b>Hardware</b></a>
+</div>
+
+<div class="doc_text">
+
+  <p>Any system that can adequately run Visual Studio .NET 2003 is fine.  The
+  LLVM source tree and object files, libraries and executables will consume
+  approximately 3GB.</p>
+
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection"><a name="software"><b>Software</b></a></div>
+<div class="doc_text">
+
+  <p>You will need Visual Studio .NET 2003.  Earlier versions cannot open the
+  solution/project files.  The VS 2005 beta can, but will migrate these files
+  to its own format in the process.  While it should work with the VS 2005
+  beta, there are no guarantees and there is no support for it at this time.
+  It has been reported that VC++ Express also works.</p>
+
+  <p>You will also need several open source packages:  bison, flex, and sed.
+  These must be installed in <tt>llvm/win32/tools</tt>.  These can be found at
+  <a href="http://gnuwin32.sourceforge.net">http://gnuwin32.sourceforge.net</a>
+  or
+  <a href="http://unxutils.sourceforge.net">http://unxutils.sourceforge.net</a>.
+  Bison prefers that m4 be in the path.  You must add it to the Visual Studio
+  configuration under the menu Options -&gt; Projects -&gt; VC++ Directories.
+  Alternatively, you can set the environment variable <tt>M4</tt> to point to
+  <tt>m4</tt> executable.</p>
+
+</div>
+
+<!-- *********************************************************************** -->
+<div class="doc_section">
+  <a name="starting"><b>Getting Started with LLVM</b></a>
+</div>
+<!-- *********************************************************************** -->
+
+<div class="doc_text">
+
+<p>The remainder of this guide is meant to get you up and running with
+LLVM using Visual Studio and to give you some basic information about the LLVM
+environment.</p>
+
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+  <a name="terminology">Terminology and Notation</a>
+</div>
+
+<div class="doc_text">
+
+<p>Throughout this manual, the following names are used to denote paths
+specific to the local system and working environment.  <i>These are not
+environment variables you need to set but just strings used in the rest
+of this document below</i>.  In any of the examples below, simply replace
+each of these names with the appropriate pathname on your local system.
+All these paths are absolute:</p>
+
+<dl>
+    <dt>SRC_ROOT
+    <dd>
+    This is the top level directory of the LLVM source tree.
+    <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
+    is fixed at SRC_ROOT/win32).
+    <p>
+</dl>
+
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+  <a name="objfiles">The Location of LLVM Object Files</a>
+</div>
+
+<div class="doc_text">
+
+  <p>The object files are placed under <tt>OBJ_ROOT/Debug</tt> for debug builds
+  and <tt>OBJ_ROOT/Release</tt> for release (optimized) builds.  These include
+  both executables and libararies that your application can link against.
+
+  <p>The files that <tt>configure</tt> would create when building on Unix are
+  created by the <tt>Configure</tt> project and placed in
+  <tt>OBJ_ROOT/llvm</tt>.  You application must have OBJ_ROOT in its include
+  search path just before <tt>SRC_ROOT/include</tt>.
+
+</div>
+
+<!-- *********************************************************************** -->
+<div class="doc_section">
+  <a name="tutorial">An Example Using the LLVM Tool Chain</a>
+</div>
+<!-- *********************************************************************** -->
+
+<div class="doc_text">
+
+<ol>
+  <li>First, create a simple C file, name it 'hello.c':
+       <pre>
+   #include &lt;stdio.h&gt;
+   int main() {
+     printf("hello world\n");
+     return 0;
+   }
+       </pre></li>
+
+  <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 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.</b></p></li>
+
+  <li><p>Run the program. To make sure the program ran, execute the
+      following command:</p>
+      
+      <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><p></li>
+
+  <li><p>Compile the program to native assembly using the LLC code
+      generator:</p>
+
+      <p><tt>% llc hello.bc -o hello.s</tt></p>
+
+  <li><p>Assemble the native assembly language file into a program:</p>
+
+  <p><b>Not currently possible, but eventually will use <tt>NASMW</tt>.</b></p>
+
+  <li><p>Execute the native code program:</p>
+
+      <p><tt>% ./hello.native</tt></p></li>
+
+</ol>
+
+</div>
+
+<!-- *********************************************************************** -->
+<div class="doc_section">
+  <a name="problems">Common Problems</a>
+</div>
+<!-- *********************************************************************** -->
+
+<div class="doc_text">
+
+<p>If you are having problems building or using LLVM, or if you have any other
+general questions about LLVM, please consult the <a href="FAQ.html">Frequently
+Asked Questions</a> page.</p>
+
+</div>
+
+<!-- *********************************************************************** -->
+<div class="doc_section">
+  <a name="links">Links</a>
+</div>
+<!-- *********************************************************************** -->
+
+<div class="doc_text">
+
+<p>This document is just an <b>introduction</b> to how to use LLVM to do
+some simple things... there are many more interesting and complicated things
+that you can do that aren't documented here (but we'll gladly accept a patch
+if you want to write something up!).  For more information about LLVM, check
+out:</p>
+
+<ul>
+  <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>
+
+</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:jeffc@jolt-lang.org">Jeff Cohen</a><br>
+  <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a><br>
+  Last modified: $Date$
+</address>
+</body>
+</html>

llvm/docs/HowToSubmitABug.html

@@ -11,10 +11,9 @@
   How to submit an LLVM bug report
 </div>
 
-<table border="0" width="100%">
-<tr>
-<td valign="top">
-
+<table class="layout" style="width: 90%" >
+<tr class="layout">
+  <td class="left">
 <ol>
   <li><a href="#introduction">Introduction - Got bugs?</a></li>
   <li><a href="#crashers">Crashing Bugs</a>
@@ -26,16 +25,13 @@
     </ul></li>
   <li><a href="#miscompilations">Miscompilations</a></li>
   <li><a href="#codegen">Incorrect code generation (JIT and LLC)</a></li>
-
 </ol>
-
 <div class="doc_author">
   <p>Written by <a href="mailto:sabre@nondot.org">Chris Lattner</a> and
                 <a href="http://misha.brukman.net">Misha Brukman</a></p>
 </div>
-
 </td>
-<td align="right">
+<td class="right">
   <img src="img/Debugging.gif" alt="Debugging" width="444" height="314">
 </td>
 </tr>

llvm/docs/Lexicon.html

@@ -0,0 +1,172 @@
+<!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 LLVM Lexicon</title>
+  <link rel="stylesheet" href="llvm.css" type="text/css">
+  <meta name="author" content="Various">
+  <meta name="description" 
+  content="A glossary of terms used with the LLVM project.">
+</head>
+<body>
+<div class="doc_title">The LLVM Lexicon</div>
+<p class="doc_warning">NOTE: This document is a work in progress!</p>
+<!-- *********************************************************************** -->
+<div class="doc_section">Table Of Contents</div>
+<!-- *********************************************************************** -->
+<div class="doc_text">
+  <table>
+    <tr><th colspan="8"><b>- <a href="#A">A</a> -</b></th></tr>
+    <tr>
+      <td><a href="#ADCE">ADCE</a></td>
+    </tr>
+    <tr><th colspan="8"><b>- <a href="#B">B</a> -</b></th></tr>
+    <tr>
+      <td><a href="#BURS">BURS</a></td>
+    </tr>
+    <tr><th colspan="8"><b>- <a href="#C">C</a> -</b></th></tr>
+    <tr>
+      <td><a href="#CSE">CSE</a></td>
+    </tr>
+    <tr><th colspan="8"><b>- <a href="#D">D</a> -</b></th></tr>
+    <tr>
+      <td><a href="#DSA">DSA</a></td>
+      <td><a href="#DSE">DSE</a></td>
+    </tr>
+    <tr><th colspan="8"><b>- <a href="#I">I</a> -</b></th></tr>
+    <tr>
+      <td><a href="#IPA">IPA</a></td>
+      <td><a href="#IPO">IPO</a></td>
+    </tr>
+    <tr><th colspan="8"><b>- <a href="#L">L</a> -</b></th></tr>
+    <tr>
+      <td><a href="#LICM">LICM</a></td>
+      <td><a href="#Load-VN">Load-VN</a></td>
+    </tr>
+    <tr><th colspan="8"><b>- <a href="#P">P</a> -</b></th></tr>
+    <tr>
+      <td><a href="#PRE">PRE</a></td>
+    </tr>
+    <tr><th colspan="8"><b>- <a href="#R">R</a> -</b></th></tr>
+    <tr>
+      <td><a href="#Reassociation">Reassociation</a></td>
+    </tr>
+    <tr><th colspan="8"><b>- <a href="#S">S</a> -</b></th></tr>
+    <tr>
+      <td><a href="#SCCP">SCCP</a></td>
+      <td><a href="#SSA">SSA</a></td>
+    </tr>
+  </table>
+</div>
+
+<!-- *********************************************************************** -->
+<div class="doc_section">Definitions</div>
+<!-- *********************************************************************** -->
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"><a name="A">- A -</a></div>
+<div class="doc_text">
+  <dl>
+    <dt><a name="ADCE"><b>ADCE</b></a></dt>
+    <dd>Aggressive Dead Code Elimination</dd>
+  </dl>
+</div>
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"><a name="B">- B -</a></div>
+<div class="doc_text">
+  <dl>
+    <dt><a name="BURS"><b>BURS</b></a></dt>
+    <dd>Bottom Up Rewriting System - A method of instruction selection for
+        code generation.  An example is the <a 
+href="http://www.program-transformation.org/Transform/BURG">BURG</a> tool.</dd>
+  </dl>
+</div>
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"><a name="C">- C -</a></div>
+<div class="doc_text">
+  <dl>
+    <dt><a name="CSE"><b>CSE</b></a></dt>
+    <dd>Common Subexpression Elimination. An optimization that removes common
+    subexpression compuation. For example <tt>(a+b)*(a+b)</tt> has two
+    subexpressions that are the same: <tt>(a+b)</tt>. This optimization would
+    perform the addition only once and then perform the multiply (but only if
+    its compulationally correct/safe).
+  </dl>
+</div>
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"><a name="D">- D -</a></div>
+<div class="doc_text">
+  <dl>
+    <dt><a name="DSA"><b>DSA</b></a></dt>
+    <dd>Data Structure Analysis</dd>
+    <dt><a name="DSE"><b>DSE</b></a></dt>
+    <dd>Dead Store Elimination</dd>
+  </dl>
+</div>
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"><a name="I">- I -</a></div>
+<div class="doc_text">
+  <dl>
+    <dt><a name="IPA"><b>IPA</b></a></dt>
+    <dd>Inter-Procedural Analysis. Refers to any variety of code analysis that
+    occurs between procedures, functions or compilation units (modules).</dd>
+    <dt><a name="IPO"><b>IPO</b></a></dt>
+    <dd>Inter-Procedural Optimization. Refers to any variety of code
+    optimization that occurs between procedures, functions or compilation units
+    (modules).</dd>
+  </dl>
+</div>
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"><a name="L">- L -</a></div>
+<div class="doc_text">
+  <dl>
+    <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>
+    <dd>Load Value Numbering</dd>
+  </dl>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"><a name="P">- P -</a></div>
+<div class="doc_text">
+  <dl>
+    <dt><a name="PRE"><b>PRE</b></a></dt>
+    <dd>Partial Redundancy Elimination</dd>
+  </dl>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"><a name="R">- R -</a></div>
+<div class="doc_text">
+  <dl>
+    <dt><a name="Reassociation"><b>Reassociation</b></a></dt> <dd>Rearranging
+    associative expressions to promote better redundancy elimination and other
+    optimization.  For example, changing (A+B-A) into (B+A-A), permitting it to
+    be optimized into (B+0) then (B).
+  </dl>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"><a name="S">- S -</a></div>
+<div class="doc_text">
+  <dl>
+    <dt><a name="SCCP"><b>SCCP</b></a></dt>
+    <dd>Sparse Conditional Constant Propagation
+    <dt><a name="SSA"><b>SSA</b></a></dt>
+    <dd>Static Single Assignment</dd>
+  </dl>
+</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.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
+-->
+</body>
+</html>

llvm/docs/Makefile

@@ -6,9 +6,61 @@
 # the University of Illinois Open Source License. See LICENSE.TXT for details.
 # 
 ##===----------------------------------------------------------------------===##
-doxygen-files:
-	doxygen doxygen.cfg
 
-doxygen.tar.gz: doxygen/index.html
-	rm -rf $@
-	gtar czvf $@ doxygen
+LEVEL      := ..
+DIRS       := CommandGuide
+
+include $(LEVEL)/Makefile.common
+
+HTML       := $(wildcard $(PROJ_SRC_DIR)/*.html) \
+              $(wildcard $(PROJ_SRC_DIR)/*.css)
+IMAGES     := $(wildcard $(PROJ_SRC_DIR)/img/*.*)
+DOXYFILES  := doxygen.cfg.in doxygen.css doxygen.footer doxygen.header \
+              doxygen.intro
+EXTRA_DIST := $(HTML) $(DOXYFILES) llvm.css CommandGuide img
+
+.PHONY: install-html install-doxygen doxygen
+
+ifeq ($(ENABLE_DOXYGEN),1)
+install-local:: install-html install-doxygen
+else
+install-local:: install-html
+endif
+
+install-html: $(PROJ_OBJ_DIR)/html.tar.gz
+	$(Echo) Installing HTML documentation
+	$(Verb) $(MKDIR) $(PROJ_docsdir)/html
+	$(Verb) $(MKDIR) $(PROJ_docsdir)/html/img
+	$(Verb) $(DataInstall) $(HTML) $(PROJ_docsdir)/html
+	$(Verb) $(DataInstall) $(IMAGES) $(PROJ_docsdir)/html/img
+	$(Verb) $(DataInstall) $(PROJ_OBJ_DIR)/html.tar.gz $(PROJ_docsdir)
+
+$(PROJ_OBJ_DIR)/html.tar.gz: $(HTML)
+	$(Echo) Packaging HTML documentation
+	$(Verb) $(RM) -rf $@ $(PROJ_OBJ_DIR)/html.tar
+	$(Verb) cd $(PROJ_SRC_DIR) && \
+	  $(TAR) cf $(PROJ_OBJ_DIR)/html.tar *.html
+	$(Verb) $(GZIP) $(PROJ_OBJ_DIR)/html.tar
+
+install-doxygen: doxygen
+	$(Echo) Installing doxygen documentation
+	$(Echo) Installing doxygen documentation
+	$(Verb) $(MKDIR) $(PROJ_docsdir)/html/doxygen
+	$(Verb) $(DataInstall) $(PROJ_OBJ_DIR)/doxygen.tar.gz $(PROJ_docsdir)
+	$(Verb) cd $(PROJ_OBJ_DIR)/doxygen && \
+	  $(FIND) . -type f -exec \
+	    $(DataInstall) {} $(PROJ_docsdir)/html/doxygen \;
+
+doxygen: $(PROJ_OBJ_DIR)/doxygen.tar.gz
+
+$(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
+	$(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
+

llvm/docs/ObjectFiles.html

@@ -1,300 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
-<html>
-<head>
-	<title>Object Files: Understanding The Result Of LLVM Compilation</title>
-  <link rel="stylesheet" href="llvm.css" type="text/css">
-</head>
-<body>
-<div class="doc_title">Object Files: Understanding The Result Of LLVM Compilation</div>
-<hr>
-<ol>
-  <li><a href="#abstract">Abstract</a></li>
-  <li><a href="#introduction">Introduction</a></li>
-  <li><a href="#files">File Contents</a></li>
-  <li><a href="#rot">Linkage Rules Of Thumb</a>
-	  <ol>
-			<li><a href="#always">Always Link vmcore.o, support.a</a>
-			<li><a href="#placeholder">Placeholder</a>
-		</ol>
-	</li>
-</ol>
-
-<div class="doc_author">
-  <p>Written by <a href="mailto:rspencer@x10sys.com">Reid Spencer</a></p>
-</div>
-
-<hr>
-
-<!-- ======================================================================= -->
-<div class="doc_section"><a name="abstract">Abstract</a></div>
-<div class="doc_text">
-<p>This document describes the contents of the many objects files and libraries
-that are produced by compiling LLVM. To make use of LLVM this information is 
-needed in order to understand what files should be linked into your program.
-</p>
-</div>
-<!-- ======================================================================= -->
-<div class="doc_section"> <a name="introduction">Introduction</a></div>
-<div class="doc_text">
-<p>If you're writing a compiler, virtual machine, or any other utility for
-	 LLVM, you'll need to figure out which of the many .a (archive) and .o
-	 (object) files you will need to link with to be successful. An
-	 understanding of the contents of these files and their inter-relationships
-	 will be useful in coming up with an optimal specification for the objects
-	 and libraries to link with. 
-</p>
-<p>The purpose of this document is to hopefully reduce some of the trial and
-   error that the author experienced in using LLVM.
-</p>
-</div>
-<!-- ======================================================================= -->
-<div class="doc_section"><a name="files"></a>File Contents</div>
-<div class="doc_text">
-<p>The table below provides a summary of the basic contents of each file.</p>
-<table class="doc_table" 
-	style="width:80%; text-align: left; border: 2px solid blue; border-collapse: collapse;">
-<tr class="doc_table">
-	<td colspan="2" class="doc_section">Summary Of LLVM Library And Object Files
-	</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue"><h2><u>Library</u></h2></td>
-	<td style="border: 2px solid blue"><h2><u>Description</u></h2></td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">libipo.a</td>
-	<td style="border: 2px solid blue">
-		An archive of all inter-procedural optimizations.
-	</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">libscalaropts.a</td>
-	<td style="border: 2px solid blue">
-		An archive of all scalar optimizations.
-	</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">libtransforms.a</td>
-	<td style="border: 2px solid blue">
-		An archive of just the level raise pass.
-	</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">libtarget.a</td>
-	<td style="border: 2px solid blue">
-		An archive containing code generator support for describing
-		target architectures.
-	</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">libanalysis.a</td>
-	<td style="border: 2px solid blue">
-		An archive containing intra-procedural analyses.
-	</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">libdatastructure.a</td>
-	<td style="border: 2px solid blue">
-		An archive containing optimizations for data structures.
-	</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">libinstrument.a</td>
-	<td style="border: 2px solid blue">No idea.</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">libregalloc.a</td>
-	<td style="border: 2px solid blue">Register Allocation code.</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">libipa.a</td>
-	<td style="border: 2px solid blue">
-		An archive containing inter-procedural analyses</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">libtransformutils.a</td>
-	<td style="border: 2px solid blue">
-		Utiltities for transformations?
-	</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">libsupport.a</td>
-	<td style="border: 2px solid blue">General support utilities</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">libevar.a</td>
-	<td style="border: 2px solid blue">Live variable analysis for SPARC</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue"><h2><u>Object File</u></h2></td>
-	<td style="border: 2px solid blue"><h2><u>Description</u></h2></td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">support.o</td>
-	<td style="border: 2px solid blue">General support utilities</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">asmparser.o</td>
-	<td style="border: 2px solid blue">Assembler Parser</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">bcreader.o</td>
-	<td style="border: 2px solid blue">Byte Code Reader</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">bcwriter.o</td>
-	<td style="border: 2px solid blue">Byte Code Writer</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">sched.o</td>
-	<td style="border: 2px solid blue">SPARC instruction scheduler</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">selectiondag.o</td>
-	<td style="border: 2px solid blue">Aggressive instruction selector for Directed Acyclic Graphs</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">transformutils.o</td>
-	<td style="border: 2px solid blue">Utilities for code transformations</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">ipa.o</td>
-	<td style="border: 2px solid blue">Inter-Procedural Analysis Optimizations</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">select.o</td>
-	<td style="border: 2px solid blue">SPARC instruction selector</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">cwriter.o</td>
-	<td style="border: 2px solid blue">"C" Code Writer</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">profpaths.o</td>
-	<td style="border: 2px solid blue">Path profiling instrumentation</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">regalloc.o</td>
-	<td style="border: 2px solid blue">Register Allocation</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">instrument.o</td>
-	<td style="border: 2px solid blue">Instrumentation? Of What?</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">datastructure.o</td>
-	<td style="border: 2px solid blue">Data Structure Analysis</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">codegen.o</td>
-	<td style="border: 2px solid blue">Native code generation</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">livevar.o</td>
-	<td style="border: 2px solid blue">Live Variable Analysis</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">vmcore.o</td>
-	<td style="border: 2px solid blue">Virtual Machine Core</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">lli-interpreter.o</td>
-	<td style="border: 2px solid blue">Interpreter for LLVM ByteCode</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">lli-jit.o</td>
-	<td style="border: 2px solid blue">
-		Just-In-Time Compiler For LLVM ByteCode
-	</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">executionengine.o</td>
-	<td style="border: 2px solid blue">Engine for LLI</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">debugger.o</td>
-	<td style="border: 2px solid blue">Source Level Debugging Support</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">analysis.o</td>
-	<td style="border: 2px solid blue">General Framework For Analysis?</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">sparc.o</td>
-	<td style="border: 2px solid blue">Sun SPARC Processor Specific</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">target.o</td>
-	<td style="border: 2px solid blue">Target Machine Support?</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">transforms.o</td>
-	<td style="border: 2px solid blue">Code Transformations</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">x86.o</td>
-	<td style="border: 2px solid blue">Intel x86 Processor Specific</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">powerpc.o</td>
-	<td style="border: 2px solid blue">PowerPC Processor Specific</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">scalaropts.o</td>
-	<td style="border: 2px solid blue">Optimizations For Scalars</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">ipo.o</td>
-	<td style="border: 2px solid blue">Inter-Procedural Optimization</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">trace.o</td>
-	<td style="border: 2px solid blue">Support For Tracing/Debugging?</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">profile_rt.o</td>
-	<td style="border: 2px solid blue">Runtime Library For Profiler</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">sample.o</td>
-	<td style="border: 2px solid blue">Sample Program ?</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">stkr_compiler.o</td>
-	<td style="border: 2px solid blue">Stacker Language Compiler Library</td>
-</tr>
-<tr class="doc_table">
-	<td style="border: 2px solid blue">stkr_runtime.o</td>
-	<td style="border: 2px solid blue">Stacker Language Runtime Library</td>
-</tr>
-</table>
-</div>
-<p></p>
-<!-- ======================================================================= -->
-<div class="doc_section"><a name="rot">Linkage Rules Of Thumb</a></div>
-<div class="doc_text">
-	<p>This section contains various "rules of thumb" about what files you
-	should link into your programs.</p>
-</div>
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="always">Always Link vmcore.o support.a</a>
-</div>
-<div class="doc_text">
-	<p>No matter what you do with LLVM, you'll always need to link with vmcore.o 
-	and support.a.</p>
-</div>
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="Placeholder">Placeholder</a></div>
-<div class="doc_text">
-	<p>Need more rules of thumb here.</p>
-</div>
-<!-- ======================================================================= -->
-<hr>
-<div class="doc_footer">
-<address><a href="mailto:rspencer@x10sys.com">Reid Spencer</a></address>
-<a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a> 
-<br>Last modified: $Date$ </div>
-</body>
-</html>
-<!-- vim: sw=2 ts=2 ai
--->

llvm/docs/OpenProjects.html

@@ -1,360 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
-                      "http://www.w3.org/TR/html4/strict.dtd">
-<html>
-<head>
-  <title>Open LLVM Projects</title>
-  <link rel="stylesheet" href="llvm.css" type="text/css">
-</head>
-<body>
-
-<div class="doc_title">
-  Open LLVM Projects
-</div>
-
-<ul>
-  <li><a href="#what">What is this?</a></li>
-  <li><a href="#improving">Improving the current system</a>
-  <ol>
-    <li><a href="#code-cleanups">Implementing Code Cleanup bugs</a></li>
-    <li><a href="#glibc">Port glibc to LLVM</a></li>
-    <li><a href="#programs">Compile programs with the LLVM Compiler</a></li>
-    <li><a href="#llvm_ir">Extend the LLVM intermediate representation</a></li>
-    <li><a href="#misc_imp">Miscellaneous Improvements</a></li>
-  </ol></li>
-
-  <li><a href="#new">Adding new capabilities to LLVM</a>
-  <ol>
-    <li><a href="#newfeaturebugs">Implementing new feature PRs</a></li>
-    <li><a href="#pointeranalysis">Pointer and Alias Analysis</a></li>
-    <li><a href="#profileguided">Profile Guided Optimization</a></li>
-    <li><a href="#xforms">New Transformations and Analyses</a></li>
-    <li><a href="#x86be">X86 Back-end Improvements</a></li>
-    <li><a href="#misc_new">Miscellaneous Additions</a></li>
-  </ol></li>
-</ul>
-
-<div class="doc_author">
-  <p>Written by the <a href="http://llvm.cs.uiuc.edu/">LLVM Team</a></p>
-</div>
-
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
-  <a name="what">What is this?</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>This document is meant to be a sort of "big TODO list" for LLVM.  Each
-project in this document is something that would be useful for LLVM to have, and
-would also be a great way to get familiar with the system.  Some of these
-projects are small and self-contained, which may be implemented in a couple of
-days, others are larger.  Several of these projects may lead to interesting
-research projects in their own right.  In any case, we welcome all
-contributions.</p>
-
-<p>If you are thinking about tackling one of these projects, please send a mail
-to the <a href="http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVM
-Developer's</a> mailing list, so that we know the project is being worked on.
-Additionally this is a good way to get more information about a specific project
-or to suggest other projects to add to this page.
-</p>
-
-<p>The projects in this page are open-ended. More specific projects are
-filed as unassigned enhancements in the <a href="http://llvm.cs.uiuc.edu/bugs/">
-LLVM bug tracker</a>. See the <a href="http://llvm.cs.uiuc.edu/bugs/buglist.cgi?keywords_type=allwords&amp;keywords=&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;bug_severity=enhancement&amp;emailassigned_to1=1&amp;emailtype1=substring&amp;email1=unassigned">list of currently outstanding issues</a> if you wish to help improve LLVM.</p>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
-  <a name="improving">Improving the current system</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>Improvements to the current infrastructure are always very welcome and tend
-to be fairly straight-forward to implement.  Here are some of the key areas that
-can use improvement...</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="code-cleanups">Implementing Code Cleanup bugs</a>
-</div>
-
-<div class="doc_text">
-
-<p>
-The <a href="http://llvm.cs.uiuc.edu/bugs/">LLVM bug tracker</a> occasionally
-has <a href="http://llvm.cs.uiuc.edu/bugs/buglist.cgi?short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=code-cleanup&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Bug+Number&field0-0-0=noop&type0-0-0=noop&value0-0-0=">"code-cleanup" bugs</a> filed in it.  Taking one of these and fixing it is a good
-way to get your feet wet in the LLVM code and discover how some of its components
-work.
-</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="glibc">Port glibc to LLVM</a>
-</div>
-
-<div class="doc_text">
-
-<p>It would be very useful to <a
-href="http://www.gnu.org/software/libc/manual/html_node/Porting.html">port</a> <a
-href="http://www.gnu.org/software/libc/">glibc</a> to LLVM.  This would allow a
-variety of interprocedural algorithms to be much more effective in the face of
-library calls.  The most important pieces to port are things like the string
-library and the <tt>stdio</tt> related functions... low-level system calls like
-'<tt>read</tt>' should stay unimplemented in LLVM.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="programs">Compile programs with the LLVM Compiler</a>
-</div>
-
-<div class="doc_text">
-
-<p>We are always looking for new testcases and benchmarks for use with LLVM.  In
-particular, it is useful to try compiling your favorite C source code with LLVM.
-If it doesn't compile, try to figure out why or report it to the <a
-href="http://mail.cs.uiuc.edu/pipermail/llvmbugs/">llvm-bugs</a> list.  If you
-get the program to compile, it would be extremely useful to convert the build
-system to be compatible with the LLVM Programs testsuite so that we can check it
-into CVS and the automated tester can use it to track progress of the
-compiler.</p>
-
-<p>When testing a code, try running it with a variety of optimizations, and with
-all the back-ends: CBE, llc, and lli.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="llvm_ir">Extend the LLVM intermediate representation</a>
-</div>
-
-<div class="doc_text">
-
-<ol>
-<li>Add support for platform-independent prefetch support.  The GCC <a
-    href="http://gcc.gnu.org/projects/prefetch.html">prefetch project</a> page
-    has a good survey of the prefetching capabilities of a variety of modern
-    processors.</li>
-
-</ol>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="misc_imp">Miscellaneous Improvements</a>
-</div>
-
-<div class="doc_text">
-
-<ol>
-<li>Someone needs to look into getting the <tt>ranlib</tt> tool to index LLVM
-    bytecode files, so that linking in .a files is not hideously slow.  They
-    would also then have to implement the reader for this index in
-    <tt>gccld</tt>.</li>
-
-<li>Rework the PassManager to be more flexible</li>
-
-<li>Some transformations and analyses only work on reducible flow graphs.  It
-would be nice to have a transformation which could be "required" by these passes
-which makes irreducible graphs reducible.  This can easily be accomplished
-through code duplication.  See <a
-href="http://citeseer.nj.nec.com/janssen97making.html">Making Graphs Reducible
-with Controlled Node Splitting</a> and perhaps <a
-href="http://doi.acm.org/10.1145/262004.262005">Nesting of Reducible and
-Irreducible Loops</a>.</li>
-
-</ol>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
-  <a name="new">Adding new capabilities to LLVM</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>Sometimes creating new things is more fun than improving existing things.
-These projects tend to be more involved and perhaps require more work, but can
-also be very rewarding.</p>
-
-</div>
-
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="newfeaturebugs">Implementing new feature PRs</a>
-</div>
-
-<div class="doc_text">
-
-<p>Many ideas for feature requests are stored in LLVM bugzilla.  Just <a href="http://llvm.org/bugs/buglist.cgi?short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=new-feature&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&namedcmd=All+PRs&newqueryname=&order=Bug+Number&field0-0-0=noop&type0-0-0=noop&value0-0-0=">search for bugs with a "new-feature" keyword</a>.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="pointeranalysis">Pointer and Alias Analysis</a>
-</div>
-
-<div class="doc_text">
-
-<p>We have a <a href="AliasAnalysis.html">strong base for development</a> of
-both pointer analysis based optimizations as well as pointer analyses
-themselves.  It seems natural to want to take advantage of this...</p>
-
-<ol>
-<li>Implement a flow-sensitive context-sensitive alias analysis algorithm<br>
-  - Pick one of the somewhat efficient algorithms, but strive for maximum
-    precision</li>
-
-<li>Implement a flow-sensitive context-insensitive alias analysis algorithm<br>
-  - Just an efficient local algorithm perhaps?</li>
-
-<li>Implement alias-analysis-based optimizations:
-  <ul>
-  <li>Dead store elimination</li>
-  <li>...</li>
-  </ul></li>
-</ol>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="profileguided">Profile Guided Optimization</a>
-</div>
-
-<div class="doc_text">
-
-<p>We now have a unified infrastructure for writing profile-guided
-transformations, which will work either at offline-compile-time or in the JIT,
-but we don't have many transformations.  We would welcome new profile-guided
-transformations as well as improvements to the current profiling system.
-</p>
-
-<p>Ideas for profile guided transformations:</p>
-
-<ol>
-<li>Superblock formation (with many optimizations)</li>
-<li>Loop unrolling/peeling</li>
-<li>Profile directed inlining</li>
-<li>Code layout</li>
-<li>...</li>
-</ol>
-
-<p>Improvements to the existing support:</p>
-
-<ol>
-<li>The current block and edge profiling code that gets inserted is very simple
-and inefficient.  Through the use of control-dependence information, many fewer
-counters could be inserted into the code.  Also, if the execution count of a
-loop is known to be a compile-time or runtime constant, all of the counters in
-the loop could be avoided.</li>
-
-<li>You could implement one of the "static profiling" algorithms which analyze a
-piece of code an make educated guesses about the relative execution frequencies
-of various parts of the code.</li>
-
-<li>You could add path profiling support, or adapt the existing LLVM path
-profiling code to work with the generic profiling interfaces.</li>
-</ol>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="xforms">New Transformations and Analyses</a>
-</div>
-
-<div class="doc_text">
-
-<ol>
-<li>Implement a Dependence Analysis Infrastructure<br>
-     - Design some way to represent and query dep analysis</li>
-<li>Implement a strength reduction pass</li>
-<li>Value range propagation pass</li>
-</ol>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_section">
-  <a name="x86be">X86 Back-end Improvements</a>
-</div>
-
-<div class="doc_text">
-
-<ol>
-<li>Implement a better instruction selector</li>
-<li>Implement support for the "switch" instruction without requiring the 
-    lower-switches pass.</li>
-<li>Implement interprocedural register allocation. The CallGraphSCCPass can be
-    used to implement a bottom-up analysis that will determine the *actual* 
-    registers clobbered by a function. Use the pass to fine tune register usage 
-    in callers based on *actual* registers used by the callee.</li>
-</ol>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_section">
-  <a name="misc_new">Miscellaneous Additions</a>
-</div>
-
-<div class="doc_text">
-
-<ol>
-<li>Port the <a href="http://www-sop.inria.fr/mimosa/fp/Bigloo/">Bigloo</A>
-Scheme compiler, from Manuel Serrano at INRIA Sophia-Antipolis, to
-output LLVM bytecode. It seems that it can already output .NET
-bytecode, JVM bytecode, and C, so LLVM would ostensibly be another good
-candidate.</li>
-<li>Write a new frontend for C/C++ <b>in</b> C++, giving us the ability to
-directly use LLVM C++ classes from within a compiler rather than use
-C-based wrapper functions a la llvm-gcc.  One possible starting point is the <a
-href="http://www.parashift.com/c++-faq-lite/compiler-dependencies.html#faq-37.11">C++
-yacc grammar by Ed Willink</a>.</li>
-<li>Write a new frontend for some other language (Java? OCaml? Forth?)</li>
-<li>Write a new backend for a target (IA64? MIPS? MMIX?)</li>
-<li>Write a disassembler for machine code that would use TableGen to output 
-<tt>MachineInstr</tt>s for transformations, optimizations, etc.</li>
-<li>Random test vector generator: Use a C grammar to generate random C code;
-run it through llvm-gcc, then run a random set of passes on it using opt.
-Try to crash opt. When opt crashes, use bugpoint to reduce the test case and
-mail the result to yourself.  Repeat ad infinitum.</li>
-<li>Design a simple, recognizable logo.</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="mailto:sabre@nondot.org">Chris Lattner</a><br>
-  <a href="http://llvm.cs.uiuc.edu">LLVM Compiler Infrastructure</a><br>
-  Last modified: $Date$
-</address>
-
-</body>
-</html>

llvm/docs/Projects.html

@@ -40,37 +40,32 @@ projects that use LLVM header files, libraries, and tools.  In order to use
 these facilities, a Makefile from a project must do the following things:</p>
 
 <ol>
-<li>Set environment variables.There are several environment variables that a
-Makefile needs to set to use the LLVM build system:
-
-<ul>
-  <li><tt>LLVM_SRC_ROOT</tt> - The root of the LLVM source tree.</li>
-  <li><tt>LLVM_OBJ_ROOT</tt> - The root of the LLVM object tree.</li>
-  <li><tt>BUILD_SRC_ROOT</tt> - The root of the project's source tree.</li>
-  <li><tt>BUILD_OBJ_ROOT</tt> - The root of the project's object tree.</li>
-  <li><tt>BUILD_SRC_DIR</tt> - The directory containing the current source to be
-  compiled.</li>
-  <li><tt>BUILD_OBJ_DIR</tt> - The directory where the current source will place
-  the new object files.  This should always be the current directory.</li>
-  <li><tt>LEVEL</tt> - The relative path from the current directory to the root
-  of the object tree.</li>
-</ul></li>
-<li>Include <tt>Makefile.config</tt> from <tt>$(LLVM_OBJ_ROOT)</tt>.</li>
-<li>Include <tt>Makefile.rules</tt> from <tt>$(LLVM_SRC_ROOT)</tt>.</li>
+  <li>Set <tt>make</tt> variables. There are several variables that a Makefile
+  needs to set to use the LLVM build system:
+  <ul>
+    <li><tt>PROJECT_NAME</tt> - The name by which your project is known.</li>
+    <li><tt>LLVM_SRC_ROOT</tt> - The root of the LLVM source tree.</li>
+    <li><tt>LLVM_OBJ_ROOT</tt> - The root of the LLVM object tree.</li>
+    <li><tt>PROJ_SRC_ROOT</tt> - The root of the project's source tree.</li>
+    <li><tt>PROJ_OBJ_ROOT</tt> - The root of the project's object tree.</li>
+    <li><tt>PROJ_INSTALL_ROOT</tt> - The root installation directory.</li>
+    <li><tt>LEVEL</tt> - The relative path from the current directory to the 
+    project's root ($PROJ_OBJ_ROOT).</li>
+  </ul></li>
+  <li>Include <tt>Makefile.config</tt> from <tt>$(LLVM_OBJ_ROOT)</tt>.</li>
+  <li>Include <tt>Makefile.rules</tt> from <tt>$(LLVM_SRC_ROOT)</tt>.</li>
 </ol>
 
 <p>There are two ways that you can set all of these variables:</p>
-
 <ol>
-<li>You can write your own Makefiles which hard-code these values.</li>
-
-<li> You can use the pre-made LLVM sample project.  This sample project includes
-Makefiles, a configure script that can be used to configure the location of
-LLVM, and the ability to support multiple object directories from a single
-source directory.</li>
+  <li>You can write your own Makefiles which hard-code these values.</li>
+  <li>You can use the pre-made LLVM sample project. This sample project 
+  includes Makefiles, a configure script that can be used to configure the 
+  location of LLVM, and the ability to support multiple object directories 
+  from a single source directory.</li>
 </ol>
 
-<p>This document assumes that you will base your project off of the LLVM sample
+<p>This document assumes that you will base your project on the LLVM sample
 project found in <tt>llvm/projects/sample</tt>.  If you want to devise your own
 build system, studying the sample project and LLVM Makefiles will probably
 provide enough information on how to write your own Makefiles.</p>
@@ -94,39 +89,52 @@ the name of your project.</li>
 
 <li>Add your source code and Makefiles to your source tree.</li>
 
-<li>If you want your Makefiles to be configured by the <tt>configure</tt>
-script, or if you want to support multiple object directories, add your
-Makefiles to the <tt>configure</tt> script by adding them into the
-<tt>autoconf/configure.ac</tt> file.  The macro <tt>AC_CONFIG_MAKEFILE</tt> will
-copy a file, unmodified, from the source directory to the object directory.</li>
+<li>If you want your project to be configured with the <tt>configure</tt> script
+then you need to edit <tt>autoconf/configure.ac</tt> as follows:
+  <ul>
+    <li><b>AC_INIT</b>. Place the name of your project, its version number and
+    a contact email address for your project as the arguments to this macro</li>
+    <li><b>AC_CONFIG_AUC_DIR</b>. If your project isn't in the
+    <tt>llvm/projects</tt> directory then you might need to adjust this so that
+    it specifies a relative path to the <tt>llvm/autoconf</tt> directory.</li>
+    <li><b>LLVM_CONFIG_PROJECT</b>. Just leave this alone.</li>
+    <li><b>AC_CONFIG_SRCDIR</b>. Specify a path to a file name that identifies
+    your project; or just leave it at <tt>Makefile.config.in</tt></li>
+    <li><b>AC_CONFIG_FILES</b>. Do not change.</li>
+    <li><b>AC_CONFIG_MAKEFILE</b>. Use one of these macros for each Makefile
+    that your project uses. This macro arranges for your makefiles to be copied
+    from the source directory, unmodified, to the build directory.</li>
+  </ul>
+</li>
 
 <li>After updating <tt>autoconf/configure.ac</tt>, regenerate the
 configure script with these commands:
 
 <div class="doc_code">
 <p><tt>% cd autoconf<br>
-       % autoconf -o ../configure</tt></p>
+       % AutoRegen.sh</tt></p>
 </div>
 
-<p>You must be using Autoconf version 2.57 or higher.</p></li>
+<p>You must be using Autoconf version 2.59 or later and your aclocal version 
+should 1.9 or later.</p></li>
 
 <li>Run <tt>configure</tt> in the directory in which you want to place
 object code.  Use the following options to tell your project where it
 can find LLVM:
 
   <dl>
-    <dt><tt>--with-llvmsrc=&lt;directory&gt;</tt>
-    <dd>
-    Tell your project where the LLVM source tree is located.
-    <p>
-    <dt><tt>--with-llvmobj=&lt;directory&gt;</tt>
-    <dd>
-    Tell your project where the LLVM object tree is located.
+    <dt><tt>--with-llvmsrc=&lt;directory&gt;</tt></dt>
+    <dd>Tell your project where the LLVM source tree is located.</dd>
+    <dt><br/><tt>--with-llvmobj=&lt;directory&gt;</tt></dt>
+    <dd>Tell your project where the LLVM object tree is located.</dd>
+    <dt><br/><tt>--prefix=&lt;directory&gt;</tt></dt>
+    <dd>Tell your project where it should get installed.</dd>
   </dl>
 </ol>
 
-<p>That's it!  Now all you have to do is type <tt>gmake</tt> in the root of
-your object directory, and your project should build.</p>
+<p>That's it!  Now all you have to do is type <tt>gmake</tt> (or <tt>make</tt>
+if your on a GNU/Linux system) in the root of your object directory, and your 
+project should build.</p>
 
 </div>
 
@@ -186,30 +194,25 @@ directories:</p>
   This subdirectory should contain tests that verify that your code
   works correctly.  Automated tests are especially useful.
   <p>
-  Currently, the LLVM build system provides little support for tests,
-  although some exists.  Expanded support for tests will hopefully
-  occur in the future.  In the meantime, the LLVM system does provide the
-  following:
+  Currently, the LLVM build system provides basic support for tests.
+  The LLVM system provides the following:
   <ul>
     <li>
-    LLVM provides several QMTest test classes that can be used to
-    create tests.  They can be found in
-    <tt>llvm/test/QMTest/llvm.py</tt>.  These test classes perform a
-    variety of functions, including code optimization tests, assembly
-    tests,  and code analysis tests.  The Makefile in
-    <tt>llvm/test</tt> provides the QMTest context needed by LLVM test
-    classes.
-    <p>
-
+    LLVM provides a tcl procedure that is used by Dejagnu to run
+    tests.  It can be found in <tt>llvm/lib/llvm-dg.exp</tt>.  This
+    test procedure uses RUN lines in the actual test case to determine
+    how to run the test.  See the <a
+    href="TestingGuide.html">TestingGuide</a> for more details. You
+    can easily write Makefile support similar to the Makefiles in 
+    <tt>llvm/test</tt> to use Dejagnu to run your project's tests.<br/></li>
     <li>
-    The LLVM source tree provides benchmarks and programs which are
-    known to compile with the LLVM GCC front ends.  You can use these
+    LLVM contains an optional package called <tt>llvm-test</tt>
+    which provides benchmarks and programs that are known to compile with the
+    LLVM GCC front ends.  You can use these
     programs to test your code, gather statistics information, and
-    compare it to the current LLVM performance statistics.  These
-    programs are found in the <tt>llvm/test/Programs</tt> directory.
-    <p>
-    Currently, there is no way to hook your tests directly into the
-    <tt>llvm/test/Programs</tt> testing harness.  You will simply
+    compare it to the current LLVM performance statistics.
+    <br/>Currently, there is no way to hook your tests directly into the
+    <tt>llvm/test</tt> testing harness.  You will simply
     need to find a way to use the source provided within that directory
     on your own.
   </ul>
@@ -404,13 +407,13 @@ whether you do a Debug, Release, or Profile build.</p>
   <dt>Libraries
   <dd>
   All libraries (static and dynamic) will be stored in
-  <tt>BUILD_OBJ_ROOT/lib/&lt;type&gt;</tt>, where type is <tt>Debug</tt>,
+  <tt>PROJ_OBJ_ROOT/&lt;type&gt;/lib</tt>, where type is <tt>Debug</tt>,
   <tt>Release</tt>, or <tt>Profile</tt> for a debug, optimized, or
   profiled build, respectively.<p>
 
   <dt>Executables
   <dd>All executables will be stored in
-  <tt>BUILD_OBJ_ROOT/tools/&lt;type&gt;</tt>, where type is <tt>Debug</tt>,
+  <tt>PROJ_OBJ_ROOT/&lt;type&gt;/bin</tt>, where type is <tt>Debug</tt>,
   <tt>Release</tt>, or <tt>Profile</tt> for a debug, optimized, or profiled
   build, respectively.
 </dl>

llvm/docs/ReleaseNotes.html

@@ -2,12 +2,13 @@
                       "http://www.w3.org/TR/html4/strict.dtd">
 <html>
 <head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
   <link rel="stylesheet" href="llvm.css" type="text/css">
-  <title>LLVM 1.3 Release Notes</title>
+  <title>LLVM 1.5 Release Notes</title>
 </head>
 <body>
 
-<div class="doc_title">LLVM 1.3 Release Notes</div>
+<div class="doc_title">LLVM 1.5 Release Notes</div>
  
 <ol>
   <li><a href="#intro">Introduction</a></li>
@@ -15,21 +16,11 @@
   <li><a href="GettingStarted.html">Installation Instructions</a></li>
   <li><a href="#portability">Portability and Supported Platforms</a></li>
   <li><a href="#knownproblems">Known Problems</a>
-  <ul>
-    <li><a href="#experimental">Experimental features included in this
-                                release</a>
-    <li><a href="#core">Known problems with the LLVM Core</a>
-    <li><a href="#c-fe">Known problems with the C Front-end</a>
-    <li><a href="#c++-fe">Known problems with the C++ Front-end</a>
-    <li><a href="#x86-be">Known problems with the X86 Back-end</a>
-    <li><a href="#sparcv9-be">Known problems with the SparcV9 Back-end</a>
-    <li><a href="#c-be">Known problems with the C back-end</a>
-  </ul></li>
   <li><a href="#additionalinfo">Additional Information</a></li>
 </ol>
 
 <div class="doc_author">
-  <p>Written by the <a href="http://llvm.cs.uiuc.edu">LLVM team</a><p>
+  <p>Written by the <a href="http://llvm.cs.uiuc.edu">LLVM Team</a><p>
 </div>
 
 <!-- *********************************************************************** -->
@@ -41,22 +32,22 @@
 <div class="doc_text">
 
 <p>This document contains the release notes for the LLVM compiler
-infrastructure, release 1.3.  Here we describe the status of LLVM, including any
-known problems and bug fixes from the previous release.  The most up-to-date
-version of this document can be found on the <a
-href="http://llvm.cs.uiuc.edu/releases/1.3/">LLVM 1.3 web site</a>.  If you are
+infrastructure, release 1.5.  Here we describe the status of LLVM, including any
+known problems and major improvements from the previous release.  The most
+up-to-date version of this document can be found on the <a
+href="http://llvm.cs.uiuc.edu/releases/1.5/">LLVM 1.5 web site</a>.  If you are
 not reading this on the LLVM web pages, you should probably go there because
 this document may be updated after the release.</p>
 
-<p>For more information about LLVM, including information about potentially more
-current releases, please check out the <a href="http://llvm.cs.uiuc.edu">main
+<p>For more information about LLVM, including information about the latest
+release, please check out the <a href="http://llvm.cs.uiuc.edu">main LLVM
 web site</a>.  If you have questions or comments, the <a
 href="http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVM developer's mailing
 list</a> is a good place to send them.</p>
 
-<p>Note that if you are reading this file from CVS, this document applies
-to the <i>next</i> release, not the current one.  To see the release notes for
-the current or previous releases, see the <a
+<p>Note that if you are reading this file from CVS or the main LLVM web page,
+this document applies to the <i>next</i> release, not the current one.  To see
+the release notes for the current or previous releases, see the <a
 href="http://llvm.cs.uiuc.edu/releases/">releases page</a>.</p>
 
 </div>
@@ -69,271 +60,286 @@ href="http://llvm.cs.uiuc.edu/releases/">releases page</a>.</p>
 
 <div class="doc_text">
 
-<p>This is the fourth public release of the LLVM compiler infrastructure.  This
-release primarily improves the <a href="#codequality">performance of the
-code</a> produced by all aspects of the LLVM compiler, adds many <a
-href="#newfeatures">new features</a>, <a href="#bugfix">fixes a few
-bugs</a>, speeds up the compiler, and introduces a new (experimental)
-PowerPC code generator.</p>
+<p>This is the sixth public release of the LLVM Compiler Infrastructure.</p>
 
-<p> At this time, LLVM is known to correctly compile and run all C &amp; C++
-SPEC CPU95 &amp; 2000 benchmarks, the Olden benchmarks, and the Ptrdist 
-benchmarks, and <b>many</b> other programs.  LLVM now also works
-with a broad variety of C++ programs.</p>
+<p>LLVM 1.5 is known to correctly compile a wide range of C and C++ programs,
+includes bug fixes for those problems found since the 1.4 release, and includes
+a large number of new features and enhancements, described below.</p>
 
 </div>
 
 <!--=========================================================================-->
-<div class="doc_subsubsection">
-<a name="newfeatures">This release implements the following new features:</a>
+<div class="doc_subsection">
+<a name="newfeatures">New Features in LLVM 1.5</a>
 </div>
 
+<!--_________________________________________________________________________-->
+<div class="doc_subsubsection"><a name="newcg">New Native Code
+Generators</a></div>
+
 <div class="doc_text">
-
-<ol>
-<li>The LLVM <a href="LangRef.html#i_select"><tt>select</tt></a> instruction is
-now fully implemented and supported by all transformations, native code
-generators, and the interpreter.</li>
-<li>Bugpoint can now narrow down code-generation bugs to a loop nest, where
-before it could only narrow them down to a function being miscompiled.</li>
-<li><a href="http://llvm.cs.uiuc.edu/PR40">Bugpoint can now debug arbitrary
-modes of llc</a> and lli, by passing them command line flags (e.g.
-<tt>-regalloc=linearscan</tt>).</li>
-<li>The Control Flow Graph in the native code generators is no longer
-constrained to be the same as the CFG for the LLVM input code.</li>
-<li>The LLVM induction variable analysis routines have been rewritten.</li>
-<li>LLVM now has new loop unrolling and loop unswitching passes.</li>
-<li>The induction variable substitution pass performs linear function test
-replacement and exit value replacement optimizations.</li>
-<li>LLVM now has first-class support for <a
-href="GarbageCollection.html">Accurate Garbage Collection</a>, enabling the use
-of aggressive copying and generational collectors.</li>
-<li>LLVM now includes a simple implementation of <a 
-href="AliasAnalysis.html#anders-aa">Andersen's interprocedural alias 
-analysis</a> algorithm.</li>
-<li>Bugpoint can <a href="http://llvm.cs.uiuc.edu/PR327">extract individual
-basic blocks</a> to track down reduce miscompilation testcases.</li>
-<li>LLVM and the C front-end now work under Win32 using the
-<a href="http://www.cygwin.com">Cygwin</a> runtime libraries.  
-This includes the JIT compiler.</li>
-<li>The LLVM code generator is now being <a
-href="CodeGenerator.html">documented</a>.</li>
-<li>LLVM includes a new tool, <a 
-href="CommandGuide/html/llvm-bcanalyzer.html">llvm-bcanalyzer</a>,  This tool 
-can compute various statistics and dump information about LLVM bytecode
-encoding.</li>
-<li>The <a href="BytecodeFormat.html">LLVM bytecode file format</a> is now 
-documented.</li>
-<li>LLVM now provides an <a
-href="LangRef.html#i_isunordered">llvm.isunordered</a> intrinsic for efficient
-implementation of unordered floating point comparisons.</li>
-<li>The llvmgcc front-end now supports the GCC builtins for ISO C99 floating
-point comparison macros (e.g., <tt>__builtin_islessequal</tt>).</li>
-<li>We now generate <a href="CommandGuide/">HTML documentation and man pages</a>
-for the tools from a single source (perl-style POD files).</li>
-<li>The LLVM code generator can now dynamically load targets from shared 
-objects.</li>
-<li>LLVM now includes a "skeleton" target, which makes it easier to get 
-started porting LLVM to new architectures.</li>
-<li>The linear scan register allocator is now enabled by default in the 
-target-independent code generator.</li>
-<li>LLVM now includes a dead store elimination pass.</li>
-<li>Bugpoint can now debug miscompilations that lead to the program going 
-into an infinite loop.</li>
-<li>LLVM now provides interfaces to support ML-style pattern matching on the 
-LLVM IR.</li>
-<li>LLVM now includes a <a 
-href="AliasAnalysis.html#globalsmodref">context-sensitive mod/ref analysis</a> 
-for global variables, which is now enabled by default in gccld.</li>
-<li>LLVM can now autogenerate assembly printers for code generators from the 
-tablegen description of the target (before they were hand coded).</li>
-<li>All LLVM tools will now respond to the 
-<a href="http://llvm.cs.uiuc.edu/PR413"><tt>--version</tt> option</a> which 
-will tell you the version of LLVM on which the tool is based.</li>
-<li>An experimental PowerPC backend has been added, capable of compiling several
-SPEC benchmarks.</li>
-</ol>
-
+<p>
+This release includes new native code generators for <a
+href="#alpha-be">Alpha</a>, <a href="#ia64-be">IA-64</a>, and <a
+href="#sparcv8">SPARC-V8</a> (32-bit SPARC).  These code generators are still
+beta quality, but are progressing rapidly.  The Alpha backend is implemented
+with an eye towards being compatible with the widely used SimpleScalar
+simulator.
+</p>
 </div>
 
-
-<!--=========================================================================-->
-<div class="doc_subsubsection">
-In this release, the following missing features were implemented:
-</div>
+<!--_________________________________________________________________________-->
+<div class="doc_subsubsection"><a name="selectiondag">New Instruction
+Selector Framework</a></div>
 
 <div class="doc_text">
-
-<ol>
-<li><a href="http://llvm.cs.uiuc.edu/PR82">LLVM cannot handle structures with
-more than 256 elements</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR38">[bugpoint] External functions used in
-non-instruction entities, such as global constant initializer</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR178">Stacker does not handle targets 
-with 64-bit pointers.</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR290">Bugpoint doesn't support
-uses of external fns by immediate constant exprs</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR407">Can't add function passes that 
-depend on immutable passes to the FunctionPassManager</a>.</li>
-<li><a href="http://llvm.cs.uiuc.edu/PR308">Archive file reader doesn't
-understand abbreviated names in headers</a></li>
-</ol>
-
+<p>This release includes a <a href="CodeGenerator.html#instselect">new framework
+for building instruction selectors</a>, which has long been the hardest part of
+building a new LLVM target.  This framework handles a lot of the mundane (but
+easy to get wrong) details of writing the instruction selector, such as
+generating efficient code for <a
+href="LangRef.html#i_getelementptr">getelementptr</a> instructions, promoting
+small integer types to larger types (e.g.  for RISC targets with one size of
+integer registers), expanding 64-bit integer operations for 32-bit targets, etc.
+Currently, the X86, PowerPC, Alpha, and IA-64 backends use this framework.  The
+SPARC backends will be migrated when time permits.
+</p>
 </div>
 
-<!--=========================================================================-->
-<div class="doc_subsubsection">
-<a name="qualityofimp">In this release, the following Quality of Implementation
-issues were fixed:</a>
-</div>
+<!--_________________________________________________________________________-->
+<div class="doc_subsubsection"><a name="customccs">New Support for Per-Function
+Calling Conventions</a></div>
 
 <div class="doc_text">
+<p>LLVM 1.5 adds supports for <a href="LangRef.html#callingconv">per-function
+calling conventions</a>.  Traditionally, the LLVM code generators match the
+native C calling conventions for a target.  This is important for compatibility,
+but is not very flexible.  This release allows custom calling conventions to be
+established for functions, and defines three target-independent conventions (<a
+href="LangRef.html#callingconv">C call, fast call, and cold call</a>) which may
+be supported by code generators.  When possible, the LLVM optimizer promotes C
+functions to use the "fastcc" convention, allowing the use of more efficient
+calling sequences (e.g., parameters are passed in registers in the X86 target).
+</p>
 
-<ol>
-<li><a href="http://llvm.cs.uiuc.edu/PR305">LLVM tools will happily spew
-bytecode onto your terminal</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR329">[llvmgcc] type names are not emitted
-for structure typedefs</a></li>
-<li>All documentation is now conformant to the HTML 4.01 (Strict) level.</li>
-<li>The spurious "WARNING: Found global types that are not compatible" warning
-produced when linking C++ programs has been fixed.</li>
-<li><a href="http://llvm.cs.uiuc.edu/PR391">lli Doesn't Handle Exceptions From 
-Bytecode Reader</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR392">Global Vars Have (Somewhat) Limited 
-  Type Range</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR341">operator&lt;&lt; on a Value* now
-prints the address of the object instead of its contents.</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR402">Bytecode Enhancements
-Needed</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR404">[loopsimplify] Loop simplify is
-really slow on 252.eon</a></li>
-<li><a href="Http://llvm.cs.uiuc.edu/PR122">[code-cleanup] SymbolTable class
-cleanup, Type should not derive from Value, eliminate ConstantPointerRef
-class</a>.</li>
-<li>The memory footprint of the LLVM IR has been reduced substantially.</li>
-<li>The LLVM linker and many core classes have been sped up substantially.</li>
-</ol>
+<p>Targets may now also define target-specific calling conventions, allowing
+LLVM to fully support calling convention altering options (e.g. GCC's
+<tt>-mregparm</tt> flag) and well-defined target conventions (e.g. stdcall and
+fastcall on X86).</p>
+</div>
+
+<!--_________________________________________________________________________-->
+<div class="doc_subsubsection"><a name="tailcalls">New Support for
+Proper Tail Calls</a></div>
+
+<div class="doc_text">
+<p>The release now includes support for <a
+href="http://doi.acm.org/10.1145/277650.277719">proper tail calls</a>, as
+required to implement languages like Scheme.  Tail calls make use of two
+features: custom calling conventions (described above), which allow the code
+generator to use a convention where the caller deallocates its stack before it
+returns.  The second feature is a flag on the <a href="LangRef.html#i_call">call
+instruction</a>, which indicates that the callee does not access the caller's
+stack frame (indicating that it is acceptable to deallocate the caller stack
+before invoking the callee).  LLVM proper tail calls run on the system stack (as
+do normal calls), supports indirect tail calls, tail calls with arbitrary
+numbers of arguments, tail calls where the callee requires more argument space
+than the caller, etc.  The only case not supported are varargs calls, but that
+could be added if desired.
+</p>
+
+<p>To ensure a call is interpreted as a tail call, a front-end must mark
+functions as "fastcc", mark calls with the 'tail' marker, and follow the call
+with a return of the called value (or void).  The optimizer and code generator
+attempt to handle more general cases, but the simple case will always work if
+the code generator supports tail calls.  Here is an example:</p>
+
+<pre>
+    fastcc int %bar(int %X, int(double, int)* %FP) {       ;<i> fastcc</i>
+        %Y = tail call fastcc int %FP(double 0.0, int %X)  ;<i> tail, fastcc</i>
+        ret int %Y
+    }
+</pre>
+
+<p>In LLVM 1.5, the X86 code generator is the only target that has been enhanced
+to support proper tail calls (other targets will be enhanced in future).
+Further, because this support was added very close to the release, it is
+disabled by default.  Pass <tt>-enable-x86-fastcc</tt> to llc to enable it (this
+will be enabled by default in the next release).  The example above compiles to:
+</p>
+
+<pre>
+    bar:
+        sub ESP, 8                   # Callee uses more space than the caller
+        mov ECX, DWORD PTR [ESP + 8] # Get the old return address
+        mov DWORD PTR [ESP + 4], 0   # First half of 0.0
+        mov DWORD PTR [ESP + 8], 0   # Second half of 0.0
+        mov DWORD PTR [ESP], ECX     # Put the return address where it belongs
+        jmp EDX                      # Tail call "FP"
+</pre>
+
+<p>
+With fastcc on X86, the first two integer arguments are passed in EAX/EDX, the
+callee pops its arguments off the stack, and the argument area is always a
+multiple of 8 bytes in size.
+</p>
 
 </div>
 
-<!--=========================================================================-->
-<div class="doc_subsubsection">
-In this release, the following build problems were fixed:
-</div>
+<!--_________________________________________________________________________-->
+<div class="doc_subsubsection">Other New Features</div>
 
 <div class="doc_text">
 <ol>
-<li><a href="http://llvm.cs.uiuc.edu/PR301">Minor configure bugs with
--disable/enable-povray and -disable-spec</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR289">shell scripts output by gccld don't
-work if you change PATH</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR364">[llvmgcc] llvmgcc does not compile 
-with gcc 3.4</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR373">[llvmgcc] obstack.h relies on 
-obsolete casts-as-lvalues GCC extension</a></li>
+  <li>LLVM now includes an <a href="http://llvm.cs.uiuc.edu/PR415">
+      Interprocedural Sparse Conditional Constant Propagation</a> pass, named
+     -ipsccp, which is run by default at link-time.</li>
+  <li>LLVM 1.5 is now about 15% faster than LLVM 1.4 and its core data 
+      structures use about 30% less memory.</li>
+  <li>Support for Microsoft Visual Studio is improved, and <a 
+      href="GettingStartedVS.html">now documented</a>.  Most LLVM tools build
+      natively with Visual C++ now.</li>
+  <li><a href="GettingStarted.html#config">Configuring LLVM to build a subset
+      of the available targets</a> is now implemented, via the
+      <tt>--enable-targets=</tt> option.</li>
+   <li>LLVM can now create native shared libraries with '<tt>llvm-gcc ...
+       -shared -Wl,-native</tt>' (or with <tt>-Wl,-native-cbe</tt>).</li>
+   <li>LLVM now supports a new "<a href="LangRef.html#i_prefetch">llvm.prefetch
+       </a>" intrinsic, and llvm-gcc now supports __builtin_prefetch.
+  <li>LLVM now supports intrinsics for <a href="LangRef.html#int_count">bit
+      counting</a> and llvm-gcc now implements the GCC
+      <tt>__builtin_popcount</tt>, <tt>__builtin_ctz</tt>, and
+      <tt>__builtin_clz</tt> builtins.</li>
+  <li>LLVM now mostly builds on HP-UX with the HP aCC Compiler.</li>
+  <li>The LLVM X86 backend can now emit Cygwin-compatible .s files.</li>
+  <li>LLVM now includes workarounds in the code generator generator which
+      reduces the likelyhood of <a href="http://llvm.cs.uiuc.edu/PR448">GCC
+      hitting swap during optimized builds</a>.</li>
+  <li>The <a href="http://llvm.cs.uiuc.edu/ProjectsWithLLVM/#llvmtv">LLVM
+      Transformation Visualizer</a> (llvm-tv) project has been updated to
+      work with LLVM 1.5.</li>
+  <li>Nightly tester output is now archived on the <a
+      href="http://mail.cs.uiuc.edu/pipermail/llvm-testresults/">
+      llvm-testresults</a> mailing list.</li>
+
 </ol>
 </div>
 
 <!--=========================================================================-->
-<div class="doc_subsubsection">
-<a name="codequality">This release includes the following Code Quality
-improvements:</a>
+<div class="doc_subsection">
+<a name="codequality">Code Quality Improvements in LLVM 1.5</a>
 </div>
 
 <div class="doc_text">
 <ol>
-<li>Fixed: <a href="http://llvm.cs.uiuc.edu/PR309">[vmcore] Code quality problem
-due to long operand of getelementptr</a></li>
+<li>The new -simplify-libcalls pass improves code generated for well-known
+library calls. The pass optimizes calls to many of the string, memory, and
+standard I/O functions (e.g. replace the calls with simpler/faster calls) when
+possible, given information known statically about the arguments to the call.
+</li>
 
-<li>The X86 backend now generates substantially better code for 64-bit integer
-and floating point operations.</li>
+<li>The -globalopt pass now promotes non-address-taken static globals that are
+only accessed in main to SSA registers.</li>
 
-<li>The -inline pass no longer inlines mutually recursive functions until it
-hits the inlining threshold.</li>
+<li>Loops with trip counts based on array pointer comparisons (e.g. "<tt>for (i
+= 0; &amp;A[i] != &amp;A[n]; ++i) ...</tt>") are optimized better than before,
+which primarily helps iterator-intensive C++ code.</li>
 
-<li>The -inline pass no longer misses obvious inlining opportunities just
-because the callee eventually calls into an external function.</li>
+<li>The optimizer now eliminates simple cases where redundant conditions exist
+    between neighboring blocks.</li>
 
-<li>The -simplifycfg pass can now "if convert" simple statements into the 
-<tt>select</tt> instruction.</li>
+<li>The reassociation pass (which turns (1+X+3) into (X+1+3) among other
+things), is more aggressive and intelligent.</li>
 
-<li>The -loopsimplify pass can now break <a
-href="http://llvm.cs.uiuc.edu/PR35">natural loops with multiple backedges</a>
-into multiple nested loops.  This enables a variety of subsequent
-optimizations.</li>
+<li>The -prune-eh pass now detects no-return functions in addition to the
+    no-unwind functions it did before.</li>
 
-<li>The -adce pass can now eliminate calls to functions that do not not write to
-memory.</li>
-
-<li>The link-time optimizer now runs the -prune-eh pass (to remove unused
-exception handlers).</li>
-
-<li>The link-time optimizer now runs dead store elimination and uses a simple
-interprocedural alias analysis.</li>
-
-<li>The -simplifycfg pass can now eliminate simple correlated branches (such as
-"<tt>if (A &lt; B &amp;&amp; A &lt; B)</tt>", and can turn short-circuiting
-operators into the strict versions when useful (such as "<tt>if (A &lt; B || A
-&gt; C)</tt>" into "<tt>if (A &lt; B | A &gt; C)</tt>"</li>
-
-<li>LLVM now has infrastructure for (simple and sparse conditional) constant
-propagation of function calls.  It currently supports a few math library
-functions like sqrt/sin/cos/etc.</li>
-
-<li>The C backend now emits <a href="http://llvm.cs.uiuc.edu/PR334">syntactic
-loops</a> in the code to help C compilers whose optimizers do not recognize 
-loops formed from gotos (like GCC).</li>
-
-<li>The SparcV9 backend no longers <a 
-href="http://llvm.cs.uiuc.edu/PR368">spills the null constant to the constant 
-pool</a>.</li>
+<li>The -globalsmodref alias analysis generates more precise results in some
+    cases.</li>
 </ol>
 </div>
 
+
 <!--=========================================================================-->
-<div class="doc_subsubsection">
-<a name="bugfix">In this release, the following bugs in the previous release
-were fixed:</a>
+<div class="doc_subsection">
+<a name="codequality">Code Generator Improvements in LLVM 1.5</a>
 </div>
 
 <div class="doc_text">
+<ol>
+<li>The code generator now can provide and use information about commutative
+    two-address instructions when performing register allocation.</li>
+
+<li>The code generator now tracks function live-in registers explicitly, 
+    instead of requiring the target to generate 'implicit defs' at the
+    entry to a function.</li>
+
+<li>The code generator can lower integer division by a constant to
+    multiplication by a magic constant and multiplication by a constant into
+    shift/add sequences.</li>
+
+<li>The code generator compiles fabs/fneg/sin/cos/sqrt to assembly instructions
+    when possible.</li>
+
+<li>The PowerPC backend generates better code in many cases, making use of 
+    FMA instructions and the recording ("dot") forms of various PowerPC
+    instructions.</li>
+</ol>
+</div>
+
+
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="bugfix">Significant Bugs Fixed in LLVM 1.5</a>
+</div>
+
+<div class="doc_text">
+
 
 <p>Bugs fixed in the LLVM Core:</p>
-
 <ol>
-<li><a href="http://llvm.cs.uiuc.edu/PR306">[loopsimplify] Loop simplify
-incorrectly updates dominator information</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR310">[tailduplicate] DemoteRegToStack
-breaks SSA form</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR313">[X86] JIT miscompiles unsigned short
-to floating point cast</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR330">[vmcore] Linker causes erroneous
-asssertion</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR332">[adce] Crash handling unreachable
-code that unwinds</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR333">[sparcv9] LLC can't emit 2 functions
-of the same name, both having constant pools</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR337">[livevar] Live variables missed
-physical register use of aliased definition</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR369">[X86] stackifier crash on floating 
-point setcc X, X</a></li>
+   <li><a href="http://llvm.cs.uiuc.edu/PR491">[dse] DSE deletes stores that 
+       are partially overwritten by smaller stores</a></li>
+   <li><a href="http://llvm.cs.uiuc.edu/PR548">[instcombine] miscompilation of 
+       setcc or setcc in one case</a></li>
+   <li>Transition code for LLVM 1.0 style varargs was removed from the .ll file
+       parser.  LLVM 1.0 bytecode files are still supported. </li>
+</ol>
+
+<p>Code Generator Bugs:</p>
+<ol>
+   <li><a href="http://llvm.cs.uiuc.edu/PR490">[cbackend] Logical constant 
+       expressions (and/or/xor) not implemented</a>.</li>
+   <li><a href="http://llvm.cs.uiuc.edu/PR511">[cbackend] C backend does not 
+       respect 'volatile'</a>.</li>
+   <li>The JIT sometimes miscompiled globals and constant pool entries for
+       64-bit integer constants on 32-bit hosts.</li>
+   <li>The C backend should no longer produce code that crashes ICC 8.1.</li>
 </ol>
 
 <p>Bugs in the C/C++ front-end:</p>
-
 <ol>
-<li><a href="http://llvm.cs.uiuc.edu/PR298">[llvmgcc] Variable length array
-indexing miscompiled</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR326">[llvmgcc] Crash on use of undeclared
-enum type</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR355">[llvmgcc] Errors handling function 
-prototypes that take opaque structs by-value</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR374">[llvmgcc] Crash compiling variable 
-length array of structures</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR377">[llvmgcc] miscompilation of staticly
-initialized unsigned bitfields</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR396">[llvm-gcc] Crash casting function to void</a></li>
+   <li><a href="http://llvm.cs.uiuc.edu/PR487">[llvmgcc] llvm-gcc incorrectly 
+       rejects some constant initializers involving the addresses of array 
+       elements</a></li>
+   <li><a href="http://llvm.cs.uiuc.edu/PR501">[llvm-g++] Crash compiling 
+       anonymous union</a></li>
+   <li><a href="http://llvm.cs.uiuc.edu/PR509">[llvm-g++] Do not use dynamic 
+       initialization where static init will do</a></li>
+   <li><a href="http://llvm.cs.uiuc.edu/PR510">[llvmgcc] Field offset 
+       miscalculated for some structure fields following bit fields</a></li>
+   <li><a href="http://llvm.cs.uiuc.edu/PR513">[llvm-g++] Temporary lifetimes 
+       incorrect for short circuit logical operations</a></li>
+   <li><a href="http://llvm.cs.uiuc.edu/PR517">[llvm-gcc] Crash compiling 
+       bitfield &lt;-&gt; aggregate assignment</a></li>
+   <li><a href="http://llvm.cs.uiuc.edu/PR520">[llvm-g++] Error compiling 
+       virtual function thunk with an unnamed argument</a></li>
+   <li><a href="http://llvm.cs.uiuc.edu/PR522">[llvm-gcc] Crash on certain 
+       C99 complex number routines</a></li>
+   <li><a href="http://llvm.cs.uiuc.edu/PR529">[llvm-g++] Crash using placement
+       new on an array type</a></li>
 </ol>
+
 </div>
 
 <!-- *********************************************************************** -->
@@ -344,16 +350,17 @@ initialized unsigned bitfields</a></li>
 
 <div class="doc_text">
 
-<p>LLVM is known to work in the following platforms:</p>
+<p>LLVM is known to work on the following platforms:</p>
 
 <ul>
-<li>Intel and AMD machines running Red Hat Linux and FreeBSD (and probably 
-    other unix-like systems).</li>
+  <li>Intel and AMD machines running Red Hat Linux, Fedora Core and FreeBSD 
+      (and probably other unix-like systems).</li>
 <li>Sun UltraSPARC workstations running Solaris 8.</li>
-<li>Intel and AMD machines running on Win32 with the Cygwin libraries.</li>
-<li>PowerPC-based Mac OS X boxes, running 10.2 and above.  Note that no JIT
-support is available yet, and LLC support is beta.  The C backend can be used
-to produce stable code for this platform.</li>
+<li>Intel and AMD machines running on Win32 with the Cygwin libraries (limited
+    support is available for native builds with Visual C++).</li>
+<li>PowerPC-based Mac OS X systems, running 10.2 and above.</li>
+<li>Alpha-based machines running Debian GNU/Linux.</li>
+<li>Itanium-based machines running Linux and HP-UX.</li>
 </ul>
 
 <p>The core LLVM infrastructure uses
@@ -362,13 +369,6 @@ to the machine and operating system on which it is built.  However, minor
 porting may be required to get LLVM to work on new platforms.  We welcome your
 portability patches and reports of successful builds or error messages.</p>
 
-<p>Note that the LLVM build system does not currently support directories with 
-spaces on them when running on Win32/cygwin.  We strongly recommend running
-LLVM and the C frontend out of a top-level directory without spaces (e.g., 
-<tt>/cygdrive/c/llvm</tt>).  Also, make sure to install <b>all</b> of the 
-cygwin packages.  By default, many important tools are not installed that 
-are needed by the LLVM build process or test suite (e.g., /bin/time).</p>
-
 </div>
 
 <!-- *********************************************************************** -->
@@ -401,15 +401,13 @@ useful to some people.  In particular, if you would like to work on one of these
 components, please contact us on the llvmdev list.</p>
 
 <ul>
-<li>The PowerPC backend is incomplete and is known to miscompile several SPEC
-benchmarks. The file <tt>llvm/lib/Target/PowerPC/README.txt</tt> has
-details.</li>
-<li>The following passes are incomplete or buggy: <tt>-pgmdep, -memdep,
-    -ipmodref, -cee</tt></li>
-<li>The <tt>-pre</tt> pass is incomplete (there are cases it doesn't handle that
-    it should) and not thoroughly tested.</li>
-<li>The <tt>llvm-ar</tt> tool is incomplete and probably buggy.</li>
-<li>The <tt>llvm-db</tt> tool is in a very early stage of development.</li>
+<li>The following passes are incomplete or buggy, and may be removed in future
+    releases: <tt>-cee, -branch-combine, -instloops, -paths, -pre</tt></li>
+<li>The <tt>llvm-db</tt> tool is in a very early stage of development, but can
+    be used to step through programs and inspect the stack.</li>
+<li>The "iterative scan" register allocator (enabled with 
+    <tt>-regalloc=iterativescan</tt>) is not stable.</li>
+<li>The SparcV8, Alpha, and IA64 code generators are experimental.</li>
 </ul>
 
 </div>
@@ -422,26 +420,16 @@ details.</li>
 <div class="doc_text">
 
 <ul>
-
-<li>In the JIT, <tt>dlsym</tt> on a symbol compiled by the JIT will not
-work.</li>
-
-<li>The JIT does not use mutexes to protect its internal data structures.  As
-such, execution of a threaded program could cause these data structures to be
-corrupted.</li>
-
-<li>It is not possible to <tt>dlopen</tt> an LLVM bytecode file in the JIT.</li>
-
-<li>Linking in static archive files (.a files) is very slow (there is no symbol
-table in the archive).</li>
-
-<li>The gccld program <a href="http://llvm.cs.uiuc.edu/PR139">does not link
-objects/archives in the order specified on the command line.</a></li>
-
-<li><a href="http://llvm.cs.uiuc.edu/PR240">The lower-invoke pass does not mark
-values live across a setjmp as volatile</a>.  This missing feature only affects
-targets whose setjmp/longjmp libraries do not save and restore the entire
-register file.</li>
+  <li>In the JIT, <tt>dlsym()</tt> on a symbol compiled by the JIT will not
+  work.</li>
+  <li>The JIT does not use mutexes to protect its internal data structures. As
+  such, execution of a threaded program could cause these data structures to be
+  corrupted.
+  </li>
+  <li><a href="http://llvm.cs.uiuc.edu/PR240">The lower-invoke pass does not 
+    mark values live across a setjmp as volatile</a>. This missing feature 
+  only affects targets whose setjmp/longjmp libraries do not save and restore 
+  the entire register file.</li>
 </ul>
 </div>
 
@@ -465,11 +453,7 @@ register file.</li>
 </pre></li>
 
 <li>Initialization of global union variables can only be done <a
-href="http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=162">with the largest union
-member</a>.</li>
-
-<li><a href="http://llvm.cs.uiuc.edu/PR244">[llvm-gcc] Error when an implicitly
-external function is re-declared as static</a></li>
+href="http://llvm.cs.uiuc.edu/PR162">with the largest union member</a>.</li>
 
 </ul>
 </div>
@@ -511,7 +495,7 @@ work:
   <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Explicit-Reg-Vars.html#Explicit%20Reg%20Vars">Explicit Reg Vars</a>: Defining variables residing in specified registers.</li>
   <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html#Vector%20Extensions">Vector Extensions</a>: Using vector instructions through built-in functions.</li>
   <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Target-Builtins.html#Target%20Builtins">Target Builtins</a>:   Built-in functions specific to particular targets.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Thread-Local.html#Thread-Local">Thread-Local</a>: Per-thread variables.</li>
+  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Thread_002dLocal.html">Thread-Local</a>: Per-thread variables.</li>
   <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Pragmas.html#Pragmas">Pragmas</a>: Pragmas accepted by GCC.</li>
   </ol>
 
@@ -532,10 +516,11 @@ work:
       return.<br>
 
       <b>Supported:</b> <tt>format</tt>, <tt>format_arg</tt>, <tt>non_null</tt>,
-      <tt>constructor</tt>, <tt>destructor</tt>, <tt>unused</tt>,
+      <tt>noreturn</tt>, <tt>constructor</tt>, <tt>destructor</tt>,
+      <tt>unused</tt>,
       <tt>deprecated</tt>, <tt>warn_unused_result</tt>, <tt>weak</tt><br>
 
-      <b>Ignored:</b> <tt>noreturn</tt>, <tt>noinline</tt>,
+      <b>Ignored:</b> <tt>noinline</tt>,
       <tt>always_inline</tt>, <tt>pure</tt>, <tt>const</tt>, <tt>nothrow</tt>,
       <tt>malloc</tt>, <tt>no_instrument_function</tt>, <tt>cdecl</tt><br>
 
@@ -568,7 +553,9 @@ work:
          <tt>__builtin_types_compatible_p</tt>, <tt>__builtin_choose_expr</tt>,
          <tt>__builtin_constant_p</tt>, and <tt>__builtin_expect</tt>
          (currently ignored).  We also support builtins for ISO C99 floating
-         point comparison macros (e.g., <tt>__builtin_islessequal</tt>).</li>
+         point comparison macros (e.g., <tt>__builtin_islessequal</tt>), 
+         <tt>__builtin_prefetch</tt>, <tt>__builtin_popcount[ll]</tt>,
+         <tt>__builtin_clz[ll]</tt>, and <tt>__builtin_ctz[ll]</tt>.</li>
   </ol>
 
   <p>The following extensions <b>are</b> known to be supported:</p>
@@ -596,7 +583,7 @@ or arrays as values.</li>
   <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Case-Ranges.html#Case%20Ranges">Case Ranges</a>: `case 1 ... 9' and such.</li>
   <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Mixed-Declarations.html#Mixed%20Declarations">Mixed Declarations</a>: Mixing declarations and code.</li>
   <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Function-Prototypes.html#Function%20Prototypes">Function Prototypes</a>: Prototype declarations and old-style definitions.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/C---Comments.html#C++%20Comments">C++ Comments</a>: C++ comments are recognized.</li>
+  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Comments.html#C_002b_002b-Comments">C++ Comments</a>: C++ comments are recognized.</li>
   <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Dollar-Signs.html#Dollar%20Signs">Dollar Signs</a>: Dollar sign is allowed in identifiers.</li>
   <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Character-Escapes.html#Character%20Escapes">Character Escapes</a>: <code>\e</code> stands for the character &lt;ESC&gt;.</li>
   <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Alignment.html#Alignment">Alignment</a>: Inquiring about the alignment of a type or variable.</li>
@@ -623,10 +610,9 @@ lists, please let us know (also including whether or not they work).</p>
 
 <div class="doc_text">
 
-<p>For this release, the C++ front-end is considered to be fully functional but
-has not been tested as thoroughly as the C front-end.  It has been tested and 
-works for a number of non-trivial programs, but there may be lurking bugs.
-Please report any bugs or problems.</p>
+<p>For this release, the C++ front-end is considered to be fully
+tested and works for a number of non-trivial programs, including LLVM
+itself.</p>
 
 </div>
 
@@ -639,12 +625,6 @@ Please report any bugs or problems.</p>
 <li>The C++ front-end inherits all problems afflicting the <a href="#c-fe">C
     front-end</a>.</li>
 
-<li><b>IA-64 specific</b>: The C++ front-end does not use <a 
-href="http://llvm.cs.uiuc.edu/PR406">IA64 ABI compliant layout of v-tables</a>.
-In particular, it just stores function pointers instead of function
-descriptors in the vtable.  This bug prevents mixing C++ code compiled with
-LLVM with C++ objects compiled by other C++ compilers.</li>
-
 </ul>
 
 </div>
@@ -684,6 +664,28 @@ href="http://gcc.gnu.org/gcc-3.4/changes.html">GCC 3.4 release notes</a>.</li>
 
 </div>
 
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+  <a name="c-be">Known problems with the C back-end</a>
+</div>
+
+<div class="doc_text">
+
+<ul>
+
+<li>The C back-end produces code that violates the ANSI C Type-Based Alias
+Analysis rules.  As such, special options may be necessary to compile the code
+(for example, GCC requires the <tt>-fno-strict-aliasing</tt> option).  This
+problem probably cannot be fixed.</li>
+
+<li><a href="http://llvm.cs.uiuc.edu/PR56">Zero arg vararg functions are not 
+supported</a>.  This should not affect LLVM produced by the C or C++ 
+frontends.</li>
+
+</ul>
+
+</div>
+
 <!-- ======================================================================= -->
 <div class="doc_subsection">
   <a name="x86-be">Known problems with the X86 back-end</a>
@@ -692,7 +694,20 @@ href="http://gcc.gnu.org/gcc-3.4/changes.html">GCC 3.4 release notes</a>.</li>
 <div class="doc_text">
 
 <ul>
-  <li>none yet</li>
+<li><a href="http://llvm.cs.uiuc.edu/PR566">Memory Mapped I/O Intrinsics do not fence memory</a></li>
+</ul>
+
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+  <a name="ppc-be">Known problems with the PowerPC back-end</a>
+</div>
+
+<div class="doc_text">
+
+<ul>
+<li>None yet</li>
 </ul>
 
 </div>
@@ -713,30 +728,71 @@ several programs in the LLVM test suite</a></li>
 
 <!-- ======================================================================= -->
 <div class="doc_subsection">
-  <a name="c-be">Known problems with the C back-end</a>
+  <a name="alpha-be">Known problems with the Alpha back-end</a>
 </div>
 
 <div class="doc_text">
 
 <ul>
 
-<li>The C back-end produces code that violates the ANSI C Type-Based Alias
-Analysis rules.  As such, special options may be necessary to compile the code
-(for example, GCC requires the <tt>-fno-strict-aliasing</tt> option).  This
-problem probably cannot be fixed.</li>
+<li>On 21164s, some rare FP arithmetic sequences which may trap do not have the
+appropriate nops inserted to ensure restartability.</li>
 
-<li><a href="http://llvm.cs.uiuc.edu/PR33">Initializers for global variables</a>
-cannot include special floating point numbers like Not-A-Number or
-Infinity.</li>
+<li>Defining vararg functions is not supported (but calling them is ok).</li>
 
-<li><a href="http://llvm.cs.uiuc.edu/PR56">Zero arg vararg functions are not 
-supported</a>.  This should not affect LLVM produced by the C or C++ 
-frontends.</li>
+<li>Due to the vararg problems, C++ exceptions do not work.  Small changes are required to the CFE (which break correctness in the exception handler) to compile the exception handling library (and thus the C++ standard library).</li>
 
 </ul>
 
 </div>
 
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+  <a name="ia64-be">Known problems with the IA64 back-end</a>
+</div>
+
+<div class="doc_text">
+
+<ul>
+
+<li>C++ programs are likely to fail on IA64, as calls to <tt>setjmp</tt> are
+made where the argument is not 16-byte aligned, as required on IA64. (Strictly
+speaking this is not a bug in the IA64 back-end; it will also be encountered
+when building C++ programs using the C back-end.)</li>
+
+<li>The C++ front-end does not use <a href="http://llvm.cs.uiuc.edu/PR406">IA64
+ABI compliant layout of v-tables</a>.  In particular, it just stores function
+pointers instead of function descriptors in the vtable.  This bug prevents
+mixing C++ code compiled with LLVM with C++ objects compiled by other C++
+compilers.</li>
+
+<li>There are a few ABI violations which will lead to problems when mixing LLVM
+output with code built with other compilers, particularly for floating-point
+programs.</li>
+
+<li>Defining vararg functions is not supported (but calling them is ok).</li>
+
+</ul>
+
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+  <a name="sparcv8">Known problems with the SPARC-V8 back-end</a>
+</div>
+
+<div class="doc_text">
+
+<ul>
+<li>Many features are still missing (e.g. support for 64-bit integer
+arithmetic).</li>
+
+<li>This backend needs to be updated to use the SelectionDAG instruction
+selection framework.</li>
+</ul>
+
+</div>
+
 <!-- *********************************************************************** -->
 <div class="doc_section">
   <a name="additionalinfo">Additional Information</a>
@@ -745,15 +801,17 @@ frontends.</li>
 
 <div class="doc_text">
 
-<p>A wide variety of additional information is available on the LLVM web page,
-including mailing lists and publications describing algorithms and components
-implemented in LLVM.  The web page also contains versions of the API
-documentation which is up-to-date with the CVS version of the source code.  You
-can access versions of these documents specific to this release by going into
-the "<tt>llvm/doc/</tt>" directory in the LLVM tree.</p>
+<p>A wide variety of additional information is available on the <a
+href="http://llvm.cs.uiuc.edu">LLVM web page</a>, including <a
+href="http://llvm.cs.uiuc.edu/docs/">documentation</a> and <a
+href="http://llvm.cs.uiuc.edu/pubs/">publications describing algorithms and
+components implemented in LLVM</a>.  The web page also contains versions of the
+API documentation which is up-to-date with the CVS version of the source code.
+You can access versions of these documents specific to this release by going
+into the "<tt>llvm/doc/</tt>" directory in the LLVM tree.</p>
 
 <p>If you have any questions or comments about LLVM, please feel free to contact
-us via the <a href="http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev">mailing
+us via the <a href="http://llvm.cs.uiuc.edu/docs/#maillist"> mailing
 lists</a>.</p>
 
 </div>

llvm/docs/SourceLevelDebugging.html

@@ -9,11 +9,10 @@
 
 <div class="doc_title">Source Level Debugging with LLVM</div>
 
-<table border="0" width="100%">
-<tr>
-<td valign="top">
+<table class="layout" style="width:100%">
+  <tr class="layout">
+    <td class="left">
 <ul>
-
   <li><a href="#introduction">Introduction</a>
   <ol>
     <li><a href="#phil">Philosophy behind LLVM debugging information</a></li>
@@ -61,12 +60,11 @@
   </ol></li>
 </ul>
 </td>
-<td align="right" valign="top">
+<td class="right">
 <img src="img/venusflytrap.jpg" alt="A leafy and green bug eater" width="247"
 height="369">
 </td>
-</tr>
-</table>
+</tr></table>
 
 <div class="doc_author">
   <p>Written by <a href="mailto:sabre@nondot.org">Chris Lattner</a></p>
@@ -74,8 +72,8 @@ height="369">
 
 
 <!-- *********************************************************************** -->
-<div class="doc_section"><a name="introduction">Introduction</a></div> <!--
-*********************************************************************** -->
+<div class="doc_section"><a name="introduction">Introduction</a></div> 
+<!-- *********************************************************************** -->
 
 <div class="doc_text">
 
@@ -225,7 +223,7 @@ compatible with the LLVM license).</p>
 <p>For someone so inclined, it should be straight-forward to write different
 front-ends for the LLVM debugger, as the LLVM debugging engine is cleanly
 separated from the <tt>llvm-db</tt> front-end.  A new LLVM GUI debugger or IDE
-would be nice. :)</p>
+would be nice.</p>
 
 </div>
 
@@ -248,7 +246,7 @@ interface as possible.  This should make it extremely easy to learn
 provides the subset of GDB commands that are applicable to LLVM debugging users.
 If there is a command missing that make a reasonable amount of sense within the
 <a href="#limitations">limitations of <tt>llvm-db</tt></a>, please report it as
-a bug or, better yet, submit a patch to add it. :)</p>
+a bug or, better yet, submit a patch to add it.</p>
 
 </div>
 
@@ -1030,6 +1028,7 @@ change in the future.</p>
 <div class="doc_section">
   <a name="ccxx_frontend">C/C++ front-end specific debug information</a>
 </div>
+<!-- *********************************************************************** -->
 
 <div class="doc_text">
 

llvm/docs/Stacker.html

@@ -4,10 +4,6 @@
 <head>
   <title>Stacker: An Example Of Using LLVM</title>
   <link rel="stylesheet" href="llvm.css" type="text/css">
-  <style>
-    table, tr, td { border: 2px solid gray }
-    table { border-collapse: collapse; margin-bottom: 2em }
-  </style>
 </head>
 <body>
 
@@ -515,16 +511,16 @@ using the following construction:</p>
 </ol>
 </div>
 <div class="doc_text" >
-    <table class="doc_table">
-<tr class="doc_table"><td colspan="4">Definition Of Operation Of Built In Words</td></tr>
-<tr class="doc_table"><td colspan="4"><b>LOGICAL OPERATIONS</b></td></tr>
-<tr class="doc_table">
+    <table>
+<tr><th colspan="4">Definition Of Operation Of Built In Words</th></tr>
+<tr><th colspan="4"><b>LOGICAL OPERATIONS</b></th></tr>
+<tr>
     <td>Word</td>
     <td>Name</td>
     <td>Operation</td>
     <td>Description</td>
 </tr>
-<tr class="doc_table">
+<tr>
     <td>&lt;</td>
     <td>LT</td>
     <td>w1 w2 -- b</td>
@@ -581,7 +577,7 @@ using the following construction:</p>
     <td> -- b</td>
     <td>The boolean value TRUE (-1) is pushed on to the stack.</td>
 </tr>
-<tr><td colspan="4"><b>BITWISE OPERATORS</b></td></tr>
+<tr><th colspan="4"><b>BITWISE OPERATORS</b></th></tr>
 <tr>
     <td>Word</td>
     <td>Name</td>
@@ -623,7 +619,7 @@ using the following construction:</p>
     are bitwise exclusive OR'd together and pushed back on the stack. 
     For example, The sequence 1 3 XOR yields 2.</td>
 </tr>
-<tr><td colspan="4"><b>ARITHMETIC OPERATORS</b></td></tr>
+<tr><th colspan="4"><b>ARITHMETIC OPERATORS</b></th></tr>
 <tr>
     <td>Word</td>
     <td>Name</td>
@@ -704,7 +700,7 @@ using the following construction:</p>
     <td>Two values are popped off the stack. The larger value is pushed back
 	on to the stack.</td>
 </tr>
-<tr><td colspan="4"><b>STACK MANIPULATION OPERATORS</b></td></tr>
+<tr><th colspan="4"><b>STACK MANIPULATION OPERATORS</b></th></tr>
 <tr>
     <td>Word</td>
     <td>Name</td>
@@ -791,7 +787,7 @@ using the following construction:</p>
 </tr>
 <tr><td>RROT</td>
     <td>RROT</td>
-    <td>w1 w2 w3 -- w2 w3 w1</td>
+    <td>w1 w2 w3 -- w3 w1 w2</td>
     <td>Reverse rotation. Like ROT, but it rotates the other way around.
 	Essentially, the third element on the stack is moved to the top
 	of the stack.</td>
@@ -849,7 +845,7 @@ using the following construction:</p>
     how much to rotate. That is, ROLL with n=1 is the same as ROT and 
     ROLL with n=2 is the same as ROT2.</td>
 </tr>
-<tr><td colspan="4"><b>MEMORY OPERATORS</b></td></tr>
+<tr><th colspan="4"><b>MEMORY OPERATORS</b></th></tr>
 <tr>
     <td>Word</td>
     <td>Name</td>
@@ -902,7 +898,7 @@ using the following construction:</p>
 	pushed back on the stack so this doesn't count as a "use ptr"
 	in the FREE idiom.</td>
 </tr>
-<tr><td colspan="4"><b>CONTROL FLOW OPERATORS</b></td></tr>
+<tr><th colspan="4"><b>CONTROL FLOW OPERATORS</b></th></tr>
 <tr>
     <td>Word</td>
     <td>Name</td>
@@ -950,26 +946,30 @@ using the following construction:</p>
 	executed. In either case, after the (words....) have executed, execution continues
         immediately following the ENDIF. </td>
 </tr>
-<tr><td>WHILE (words...) END</td>
-    <td>WHILE (words...) END</td>
+<tr><td>WHILE word END</td>
+    <td>WHILE word END</td>
     <td>b -- b </td>
-    <td>The boolean value on the top of the stack is examined. If it is non-zero then the 
-	"words..." between WHILE and END are executed. Execution then begins again at the WHILE where another
-	boolean is popped off the stack. To prevent this operation from eating up the entire
-	stack, you should push on to the stack (just before the END) a boolean value that indicates
-	whether to terminate. Note that since booleans and integers can be coerced you can
-	use the following "for loop" idiom:<br/>
-	<code>(push count) WHILE (words...) -- END</code><br/>
+    <td>The boolean value on the top of the stack is examined (not popped). If 
+      it is non-zero then the "word" between WHILE and END is executed. 
+      Execution then begins again at the WHILE where the boolean on the top of 
+      the stack is examined again. The stack is not modified by the WHILE...END 
+      loop, only examined. It is imperative that the "word" in the body of the
+      loop ensure that the top of the stack contains the next boolean to examine
+      when it completes.  Note that since booleans and integers can be coerced 
+      you can use the following "for loop" idiom:<br/>
+	<code>(push count) WHILE word -- END</code><br/>
 	For example:<br/>
-	<code>10 WHILE DUP &gt;d -- END</code><br/>
-	This will print the numbers from 10 down to 1. 10 is pushed on the stack. Since that is
-	non-zero, the while loop is entered. The top of the stack (10) is duplicated and then
-	printed out with &gt;d. The top of the stack is decremented, yielding 9 and control is
-	transfered back to the WHILE keyword. The process starts all over again and repeats until
-	the top of stack is decremented to 0 at which the WHILE test fails and control is
-	transfered to the word after the END.</td>
+	<code>10 WHILE &gt;d -- END</code><br/>
+        This will print the numbers from 10 down to 1. 10 is pushed on the 
+        stack. Since that is non-zero, the while loop is entered. The top of 
+        the stack (10) is printed out with &gt;d. The top of the stack is 
+        decremented, yielding 9 and control is transfered back to the WHILE 
+        keyword. The process starts all over again and repeats until
+        the top of stack is decremented to 0 at which point the WHILE test 
+        fails and control is transfered to the word after the END.
+      </td>
 </tr>
-<tr><td colspan="4"><b>INPUT &amp; OUTPUT OPERATORS</b></td></tr>
+<tr><th colspan="4"><b>INPUT &amp; OUTPUT OPERATORS</b></th></tr>
 <tr>
     <td>Word</td>
     <td>Name</td>
@@ -1379,8 +1379,6 @@ interested, here are some things that could be implemented better:</p>
     <li>Write an LLVM pass to optimize the use of the global stack. The code
     emitted currently is somewhat wasteful. It gets cleaned up a lot by existing
     passes but more could be done.</li>
-    <li>Add -O -O1 -O2 and -O3 optimization switches to the compiler driver to
-    allow LLVM optimization without using "opt."</li>
     <li>Make the compiler driver use the LLVM linking facilities (with IPO)
     before depending on GCC to do the final link.</li>
     <li>Clean up parsing. It doesn't handle errors very well.</li>

llvm/docs/SystemLibrary.html

@@ -8,35 +8,26 @@
 <body>
 
 <div class="doc_title">System Library</div>
-
-<div class="doc_warning">
-  <p>Warning: This document is a work in progress.</p>
-</div>
-
 <ul>
   <li><a href="#abstract">Abstract</a></li>
-  <li><a href="#requirements">System Library Requirements</a>
+  <li><a href="#requirements">Keeping LLVM Portable</a>
   <ol>
-    <li><a href="#headers">Hide System Header Files</a></li>
+    <li><a href="#headers">Don't Include System Headers</a></li>
+    <li><a href="#expose">Don't Expose System Headers</a></li>
+    <li><a href="#c_headers">Allow Standard C Header Files</a></li>
+    <li><a href="#cpp_headers">Allow Standard C++ Header Files</a></li>
+    <li><a href="#highlev">High-Level Interface</a></li>
     <li><a href="#nofunc">No Exposed Functions</a></li>
     <li><a href="#nodata">No Exposed Data</a></li>
-    <li><a href="#xcptns">No Exceptions</a></li>
-    <li><a href="#errors">Standard Error Codes</a></li>
-    <li><a href="#overhead">Minimize Overhead</a></li>
-  </ol></li>
-  <li><a href="#design">System Library Design</a>
-  <ol>
-    <li><a href="#opaque">Use Opaque Classes</a></li>
-    <li><a href="#common">Common Implementations</a></li>
-    <li><a href="#multi_imps">Multiple Implementations</a></li>
-    <li><a href="#lowlevel">Use Low Level Interfaces</a></li>
-    <li><a href="#memalloc">No Memory Allocation</a></li>
+    <li><a href="#nodupl">No Duplicate Implementations</a></li>
+    <li><a href="#nounused">No Unused Functionality</a></li>
     <li><a href="#virtuals">No Virtual Methods</a></li>
-  </ol></li>
-  <li><a href="#detail">System Library Details</a>
-  <ol>
+    <li><a href="#softerrors">Minimize Soft Errors</a></li>
+    <li><a href="#throw">Throw Only std::string</a></li>
+    <li><a href="#throw_spec">No throw() Specifications</a></li>
+    <li><a href="#organization">Code Organization</a></li>
+    <li><a href="#semantics">Consistent Semantics</a></li>
     <li><a href="#bug">Tracking Bugzilla Bug: 351</a></li>
-    <li><a href="#refimpl">Reference Implementatation</a></li>
   </ol></li>
 </ul>
 
@@ -48,123 +39,285 @@
 <!-- *********************************************************************** -->
 <div class="doc_section"><a name="abstract">Abstract</a></div>
 <div class="doc_text">
-  <p>This document describes the requirements, design, and implementation 
-  details of LLVM's System Library. The library is composed of the header files
-  in <tt>llvm/include/llvm/System</tt> and the source files in 
-  <tt>llvm/lib/System</tt>. The goal of this library is to completely shield 
-  LLVM from the variations in operating system interfaces. By centralizing 
-  LLVM's use of operating system interfaces, we make it possible for the LLVM
-  tool chain and runtime libraries to be more easily ported to new platforms.
-  The library also unclutters the rest of LLVM from #ifdef use and special
-  cases for specific operating systems.</p>
-  <p>The System Library was donated to LLVM by Reid Spencer who formulated the
-  original design as part of the eXtensible Programming System (XPS) which is
-  based, in part, on LLVM.</p>
+  <p>This document provides some details on LLVM's System Library, located in
+  the source at <tt>lib/System</tt> and <tt>include/llvm/System</tt>. The
+  library's purpose is to shield LLVM from the differences between operating
+  systems for the few services LLVM needs from the operating system. Much of
+  LLVM is written using portability features of standard C++. However, in a few
+  areas, system dependent facilities are needed and the System Library is the
+  wrapper around those system calls.</p>
+  <p>By centralizing LLVM's use of operating system interfaces, we make it 
+  possible for the LLVM tool chain and runtime libraries to be more easily 
+  ported to new platforms since (theoretically) only <tt>lib/System</tt> needs 
+  to be ported.  This library also unclutters the rest of LLVM from #ifdef use 
+  and special cases for specific operating systems. Such uses are replaced 
+  with simple calls to the interfaces provided in <tt>include/llvm/System</tt>.
+  </p> 
+  <p>Note that the System Library is not intended to be a complete operating 
+  system wrapper (such as the Adaptive Communications Environment (ACE) or 
+  Apache Portable Runtime (APR)), but only provides the functionality necessary
+  to support LLVM.
+  <p>The System Library was written by Reid Spencer who formulated the
+  design based on similar work originating from the eXtensible Programming 
+  System (XPS). Several people helped with the effort; especially,
+  Jeff Cohen and Henrik Bach on the Win32 port.</p>
 </div>
 
 <!-- *********************************************************************** -->
 <div class="doc_section">
-  <a name="requirements">System Library Requirements</a>
+  <a name="requirements">Keeping LLVM Portable</a>
 </div>
 <div class="doc_text">
-  <p>The System library's requirements are aimed at shielding LLVM from the
-  variations in operating system interfaces. The following sections define the
-  requirements needed to fulfill this objective.</p>
+  <p>In order to keep LLVM portable, LLVM developers should adhere to a set of
+  portability rules associated with the System Library. Adherence to these rules
+  should help the System Library achieve its goal of shielding LLVM from the
+  variations in operating system interfaces and doing so efficiently.  The 
+  following sections define the rules needed to fulfill this objective.</p>
 </div>
 
 <!-- ======================================================================= -->
-<div class="doc_subsection"><a name="headers">Hide System Header Files</a></div>
+<div class="doc_subsection"><a name="headers">Don't Inlcude System Headers</a>
+</div>
 <div class="doc_text">
-  <p>To be written.</p>
+  <p>Except in <tt>lib/System</tt>, no LLVM source code should directly
+  <tt>#include</tt> a system header. Care has been taken to remove all such
+  <tt>#includes</tt> from LLVM while <tt>lib/System</tt> was being
+  developed.  Specifically this means that header files like "unistd.h", 
+  "windows.h", "stdio.h", and "string.h" are forbidden to be included by LLVM 
+  source code outside the implementation of <tt>lib/System</tt>.</p>
+  <p>To obtain system-dependent functionality, existing interfaces to the system
+  found in <tt>include/llvm/System</tt> should be used. If an appropriate 
+  interface is not available, it should be added to <tt>include/llvm/System</tt>
+  and implemented in <tt>lib/System</tt> for all supported platforms.</p>
 </div>
 
 <!-- ======================================================================= -->
-<div class="doc_subsection"><a name="nofunc">No Exposed Functions</a></div>
+<div class="doc_subsection"><a name="expose">Don't Expose System Headers</a>
+</div>
 <div class="doc_text">
-  <p>To be written.</p>
+  <p>The System Library must shield LLVM from <em>all</em> system headers. To 
+  obtain system level functionality, LLVM source must 
+  <tt>#include "llvm/System/Thing.h"</tt> and nothing else. This means that 
+  <tt>Thing.h</tt> cannot expose any system header files. This protects LLVM 
+  from accidentally using system specific functionality and only allows it
+  via the <tt>lib/System</tt> interface.</p>
 </div>
 
 <!-- ======================================================================= -->
-<div class="doc_subsection"><a name="nodata">No Exposed Data</a></div>
+<div class="doc_subsection"><a name="c_headers">Use Standard C Headers</a></div>
 <div class="doc_text">
-  <p>To be written.</p>
+  <p>The <em>standard</em> C headers (the ones beginning with "c") are allowed
+  to be exposed through the <tt>lib/System</tt> interface. These headers and 
+  the things they declare are considered to be platform agnostic. LLVM source 
+  files may include them directly or obtain their inclusion through 
+  <tt>lib/System</tt> interfaces.</p>
 </div>
 
 <!-- ======================================================================= -->
-<div class="doc_subsection"><a name="xcptns">No Exceptions</a></div>
+<div class="doc_subsection"><a name="cpp_headers">Use Standard C++ Headers</a>
+</div>
 <div class="doc_text">
-  <p>To be written.</p>
+  <p>The <em>standard</em> C++ headers from the standard C++ library and
+  standard template library may be exposed through the <tt>lib/System</tt>
+  interface. These headers and the things they declare are considered to be
+  platform agnostic. LLVM source files may include them or obtain their
+  inclusion through lib/System interfaces.</p>
 </div>
 
 <!-- ======================================================================= -->
-<div class="doc_subsection"><a name="errors">Standard Error Codes</a></div>
+<div class="doc_subsection"><a name="highlev">High Level Interface</a></div>
 <div class="doc_text">
-  <p>To be written.</p>
+  <p>The entry points specified in the interface of lib/System must be aimed at 
+  completing some reasonably high level task needed by LLVM. We do not want to
+  simply wrap each operating system call. It would be preferable to wrap several
+  operating system calls that are always used in conjunction with one another by
+  LLVM.</p>
+  <p>For example, consider what is needed to execute a program, wait for it to
+  complete, and return its result code. On Unix, this involves the following
+  operating system calls: <tt>getenv, fork, execve,</tt> and <tt>wait</tt>. The
+  correct thing for lib/System to provide is a function, say
+  <tt>ExecuteProgramAndWait</tt>, that implements the functionality completely.
+  what we don't want is wrappers for the operating system calls involved.</p>
+  <p>There must <em>not</em> be a one-to-one relationship between operating
+  system calls and the System library's interface. Any such interface function
+  will be suspicious.</p>
 </div>
 
 <!-- ======================================================================= -->
-<div class="doc_subsection"><a name="overhead">Minimize Overhead</a></div>
+<div class="doc_subsection"><a name="nounused">No Unused Functionality</a></div>
 <div class="doc_text">
-  <p>To be written.</p>
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section"><a name="design">System Library Design</a></div>
-<div class="doc_text">
-  <p>In order to fulfill the requirements of the system library, strict design
-  objectives must be maintained in the library as it evolves.  The goal here 
-  is to provide interfaces to operating system concepts (files, memory maps, 
-  sockets, signals, locking, etc) efficiently and in such a way that the 
-  remainder of LLVM is completely operating system agnostic.</p>
+  <p>There must be no functionality specified in the interface of lib/System 
+  that isn't actually used by LLVM. We're not writing a general purpose
+  operating system wrapper here, just enough to satisfy LLVM's needs. And, LLVM
+  doesn't need much. This design goal aims to keep the lib/System interface
+  small and understandable which should foster its actual use and adoption.</p>
 </div>
 
 <!-- ======================================================================= -->
-<div class="doc_subsection"><a name="opaque">Use Opaque Classes</a></div>
-<div class="doc_text">
-  <p>no public data</p>
-  <p>onlyprimitive typed private/protected data</p>
-  <p>data size is "right" for platform, not max of all platforms</p>
-  <p>each class corresponds to O/S concept</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="common">Common Implementations</a></div>
-<div class="doc_text">
-  <p>To be written.</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="multi_imps">Multiple Implementations</a>
+<div class="doc_subsection"><a name="nodupl">No Duplicate Implementations</a>
 </div>
 <div class="doc_text">
-  <p>To be written.</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="low_level">Use Low Level Interfaces</a>
-</div>
-<div class="doc_text">
-  <p>To be written.</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="memalloc">No Memory Allocation</a></div>
-<div class="doc_text">
-  <p>To be written.</p>
+  <p>The implementation of a function for a given platform must be written
+  exactly once. This implies that it must be possible to apply a function's 
+  implementation to multiple operating systems if those operating systems can
+  share the same implementation. This rule applies to the set of operating
+  systems supported for a given class of operating system (e.g. Unix, Win32).
+  </p>
 </div>
 
 <!-- ======================================================================= -->
 <div class="doc_subsection"><a name="virtuals">No Virtual Methods</a></div>
 <div class="doc_text">
-  <p>To be written.</p>
+  <p>The System Library interfaces can be called quite frequently by LLVM. In
+  order to make those calls as efficient as possible, we discourage the use of
+  virtual methods. There is no need to use inheritance for implementation
+  differences, it just adds complexity. The <tt>#include</tt> mechanism works
+  just fine.</p>
 </div>
 
-<!-- *********************************************************************** -->
-<div class="doc_section"><a name="detail">System Library Details</a></div>
+<!-- ======================================================================= -->
+<div class="doc_subsection"><a name="nofunc">No Exposed Functions</a></div>
 <div class="doc_text">
-  <p>To be written.</p>
+  <p>Any functions defined by system libraries (i.e. not defined by lib/System) 
+  must not be exposed through the lib/System interface, even if the header file 
+  for that function is not exposed. This prevents inadvertent use of system
+  specific functionality.</p>
+  <p>For example, the <tt>stat</tt> system call is notorious for having
+  variations in the data it provides. <tt>lib/System</tt> must not declare 
+  <tt>stat</tt> nor allow it to be declared. Instead it should provide its own 
+  interface to discovering information about files and directories. Those 
+  interfaces may be implemented in terms of <tt>stat</tt> but that is strictly 
+  an implementation detail. The interface provided by the System Library must
+  be implemented on all platforms (even those without <tt>stat</tt>).</p>
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection"><a name="nodata">No Exposed Data</a></div>
+<div class="doc_text">
+  <p>Any data defined by system libraries (i.e. not defined by lib/System) must
+  not be exposed through the lib/System interface, even if the header file for
+  that function is not exposed. As with functions, this prevents inadvertent use
+  of data that might not exist on all platforms.</p>
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection"><a name="softerrors">Minimize Soft Errors</a></div>
+<div class="doc_text">
+  <p>Operating system interfaces will generally provide error results for every
+  little thing that could go wrong. In almost all cases, you can divide these
+  error results into two groups: normal/good/soft and abnormal/bad/hard. That
+  is, some of the errors are simply information like "file not found", 
+  "insufficient privileges", etc. while other errors are much harder like
+  "out of space", "bad disk sector", or "system call interrupted". We'll call 
+  the first group "<i>soft</i>" errors and the second group "<i>hard</i>" 
+  errors.<p>
+  <p>lib/System must always attempt to minimize soft errors and always just
+  throw a std::string on hard errors. This is a design requirement because the
+  minimization of soft errors can affect the granularity and the nature of the
+  interface. In general, if you find that you're wanting to throw soft errors,
+  you must review the granularity of the interface because it is likely you're
+  trying to implement something that is too low level. The rule of thumb is to
+  provide interface functions that <em>can't</em> fail, except when faced with 
+  hard errors.</p>
+  <p>For a trivial example, suppose we wanted to add an "OpenFileForWriting" 
+  function. For many operating systems, if the file doesn't exist, attempting 
+  to open the file will produce an error.  However, lib/System should not
+  simply throw that error if it occurs because its a soft error. The problem
+  is that the interface function, OpenFileForWriting is too low level. It should
+  be OpenOrCreateFileForWriting. In the case of the soft "doesn't exist" error, 
+  this function would just create it and then open it for writing.</p>
+  <p>This design principle needs to be maintained in lib/System because it
+  avoids the propagation of soft error handling throughout the rest of LLVM.
+  Hard errors will generally just cause a termination for an LLVM tool so don't
+  be bashful about throwing them.</p>
+  <p>Rules of thumb:</p>
+  <ol>
+    <li>Don't throw soft errors, only hard errors.</li>
+    <li>If you're tempted to throw a soft error, re-think the interface.</li>
+    <li>Handle internally the most common normal/good/soft error conditions
+    so the rest of LLVM doesn't have to.</li>
+  </ol>
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection"><a name="throw">Throw Only std::string</a></div>
+<div class="doc_text">
+  <p>If an error occurs that lib/System cannot handle, the only action taken by
+  lib/System is to throw an instance of std:string. The contents of the string
+  must explain both what happened and the context in which it happened. The
+  format of the string should be a (possibly empty) list of contexts each 
+  terminated with a : and a space, followed by the error message, optionally
+  followed by a reason, and optionally followed by a suggestion.</p>
+  <p>For example, failure to open a file named "foo" could result in a message
+  like:</p>
+  <ul><li>foo: Unable to open file because it doesn't exist."</li></ul>
+  <p>The "foo:" part is the context. The "Unable to open file" part is the error
+  message. The "because it doesn't exist." part is the reason. This message has
+  no suggestion. Where possible, the implementation of lib/System should use
+  operating system specific facilities for converting the error code returned by
+  a system call into an error message. This will help to make the error message
+  more familiar to users of that type of operating system.</p>
+  <p>Note that this requirement precludes the throwing of any other exceptions.
+  For example, various C++ standard library functions can cause exceptions to be
+  thrown (e.g. out of memory situation). In all cases, if there is a possibility
+  that non-string exceptions could be thrown, the lib/System library must ensure
+  that the exceptions are translated to std::string form.</p>
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection"><a name="throw_spec">No throw Specifications</a>
+</div>
+<div class="doc_text">
+  <p>None of the lib/System interface functions may be declared with C++ 
+  <tt>throw()</tt> specifications on them. This requirement makes sure that the
+  compiler does not insert additional exception handling code into the interface
+  functions. This is a performance consideration: lib/System functions are at
+  the bottom of many call chains and as such can be frequently called. We
+  need them to be as efficient as possible.</p>
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection"><a name="organization">Code Organization</a></div>
+<div class="doc_text">
+  <p>Implementations of the System Library interface are separated by their
+  general class of operating system. Currently only Unix and Win32 classes are
+  defined but more could be added for other operating system classifications.
+  To distinguish which implementation to compile, the code in lib/System uses
+  the LLVM_ON_UNIX and LLVM_ON_WIN32 #defines provided via configure through the
+  llvm/Config/config.h file. Each source file in lib/System, after implementing
+  the generic (operating system independent) functionality needs to include the
+  correct implementation using a set of <tt>#if defined(LLVM_ON_XYZ)</tt> 
+  directives. For example, if we had lib/System/File.cpp, we'd expect to see in
+  that file:</p>
+  <pre><tt>
+  #if defined(LLVM_ON_UNIX)
+  #include "Unix/File.cpp"
+  #endif
+  #if defined(LLVM_ON_WIN32)
+  #include "Win32/File.cpp"
+  #endif
+  </tt></pre>
+  <p>The implementation in lib/System/Unix/File.cpp should handle all Unix
+  variants. The implementation in lib/System/Win32/File.cpp should handle all
+  Win32 variants.  What this does is quickly differentiate the basic class of 
+  operating system that will provide the implementation. The specific details
+  for a given platform must still be determined through the use of
+  <tt>#ifdef</tt>.</p>
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection"><a name="semantics">Consistent Semantics</a></div>
+<div class="doc_text">
+  <p>The implementation of a lib/System interface can vary drastically between
+  platforms. That's okay as long as the end result of the interface function 
+  is the same. For example, a function to create a directory is pretty straight
+  forward on all operating system. System V IPC on the other hand isn't even
+  supported on all platforms. Instead of "supporting" System V IPC, lib/System
+  should provide an interface to the basic concept of inter-process 
+  communications. The implementations might use System V IPC if that was 
+  available or named pipes, or whatever gets the job done effectively for a 
+  given operating system.  In all cases, the interface and the implementation 
+  must be semantically consistent. </p>
 </div>
 
 <!-- ======================================================================= -->
@@ -174,18 +327,6 @@
   for further details on the progress of this work</p>
 </div>
 
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="refimpl">Reference Implementation</a>
-</div>
-<div class="doc_text">
-  <p>The <tt>linux</tt> implementation of the system library will always be the
-  reference implementation. This means that (a) the concepts defined by the
-  linux must be identically replicated in the other implementations and (b) the
-  linux implementation must always be complete (provide implementations for all
-  concepts).</p>
-</div>
-
 <!-- *********************************************************************** -->
 
 <hr>

llvm/docs/TestingGuide.html

@@ -12,28 +12,30 @@
 </div>
 
 <ol>
-<li><a href="#overview">Overview</a></li>
-<li><a href="#Requirements">Requirements</a></li>
-<li><a href="#quick">Quick Start</a></li>
-<li><a href="#org">LLVM Test Suite Organization</a>
-<ul>
-  <li><a href="#codefragments">Code Fragments</a></li>
-  <li><a href="#wholeprograms">Whole Programs</a></li>
-</ul></li>
-<li><a href="#tree">LLVM Test Suite Tree</a></li>
-<li><a href="#qmstructure">QMTest Structure</a></li>
-<li><a href="#progstructure">Programs Structure</a></li>
-<li><a href="#run">Running the LLVM Tests</a></li>
-<li><a href="#nightly">Running the nightly tester</a></li>
+  <li><a href="#overview">Overview</a></li>
+  <li><a href="#Requirements">Requirements</a></li>
+  <li><a href="#quick">Quick Start</a></li>
+  <li><a href="#org">LLVM Test Suite Organization</a>
+    <ul>
+      <li><a href="#codefragments">Code Fragments</a></li>
+      <li><a href="#wholeprograms">Whole Programs</a></li>
+    </ul>
+  </li>
+  <li><a href="#tree">LLVM Test Suite Tree</a></li>
+  <li><a href="#dgstructure">DejaGNU Structure</a></li>
+  <li><a href="#progstructure"><tt>llvm-test</tt> Structure</a></li>
+  <li><a href="#run">Running the LLVM Tests</a></li>
+  <li><a href="#nightly">Running the nightly tester</a></li>
 </ol>
 
 <div class="doc_author">
-  <p>Written by John T. Criswell</p>
+  <p>Written by John T. Criswell, <a
+  href="http://llvm.x10sys.com/rspencer">Reid Spencer</a>, and Tanya Lattner</p>
 </div>
 
-<!--===============================================================-->
+<!--=========================================================================-->
 <div class="doc_section"><a name="overview">Overview</a></div>
-<!--===============================================================-->
+<!--=========================================================================-->
 
 <div class="doc_text">
 
@@ -43,9 +45,9 @@ and run tests.</p>
 
 </div>
 
-<!--===============================================================-->
+<!--=========================================================================-->
 <div class="doc_section"><a name="Requirements">Requirements</a></div>
-<!--===============================================================-->
+<!--=========================================================================-->
 
 <div class="doc_text">
 
@@ -53,57 +55,98 @@ and run tests.</p>
 required to build LLVM, plus the following:</p>
 
 <dl>
-  <dt><a href="http://www.qmtest.com">QMTest</A></dt>
-  <dd>The LLVM test suite uses QMTest to organize and run tests. <b>Note:
-  you will need <a href="http://llvm.cs.uiuc.edu/qm-2.0.3.tar.gz">QMTest
-  2.0.3 (source tar.gz file)</a> to be successful. The tests do not run with
-  any other version.</b></dd>
+<dt><a href="http://www.gnu.org/software/dejagnu/">DejaGNU</a></dt>
+<dd>The Feature and Regressions tests are organized and run by DejaGNU.</dd>
+<dt><a href="http://expect.nist.gov/">Expect</a></dt>
+<dd>Expect is required by DejaGNU.</dd>
+<dt><a href="http://www.tcl.tk/software/tcltk/">tcl</a></dt>
+<dd>Tcl is required by DejaGNU. </dd>
 
-  <dt><a href="http://www.python.org">Python</A></dt>
-  <dd>You will need a Python interpreter that works with QMTest. Python will
-  need zlib and SAX support enabled.</dd>
+<dt><a href="http://www.netlib.org/f2c">F2C</a></dt>
+<dd>For now, LLVM does not have a Fortran front-end, but using F2C, we can run
+Fortran benchmarks.  F2C support must be enabled via <tt>configure</tt> if not
+installed in a standard place.  F2C requires three items: the <tt>f2c</tt>
+executable, <tt>f2c.h</tt> to compile the generated code, and <tt>libf2c.a</tt>
+to link generated code.  By default, given an F2C directory <tt>$DIR</tt>, the
+configure script will search <tt>$DIR/bin</tt> for <tt>f2c</tt>,
+<tt>$DIR/include</tt> for <tt>f2c.h</tt>, and <tt>$DIR/lib</tt> for
+<tt>libf2c.a</tt>.  The default <tt>$DIR</tt> values are: <tt>/usr</tt>,
+<tt>/usr/local</tt>, <tt>/sw</tt>, and <tt>/opt</tt>.  If you installed F2C in a
+different location, you must tell <tt>configure</tt>:
+
+<ul>
+<li><tt>./configure --with-f2c=$DIR</tt><br>
+This will specify a new <tt>$DIR</tt> for the above-described search
+process.  This will only work if the binary, header, and library are in their
+respective subdirectories of <tt>$DIR</tt>.</li>
+
+<li><tt>./configure --with-f2c-bin=/binary/path --with-f2c-inc=/include/path
+--with-f2c-lib=/lib/path</tt><br>
+This allows you to specify the F2C components separately.  Note: if you choose
+this route, you MUST specify all three components, and you need to only specify
+<em>directories</em> where the files are located; do NOT include the
+filenames themselves on the <tt>configure</tt> line.</li>
+</ul></dd>
 </dl>
-
 </div>
 
-<!--===============================================================-->
+<!--=========================================================================-->
 <div class="doc_section"><a name="quick">Quick Start</a></div>
-<!--===============================================================-->
+<!--=========================================================================-->
 
 <div class="doc_text">
 
-<p> The tests are located in the LLVM source tree under the directory
-<tt>llvm/test</tt>. To run all of the tests in LLVM, use the Master Makefile in
-that directory:</p>
-
+<p>The tests are located in two separate CVS modules. The basic feature and 
+regression tests are in the main "llvm" module under the directory 
+<tt>llvm/test</tt>. A more comprehensive test suite that includes whole 
+programs in C and C++ is in the <tt>llvm-test</tt> module. This module should 
+be checked out to the <tt>llvm/projects</tt> directory. When you
+<tt>configure</tt> the <tt>llvm</tt> module, the <tt>llvm-test</tt> module
+will be automatically configured. Alternatively, you can configure the <tt>llvm-test</tt> module manually.</p>
+<p>To run all of the simple tests in LLVM using DejaGNU, use the master Makefile in the
+<tt>llvm/test</tt> directory:</p>
 <pre>
- % gmake -C llvm/test
+% gmake -C llvm/test
+</pre>
+or<br>
+<pre>
+% gmake check
 </pre>
 
-<p>To run only the code fragment tests (i.e. those that do basic testing of
-LLVM), run the tests organized by QMTest:</p>
-
+<p>To run only a subdirectory of tests in llvm/test using DejaGNU (ie.
+Regression/Transforms), just set the TESTSUITE variable to the path of the
+subdirectory (relative to <tt>llvm/test</tt>):</p>
 <pre>
- % gmake -C llvm/test qmtest
+% gmake -C llvm/test TESTSUITE=Regression/Transforms
 </pre>
 
-<p>To run only the tests that compile and execute whole programs, run the
-Programs tests:</p>
+<p><b>Note: If you are running the tests with <tt>objdir != subdir</tt>, you
+must have run the complete testsuite before you can specify a
+subdirectory.</b></p>
+
+<p>To run the comprehensive test suite (tests that compile and execute whole 
+programs), run the <tt>llvm-test</tt> tests:</p>
 
 <pre>
- % gmake -C llvm/test/Programs
+% cd llvm/projects
+% cvs co llvm-test
+% cd llvm-test
+% ./configure --with-llvmsrc=$LLVM_SRC_ROOT --with-llvmobj=$LLVM_OBJ_ROOT
+% gmake
 </pre>
 
 </div>
 
-<!--===============================================================-->
+<!--=========================================================================-->
 <div class="doc_section"><a name="org">LLVM Test Suite Organization</a></div>
-<!--===============================================================-->
+<!--=========================================================================-->
 
 <div class="doc_text">
 
 <p>The LLVM test suite contains two major categories of tests: code
-fragments and whole programs.</p>
+fragments and whole programs. Code fragments are in the <tt>llvm</tt> module
+under the <tt>llvm/test</tt> directory. The whole programs
+test suite is in the <tt>llvm-test</tt> module under the main directory.</p>
 
 </div>
 
@@ -120,8 +163,8 @@ language front end.</p>
 <p>Code fragments are not complete programs, and they are never executed to
 determine correct behavior.</p> 
 
-<p>The tests in the Features and Regression directories contain code
-fragments.</p>
+<p>These code fragment tests are located in the <tt>llvm/test/Features</tt> and 
+<tt>llvm/test/Regression</tt> directories.</p>
 
 </div>
 
@@ -133,7 +176,7 @@ fragments.</p>
 stand-alone program that can be executed.  These programs are generally written
 in high level languages such as C or C++, but sometimes they are written
 straight in LLVM assembly.</p>
-  
+
 <p>These programs are compiled and then executed using several different
 methods (native compiler, LLVM C backend, LLVM JIT, LLVM native code generation,
 etc).  The output of these programs is compared to ensure that LLVM is compiling
@@ -144,171 +187,166 @@ a way of benchmarking LLVM performance, both in terms of the efficiency of the
 programs generated as well as the speed with which LLVM compiles, optimizes, and
 generates code.</p>
 
-<p>The Programs directory contains all tests which compile and benchmark whole
-programs.</p> 
+<p>All "whole program" tests are located in the <tt>llvm-test</tt> CVS
+module.</p> 
 
 </div>
 
-<!--===============================================================-->
+<!--=========================================================================-->
 <div class="doc_section"><a name="tree">LLVM Test Suite Tree</a></div>
-<!--===============================================================-->
+<!--=========================================================================-->
 
 <div class="doc_text">
 
 <p>Each type of test in the LLVM test suite has its own directory. The major
 subtrees of the test suite directory tree are as follows:</p>
-      
-<ul>
-  <li>Features 
-    <p>This directory contains sample codes that test various features of the
-    LLVM language.  These pieces of sample code are run through various
-    assembler, disassembler, and optimizer passes.</p>
-
-  <li>Regression
-    <p>This directory contains regression tests for LLVM.  When a bug is found
-    in LLVM, a regression test containing just enough code to reproduce the
-    problem should be written and placed somewhere underneath this directory.
-    In most cases, this will be a small piece of LLVM assembly language code,
-    often distilled from an actual application or benchmark.</p>
-
-  <li>Programs
-    <p>The Programs directory contains programs that can be compiled with LLVM
-    and executed.  These programs are compiled using the native compiler and
-    various LLVM backends.  The output from the program compiled with the native
-    compiler is assumed correct; the results from the other programs are
-    compared to the native program output and pass if they match.  </p>
-  
-    <p> In addition for testing correctness, the Programs directory also
-    performs timing tests of various LLVM optimizations.  It also records
-    compilation times for the compilers and the JIT.  This information can be
-    used to compare the effectiveness of LLVM's optimizations and code
-    generation.</p>
     
-    <p>The Programs directory is subdivided into several smaller subdirectories:
-    </p>
-
-    <ul>
-      <li>Programs/SingleSource
-        <p>The SingleSource directory contains test programs that are only a
-        single source file in size.  These are usually small benchmark programs
-        or small programs that calculate a particular value.  Several such
-        programs are grouped together in each directory.</p></li>
-
-      <li>Programs/MultiSource
-        <p>The MultiSource directory contains subdirectories which contain
-        entire programs with multiple source files.  Large benchmarks and whole
-        applications go here.</p></li>
-
-      <li>Programs/External
-        <p>The External directory contains Makefiles for building code that is
-        external to (i.e. not distributed with) LLVM.  The most prominent member
-        of this directory is the SPEC 2000 benchmark suite.  The presence and
-        location of these external programs is configured by the LLVM
-        <tt>configure</tt> script.</p></li>
-        
-    </ul></li>
-
-  <li>QMTest
-    <p>This directory contains the QMTest information files.  Inside this
-    directory are QMTest administration files and the Python code that
-    implements the LLVM test and database classes.</p>
-
-</ul>
-
-</div>
-
-<!--===============================================================-->
-<div class="doc_section"><a name="qmstructure">QMTest Structure</a></div>
-<!--===============================================================-->
-
-<div class="doc_text">
-
-<p>The LLVM test suite is partially driven by QMTest and partially
-driven by GNU Make.  Specifically, the Features and Regression tests
-are all driven by QMTest.  The Programs directory is currently
-driven by a set of Makefiles.</p>
-
-<p>The QMTest system needs to have several pieces of information
-available; these pieces of configuration information are known
-collectively as the "context" in QMTest parlance.  Since the context
-for LLVM is relatively large, the master Makefile in llvm/test
-sets it for you.</p>
-
-<p>The LLVM database class makes the subdirectories of llvm/test a
-QMTest test database.  For each directory that contains tests driven by
-QMTest, it knows what type of test the source file is and how to run it.</p>
-
-<p>Hence, the QMTest namespace is essentially what you see in the
-Feature and Regression directories, but there is some magic that
-the database class performs (as described below).</p>
-
-<p>The QMTest namespace is currently composed of the following tests and test
-suites:</p>
-
 <ul>
-  <li>Feature
-              <p>
-  These are the feature tests found in the Feature directory.
-  They are broken up into the following categories:
-              </p>
-  <ul>
-    <li>ad
-      <p>Assembler/Disassembler tests.  These tests verify that a piece of LLVM
-      assembly language can be assembled into bytecode and then disassembled
-      into the original assembly language code.  It does this several times to
-      ensure that assembled output can be disassembled and disassembler output
-      can be assembled.  It also verifies that the give assembly language file
-      can be assembled correctly.</p></li>
+<li><tt>llvm/test/Features</tt>
+<p>This directory contains sample codes that test various features of the
+LLVM language.  These pieces of sample code are run through various
+assembler, disassembler, and optimizer passes.</p>
+</li>
 
-    <li>opt
-      <p>Optimizer tests.  These tests verify that two of the optimizer passes
-      completely optimize a program (i.e.  after a single pass, they cannot
-      optimize a program any further).</p></li>
+<li><tt>llvm/test/Regression</tt>
+<p>This directory contains regression tests for LLVM.  When a bug is found
+in LLVM, a regression test containing just enough code to reproduce the
+problem should be written and placed somewhere underneath this directory.
+In most cases, this will be a small piece of LLVM assembly language code,
+often distilled from an actual application or benchmark.</p>
+</li>
 
-    <li>mc
-      <p> Machine code tests.  These tests verify that the LLVM assembly
-      language file can be translated into native assembly code.</p></li>
+<li><tt>llvm-test</tt>
+<p>The <tt>llvm-test</tt> CVS module contains programs that can be compiled 
+with LLVM and executed.  These programs are compiled using the native compiler
+and various LLVM backends.  The output from the program compiled with the 
+native compiler is assumed correct; the results from the other programs are
+compared to the native program output and pass if they match.</p>
 
-    <li>cc
-      <p>C code tests.  These tests verify that the specified LLVM assembly
-      code can be converted into C source code using the C backend.</p></li>
-  </ul>
+<p>In addition for testing correctness, the <tt>llvm-test</tt> directory also
+performs timing tests of various LLVM optimizations.  It also records
+compilation times for the compilers and the JIT.  This information can be
+used to compare the effectiveness of LLVM's optimizations and code
+generation.</p></li>
 
-  <p>The LLVM database class looks at every file in the Feature directory and
-  creates a fake test hierarchy containing
-  <tt>Feature.&lt;testtype&gt;.&lt;testname&gt;</tt>.  So, if you add an LLVM
-  assembly language file to the Feature directory, it actually creates 5 new
-  tests: assembler/disassembler, assembler, optimizer, machine code, and C code.
-  </p>
+<li><tt>llvm-test/SingleSource</tt>
+<p>The SingleSource directory contains test programs that are only a single 
+source file in size.  These are usually small benchmark programs or small 
+programs that calculate a particular value.  Several such programs are grouped 
+together in each directory.</p></li>
 
-  <li>Regression
-    <p>These are the regression tests.  There is one suite for each
-    subdirectory of the Regression directory.  If you add a new subdirectory
-    there, you will need to modify, at least, the <tt>RegressionMap</tt>
-    variable in <tt>QMTest/llvmdb.py</tt> so that QMTest knows how to run the
-    tests in the new subdirectory.</p>
+<li><tt>llvm-test/MultiSource</tt>
+<p>The MultiSource directory contains subdirectories which contain entire 
+programs with multiple source files.  Large benchmarks and whole applications 
+go here.</p></li>
 
-</ul>
+<li><tt>llvm-test/External</tt>
+<p>The External directory contains Makefiles for building code that is external
+to (i.e., not distributed with) LLVM.  The most prominent members of this
+directory are the SPEC 95 and SPEC 2000 benchmark suites.  The presence and
+location of these external programs is configured by the llvm-test
+<tt>configure</tt> script.</p></li>
       
+</ul>
+
+</div>
+<!--=========================================================================-->
+<div class="doc_section"><a name="dgstructure">DejaGNU Structure</a></div>
+<!--=========================================================================-->
+
+<div class="doc_text">
+<p>The LLVM test suite is partially driven by DejaGNU and partially
+driven by GNU Make. Specifically, the Features and Regression tests
+are all driven by DejaGNU. The <tt>llvm-test</tt>
+module is currently driven by a set of Makefiles.</p>
+
+<p>The DejaGNU structure is very simple, but does require some
+information to be set. This information is gathered via <tt>configure</tt> and
+is written to a file, <tt>site.exp</tt> in <tt>llvm/test</tt>. The
+<tt>llvm/test</tt>
+Makefile does this work for you.</p>
+
+<p>In order for DejaGNU to work, each directory of tests must have a
+<tt>dg.exp</tt> file. This file is a program written in tcl that calls
+the <tt>llvm-runtests</tt> procedure on each test file. The
+llvm-runtests procedure is defined in
+<tt>llvm/test/lib/llvm-dg.exp</tt>. Any directory that contains only
+directories does not need the <tt>dg.exp</tt> file.</p>
+
+<p>In order for a test to be run, it must contain information within
+the test file on how to run the test. These are called <tt>RUN</tt>
+lines. Run lines are specified in the comments of the test program
+using the keyword <tt>RUN</tt> followed by a colon, and lastly the
+commands to execute. These commands will be executed in a bash script,
+so any bash syntax is acceptable. You can specify as many RUN lines as
+necessary.  Each RUN line translates to one line in the resulting bash
+script. Below is an example of legal RUN lines in a <tt>.ll</tt>
+file:</p>
+<pre>
+; RUN: llvm-as < %s | llvm-dis > %t1
+; RUN: llvm-dis < %s.bc-13 > %t2
+; RUN: diff %t1 %t2
+</pre>
+<p>There are a couple patterns within a <tt>RUN</tt> line that the
+llvm-runtest procedure looks for and replaces with the appropriate
+syntax:</p>
+
+<dl style="margin-left: 25px">
+<dt>%p</dt> 
+<dd>The path to the source directory. This is for locating
+any supporting files that are not generated by the test, but used by
+the test.</dd> 
+<dt>%s</dt> 
+<dd>The test file.</dd> 
+
+<dt>%t</dt>
+<dd>Temporary filename: testscript.test_filename.tmp, where
+test_filename is the name of the test file. All temporary files are
+placed in the Output directory within the directory the test is
+located.</dd> 
+
+<dt>%prcontext</dt> 
+<dd>Path to a script that performs grep -C. Use this since not all
+platforms support grep -C.</dd>
+
+<dt>%llvmgcc</dt> <dd>Full path to the llvm-gcc executable.</dd>
+<dt>%llvmgxx</dt> <dd>Full path to the llvm-g++ executable.</dd>
+</dl>
+
+<p>There are also several scripts in the llvm/test/Scripts directory
+that you might find useful when writing <tt>RUN</tt> lines.</p>
+
+<p>Lastly, you can easily mark a test that is expected to fail on a
+specific platform by using the <tt>XFAIL</tt> keyword. Xfail lines are
+specified in the comments of the test program using <tt>XFAIL</tt>,
+followed by a colon, and one or more regular expressions (separated by
+a comma) that will match against the target triplet for the
+machine. You can use * to match all targets. Here is an example of an
+<tt>XFAIL</tt> line:</p>
+<pre>
+; XFAIL: darwin,sun
+</pre>
+
 </div>
 
-<!--===============================================================-->
-<div class="doc_section"><a name="progstructure">Programs Structure</a></div>
-<!--===============================================================-->
+<!--=========================================================================-->
+<div class="doc_section"><a name="progstructure"><tt>llvm-test</tt> 
+Structure</a></div>
+<!--=========================================================================-->
 
 <div class="doc_text">
 
-<p>As mentioned previously, the Programs tree in llvm/test provides three types
+<p>As mentioned previously, the <tt>llvm-test</tt> module  provides three types
 of tests: MultiSource, SingleSource, and External.  Each tree is then subdivided
 into several categories, including applications, benchmarks, regression tests,
 code that is strange grammatically, etc.  These organizations should be
 relatively self explanatory.</p>
 
-<p>In addition to the regular Programs tests, the Programs tree also provides a
-mechanism for compiling the programs in different ways.  If the variable TEST is
-defined on the gmake command line, the test system will include a Makefile named
-<tt>TEST.&lt;value of TEST variable&gt;.Makefile</tt>.  This Makefile can modify
-build rules to yield different results.</p>
+<p>In addition to the regular "whole program"  tests, the <tt>llvm-test</tt>
+module also provides a mechanism for compiling the programs in different ways.
+If the variable TEST is defined on the gmake command line, the test system will
+include a Makefile named <tt>TEST.&lt;value of TEST variable&gt;.Makefile</tt>.
+This Makefile can modify build rules to yield different results.</p>
 
 <p>For example, the LLVM nightly tester uses <tt>TEST.nightly.Makefile</tt> to
 create the nightly test reports.  To run the nightly tests, run <tt>gmake
@@ -319,40 +357,91 @@ designed for internal LLVM research and will not work outside of the LLVM
 research group.  They may still be valuable, however, as a guide to writing your
 own TEST Makefile for any optimization or analysis passes that you develop with
 LLVM.</p>
-      
+
+<p>Note, when configuring the <tt>llvm-test</tt> module, you might want to
+specify the following configuration options:</p>
+<dl>
+  <dt><i>--enable-spec2000</i>
+  <dt><i>--enable-spec2000=&lt;<tt>directory</tt>&gt;</i>
+  <dd>
+    Enable the use of SPEC2000 when testing LLVM.  This is disabled by default
+    (unless <tt>configure</tt> finds SPEC2000 installed).  By specifying
+    <tt>directory</tt>, you can tell configure where to find the SPEC2000
+    benchmarks.  If <tt>directory</tt> is left unspecified, <tt>configure</tt>
+    uses the default value
+    <tt>/home/vadve/shared/benchmarks/speccpu2000/benchspec</tt>.
+    <p>
+  <dt><i>--enable-spec95</i>
+  <dt><i>--enable-spec95=&lt;<tt>directory</tt>&gt;</i>
+  <dd>
+    Enable the use of SPEC95 when testing LLVM.  It is similar to the
+    <i>--enable-spec2000</i> option.
+    <p>
+  <dt><i>--enable-povray</i>
+  <dt><i>--enable-povray=&lt;<tt>directory</tt>&gt;</i>
+  <dd>
+    Enable the use of Povray as an external test.  Versions of Povray written
+    in C should work.  This option is similar to the <i>--enable-spec2000</i>
+    option.
+</dl>
 </div>
 
-<!--===============================================================-->
+<!--=========================================================================-->
 <div class="doc_section"><a name="run">Running the LLVM Tests</a></div>
-<!--===============================================================-->
+<!--=========================================================================-->
 
 <div class="doc_text">
 
 <p>First, all tests are executed within the LLVM object directory tree.  They
-<i>are not</i> executed inside of the LLVM source tree.  This is because the
-test suite creates temporary files during execution.  </p>
+<i>are not</i> executed inside of the LLVM source tree. This is because the
+test suite creates temporary files during execution.</p>
 
-<p>The master Makefile in llvm/test is capable of running both the QMTest driven
-tests and the Programs tests.  By default, it will run all of the tests.</p>
+<p>The master Makefile in llvm/test is capable of running only the DejaGNU driven
+tests. By default, it will run all of these tests.</p>
 
-<p>To run only the QMTest driven tests, run <tt>gmake qmtest</tt> at the
-command line in llvm/tests.  To run a specific qmtest, suffix the test name with
-".t" when running gmake.</p>
+<p>To run only the DejaGNU driven tests, run <tt>gmake</tt> at the
+command line in <tt>llvm/test</tt>.  To run a specific directory of tests, use
+the TESTSUITE variable.
+</p>
 
-<p>For example, to run the Regression.LLC tests, type <tt>gmake
-Regression.LLC.t</tt> in llvm/tests.</p>
+<p>For example, to run the Regression tests, type 
+<tt>gmake TESTSUITE=Regression</tt> in <tt>llvm/tests</tt>.</p>
 
-<p>Note that the Makefiles in llvm/test/Features and llvm/test/Regression are
-gone. You must now use QMTest from the llvm/test directory to run them.</p>
+<p>Note that there are no Makefiles in <tt>llvm/test/Features</tt> and
+<tt>llvm/test/Regression</tt>. You must use DejaGNU from the <tt>llvm/test</tt>
+directory to run them.</p>
 
-<p>To run the Programs test, cd into the llvm/test/Programs directory and type
-<tt>gmake</tt>.  Alternatively, you can type <tt>gmake TEST=&lt;type&gt;
-test</tt> to run one of the specialized tests in
-llvm/test/Programs/TEST.&lt;type&gt;.Makefile. For example, you could run the
+<p>To run the <tt>llvm-test</tt> suite, you need to use the following steps:
+</p>
+<ol>
+  <li>cd into the llvm/projects directory</li>
+  <li>check out the <tt>llvm-test</tt> module with:<br/>
+  <tt>cvs -d :pserver:anon@llvm.cs.uiuc.edu:/var/cvs/llvm co -PR llvm-test</tt><br> 
+  This will get the test suite into <tt>llvm/projects/llvm-test</tt></li>
+  <li>configure the test suite. You can do this one of two ways:
+  <ol>
+    <li>Use the regular llvm configure:<br/>
+    <tt>cd $LLVM_OBJ_ROOT ; $LLVM_SRC_ROOT/configure</tt><br/>
+    This will ensure that the <tt>projects/llvm-test</tt> directory is also
+    properly configured.</li>
+    <li>Use the <tt>configure</tt> script found in the <tt>llvm-test</tt> source
+    directory:<br/>
+    <tt>$LLVM_SRC_ROOT/projects/llvm-test/configure --with-llvmsrc=$LLVM_SRC_ROOT --with-llvmobj=$LLVM_OBJ_ROOT</tt>
+    </li>
+  </ol>
+  <li>gmake</li>
+</ol>
+<p>Note that the second and third steps only need to be done once. After you
+have the suite checked out and configured, you don't need to do it again (unless
+the test code or configure script changes).</p>
+
+<p>To make a specialized test (use one of the
+<tt>llvm-test/TEST.&lt;type&gt;.Makefile</tt>s), just run:<br/>
+<tt>gmake TEST=&lt;type&gt; test</tt><br/>For example, you could run the
 nightly tester tests using the following commands:</p>
 
 <pre>
- % cd llvm/test/Programs
+ % cd llvm/projects/llvm-test
  % gmake TEST=nightly test
 </pre>
 
@@ -361,46 +450,65 @@ output and standard error.  You can redirect these results to a file if you
 choose.</p>
 
 <p>Some tests are known to fail.  Some are bugs that we have not fixed yet;
-others are features that we haven't added yet (or may never add).  In QMTest,
+others are features that we haven't added yet (or may never add).  In DejaGNU,
 the result for such tests will be XFAIL (eXpected FAILure).  In this way, you
 can tell the difference between an expected and unexpected failure.</p>
 
-<p>The Programs tests have no such feature as of this time. If the test passes,
-only warnings and other miscellaneous output will be generated.  If a test
-fails, a large &lt;program&gt; FAILED message will be displayed.  This will help
-you separate benign warnings from actual test failures.</p>
+<p>The tests in <tt>llvm-test</tt> have no such feature at this time. If the
+test passes, only warnings and other miscellaneous output will be generated.  If
+a test fails, a large &lt;program&gt; FAILED message will be displayed.  This
+will help you separate benign warnings from actual test failures.</p>
 
 </div>
 
-<!--===============================================================-->
+<!--=========================================================================-->
 <div class="doc_section"><a name="nightly">Running the nightly tester</a></div>
-<!--===============================================================-->
+<!--=========================================================================-->
 
 <div class="doc_text">
 
 <p>
 The <a href="http://llvm.cs.uiuc.edu/testresults/">LLVM Nightly Testers</a>
 automatically check out an LLVM tree, build it, run the "nightly" 
-program test (described above) and all of the regression tests, then 
-delete the checked out tree.  This tester is designed to ensure that 
+program test (described above), run  all of the feature and regression tests, 
+and then delete the checked out tree.  This tester is designed to ensure that 
 programs don't break as well as keep track of LLVM's progress over time.</p>
 
-<p>
-If you'd like to set up an instance of the nightly tester to run on your 
-machine, take a look at the comments at the top of the utils/NightlyTester.pl
-file.  We usually run it from a crontab entry that looks ilke this:
-</p>
+<p>If you'd like to set up an instance of the nightly tester to run on your
+machine, take a look at the comments at the top of the
+<tt>utils/NightlyTester.pl</tt> file.  We usually run it from a crontab entry
+that looks ilke this:</p>
 
+<div class="doc_code">
 <pre>
-5 3 * * *       LLVM_LIB_SEARCH_PATH=.../llvm-gcc/bytecode-libs $HOME/llvm/utils/NightlyTest.pl -parallel -enable-linscan ...CVSREPOSTRING... $HOME/buildtest-X86 $HOME/cvs/testresults-X86
+5 3 * * *  $HOME/llvm/utils/NightlyTest.pl -parallel $CVSROOT $HOME/buildtest-X86 $HOME/cvs/testresults-X86
 </pre>
+</div>
+
+<p>Or, you can create a shell script to encapsulate the running of the script.
+The optimized x86 Linux nightly test is run from just such a script:</p>
+
+<div class="doc_code">
+<pre>
+#!/bin/bash
+BASE=/proj/work/llvm/nightlytest
+export CVSROOT=:pserver:anon@llvm.cs.uiuc.edu:/var/cvs/llvm
+export BUILDDIR=$BASE/build 
+export WEBDIR=$BASE/testresults 
+export LLVMGCCDIR=/proj/work/llvm/cfrontend/install
+export PATH=/proj/install/bin:$LLVMGCCDIR/bin:$PATH
+export LD_LIBRARY_PATH=/proj/install/lib
+cd $BASE
+cp /proj/work/llvm/llvm/utils/NightlyTest.pl .
+nice ./NightlyTest.pl -nice -release -verbose -parallel -enable-linscan -noexternals 2&gt;&amp;1 &gt; output.log
+mail -s 'X86 nightly tester results' <a href="http://mail.cs.uiuc.edu/mailman/listinfo/llvm-testresults">llvm-testresults@cs.uiuc.edu</a> &lt; output.log
+</pre>
+</div>
+
+<p>Take a look at the <tt>NightlyTest.pl</tt> file to see what all of the flags
+and strings do.  If you start running the nightly tests, please let us know and
+we'll link your page to the global tester page.  Thanks!</p>
 
-<p>
-Take a look at the NightlyTest.pl file to see what all of the flags and 
-strings do.  If you start running the nightly tests, please let us know and 
-we'll link your page to the global tester page.  Thanks!
-</p>
-      
 </div>
 
 <!-- *********************************************************************** -->
@@ -412,8 +520,8 @@ we'll link your page to the global tester page.  Thanks!
   <a href="http://validator.w3.org/check/referer"><img
   src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /></a>
 
-  John T. Criswell<br>
-  <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a><br>
+  John T. Criswell, Reid Spencer, and Tanya Lattner<br>
+  <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a><br/>
   Last modified: $Date$
 </address>
 </body>

llvm/docs/UsingLibraries.html

@@ -0,0 +1,504 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
+<html>
+<head>
+	<title>Using The LLVM Libraries</title>
+  <link rel="stylesheet" href="llvm.css" type="text/css">
+</head>
+<body>
+<div class="doc_title">Using The LLVM Libraries</div>
+<ol>
+  <li><a href="#abstract">Abstract</a></li>
+  <li><a href="#introduction">Introduction</a></li>
+  <li><a href="#descriptions">Library Descriptions</a></li>
+  <li><a href="#dependencies">Library Dependencies</a></li>
+  <li><a href="#rot">Linkage Rules Of Thumb</a>
+	  <ol>
+      <li><a href="#always">Always link LLVMCore, LLVMSupport, LLVMSystem</a>
+			<li><a href="#onlyone">Never link both archive and re-linked</a>
+		</ol>
+	</li>
+</ol>
+
+<div class="doc_author">
+  <p>Written by <a href="mailto:rspencer@x10sys.com">Reid Spencer</a></p>
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_section"><a name="abstract">Abstract</a></div>
+<div class="doc_text">
+  <p>Amongst other things, LLVM is a toolkit for building compilers, linkers,
+  runtime executives, virtual machines, and other program execution related
+  tools. In addition to the LLVM tool set, the functionality of LLVM is
+  available through a set of libraries.  To use LLVM as a toolkit for
+  constructing tools, a developer needs to understand what is contained in the
+  various libraries, what they depend on, and how to use them.  This document 
+  describes the contents of the libraries and how and when to use them.
+</p>
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_section"> <a name="introduction">Introduction</a></div>
+<div class="doc_text">
+  <p>If you're writing a compiler, virtual machine, or any other utility based 
+  on LLVM, you'll need to figure out which of the many libraries files you will 
+  need to link with to be successful. An understanding of the contents of these 
+  files and their inter-relationships will be useful in coming up with an optimal 
+  specification for the libraries to link with. The purpose of this document is 
+  to reduce some of the trial and error that the author experienced in using 
+  LLVM.</p>
+  <p>LLVM produces two types of libraries: archives (ending in <tt>.a</tt>) and
+  objects (ending in <tt>.o</tt>). However, both are libraries. Libraries ending
+  in <tt>.o</tt> are known as re-linked libraries because they contain all the
+  compilation units of the library linked together as a single <tt>.o</tt> file.
+  Furthermore, many of the libraries have <em>both</em> forms of library. The
+  re-linked libraries are used whenever you want to include all symbols from the
+  library. The archive libraries are used whenever you want to only resolve
+  outstanding symbols at that point in the link without including everything in
+  the library. </p>
+  <p>When linking your tools, you will use the <tt>LLVMLIBS</tt> make variable. 
+  (see the <a href="MakefileGuide.html#LLVMLIBS">Makefile Guide</a> for 
+  details). This variable specifies which LLVM libraries to link into your tool 
+  and the order in which they will be linked. You specify re-linked libraries by
+  naming the library without a suffix. You specify archive libraries by naming
+  the library with a <tt>.a</tt> suffix but without the <tt>lib</tt> prefix. The
+  order in which the libraries appear in the <tt>LLVMLIBS</tt> variable
+  definition is the order in which they will be linked. Getting this order
+  correct for your tool can sometimes be challenging.
+</div>
+<!-- ======================================================================= -->
+<div class="doc_section"><a name="descriptions"></a>Library Descriptions</div>
+<div class="doc_text">
+  <p>The table below categorizes each library
+<table style="text-align:left">
+  <tr><th>Library</th><th>Forms</th><th>Description</th></tr>
+  <tr><th colspan="3">Core Libraries</th></tr>
+  <tr><td>LLVMArchive</td><td><tt>.a</tt></td>
+    <td>LLVM archive reading and writing</td></tr>
+  <tr><td>LLVMAsmParser</td><td><tt>.o</tt></td>
+    <td>LLVM assembly parsing</td></tr>
+  <tr><td>LLVMBCReader</td><td><tt>.o</tt></td>
+    <td>LLVM bytecode reading</td></tr>
+  <tr><td>LLVMBCWriter</td><td><tt>.o</tt></td>
+    <td>LLVM bytecode writing</td></tr>
+  <tr><td>LLVMCore</td><td><tt>.o</tt></td>
+    <td>LLVM core intermediate representation</td></tr>
+  <tr><td>LLVMDebugger</td><td><tt>.o</tt></td>
+    <td>Source level debugging support</td></tr>
+  <tr><td>LLVMLinker</td><td><tt>.a</tt></td>
+    <td>Bytecode and archive linking interface</td></tr>
+  <tr><td>LLVMSupport</td><td><tt>.a .o</tt></td>
+    <td>General support utilities</td></tr>
+  <tr><td>LLVMSystem</td><td><tt>.a .o</tt></td>
+    <td>Operating system abstraction layer</td></tr>
+
+  <tr><th colspan="3">Analysis Libraries</th></tr>
+  <tr><td>LLVMAnalysis</td><td><tt>.a .o</tt></td>
+    <td>Various analysis passes.</td></tr>
+  <tr><td>LLVMDataStructure</td><td><tt>.a .o</tt></td>
+    <td>Data structure analysis passes.</td></tr>
+  <tr><td>LLVMipa</td><td><tt>.a .o</tt></td>
+    <td>Inter-procedural analysis passes.</td></tr>
+
+  <tr><th colspan="3">Transformation Libraries</th></tr>
+  <tr><td>LLVMInstrumentation</td><td><tt>.a .o</tt></td>
+    <td>Instrumentation passes.</td></tr>
+  <tr><td>LLVMipo</td><td><tt>.a .o</tt></td>
+    <td>All inter-procedural optimization passes.</td></tr>
+  <tr><td>LLVMScalarOpts</td><td><tt>.a .o</tt></td>
+    <td>All scalar optimization passes.</td></tr>
+  <tr><td>LLVMTransforms</td><td><tt>.a .o</tt></td>
+    <td>Uncategorized transformation passes.</td></tr>
+  <tr><td>LLVMTransformUtils</td><td><tt>.a .o</tt></td>
+    <td>Transformation utilities.</td></tr>
+  <tr><td>LLVMProfilePaths</td><td><tt>.o</tt></td>
+    <td>Profile paths for instrumentation.</td></tr>
+
+  <tr><th colspan="3">Code Generation Libraries </th></tr>
+  <tr><td>LLVMCodeGen</td><td><tt>.o</tt></td>
+    <td>Native code generation infrastructure</td></tr>
+
+  <tr><th colspan="3">Target Libraries</th></tr>
+  <tr><td>LLVMCBackend</td><td><tt>.o</tt></td>
+    <td>'C' language code generator.</td></tr>
+  <tr><td>LLVMPowerPC</td><td><tt>.o</tt></td>
+    <td>PowerPC code generation backend</td></tr>
+  <tr><td>LLVMSelectionDAG</td><td><tt>.o</tt></td>
+    <td>Aggressive instruction selector for directed acyclic graphs.</td></tr>
+  <tr><td>LLVMSkeleton</td><td><tt>.a .o</tt></td>
+    <td>Skeleton for a code generation backend.</td></tr>
+  <tr><td>LLVMSparcV8</td><td><tt>.o</tt></td>
+    <td>Code generation for SparcV8.</td></tr>
+  <tr><td>LLVMSparcV9</td><td><tt>.o</tt></td>
+    <td>Code generation for SparcV9.</td></tr>
+  <tr><td>LLVMSparcV9RegAlloc</td><td><tt>.a .o</tt></td>
+    <td>Graph-coloring register allocator for SparcV9.</td></tr>
+  <tr><td>LLVMSparcV9InstrSched</td><td><tt>.o</tt></td>
+    <td>Instruction scheduling for SparcV9.</td></tr>
+  <tr><td>LLVMSparcV9LiveVar</td><td><tt>.o</tt></td>
+    <td>Live variable analysis SparcV9.</td></tr>
+  <tr><td>LLVMSparcV9ModuloSched</td><td><tt>.o</tt></td>
+    <td>Modulo scheduling for SparcV9.</td></tr>
+  <tr><td>LLVMTarget</td><td><tt>.a .o</tt></td>
+    <td>Generic code generation utilities.</td></tr>
+  <tr><td>LLVMX86</td><td><tt>.o</tt></td>
+    <td>Intel x86 code generation backend</td></tr>
+
+  <tr><th colspan="3">Runtime Libraries</th></tr>
+  <tr><td>LLVMInterpreter</td><td><tt>.o</tt></td>
+    <td>Bytecode Interpreter</td></tr>
+  <tr><td>LLVMJIT</td><td><tt>.o</tt></td>
+    <td>Bytecode JIT Compiler</td></tr>
+  <tr><td>LLVMExecutionEngine</td><td><tt>.o</tt></td>
+    <td>Virtual machine engine</td></tr>
+  <tr><td>LLVMexecve</td><td><tt>.o</tt></td>
+    <td>execve(2) replacement for llee</td></tr>
+</table>
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_section"><a name="dependencies"></a>Library Dependencies</div>
+<div class="doc_text">
+  <p>Below are two dependency graphs and a list that show the relationships
+  between the various LLVM archive libraries and object files.  This information 
+  can be automatically generated with the <tt>GenLibDeps.pl</tt> utility found
+  in the <tt>llvm/utils</tt> directory.</p>
+  <!-- =======NOTE: =========================================================-->
+  <!-- === The following graphs and <dl> list are generated automatically ===-->
+  <!-- === by the util named GenLibDeps.pl in the llvm/utils directory.   ===-->
+  <!-- === This should be updated whenever new libraries are added,       ===-->
+  <!-- === removed, or changed                                            ===-->
+  <!-- =======NOTE: =========================================================-->
+  <h2>Dependency Relationships Of Libraries</h2>
+  <p>This graph shows the dependency of archive libraries on other archive 
+  libraries or objects. Where a library has both archive and object forms, only
+  the archive form is shown.</p>
+  <img src="img/libdeps.gif" alt="Library Dependencies"/>
+  <h2>Dependency Relationships Of Object Files</h2>
+  <p>This graph shows the dependency of object files on archive libraries or 
+  other objects. Where a library has both object and archive forms, only the 
+  dependency to the archive form is shown.</p> 
+  <img src="img/objdeps.gif" alt="Object File Dependencies"/>
+  <p>The following list shows the dependency relationships between libraries in
+  textual form. The information is the same as shown on the graphs but arranged
+  alphabetically.</p>
+<dl>
+  <dt><b>libLLVMAnalysis.a</b</dt><dd><ul>
+    <li>libLLVMScalarOpts.a</li>
+    <li>libLLVMSupport.a</li>
+    <li>libLLVMTarget.a</li>
+    <li>libLLVMTransformUtils.a</li>
+    <li>LLVMCore.o</li>
+  </ul></dd>
+  <dt><b>libLLVMArchive.a</b</dt><dd><ul>
+    <li>libLLVMSupport.a</li>
+    <li>libLLVMSystem.a</li>
+    <li>LLVMBCReader.o</li>
+  </ul></dd>
+  <dt><b>libLLVMDataStructure.a</b</dt><dd><ul>
+    <li>libLLVMAnalysis.a</li>
+    <li>libLLVMSupport.a</li>
+    <li>libLLVMTarget.a</li>
+    <li>libLLVMTransformUtils.a</li>
+    <li>LLVMCore.o</li>
+  </ul></dd>
+  <dt><b>libLLVMInstrumentation.a</b</dt><dd><ul>
+    <li>libLLVMSupport.a</li>
+    <li>libLLVMTransformUtils.a</li>
+    <li>LLVMCore.o</li>
+  </ul></dd>
+  <dt><b>libLLVMLinker.a</b</dt><dd><ul>
+    <li>libLLVMArchive.a</li>
+    <li>libLLVMSystem.a</li>
+    <li>LLVMBCReader.o</li>
+    <li>LLVMCore.o</li>
+  </ul></dd>
+  <dt><b>libLLVMScalarOpts.a</b</dt><dd><ul>
+    <li>libLLVMAnalysis.a</li>
+    <li>libLLVMSupport.a</li>
+    <li>libLLVMTarget.a</li>
+    <li>libLLVMTransformUtils.a</li>
+    <li>LLVMCore.o</li>
+  </ul></dd>
+  <dt><b>libLLVMSparcV9RegAlloc.a</b</dt><dd><ul>
+    <li>libLLVMAnalysis.a</li>
+    <li>libLLVMSupport.a</li>
+    <li>LLVMCodeGen.o</li>
+    <li>LLVMCore.o</li>
+    <li>LLVMSparcV9LiveVar.o</li>
+    <li>LLVMSparcV9.o</li>
+  </ul></dd>
+  <dt><b>libLLVMSupport.a</b</dt><dd><ul>
+    <li>libLLVMSystem.a</li>
+    <li>LLVMbzip2.o</li>
+  </ul></dd>
+  <dt><b>libLLVMSystem.a</b</dt><dd></dd>
+  <dt><b>libLLVMTarget.a</b</dt><dd><ul>
+    <li>libLLVMSupport.a</li>
+    <li>LLVMCore.o</li>
+  </ul></dd>
+  <dt><b>libLLVMTransformUtils.a</b</dt><dd><ul>
+    <li>libLLVMAnalysis.a</li>
+    <li>libLLVMScalarOpts.a</li>
+    <li>libLLVMSupport.a</li>
+    <li>LLVMCore.o</li>
+  </ul></dd>
+  <dt><b>libLLVMTransforms.a</b</dt><dd><ul>
+    <li>libLLVMAnalysis.a</li>
+    <li>libLLVMSupport.a</li>
+    <li>libLLVMTarget.a</li>
+    <li>libLLVMTransformUtils.a</li>
+    <li>LLVMCore.o</li>
+  </ul></dd>
+  <dt><b>libLLVMipa.a</b</dt><dd><ul>
+    <li>libLLVMAnalysis.a</li>
+    <li>libLLVMSupport.a</li>
+    <li>LLVMCore.o</li>
+  </ul></dd>
+  <dt><b>libLLVMipo.a</b</dt><dd><ul>
+    <li>libLLVMAnalysis.a</li>
+    <li>libLLVMipa.a</li>
+    <li>libLLVMScalarOpts.a</li>
+    <li>libLLVMSupport.a</li>
+    <li>libLLVMTarget.a</li>
+    <li>libLLVMTransformUtils.a</li>
+    <li>LLVMCore.o</li>
+  </ul></dd>
+  <dt><b>LLVMAnalysis.o</b</dt><dd><ul>
+    <li>libLLVMScalarOpts.a</li>
+    <li>libLLVMSupport.a</li>
+    <li>libLLVMTarget.a</li>
+    <li>libLLVMTransformUtils.a</li>
+    <li>LLVMCore.o</li>
+  </ul></dd>
+  <dt><b>LLVMAsmParser.o</b</dt><dd><ul>
+    <li>LLVMCore.o</li>
+  </ul></dd>
+  <dt><b>LLVMBCReader.o</b</dt><dd><ul>
+    <li>libLLVMSupport.a</li>
+    <li>libLLVMSystem.a</li>
+    <li>LLVMCore.o</li>
+  </ul></dd>
+  <dt><b>LLVMBCWriter.o</b</dt><dd><ul>
+    <li>libLLVMSupport.a</li>
+    <li>LLVMCore.o</li>
+  </ul></dd>
+  <dt><b>LLVMCBackend.o</b</dt><dd><ul>
+    <li>libLLVMAnalysis.a</li>
+    <li>libLLVMipa.a</li>
+    <li>libLLVMScalarOpts.a</li>
+    <li>libLLVMSupport.a</li>
+    <li>libLLVMTarget.a</li>
+    <li>LLVMCore.o</li>
+  </ul></dd>
+  <dt><b>LLVMCodeGen.o</b</dt><dd><ul>
+    <li>libLLVMAnalysis.a</li>
+    <li>libLLVMSupport.a</li>
+    <li>libLLVMTarget.a</li>
+    <li>LLVMCore.o</li>
+  </ul></dd>
+  <dt><b>LLVMCore.o</b</dt><dd><ul>
+    <li>libLLVMSupport.a</li>
+  </ul></dd>
+  <dt><b>LLVMDataStructure.o</b</dt><dd><ul>
+    <li>libLLVMAnalysis.a</li>
+    <li>libLLVMSupport.a</li>
+    <li>libLLVMTarget.a</li>
+    <li>libLLVMTransformUtils.a</li>
+    <li>LLVMCore.o</li>
+  </ul></dd>
+  <dt><b>LLVMDebugger.o</b</dt><dd><ul>
+    <li>libLLVMSupport.a</li>
+    <li>libLLVMSystem.a</li>
+    <li>LLVMBCReader.o</li>
+    <li>LLVMCodeGen.o</li>
+    <li>LLVMCore.o</li>
+    <li>LLVMExecutionEngine.o</li>
+  </ul></dd>
+  <dt><b>LLVMExecutionEngine.o</b</dt><dd><ul>
+    <li>libLLVMSupport.a</li>
+    <li>libLLVMSystem.a</li>
+    <li>libLLVMTarget.a</li>
+    <li>LLVMCore.o</li>
+    <li>LLVMInterpreter.o</li>
+    <li>LLVMJIT.o</li>
+  </ul></dd>
+  <dt><b>LLVMInstrumentation.o</b</dt><dd><ul>
+    <li>libLLVMSupport.a</li>
+    <li>libLLVMTransformUtils.a</li>
+    <li>LLVMCore.o</li>
+  </ul></dd>
+  <dt><b>LLVMInterpreter.o</b</dt><dd><ul>
+    <li>libLLVMSupport.a</li>
+    <li>libLLVMSystem.a</li>
+    <li>libLLVMTarget.a</li>
+    <li>LLVMCore.o</li>
+    <li>LLVMExecutionEngine.o</li>
+  </ul></dd>
+  <dt><b>LLVMJIT.o</b</dt><dd><ul>
+    <li>libLLVMSupport.a</li>
+    <li>libLLVMSystem.a</li>
+    <li>libLLVMTarget.a</li>
+    <li>LLVMCore.o</li>
+    <li>LLVMExecutionEngine.o</li>
+  </ul></dd>
+  <dt><b>LLVMPowerPC.o</b</dt><dd><ul>
+    <li>libLLVMScalarOpts.a</li>
+    <li>libLLVMSupport.a</li>
+    <li>libLLVMTarget.a</li>
+    <li>LLVMCodeGen.o</li>
+    <li>LLVMCore.o</li>
+  </ul></dd>
+  <dt><b>LLVMProfilePaths.o</b</dt><dd><ul>
+    <li>libLLVMInstrumentation.a</li>
+    <li>libLLVMSupport.a</li>
+    <li>LLVMCore.o</li>
+  </ul></dd>
+  <dt><b>LLVMScalarOpts.o</b</dt><dd><ul>
+    <li>libLLVMAnalysis.a</li>
+    <li>libLLVMSupport.a</li>
+    <li>libLLVMTarget.a</li>
+    <li>libLLVMTransformUtils.a</li>
+    <li>LLVMCore.o</li>
+  </ul></dd>
+  <dt><b>LLVMSelectionDAG.o</b</dt><dd><ul>
+    <li>LLVMCodeGen.o</li>
+    <li>LLVMCore.o</li>
+  </ul></dd>
+  <dt><b>LLVMSkeleton.o</b</dt><dd><ul>
+    <li>libLLVMTarget.a</li>
+    <li>LLVMCodeGen.o</li>
+    <li>LLVMCore.o</li>
+  </ul></dd>
+  <dt><b>LLVMSparcV8.o</b</dt><dd><ul>
+    <li>libLLVMScalarOpts.a</li>
+    <li>libLLVMSupport.a</li>
+    <li>libLLVMTarget.a</li>
+    <li>LLVMCodeGen.o</li>
+    <li>LLVMCore.o</li>
+  </ul></dd>
+  <dt><b>LLVMSparcV9.o</b</dt><dd><ul>
+    <li>libLLVMScalarOpts.a</li>
+    <li>libLLVMSparcV9RegAlloc.a</li>
+    <li>libLLVMSupport.a</li>
+    <li>libLLVMTarget.a</li>
+    <li>LLVMBCWriter.o</li>
+    <li>LLVMCodeGen.o</li>
+    <li>LLVMCore.o</li>
+    <li>LLVMSparcV9InstrSched.o</li>
+    <li>LLVMSparcV9ModuloSched.o</li>
+  </ul></dd>
+  <dt><b>LLVMSparcV9InstrSched.o</b</dt><dd><ul>
+    <li>libLLVMSupport.a</li>
+    <li>LLVMCodeGen.o</li>
+    <li>LLVMCore.o</li>
+    <li>LLVMSparcV9LiveVar.o</li>
+    <li>LLVMSparcV9.o</li>
+  </ul></dd>
+  <dt><b>LLVMSparcV9LiveVar.o</b</dt><dd><ul>
+    <li>libLLVMSupport.a</li>
+    <li>LLVMCodeGen.o</li>
+    <li>LLVMCore.o</li>
+  </ul></dd>
+  <dt><b>LLVMSparcV9ModuloSched.o</b</dt><dd><ul>
+    <li>libLLVMSupport.a</li>
+    <li>libLLVMTarget.a</li>
+    <li>LLVMCodeGen.o</li>
+    <li>LLVMCore.o</li>
+    <li>LLVMSparcV9.o</li>
+  </ul></dd>
+  <dt><b>LLVMSparcV9RegAlloc.o</b</dt><dd><ul>
+    <li>libLLVMAnalysis.a</li>
+    <li>libLLVMSupport.a</li>
+    <li>LLVMCodeGen.o</li>
+    <li>LLVMCore.o</li>
+    <li>LLVMSparcV9LiveVar.o</li>
+    <li>LLVMSparcV9.o</li>
+  </ul></dd>
+  <dt><b>LLVMSupport.o</b</dt><dd><ul>
+    <li>libLLVMSystem.a</li>
+    <li>LLVMbzip2.o</li>
+  </ul></dd>
+  <dt><b>LLVMSystem.o</b</dt><dd></dd>
+  <dt><b>LLVMTarget.o</b</dt><dd><ul>
+    <li>libLLVMSupport.a</li>
+    <li>LLVMCore.o</li>
+  </ul></dd>
+  <dt><b>LLVMTransformUtils.o</b</dt><dd><ul>
+    <li>libLLVMAnalysis.a</li>
+    <li>libLLVMScalarOpts.a</li>
+    <li>libLLVMSupport.a</li>
+    <li>LLVMCore.o</li>
+  </ul></dd>
+  <dt><b>LLVMTransforms.o</b</dt><dd><ul>
+    <li>libLLVMAnalysis.a</li>
+    <li>libLLVMSupport.a</li>
+    <li>libLLVMTarget.a</li>
+    <li>libLLVMTransformUtils.a</li>
+    <li>LLVMCore.o</li>
+  </ul></dd>
+  <dt><b>LLVMX86.o</b</dt><dd><ul>
+    <li>libLLVMScalarOpts.a</li>
+    <li>libLLVMSupport.a</li>
+    <li>libLLVMTarget.a</li>
+    <li>LLVMCodeGen.o</li>
+    <li>LLVMCore.o</li>
+  </ul></dd>
+  <dt><b>LLVMbzip2.o</b</dt><dd></dd>
+  <dt><b>LLVMipa.o</b</dt><dd><ul>
+    <li>libLLVMAnalysis.a</li>
+    <li>libLLVMSupport.a</li>
+    <li>LLVMCore.o</li>
+  </ul></dd>
+  <dt><b>LLVMipo.o</b</dt><dd><ul>
+    <li>libLLVMAnalysis.a</li>
+    <li>libLLVMipa.a</li>
+    <li>libLLVMScalarOpts.a</li>
+    <li>libLLVMSupport.a</li>
+    <li>libLLVMTarget.a</li>
+    <li>libLLVMTransformUtils.a</li>
+    <li>LLVMCore.o</li>
+  </ul></dd>
+</dl>
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_section"><a name="rot">Linkage Rules Of Thumb</a></div>
+<div class="doc_text">
+	<p>This section contains various "rules of thumb" about what files you
+	should link into your programs.</p>
+</div>
+<!-- ======================================================================= -->
+<div class="doc_subsection"><a name="always">Always Link LLVMCore, LLVMSupport,
+    and LLVMSystem</a></div>
+<div class="doc_text">
+  <p>No matter what you do with LLVM, the last three entries in the value of 
+  your LLVMLIBS make variable should always be: 
+  <tt>LLVMCore LLVMSupport.a LLVMSystem.a</tt>. There are no <tt>LLVM</tt> 
+  programs that don't depend on these three.</p>
+</div>
+<!-- ======================================================================= -->
+<div class="doc_subsection"><a name="onlyone">Never link both archive and
+    re-linked library</a></div>
+<div class="doc_text">
+  <p>There is never any point to linking both the re-linked (<tt>.o</tt>) and
+  the archive (<tt>.a</tt>) versions of a library. Since the re-linked version
+  includes the entire library, the archive version will not resolve any symbols.
+  You could even end up with link error if you place the archive version before
+  the re-linked version on the linker's command line.</p>
+</div>
+<!-- ======================================================================= -->
+<hr>
+<div class="doc_footer">
+<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>
+</address>
+<a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a> 
+<br>Last modified: $Date$ </div>
+</body>
+</html>
+<!-- vim: sw=2 ts=2 ai
+-->

llvm/docs/WritingAnLLVMBackend.html

@@ -0,0 +1,260 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+                      "http://www.w3.org/TR/html4/strict.dtd">
+<html>
+<head>
+  <title>Writing an LLVM backend</title>
+  <link rel="stylesheet" href="llvm.css" type="text/css">
+</head>
+
+<body>
+
+<div class="doc_title">
+  Writing an LLVM backend
+</div>
+
+<ol>
+  <li><a href="#intro">Introduction</a>
+  <li><a href="#backends">Writing a backend</a>
+  <ol>
+    <li><a href="#machine">Machine backends</a>
+    <ol>
+      <li><a href="#machineTOC">Outline</a></li>
+      <li><a href="#machineDetails">Implementation details</a></li>
+    </ol></li>  
+    <li><a href="#lang">Language backends</a></li>
+  </ol></li>
+  <li><a href="#related">Related reading material</a>
+</ol>
+
+<div class="doc_author">    
+  <p>Written by <a href="http://misha.brukman.net">Misha Brukman</a></p>
+</div>
+
+<!-- *********************************************************************** -->
+<div class="doc_section">
+  <a name="intro">Introduction</a>
+</div>
+<!-- *********************************************************************** -->
+
+<div class="doc_text">
+
+<p>This document describes techniques for writing backends for LLVM which
+convert the LLVM representation to machine assembly code or other languages.</p>
+
+</div>
+
+<!-- *********************************************************************** -->
+<div class="doc_section">
+  <a name="backends">Writing a backend</a>
+</div>
+<!-- *********************************************************************** -->
+
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+  <a name="machine">Machine backends</a>
+</div>
+    
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+  <a name="machineTOC">Outline</a>
+</div>
+
+<div class="doc_text">
+
+<p>In general, you want to follow the format of X86 or PowerPC (in
+<tt>lib/Target</tt>).</p>
+
+<p>To create a static compiler (one that emits text assembly), you need to
+implement the following:</p>
+
+<ul>
+<li>Describe the register set
+  <ul>
+  <li>Create a <a href="TableGenFundamentals.html">TableGen</a> description of
+      the register set and register classes</li>
+  <li>Implement a subclass of <tt><a
+      href="CodeGenerator.html#mregisterinfo">MRegisterInfo</a></tt></li>
+  </ul></li>
+<li>Describe the instruction set
+  <ul>
+  <li>Create a <a href="TableGenFundamentals.html">TableGen</a> description of
+      the instruction set</li>
+  <li>Implement a subclass of <tt><a
+      href="CodeGenerator.html#targetinstrinfo">TargetInstrInfo</a></tt></li>
+  </ul></li>
+<li>Describe the target machine
+  <ul>
+  <li>Create a <a href="TableGenFundamentals.html">TableGen</a> description of
+      the target that describes the pointer size and references the instruction
+      set</li>
+  <li>Implement a subclass of <tt><a
+      href="CodeGenerator.html#targetmachine">TargetMachine</a></tt>, which
+      configures <tt><a href="CodeGenerator.html#targetdata">TargetData</a></tt>
+      correctly</li>
+  <li>Register your new target using the <tt>RegisterTarget</tt>
+  template:<br><br>
+<div class="doc_code"><pre>
+RegisterTarget&lt;<em>MyTargetMachine</em>&gt; M("short_name", "  Target name");
+</pre></div>
+      <br>Here, <em>MyTargetMachine</em> is the name of your implemented
+      subclass of <tt><a
+      href="CodeGenerator.html#targetmachine">TargetMachine</a></tt>,
+      <em>short_name</em> is the option that will be active following
+      <tt>-march=</tt> to select a target in llc and lli, and the last string
+      is the description of your target to appear in <tt>-help</tt>
+      listing.</li>
+  </ul></li>
+<li>Implement the assembly printer for the architecture.  Usually, if you have
+described the instruction set with the assembly printer generator in mind, that
+step can be almost automated.</li>
+</ul>
+
+<p>You also need to write an instruction selector for your platform.  The
+recommended method is the <a
+href="CodeGenerator.html#instselect">pattern-matching instruction selector</a>,
+examples of which you can see in other targets:
+<tt>lib/Target/*/*ISelPattern.cpp</tt>.  The former method for writing
+instruction selectors (<b>not</b> recommended for new targets) is evident in
+<tt>lib/Target/*/*ISelSimple.cpp</tt>, which are <tt>InstVisitor</tt>-based
+translators, generating code for an LLVM instruction at a time.  Creating an
+instruction selector is perhaps the most time-consuming part of creating a
+back-end.</p>
+
+<p>To create a JIT for your platform:</p>
+
+<ul>
+<li>Create a subclass of <tt><a
+    href="CodeGenerator.html#targetjitinfo">TargetJITInfo</a></tt></li>
+<li>Create a machine code emitter that will be used to emit binary code
+    directly into memory, given <tt>MachineInstr</tt>s</li>
+</ul>
+
+<p>Note that <tt>lib/target/Skeleton</tt> is a clean skeleton for a new target,
+so you might want to start with that and adapt it for your target, and if you
+are wondering how things are done, peek in the X86 or PowerPC target.</p>
+
+<p>The Skeleton target is non-functional but provides the basic building blocks
+you will need for your endeavor.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+  <a name="machineDetails">Implementation details</a>
+</div>
+
+<div class="doc_text">
+
+<ul>
+
+<li><p><b>TableGen register info description</b> - describe a class which
+will store the register's number in the binary encoding of the instruction
+(e.g., for JIT purposes).</p>
+
+<p>You also need to define register classes to contain these registers, such as
+the integer register class and floating-point register class, so that you can
+allocate virtual registers to instructions from these sets, and let the
+target-independent register allocator automatically choose the actual
+architected registers.</p>
+
+<div class="doc_code">
+<pre>
+// class Register is defined in Target.td
+<b>class</b> <em>Target</em>Reg&lt;string name&gt; : Register&lt;name&gt; {
+  <b>let</b> Namespace = "<em>Target</em>";
+}
+
+<b>class</b> IntReg&lt;<b>bits</b>&lt;5&gt; num, string name&gt; : <em>Target</em>Reg&lt;name&gt; {
+  <b>field</b> <b>bits</b>&lt;5&gt; Num = num;
+}
+
+<b>def</b> R0 : IntReg&lt;0, "%R0"&gt;;
+...
+
+// class RegisterClass is defined in Target.td
+<b>def</b> IReg : RegisterClass&lt;i64, 64, [R0, ... ]&gt;;
+</pre>
+</div>
+</li>
+
+<li><p><b>TableGen instruction info description</b> - break up instructions into
+classes, usually that's already done by the manufacturer (see instruction
+manual).  Define a class for each instruction category.  Define each opcode as a
+subclass of the category, with appropriate parameters such as the fixed binary
+encoding of opcodes and extended opcodes, and map the register bits to the bits
+of the instruction which they are encoded in (for the JIT).  Also specify how
+the instruction should be printed so it can use the automatic assembly printer,
+e.g.:</p>
+
+<div class="doc_code">
+<pre>
+// class Instruction is defined in Target.td
+<b>class</b> Form&lt;<b>bits</b>&lt;6&gt; opcode, <b>dag</b> OL, <b>string</b> asmstr&gt; : Instruction {
+  <b>field</b> <b>bits</b>&lt;42&gt; Inst;
+
+  <b>let</b> Namespace = "<em>Target</em>";
+  <b>let</b> Inst{0-6} = opcode;
+  <b>let</b> OperandList = OL;
+  <b>let</b> AsmString = asmstr;
+}
+
+<b>def</b> ADD : Form&lt;42, (ops IReg:$rD, IReg:$rA, IReg:$rB), "add $rD, $rA, $rB"&gt;;
+</pre>
+</div>
+</li>
+
+</ul>
+
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+  <a name="lang">Language backends</a>
+</div>
+
+<div class="doc_text">
+
+<p>For now, just take a look at <tt>lib/Target/CBackend</tt> for an example of
+how the C backend is written.</p>
+
+</div>
+
+<!-- *********************************************************************** -->
+<div class="doc_section">
+  <a name="related">Related reading material</a>
+</div>
+<!-- *********************************************************************** -->
+
+<div class="doc_text">
+
+<ul>
+<li><a href="CodeGenerator.html">Code generator</a> -
+    describes some of the classes in code generation at a high level, but
+    it is not (yet) complete</li>
+<li><a href="TableGenFundamentals.html">TableGen fundamentals</a> -
+    describes how to use TableGen to describe your target information
+    succinctly</li>
+<li><a href="HowToSubmitABug.html#codegen">Debugging code generation with
+    bugpoint</a> - shows bugpoint usage scenarios to simplify backend
+    development</li>
+</ul>
+
+</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://misha.brukman.net">Misha Brukman</a><br>
+  <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
+  <br>
+  Last modified: $Date$
+</address>
+
+</body>
+</html>

llvm/docs/WritingAnLLVMPass.html

@@ -2,6 +2,7 @@
                       "http://www.w3.org/TR/html4/strict.dtd">
 <html>
 <head>
+  <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
   <title>Writing an LLVM Pass</title>
   <link rel="stylesheet" href="llvm.css" type="text/css">
 </head>
@@ -18,14 +19,22 @@
     <li><a href="#makefile">Setting up the build environment</a></li>
     <li><a href="#basiccode">Basic code required</a></li>
     <li><a href="#running">Running a pass with <tt>opt</tt>
-         or <tt>analyze</tt></a></li>
+                 or <tt>analyze</tt></a></li>
     </ul></li>
   <li><a href="#passtype">Pass classes and requirements</a>
      <ul>
      <li><a href="#ImmutablePass">The <tt>ImmutablePass</tt> class</a></li>
-     <li><a href="#Pass">The <tt>Pass</tt> class</a>
+     <li><a href="#ModulePass">The <tt>ModulePass</tt> class</a>
         <ul>
-        <li><a href="#run">The <tt>run</tt> method</a></li>
+        <li><a href="#runOnModule">The <tt>runOnModule</tt> method</a></li>
+        </ul></li>
+     <li><a href="#CallGraphSCCPass">The <tt>CallGraphSCCPass</tt> class</a>
+        <ul>
+        <li><a href="#doInitialization_scc">The <tt>doInitialization(Module
+                                           &amp;)</tt> method</a></li>
+        <li><a href="#runOnSCC">The <tt>runOnSCC</tt> method</a></li>
+        <li><a href="#doFinalization_scc">The <tt>doFinalization(Module
+                                           &amp;)</tt> method</a></li>
         </ul></li>
      <li><a href="#FunctionPass">The <tt>FunctionPass</tt> class</a>
         <ul>
@@ -69,6 +78,7 @@
      <li><a href="#agconcepts">Analysis Group Concepts</a></li>
      <li><a href="#registerag">Using <tt>RegisterAnalysisGroup</tt></a></li>
      </ul></li>
+  <li><a href="#passStatistics">Pass Statistics</a>
   <li><a href="#passmanager">What PassManager does</a>
     <ul>
     <li><a href="#releaseMemory">The <tt>releaseMemory</tt> method</a></li>
@@ -81,8 +91,7 @@
   <li><a href="#future">Future extensions planned</a>
     <ul>
     <li><a href="#SMP">Multithreaded LLVM</a></li>
-    <li><a href="#ModuleSource">A new <tt>ModuleSource</tt> interface</a></li>
-    <li><a href="#PassFunctionPass"><tt>Pass</tt>es requiring 
+    <li><a href="#PassFunctionPass"><tt>ModulePass</tt>es requiring 
                                     <tt>FunctionPass</tt>es</a></li>
     </ul></li>
 </ol>
@@ -100,23 +109,23 @@
 <div class="doc_text">
 
 <p>The LLVM Pass Framework is an important part of the LLVM system, because LLVM
-passes are where the interesting parts of the compiler exist.  Passes perform
-the transformations and optimizations that make up the compiler, they build
-the analysis results that are used by these transformations, and they are, above
-all, a structuring technique for compiler code.</p>
+passes are where most of the interesting parts of the compiler exist.  Passes
+perform the transformations and optimizations that make up the compiler, they
+build the analysis results that are used by these transformations, and they are,
+above all, a structuring technique for compiler code.</p>
 
 <p>All LLVM passes are subclasses of the <tt><a
 href="http://llvm.cs.uiuc.edu/doxygen/classllvm_1_1Pass.html">Pass</a></tt>
 class, which implement functionality by overriding virtual methods inherited
-from <tt>Pass</tt>.  Depending on how your pass works, you may be able to
-inherit from the <tt><a
-href="http://llvm.cs.uiuc.edu/doxygen/structllvm_1_1FunctionPass.html">FunctionPass</a></tt>
-or <tt><a
-href="http://llvm.cs.uiuc.edu/doxygen/structllvm_1_1BasicBlockPass.html">BasicBlockPass</a></tt>,
-which gives the system more information about what your pass does, and how it
-can be combined with other passes.  One of the main features of the LLVM Pass
-Framework is that it schedules passes to run in an efficient way based on the
-constraints that your pass has.</p>
+from <tt>Pass</tt>.  Depending on how your pass works, you should inherit from
+the <tt><a href="#ModulePass">ModulePass</a></tt>, <tt><a
+href="#CallGraphSCCPass">CallGraphSCCPass</a></tt>, <tt><a
+href="#FunctionPass">FunctionPass</a></tt>, or <tt><a
+href="#BasicBlockPass">BasicBlockPass</a></tt> classes, which gives the system
+more information about what your pass does, and how it can be combined with
+other passes.  One of the main features of the LLVM Pass Framework is that it
+schedules passes to run in an efficient way based on the constraints that your
+pass meets (which are indicated by which class they derive from).</p>
 
 <p>We start by showing you how to construct a pass, everything from setting up
 the code, to compiling, loading, and executing it.  After the basics are down,
@@ -134,7 +143,7 @@ more advanced features are discussed.</p>
 
 <p>Here we describe how to write the "hello world" of passes.  The "Hello" pass
 is designed to simply print out the name of non-external functions that exist in
-the program being compiled.  It does not modify the program at all, just
+the program being compiled.  It does not modify the program at all, it just
 inspects it.  The source code and files for this pass are available in the LLVM
 source tree in the <tt>lib/Transforms/Hello</tt> directory.</p>
 
@@ -147,13 +156,12 @@ source tree in the <tt>lib/Transforms/Hello</tt> directory.</p>
 
 <div class="doc_text">
 
-<p>First thing you need to do is create a new directory somewhere in the LLVM
-source base.  For this example, we'll assume that you made
-"<tt>lib/Transforms/Hello</tt>".  The first thing you must do is set up a build
-script (Makefile) that will compile the source code for the new pass.  To do
-this, copy this into "<tt>Makefile</tt>":</p>
-
-<hr>
+  <p>First, you need to create a new directory somewhere in the LLVM source 
+  base.  For this example, we'll assume that you made 
+  <tt>lib/Transforms/Hello</tt>.  Next, you must set up a build script 
+  (Makefile) that will compile the source code for the new pass.  To do this, 
+  copy the following into <tt>Makefile</tt>:</p>
+  <hr/>
 
 <pre>
 # Makefile for hello pass
@@ -162,21 +170,25 @@ this, copy this into "<tt>Makefile</tt>":</p>
 LEVEL = ../../..
 
 # Name of the library to build
-LIBRARYNAME = hello
+LIBRARYNAME = Hello
 
-# Build a dynamically loadable shared object
+# Build a dynamically linkable shared object
 SHARED_LIBRARY = 1
 
+# Make the shared library become a loadable module so the tools can 
+# dlopen/dlsym on the resulting library.
+LOADABLE_MODULE
+
 # Include the makefile implementation stuff
 include $(LEVEL)/Makefile.common
 </pre>
 
 <p>This makefile specifies that all of the <tt>.cpp</tt> files in the current
 directory are to be compiled and linked together into a
-<tt>lib/Debug/libhello.so</tt> shared object that can be dynamically loaded by
-the <tt>opt</tt> or <tt>analyze</tt> tools.  If your operating system uses a
-suffix other than .so (such as windows of Mac OS/X), the appropriate extension
-will be used.</p>
+<tt>Debug/lib/Hello.so</tt> shared object that can be dynamically loaded by
+the <tt>opt</tt> or <tt>analyze</tt> tools via their <tt>-load</tt> options.  
+If your operating system uses a suffix other than .so (such as windows or 
+Mac OS/X), the appropriate extension will be used.</p>
 
 <p>Now that we have the build scripts set up, we just need to write the code for
 the pass itself.</p>
@@ -230,7 +242,7 @@ information.</p>
 </pre><p>
 
 <p>This declares a "<tt>Hello</tt>" class that is a subclass of <tt><a
-href="http://llvm.cs.uiuc.edu/doxygen/structllvm_1_1FunctionPass.html">FunctionPass</a></tt>.
+href="http://llvm.cs.uiuc.edu/doxygen/classllvm_1_1FunctionPass.html">FunctionPass</a></tt>.
 The different builtin pass subclasses are described in detail <a
 href="#passtype">later</a>, but for now, know that <a
 href="#FunctionPass"><tt>FunctionPass</tt></a>'s operate a function at a
@@ -283,7 +295,7 @@ depending on what it is to be used for.  For "optimizations" we use the
 
 <p>Now that it's all together, compile the file with a simple "<tt>gmake</tt>"
 command in the local directory and you should get a new
-"<tt>lib/Debug/libhello.so</tt> file.  Note that everything in this file is
+"<tt>Debug/lib/Hello.so</tt> file.  Note that everything in this file is
 contained in an anonymous namespace: this reflects the fact that passes are self
 contained units that do not need external interfaces (although they can have
 them) to be useful.</p>
@@ -309,7 +321,7 @@ through our transformation like this (or course, any bytecode file will
 work):</p>
 
 <pre>
-$ opt -load ../../../lib/Debug/libhello.so -hello &lt; hello.bc &gt; /dev/null
+$ opt -load ../../../Debug/lib/Hello.so -hello &lt; hello.bc &gt; /dev/null
 Hello: __main
 Hello: puts
 Hello: main
@@ -326,7 +338,7 @@ interesting way, we just throw away the result of <tt>opt</tt> (sending it to
 <tt>opt</tt> with the <tt>--help</tt> option:</p>
 
 <pre>
-$ opt -load ../../../lib/Debug/libhello.so --help
+$ opt -load ../../../Debug/lib/Hello.so --help
 OVERVIEW: llvm .bc -&gt; .bc modular optimizer
 
 USAGE: opt [options] &lt;input bytecode&gt;
@@ -354,7 +366,7 @@ the execution time of your pass along with the other passes you queue up.  For
 example:</p>
 
 <pre>
-$ opt -load ../../../lib/Debug/libhello.so -hello -time-passes &lt; hello.bc &gt; /dev/null
+$ opt -load ../../../Debug/lib/Hello.so -hello -time-passes &lt; hello.bc &gt; /dev/null
 Hello: __main
 Hello: puts
 Hello: main
@@ -412,7 +424,7 @@ slow.</p>
 <div class="doc_text">
 
 <p>The most plain and boring type of pass is the "<tt><a
-href="http://llvm.cs.uiuc.edu/doxygen/structllvm_1_1ImmutablePass.html">ImmutablePass</a></tt>"
+href="http://llvm.cs.uiuc.edu/doxygen/classllvm_1_1ImmutablePass.html">ImmutablePass</a></tt>"
 class.  This pass type is used for passes that do not have to be run, do not
 change state, and never need to be updated.  This is not a normal type of
 transformation or analysis, but can provide information about the current
@@ -429,41 +441,150 @@ invalidated, and are never "run".</p>
 
 <!-- ======================================================================= -->
 <div class="doc_subsection">
-  <a name="Pass">The <tt>Pass</tt> class</a>
+  <a name="ModulePass">The <tt>ModulePass</tt> class</a>
 </div>
 
 <div class="doc_text">
 
 <p>The "<tt><a
-href="http://llvm.cs.uiuc.edu/doxygen/classllvm_1_1Pass.html">Pass</a></tt>"
+href="http://llvm.cs.uiuc.edu/doxygen/classllvm_1_1ModulePass.html">ModulePass</a></tt>"
 class is the most general of all superclasses that you can use.  Deriving from
-<tt>Pass</tt> indicates that your pass uses the entire program as a unit,
+<tt>ModulePass</tt> indicates that your pass uses the entire program as a unit,
 refering to function bodies in no predictable order, or adding and removing
-functions.  Because nothing is known about the behavior of direct <tt>Pass</tt>
+functions.  Because nothing is known about the behavior of <tt>ModulePass</tt>
 subclasses, no optimization can be done for their execution.</p>
 
-<p>To write a correct <tt>Pass</tt> subclass, derive from <tt>Pass</tt> and
-overload the <tt>run</tt> method with the following signature:</p>
+<p>To write a correct <tt>ModulePass</tt> subclass, derive from
+<tt>ModulePass</tt> and overload the <tt>runOnModule</tt> method with the
+following signature:</p>
 
 </div>
 
 <!-- _______________________________________________________________________ -->
 <div class="doc_subsubsection">
-  <a name="run">The <tt>run</tt> method</a>
+  <a name="runOnModule">The <tt>runOnModule</tt> method</a>
 </div>
 
 <div class="doc_text">
 
 <pre>
-  <b>virtual bool</b> run(Module &amp;M) = 0;
+  <b>virtual bool</b> runOnModule(Module &amp;M) = 0;
 </pre>
 
-<p>The <tt>run</tt> method performs the interesting work of the pass, and should
-return true if the module was modified by the transformation, false
+<p>The <tt>runOnModule</tt> method performs the interesting work of the pass,
+and should return true if the module was modified by the transformation, false
 otherwise.</p>
 
 </div>
 
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+  <a name="CallGraphSCCPass">The <tt>CallGraphSCCPass</tt> class</a>
+</div>
+
+<div class="doc_text">
+
+<p>The "<tt><a
+href="http://llvm.cs.uiuc.edu/doxygen/classllvm_1_1CallGraphSCCPass.html">CallGraphSCCPass</a></tt>"
+is used by passes that need to traverse the program bottom-up on the call graph
+(callees before callers).  Deriving from CallGraphSCCPass provides some
+mechanics for building and traversing the CallGraph, but also allows the system
+to optimize execution of CallGraphSCCPass's.  If your pass meets the
+requirements outlined below, and doesn't meet the requirements of a <tt><a
+href="#FunctionPass">FunctionPass</a></tt> or <tt><a
+href="#BasicBlockPass">BasicBlockPass</a></tt>, you should derive from
+<tt>CallGraphSCCPass</tt>.</p>
+
+<p><b>TODO</b>: explain briefly what SCC, Tarjan's algo, and B-U mean.</p>
+
+<p>To be explicit, <tt>CallGraphSCCPass</tt> subclasses are:</p>
+
+<ol>
+
+<li>... <em>not allowed</em> to modify any <tt>Function</tt>s that are not in
+the current SCC.</li>
+
+<li>... <em>allowed</em> to inspect any Function's other than those in the
+current SCC and the direct callees of the SCC.</li>
+
+<li>... <em>required</em> to preserve the current CallGraph object, updating it
+to reflect any changes made to the program.</li>
+
+<li>... <em>not allowed</em> to add or remove SCC's from the current Module,
+though they may change the contents of an SCC.</li>
+
+<li>... <em>allowed</em> to add or remove global variables from the current
+Module.</li>
+
+<li>... <em>allowed</em> to maintain state across invocations of
+    <a href="#runOnSCC"><tt>runOnSCC</tt></a> (including global data).</li>
+</ol>
+
+<p>Implementing a <tt>CallGraphSCCPass</tt> is slightly tricky in some cases
+because it has to handle SCCs with more than one node in it.  All of the virtual
+methods described below should return true if they modified the program, or
+false if they didn't.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+  <a name="doInitialization_scc">The <tt>doInitialization(Module &amp;)</tt>
+  method</a>
+</div>
+
+<div class="doc_text">
+
+<pre>
+  <b>virtual bool</b> doInitialization(Module &amp;M);
+</pre>
+
+<p>The <tt>doIninitialize</tt> method is allowed to do most of the things that
+<tt>CallGraphSCCPass</tt>'s are not allowed to do.  They can add and remove
+functions, get pointers to functions, etc.  The <tt>doInitialization</tt> method
+is designed to do simple initialization type of stuff that does not depend on
+the SCCs being processed.  The <tt>doInitialization</tt> method call is not
+scheduled to overlap with any other pass executions (thus it should be very
+fast).</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+  <a name="runOnSCC">The <tt>runOnSCC</tt> method</a>
+</div>
+
+<div class="doc_text">
+
+<pre>
+  <b>virtual bool</b> runOnSCC(const std::vector&lt;CallGraphNode *&gt; &amp;SCCM) = 0;
+</pre>
+
+<p>The <tt>runOnSCC</tt> method performs the interesting work of the pass, and
+should return true if the module was modified by the transformation, false
+otherwise.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+  <a name="doFinalization_scc">The <tt>doFinalization(Module
+   &amp;)</tt> method</a>
+</div>
+
+<div class="doc_text">
+
+<pre>
+  <b>virtual bool</b> doFinalization(Module &amp;M);
+</pre>
+
+<p>The <tt>doFinalization</tt> method is an infrequently used method that is
+called when the pass framework has finished calling <a
+href="#runOnFunction"><tt>runOnFunction</tt></a> for every function in the
+program being compiled.</p>
+
+</div>
+
 <!-- ======================================================================= -->
 <div class="doc_subsection">
   <a name="FunctionPass">The <tt>FunctionPass</tt> class</a>
@@ -471,7 +592,7 @@ otherwise.</p>
 
 <div class="doc_text">
 
-<p>In contrast to direct <tt>Pass</tt> subclasses, direct <tt><a
+<p>In contrast to <tt>ModulePass</tt> subclasses, <tt><a
 href="http://llvm.cs.uiuc.edu/doxygen/classllvm_1_1Pass.html">FunctionPass</a></tt>
 subclasses do have a predictable, local behavior that can be expected by the
 system.  All <tt>FunctionPass</tt> execute on each function in the program
@@ -577,8 +698,8 @@ As such, they are <b>not</b> allowed to do any of the following:</p>
 <li>Modify or inspect any basic blocks outside of the current one</li>
 <li>Maintain state across invocations of
     <a href="#runOnBasicBlock"><tt>runOnBasicBlock</tt></a></li>
-<li>Modify the constrol flow graph (by altering terminator instructions)</li>
-<li>Any of the things verboten for
+<li>Modify the control flow graph (by altering terminator instructions)</li>
+<li>Any of the things forbidden for
     <a href="#FunctionPass"><tt>FunctionPass</tt></a>es.</li>
 </ol>
 
@@ -605,7 +726,7 @@ href="#FunctionPass"><tt>FunctionPass</tt></a>'s have, but also have the followi
 <p>The <tt>doIninitialize</tt> method is allowed to do most of the things that
 <tt>BasicBlockPass</tt>'s are not allowed to do, but that
 <tt>FunctionPass</tt>'s can.  The <tt>doInitialization</tt> method is designed
-to do simple initialization type of stuff that does not depend on the
+to do simple initialization that does not depend on the
 BasicBlocks being processed.  The <tt>doInitialization</tt> method call is not
 scheduled to overlap with any other pass executions (thus it should be very
 fast).</p>
@@ -826,11 +947,11 @@ object:</p>
 
 <div class="doc_text">
 <p>
-If you pass requires a previous pass to be executed (an analysis for example),
+If your pass requires a previous pass to be executed (an analysis for example),
 it can use one of these methods to arrange for it to be run before your pass.
 LLVM has many different types of analyses and passes that can be required,
-spaning the range from <tt>DominatorSet</tt> to <tt>BreakCriticalEdges</tt>.
-requiring <tt>BreakCriticalEdges</tt>, for example, guarantees that there will
+spanning the range from <tt>DominatorSet</tt> to <tt>BreakCriticalEdges</tt>.
+Requiring <tt>BreakCriticalEdges</tt>, for example, guarantees that there will
 be no critical edges in the CFG when your pass has been run.
 </p>
 
@@ -856,7 +977,7 @@ One of the jobs of the PassManager is to optimize how and when analyses are run.
 In particular, it attempts to avoid recomputing data unless it needs to.  For
 this reason, passes are allowed to declare that they preserve (i.e., they don't
 invalidate) an existing analysis if it's available.  For example, a simple
-constant folding pass would not modify the CFG, so it can't possible effect the
+constant folding pass would not modify the CFG, so it can't possibly affect the
 results of dominator analysis.  By default, all passes are assumed to invalidate
 all others.
 </p>
@@ -890,9 +1011,9 @@ the fact that it hacks on the CFG.
 <pre>
   <i>// This is an example implementation from an analysis, which does not modify
   // the program at all, yet has a prerequisite.</i>
-  <b>void</b> <a href="http://llvm.cs.uiuc.edu/doxygen/structllvm_1_1PostDominanceFrontier.html">PostDominanceFrontier</a>::getAnalysisUsage(AnalysisUsage &amp;AU) <b>const</b> {
+  <b>void</b> <a href="http://llvm.cs.uiuc.edu/doxygen/classllvm_1_1PostDominanceFrontier.html">PostDominanceFrontier</a>::getAnalysisUsage(AnalysisUsage &amp;AU) <b>const</b> {
     AU.setPreservesAll();
-    AU.addRequired&lt;<a href="http://llvm.cs.uiuc.edu/doxygen/structllvm_1_1PostDominatorTree.html">PostDominatorTree</a>&gt;();
+    AU.addRequired&lt;<a href="http://llvm.cs.uiuc.edu/doxygen/classllvm_1_1PostDominatorTree.html">PostDominatorTree</a>&gt;();
   }
 </pre>
 
@@ -1087,6 +1208,23 @@ pass is the default implementation for the interface.</p>
 
 </div>
 
+<!-- *********************************************************************** -->
+<div class="doc_section">
+  <a name="passStatistics">Pass Statistics</a>
+</div>
+<!-- *********************************************************************** -->
+
+<div class="doc_text">
+<p>The <a
+href="http://llvm.cs.uiuc.edu/doxygen/Statistic_8h-source.html"><tt>Statistic</tt></a>
+class, is designed to be an easy way to expose various success
+metrics from passes.  These statistics are printed at the end of a
+run, when the -stats command line option is enabled on the command
+line. See the <a href="http://llvm.org/docs/ProgrammersManual.html#Statistic">Statistics section</a> in the Programmer's Manual for details. 
+
+</div>
+
+
 <!-- *********************************************************************** -->
 <div class="doc_section">
   <a name="passmanager">What PassManager does</a>
@@ -1129,7 +1267,7 @@ etc... until the entire program has been run through the passes.
 the LLVM program representation for a single function at a time, instead of
 traversing the entire program.  It reduces the memory consumption of compiler,
 because, for example, only one <a
-href="http://llvm.cs.uiuc.edu/doxygen/structllvm_1_1DominatorSet.html"><tt>DominatorSet</tt></a>
+href="http://llvm.cs.uiuc.edu/doxygen/classllvm_1_1DominatorSet.html"><tt>DominatorSet</tt></a>
 needs to be calculated at a time.  This also makes it possible some <a
 href="#SMP">interesting enhancements</a> in the future.</p></li>
 
@@ -1153,7 +1291,7 @@ how our <a href="#basiccode">Hello World</a> pass interacts with other passes.
 Lets try it out with the <tt>gcse</tt> and <tt>licm</tt> passes:</p>
 
 <pre>
-$ opt -load ../../../lib/Debug/libhello.so -gcse -licm --debug-pass=Structure &lt; hello.bc &gt; /dev/null
+$ opt -load ../../../Debug/lib/Hello.so -gcse -licm --debug-pass=Structure &lt; hello.bc &gt; /dev/null
 Module Pass Manager
   Function Pass Manager
     Dominator Set Construction
@@ -1190,7 +1328,7 @@ passes.</p>
 World</a> pass in between the two passes:</p>
 
 <pre>
-$ opt -load ../../../lib/Debug/libhello.so -gcse -hello -licm --debug-pass=Structure &lt; hello.bc &gt; /dev/null
+$ opt -load ../../../Debug/lib/Hello.so -gcse -hello -licm --debug-pass=Structure &lt; hello.bc &gt; /dev/null
 Module Pass Manager
   Function Pass Manager
     Dominator Set Construction
@@ -1231,7 +1369,7 @@ href="#getAnalysisUsage"><tt>getAnalysisUsage</tt></a> method to our pass:</p>
 <p>Now when we run our pass, we get this output:</p>
 
 <pre>
-$ opt -load ../../../lib/Debug/libhello.so -gcse -hello -licm --debug-pass=Structure &lt; hello.bc &gt; /dev/null
+$ opt -load ../../../Debug/lib/Hello.so -gcse -hello -licm --debug-pass=Structure &lt; hello.bc &gt; /dev/null
 Pass Arguments:  -gcse -hello -licm
 Module Pass Manager
   Function Pass Manager
@@ -1339,8 +1477,8 @@ want:</p>
 <pre>
 (gdb) <b>break PassManager::run</b>
 Breakpoint 1 at 0x2413bc: file Pass.cpp, line 70.
-(gdb) <b>run test.bc -load $(LLVMTOP)/llvm/lib/Debug/[libname].so -[passoption]</b>
-Starting program: opt test.bc -load $(LLVMTOP)/llvm/lib/Debug/[libname].so -[passoption]
+(gdb) <b>run test.bc -load $(LLVMTOP)/llvm/Debug/lib/[libname].so -[passoption]</b>
+Starting program: opt test.bc -load $(LLVMTOP)/llvm/Debug/lib/[libname].so -[passoption]
 Breakpoint 1, PassManager::run (this=0xffbef174, M=@0x70b298) at Pass.cpp:70
 70      bool PassManager::run(Module &amp;M) { return PM-&gt;run(M); }
 (gdb)
@@ -1424,50 +1562,24 @@ Despite that, we have kept the LLVM passes SMP ready, and you should too.</p>
 
 <!-- _______________________________________________________________________ -->
 <div class="doc_subsubsection">
-  <a name="ModuleSource">A new <tt>ModuleSource</tt> interface</a>
+<a name="PassFunctionPass"><tt>ModulePass</tt>es requiring <tt>FunctionPass</tt>es</a>
 </div>
 
 <div class="doc_text">
 
-<p>Currently, the <tt>PassManager</tt>'s <tt>run</tt> method takes a <tt><a
-href="http://llvm.cs.uiuc.edu/doxygen/classllvm_1_1Module.html">Module</a></tt>
-as input, and runs all of the passes on this module.  The problem with this
-approach is that none of the <tt>PassManager</tt> features can be used for
-timing and debugging the actual <b>loading</b> of the module from disk or
-standard input.</p>
-
-<p>To solve this problem, eventually the <tt>PassManager</tt> class will accept
-a <tt>ModuleSource</tt> object instead of a Module itself.  When complete, this
-will also allow for streaming of functions out of the bytecode representation,
-allowing us to avoid holding the entire program in memory at once if we only are
-dealing with <a href="#FunctionPass">FunctionPass</a>es.</p>
-
-<p>As part of a different issue, eventually the bytecode loader will be extended
-to allow on-demand loading of functions from the bytecode representation, in
-order to better support the runtime reoptimizer.  The bytecode format is already
-capable of this, the loader just needs to be reworked a bit.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
-<a name="PassFunctionPass"><tt>Pass</tt>es requiring <tt>FunctionPass</tt>es</a>
-</div>
-
-<div class="doc_text">
-
-<p>Currently it is illegal for a <a href="#Pass"><tt>Pass</tt></a> to require a
-<a href="#FunctionPass"><tt>FunctionPass</tt></a>.  This is because there is
-only one instance of the <a href="#FunctionPass"><tt>FunctionPass</tt></a>
-object ever created, thus nowhere to store information for all of the functions
-in the program at the same time.  Although this has come up a couple of times
-before, this has always been worked around by factoring one big complicated pass
-into a global and an interprocedural part, both of which are distinct.  In the
-future, it would be nice to have this though.</p>
+<p>Currently it is illegal for a <a href="#ModulePass"><tt>ModulePass</tt></a>
+to require a <a href="#FunctionPass"><tt>FunctionPass</tt></a>.  This is because
+there is only one instance of the <a
+href="#FunctionPass"><tt>FunctionPass</tt></a> object ever created, thus nowhere
+to store information for all of the functions in the program at the same time.
+Although this has come up a couple of times before, this has always been worked
+around by factoring one big complicated pass into a global and an
+interprocedural part, both of which are distinct.  In the future, it would be
+nice to have this though.</p>
 
 <p>Note that it is no problem for a <a
 href="#FunctionPass"><tt>FunctionPass</tt></a> to require the results of a <a
-href="#Pass"><tt>Pass</tt></a>, only the other way around.</p>
+href="#ModulePass"><tt>ModulePass</tt></a>, only the other way around.</p>
 
 </div>
 

llvm/docs/doxygen.cfg.in

@@ -23,14 +23,14 @@ PROJECT_NAME           = LLVM
 # This could be handy for archiving the generated documentation or 
 # if some version control system is used.
 
-PROJECT_NUMBER         = 
+PROJECT_NUMBER         = @PACKAGE_VERSION@
 
 # The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) 
 # base path where the generated documentation will be put. 
 # If a relative path is entered, it will be relative to the location 
 # where doxygen was started. If left blank the current directory will be used.
 
-OUTPUT_DIRECTORY       = doxygen
+OUTPUT_DIRECTORY       = @abs_top_builddir@/docs/doxygen
 
 # The OUTPUT_LANGUAGE tag is used to specify the language in which all 
 # documentation generated by doxygen is written. Doxygen will use this 
@@ -88,7 +88,7 @@ HIDE_UNDOC_CLASSES     = NO
 BRIEF_MEMBER_DESC      = YES
 
 # If the REPEAT_BRIEF tag is set to YES (the default) Doxygen will prepend 
-# the brief description of a member or function before the detailed description. 
+# the brief description of a member or function before the detailed description.
 # Note: if both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the 
 # brief descriptions will be completely suppressed.
 
@@ -301,7 +301,7 @@ WARN_LOGFILE           =
 # directories like "/usr/src/myproject". Separate the files or directories with
 # spaces.
 
-INPUT                  = .. ./doxygen.intro
+INPUT                  = @abs_top_srcdir@/include @abs_top_srcdir@/lib @abs_top_srcdir@/docs/doxygen.intro
 
 # If the value of the INPUT tag contains directories, you can use the 
 # FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp 
@@ -318,11 +318,11 @@ FILE_PATTERNS          =
 
 RECURSIVE              = YES
 
-# The EXCLUDE tag can be used to specify files and/or directories that should 
+# The EXCLUDE tag can be u sed to specify files and/or directories that should 
 # excluded from the INPUT source files. This way you can easily exclude a 
 # subdirectory from a directory tree whose root is specified with the INPUT tag.
 
-EXCLUDE                =  ../test ../include/boost
+EXCLUDE                = 
 
 # If the value of the INPUT tag contains directories, you can use the 
 # EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude 
@@ -334,7 +334,7 @@ EXCLUDE_PATTERNS       =
 # directories that contain example code fragments that are included (see 
 # the \include command).
 
-EXAMPLE_PATH           = 
+EXAMPLE_PATH           = @abs_top_srcdir@/examples
 
 # If the value of the EXAMPLE_PATH tag contains directories, you can use the 
 # EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp 
@@ -348,13 +348,13 @@ EXAMPLE_PATTERNS       =
 # commands irrespective of the value of the RECURSIVE tag. 
 # Possible values are YES and NO. If left blank NO is used.
 
-EXAMPLE_RECURSIVE      = NO
+EXAMPLE_RECURSIVE      = YES
 
 # The IMAGE_PATH tag can be used to specify one or more files or 
 # directories that contain image that are included in the documentation (see 
 # the \image command).
 
-IMAGE_PATH             = 
+IMAGE_PATH             = @abs_top_srcdir@/docs/img
 
 # The INPUT_FILTER tag can be used to specify a program that doxygen should 
 # invoke to filter for each input file. Doxygen will invoke the filter program 
@@ -418,7 +418,7 @@ COLS_IN_ALPHA_INDEX    = 4
 # The IGNORE_PREFIX tag can be used to specify one or more prefixes that 
 # should be ignored while generating the index headers.
 
-IGNORE_PREFIX          = 
+IGNORE_PREFIX          = llvm::
 
 #---------------------------------------------------------------------------
 # configuration options related to the HTML output
@@ -433,26 +433,26 @@ GENERATE_HTML          = YES
 # If a relative path is entered the value of OUTPUT_DIRECTORY will be 
 # put in front of it. If left blank `html' will be used as the default path.
 
-HTML_OUTPUT            = .
+HTML_OUTPUT            = html
 
 # The HTML_HEADER tag can be used to specify a personal HTML header for 
 # each generated HTML page. If it is left blank doxygen will generate a 
 # standard header.
 
-HTML_HEADER            = doxygen.header
+HTML_HEADER            = @abs_top_srcdir@/docs/doxygen.header
 
 # The HTML_FOOTER tag can be used to specify a personal HTML footer for 
 # each generated HTML page. If it is left blank doxygen will generate a 
 # standard footer.
 
-HTML_FOOTER            = doxygen.footer
+HTML_FOOTER            = @abs_top_srcdir@/docs/doxygen.footer
 
 # The HTML_STYLESHEET tag can be used to specify a user defined cascading 
 # style sheet that is used by each HTML page. It can be used to 
 # fine-tune the look of the HTML output. If the tag is left blank doxygen 
 # will generate a default style sheet
 
-HTML_STYLESHEET        = doxygen.css
+HTML_STYLESHEET        = @abs_top_srcdir@/docs/doxygen.css
 
 # If the HTML_ALIGN_MEMBERS tag is set to YES, the members of classes, 
 # files or namespaces will be aligned in HTML using tables. If set to 
@@ -536,7 +536,7 @@ COMPACT_LATEX          = NO
 # by the printer. Possible values are: a4, a4wide, letter, legal and 
 # executive. If left blank a4wide will be used.
 
-PAPER_TYPE             = a4wide
+PAPER_TYPE             = letter
 
 # The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX 
 # packages that should be included in the LaTeX output.
@@ -817,7 +817,7 @@ GRAPHICAL_HIERARCHY    = YES
 # The tag DOT_PATH can be used to specify the path where the dot tool can be 
 # found. If left blank, it is assumed the dot tool can be found on the path.
 
-DOT_PATH               =
+DOT_PATH               = @DOT@
 
 # The DOTFILE_DIRS tag can be used to specify one or more directories that 
 # contain dot files that are included in the documentation (see the 

llvm/docs/doxygen.intro

@@ -1,14 +1,7 @@
-////////////////////////////////////////////////////////////////////////////////
-/// @file doxygen.intro
-/// @author Reid Spencer <rspencer@x10sys.com> 
-/// @date 2003/12/30
-/// @brief LLVM API documentation introduction.
-////////////////////////////////////////////////////////////////////////////////
-///
-/// @mainpage LLVM:Low Level Virtual Machine
+/// @mainpage Low Level Virtual Machine
 ///
 /// @section main_intro Introduction
-/// Welcome to the Low Level Virtual Machine (LLVM)
+/// Welcome to the Low Level Virtual Machine (LLVM).
 ///
 /// This documentation describes the @b internal software that makes 
 /// up LLVM, not the @b external use of  LLVM. There are no instructions