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

@@ -17,12 +17,7 @@ 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
@@ -39,6 +34,8 @@ 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
@@ -52,7 +49,7 @@ 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
 
@@ -76,6 +73,22 @@ 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
@@ -105,6 +118,10 @@ E: rspencer@x10sys.com
 W: http://llvm.x10sys.com/rspencer
 D: Stacker, llvmc, bytecode, other. See web page for current notes.
 
+N: Adam Treat
+E: manyoso@yahoo.com
+D: C++ bugs filed, and C++ front-end bug fixes.
+
 N: Bill Wendling
 E: wendling@isanbard.org
 D: The `Lower Setjmp/Longjmp' pass, improvements to the -lowerswitch pass.

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:
@@ -64,9 +64,9 @@ Program             Directory
 System Library      llvm/lib/System
 Compiler Driver     llvm/tools/llvmc
 PowerPC Backend     llvm/lib/Target/PowerPC
-bzip2:              llvm/lib/Support/bzip2/LICENSE 
-Autoconf:           llvm/autoconf
+bzip2               llvm/lib/Support/bzip2/LICENSE 
+Autoconf            llvm/autoconf
                     llvm/projects/ModuleMaker/autoconf
                     llvm/projects/sample/autoconf
-Burg:               llvm/utils/Burg
-GNU Libc:           llvm/runtime/GCCLibraries/libc
+Burg                llvm/utils/Burg
+GNU Libc            llvm/runtime/GCCLibraries/libc

llvm/Makefile

@@ -41,7 +41,4 @@ dist-hook::
 	  $(TopDistDir)/include/llvm/Support/DataTypes.h  \
 	  $(TopDistDir)/include/llvm/Support/ThreadSupport.h
 
-check : 
-	$(MAKE) -C test check TESTSUITE=$(TESTSUITE)
-
 tools-only: all

llvm/Makefile.common

@@ -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,20 +12,84 @@
 #
 #===------------------------------------------------------------------------===#
 
-# Define LLVM speific info and directories
-PACKAGE_NAME      := @PACKAGE_NAME@
-PACKAGE_VERSION   := @PACKAGE_VERSION@
-LLVM_PREFIX       := @LLVM_PREFIX@
-LLVM_BINDIR       := @LLVM_BINDIR@
-LLVM_LIBDIR       := @LLVM_LIBDIR@
-LLVM_DATADIR      := @LLVM_DATADIR@
-LLVM_DOCSDIR      := @LLVM_DOCSDIR@
-LLVM_ETCDIR       := @LLVM_ETCDIR@
-LLVM_INCLUDEDIR   := @LLVM_INCLUDEDIR@
-LLVM_INFODIR      := @LLVM_INFODIR@
-LLVM_MANDIR       := @LLVM_MANDIR@
+# Define LLVM specific info and directories based on the autoconf variables
+LLVMPackageName   := @PACKAGE_NAME@
+LLVMVersion       := @PACKAGE_VERSION@
 LLVM_CONFIGTIME   := @LLVM_CONFIGTIME@
-LLVM_TARBALL_NAME := @PACKAGE_NAME@-@PACKAGE_VERSION@
+
+###########################################################################
+# 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@
@@ -36,6 +100,9 @@ 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@
 
@@ -49,26 +116,20 @@ CC := @CC@
 # Linker flags.
 LDFLAGS+=@LDFLAGS@
 
-# Libraries needed by tools
-TOOLLINKOPTS=@LIBS@
-
 # Path to the library archiver program.
 AR_PATH = @AR@
 
 # 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@
-INSTALL_SH := $(BUILD_SRC_ROOT)/autoconf/install-sh
-INSTALL_PROGRAM = @INSTALL_PROGRAM@
-INSTALL_SCRIPT = @INSTALL_SCRIPT@
-INSTALL_DATA = @INSTALL_DATA@
-MKDIR      := @abs_top_srcdir@/autoconf/mkinstalldirs
+MKDIR      := $(LLVM_SRC_ROOT)/autoconf/mkinstalldirs
 MV         := @MV@
-PAX        := @PAX@
 RANLIB     := @RANLIB@
 RM         := @RM@
 SED        := @SED@
@@ -85,30 +146,30 @@ GROFF      := @GROFF@
 GZIP       := @GZIP@
 POD2HTML   := @POD2HTML@
 POD2MAN    := @POD2MAN@
-PYTHON     := @PYTHON@
 RUNTEST    := @RUNTEST@
 TCLSH      := @TCLSH@
 ZIP        := @ZIP@
 
-# Paths to miscellaneous programs we assume are present
-RPWD       := pwd
-ECHO       := echo
+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@
+
 # 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@
+LLVMGCC  := @LLVMGCC@
+LLVMGXX  := @LLVMGXX@
+LLVMCC1  := @LLVMCC1@
+LLVMCC1PLUS := @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 := .
 
-# 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@
-
 # These are options that can either be enabled here, or can be enabled on the
 # make command line (ie, make ENABLE_PROFILING=1):
 
@@ -137,72 +198,5 @@ 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
-
-# Installation directories, as provided by the configure script.
-abs_top_srcdir = @abs_top_srcdir@
-abs_top_builddir = @abs_top_builddir@
-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@
+# Things we just assume are "there"
+ECHO := echo

llvm/autoconf/.cvsignore

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

llvm/autoconf/AutoRegen.sh

@@ -3,17 +3,8 @@ die () {
 	echo "$@" 1>&2
 	exit 1
 }
-if test "$1" = --with-automake ; then
-  outfile=configure_am
-  configfile=configure.am
-  with_automake=1
-elif test -z "$1" ; then
 outfile=configure
 configfile=configure.ac
-  with_automake=0
-else
-  die "Invalid option: $1"
-fi
 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

llvm/autoconf/README.TXT

@@ -8,20 +8,21 @@ If you are in the mood to upgrade libtool, you must do the following:
  3. Copy <SRC>/ltdl.m4 to llvm/autoconf/m4
  4. Copy <PFX>/share/aclocal/libtool.m4 to llvm/autoconf/m4/libtool.m4
  5. Copy <PFX>/share/libtool/ltmain.sh to llvm/autoconf/ltmain.sh
- 6. Copy <PFX>/share/libtool/libltdl/ltdl.c to llvm/lib/System
- 7. Copy <PFX>/share/libtool/libltdl/ltdl.h to llvm/lib/System
- 8. Adjust the llvm/autoconf/m4/libtool.m4 file to ensure that the variable
+ 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"
- 9. Run "autoupdate libtool.m4 ltdl.m4" in the llvm/autoconf/m4 directory.
+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.
-10. Run AutoRegen.sh to get the new macros into configure script
-11. If there are any warnings from configure, go to step 9.
-12. Rebuild LLVM, making sure it reconfigured
-13. Test the JIT which uses libltdl
-14. If it all works, only THEN commit the changes.
+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
 ===============================================================================

llvm/autoconf/configure.ac

@@ -31,11 +31,11 @@ dnl===
 dnl===-----------------------------------------------------------------------===
 dnl Initialize autoconf and define the package name, version number and
 dnl email address for reporting bugs.
-AC_INIT([[llvm]],[[1.4]],[llvmbugs@cs.uiuc.edu])
+AC_INIT([[llvm]],[[1.5]],[llvmbugs@cs.uiuc.edu])
 
 dnl Provide a copyright substitution and ensure the copyright notice is included
 dnl in the output of --version option of the generated configure script.
-AC_SUBST(LLVM_COPYRIGHT,["Copyright (c) 2003-2005 U University of Illinois at Urbana-Champaign."])
+AC_SUBST(LLVM_COPYRIGHT,["Copyright (c) 2003-2005 University of Illinois at Urbana-Champaign."])
 AC_COPYRIGHT($LLVM_COPYRIGHT)
 
 dnl Indicate that we require autoconf 2.59 or later. Ths is needed because we
@@ -72,10 +72,9 @@ do
       "llvm-test")    AC_CONFIG_SUBDIRS([projects/llvm-test]) ;;
       "llvm-reopt")   AC_CONFIG_SUBDIRS([projects/llvm-reopt]);;
       "llvm-gcc")     AC_CONFIG_SUBDIRS([projects/llvm-gcc])  ;;
-      "Java")         AC_CONFIG_SUBDIRS([projects/Java])      ;;
+      "llvm-java")    AC_CONFIG_SUBDIRS([projects/llvm-java]) ;;
       "llvm-tv")      AC_CONFIG_SUBDIRS([projects/llvm-tv])   ;;
-      "llvm-fefw")    AC_CONFIG_SUBDIRS([projects/llvm-fefw]) ;;
-      "poolalloc")    AC_CONFIG_SUBDIRS([projects/poolalloc]) ;;
+      "llvm-poolalloc") AC_CONFIG_SUBDIRS([projects/llvm-poolalloc]) ;;
       *)              
         AC_MSG_WARN([Unknown project (${i}) won't be configured automatically])
         ;;
@@ -97,34 +96,68 @@ AC_CANONICAL_TARGET
 
 dnl Determine the platform type and cache its value. This helps us configure
 dnl the System library to the correct build platform.
-AC_CACHE_CHECK([support for generic build operating system],
-               [llvm_cv_platform_type],
+AC_CACHE_CHECK([type of operating system we're on],
+               [llvm_cv_os_type],
 [case $build in
-  *-*-aix*) llvm_cv_platform_type="AIX" ;;
-  *-*-cygwin*) llvm_cv_platform_type="Cygwin" ;;
-  *-*-darwin*) llvm_cv_platform_type="Darwin" ;;
-  *-*-freebsd*) llvm_cv_platform_type="FreeBSD" ;;
-  *-*-interix*) llvm_cv_platform_type="Interix" ;;
-  *-*-linux*) llvm_cv_platform_type="Linux" ;;
-  *-*-solaris*) llvm_cv_platform_type="SunOS" ;;
-  *-*-win32*) llvm_cv_platform_type="Win32" ;;
-  *-*-mingw*) llvm_cv_platform_type="Win32" ;;
-  *) llvm_cv_platform_type="Unknown" ;;
+  *-*-aix*) 
+    llvm_cv_os_type="AIX" 
+    llvm_cv_platform_type="Unix" ;;
+  *-*-cygwin*) 
+    llvm_cv_os_type="Cygwin" 
+    llvm_cv_platform_type="Unix" ;;
+  *-*-darwin*) 
+    llvm_cv_os_type="Darwin"
+    llvm_cv_platform_type="Unix" ;;
+  *-*-freebsd*) 
+    llvm_cv_os_type="FreeBSD" 
+    llvm_cv_platform_type="Unix" ;;
+  *-*-hpux*) 
+    llvm_cv_os_type="HP-UX" 
+    llvm_cv_platform_type="Unix" ;;
+  *-*-interix*) 
+    llvm_cv_os_type="Interix"
+    llvm_cv_platform_type="Unix" ;;
+  *-*-linux*) 
+    llvm_cv_os_type="Linux"
+    llvm_cv_platform_type="Unix" ;;
+  *-*-solaris*) 
+    llvm_cv_os_type="SunOS"
+    llvm_cv_platform_type="Unix" ;;
+  *-*-win32*) 
+    llvm_cv_os_type="Win32"
+    llvm_cv_platform_type="Win32" ;;
+  *-*-mingw*) 
+    llvm_cv_os_type="MingW" 
+    llvm_cv_platform_type="Win32" ;;
+  *) 
+    llvm_cv_os_type="Unknown" 
+    llvm_cv_platform_type="Unknown" ;;
 esac])
 
 dnl Make sure we aren't attempting to configure for an unknown system
-if test "$llvm_cv_platform_type" = "Unknown" ; then
-  AC_MSG_ERROR([Operating system platform is unknown, configure can't continue])
+if test "$llvm_cv_os_type" = "Unknown" ; then
+  AC_MSG_ERROR([Operating system is unknown, configure can't continue])
 fi
 
 dnl Set the "OS" Makefile variable based on the platform type so the
 dnl makefile can configure itself to specific build hosts
-AC_SUBST(OS,$llvm_cv_platform_type)
+AC_SUBST(OS,$llvm_cv_os_type)
 
-dnl Make a link from lib/System/platform to lib/System/$llvm_cv_platform_type
-dnl This helps the #inclusion of the system specific include files
-dnl for the operating system abstraction library, lib/System.
-AC_CONFIG_LINKS(lib/System/platform:lib/System/$llvm_cv_platform_type)
+dnl Set the "LLVM_ON_*" variables based on llvm_cvs_platform_type
+dnl This is used by lib/System to determine the basic kind of implementation
+dnl to use.
+case $llvm_cv_platform_type in
+  Unix)  
+    AC_DEFINE([LLVM_ON_UNIX],[1],[Define if this is Unixish platform]) 
+    AC_SUBST(LLVM_ON_UNIX,[1])
+    AC_SUBST(LLVM_ON_WIN32,[0])
+    ;;
+  Win32) 
+    AC_DEFINE([LLVM_ON_WIN32],[1],[Define if this is Win32ish platform]) 
+    AC_SUBST(LLVM_ON_UNIX,[0])
+    AC_SUBST(LLVM_ON_WIN32,[1])
+    ;;
+esac
 
 dnl If we are targetting a Sparc machine running Solaris, pretend that it is
 dnl V9, since that is all that we support at the moment, and autoconf will only
@@ -139,9 +172,12 @@ dnl This will allow Makefiles to make a distinction between the hardware and
 dnl the OS.
 AC_CACHE_CHECK([target architecture],[llvm_cv_target_arch],
 [case $target in
-  i*86-*)      llvm_cv_target_arch="x86" ;;
+  i?86-*)                 llvm_cv_target_arch="x86" ;;
+  amd64-* | x86_64-*)     llvm_cv_target_arch="x86_64" ;;
   sparc*-*)               llvm_cv_target_arch="Sparc" ;;
   powerpc*-*)             llvm_cv_target_arch="PowerPC" ;;
+  alpha*-*)               llvm_cv_target_arch="Alpha" ;;
+  ia64-*)                 llvm_cv_target_arch="IA64" ;;
   *)                      llvm_cv_target_arch="Unknown" ;;
 esac])
 
@@ -183,6 +219,9 @@ else
     x86)     AC_SUBST(JIT,[[TARGET_HAS_JIT=1]]) ;;
     Sparc)   AC_SUBST(JIT,[[TARGET_HAS_JIT=1]]) ;;
     PowerPC) AC_SUBST(JIT,[[TARGET_HAS_JIT=1]]) ;;
+    x86_64)  AC_SUBST(JIT,[[]]) ;;
+    Alpha)   AC_SUBST(JIT,[[]]) ;;
+    IA64)    AC_SUBST(JIT,[[]]) ;;
     *)       AC_SUBST(JIT,[[]]) ;;
   esac
 fi
@@ -199,26 +238,52 @@ case "$enableval" in
   *) AC_MSG_ERROR([Invalid setting for --enable-doxygen. Use "yes" or "no"]) ;;
 esac
 
-dnl Find the LLVM GCC-based C/C++ front end
-AC_ARG_WITH(llvmgccdir,
-  AS_HELP_STRING(--with-llvmgccdir,[Location of LLVM GCC front-end]),
-  AC_SUBST(LLVMGCCDIR,[$withval]))
-
-dnl Provide some defaults for LLVMGCC for UIUC environments.
-if test "x$LLVMGCCDIR" = x ; then
-  case "$llvm_cv_platform_type" in
-    Linux)
-      if test -d /home/vadve/lattner/local/x86/llvm-gcc ; then
-        AC_SUBST(LLVMGCCDIR,[/home/vadve/lattner/local/x86/llvm-gcc/])
-      fi
+dnl Allow specific targets to be specified for building (or not)
+TARGETS_TO_BUILD=""
+AC_ARG_ENABLE([targets],AS_HELP_STRING([--enable-target],
+    [Build specific host targets: all,host-only,{target-name} (default=all)]),,
+    enableval=all)
+case "$enableval" in
+  all) TARGETS_TO_BUILD="X86 SparcV8 SparcV9 PowerPC Alpha IA64 Skeleton" ;;
+  host-only)
+    case "$llvm_cv_target_arch" in
+      x86)     TARGETS_TO_BUILD="X86" ;;
+      x86_64)  TARGETS_TO_BUILD="X86" ;;
+      Sparc)   TARGETS_TO_BUILD="SparcV8 SparcV9" ;;
+      PowerPC) TARGETS_TO_BUILD="PowerPC" ;;
+      Alpha)   TARGETS_TO_BUILD="Alpha" ;;
+      IA64)    TARGETS_TO_BUILD="IA64" ;;
+      *)       AC_MSG_ERROR([Can not set target to build]) ;;
+    esac 
     ;;
-    SunOS)
-      if test -d /home/vadve/lattner/local/sparc/llvm-gcc ; then
-        AC_SUBST(LLVMGCCDIR,[/home/vadve/lattner/local/sparc/llvm-gcc/])
-      fi
+  *)for a_target in `echo $enableval|sed -e 's/,/ /g' ` ; do
+      case "$a_target" in
+        x86)     TARGETS_TO_BUILD="X86 $TARGETS_TO_BUILD" ;;
+        x86_64)  TARGETS_TO_BUILD="X86 $TARGETS_TO_BUILD" ;;
+        sparc)   TARGETS_TO_BUILD="SparcV8 SparcV9 $TARGETS_TO_BUILD" ;;
+        powerpc) TARGETS_TO_BUILD="PowerPC $TARGETS_TO_BUILD" ;;
+        alpha)   TARGETS_TO_BUILD="Alpha $TARGETS_TO_BUILD" ;;
+        ia64)    TARGETS_TO_BUILD="IA64 $TARGETS_TO_BUILD" ;;
+        skeleton)TARGETS_TO_BUILD="Skeleton $TARGETS_TO_BUILD";;
+        *) AC_MSG_ERROR([Unrecognized target $a_target]) ;;
+      esac
+  done 
   ;;
 esac
-fi
+TARGETS_TO_BUILD="CBackend $TARGETS_TO_BUILD"
+AC_SUBST(TARGETS_TO_BUILD,$TARGETS_TO_BUILD)
+
+dnl Allow a specific llvm-gcc/llvm-g++ pair to be used with this LLVM config.
+AC_ARG_WITH(llvmgccdir,
+  AS_HELP_STRING([--with-llvmgccdir],
+    [Specify location of llvm-gcc install dir (default searches PATH)]),,
+    withval=default)
+case "$withval" in
+  default) WITH_LLVMGCCDIR=default ;;
+  /*)      WITH_LLVMGCCDIR=$withval ;;
+  *) AC_MSG_ERROR([Invalid path for --with-llvmgccdir. Provide full path]) ;;
+esac
+
 
 dnl===-----------------------------------------------------------------------===
 dnl===
@@ -236,12 +301,13 @@ AC_PROG_BISON
 dnl Check for the tools that the makefiles require
 AC_CHECK_GNU_MAKE
 AC_PROG_LN_S
+AC_PATH_PROG(CMP, [cmp], [cmp])
+AC_PATH_PROG(CP, [cp], [cp])
 AC_PATH_PROG(DATE, [date], [date])
 AC_PATH_PROG(FIND, [find], [find])
 AC_PATH_PROG(GREP, [grep], [grep])
 AC_PATH_PROG(MKDIR,[mkdir],[mkdir])
 AC_PATH_PROG(MV,   [mv],   [mv])
-AC_PATH_PROG(PAX,  [pax],  [pax])
 AC_PROG_RANLIB
 AC_PATH_PROG(RM,   [rm],   [rm])
 AC_PATH_PROG(SED,  [sed],  [sed])
@@ -262,8 +328,6 @@ AC_PATH_PROG(GROFF,[groff],[true groff])
 AC_PATH_PROG(GZIP,[gzip],[true gzip])
 AC_PATH_PROG(POD2HTML,[pod2html],[true pod2html])
 AC_PATH_PROG(POD2MAN,[pod2man],[true pod2man])
-AC_PATH_PROG(PYTHON,[python],[true python])
-AC_PATH_PROG(QMTEST,[qmtest],[true qmtest])
 AC_PATH_PROG(RUNTEST,[runtest],[true runtest])
 DJ_AC_PATH_TCLSH
 AC_PATH_PROG(ZIP,[zip],[true zip])
@@ -278,6 +342,11 @@ AC_LIBTOOL_DLOPEN
 AC_LIB_LTDL
 AC_PROG_LIBTOOL
 
+if test "$lt_cv_dlopen_self" = "yes" ; then
+  AC_DEFINE([CAN_DLOPEN_SELF],[1],
+              [Define if dlopen(0) will open the symbols of the program])
+fi
+
 dnl Check if we know how to tell etags we are using C++:
 etags_version=`$ETAGS --version 2>&1`
 case "$etags_version" in
@@ -287,25 +356,54 @@ case "$etags_version" in
 esac
 AC_SUBST(ETAGSFLAGS,$ETAGSFLAGS)
 
+if test "$WITH_LLVMGCCDIR" = "default" ; then
+  AC_PATH_PROG(LLVMGCC, [llvm-gcc], [])
+  AC_PATH_PROG(LLVMGXX, [llvm-g++], [])
+else
+  LLVMGCC=$WITH_LLVMGCCDIR/bin/llvm-gcc
+  LLVMGXX=$WITH_LLVMGCCDIR/bin/llvm-g++
+  AC_SUBST(LLVMGCC,$LLVMGCC)
+  AC_SUBST(LLVMGXX,$LLVMGXX)
+fi
+  
 AC_MSG_CHECKING([tool compatibility])
 
-dnl Ensure that compilation tools are GCC; we use GCC specific extensions
-if test "$GCC" != "yes"
+dnl Ensure that compilation tools are GCC or a GNU compatible compiler such as
+dnl ICC; we use GCC specific options in the makefiles so the compiler needs
+dnl to support those options.
+dnl "icc" emits gcc signatures
+dnl "icc -no-gcc" emits no gcc signature BUT is still compatible
+ICC=no
+IXX=no
+case $CC in
+  icc*|icpc*) 
+    ICC=yes
+    IXX=yes
+    ;;
+   *)
+    ;;
+esac
+
+if test "$GCC" != "yes" && test "$ICC" != "yes"
 then
-  AC_MSG_ERROR([gcc required but not found])
+  AC_MSG_ERROR([gcc|icc required but not found])
 fi
+
 dnl Ensure that compilation tools are GCC; we use GCC specific extensions
-if test "$GXX" != "yes"
+if test "$GXX" != "yes" && test "$IXX" != "yes"
 then
-  AC_MSG_ERROR([g++ required but not found])
+  AC_MSG_ERROR([g++|icc required but not found])
 fi
 
 dnl Verify that GCC is version 3.0 or higher
+if test "$GCC" = "yes"
+then
   gccmajor=`$CC --version | head -n 1 | awk '{print $NF;}' | cut -d. -f1`
   if test "$gccmajor" -lt "3"
   then
     AC_MSG_ERROR([gcc 3.x required, but you have a lower version])
   fi
+fi
 
 dnl Check for GNU Make.  We use its extensions, so don't build without it
 if test -z "$llvm_cv_gnu_make_command"
@@ -316,31 +414,6 @@ fi
 dnl Tool compatibility is okay if we make it here.
 AC_MSG_RESULT([ok])
 
-dnl Generate warnings for things not found but not strictly needed
-if test "$PYTHON" = "false" ; then
-  AC_MSG_WARN([Python is required for the test suite, but it was not found])
-fi
-if test "$QMTEST" = "false" ; then
-  AC_MSG_WARN([QMTest is required for the test suite, but it was not found])
-fi
-if test "$RUNTEST" = "false" ; then
-  AC_MSG_WARN([runtest (Deja-Gnu) is required for the test sute, but it was not found])
-fi
-pyversion=`$PYTHON -V 2>&1 | cut -d\  -f2`
-pymajor=`echo $pyversion | cut -d. -f1`
-pyminor=`echo $pyversion | cut -d. -f2`
-if test "$pymajor" -ge "2" ; then
-  if test "$pymajor" -eq "2" ; then
-    if test "$pyminor" -lt "2" ; then
-      AC_MSG_WARN([QMTest requires Python 2.2 or later])
-    fi
-  fi
-else
-  AC_MSG_WARN([QMTest requires Python 2.2 or later])
-fi
-
-AC_MSG_RESULT([])
-
 dnl===-----------------------------------------------------------------------===
 dnl===
 dnl=== SECTION 5: Check for libraries
@@ -377,23 +450,21 @@ dnl=== SECTION 6: Check for header files
 dnl===
 dnl===-----------------------------------------------------------------------===
 
+dnl First, use autoconf provided macros for specific headers that we need
 dnl We don't check for ancient stuff or things that are guaranteed to be there
 dnl by the C++ standard. We always use the <cfoo> versions of <foo.h> C headers.
-AC_HEADER_STDC
-
-dnl However, we do need some system specific header files. Generally we're
-dnl looking for POSIX headers.
-AC_HEADER_SYS_WAIT
-AC_CHECK_HEADERS([sys/time.h sys/mman.h sys/resource.h sys/time.h sys/types.h])
-AC_CHECK_HEADERS([dlfcn.h execinfo.h fcntl.h limits.h link.h])
-AC_CHECK_HEADERS([malloc.h unistd.h windows.h])
-AC_HEADER_TIME
+dnl Generally we're looking for POSIX headers.
+AC_HEADER_DIRENT
 AC_HEADER_MMAP_ANONYMOUS
+AC_HEADER_STAT
+AC_HEADER_STDC
+AC_HEADER_SYS_WAIT
+AC_HEADER_TIME
 
-dnl Check for things that need to be included in public headers, and so
-dnl for which we may not have access to a HAVE_* preprocessor #define.
-dnl (primarily used in DataTypes.h)
-AC_CHECK_HEADERS([inttypes.h stdint.h])
+AC_CHECK_HEADERS([dlfcn.h execinfo.h fcntl.h inttypes.h limits.h link.h])
+AC_CHECK_HEADERS([malloc.h signal.h stdint.h unistd.h utime.h windows.h])
+AC_CHECK_HEADERS([sys/mman.h sys/param.h sys/resource.h sys/time.h sys/types.h])
+AC_CHECK_HEADERS([rw/stdex/hash_map.h rw/stdex/hash_set.h])
 
 dnl===-----------------------------------------------------------------------===
 dnl===
@@ -416,8 +487,10 @@ dnl=== SECTION 8: Check for specific functions needed
 dnl===
 dnl===-----------------------------------------------------------------------===
 
-AC_CHECK_FUNCS([backtrace getcwd gettimeofday isatty getrusage mkstemp]) 
-AC_CHECK_FUNCS([strdup strtoq strtoll])
+AC_CHECK_FUNCS([backtrace getcwd getpagesize getrusage gettimeofday ])
+AC_CHECK_FUNCS([isatty mkdtemp mkstemp mktemp ])
+AC_CHECK_FUNCS([realpath sbrk setrlimit strdup strerror strerror_r ])
+AC_CHECK_FUNCS([strtoll strtoq sysconf])
 AC_C_PRINTF_A
 AC_FUNC_ALLOCA
 AC_FUNC_RAND48
@@ -433,15 +506,17 @@ AC_FUNC_ISNAN
 AC_FUNC_ISINF
 
 dnl Check for mmap and mprotect support. We need both to do the JIT and for
-dnl bytecode loading, etc.
+dnl bytecode loading, etc. We also need to know if /dev/zero is required to
+dnl be opened for allocating RWX memory.
 AC_FUNC_MMAP
 AC_FUNC_MMAP_FILE
+AC_NEED_DEV_ZERO_FOR_MMAP
 AC_CHECK_FUNC(mprotect,,
               AC_MSG_ERROR([Function mprotect() required but not found]))
 
 if test "$ac_cv_func_mmap_fixed_mapped" = "no"
 then
-  AC_MSG_WARN([mmap() required but not found])
+  AC_MSG_WARN([mmap() of a fixed address required but not supported])
 fi
 if test "$ac_cv_func_mmap_file" = "no"
 then
@@ -454,34 +529,26 @@ dnl=== SECTION 9: Additional checks, variables, etc.
 dnl===
 dnl===-----------------------------------------------------------------------===
 
-dnl Figure out if there's an executable llvm-gcc in the llvmgccdir.
-AC_CACHE_CHECK([for llvm-gcc],[llvm_cv_llvmgcc],
-[llvm_cv_llvmgcc='llvmgcc_not_found'
-if test -d "$LLVMGCCDIR" ; then
-  if test -x "$LLVMGCCDIR/bin/gcc" ; then
-    llvm_cv_llvmgcc="$LLVMGCCDIR/bin/gcc"
-  fi
-fi])
-
-dnl See if the llvmgcc executable can compile to LLVM assembly
+dnl See if the llvm-gcc executable can compile to LLVM assembly
 AC_CACHE_CHECK([whether llvm-gcc is sane],[llvm_cv_llvmgcc_sanity],
 [llvm_cv_llvmgcc_sanity="no"
-if test -x "$llvm_cv_llvmgcc" ; then
+if test -x "$LLVMGCC" ; then
   cp /dev/null conftest.c
-  "$llvm_cv_llvmgcc" -S -o - conftest.c | grep implementation > /dev/null 2>&1
+  "$LLVMGCC" -S -o - conftest.c | grep implementation > /dev/null 2>&1
   if test $? -eq 0 ; then
     llvm_cv_llvmgcc_sanity="yes"
   fi
   rm conftest.c
 fi])
 
-dnl Since we have a sane llvmgcc, identify it and its sub-tools 
+dnl Since we have a sane llvm-gcc, identify it and its sub-tools 
 if test "$llvm_cv_llvmgcc_sanity" = "yes" ; then
-  AC_SUBST(LLVMGCC,"$llvm_cv_llvmgcc")
-  llvmcc1path=`"$llvm_cv_llvmgcc" --print-prog-name=cc1`
+  llvmcc1path=`"$LLVMGCC" --print-prog-name=cc1`
   AC_SUBST(LLVMCC1,$llvmcc1path)
-  llvmcc1pluspath=`"$llvm_cv_llvmgcc" --print-prog-name=cc1plus`
+  llvmcc1pluspath=`"$LLVMGCC" --print-prog-name=cc1plus`
   AC_SUBST(LLVMCC1PLUS,$llvmcc1pluspath)
+  llvmgccdir=`echo "$llvmcc1path" | sed 's,/libexec/.*,,'`
+  AC_SUBST(LLVMGCCDIR,$llvmgccdir)
 fi
 
 dnl Propagate the shared library extension that the libltdl checks did to 
@@ -560,6 +627,7 @@ dnl Configure doxygen's configuration file
 AC_CONFIG_FILES([docs/doxygen.cfg])
 
 dnl Do special configuration of Makefiles
+AC_CONFIG_COMMANDS([setup],,[llvm_src="${srcdir}"])
 AC_CONFIG_MAKEFILE(Makefile)
 AC_CONFIG_MAKEFILE(Makefile.common)
 AC_CONFIG_MAKEFILE(examples/Makefile)
@@ -567,8 +635,6 @@ AC_CONFIG_MAKEFILE(lib/Makefile)
 AC_CONFIG_MAKEFILE(runtime/Makefile)
 AC_CONFIG_MAKEFILE(test/Makefile)
 AC_CONFIG_MAKEFILE(test/Makefile.tests)
-AC_CONFIG_MAKEFILE(test/QMTest/llvm.py)
-AC_CONFIG_MAKEFILE(test/QMTest/llvmdb.py)
 AC_CONFIG_MAKEFILE(tools/Makefile)
 AC_CONFIG_MAKEFILE(utils/Makefile)
 AC_CONFIG_MAKEFILE(projects/Makefile)
@@ -578,10 +644,9 @@ AC_OUTPUT
 
 dnl Warn loudly if llvm-gcc was not obviously working
 if test "$llvm_cv_llvmgcc_sanity" = "no" ; then
- AC_MSG_WARN([***** llvm C/C++ front end was not found, or does not])
- AC_MSG_WARN([***** appear to be working.])
- AC_MSG_WARN([***** ])
- AC_MSG_WARN([***** Please check configure's --with-llvmgccdir option.])
- AC_MSG_WARN([***** Runtime libraries (in llvm/runtime) will not be built,])
- AC_MSG_WARN([***** but you should be able to build the llvm tools.])
+ AC_MSG_WARN([***** llvm-gcc/llvm-g++ was not found, or does not appear to be ])
+ AC_MSG_WARN([***** working. Please make sure you have llvmgcc and llvmg++ in])
+ AC_MSG_WARN([***** your path before configuring LLVM. The runtime libraries])
+ AC_MSG_WARN([***** (llvm/runtime) will not be built but you should be able to])
+ AC_MSG_WARN([***** build the llvm tools.])
 fi

llvm/autoconf/ltmain.sh

@@ -4327,12 +4327,12 @@ extern \"C\" {
 
 	    # Prepare the list of exported symbols
 	    if test -z "$export_symbols"; then
-	      export_symbols="$output_objdir/$output.exp"
+	      export_symbols="$output_objdir/$outputname.exp"
 	      $run $rm $export_symbols
 	      $run eval "${SED} -n -e '/^: @PROGRAM@$/d' -e 's/^.* \(.*\)$/\1/p' "'< "$nlist" > "$export_symbols"'
 	    else
-	      $run eval "${SED} -e 's/\([][.*^$]\)/\\\1/g' -e 's/^/ /' -e 's/$/$/'"' < "$export_symbols" > "$output_objdir/$output.exp"'
-	      $run eval 'grep -f "$output_objdir/$output.exp" < "$nlist" > "$nlist"T'
+	      $run eval "${SED} -e 's/\([][.*^$]\)/\\\1/g' -e 's/^/ /' -e 's/$/$/'"' < "$export_symbols" > "$output_objdir/$outputname.exp"'
+	      $run eval 'grep -f "$output_objdir/$outputname.exp" < "$nlist" > "$nlist"T'
 	      $run eval 'mv "$nlist"T "$nlist"'
 	    fi
 	  fi

llvm/autoconf/m4/bison.m4

@@ -6,12 +6,9 @@
 # 2) BISON is set to bison
 #
 AC_DEFUN([AC_PROG_BISON],
-[AC_CACHE_CHECK([],[llvm_cv_has_bison],
-[AC_PROG_YACC()
-])
+[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
-])
+fi])

llvm/autoconf/m4/config_makefile.m4

@@ -3,5 +3,7 @@
 # date.  This macro is unique to LLVM.
 #
 AC_DEFUN([AC_CONFIG_MAKEFILE],
-[AC_CONFIG_COMMANDS($1,${SHELL} ${srcdir}/autoconf/install-sh -c ${srcdir}/$1 $1,${srcdir}/autoconf/mkinstalldirs `dirname $1`)
+[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/header_mmap_anonymous.m4

@@ -16,6 +16,6 @@ ac_cv_header_mmap_anon,
   AC_LANG_POP([C])
 ])
 if test "$ac_cv_header_mmap_anon" = yes; then
-   AC_DEFINE([HAVE_MMAP_ANONYMOUS],[],[Define if mmap() uses MAP_ANONYMOUS to map anonymous pages, or undefine if it uses MAP_ANON])
+   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/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

@@ -24,7 +24,7 @@ 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])
+  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

llvm/docs/.cvsignore

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

llvm/docs/Bugpoint.html

@@ -1,41 +1,63 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
+<!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: bugpoint tool</title>
+  <title>LLVM bugpoint tool: design and usage</title>
   <link rel="stylesheet" href="llvm.css" type="text/css">
-  <meta name="author" content="Chris Lattner">
-  <meta name="description" 
-  content="A tool for automatic test case reduction">
 </head>
-<html>
 
-<body>
-<center><h1>LLVM: <tt>bugpoint</tt> tool</h1></center>
-<HR>
+<div class="doc_title">
+  LLVM bugpoint tool: design and usage
+</div>
 
-<h3>NAME</h3>
-<tt>bugpoint</tt>
+<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>SYNOPSIS</h3>
-<tt>bugpoint [options] [input LLVM ll/bc files] [LLVM passes] --args &lt;program arguments&gt;...</tt>
+<div class="doc_author">
+<p>Written by <a href="mailto:sabre@nondot.org">Chris Lattner</a></p>
+</div>
 
-<img src="img/Debugging.gif" width=444 height=314 align=right>
-<h3>DESCRIPTION</h3>
+<!-- *********************************************************************** -->
+<div class="doc_section">
+<a name="desc">Description</a>
+</div>
+<!-- *********************************************************************** -->
 
-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/html/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>
+<div class="doc_text">
 
-<a name="designphilosophy">
-<h4>Design Philosophy</h4>
+<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>
 
-<tt>bugpoint</tt> is designed to be a useful tool without requiring any
+<p>For detailed case scenarios, such as debugging <tt>gccas</tt>,
+<tt>gccld</tt>, or one of the LLVM code generators, see <a
+href="HowToSubmitABug.html">How To Submit a Bug Report document</a>.</p>
+
+</div>
+
+<!-- *********************************************************************** -->
+<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
@@ -44,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
@@ -92,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/html/opt.html">opt</a></tt>, <tt><a
-href="CommandGuide/html/analyze.html">analyze</a></tt>, or <tt><a href="CommandGuide/html/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>
@@ -131,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
@@ -143,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,
@@ -165,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

@@ -1059,7 +1059,11 @@ href="#uint32_vbr">uint32_vbr</a> that describes the function.</p>
     </tr>
     <tr>
       <td><a href="#bit">bit(0-3)</a></td>
-      <td class="td_left">Reserved for future use.  Currently set to 0001.</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>
@@ -1595,12 +1599,45 @@ single <a href="#uint32_vbr">uint32_vbr</a> as follows:</p>
       <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>UserOp1</td><td>35</td><td>1</td><td>1.0</td></tr>
-      <tr><td>UserOp2</td><td>36</td><td>1</td><td>1.0</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">

llvm/docs/CFEBuildInstrs.html

@@ -45,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>
@@ -59,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 
@@ -67,16 +67,25 @@ 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_subsection"><a name="aix">Building under AIX</a></div>
 <div class="doc_text">
-<p>If you are building LLVM and the C front-end under AIX, do NOT use GNU
+<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>
@@ -91,12 +100,22 @@ invalid code.  Instead, use the system assembler and linker.
 <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 --prefix=/some/path/you/can/install/to [options...]
  % gmake tools-only
-</pre>
+  </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
@@ -109,9 +128,11 @@ invalid code.  Instead, use the system assembler and linker.
  % 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
@@ -121,7 +142,7 @@ invalid code.  Instead, use the system assembler and linker.
 </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>
@@ -132,9 +153,7 @@ invalid code.  Instead, use the system assembler and linker.
 <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 
+   --disable-shared --enable-languages=c,c++ --program-prefix=llvm-
  % gmake all; gmake install
 </pre>
 
@@ -143,17 +162,23 @@ invalid code.  Instead, use the system assembler and linker.
 <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 
+   --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 architecture.  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>).
@@ -163,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>
 
@@ -176,7 +199,7 @@ 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
+   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
@@ -186,10 +209,10 @@ 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 assembler or linker flags which
@@ -214,39 +237,37 @@ 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 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>
+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/<i>target-triplet</i>/3.4-llvm
+ % cd $CFEINSTALL/lib/gcc/<i>target-triplet</i>/3.4-llvm
  % llvm-ranlib libgcc.a
  % llvm-ranlib libgcov.a
 </pre>
@@ -254,9 +275,9 @@ the <tt>llvm-ranlib</tt> tool to do this, as follows:</p>
 <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>
@@ -279,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>
@@ -35,6 +36,22 @@
     </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>
@@ -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 than 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/CommandGuide/Makefile

@@ -7,53 +7,88 @@
 # 
 ##===----------------------------------------------------------------------===##
 
+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)
+
+.SUFFIXES:
+.SUFFIXES: .html .pod .1 .ps
+
+html/%.html: %.pod
+	pod2html --css=manpage.css --htmlroot=. \
+	  --podpath=. --noindex --infile=$< --outfile=$@ --title=$*
+
+man/man1/%.1: %.pod
+	pod2man --release=1.5 --center="LLVM Command Guide" $< $@
+
+ps/%.ps: man/man1/%.1
+	groff -Tps -man $< > $@
+
+clean:
+	rm -f pod2htm*.*~~ $(HTML) $(MAN) $(PS)
+
+else 
+
 LEVEL := ../..
 
 include $(LEVEL)/Makefile.common
 
-POD := $(wildcard $(BUILD_SRC_DIR)/*.pod)
+POD := $(wildcard $(PROJ_SRC_DIR)/*.pod)
 
 EXTRA_DIST := $(POD) index.html
 
-HTML = $(patsubst $(BUILD_SRC_DIR)/%.pod, $(BUILD_OBJ_DIR)/%.html, $(POD))
-MAN = $(patsubst $(BUILD_SRC_DIR)/%.pod, $(BUILD_OBJ_DIR)/%.1, $(POD))
-PS = $(patsubst $(BUILD_SRC_DIR)/%.pod, $(BUILD_OBJ_DIR)/%.ps, $(POD))
+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
 
-$(BUILD_OBJ_DIR)/%.html: %.pod
+html: $(HTML)
+
+$(PROJ_OBJ_DIR)/%.html: %.pod
 	$(POD2HTML) --css=manpage.css --htmlroot=. --podpath=. \
 	  --noindex --infile=$< --outfile=$@ --title=$*
 
-$(BUILD_OBJ_DIR)/%.1: %.pod
-	$(POD2MAN) --release=$(PACKAGE_VERSION) \
+$(PROJ_OBJ_DIR)/%.1: %.pod
+	$(POD2MAN) --release=$(LLVMVersion) \
 	  --center="LLVM Command Guide" $< $@
 
-$(BUILD_OBJ_DIR)/%.ps: $(BUILD_OBJ_DIR)/%.1
+$(PROJ_OBJ_DIR)/%.ps: $(PROJ_OBJ_DIR)/%.1
 	$(GROFF) -Tps -man $< > $@
 
 clean-local::
 	$(Verb) $(RM) -f pod2htm*.*~~ $(HTML) $(MAN) $(PS)
 
-HTML_DIR := $(LLVM_DOCSDIR)/html/CommandGuide
-MAN_DIR  := $(LLVM_MANDIR)/man1
-PS_DIR   := $(LLVM_DOCSDIR)/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) $(INSTALL) -d $(HTML_DIR)
-	$(Verb) $(INSTALL) -C $(HTML) $(HTML_DIR)
-	$(Verb) $(INSTALL) -C $(BUILD_SRC_DIR)/index.html $(HTML_DIR)
-	$(Verb) $(INSTALL) -C $(BUILD_SRC_DIR)/manpage.css $(HTML_DIR)
+	$(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) $(INSTALL) -d $(MAN_DIR)
-	$(Verb) $(INSTALL) -C $(MAN) $(MAN_DIR)
+	$(Verb) $(MKDIR) $(MAN_DIR)
+	$(Verb) $(DataInstall) $(MAN) $(MAN_DIR)
 	$(Echo) Installing PS CommandGuide Documentation
-	$(Verb) $(INSTALL) -d $(PS_DIR)
-	$(Verb) $(INSTALL) -C $(PS) $(PS_DIR)
+	$(Verb) $(MKDIR) $(PS_DIR)
+	$(Verb) $(DataInstall) $(PS) $(PS_DIR)
 
 uninstall-local::
 	$(Echo) Uninstalling Documentation
@@ -62,3 +97,5 @@ uninstall-local::
 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

@@ -32,44 +32,44 @@ options) arguments to the tool you are interested in.</p>
 
 <ul>
 
-<li><a href="llvm-as.html"><b>llvm-as</b></a> - 
+<li><a href="html/llvm-as.html"><b>llvm-as</b></a> - 
     assemble a human-readable .ll file into bytecode</li>
 
-<li><a href="llvm-dis.html"><b>llvm-dis</b></a> -
+<li><a href="html/llvm-dis.html"><b>llvm-dis</b></a> -
     disassemble a bytecode file into a human-readable .ll file</li>
 
-<li><a href="opt.html"><b>opt</b></a> -
+<li><a href="html/opt.html"><b>opt</b></a> -
     run a series of LLVM-to-LLVM optimizations on a bytecode file</li>
 
-<li><a href="llc.html"><b>llc</b></a> - 
+<li><a href="html/llc.html"><b>llc</b></a> - 
     generate native machine code for a bytecode file</li>
 
-<li><a href="lli.html"><b>lli</b></a> - 
+<li><a href="html/lli.html"><b>lli</b></a> - 
     directly run a program compiled to bytecode using a JIT compiler or 
     interpreter</li>
 
-<li><a href="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="analyze.html"><b>analyze</b></a> -
+<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="llvm-ar.html"><b>llvm-ar</b></a> - 
+<li><a href="html/llvm-ar.html"><b>llvm-ar</b></a> - 
     archive bytecode files</li>
 
-<li><a href="llvm-ranlib.html"><b>llvm-ranlib</b></a> - 
+<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="llvm-nm.html"><b>llvm-nm</b></a> -
+<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="llvm-prof.html"><b>llvm-prof</b></a> -
+<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="llvmc.html"><b>llvmc</b></a> -
+<li><a href="html/llvmc.html"><b>llvmc</b></a> -
   generic and configurable compiler driver</li>
 
-<li><a href="llvm-ld.html"><b>llvm-ld</b></a> -
+<li><a href="html/llvm-ld.html"><b>llvm-ld</b></a> -
   general purpose linker with loadable runtime optimization support</li>
 
 </ul>
@@ -85,19 +85,19 @@ options) arguments to the tool you are interested in.</p>
 <div class="doc_text">
 <ul>
 
-<li><a href="llvmgcc.html"><b>llvmgcc</b></a> -
+<li><a href="html/llvmgcc.html"><b>llvmgcc</b></a> -
     GCC-based C front-end for LLVM
 
-<li><a href="llvmgxx.html"><b>llvmg++</b></a> -
+<li><a href="html/llvmgxx.html"><b>llvmg++</b></a> -
     GCC-based C++ front-end for LLVM</li>
 
-<li><a href="gccas.html"><b>gccas</b></a> -
+<li><a href="html/gccas.html"><b>gccas</b></a> -
     compile-time optimizer used by llvm-g++ and llvm-gcc</li>
 
-<li><a href="gccld.html"><b>gccld</b></a> -
+<li><a href="html/gccld.html"><b>gccld</b></a> -
     linker and link-time optimizer used by llvm-g++ and llvm-gcc</li>
 
-<li><a href="stkrc.html"><b>stkrc</b></a> -
+<li><a href="html/stkrc.html"><b>stkrc</b></a> -
     front-end compiler for the <a href="../Stacker.html">Stacker</a> 
     language</li>
 
@@ -116,13 +116,13 @@ options) arguments to the tool you are interested in.</p>
 
 <ul>
 
-<li><a href="bugpoint.html"><b>bugpoint</b></a> -
+<li><a href="html/bugpoint.html"><b>bugpoint</b></a> -
     automatic test-case reducer</li>
 
-<li><a href="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="llvm-bcanalyzer.html"><b>llvm-bcanalyzer</b></a> -
+<li><a href="html/llvm-bcanalyzer.html"><b>llvm-bcanalyzer</b></a> -
     bytecode analyzer (analyzes the binary encoding itself, not the program it
     represents)</li>
 

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,64 +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<ppc32>
-
-32-bit PowerPC (MacOS X, 32-bit ABI)
-
-=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>
 
@@ -171,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
@@ -183,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

@@ -23,7 +23,7 @@ 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. There are first departure is that B<llvm-ar> only
+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
@@ -63,7 +63,7 @@ slash (/) character.
 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", bzip2 or zlib depending on what makes sense for the
+between "no compression" or bzip2 depending on what makes sense for the
 file's content.
 
 =item I<Directory Recursion>
@@ -229,9 +229,9 @@ 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.
-The compression will attempt to use the zlib compression algorithm. This
+This
 modifier is safe to use when (previously) compressed bytecode files are added to
-the archive; the compress bytecode files will not be doubly compressed.
+the archive; the compressed bytecode files will not be doubly compressed.
 
 =back
 
@@ -342,9 +342,8 @@ 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 1 (0x31) indicates that zlib
-compression was used. A value of 2 (0x32) indicates that bzip2 compression was
-used.
+that no compression was used. A value of 2 (0x32) indicates that bzip2
+compression was used.
 
 =item fmag - char[2]
 

llvm/docs/CommandGuide/llvm-as.pod

@@ -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,26 +6,24 @@ 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
 
-
 =over
 
 =item B<-nodetails>
@@ -41,7 +39,7 @@ 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.
 
@@ -112,7 +110,7 @@ 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<Compaction Table 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
@@ -280,20 +278,20 @@ 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<# of VBR 32-bit Integers>
+=item B<Number of VBR 32-bit Integers>
 
 The total number of 32-bit integers found in this function (for any use).
 
-=item B<# of VBR 64-bit Integers>
+=item B<Number of VBR 64-bit Integers>
 
 The total number of 64-bit integers found in this function (for any use).
 
-=item B<# of VBR Compressed Bytes>
+=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<# of VBR Expanded Bytes>
+=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 

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

@@ -43,7 +43,7 @@ exit code will be returned.
 
 =head1 SEE ALSO
 
-L<llvm-ar|llvm-ar>, L<ranlib(1)>
+L<llvm-ar|llvm-ar>, ranlib(1)
 
 =head1 AUTHORS
 

llvm/docs/CommandGuide/llvmc.pod

@@ -109,13 +109,13 @@ 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> or B<--assemble>
+=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> or B<--preprocess>
+=item B<-E>
 
 This option specifies that no compilation or linking should be 
 performed. Only pre-processing, if applicable to the language being
@@ -274,7 +274,7 @@ it to the standard error.
 
 =over
 
-=item B<-T,pp>=I<options>
+=item B<-T,pre>=I<options>
 
 Pass an arbitrary option to the pre-processor.
 
@@ -282,7 +282,7 @@ Pass an arbitrary option to the pre-processor.
 
 Pass an arbitrary option to the optimizer.
 
-=item B<-T,link>=I<options>
+=item B<-T,lnk>=I<options>
 
 Pass an arbitrary option to the linker.
 
@@ -292,7 +292,7 @@ Pass an arbitrary option to the code generator.
 
 =back
 
-=head3 C/C++ Specific Options
+=head2 C/C++ Specific Options
 
 =over
 
@@ -301,6 +301,11 @@ Pass an arbitrary option to the code generator.
 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
@@ -311,10 +316,9 @@ where include files can be found.
 
 Print a summary of command line options.
 
-=item B<-V> or B<--version>
+=item B<--version>
 
-This option will cause B<llvmc> to print out its version number
-and terminate.
+This option will cause B<llvmc> to print out its version number and terminate.
 
 =back
 
@@ -325,6 +329,23 @@ 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
@@ -345,15 +366,6 @@ 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-file> 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.
-
 =item B<--config-only-from> F<dirname>
 
 This option tells B<llvmc> to skip the normal processing of configuration
@@ -361,7 +373,6 @@ 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 

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

@@ -192,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>
@@ -220,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
@@ -235,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
@@ -270,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
@@ -285,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
@@ -304,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>
 
@@ -329,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
@@ -351,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
@@ -367,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:
@@ -375,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:
@@ -388,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
@@ -408,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
@@ -436,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
@@ -486,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
 };
@@ -502,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
@@ -514,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:
@@ -527,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
 };
@@ -550,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
@@ -575,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
 };
@@ -587,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:
@@ -611,7 +611,7 @@ 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 optimization level declaration is that the debug level declaration includes
@@ -637,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>"),
@@ -654,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>
 
@@ -676,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
@@ -709,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>
@@ -730,7 +730,7 @@ OPTIONS:
   ...
   -help             - display available options (--help-hidden for more)
   -o &lt;filename&gt;     - Specify output filename
-</pre>
+</pre></div>
 
 </div>
 
@@ -764,20 +764,20 @@ 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>
@@ -804,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'
 
@@ -813,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
@@ -821,10 +821,10 @@ 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>
 
@@ -847,7 +847,9 @@ can use it like this:</p>
   <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:<pre><tt>
+  <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);
 
@@ -877,8 +879,8 @@ can use it like this:</p>
       else
         break; // we're done with the list
     }
-  }
-  </tt></pre></p>
+  }</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 
@@ -906,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
@@ -961,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
 //
@@ -976,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
@@ -993,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>
 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>
 
@@ -1055,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
@@ -1282,31 +1286,33 @@ 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 <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>
+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>
@@ -1322,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>
 
@@ -1450,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
@@ -1484,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
@@ -1510,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
@@ -1533,22 +1539,22 @@ the conversion from string to data.</p>
 <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>
 
-<pre>
+<div class="doc_code"><pre>
 <b>namespace</b> cl {
   <b>struct</b> extrahelp;
 }
-</pre>
+</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
+<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>
-<pre>
+<div class="doc_code"><pre>
   cl::extrahelp("\nADDITIONAL HELP:\n\n  This is the extra help\n");
-</pre>
+</pre></div>
 </div>
 
 <!-- ======================================================================= -->
@@ -1675,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
@@ -1697,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();
@@ -1723,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
@@ -1732,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
@@ -1759,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"

llvm/docs/CompilerWriterInfo.html

@@ -19,7 +19,9 @@
 <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>
@@ -31,10 +33,7 @@
     <li><a href="#linux">Linux</a></li>
     <li><a href="#osx">OS X</a></li>
   </ol></li>
-  <li><a href="#fmt">Binary File Formats</a>
-  <ol>
-    <li>...</li>
-  </ol></li>
+  <li><a href="#misc">Miscellaneous resources</a></li>
 </ol>
 
 <div class="doc_author">
@@ -46,10 +45,18 @@
 <!-- *********************************************************************** -->
 
 <!-- ======================================================================= -->
-<div class="doc_subsection"><a name="arm">ARM</a></div>
+<div class="doc_subsection"><a name="alpha">Alpha</a></div>
 
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">ARM - Official manuals and docs</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>
@@ -60,19 +67,25 @@ Cores</a>)</li>
 </div>
 
 <!-- ======================================================================= -->
-<div class="doc_subsection"><a name="mips">MIPS</a></div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">MIPS - Official manuals and docs</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>
 
 <!-- ======================================================================= -->
@@ -130,9 +143,6 @@ branch stubs for powerpc64-linux (from binutils)</a></li>
 <!-- ======================================================================= -->
 <div class="doc_subsection"><a name="sparc">SPARC</a></div>
 
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">Official manuals and docs</div>
-
 <div class="doc_text">
 
 <ul>
@@ -152,6 +162,7 @@ branch stubs for powerpc64-linux (from binutils)</a></li>
 <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>
 
@@ -219,13 +230,16 @@ ABI</a></li>
 </div>
 
 <!-- *********************************************************************** -->
-<div class="doc_section"><a name="fmt">Binary File Formats</a></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>
 
 <!-- *********************************************************************** -->

llvm/docs/ExtendingLLVM.html

@@ -24,8 +24,8 @@
 </ol>
 
 <div class="doc_author">    
-  <p>Written by <a href="http://misha.brukman.net">Misha Brukman</a> and
-  Brad Jones</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>
 
 <!-- *********************************************************************** -->
@@ -86,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>
 
@@ -100,17 +97,63 @@ function and then be turned into an instruction if warranted.</p>
     not access memory or does not write to memory, add it to the relevant list
     of functions.</li>
 
-<li><tt>llvm/lib/Transforms/Utils/Local.cpp</tt>: If it is possible to
-    constant-propagate your intrinsic, add support to it in the
-    <tt>canConstantFoldCallTo</tt> and <tt>ConstantFoldCall</tt> functions.</li>
+<li><tt>llvm/lib/Transforms/Utils/Local.cpp</tt>: If it is possible to constant
+fold your intrinsic, add support to it in the <tt>canConstantFoldCallTo</tt> and
+<tt>ConstantFoldCall</tt> functions.</li>
 
 <li>Test your intrinsic</li>
 
 <li><tt>llvm/test/Regression/*</tt>: add your test cases to the test suite</li>
 </ol>
 
-<p>If this intrinsic requires code generator support (i.e., 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>
 
@@ -194,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>;
@@ -222,11 +262,8 @@ installations.</span> Only add new types if it is absolutely necessary.</p>
 <div class="doc_text">
 
 <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 a forward declaration of the type
+    add enum for the new type; add a forward declaration of the type
     also</li>
 
 <li><tt>llvm/include/llvm/DerivedType.h</tt>:
@@ -283,7 +320,6 @@ void calcTypeName(const Type *Ty,
   <a href="http://validator.w3.org/check/referer"><img
   src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /></a>
 
-  <a href="http://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

@@ -67,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>
@@ -168,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>
@@ -350,31 +352,6 @@ build.</p>
    affects projects other than LLVM.  Try upgrading or downgrading your GCC.</p>
 </div>
 
-<div class="question">
-<p>
-When I use the test suite, all of the C Backend tests fail.  What is
-wrong?
-</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>
-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>
-
 <div class="question">
 <p>After CVS update, rebuilding gives the error "No rule to make target".</p>
 </div>
@@ -462,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">
@@ -476,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>
 
@@ -497,29 +489,8 @@ linked in automatically when you link the program.
 
 <!--=========================================================================-->
 
-<div class="question"><p>
-Where did all of my code go??
-</p></div>
-
-<div class="answer">
-<p>
-If you are using the LLVM demo page, you may often wonder what happened to all
-of the code that you typed in.  Remember that the demo script is running the
-code through the LLVM optimizers, so if your code doesn't actually do anything
-useful, it might all be deleted.
-</p>
-
-<p>
-To prevent this, make sure that the code is actually needed.  For example, if
-you are computing some expression, return the value from the function instead of
-leaving it in a local variable.  If you really want to constrain the optimizer,
-you can read from and assign to <tt>volatile</tt> global variables.
-</p>
-</div>
-
-<!--=========================================================================-->
-
 <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>
@@ -548,6 +519,51 @@ 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>
+
+<div class="answer">
+<p>
+If you are using the LLVM demo page, you may often wonder what happened to all
+of the code that you typed in.  Remember that the demo script is running the
+code through the LLVM optimizers, so if your code doesn't actually do anything
+useful, it might all be deleted.
+</p>
+
+<p>
+To prevent this, make sure that the code is actually needed.  For example, if
+you are computing some expression, return the value from the function instead of
+leaving it in a local variable.  If you really want to constrain the optimizer,
+you can read from and assign to <tt>volatile</tt> global variables.
+</p>
+</div>
+
+<!--=========================================================================-->
+
+<div class="question"><p>
+<a name="undef"></a>
+<p>What is this "<tt>undef</tt>" thing that shows up in my code?
+</p></div>
+
+<div class="answer">
+<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>
+
+<div class="doc_code">
+  <tt>int X() { int i; return i; }</tt>
+</div>
+
+<p>Is compiled to "<tt>ret int undef</tt>" because "i" never has a value 
+specified for it.
+</p>
+</div>
+
 <!-- *********************************************************************** -->
 
 <hr>

llvm/docs/GettingStarted.html

@@ -38,13 +38,16 @@
   <li><a href="#layout">Program layout</a>
     <ol>
       <li><a href="#cvsdir"><tt>CVS</tt> directories</a>
+      <li><a href="#examples"><tt>llvm/examples</tt></a>
       <li><a href="#include"><tt>llvm/include</tt></a>
       <li><a href="#lib"><tt>llvm/lib</tt></a>
+      <li><a href="#projects"><tt>llvm/projects</tt></a>
       <li><a href="#runtime"><tt>llvm/runtime</tt></a>  
       <li><a href="#test"><tt>llvm/test</tt></a>
       <li><a href="#llvmtest"><tt>llvm-test</tt></a>
       <li><a href="#tools"><tt>llvm/tools</tt></a>  
       <li><a href="#utils"><tt>llvm/utils</tt></a>
+      <li><a href="#win32"><tt>llvm/win32</tt></a>
     </ol></li>
 
   <li><a href="#tutorial">An Example Using the LLVM Tool Chain</a>
@@ -86,6 +89,12 @@ end is a modified version of GCC 3.4 (we track the GCC 3.4 development).  Once
 compiled into LLVM bytecode, a program can be manipulated with the LLVM tools
 from the LLVM suite.</p>
 
+<p>
+There is a third, optional piece called llvm-test.  It is a suite of programs
+with a testing harness that can be used to further test LLVM's functionality
+and performance.
+</p>
+
 </div>
 
 <!-- *********************************************************************** -->
@@ -102,46 +111,53 @@ from the LLVM suite.</p>
   <li>Read the documentation.</li>
   <li>Read the documentation.</li>
   <li>Remember that you were warned twice about reading the documentation.</li>
-  <li>Install the GCC front end:
+  <li>Install the GCC front end if you intend to compile C or C++:
     <ol>
-      <li><tt>cd <i>where-you-want-the-C-front-end-to-live</i></tt>
+      <li><tt>cd <i>where-you-want-the-C-front-end-to-live</i></tt></li>
       <li><tt>gunzip --stdout cfrontend.<i>platform</i>.tar.gz | tar -xvf -</tt>
-      <li><b>Sparc and MacOS X Only:</b><br>
-      <tt>cd cfrontend/<i>platform</i><br>
-          ./fixheaders</tt>
+      </li>
+      <li><tt>cd cfrontend/<i>platform</i><br>
+        ./fixheaders</tt></li>
+      <li>Add the cfrontend's "bin" directory to your PATH variable.</li>
     </ol></li>
 
-  <li>Get the Source Code
+  <li>Get the LLVM Source Code
   <ul>
-    <li>With the distributed files:
+    <li>With the distributed files (or use <a href="#checkout">CVS</a>):
     <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>
-      <li><tt>cd llvm</tt>
     </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><b>[Optional]</b> Get the Test Suite Source Code 
+  <ul>
+    <li>With the distributed files (or use <a href="#checkout">CVS</a>):
+    <ol>
+      <li><tt>cd <i>where-you-want-llvm-to-live</i></tt>
+      <li><tt>cd llvm/projects</tt>
+      <li><tt>gunzip --stdout llvm-test-<i>version</i>.tar.gz | tar -xvf -</tt>
+    </ol></li>
+
+  </ul></li>
+
+
   <li>Configure the LLVM Build Environment
   <ol>
-    <li>Change directory to where you want to store the LLVM object
-        files and run <tt>configure</tt> to configure the Makefiles and
-        header files for the default platform. Useful options include:
+    <li><tt>cd <i>where-you-want-to-build-llvm</i></tt></li>
+    <li><tt><i>/path/to/llvm/</i>configure [options]</tt><br>
+    Some common options:
+
       <ul>
+        <li><tt>--prefix=<i>directory</i></tt>
+        <p>Specify for <i>directory</i> the full pathname of where you
+        want the LLVM tools and libraries to be installed (default
+        <tt>/usr/local</tt>).</p></li>
         <li><tt>--with-llvmgccdir=<i>directory</i></tt>
-            <p>Specify the full pathname of where the LLVM GCC frontend is
-            installed.</p></li>
+        <p>Optionally, specify for <i>directory</i> the full pathname of the 
+        C/C++ front end installation to use with this LLVM configuration. If
+        not specified, the PATH will be searched.</p></li>
         <li><tt>--enable-spec2000=<i>directory</i></tt>
             <p>Enable the SPEC2000 benchmarks for testing.  The SPEC2000
             benchmarks should be available in
@@ -151,7 +167,6 @@ from the LLVM suite.</p>
 
   <li>Build the LLVM Suite:
   <ol>
-      <li>Set your LLVM_LIB_SEARCH_PATH environment variable.</li>
       <li><tt>gmake -k |&amp; tee gnumake.out
       &nbsp;&nbsp;&nbsp;# this is csh or tcsh syntax</tt></li>
       <li>If you get an "internal compiler error (ICE)" see <a href="#brokengcc">below</a>.</li>
@@ -198,7 +213,7 @@ software you will need.</p>
 </tr>
 <tr>
   <td>Linux</td>
-  <td>x86<sup>1</sup></td>
+  <td>x86<sup><a href="#pf_1">1</a></sup></td>
   <td>GCC</td>
 </tr>
 <tr>
@@ -208,17 +223,27 @@ software you will need.</p>
 </tr>
 <tr>
   <td>FreeBSD</td>
-  <td>x86<sup>1</sup></td>
+  <td>x86<sup><a href="#pf_1">1</a></sup></td>
   <td>GCC</td>
 </tr>
 <tr>
-  <td>MacOS X<sup>2</sup></td>
+  <td>MacOS X<sup><a href="#pf_2">2</a></sup></td>
   <td>PowerPC</td>
   <td>GCC</td>
 </tr>
 <tr>
   <td>Cygwin/Win32</td>
-  <td>x86<sup>1</sup></td>
+  <td>x86<sup><a href="#pf_1">1</a></sup></td>
+  <td>GCC 3.4.X, binutils 2.15</td>
+</tr>
+<tr>
+  <td>MinGW/Win32</td>
+  <td>x86<sup><a href="#pf_1">1</a>,<a href="#pf_6">6</a></sup></td>
+  <td>GCC 3.4.X, binutils 2.15</td>
+</tr>
+<tr>
+  <td>Linux</td>
+  <td>amd64<sup><a href="#pf_3">3</a></sup></td>
   <td>GCC</td>
 </tr>
 </table>
@@ -233,33 +258,58 @@ software you will need.</p>
 </tr>
 <tr>
   <td>Windows</td>
-  <td>x86<sup>1</sup></td>
-  <td>Visual Studio .NET<sup>4,5</sup>, MinGW</td>
+  <td>x86<sup><a href="#pf_1">1</a></sup></td>
+  <td>Visual Studio .NET<sup><a href="#pf_4">4</a>,<a href="#pf_5">5</a></sup></td>
 <tr>
-  <td>AIX<sup>3,4</sup></td>
+  <td>AIX<sup><a href="#pf_3">3</a>,<a href="#pf_4">4</a></sup></td>
   <td>PowerPC</td>
   <td>GCC</td>
 </tr>
 <tr>
-  <td>Linux<sup>3,5</sup></td>
+  <td>Linux<sup><a href="#pf_3">3</a>,<a href="#pf_5">5</a></sup></td>
   <td>PowerPC</td>
   <td>GCC</td>
 </tr>
+
+<tr>
+  <td>Linux<sup><a href="#pf_7">7</a></sup></td>
+  <td>Alpha</td>
+  <td>GCC</td>
+</tr>
+<tr>
+  <td>Linux<sup><a href="#pf_7">7</a></sup></td>
+  <td>Itanium (IA-64)</td>
+  <td>GCC</td>
+</tr>
+<tr>
+  <td>HP-UX<sup><a href="#pf_7">7</a></sup></td>
+  <td>Itanium (IA-64)</td>
+  <td>HP aCC</td>
+</tr>
 </table>
 
-<p>
-Notes:<br>
-<sup>1</sup> Code generation supported for Pentium processors and up<br>
-<sup>2</sup> Code generation supported for 32-bit ABI only<br>
-<sup>3</sup> No native code generation<br>
-<sup>4</sup> Build is not complete: one or more tools don't link<br>
-<sup>5</sup> The GCC-based C/C++ frontend does not build<br>
-</p>
+<p><b>Notes:</b></p>
+
+<div class="doc_notes">
+<ol>
+<li><a name="pf_1">Code generation supported for Pentium processors and
+up</a></li>
+<li><a name="pf_2">Code generation supported for 32-bit ABI only</a></li>
+<li><a name="pf_3">No native code generation</a></li>
+<li><a name="pf_4">Build is not complete: one or more tools don't link</a></li>
+<li><a name="pf_5">The GCC-based C/C++ frontend does not build</a></li>
+<li><a name="pf_6">The port is done using the MSYS shell. 
+<a href="http://www.mingw.org/MinGWiki/">Download</a> and install 
+bison (excl. M4.exe) and flex in that order.  Build binutils-2.15 from source,
+if necessary.</li>
+<li><a name="pf_7">Native code generation exists but is not complete.</a></li>
+</ol>
+</div>
 
 <p>Note that you will need about 1-3 GB of space for a full LLVM build in Debug
-mode, depending on the system (because of all the debug info), and the libraries
-appear in more than one of the tools that get linked, so there is some
-duplication.  If you do not need many of the tools and you are space-conscious,
+mode, depending on the system (it is so large because of all the debugging
+information and the fact that the libraries are statically linked into multiple
+tools).  If you do not need many of the tools and you are space-conscious,
 you can disable them individually in <tt>llvm/tools/Makefile</tt>.  The Release
 build requires considerably less space.</p>
 
@@ -295,7 +345,7 @@ href="CFEBuildInstrs.html">try to compile it</a> on your platform.</p>
     <tr>
       <td><a href="http://gcc.gnu.org">GCC</a></td>
       <td>3.4.2</td>
-      <td>C/C++ compiler (<a href="#Note4">Note 4</a>)</td>
+      <td>C/C++ compiler<sup><a href="#sf1">1</a></sup></td>
     </tr>
 
     <tr>
@@ -310,102 +360,80 @@ href="CFEBuildInstrs.html">try to compile it</a> on your platform.</p>
       <td>YACC compiler</td>
     </tr>
 
+    <tr>
+      <td><a href="https://www.cvshome.org/downloads.html">CVS</a></td>
+      <td>&ge;1.11</td>
+      <td>CVS access to LLVM<sup><a href="#sf2">2</a></sup></td>
+    </tr>
+
     <tr>
       <td><a href="http://savannah.gnu.org/projects/dejagnu">DejaGnu</a></td>
       <td>1.4.2</td>
-      <td>Automated test suite (<a href="#Note2">Note 2</a>)</td>
+      <td>Automated test suite<sup><a href="#sf3">3</a></sup></td>
     </tr>
 
     <tr>
       <td><a href="http://www.tcl.tk/software/tcltk/">tcl</a></td>
       <td>8.3, 8.4</td>
-      <td>Automated test suite (<a href="#Note2">Note 2</a>)</td>
+      <td>Automated test suite<sup><a href="#sf3">3</a></sup></td>
     </tr>
 
     <tr>
       <td><a href="http://expect.nist.gov/">expect</a></td>
       <td>5.38.0</td>
-      <td>Automated test suite (<a href="#Note2">Note 2</a>)</td>
+      <td>Automated test suite<sup><a href="#sf3">3</a></sup></td>
+    </tr>
+
+    <tr>
+      <td><a href="http://www.perl.com/download.csp">perl</a></td>
+      <td>&ge;5.6.0</td>
+      <td>Nightly tester, utilities</td>
     </tr>
 
     <tr>
       <td><a href="http://savannah.gnu.org/projects/m4">GNU M4</a>
       <td>1.4</td>
-      <td>Macro processor for configuration (<a href="#Note1">Note 1</a>)</td>
+      <td>Macro processor for configuration<sup><a href="#sf4">4</a></sup></td>
     </tr>
 
     <tr>
       <td><a href="http://www.gnu.org/software/autoconf">GNU Autoconf</a></td>
       <td>2.59</td>
-      <td>Configuration script builder (<a href="#Note1">Note 1</a>)</td>
+      <td>Configuration script builder<sup><a href="#sf4">4</a></sup></td>
     </tr>
 
     <tr>
       <td><a href="http://www.gnu.org/software/automake">GNU Automake</a></td>
-      <td>2.59</td>
-      <td>aclocal macro generator (<a href="#Note1">Note 1</a>)</td>
-    </tr>
-
-    <tr>
-      <td><a href="http://www.perl.com/download.csp">perl</a></td>
-      <td>&gt;5.6.0</td>
-      <td>Nightly tester, utilities</td>
+      <td>1.9.2</td>
+      <td>aclocal macro generator<sup><a href="#sf4">4</a></sup></td>
     </tr>
 
     <tr>
       <td><a href="http://savannah.gnu.org/projects/libtool">libtool</a></td>
       <td>1.5.10</td>
-      <td>Shared library manager (<a href="#Note1">Note 1</a>)</td>
-    </tr>
-
-    <tr>
-      <td><a href="http://www.codesourcery.com/qmtest">QMTest</a></td>
-      <td>2.0.3</td>
-      <td>Automated test suite (<a href="#Note2">Note 2</a>,<a href="#Note3">
-          Note 3</a>)</td>
-    </tr>
-
-    <tr>
-      <td><a href="http://www.python.org">Python</a></td>
-      <td>2.3</td>
-      <td>Automated test suite (<a href="#Note2">Note 2</a>,<a href="#Note3">
-          Note 3</a>)</td>
-    </tr>
-
-    <tr>
-      <td><a href="https://www.cvshome.org/downloads.html">CVS</a></td>
-      <td>&gt;1.11</td>
-      <td>CVS access to LLVM (<a href="#Note5">Note 5</a>)</td>
+      <td>Shared library manager<sup><a href="#sf4">4</a></sup></td>
     </tr>
 
   </table>
 
-  <p>Notes:</p>
+  <p><b>Notes:</b></p>
+  <div class="doc_notes">
   <ol>
-    <li><a name="Note1">If you want to make changes to the configure scripts, 
-      you will need GNU autoconf (2.59), and consequently, GNU M4 (version 1.4 
-      or higher). You will also need automake. We only use aclocal from that 
-      package.</a></li>
-    <li><a name="Note2">Only needed if you want to run the automated test 
-      suite in the <tt>test</tt> directory.</a></li>
-    <li><a name="Note3">These are needed to use the LLVM test suite.</a>
-      Please note that newer versions of QMTest may not work with the LLVM 
-      test suite.  QMTest 2.0.3 can be retrieved from the QMTest CVS 
-      repository using the following commands:
-      <ul>
-        <li><tt>cvs -d :pserver:anoncvs@cvs.codesourcery.com:/home/qm/Repository login</tt></li>
-        <li>When prompted, use <tt>anoncvs</tt> as the password. </li>
-        <li><tt>cvs -d :pserver:anoncvs@cvs.codesourcery.com:/home/qm/Repository co -r release-2-0-3 qm</tt></li>
-      </ul>
-    </li>
-    <li><a name="Note4">Only the C and C++ languages are needed so there's no
+    <li><a name="sf3">Only the C and C++ languages are needed so there's no
       need to build the other languages for LLVM's purposes.</a> See 
-      <a href="#brokengcc">below</a> for specific version info.
-    </li>
-    <li><a name="Note5">You only need CVS if you intend to build from the 
+      <a href="#brokengcc">below</a> for specific version info.</li>
+    <li><a name="sf2">You only need CVS if you intend to build from the 
       latest LLVM sources. If you're working from a release distribution, you
       don't need CVS.</a></li>
+    <li><a name="sf3">Only needed if you want to run the automated test 
+      suite in the <tt>llvm/test</tt> directory.</a></li>
+    <li><a name="sf4">If you want to make changes to the configure scripts, 
+      you will need GNU autoconf (2.59), and consequently, GNU M4 (version 1.4 
+      or higher). You will also need automake (1.9.2). We only use aclocal 
+      from that package.</a></li>
   </ol>
+  </div>
+  
   <p>Additionally, your compilation host is expected to have the usual 
   plethora of Unix utilities. Specifically:</p>
   <ul>
@@ -413,7 +441,7 @@ href="CFEBuildInstrs.html">try to compile it</a> on your platform.</p>
     <li><b>bzip2*</b> - bzip2 command for distribution generation</li>
     <li><b>bunzip2*</b> - bunzip2 command for distribution checking</li>
     <li><b>chmod</b> - change permissions on a file</li>
-    <li><b>cat</b> - output concatentation utility</li>
+    <li><b>cat</b> - output concatenation utility</li>
     <li><b>cp</b> - copy files</li>
     <li><b>date</b> - print the current date/time </li>
     <li><b>echo</b> - print to standard output</li>
@@ -447,7 +475,8 @@ href="CFEBuildInstrs.html">try to compile it</a> on your platform.</p>
 <p>LLVM is very demanding of the host C++ compiler, and as such tends to expose
 bugs in the compiler.  In particular, several versions of GCC crash when trying
 to compile LLVM.  We routinely use GCC 3.3.3 and GCC 3.4.0 and have had success
-with them.  Other versions of GCC will probably work as well.  GCC versions listed
+with them (however, see below).  Other versions of GCC will probably
+work as well.  GCC versions listed
 here are known to not work.  If you are using one of these versions, please try
 to upgrade your GCC to something more recent.  If you run into a problem with a
 version of GCC not listed here, please <a href="mailto:llvmdev@cs.uiuc.edu">let
@@ -464,6 +493,16 @@ problems in the STL that effectively prevent it from compiling LLVM.
 <p><b>GCC 3.3.2</b>: This version of GCC suffered from a <a 
 href="http://gcc.gnu.org/PR13392">serious bug</a> which causes it to crash in
 the "<tt>convert_from_eh_region_ranges_1</tt>" GCC function.</p>
+
+<p><b>Cygwin GCC 3.3.3</b>: The version of GCC 3.3.3 commonly shipped with 
+   Cygwin does not work.  Please <a href="CFEBuildInstrs.html#cygwin">upgrade 
+   to a newer version</a> if possible.</p>
+<p><b>SuSE GCC 3.3.3</b>: The version of GCC 3.3.3 shipped with SuSE 9.1 (and 
+   possibly others) does not compile LLVM correctly (it appears that exception 
+   handling is broken in some cases).  Please download the FSF 3.3.3 or upgrade
+   to a newer version of GCC.</p>
+<p><b>IA-64 GCC 4.0.0</b>: The IA-64 version of GCC 4.0.0 is known to
+   miscompile LLVM.</p>
 </div>
 
 
@@ -515,7 +554,7 @@ All these paths are absolute:</p>
 
     <dt>LLVMGCCDIR
     <dd>
-    This is the where the LLVM GCC Front End is installed.
+    This is where the LLVM GCC Front End is installed.
     <p>
     For the pre-built GCC front end binaries, the LLVMGCCDIR is
     <tt>cfrontend/<i>platform</i>/llvm-gcc</tt>.
@@ -531,23 +570,17 @@ All these paths are absolute:</p>
 <div class="doc_text">
 
 <p>
-In order to compile and use LLVM, you will need to set some environment
-variables.  There are also some shell aliases which you may find useful.
-You can set these on the command line, or better yet, set them in your
-<tt>.cshrc</tt> or <tt>.profile</tt>.
+In order to compile and use LLVM, you may need to set some environment
+variables.
 
 <dl>
-    <dt><tt>LLVM_LIB_SEARCH_PATH</tt>=<tt><i>LLVMGCCDIR</i>/bytecode-libs</tt>
-    <dd>
-    This environment variable helps the LLVM GCC front end find bytecode
-    libraries that it will need for compilation.
-    <p>
-
-    <dt>alias llvmgcc <i>LLVMGCCDIR</i><tt>/bin/gcc</tt>
-    <dt>alias llvmg++ <i>LLVMGCCDIR</i><tt>/bin/g++</tt>
-    <dd>
-    This alias allows you to use the LLVM C and C++ front ends without putting
-    them in your <tt>PATH</tt> or typing in their complete pathnames.
+  <dt><tt>LLVM_LIB_SEARCH_PATH</tt>=<tt>/path/to/your/bytecode/libs</tt></dt>
+  <dd>[Optional] This environment variable helps LLVM linking tools find the
+  locations of your bytecode libraries. It is provided only as a
+  convenience since you can specify the paths using the -L options of the
+  tools and the C/C++ front-end will automatically use the bytecode files
+  installed in its
+  <tt>lib</tt> directory.</dd>
 </dl>
 
 </div>
@@ -562,34 +595,34 @@ You can set these on the command line, or better yet, set them in your
 <p>
 If you have the LLVM distribution, you will need to unpack it before you
 can begin to compile it.  LLVM is distributed as a set of two files: the LLVM
-suite and the LLVM GCC front end compiled for your platform.  Each
-file is a TAR archive that is compressed with the gzip program.
+suite and the LLVM GCC front end compiled for your platform.  There is an
+additional test suite that is optional.  Each file is a TAR archive that is
+compressed with the gzip program.
 </p>
 
-<p> The files are as follows:
+<p>The files are as follows, with <em>x.y</em> marking the version number:
 <dl>
-    <dt>llvm-1.3.tar.gz
-    <dd>This is the source code to the LLVM suite.
-    <p>
+  <dt><tt>llvm-x.y.tar.gz</tt></dt>
+  <dd>Source release for the LLVM libraries and tools.<br/></dd>
 
-    <dt>cfrontend-1.3.source.tar.gz
-    <dd>This is the source release of the GCC front end.
-    <p>
+  <dt><tt>llvm-test-x.y.tar.gz</tt></dt>
+  <dd>Source release for the LLVM test suite.</dd>
 
-    <dt>cfrontend-1.3.sparc-sun-solaris2.8.tar.gz
-    <dd>This is the binary release of the GCC front end for Solaris/Sparc.
-    <p>
+  <dt><tt>cfrontend-x.y.source.tar.gz</tt></dt>
+  <dd>Source release of the GCC front end.<br/></dd>
 
-    <dt>cfrontend-1.3.i686-redhat-linux-gnu.tar.gz
-    <dd>This is the binary release of the GCC front end for Linux/x86.
-    <p>
+  <dt><tt>cfrontend-x.y.sparc-sun-solaris2.8.tar.gz</tt></dt>
+  <dd>Binary release of the GCC front end for Solaris/Sparc.
+  <br/></dd>
 
-    <dt>cfrontend-1.3.i386-unknown-freebsd5.1.tar.gz
-    <dd>This is the binary release of the GCC front end for FreeBSD/x86.
-    <p>
+  <dt><tt>cfrontend-x.y.i686-redhat-linux-gnu.tar.gz</tt></dt>
+  <dd>Binary release of the GCC front end for Linux/x86.<br/></dd>
 
-    <dt>cfrontend-1.3.powerpc-apple-darwin7.0.0.tar.gz
-    <dd>This is the binary release of the GCC front end for MacOS X/PPC.
+  <dt><tt>cfrontend-x.y.i386-unknown-freebsd5.1.tar.gz</tt></dt>
+  <dd>Binary release of the GCC front end for FreeBSD/x86.<br/></dd>
+
+  <dt><tt>cfrontend-x.y.powerpc-apple-darwin7.8.0.tar.gz</tt></dt>
+  <dd>Binary release of the GCC front end for MacOS X/PPC.<br/></dd>
 </dl>
 
 </div>
@@ -619,15 +652,27 @@ test directories, and local copies of documentation files.</p>
 
 <p>If you want to get a specific release (as opposed to the most recent
 revision), you can specify a label.  The following releases have the following
-label:</p>
+labels:</p>
 
 <ul>
+<li>Release 1.5: <b>RELEASE_15</b></li>
+<li>Release 1.4: <b>RELEASE_14</b></li>
 <li>Release 1.3: <b>RELEASE_13</b></li>
 <li>Release 1.2: <b>RELEASE_12</b></li>
 <li>Release 1.1: <b>RELEASE_11</b></li>
 <li>Release 1.0: <b>RELEASE_1</b></li>
 </ul>
 
+<p>If you would like to get the LLVM test suite (a separate package as of 1.4),
+you get it from the CVS repository:</p>
+<pre>
+  cd llvm/projects
+  cvs -z3 -d :pserver:anon@llvm-cvs.cs.uiuc.edu:/var/cvs/llvm co llvm-test
+</pre>
+<p>By placing it in the <tt>llvm/projects</tt>, it will be automatically
+configured by the LLVM configure script as well as automatically updated when
+you run <tt>cvs update</tt>.</p>
+
 <p>If you would like to get the GCC front end source code, you can also get it
 from the CVS repository:</p>
 
@@ -636,7 +681,7 @@ from the CVS repository:</p>
 </pre>
 
 <p>Please note that you must follow <a href="CFEBuildInstrs.html">these 
-instructions</a> to successfully build the LLVM C front-end.</p>
+instructions</a> to successfully build the LLVM GCC front-end.</p>
 
 </div>
 
@@ -676,8 +721,7 @@ location must be specified when the LLVM suite is configured.</p>
       -</tt></li>
 </ol>
 
-<p>If you are using Solaris/Sparc or MacOS X/PPC, you will need to fix the
-header files:</p>
+<p>Next, you will need to fix your system header files:</p>
 
 <p><tt>cd cfrontend/<i>platform</i><br>
    ./fixheaders</tt></p>
@@ -701,10 +745,10 @@ not for the faint of heart, so be forewarned.</p>
 <div class="doc_text">
 
 <p>Once checked out from the CVS repository, the LLVM suite source code must be
-configured via the <tt>configure</tt> script.  This script sets variables in
-<tt>llvm/Makefile.config</tt> and <tt>llvm/include/Config/config.h</tt>.  It
-also populates <i>OBJ_ROOT</i> with the Makefiles needed to begin building
-LLVM.</p>
+configured via the <tt>configure</tt> script.  This script sets variables in the
+various <tt>*.in</tt> files, most notably <tt>llvm/Makefile.config</tt> and 
+<tt>llvm/include/Config/config.h</tt>.  It also populates <i>OBJ_ROOT</i> with 
+the Makefiles needed to begin building LLVM.</p>
 
 <p>The following environment variables are used by the <tt>configure</tt>
 script to configure the build system:</p>
@@ -730,47 +774,59 @@ script to configure the build system:</p>
 <p>The following options can be used to set or enable LLVM specific options:</p>
 
 <dl>
-  <dt><i>--with-llvmgccdir=LLVMGCCDIR</i>
-  <dd>
-    Path to the location where the LLVM GCC front end binaries and
-    associated libraries were installed.  This must be specified as an
-    absolute pathname.
-    <p>
-  <dt><i>--enable-optimized</i>
+  <dt><i>--with-llvmgccdir</i></dt>
+  <dd>Path to the LLVM C/C++ FrontEnd to be used with this LLVM configuration. 
+  The value of this option should specify the full pathname of the C/C++ Front
+  End to be used. If this option is not provided, the PATH will be searched for
+  a program named <i>llvm-gcc</i> and the C/C++ FrontEnd install directory will
+  be inferred from the path found. If the option is not given, and no llvm-gcc
+  can be found in the path then a warning will be produced by 
+  <tt>configure</tt> indicating this situation. LLVM may still be built with 
+  the <tt>tools-only</tt> target but attempting to build the runtime libraries
+  will fail as these libraries require llvm-gcc and llvm-g++. See 
+  <a href="#installcf">Install the GCC Front End</a> for details on installing
+  the C/C++ Front End. See
+  <a href="CFEBuildInstrs.html">Bootstrapping the LLVM C/C++ Front-End</a>
+  for details on building the C/C++ Front End.</dd>
+  <dt><i>--with-tclinclude</i></dt>
+  <dd>Path to the tcl include directory under which <tt>tclsh</tt> can be
+  found. Use this if you have multiple tcl installations on your machine and you
+  want to use a specific one (8.x) for LLVM. LLVM only uses tcl for running the
+  dejagnu based test suite in <tt>llvm/test</tt>. If you don't specify this
+  option, the LLVM configure script will search for the tcl 8.4 and 8.3
+  releases.
+  <p></p>
+  </dd>
+  <dt><i>--enable-optimized</i></dt>
   <dd>
     Enables optimized compilation by default (debugging symbols are removed
     and GCC optimization flags are enabled).  The default is to use an
     unoptimized build (also known as a debug build).
-    <p>
-  <dt><i>--enable-jit</i>
+    <p></p>
+  </dd>
+  <dt><i>--enable-jit</i></dt>
   <dd>
     Compile the Just In Time (JIT) compiler functionality.  This is not
     available
     on all platforms.  The default is dependent on platform, so it is best
     to explicitly enable it if you want it.
-    <p>
-  <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.
+    <p></p>
+  </dd>
+  <dt><i>--enable-targets=</i><tt>target-option</tt></dt>
+  <dd>Controls which targets will be built and linked into llc. The default 
+  value for <tt>target_options</tt> is "all" which builds and links all 
+  available targets.  The value "host-only" can be specified to build only a 
+  native compiler (no cross-compiler targets available). The "native" target is 
+  selected as the target of the build host. You can also specify a comma 
+  separated list of target names that you want available in llc. The target 
+  names use all lower case. The current set of targets is: <br/>
+  <tt>alpha, ia64, powerpc, skeleton, sparc, x86</tt>.
+  <p></p></dd>
+  <dt><i>--enable-doxygen</i></dt>
+  <dd>Look for the doxygen program and enable construction of doxygen based
+  documentation from the source code. This is disabled by default because 
+  generating the documentation can take a long time and producess 100s of 
+  megabytes of output.</dd>
 </dl>
 
 <p>To configure LLVM, follow these steps:</p>
@@ -783,20 +839,10 @@ script to configure the build system:</p>
 
     <li>Run the <tt>configure</tt> script located in the LLVM source tree:
     <br>
-    <tt><i>SRC_ROOT</i>/configure</tt>
+    <tt><i>SRC_ROOT</i>/configure --prefix=/install/path [other options]</tt>
     <p>
 </ol>
 
-<p>In addition to running <tt>configure</tt>, you must set the
-<tt>LLVM_LIB_SEARCH_PATH</tt> environment variable in your startup scripts.
-This environment variable is used to locate "system" libraries like
-"<tt>-lc</tt>" and "<tt>-lm</tt>" when linking.  This variable should be set to
-the absolute path of the <tt>bytecode-libs</tt> subdirectory of the GCC front
-end, or <i>LLVMGCCDIR</i>/<tt>bytecode-libs</tt>.  For example, one might set
-<tt>LLVM_LIB_SEARCH_PATH</tt> to
-<tt>/home/vadve/lattner/local/x86/llvm-gcc/bytecode-libs</tt> for the x86
-version of the GCC front end on our research machines.</p>
-
 </div>
 
 <!-- ======================================================================= -->
@@ -841,7 +887,7 @@ builds:</p>
 <p><tt>gmake</tt></p>
 
 <p>If the build fails, please <a href="#brokengcc">check here</a> to see if you
-are using a known broken version of GCC to compile LLVM with.</p>
+are using a version of GCC that is known not to compile LLVM.</p>
 
 <p>
 If you have multiple processors in your machine, you may wish to use some of
@@ -860,7 +906,7 @@ source code:</p>
   generated C/C++ files, libraries, and executables.
   <p>
 
-  <dt><tt>gmake distclean</tt>
+  <dt><tt>gmake dist-clean</tt>
   <dd>
   Removes everything that <tt>gmake clean</tt> does, but also removes files
   generated by <tt>configure</tt>.  It attempts to return the source tree to the
@@ -869,11 +915,13 @@ source code:</p>
 
   <dt><tt>gmake install</tt>
   <dd>
-  Installs LLVM libraries and tools in a heirarchy under $PREFIX, specified with
-  <tt>./configure --prefix=[dir]</tt>, defaults to <tt>/usr/local</tt>.
+  Installs LLVM header files, libraries, tools, and documentation in a
+  hierarchy 
+  under $PREFIX, specified with <tt>./configure --prefix=[dir]</tt>, which 
+  defaults to <tt>/usr/local</tt>.
   <p>
   
-  <dt><tt>gmake -C runtime install</tt>
+  <dt><tt>gmake -C runtime install-bytecode</tt>
   <dd>
   Assuming you built LLVM into $OBJDIR, when this command is run, it will 
   install bytecode libraries into the GCC front end's bytecode library 
@@ -882,6 +930,10 @@ source code:</p>
   <p>
 </dl>
 
+<p>Please see the <a href="MakefileGuide.html">Makefile Guide</a> for further
+details on these <tt>make</tt> targets and descriptions of other targets
+available.</p>
+
 <p>It is also possible to override default values from <tt>configure</tt> by
 declaring variables on the command line.  The following are some examples:</p>
 
@@ -900,6 +952,11 @@ declaring variables on the command line.  The following are some examples:</p>
   <dd>
   Print what <tt>gmake</tt> is doing on standard output.
   <p>
+
+  <dt><tt>gmake TOOL_VERBOSE=1</tt></dt>
+  <dd>Ask each tool invoked by the makefiles to print out what it is doing on 
+  the standard output. This also implies <tt>VERBOSE=1</tt>.
+  <p></dd>
 </dl>
 
 <p>Every directory in the LLVM object tree includes a <tt>Makefile</tt> to build
@@ -941,9 +998,9 @@ named after the build type:</p>
   <dd>
   <dl>
     <dt>Tools
-    <dd><tt><i>OBJ_ROOT</i>/tools/Debug</tt>
+    <dd><tt><i>OBJ_ROOT</i>/Debug/bin</tt>
     <dt>Libraries
-    <dd><tt><i>OBJ_ROOT</i>/lib/Debug</tt>
+    <dd><tt><i>OBJ_ROOT</i>/Debug/lib</tt>
   </dl>
   <p>
 
@@ -951,9 +1008,9 @@ named after the build type:</p>
   <dd>
   <dl>
     <dt>Tools
-    <dd><tt><i>OBJ_ROOT</i>/tools/Release</tt>
+    <dd><tt><i>OBJ_ROOT</i>/Release/bin</tt>
     <dt>Libraries
-    <dd><tt><i>OBJ_ROOT</i>/lib/Release</tt>
+    <dd><tt><i>OBJ_ROOT</i>/Release/lib</tt>
   </dl>
   <p>
 
@@ -961,9 +1018,9 @@ named after the build type:</p>
   <dd>
   <dl>
     <dt>Tools
-    <dd><tt><i>OBJ_ROOT</i>/tools/Profile</tt>
+    <dd><tt><i>OBJ_ROOT</i>/Profile/bin</tt>
     <dt>Libraries
-    <dd><tt><i>OBJ_ROOT</i>/lib/Profile</tt>
+    <dd><tt><i>OBJ_ROOT</i>/Profile/lib</tt>
   </dl>
 </dl>
 
@@ -977,18 +1034,21 @@ named after the build type:</p>
 <div class="doc_text">
 
 <p>
-If you're running on a linux system that supports the "<a
-href="http://www.tat.physik.uni-tuebingen.de/~rguenth/linux/binfmt_misc.html">binfmt_misc</a>"
+If you're running on a Linux system that supports the "<a
+  href="http://www.tat.physik.uni-tuebingen.de/~rguenth/linux/binfmt_misc.html">
+  binfmt_misc</a>"
 module, and you have root access on the system, you can set your system up to
 execute LLVM bytecode files directly.  To do this, use commands like this (the
 first command may not be required if you are already using the module):</p>
 
+<div class="doc_code">
 <pre>
    $ mount -t binfmt_misc none /proc/sys/fs/binfmt_misc
-   $ echo ':llvm:M::llvm::/path/to/lli:' > /proc/sys/fs/binfmt_misc/register
+   $ echo ':llvm:M::llvm::/path/to/lli:' &gt; /proc/sys/fs/binfmt_misc/register
    $ chmod u+x hello.bc                (if needed)
    $ ./hello.bc
 </pre>
+</div>
 
 <p>
 This allows you to execute LLVM bytecode files directly.  Thanks to Jack
@@ -1015,17 +1075,20 @@ The following is a brief introduction to code layout:</p>
 
 <!-- ======================================================================= -->
 <div class="doc_subsection"><a name="cvsdir"><tt>CVS</tt> directories</a></div>
-
 <div class="doc_text">
-
 <p>Every directory checked out of CVS will contain a <tt>CVS</tt> directory; for
 the most part these can just be ignored.</p>
+</div>
 
+<!-- ======================================================================= -->
+<div class="doc_subsection"><a name="examples"><tt>llvm/examples</tt></a></div>
+<div class="doc_text">
+  <p>This directory contains some simple examples of how to use the LLVM IR and
+  JIT.</p>
 </div>
 
 <!-- ======================================================================= -->
 <div class="doc_subsection"><a name="include"><tt>llvm/include</tt></a></div>
-
 <div class="doc_text">
 
 <p>This directory contains public header files exported from the LLVM
@@ -1054,7 +1117,6 @@ library. The three main subdirectories of this directory are:</p>
 
 <!-- ======================================================================= -->
 <div class="doc_subsection"><a name="lib"><tt>llvm/lib</tt></a></div>
-
 <div class="doc_text">
 
 <p>This directory contains most of the source files of the LLVM system. In LLVM,
@@ -1088,7 +1150,7 @@ different <a href="#tools">tools</a>.</p>
   <dd> This directory contains files that describe various target architectures
   for code generation.  For example, the <tt>llvm/lib/Target/SparcV9</tt> 
   directory holds the Sparc machine description while
-  <tt>llvm/lib/Target/CBackend</tt> implements the LLVM-to-C converter</dd>
+  <tt>llvm/lib/Target/CBackend</tt> implements the LLVM-to-C converter.</dd>
     
   <dt><tt><b>llvm/lib/CodeGen/</b></tt></dt>
   <dd> This directory contains the major parts of the code generator: Instruction 
@@ -1114,6 +1176,16 @@ different <a href="#tools">tools</a>.</p>
 
 </div>
 
+<!-- ======================================================================= -->
+<div class="doc_subsection"><a name="projects"><tt>llvm/projects</tt></a></div>
+<div class="doc_text">
+  <p>This directory contains projects that are not strictly part of LLVM but are
+  shipped with LLVM. This is also the directory where you should create your own
+  LLVM-based projects. See <tt>llvm/projects/sample</tt> for an example of how
+  to set up your own project. See <tt>llvm/projects/Stacker</tt> for a fully 
+  functional example of a compiler front end.</p>
+</div>
+
 <!-- ======================================================================= -->
 <div class="doc_subsection"><a name="runtime"><tt>llvm/runtime</tt></a></div>
 <div class="doc_text">
@@ -1139,12 +1211,13 @@ end to compile.</p>
 <!-- ======================================================================= -->
 <div class="doc_subsection"><a name="llvmtest"><tt>llvm-test</tt></a></div>
 <div class="doc_text">
-  <p>This is not a directory in the normal llvm module, it is a separate CVS
+  <p>This is not a directory in the normal llvm module; it is a separate CVS
   module that must be checked out (usually to <tt>projects/llvm-test</tt>). This
-  module contains a comprehensive correctness, performance and benchmarking test
+  module contains a comprehensive correctness, performance, and benchmarking
+  test
   suite for LLVM. It is a separate CVS module because not every LLVM user is
-  interested in downloading or building such a comprehensive test. For further
-  details on this test suite, please see the 
+  interested in downloading or building such a comprehensive test suite. For
+  further details on this test suite, please see the 
   <a href="TestingGuide.html">Testing Guide</a> document.</p>
 </div>
 
@@ -1179,7 +1252,9 @@ information is in the <a href="CommandGuide/index.html">Command Guide</a>.</p>
   pre-processing, translation, optimization, assembly, and linking of programs
   all from one command line. <tt>llvmc</tt> also takes care of processing the
   dependent libraries found in bytecode. This reduces the need to get the
-  traditional <tt>-l&lt;name&gt;</tt> options right on the command line.</dd>
+  traditional <tt>-l&lt;name&gt;</tt> options right on the command line. Please
+  note that this tool, while functional, is still experimental and not feature
+  complete.</dd>
 
   <dt><tt><b>llvm-ar</b></tt></dt>
   <dd>The archiver produces an archive containing
@@ -1194,6 +1269,13 @@ information is in the <a href="CommandGuide/index.html">Command Guide</a>.</p>
   <dd>The disassembler transforms the LLVM bytecode to human readable 
   LLVM assembly.</dd>
 
+  <dt><tt><b>llvm-ld</b></tt></dt>
+  <dd><tt>llvm-ld</tt> is very similar to gccld and provides a general purpose
+  and extensible linker for LLVM. This is the linker invoked by <tt>llvmc</tt>.
+  It allows optimization modules to be loaded so that language specific
+  optimizations can be applied at link time. This tool is considered
+  experimental.</dd>
+
   <dt><tt><b>llvm-link</b></tt></dt>
   <dd><tt>llvm-link</tt>, not surprisingly, links multiple LLVM modules into 
   a single program.</dd>
@@ -1203,31 +1285,30 @@ information is in the <a href="CommandGuide/index.html">Command Guide</a>.</p>
   can directly execute LLVM bytecode (although very slowly...). In addition
   to a simple interpreter, <tt>lli</tt> also has a tracing mode (entered by
   specifying <tt>-trace</tt> on the command line). Finally, for
-  architectures that support it (currently only x86 and Sparc), by default,
+  architectures that support it (currently x86, Sparc, and PowerPC), by default,
   <tt>lli</tt> will function as a Just-In-Time compiler (if the
   functionality was compiled in), and will execute the code <i>much</i>
   faster than the interpreter.</dd>
 
   <dt><tt><b>llc</b></tt></dt>
   <dd> <tt>llc</tt> is the LLVM backend compiler, which
-  translates LLVM bytecode to a SPARC or x86 assembly file, or to C code (with
+  translates LLVM bytecode to a native code assembly file or to C code (with
   the -march=c option).</dd>
 
-  <dt><tt><b>llvmgcc</b></tt></dt>
-  <dd><tt>llvmgcc</tt> is a GCC-based C frontend
+  <dt><tt><b>llvm-gcc</b></tt></dt>
+  <dd><tt>llvm-gcc</tt> is a GCC-based C frontend
   that has been retargeted to emit LLVM code as the machine code output.  It
   works just like any other GCC compiler, taking the typical <tt>-c, -S, -E,
   -o</tt> options that are typically used.  The source code for the
-  <tt>llvmgcc</tt> tool is currently not included in the LLVM CVS tree
-  because it is quite large and not very interesting.
+  <tt>llvm-gcc</tt> tool is available as a separate CVS module.
   <blockquote>
     <dl>
       <dt><tt><b>gccas</b></tt></dt>
-      <dd>This tool is invoked by the <tt>llvmgcc</tt> frontend as the 
+      <dd>This tool is invoked by the <tt>llvm-gcc</tt> frontend as the 
       "assembler" part of the compiler.  This tool actually assembles LLVM 
       assembly to LLVM bytecode, performs a variety of optimizations, and 
       outputs LLVM bytecode.  Thus when you invoke 
-      <tt>llvmgcc -c x.c -o x.o</tt>, you are causing <tt>gccas</tt> to be 
+      <tt>llvm-gcc -c x.c -o x.o</tt>, you are causing <tt>gccas</tt> to be 
       run, which writes the <tt>x.o</tt> file (which is an LLVM bytecode file 
       that can be disassembled or manipulated just like any other bytecode 
       file).  The command line interface to <tt>gccas</tt> is designed to be 
@@ -1331,6 +1412,15 @@ are code generators for parts of LLVM infrastructure.</p>
 
 </div>
 
+<!-- ======================================================================= -->
+<div class="doc_subsection"><a name="win32"><tt>llvm/win32</tt></a></div>
+<div class="doc_text">
+  <p>This directory contains build scripts and project files for use with 
+  Visual C++. This allows developers on Windows to build LLVM without the need
+  for Cygwin. The contents of this directory should be considered experimental
+  at this time.
+  </p>
+</div>
 <!-- *********************************************************************** -->
 <div class="doc_section">
   <a name="tutorial">An Example Using the LLVM Tool Chain</a>
@@ -1350,7 +1440,7 @@ are code generators for parts of LLVM infrastructure.</p>
        </pre></li>
 
   <li><p>Next, compile the C file into a LLVM bytecode file:</p>
-      <p><tt>% llvmgcc hello.c -o hello</tt></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>

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/Lexicon.html

@@ -19,53 +19,42 @@
     <tr><th colspan="8"><b>- <a href="#A">A</a> -</b></th></tr>
     <tr>
       <td><a href="#ADCE">ADCE</a></td>
-      <td></td>
-      <td></td>
     </tr>
     <tr><th colspan="8"><b>- <a href="#B">B</a> -</b></th></tr>
     <tr>
       <td><a href="#BURS">BURS</a></td>
-      <td></td>
-      <td></td>
     </tr>
     <tr><th colspan="8"><b>- <a href="#C">C</a> -</b></th></tr>
     <tr>
       <td><a href="#CSE">CSE</a></td>
-      <td></td>
-      <td></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>
-      <td></td>
-      <td></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>
-      <td></td>
-      <td></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>
-      <td></td>
-      <td></td>
     </tr>
     <tr><th colspan="8"><b>- <a href="#P">P</a> -</b></th></tr>
     <tr>
       <td><a href="#PRE">PRE</a></td>
-      <td></td>
-      <td></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>
-      <td></td>
     </tr>
   </table>
 </div>
@@ -136,6 +125,7 @@ href="http://www.program-transformation.org/Transform/BURG">BURG</a> tool.</dd>
     <dd>Load Value Numbering</dd>
   </dl>
 </div>
+
 <!-- _______________________________________________________________________ -->
 <div class="doc_subsection"><a name="P">- P -</a></div>
 <div class="doc_text">
@@ -144,6 +134,18 @@ href="http://www.program-transformation.org/Transform/BURG">BURG</a> tool.</dd>
     <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">

llvm/docs/Makefile

@@ -12,10 +12,11 @@ DIRS       := CommandGuide
 
 include $(LEVEL)/Makefile.common
 
-HTML       := $(wildcard $(BUILD_SRC_DIR)/*.html) \
-              $(wildcard $(BUILD_SRC_DIR)/*.css)
-IMAGES     := $(wildcard $(BUILD_SRC_DIR)/img/*.*)
-DOXYFILES  := $(wildcard $(BUILD_SRC_DIR)/doxygen.*)
+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
@@ -26,37 +27,40 @@ else
 install-local:: install-html
 endif
 
-install-html: $(BUILD_OBJ_DIR)/html.tar.gz
+install-html: $(PROJ_OBJ_DIR)/html.tar.gz
 	$(Echo) Installing HTML documentation
-	$(Verb) $(INSTALL) -d $(LLVM_DOCSDIR)/html
-	$(Verb) $(INSTALL) -d $(LLVM_DOCSDIR)/html/img
-	$(Verb) $(INSTALL) -C $(HTML) $(LLVM_DOCSDIR)/html
-	$(Verb) $(INSTALL) -C $(IMAGES) $(LLVM_DOCSDIR)/html/img
-	$(Verb) $(INSTALL) -C $(BUILD_OBJ_DIR)/html.tar.gz $(LLVM_DOCSDIR)
+	$(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)
 
-$(BUILD_OBJ_DIR)/html.tar.gz: $(HTML)
+$(PROJ_OBJ_DIR)/html.tar.gz: $(HTML)
 	$(Echo) Packaging HTML documentation
-	$(Verb) $(RM) -rf $@ $(BUILD_OBJ_DIR)/html.tar
-	$(Verb) cd $(BUILD_SRC_DIR) && \
-	  $(TAR) cf $(BUILD_OBJ_DIR)/html.tar *.html
-	$(Verb) $(GZIP) $(BUILD_OBJ_DIR)/html.tar
+	$(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) $(INSTALL) -d $(LLVM_DOCSDIR)/html/doxygen
-	$(Verb) $(INSTALL) $(BUILD_OBJ_DIR)/doxygen.tar.gz $(LLVM_DOCSDIR)
-	$(Verb) cd $(BUILD_OBJ_DIR)/doxygen && \
+	$(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 \
-	    $(INSTALL) -C {} $(LLVM_DOCSDIR)/html/doxygen \;
+	    $(DataInstall) {} $(PROJ_docsdir)/html/doxygen \;
 
-doxygen: $(BUILD_OBJ_DIR)/doxygen.tar.gz
+doxygen: $(PROJ_OBJ_DIR)/doxygen.tar.gz
 
-$(BUILD_OBJ_DIR)/doxygen.tar.gz: $(DOXYFILES) $(BUILD_OBJ_DIR)/doxygen.cfg
+$(PROJ_OBJ_DIR)/doxygen.tar.gz: $(DOXYFILES) $(PROJ_OBJ_DIR)/doxygen.cfg
 	$(Echo) Building doxygen documentation
-	$(Verb) $(DOXYGEN) $(BUILD_OBJ_DIR)/doxygen.cfg
+	$(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 $@ $(BUILD_OBJ_DIR)/doxygen.tar
-	$(Verb) $(TAR) cf $(BUILD_OBJ_DIR)/doxygen.tar doxygen
-	$(Verb) $(GZIP) $(BUILD_OBJ_DIR)/doxygen.tar
+	$(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/MakefileGuide.html

@@ -28,12 +28,17 @@
   </li>
   <li><a href="#tutorial">Tutorial</a>
     <ol>
-      <li><a href="#libraries">Libraries</a></li>
+      <li><a href="#libraries">Libraries</a>
+        <ol>
+	  <li><a href="#Modules">Bytecode Modules</a></li>
+	</ol>
+      </li>
       <li><a href="#tools">Tools</a>
         <ol>
 	  <li><a href="#JIT">JIT Tools</a></li>
 	</ol>
       </li>
+      <li><a href="#projects">Projects</a></li>
     </ol>
   </li>
   <li><a href="#targets">Targets Supported</a>
@@ -41,6 +46,7 @@
       <li><a href="#all">all</a></li>
       <li><a href="#all-local">all-local</a></li>
       <li><a href="#check">check</a></li>
+      <li><a href="#check-local">check-local</a></li>
       <li><a href="#clean">clean</a></li>
       <li><a href="#clean-local">clean-local</a></li>
       <li><a href="#dist">dist</a></li>
@@ -49,6 +55,8 @@
       <li><a href="#install">install</a></li>
       <li><a href="#preconditions">preconditions</a></li>
       <li><a href="#printvars">printvars</a></li>
+      <li><a href="#reconfigure">reconfigure</a></li>
+      <li><a href="#spotless">spotless</a></li>
       <li><a href="#tags">tags</a></li>
       <li><a href="#uninstall">uninstall</a></li>
     </ol>
@@ -108,10 +116,15 @@
   software, but it can build yours too. Built into the system is knowledge of
   the <tt>llvm/projects</tt> directory. Any directory under <tt>projects</tt>
   that has both a <tt>configure</tt> script and a <tt>Makefile</tt> is assumed
-  to be a project that uses the LLVM Makefile system. This allows your project
+  to be a project that uses the LLVM Makefile system.  Building software that
+  uses LLVM does not require the LLVM Makefile System nor even placement in the
+  <tt>llvm/projects</tt> directory. However, doing so will allow your project
   to get up and running quickly by utilizing the built-in features that are used
   to compile LLVM. LLVM compiles itself using the same features of the makefile
   system as used for projects.</p>
+  <p>For complete details on setting up your projects configuration, simply
+  mimic the <tt>llvm/projects/sample</tt> project or for further details, 
+  consult the <a href="Projects.html">Projects.html</a> page.</p>
 </div>
 
 <!-- ======================================================================= -->
@@ -195,7 +208,7 @@
 <div class="doc_subsection"><a name="Comments">Comments</a></div>
 <div class="doc_text">
   <p>User Makefiles need not have comments in them unless the construction is
-  unusual or it doesn't strictly follow the rules and patterns of the LLVM
+  unusual or it does not strictly follow the rules and patterns of the LLVM
   makefile system. Makefile comments are invoked with the pound (#) character.
   The # character and any text following it, to the end of the line, are ignored
   by <tt>make</tt>.</p>
@@ -233,6 +246,37 @@
   Note that you normally do not need to specify the sources involved. The LLVM
   Makefile system will infer the source files from the contents of the source
   directory.</p>
+  <p>The <tt>LOADABLE_MODULE=1</tt> directive can be used in conjunction with
+  <tt>SHARED_LIBRARY=1</tt> to indicate that the resulting shared library should
+  be openable with the <tt>dlopen</tt> function and searchable with the
+  <tt>dlsym</tt> function (or your operating system's equivalents). While this
+  isn't strictly necessary on Linux and a few other platforms, it is required
+  on systems like HP-UX and Darwin. You should use <tt>LOADABLE_MODULE</tt> for
+  any shared library that you intend to be loaded into an tool via the
+  <tt>-load</tt> option. See the 
+  <a href="WritingAnLLVMPass.html#makefile">WritingAnLLVMPass.html</a> document
+  for an example of why you might want to do this.
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsubsection"><a name="Modules">Bytecode Modules</a></div>
+<div class="doc_text">
+  <p>In some situations, it is desireable to build a single bytecode module from
+  a variety of sources, instead of an archive, shared library, or bytecode 
+  library. Bytecode modules can be specified in addition to any of the other
+  types of libraries by defining the <a href="#MODULE_NAME">MODULE_NAME</a>
+  variable. For example:</p>
+  <pre><tt>
+      LIBRARYNAME = mylib
+      BYTECODE_LIBRARY = 1
+      MODULE_NAME = mymod
+  </tt></pre>
+  <p>will build a module named <tt>mymod.bc</tt> from the sources in the
+  directory. This module will be an aggregation of all the bytecode modules 
+  derived from the sources. The example will also build a bytecode archive 
+  containing a bytecode module for each compiled source file. The difference is
+  subtle, but important depending on how the module or library is to be linked.
+  </p>
 </div>
 
 <!-- ======================================================================= -->
@@ -312,11 +356,13 @@
 <div class="doc_text">
   <p>This section describes each of the targets that can be built using the LLVM
   Makefile system. Any target can be invoked from any directory but not all are
-  applicable to a given directory (e.g. "check", "dist", and "install" will
+  applicable to a given directory (e.g. "check", "dist" and "install" will
   always operate as if invoked from the top level directory).</p>
 
   <table style="text-align:left">
-    <tr><th>Target Name</th><th>Implied Targets</th><th>Target Description</th></tr>
+    <tr>
+      <th>Target Name</th><th>Implied Targets</th><th>Target Description</th>
+    </tr>
     <tr><td><a href="#all"><tt>all</tt></a></td><td></td>
       <td>Compile the software recursively. Default target.
     </td></tr>
@@ -324,7 +370,12 @@
       <td>Compile the software in the local directory only.
     </td></tr>
     <tr><td><a href="#check"><tt>check</tt></a></td><td></td>
-      <td>Change to the llvm/test directory and run regression tests.
+      <td>Change to the <tt>test</tt> directory in a project and run the
+      test suite there.
+    </td></tr>
+    <tr><td><a href="#check-local"><tt>check-local</tt></a></td><td></td>
+      <td>Run a local test suite. Generally this is only defined in the 
+        <tt>Makefile</tt> of the project's <tt>test</tt> directory.
     </td></tr>
     <tr><td><a href="#clean"><tt>clean</tt></a></td><td></td>
       <td>Remove built objects recursively.
@@ -335,7 +386,7 @@
     <tr><td><a href="#dist"><tt>dist</tt></a></td><td>all</td>
       <td>Prepare a source distribution tarball.
     </td></tr>
-    <tr><td><a href="#dist-check"><tt>dist-check</tt></a></td><td>all check</td>
+    <tr><td><a href="#dist-check"><tt>dist-check</tt></a></td><td>all</td>
       <td>Prepare a source distribution tarball and check that it builds.
     </td></tr>
     <tr><td><a href="#dist-clean"><tt>dist-clean</tt></a></td><td>clean</td>
@@ -377,12 +428,41 @@
   the current directory instead of recursively.</p>
 </div>
 
+<!-- ======================================================================= -->
+<div class="doc_subsection"><a name="check">check</a></div>
+<div class="doc_text">
+  <p>This target can be invoked from anywhere within a project's directories
+  but always invokes the <a href="#check-local"><tt>check-local</tt></a> target 
+  in the project's <tt>test</tt> directory, if it exists and has a 
+  <tt>Makefile</tt>. A warning is produced otherwise.  If 
+  <a href="#TESTSUITE"><tt>TESTSUITE</tt></a> is defined on the <tt>make</tt>
+  command line, it will be passed down to the invocation of 
+  <tt>make check-local</tt> in the <tt>test</tt> directory. The intended usage 
+  for this is to assist in running specific suites of tests. If
+  <tt>TESTSUITE</tt> is not set, the implementation of <tt>check-local</tt> 
+  should run all normal tests.  It is up to the project to define what 
+  different values for <tt>TESTSUTE</tt> will do. See the 
+  <a href="TestingGuide.html">TestingGuide</a> for further details.</p>
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection"><a name="check-local">check-local</a></div>
+<div class="doc_text">
+  <p>This target should be implemented by the <tt>Makefile</tt> in the project's
+  <tt>test</tt> directory. It is invoked by the <tt>check</tt> target elsewhere.
+  Each project is free to define the actions of <tt>check-local</tt> as 
+  appropriate for that project. The LLVM project itself uses dejagnu to run a 
+  suite of feature and regresson tests. Other projects may choose to use 
+  dejagnu or any other testing mechanism.</p>
+</div>
+
 <!-- ======================================================================= -->
 <div class="doc_subsection"><a name="clean">clean</a></div>
 <div class="doc_text">
   <p>This target cleans the build directory, recursively removing all things
-  that the Makefile builds. Despite once or twice attempting to remove /*, the
-  cleaning rules have been made guarded so they shouldn't go awry.</p>
+  that the Makefile builds. The cleaning rules have been made guarded so they 
+  shouldn't go awry (via <tt>rm -f $(UNSET_VARIABLE)/*</tt> which will attempt
+  to erase the entire directory structure.</p>
 </div>
 
 <!-- ======================================================================= -->
@@ -453,8 +533,30 @@
 <!-- ======================================================================= -->
 <div class="doc_subsection"><a name="printvars">printvars</a></div>
 <div class="doc_text">
-  <p>This utility target just causes LLVM to print out some of its variables so
-  that you can double check how things are set. </p>
+  <p>This utility target just causes the LLVM makefiles to print out some of 
+  the makefile variables so that you can double check how things are set. </p>
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection"><a name="reconfigure">reconfigure</a></div>
+<div class="doc_text">
+  <p>This utility target will force a reconfigure of LLVM or your project. It 
+  simply runs <tt>$(PROJ_OBJ_ROOT)/config.status --recheck</tt> to rerun the
+  configuration tests and rebuild the configured files. This isn't generally
+  useful as the makefiles will reconfigure themselves whenever its necessary.
+  </p>
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection"><a name="spotless">spotless</a></div>
+<div class="doc_text">
+  <p>This utility target, only available when <tt>$(PROJ_OBJ_ROOT)</tt> is not 
+  the same as <tt>$(PROJ_SRC_ROOT)</tt>, will completely clean the
+  <tt>$(PROJ_OBJ_ROOT)</tt> directoy by removing its content entirely and 
+  reconfiguring the directory. This returns the <tt>$(PROJ_OBJ_ROOT)</tt> 
+  directory to a completely fresh state. All content in the directory except 
+  configured files and top-level makefiles will be lost.</p>
+  <div class="doc_warning"><p>Use with caution.</p></div>
 </div>
 
 <!-- ======================================================================= -->
@@ -544,6 +646,14 @@
     source files, all built sources, all Makefiles, and most documentation files 
     will be automatically distributed. Use this variable to distribute any 
     files that are not automatically distributed.</dd>
+    <dt><a name="FAKE_SOURCES"><tt>FAKE_SOURCES</tt><small>(optional)</small>
+    </a></dt>
+    <dd>This variable is like <a href="#SOURCES"><tt>SOURCES</tt></a> except that
+    the source files don't need to exist. The makefiles only use
+    <tt>FAKE_SOURCES</tt> to create the names of derived objects that should be
+    included in the directory's result. It is assumed that the project's
+    <tt>Makefile</tt> will define how to build the derived objects
+    necessary.</dd>
     <dt><a name="KEEP_SYMBOLS"><tt>KEEP_SYMBOLS</tt></a></dt>
     <dd>If set to any value, specifies that when linking executables the
     makefiles should retain debug symbols in the executable. Normally, symbols
@@ -558,6 +668,12 @@
     <dt><a name="LLVMLIBS"><tt>LLVMLIBS</tt></a></dt>
     <dd>Specifies the set of libraries from the LLVM $(ObjDir) that will be
     linked into the tool or library.</dd>
+    <dt><a name="LOADABLE_MODULE"><tt>LOADABLE_MODULE</tt></a></dt>
+    <dd>If set to any value, causes the shared library being built to also be
+    a loadable module. Loadable modules can be opened with the dlopen() function
+    and searched with dlsym (or the operating system's equivalent). Note that
+    setting this variable without also setting <tt>SHARED_LIBRARY</tt> will have
+    no effect.</dd>
     <dt><a name="MODULE_NAME"><tt>MODULE_NAME</tt></a></dt>
     <dd>Specifies the name of a bytecode module to be created. A bytecode 
     module can be specified in conjunction with other kinds of library builds 
@@ -588,6 +704,8 @@
     <dd>Specifies the name of the LLVM code generation target that the
     current directory builds. Setting this variable enables additional rules to
     build <tt>.inc</tt> files from <tt>.td</tt> files. </dd>
+    <dt><a name="TESTSUITE"><tt>TESTSUITE</tt></a></dt>
+    <dd>Specifies the directory of tests to run in <tt>llvm/test</tt>.</dd>
     <dt><a name="TOOLNAME"><tt>TOOLNAME</tt></a></dt>
     <dd>Specifies the name of the tool that the current directory should
     build.</dd>
@@ -619,18 +737,18 @@
     <li>In the Makefile (only <em>after</em> the inclusion of <a
     href="#Makefile.common"><tt>$(LEVEL)/Makefile.common</tt></a>).</li>
   </ul>
-  <p>The overridable variables are given below:</p>
+  <p>The override variables are given below:</p>
   <dl>
     <dt><a name="AR"><tt>AR</tt></a> <small>(defaulted)</small></dt>
     <dd>Specifies the path to the <tt>ar</tt> tool.</dd>
     <dt><a name="BISON"><tt>BISON</tt></a><small>(configured)</small></dt>
     <dd>Specifies the path to the <tt>bison</tt> tool.</dd>
-    <dt><a name="BUILD_OBJ_DIR"><tt>BUILD_OBJ_DIR</tt></a></dt>
+    <dt><a name="PROJ_OBJ_DIR"><tt>PROJ_OBJ_DIR</tt></a></dt>
     <dd>The directory into which the products of build rules will be placed.
     This might be the same as 
-    <a href="#BUILD_SRC_DIR"><tt>BUILD_SRC_DIR</tt></a> but typically is
+    <a href="#PROJ_SRC_DIR"><tt>PROJ_SRC_DIR</tt></a> but typically is
     not.</dd>
-    <dt><a name="BUILD_SRC_DIR"><tt>BUILD_SRC_DIR</tt></a></dt>
+    <dt><a name="PROJ_SRC_DIR"><tt>PROJ_SRC_DIR</tt></a></dt>
     <dd>The directory which contains the source files to be built.</dd>
     <dt><a name="BURG"><tt>BURG</tt></a></dt>
     <dd>Specifies the path to the <tt>burg</tt> tool.</dd>
@@ -772,7 +890,8 @@
     <dd>The configuration specific directory into which executables are placed
     before they are installed.</dd>
     <dt><a name="TopDistDir"><tt>TopDistDir</tt></a></dt>
-    <dd>The top most directory into which the distribution files are copied.</dd>
+    <dd>The top most directory into which the distribution files are copied.
+    </dd>
     <dt><a name="Verb"><tt>Verb</tt></a></dt>
     <dd>Use this as the first thing on your build script lines to enable or
     disable verbose mode. It expands to either an @ (quiet mode) or nothing
@@ -786,83 +905,88 @@
   <p>Variables listed below are used by the LLVM Makefile System 
   and considered internal. You should not use these variables under any
   circumstances.</p>
-  <dl>
-    <dt><a name="Archive"><tt>Archive</tt></a></dt><dd></dd>
-    <dt><a name="AR.Flags"><tt>AR.Flags</tt></a></dt><dd></dd>
-    <dt><a name="BaseNameSources"><tt>BaseNameSources</tt></a></dt><dd></dd>
-    <dt><a name="BCCompile.C"><tt>BCCompile.C</tt></a></dt><dd></dd>
-    <dt><a name="BCCompile.CXX"><tt>BCCompile.CXX</tt></a></dt><dd></dd>
-    <dt><a name="BCLinkLib"><tt>BCLinkLib</tt></a></dt><dd></dd>
-    <dt><a name="Burg"><tt>Burg</tt></a></dt><dd></dd>
-    <dt><a name="C.Flags"><tt>C.Flags</tt></a></dt><dd></dd>
-    <dt><a name="Compile.C"><tt>Compile.C</tt></a></dt><dd></dd>
-    <dt><a name="CompileCommonOpts"><tt>CompileCommonOpts</tt></a></dt><dd></dd>
-    <dt><a name="Compile.CXX"><tt>Compile.CXX</tt></a></dt><dd></dd>
-    <dt><a name="ConfigStatusScript"><tt>ConfigStatusScript</tt></a></dt><dd></dd>
-    <dt><a name="ConfigureScript"><tt>ConfigureScript</tt></a></dt><dd></dd>
-    <dt><a name="CPP.Flags"><tt>CPP.Flags</tt></a></dt><dd></dd>
-    <dt><a name="CPP.Flags "><tt>CPP.Flags </tt></a></dt><dd></dd>
-    <dt><a name="CXX.Flags"><tt>CXX.Flags</tt></a></dt><dd></dd>
-    <dt><a name="DependFiles"><tt>DependFiles</tt></a></dt><dd></dd>
-    <dt><a name="DestArchiveLib"><tt>DestArchiveLib</tt></a></dt><dd></dd>
-    <dt><a name="DestBytecodeLib"><tt>DestBytecodeLib</tt></a></dt><dd></dd>
-    <dt><a name="DestRelinkedLib"><tt>DestRelinkedLib</tt></a></dt><dd></dd>
-    <dt><a name="DestSharedLib"><tt>DestSharedLib</tt></a></dt><dd></dd>
-    <dt><a name="DestTool"><tt>DestTool</tt></a></dt><dd></dd>
-    <dt><a name="DistAlways"><tt>DistAlways</tt></a></dt><dd></dd>
-    <dt><a name="DistCheckDir"><tt>DistCheckDir</tt></a></dt><dd></dd>
-    <dt><a name="DistCheckTop"><tt>DistCheckTop</tt></a></dt><dd></dd>
-    <dt><a name="DistFiles"><tt>DistFiles</tt></a></dt><dd></dd>
-    <dt><a name="DistName"><tt>DistName</tt></a></dt><dd></dd>
-    <dt><a name="DistOther"><tt>DistOther</tt></a></dt><dd></dd>
-    <dt><a name="DistSources"><tt>DistSources</tt></a></dt><dd></dd>
-    <dt><a name="DistSubDirs"><tt>DistSubDirs</tt></a></dt><dd></dd>
-    <dt><a name="DistTarBZ2"><tt>DistTarBZ2</tt></a></dt><dd></dd>
-    <dt><a name="DistTarGZip"><tt>DistTarGZip</tt></a></dt><dd></dd>
-    <dt><a name="DistZip"><tt>DistZip</tt></a></dt><dd></dd>
-    <dt><a name="ExtraLibs"><tt>ExtraLibs</tt></a></dt><dd></dd>
-    <dt><a name="INCFiles"><tt>INCFiles</tt></a></dt><dd></dd>
-    <dt><a name="InternalTargets"><tt>InternalTargets</tt></a></dt><dd></dd>
-    <dt><a name="LD.Flags"><tt>LD.Flags</tt></a></dt><dd></dd>
-    <dt><a name="LexOutput"><tt>LexOutput</tt></a></dt><dd></dd>
-    <dt><a name="LibName.A"><tt>LibName.A</tt></a></dt><dd></dd>
-    <dt><a name="LibName.BC"><tt>LibName.BC</tt></a></dt><dd></dd>
-    <dt><a name="LibName.LA"><tt>LibName.LA</tt></a></dt><dd></dd>
-    <dt><a name="LibName.O"><tt>LibName.O</tt></a></dt><dd></dd>
-    <dt><a name="LibTool.Flags"><tt>LibTool.Flags</tt></a></dt><dd></dd>
-    <dt><a name="Link"><tt>Link</tt></a></dt><dd></dd>
-    <dt><a name="LLVMGCCLibDir"><tt>LLVMGCCLibDir</tt></a></dt><dd></dd>
-    <dt><a name="LLVMLibDir"><tt>LLVMLibDir</tt></a></dt><dd></dd>
-    <dt><a name="LLVMLibsOptions"><tt>LLVMLibsOptions</tt></a></dt><dd></dd>
-    <dt><a name="LLVMLibsPaths"><tt>LLVMLibsPaths</tt></a></dt><dd></dd>
-    <dt><a name="LLVMToolDir"><tt>LLVMToolDir</tt></a></dt><dd></dd>
-    <dt><a name="LLVMUsedLibs"><tt>LLVMUsedLibs</tt></a></dt><dd></dd>
-    <dt><a name="LocalTargets"><tt>LocalTargets</tt></a></dt><dd></dd>
-    <dt><a name="LTCompile.C"><tt>LTCompile.C</tt></a></dt><dd></dd>
-    <dt><a name="LTCompile.CXX"><tt>LTCompile.CXX</tt></a></dt><dd></dd>
-    <dt><a name="LTInstall"><tt>LTInstall</tt></a></dt><dd></dd>
-    <dt><a name="ObjectsBC"><tt>ObjectsBC</tt></a></dt><dd></dd>
-    <dt><a name="ObjectsLO"><tt>ObjectsLO</tt></a></dt><dd></dd>
-    <dt><a name="ObjectsO"><tt>ObjectsO</tt></a></dt><dd></dd>
-    <dt><a name="ObjMakefiles"><tt>ObjMakefiles</tt></a></dt><dd></dd>
-    <dt><a name="Parallel_Targets"><tt>Parallel_Targets</tt></a></dt><dd></dd>
-    <dt><a name="PreConditions"><tt>PreConditions</tt></a></dt><dd></dd>
-    <dt><a name="ProjLibsOptions"><tt>ProjLibsOptions</tt></a></dt><dd></dd>
-    <dt><a name="ProjLibsPaths"><tt>ProjLibsPaths</tt></a></dt><dd></dd>
-    <dt><a name="ProjUsedLibs"><tt>ProjUsedLibs</tt></a></dt><dd></dd>
-    <dt><a name="Ranlib"><tt>Ranlib</tt></a></dt><dd></dd>
-    <dt><a name="RecursiveTargets"><tt>RecursiveTargets</tt></a></dt><dd></dd>
-    <dt><a name="Relink"><tt>Relink</tt></a></dt><dd></dd>
-    <dt><a name="SrcMakefiles"><tt>SrcMakefiles</tt></a></dt><dd></dd>
-    <dt><a name="Strip"><tt>Strip</tt></a></dt><dd></dd>
-    <dt><a name="StripWarnMsg"><tt>StripWarnMsg</tt></a></dt><dd></dd>
-    <dt><a name="TableGen"><tt>TableGen</tt></a></dt><dd></dd>
-    <dt><a name="TDFiles"><tt>TDFiles</tt></a></dt><dd></dd>
-    <dt><a name="ToolBuildPath"><tt>ToolBuildPath</tt></a></dt><dd></dd>
-    <dt><a name="TopLevelTargets"><tt>TopLevelTargets</tt></a></dt><dd></dd>
-    <dt><a name="UserTargets"><tt>UserTargets</tt></a></dt><dd></dd>
-    <dt><a name="YaccOutput"><tt>YaccOutput</tt></a></dt><dd></dd>
-  </dl>
+  <p><tt>
+    Archive
+    AR.Flags
+    BaseNameSources
+    BCCompile.C
+    BCCompile.CXX
+    BCLinkLib
+    Burg
+    C.Flags
+    Compile.C
+    CompileCommonOpts
+    Compile.CXX
+    ConfigStatusScript
+    ConfigureScript
+    CPP.Flags
+    CPP.Flags 
+    CXX.Flags
+    DependFiles
+    DestArchiveLib
+    DestBytecodeLib
+    DestModule
+    DestRelinkedLib
+    DestSharedLib
+    DestTool
+    DistAlways
+    DistCheckDir
+    DistCheckTop
+    DistFiles
+    DistName
+    DistOther
+    DistSources
+    DistSubDirs
+    DistTarBZ2
+    DistTarGZip
+    DistZip
+    ExtraLibs
+    FakeSources
+    INCFiles
+    InternalTargets
+    LD.Flags
+    LexFiles
+    LexOutput
+    LibName.A
+    LibName.BC
+    LibName.LA
+    LibName.O
+    LibTool.Flags
+    Link
+    LinkModule
+    LLVMLibDir
+    LLVMLibsOptions
+    LLVMLibsPaths
+    LLVMToolDir
+    LLVMUsedLibs
+    LocalTargets
+    LTCompile.C
+    LTCompile.CXX
+    LTInstall
+    Module
+    ObjectsBC
+    ObjectsLO
+    ObjectsO
+    ObjMakefiles
+    ParallelTargets
+    PreConditions
+    ProjLibsOptions
+    ProjLibsPaths
+    ProjUsedLibs
+    Ranlib
+    RecursiveTargets
+    Relink
+    SrcMakefiles
+    Strip
+    StripWarnMsg
+    TableGen
+    TDFiles
+    ToolBuildPath
+    TopLevelTargets
+    UserTargets
+    YaccFiles
+    YaccOutput
+  </tt></p>
 </div>
 
 <!-- *********************************************************************** -->
@@ -880,5 +1004,3 @@
 
 </body>
 </html>
-<!-- vim: sw=2 noai
--->

llvm/docs/OpenProjects.html

@@ -1,394 +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="#target">Target backend improvements</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&amp;short_desc=&amp;long_desc_type=allwordssubstr&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=&amp;keywords_type=allwords&amp;keywords=code-cleanup&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;emailassigned_to1=1&amp;emailtype1=substring&amp;email1=&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailcc2=1&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;votes=&amp;changedin=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;order=Bug+Number&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;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="target">Target backend improvements</a>
-</div>
-
-<div class="doc_text">
-
-<ol>
-  <li>Find benchmarks either using our <a
-  href="http://llvm.cs.uiuc.edu/testresults/">test results</a> or on your own,
-  where LLVM code generators do not produce optimal code or simply where another
-  compiler produces better code.  Try to minimize the test case that
-  demonstrates the issue.  Then, either <a
-  href="http://llvm.cs.uiuc.edu/bugs/">submit a bug</a> with your testcase and
-  the code that LLVM produces vs. the code that it <em>should</em> produce, or
-  even better, see if you can improve the code generator and submit a
-  patch.</li>
-</ol>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="misc_imp">Miscellaneous Improvements</a>
-</div>
-
-<div class="doc_text">
-
-<ol>
-<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.cs.uiuc.edu/bugs/buglist.cgi?short_desc_type=allwordssubstr&amp;short_desc=&amp;long_desc_type=allwordssubstr&amp;long_desc=&amp;bug_file_loc_type=allwordssubstr&amp;bug_file_loc=&amp;status_whiteboard_type=allwordssubstr&amp;status_whiteboard=&amp;keywords_type=allwords&amp;keywords=new-feature&amp;bug_status=UNCONFIRMED&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;emailassigned_to1=1&amp;emailtype1=substring&amp;email1=&amp;emailassigned_to2=1&amp;emailreporter2=1&amp;emailcc2=1&amp;emailtype2=substring&amp;email2=&amp;bugidtype=include&amp;bug_id=&amp;votes=&amp;changedin=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;cmdtype=doit&amp;namedcmd=All+PRs&amp;newqueryname=&amp;order=Bug+Number&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;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>...</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 href="http://www.cs.purdue.edu/homes/vandrutj/">GVN-PRE</a>, a 
-  powerful and simple Partial Redundancy Elimination algorithm for SSA form</li>
-<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>
-<li>Improve the usefulness and utility of the Skeleton target backend:
-<ul>
-  <li>Convert the non-functional Skeleton target to become an abstract machine
-  target (choose some simple instructions, a register set, etc).  This will
-  become a much more useful example of a backend since it would be a simple
-  but <em>functional</em> backend.  Examples of such architectures include MIX,
-  MMIX, <a
-  href="http://www.cs.cinvestav.mx/SC/prof_personal/adiaz/vhdl/DLX/">DLX</a>,
-  or come up with your own!</li>
-  <li>Use the new Skeleton backend in the Interpreter: compile LLVM to Skeleton
-  target, and then interpret that code instead of LLVM.  Performance win would
-  be the primary goal, as the number of registers would be a small constant
-  instead of unbounded, for example.</li>
-</ul></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/ProgrammersManual.html

@@ -20,6 +20,7 @@
       <li>The <tt>-time-passes</tt> option</li>
       <li>How to use the LLVM Makefile system</li>
       <li>How to write a regression test</li>
+
 --> 
     </ul>
   </li>
@@ -81,6 +82,20 @@ with another <tt>Value</tt></a> </li>
 --> 
     </ul>
   </li>
+
+  <li><a href="#advanced">Advanced Topics</a>
+  <ul>
+  <li><a href="#TypeResolve">LLVM Type Resolution</a>
+  <ul>
+    <li><a href="#BuildRecType">Basic Recursive Type Construction</a></li>
+    <li><a href="#refineAbstractTypeTo">The <tt>refineAbstractTypeTo</tt> method</a></li>
+    <li><a href="#PATypeHolder">The PATypeHolder Class</a></li>
+    <li><a href="#AbstractTypeUser">The AbstractTypeUser Class</a></li>
+  </ul></li>
+
+  <li><a href="#SymbolTable">The <tt>SymbolTable</tt> class </a></li>
+  </ul></li>
+
   <li><a href="#coreclasses">The Core LLVM Class Hierarchy Reference</a>
     <ul>
       <li><a href="#Value">The <tt>Value</tt> class</a>
@@ -112,13 +127,6 @@ with another <tt>Value</tt></a> </li>
       </li>
     </ul>
   </li>
-  <li><a href="#SymbolTable">The <tt>SymbolTable</tt> class </a></li>
-  <li>The <tt>ilist</tt> and <tt>iplist</tt> classes
-    <ul>
-      <li>Creating, inserting, moving and deleting from LLVM lists </li>
-    </ul>
-  </li>
-  <li>Important iterator invalidation semantics to be aware of.</li>
 </ol>
 
 <div class="doc_author">    
@@ -212,7 +220,7 @@ STL</a>.</li>
 <li><a href="http://www.research.att.com/%7Ebs/C++.html">Bjarne Stroustrup's C++
 Page</a></li>
 
-<li><a href="http://www.linux.com.cn/Bruce_Eckel/TICPPv2/Contents.htm">
+<li><a href="http://64.78.49.204/">
 Bruce Eckel's Thinking in C++, 2nd ed. Volume 2 Revision 4.0 (even better, get
 the book).</a></li>
 
@@ -266,7 +274,7 @@ operator, but they don't have some drawbacks (primarily stemming from
 the fact that <tt>dynamic_cast&lt;&gt;</tt> only works on classes that
 have a v-table). Because they are used so often, you must know what they
 do and how they work. All of these templates are defined in the <a
- href="/doxygen/Casting_8h-source.html"><tt>Support/Casting.h</tt></a>
+ href="/doxygen/Casting_8h-source.html"><tt>llvm/Support/Casting.h</tt></a>
 file (note that you very rarely have to include this file directly).</p>
 
 <dl>
@@ -293,6 +301,7 @@ file (note that you very rarely have to include this file directly).</p>
 
     <i>// Otherwise, it must be an instruction...</i>
     return !L-&gt;contains(cast&lt;<a href="#Instruction">Instruction</a>&gt;(V)-&gt;getParent());
+  }
   </pre>
 
   <p>Note that you should <b>not</b> use an <tt>isa&lt;&gt;</tt> test followed
@@ -321,21 +330,12 @@ file (note that you very rarely have to include this file directly).</p>
    call to <tt>isa&lt;&gt;</tt> and a call to <tt>cast&lt;&gt;</tt> into one
    statement, which is very convenient.</p>
 
-   <p> Another common example is:</p>
-
-   <pre>
-     <i>// Loop over all of the phi nodes in a basic block</i>
-     BasicBlock::iterator BBI = BB-&gt;begin();
-     for (; <a href="#PhiNode">PHINode</a> *PN = dyn_cast&lt;<a href="#PHINode">PHINode</a>&gt;(BBI); ++BBI)
-       std::cerr &lt;&lt; *PN;
-   </pre>
-
    <p>Note that the <tt>dyn_cast&lt;&gt;</tt> operator, like C++'s
    <tt>dynamic_cast</tt> or Java's <tt>instanceof</tt> operator, can be abused.
    In particular you should not use big chained <tt>if/then/else</tt> blocks to
    check for lots of different variants of classes.  If you find yourself
    wanting to do this, it is much cleaner and more efficient to use the
-   InstVisitor class to dispatch over the instruction type directly.</p>
+   <tt>InstVisitor</tt> class to dispatch over the instruction type directly.</p>
 
     </dd>
 
@@ -379,7 +379,7 @@ across).</p>
 but you don't want them to always be noisy.  A standard compromise is to comment
 them out, allowing you to enable them if you need them in the future.</p>
 
-<p>The "<tt><a href="/doxygen/Debug_8h-source.html">Support/Debug.h</a></tt>"
+<p>The "<tt><a href="/doxygen/Debug_8h-source.html">llvm/Support/Debug.h</a></tt>"
 file provides a macro named <tt>DEBUG()</tt> that is a much nicer solution to
 this problem.  Basically, you can put arbitrary code into the argument of the
 <tt>DEBUG</tt> macro, and it is only executed if '<tt>opt</tt>' (or any other
@@ -407,7 +407,7 @@ program hasn't been started yet, you can always just run it with
 
 <!-- _______________________________________________________________________ -->
 <div class="doc_subsubsection">
-  <a name="DEBUG_TYPE">Fine grained debug info with <tt>DEBUG_TYPE()</tt> and
+  <a name="DEBUG_TYPE">Fine grained debug info with <tt>DEBUG_TYPE</tt> and
   the <tt>-debug-only</tt> option</a>
 </div>
 
@@ -427,7 +427,7 @@ option as follows:</p>
 
 <p>Of course, in practice, you should only set <tt>DEBUG_TYPE</tt> at the top of
 a file, to specify the debug type for the entire module (if you do this before
-you <tt>#include "Support/Debug.h"</tt>, you don't have to insert the ugly
+you <tt>#include "llvm/Support/Debug.h"</tt>, you don't have to insert the ugly
 <tt>#undef</tt>'s).  Also, you should use names more meaningful than "foo" and
 "bar", because there is no system in place to ensure that names do not
 conflict. If two different modules use the same string, they will all be turned
@@ -446,7 +446,7 @@ even if the source lives in multiple files.</p>
 <div class="doc_text">
 
 <p>The "<tt><a
-href="/doxygen/Statistic_8h-source.html">Support/Statistic.h</a></tt>" file
+href="/doxygen/Statistic_8h-source.html">llvm/ADT/Statistic.h</a></tt>" file
 provides a template named <tt>Statistic</tt> that is used as a unified way to
 keep track of what the LLVM compiler is doing and how effective various
 optimizations are.  It is useful to see what optimizations are contributing to
@@ -573,18 +573,18 @@ easy to iterate over the individual instructions that make up
 <tt>BasicBlock</tt>s. Here's a code snippet that prints out each instruction in
 a <tt>BasicBlock</tt>:</p>
 
-  <pre>  // blk is a pointer to a BasicBlock instance<br>  for (BasicBlock::iterator i = blk-&gt;begin(), e = blk-&gt;end(); i != e; ++i)<br>     // the next statement works since operator&lt;&lt;(ostream&amp;,...) <br>     // is overloaded for Instruction&amp;<br>     cerr &lt;&lt; *i &lt;&lt; "\n";<br></pre>
+<pre>
+  // blk is a pointer to a BasicBlock instance
+  for (BasicBlock::iterator i = blk-&gt;begin(), e = blk-&gt;end(); i != e; ++i)
+     // the next statement works since operator&lt;&lt;(ostream&amp;,...)
+     // is overloaded for Instruction&amp;
+     std::cerr &lt;&lt; *i &lt;&lt; "\n";
+</pre>
 
 <p>However, this isn't really the best way to print out the contents of a
 <tt>BasicBlock</tt>!  Since the ostream operators are overloaded for virtually
 anything you'll care about, you could have just invoked the print routine on the
-basic block itself: <tt>cerr &lt;&lt; *blk &lt;&lt; "\n";</tt>.</p>
-
-<p>Note that currently operator&lt;&lt; is implemented for <tt>Value*</tt>, so
-it will print out the contents of the pointer, instead of the pointer value you
-might expect.  This is a deprecated interface that will be removed in the
-future, so it's best not to depend on it.  To print out the pointer value for
-now, you must cast to <tt>void*</tt>.</p>
+basic block itself: <tt>std::cerr &lt;&lt; *blk &lt;&lt; "\n";</tt>.</p>
 
 </div>
 
@@ -903,7 +903,7 @@ and <tt>ReplaceInstWithInst</tt>.</p>
     <p>This function replaces all uses (within a basic block) of a given
     instruction with a value, and then removes the original instruction. The
     following example illustrates the replacement of the result of a particular
-    <tt>AllocaInst</tt> that allocates memory for a single integer with an null
+    <tt>AllocaInst</tt> that allocates memory for a single integer with a null
     pointer to an integer.</p>
 
       <pre>AllocaInst* instToReplace = ...;<br>BasicBlock::iterator ii(instToReplace);<br>ReplaceInstWithValue(instToReplace-&gt;getParent()-&gt;getInstList(), ii,<br>                     Constant::getNullValue(PointerType::get(Type::IntTy)));<br></pre></li>
@@ -931,6 +931,408 @@ ReplaceInstWithValue, ReplaceInstWithInst -->
 
 </div>
 
+<!-- *********************************************************************** -->
+<div class="doc_section">
+  <a name="advanced">Advanced Topics</a>
+</div>
+<!-- *********************************************************************** -->
+
+<div class="doc_text">
+<p>
+This section describes some of the advanced or obscure API's that most clients
+do not need to be aware of.  These API's tend manage the inner workings of the
+LLVM system, and only need to be accessed in unusual circumstances.
+</p>
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+  <a name="TypeResolve">LLVM Type Resolution</a>
+</div>
+
+<div class="doc_text">
+
+<p>
+The LLVM type system has a very simple goal: allow clients to compare types for
+structural equality with a simple pointer comparison (aka a shallow compare).
+This goal makes clients much simpler and faster, and is used throughout the LLVM
+system.
+</p>
+
+<p>
+Unfortunately achieving this goal is not a simple matter.  In particular,
+recursive types and late resolution of opaque types makes the situation very
+difficult to handle.  Fortunately, for the most part, our implementation makes
+most clients able to be completely unaware of the nasty internal details.  The
+primary case where clients are exposed to the inner workings of it are when
+building a recursive type.  In addition to this case, the LLVM bytecode reader,
+assembly parser, and linker also have to be aware of the inner workings of this
+system.
+</p>
+
+<p>
+For our purposes below, we need three concepts.  First, an "Opaque Type" is 
+exactly as defined in the <a href="LangRef.html#t_opaque">language 
+reference</a>.  Second an "Abstract Type" is any type which includes an 
+opaque type as part of its type graph (for example "<tt>{ opaque, int }</tt>").
+Third, a concrete type is a type that is not an abstract type (e.g. "<tt>[ int, 
+float }</tt>").
+</p>
+
+</div>
+
+<!-- ______________________________________________________________________ -->
+<div class="doc_subsubsection">
+  <a name="BuildRecType">Basic Recursive Type Construction</a>
+</div>
+
+<div class="doc_text">
+
+<p>
+Because the most common question is "how do I build a recursive type with LLVM",
+we answer it now and explain it as we go.  Here we include enough to cause this
+to be emitted to an output .ll file:
+</p>
+
+<pre>
+   %mylist = type { %mylist*, int }
+</pre>
+
+<p>
+To build this, use the following LLVM APIs:
+</p>
+
+<pre>
+  //<i> Create the initial outer struct.</i>
+  <a href="#PATypeHolder">PATypeHolder</a> StructTy = OpaqueType::get();
+  std::vector&lt;const Type*&gt; Elts;
+  Elts.push_back(PointerType::get(StructTy));
+  Elts.push_back(Type::IntTy);
+  StructType *NewSTy = StructType::get(Elts);
+
+  //<i> At this point, NewSTy = "{ opaque*, int }". Tell VMCore that</i>
+  //<i> the struct and the opaque type are actually the same.</i>
+  cast&lt;OpaqueType&gt;(StructTy.get())-&gt;<a href="#refineAbstractTypeTo">refineAbstractTypeTo</a>(NewSTy);
+
+  // <i>NewSTy is potentially invalidated, but StructTy (a <a href="#PATypeHolder">PATypeHolder</a>) is</i>
+  // <i>kept up-to-date.</i>
+  NewSTy = cast&lt;StructType&gt;(StructTy.get());
+
+  // <i>Add a name for the type to the module symbol table (optional).</i>
+  MyModule-&gt;addTypeName("mylist", NewSTy);
+</pre>
+
+<p>
+This code shows the basic approach used to build recursive types: build a
+non-recursive type using 'opaque', then use type unification to close the cycle.
+The type unification step is performed by the <tt><a
+ref="#refineAbstractTypeTo">refineAbstractTypeTo</a></tt> method, which is
+described next.  After that, we describe the <a
+href="#PATypeHolder">PATypeHolder class</a>.
+</p>
+
+</div>
+
+<!-- ______________________________________________________________________ -->
+<div class="doc_subsubsection">
+  <a name="refineAbstractTypeTo">The <tt>refineAbstractTypeTo</tt> method</a>
+</div>
+
+<div class="doc_text">
+<p>
+The <tt>refineAbstractTypeTo</tt> method starts the type unification process.
+While this method is actually a member of the DerivedType class, it is most
+often used on OpaqueType instances.  Type unification is actually a recursive
+process.  After unification, types can become structurally isomorphic to
+existing types, and all duplicates are deleted (to preserve pointer equality).
+</p>
+
+<p>
+In the example above, the OpaqueType object is definitely deleted.
+Additionally, if there is an "{ \2*, int}" type already created in the system,
+the pointer and struct type created are <b>also</b> deleted.  Obviously whenever
+a type is deleted, any "Type*" pointers in the program are invalidated.  As
+such, it is safest to avoid having <i>any</i> "Type*" pointers to abstract types
+live across a call to <tt>refineAbstractTypeTo</tt> (note that non-abstract
+types can never move or be deleted).  To deal with this, the <a
+href="#PATypeHolder">PATypeHolder</a> class is used to maintain a stable
+reference to a possibly refined type, and the <a
+href="#AbstractTypeUser">AbstractTypeUser</a> class is used to update more
+complex datastructures.
+</p>
+
+</div>
+
+<!-- ______________________________________________________________________ -->
+<div class="doc_subsubsection">
+  <a name="PATypeHolder">The PATypeHolder Class</a>
+</div>
+
+<div class="doc_text">
+<p>
+PATypeHolder is a form of a "smart pointer" for Type objects.  When VMCore
+happily goes about nuking types that become isomorphic to existing types, it
+automatically updates all PATypeHolder objects to point to the new type.  In the
+example above, this allows the code to maintain a pointer to the resultant
+resolved recursive type, even though the Type*'s are potentially invalidated.
+</p>
+
+<p>
+PATypeHolder is an extremely light-weight object that uses a lazy union-find
+implementation to update pointers.  For example the pointer from a Value to its
+Type is maintained by PATypeHolder objects.
+</p>
+
+</div>
+
+<!-- ______________________________________________________________________ -->
+<div class="doc_subsubsection">
+  <a name="AbstractTypeUser">The AbstractTypeUser Class</a>
+</div>
+
+<div class="doc_text">
+
+<p>
+Some data structures need more to perform more complex updates when types get
+resolved.  The <a href="#SymbolTable">SymbolTable</a> class, for example, needs
+move and potentially merge type planes in its representation when a pointer
+changes.</p>
+
+<p>
+To support this, a class can derive from the AbstractTypeUser class.  This class
+allows it to get callbacks when certain types are resolved.  To register to get
+callbacks for a particular type, the DerivedType::{add/remove}AbstractTypeUser
+methods can be called on a type.  Note that these methods only work for <i>
+abstract</i> types.  Concrete types (those that do not include an opaque objects
+somewhere) can never be refined.
+</p>
+</div>
+
+
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+  <a name="SymbolTable">The <tt>SymbolTable</tt> class</a>
+</div>
+
+<div class="doc_text">
+<p>This class provides a symbol table that the <a
+href="#Function"><tt>Function</tt></a> and <a href="#Module">
+<tt>Module</tt></a> classes use for naming definitions. The symbol table can
+provide a name for any <a href="#Value"><tt>Value</tt></a> or <a
+href="#Type"><tt>Type</tt></a>.  <tt>SymbolTable</tt> is an abstract data
+type. It hides the data it contains and provides access to it through a
+controlled interface.</p>
+
+<p>Note that the symbol table class is should not be directly accessed by most
+clients.  It should only be used when iteration over the symbol table names
+themselves are required, which is very special purpose.  Note that not all LLVM
+<a href="#Value">Value</a>s have names, and those without names (i.e. they have
+an empty name) do not exist in the symbol table.
+</p>
+
+<p>To use the <tt>SymbolTable</tt> well, you need to understand the 
+structure of the information it holds. The class contains two 
+<tt>std::map</tt> objects. The first, <tt>pmap</tt>, is a map of 
+<tt>Type*</tt> to maps of name (<tt>std::string</tt>) to <tt>Value*</tt>. 
+The second, <tt>tmap</tt>, is a map of names to <tt>Type*</tt>. Thus, Values
+are stored in two-dimensions and accessed by <tt>Type</tt> and name. Types,
+however, are stored in a single dimension and accessed only by name.</p>
+
+<p>The interface of this class provides three basic types of operations:
+<ol>
+  <li><em>Accessors</em>. Accessors provide read-only access to information
+  such as finding a value for a name with the 
+  <a href="#SymbolTable_lookup">lookup</a> method.</li> 
+  <li><em>Mutators</em>. Mutators allow the user to add information to the
+  <tt>SymbolTable</tt> with methods like 
+  <a href="#SymbolTable_insert"><tt>insert</tt></a>.</li>
+  <li><em>Iterators</em>. Iterators allow the user to traverse the content
+  of the symbol table in well defined ways, such as the method
+  <a href="#SymbolTable_type_begin"><tt>type_begin</tt></a>.</li>
+</ol>
+
+<h3>Accessors</h3>
+<dl>
+  <dt><tt>Value* lookup(const Type* Ty, const std::string&amp; name) const</tt>:
+  </dt>
+  <dd>The <tt>lookup</tt> method searches the type plane given by the
+  <tt>Ty</tt> parameter for a <tt>Value</tt> with the provided <tt>name</tt>.
+  If a suitable <tt>Value</tt> is not found, null is returned.</dd>
+
+  <dt><tt>Type* lookupType( const std::string&amp; name) const</tt>:</dt>
+  <dd>The <tt>lookupType</tt> method searches through the types for a
+  <tt>Type</tt> with the provided <tt>name</tt>. If a suitable <tt>Type</tt>
+  is not found, null is returned.</dd>
+
+  <dt><tt>bool hasTypes() const</tt>:</dt>
+  <dd>This function returns true if an entry has been made into the type
+  map.</dd>
+
+  <dt><tt>bool isEmpty() const</tt>:</dt>
+  <dd>This function returns true if both the value and types maps are
+  empty</dd>
+</dl>
+
+<h3>Mutators</h3>
+<dl>
+  <dt><tt>void insert(Value *Val)</tt>:</dt>
+  <dd>This method adds the provided value to the symbol table.  The Value must
+  have both a name and a type which are extracted and used to place the value
+  in the correct type plane under the value's name.</dd>
+
+  <dt><tt>void insert(const std::string&amp; Name, Value *Val)</tt>:</dt>
+  <dd> Inserts a constant or type into the symbol table with the specified
+  name. There can be a many to one mapping between names and constants
+  or types.</dd>
+
+  <dt><tt>void insert(const std::string&amp; Name, Type *Typ)</tt>:</dt>
+  <dd> Inserts a type into the symbol table with the specified name. There
+  can be a many-to-one mapping between names and types. This method
+  allows a type with an existing entry in the symbol table to get
+  a new name.</dd>
+
+  <dt><tt>void remove(Value* Val)</tt>:</dt>
+ <dd> This method removes a named value from the symbol table. The
+  type and name of the Value are extracted from \p N and used to
+  lookup the Value in the correct type plane. If the Value is
+  not in the symbol table, this method silently ignores the
+  request.</dd>
+
+  <dt><tt>void remove(Type* Typ)</tt>:</dt>
+  <dd> This method removes a named type from the symbol table. The
+  name of the type is extracted from \P T and used to look up
+  the Type in the type map. If the Type is not in the symbol
+  table, this method silently ignores the request.</dd>
+
+  <dt><tt>Value* remove(const std::string&amp; Name, Value *Val)</tt>:</dt>
+  <dd> Remove a constant or type with the specified name from the 
+  symbol table.</dd>
+
+  <dt><tt>Type* remove(const std::string&amp; Name, Type* T)</tt>:</dt>
+  <dd> Remove a type with the specified name from the symbol table.
+  Returns the removed Type.</dd>
+
+  <dt><tt>Value *value_remove(const value_iterator&amp; It)</tt>:</dt>
+  <dd> Removes a specific value from the symbol table. 
+  Returns the removed value.</dd>
+
+  <dt><tt>bool strip()</tt>:</dt>
+  <dd> This method will strip the symbol table of its names leaving
+  the type and values. </dd>
+
+  <dt><tt>void clear()</tt>:</dt>
+  <dd>Empty the symbol table completely.</dd>
+</dl>
+
+<h3>Iteration</h3>
+<p>The following functions describe three types of iterators you can obtain
+the beginning or end of the sequence for both const and non-const. It is
+important to keep track of the different kinds of iterators. There are
+three idioms worth pointing out:</p>
+<table>
+  <tr><th>Units</th><th>Iterator</th><th>Idiom</th></tr>
+  <tr>
+    <td align="left">Planes Of name/Value maps</td><td>PI</td>
+    <td align="left"><pre><tt>
+for (SymbolTable::plane_const_iterator PI = ST.plane_begin(),
+     PE = ST.plane_end(); PI != PE; ++PI ) {
+  PI-&gt;first // This is the Type* of the plane
+  PI-&gt;second // This is the SymbolTable::ValueMap of name/Value pairs
+    </tt></pre></td>
+  </tr>
+  <tr>
+    <td align="left">All name/Type Pairs</td><td>TI</td>
+    <td align="left"><pre><tt>
+for (SymbolTable::type_const_iterator TI = ST.type_begin(),
+     TE = ST.type_end(); TI != TE; ++TI )
+  TI-&gt;first  // This is the name of the type
+  TI-&gt;second // This is the Type* value associated with the name
+    </tt></pre></td>
+  </tr>
+  <tr>
+    <td align="left">name/Value pairs in a plane</td><td>VI</td>
+    <td align="left"><pre><tt>
+for (SymbolTable::value_const_iterator VI = ST.value_begin(SomeType),
+     VE = ST.value_end(SomeType); VI != VE; ++VI )
+  VI-&gt;first  // This is the name of the Value
+  VI-&gt;second // This is the Value* value associated with the name
+    </tt></pre></td>
+  </tr>
+</table>
+
+<p>Using the recommended iterator names and idioms will help you avoid
+making mistakes. Of particular note, make sure that whenever you use
+value_begin(SomeType) that you always compare the resulting iterator
+with value_end(SomeType) not value_end(SomeOtherType) or else you 
+will loop infinitely.</p>
+
+<dl>
+
+  <dt><tt>plane_iterator plane_begin()</tt>:</dt>
+  <dd>Get an iterator that starts at the beginning of the type planes.
+  The iterator will iterate over the Type/ValueMap pairs in the
+  type planes. </dd>
+
+  <dt><tt>plane_const_iterator plane_begin() const</tt>:</dt>
+  <dd>Get a const_iterator that starts at the beginning of the type 
+  planes.  The iterator will iterate over the Type/ValueMap pairs 
+  in the type planes. </dd>
+
+  <dt><tt>plane_iterator plane_end()</tt>:</dt>
+  <dd>Get an iterator at the end of the type planes. This serves as
+  the marker for end of iteration over the type planes.</dd>
+
+  <dt><tt>plane_const_iterator plane_end() const</tt>:</dt>
+  <dd>Get a const_iterator at the end of the type planes. This serves as
+  the marker for end of iteration over the type planes.</dd>
+
+  <dt><tt>value_iterator value_begin(const Type *Typ)</tt>:</dt>
+  <dd>Get an iterator that starts at the beginning of a type plane.
+  The iterator will iterate over the name/value pairs in the type plane.
+  Note: The type plane must already exist before using this.</dd>
+
+  <dt><tt>value_const_iterator value_begin(const Type *Typ) const</tt>:</dt>
+  <dd>Get a const_iterator that starts at the beginning of a type plane.
+  The iterator will iterate over the name/value pairs in the type plane.
+  Note: The type plane must already exist before using this.</dd>
+
+  <dt><tt>value_iterator value_end(const Type *Typ)</tt>:</dt>
+  <dd>Get an iterator to the end of a type plane. This serves as the marker
+  for end of iteration of the type plane.
+  Note: The type plane must already exist before using this.</dd>
+
+  <dt><tt>value_const_iterator value_end(const Type *Typ) const</tt>:</dt>
+  <dd>Get a const_iterator to the end of a type plane. This serves as the
+  marker for end of iteration of the type plane.
+  Note: the type plane must already exist before using this.</dd>
+
+  <dt><tt>type_iterator type_begin()</tt>:</dt>
+  <dd>Get an iterator to the start of the name/Type map.</dd>
+
+  <dt><tt>type_const_iterator type_begin() cons</tt>:</dt>
+  <dd> Get a const_iterator to the start of the name/Type map.</dd>
+
+  <dt><tt>type_iterator type_end()</tt>:</dt>
+  <dd>Get an iterator to the end of the name/Type map. This serves as the
+  marker for end of iteration of the types.</dd>
+
+  <dt><tt>type_const_iterator type_end() const</tt>:</dt>
+  <dd>Get a const-iterator to the end of the name/Type map. This serves 
+  as the marker for end of iteration of the types.</dd>
+
+  <dt><tt>plane_const_iterator find(const Type* Typ ) const</tt>:</dt>
+  <dd>This method returns a plane_const_iterator for iteration over
+  the type planes starting at a specific plane, given by \p Ty.</dd>
+
+  <dt><tt>plane_iterator find( const Type* Typ </tt>:</dt>
+  <dd>This method returns a plane_iterator for iteration over the
+  type planes starting at a specific plane, given by \p Ty.</dd>
+
+</dl>
+</div>
+
+
+
 <!-- *********************************************************************** -->
 <div class="doc_section">
   <a name="coreclasses">The Core LLVM Class Hierarchy Reference </a>
@@ -1091,9 +1493,9 @@ convenient form for direct access.</p></li>
 
   <li><tt>User::op_iterator</tt> - Typedef for iterator over the operand
 list<br>
-    <tt>User::op_const_iterator</tt> <tt>use_iterator op_begin()</tt> -
-Get an iterator to the start of the operand list.<br>
-    <tt>use_iterator op_end()</tt> - Get an iterator to the end of the
+    <tt>op_iterator op_begin()</tt> - Get an iterator to the start of 
+the operand list.<br>
+    <tt>op_iterator op_end()</tt> - Get an iterator to the end of the
 operand list.
     <p> Together, these methods make up the iterator based interface to
 the operands of a <tt>User</tt>.</p></li>
@@ -1221,7 +1623,7 @@ manually inserted into the <a href="#Function"><tt>Function</tt></a>.</p></li>
 <li><tt>BasicBlock::iterator</tt> - Typedef for instruction list iterator<br>
 <tt>BasicBlock::const_iterator</tt> - Typedef for const_iterator.<br>
 <tt>begin()</tt>, <tt>end()</tt>, <tt>front()</tt>, <tt>back()</tt>,
-<tt>size()</tt>, <tt>empty()</tt>, <tt>rbegin()</tt>, <tt>rend()</tt> -
+<tt>size()</tt>, <tt>empty()</tt>
 STL-style functions for accessing the instruction list.
 
 <p>These methods and typedefs are forwarding functions that have the same
@@ -1409,8 +1811,8 @@ is its address (after linking) which is guaranteed to be constant.</p>
   <li><tt>Function::iterator</tt> - Typedef for basic block list iterator<br>
     <tt>Function::const_iterator</tt> - Typedef for const_iterator.<br>
 
-    <tt>begin()</tt>, <tt>end()</tt>, <tt>front()</tt>, <tt>back()</tt>,
-    <tt>size()</tt>, <tt>empty()</tt>, <tt>rbegin()</tt>, <tt>rend()</tt>
+    <tt>begin()</tt>, <tt>end()</tt>
+    <tt>size()</tt>, <tt>empty()</tt>
 
     <p>These are forwarding methods that make it easy to access the contents of
     a <tt>Function</tt> object's <a href="#BasicBlock"><tt>BasicBlock</tt></a>
@@ -1422,12 +1824,12 @@ is its address (after linking) which is guaranteed to be constant.</p>
     is necessary to use when you need to update the list or perform a complex
     action that doesn't have a forwarding method.</p></li>
 
-  <li><tt>Function::aiterator</tt> - Typedef for the argument list
+  <li><tt>Function::arg_iterator</tt> - Typedef for the argument list
 iterator<br>
-    <tt>Function::const_aiterator</tt> - Typedef for const_iterator.<br>
+    <tt>Function::const_arg_iterator</tt> - Typedef for const_iterator.<br>
 
-    <tt>abegin()</tt>, <tt>aend()</tt>, <tt>afront()</tt>, <tt>aback()</tt>,
-    <tt>asize()</tt>, <tt>aempty()</tt>, <tt>arbegin()</tt>, <tt>arend()</tt>
+    <tt>arg_begin()</tt>, <tt>arg_end()</tt>
+    <tt>arg_size()</tt>, <tt>arg_empty()</tt>
 
     <p>These are forwarding methods that make it easy to access the contents of
     a <tt>Function</tt> object's <a href="#Argument"><tt>Argument</tt></a>
@@ -1571,8 +1973,8 @@ provide a name for it (probably based on the name of the translation unit).</p>
   <li><tt>Module::iterator</tt> - Typedef for function list iterator<br>
     <tt>Module::const_iterator</tt> - Typedef for const_iterator.<br>
 
-    <tt>begin()</tt>, <tt>end()</tt>, <tt>front()</tt>, <tt>back()</tt>,
-    <tt>size()</tt>, <tt>empty()</tt>, <tt>rbegin()</tt>, <tt>rend()</tt>
+    <tt>begin()</tt>, <tt>end()</tt>
+    <tt>size()</tt>, <tt>empty()</tt>
 
     <p>These are forwarding methods that make it easy to access the contents of
     a <tt>Module</tt> object's <a href="#Function"><tt>Function</tt></a>
@@ -1590,12 +1992,12 @@ provide a name for it (probably based on the name of the translation unit).</p>
 <hr>
 
 <ul>
-  <li><tt>Module::giterator</tt> - Typedef for global variable list iterator<br>
+  <li><tt>Module::global_iterator</tt> - Typedef for global variable list iterator<br>
 
-    <tt>Module::const_giterator</tt> - Typedef for const_iterator.<br>
+    <tt>Module::const_global_iterator</tt> - Typedef for const_iterator.<br>
 
-    <tt>gbegin()</tt>, <tt>gend()</tt>, <tt>gfront()</tt>, <tt>gback()</tt>,
-    <tt>gsize()</tt>, <tt>gempty()</tt>, <tt>grbegin()</tt>, <tt>grend()</tt>
+    <tt>global_begin()</tt>, <tt>global_end()</tt>
+    <tt>global_size()</tt>, <tt>global_empty()</tt>
 
     <p> These are forwarding methods that make it easy to access the contents of
     a <tt>Module</tt> object's <a
@@ -1709,13 +2111,13 @@ ConstantArray etc for representing the various types of Constants.</p>
   <li>ConstantArray : This represents a constant array.
     <ul>
       <li><tt>const std::vector&lt;Use&gt; &amp;getValues() const</tt>: Returns 
-      a Vecotr of component constants that makeup this array. </li>
+      a vector of component constants that makeup this array. </li>
     </ul>
   </li>
   <li>ConstantStruct : This represents a constant struct.
     <ul>
       <li><tt>const std::vector&lt;Use&gt; &amp;getValues() const</tt>: Returns 
-      a Vector of component constants that makeup this array. </li>
+      a vector of component constants that makeup this array. </li>
     </ul>
   </li>
   <li>GlobalValue : This represents either a global variable or a function. In 
@@ -1818,236 +2220,11 @@ types.</p>
 <div class="doc_text">
 
 <p>This subclass of Value defines the interface for incoming formal
-arguments to a function. A Function maitanis a list of its formal
+arguments to a function. A Function maintains a list of its formal
 arguments. An argument has a pointer to the parent Function.</p>
 
 </div>
 
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="SymbolTable">The <tt>SymbolTable</tt> class</a>
-</div>
-<div class="doc_text">
-<p>This class provides a symbol table that the
-<a href="#Function"><tt>Function</tt></a> and <a href="#Module">
-<tt>Module</tt></a> classes use for naming definitions. The symbol table can 
-provide a name for any <a href="#Value"><tt>Value</tt></a> or 
-<a href="#Type"><tt>Type</tt></a>.  <tt>SymbolTable</tt> is an abstract data 
-type. It hides the data it contains and provides access to it through a 
-controlled interface.</p>
-
-<p>To use the <tt>SymbolTable</tt> well, you need to understand the 
-structure of the information it holds. The class contains two 
-<tt>std::map</tt> objects. The first, <tt>pmap</tt>, is a map of 
-<tt>Type*</tt> to maps of name (<tt>std::string</tt>) to <tt>Value*</tt>. 
-The second, <tt>tmap</tt>, is a map of names to <tt>Type*</tt>. Thus, Values
-are stored in two-dimensions and accessed by <tt>Type</tt> and name. Types,
-however, are stored in a single dimension and accessed only by name.</p>
-
-<p>The interface of this class provides three basic types of operations:
-<ol>
-  <li><em>Accessors</em>. Accessors provide read-only access to information
-  such as finding a value for a name with the 
-  <a href="#SymbolTable_lookup">lookup</a> method.</li> 
-  <li><em>Mutators</em>. Mutators allow the user to add information to the
-  <tt>SymbolTable</tt> with methods like 
-  <a href="#SymbolTable_insert"><tt>insert</tt></a>.</li>
-  <li><em>Iterators</em>. Iterators allow the user to traverse the content
-  of the symbol table in well defined ways, such as the method
-  <a href="#SymbolTable_type_begin"><tt>type_begin</tt></a>.</li>
-</ol>
-
-<h3>Accessors</h3>
-<dl>
-  <dt><tt>Value* lookup(const Type* Ty, const std::string&amp; name) const</tt>:
-  </dt>
-  <dd>The <tt>lookup</tt> method searches the type plane given by the
-  <tt>Ty</tt> parameter for a <tt>Value</tt> with the provided <tt>name</tt>.
-  If a suitable <tt>Value</tt> is not found, null is returned.</dd>
-
-  <dt><tt>Type* lookupType( const std::string&amp; name) const</tt>:</dt>
-  <dd>The <tt>lookupType</tt> method searches through the types for a
-  <tt>Type</tt> with the provided <tt>name</tt>. If a suitable <tt>Type</tt>
-  is not found, null is returned.</dd>
-
-  <dt><tt>bool hasTypes() const</tt>:</dt>
-  <dd>This function returns true if an entry has been made into the type
-  map.</dd>
-
-  <dt><tt>bool isEmpty() const</tt>:</dt>
-  <dd>This function returns true if both the value and types maps are
-  empty</dd>
-
-  <dt><tt>std::string get_name(const Value*) const</tt>:</dt>
-  <dd>This function returns the name of the Value provided or the empty
-  string if the Value is not in the symbol table.</dd> 
-
-  <dt><tt>std::string get_name(const Type*) const</tt>:</dt>
-  <dd>This function returns the name of the Type provided or the empty
-  string if the Type is not in the symbol table.</dd>
-</dl>
-
-<h3>Mutators</h3>
-<dl>
-  <dt><tt>void insert(Value *Val)</tt>:</dt>
-  <dd>This method adds the provided value to the symbol table.  The Value must
-  have both a name and a type which are extracted and used to place the value
-  in the correct type plane under the value's name.</dd>
-
-  <dt><tt>void insert(const std::string&amp; Name, Value *Val)</tt>:</dt>
-  <dd> Inserts a constant or type into the symbol table with the specified
-  name. There can be a many to one mapping between names and constants
-  or types.</dd>
-
-  <dt><tt>void insert(const std::string&amp; Name, Type *Typ)</tt>:</dt>
-  <dd> Inserts a type into the symbol table with the specified name. There
-  can be a many-to-one mapping between names and types. This method
-  allows a type with an existing entry in the symbol table to get
-  a new name.</dd>
-
-  <dt><tt>void remove(Value* Val)</tt>:</dt>
- <dd> This method removes a named value from the symbol table. The
-  type and name of the Value are extracted from \p N and used to
-  lookup the Value in the correct type plane. If the Value is
-  not in the symbol table, this method silently ignores the
-  request.</dd>
-
-  <dt><tt>void remove(Type* Typ)</tt>:</dt>
-  <dd> This method removes a named type from the symbol table. The
-  name of the type is extracted from \P T and used to look up
-  the Type in the type map. If the Type is not in the symbol
-  table, this method silently ignores the request.</dd>
-
-  <dt><tt>Value* remove(const std::string&amp; Name, Value *Val)</tt>:</dt>
-  <dd> Remove a constant or type with the specified name from the 
-  symbol table.</dd>
-
-  <dt><tt>Type* remove(const std::string&amp; Name, Type* T)</tt>:</dt>
-  <dd> Remove a type with the specified name from the symbol table.
-  Returns the removed Type.</dd>
-
-  <dt><tt>Value *value_remove(const value_iterator&amp; It)</tt>:</dt>
-  <dd> Removes a specific value from the symbol table. 
-  Returns the removed value.</dd>
-
-  <dt><tt>bool strip()</tt>:</dt>
-  <dd> This method will strip the symbol table of its names leaving
-  the type and values. </dd>
-
-  <dt><tt>void clear()</tt>:</dt>
-  <dd>Empty the symbol table completely.</dd>
-</dl>
-
-<h3>Iteration</h3>
-<p>The following functions describe three types of iterators you can obtain
-the beginning or end of the sequence for both const and non-const. It is
-important to keep track of the different kinds of iterators. There are
-three idioms worth pointing out:</p>
-<table>
-  <tr><th>Units</th><th>Iterator</th><th>Idiom</th></tr>
-  <tr>
-    <td align="left">Planes Of name/Value maps</td><td>PI</td>
-    <td align="left"><pre><tt>
-for (SymbolTable::plane_const_iterator PI = ST.plane_begin(),
-     PE = ST.plane_end(); PI != PE; ++PI ) {
-  PI-&gt;first // This is the Type* of the plane
-  PI-&gt;second // This is the SymbolTable::ValueMap of name/Value pairs
-    </tt></pre></td>
-  </tr>
-  <tr>
-    <td align="left">All name/Type Pairs</td><td>TI</td>
-    <td align="left"><pre><tt>
-for (SymbolTable::type_const_iterator TI = ST.type_begin(),
-     TE = ST.type_end(); TI != TE; ++TI )
-  TI-&gt;first  // This is the name of the type
-  TI-&gt;second // This is the Type* value associated with the name
-    </tt></pre></td>
-  </tr>
-  <tr>
-    <td align="left">name/Value pairs in a plane</td><td>VI</td>
-    <td align="left"><pre><tt>
-for (SymbolTable::value_const_iterator VI = ST.value_begin(SomeType),
-     VE = ST.value_end(SomeType); VI != VE; ++VI )
-  VI-&gt;first  // This is the name of the Value
-  VI-&gt;second // This is the Value* value associated with the name
-    </tt></pre></td>
-  </tr>
-</table>
-
-<p>Using the recommended iterator names and idioms will help you avoid
-making mistakes. Of particular note, make sure that whenever you use
-value_begin(SomeType) that you always compare the resulting iterator
-with value_end(SomeType) not value_end(SomeOtherType) or else you 
-will loop infinitely.</p>
-
-<dl>
-
-  <dt><tt>plane_iterator plane_begin()</tt>:</dt>
-  <dd>Get an iterator that starts at the beginning of the type planes.
-  The iterator will iterate over the Type/ValueMap pairs in the
-  type planes. </dd>
-
-  <dt><tt>plane_const_iterator plane_begin() const</tt>:</dt>
-  <dd>Get a const_iterator that starts at the beginning of the type 
-  planes.  The iterator will iterate over the Type/ValueMap pairs 
-  in the type planes. </dd>
-
-  <dt><tt>plane_iterator plane_end()</tt>:</dt>
-  <dd>Get an iterator at the end of the type planes. This serves as
-  the marker for end of iteration over the type planes.</dd>
-
-  <dt><tt>plane_const_iterator plane_end() const</tt>:</dt>
-  <dd>Get a const_iterator at the end of the type planes. This serves as
-  the marker for end of iteration over the type planes.</dd>
-
-  <dt><tt>value_iterator value_begin(const Type *Typ)</tt>:</dt>
-  <dd>Get an iterator that starts at the beginning of a type plane.
-  The iterator will iterate over the name/value pairs in the type plane.
-  Note: The type plane must already exist before using this.</dd>
-
-  <dt><tt>value_const_iterator value_begin(const Type *Typ) const</tt>:</dt>
-  <dd>Get a const_iterator that starts at the beginning of a type plane.
-  The iterator will iterate over the name/value pairs in the type plane.
-  Note: The type plane must already exist before using this.</dd>
-
-  <dt><tt>value_iterator value_end(const Type *Typ)</tt>:</dt>
-  <dd>Get an iterator to the end of a type plane. This serves as the marker
-  for end of iteration of the type plane.
-  Note: The type plane must already exist before using this.</dd>
-
-  <dt><tt>value_const_iterator value_end(const Type *Typ) const</tt>:</dt>
-  <dd>Get a const_iterator to the end of a type plane. This serves as the
-  marker for end of iteration of the type plane.
-  Note: the type plane must already exist before using this.</dd>
-
-  <dt><tt>type_iterator type_begin()</tt>:</dt>
-  <dd>Get an iterator to the start of the name/Type map.</dd>
-
-  <dt><tt>type_const_iterator type_begin() cons</tt>:</dt>
-  <dd> Get a const_iterator to the start of the name/Type map.</dd>
-
-  <dt><tt>type_iterator type_end()</tt>:</dt>
-  <dd>Get an iterator to the end of the name/Type map. This serves as the
-  marker for end of iteration of the types.</dd>
-
-  <dt><tt>type_const_iterator type_end() const</tt>:</dt>
-  <dd>Get a const-iterator to the end of the name/Type map. This serves 
-  as the marker for end of iteration of the types.</dd>
-
-  <dt><tt>plane_const_iterator find(const Type* Typ ) const</tt>:</dt>
-  <dd>This method returns a plane_const_iterator for iteration over
-  the type planes starting at a specific plane, given by \p Ty.</dd>
-
-  <dt><tt>plane_iterator find( const Type* Typ </tt>:</dt>
-  <dd>This method returns a plane_iterator for iteration over the
-  type planes starting at a specific plane, given by \p Ty.</dd>
-
-  <dt><tt>const ValueMap* findPlane( const Type* Typ ) cons</tt>:</dt>
-  <dd>This method returns a ValueMap* for a specific type plane. This
-  interface is deprecated and may go away in the future.</dd>
-</dl>
-</div>
-
 <!-- *********************************************************************** -->
 <hr>
 <address>
@@ -2064,5 +2241,3 @@ will loop infinitely.</p>
 
 </body>
 </html>
-<!-- vim: sw=2 noai
--->

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

@@ -4,11 +4,11 @@
 <head>
   <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
   <link rel="stylesheet" href="llvm.css" type="text/css">
-  <title>LLVM 1.4 Release Notes</title>
+  <title>LLVM 1.5 Release Notes</title>
 </head>
 <body>
 
-<div class="doc_title">LLVM 1.4 Release Notes</div>
+<div class="doc_title">LLVM 1.5 Release Notes</div>
  
 <ol>
   <li><a href="#intro">Introduction</a></li>
@@ -16,22 +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="#ppc-be">Known problems with the PowerPC 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>
 
 <!-- *********************************************************************** -->
@@ -43,22 +32,22 @@
 <div class="doc_text">
 
 <p>This document contains the release notes for the LLVM compiler
-infrastructure, release 1.4.  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.4/">LLVM 1.4 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>
@@ -71,221 +60,284 @@ href="http://llvm.cs.uiuc.edu/releases/">releases page</a>.</p>
 
 <div class="doc_text">
 
-<p>This is the fifth public release of the LLVM compiler infrastructure.</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 C and 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">
+<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"><a name="selectiondag">New Instruction
+Selector Framework</a></div>
+
+<div class="doc_text">
+<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="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>
+
+<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">Other New Features</div>
+
 <div class="doc_text">
 <ol>
-  <li>LLVM now includes a JIT for the PowerPC target.</li>
-  <li>LLVM now optimizes global variables significantly more than it did 
-  before.
-  </li>
-  <li>LLVM now includes the new '<tt>undef</tt>' value and 
-  <a href="LangRef.html#i_unreachable"><tt>unreachable</tt></a> instruction,
-  which give the optimizer more information about the behavior of the
-  program.
-  </li>
-  <li>llvmgcc and llvmg++ now emit source line number information when '-g' is
-  passed in.  This information can be used with llvm-db or other tools and 
-  passes.
-  </li>
-  <li>The test/Programs hierarchy <a href="http://llvm.cs.uiuc.edu/PR257">has
-    been moved out of the main LLVM tree</a> into a separate CVS repository and
-    tarball. This shrinks the distribution size of LLVM itself significantly.
-  </li>
-  <li>Bytecode compression with bzip2 has been implemented. All bytecode files
-  generated by LLVM will now be compressed by default. Compression can be 
-  disabled with the <tt>-disable-compression</tt> option to the tools that can 
-  generate bytecode files.
-  </li>
-  <li>A generic <a href="http://llvm.cs.uiuc.edu/PR353">compiler driver</a> and
-  an associated <a href="CommandGuide/html/llvm-ld.html">generic linker</a> have
-  been implemented. The compiler driver is generic because it can be configured
-  to pre-process, translate, optimize, assemble, and link code from any source
-  language. This aids compiler writers because all that is needed is a
-  source-to-bytecode or source-to-assembly translator and a configuration file.
-  The linker is generic because it allows dynamically loadable optimization
-  modules to be executed for link-time optimization. Language specific 
-  link-time optimization modules can be created and executed automatically.
-  </li>
-  <li>The <a href="http://llvm.cs.uiuc.edu/PR263">dependent libraries</a> 
-  feature has been implemented. This allows front end compilers to indicate in
-  the bytecode which libraries the bytecode needs to be linked with. Both the
-  C/C++ front end and Stacker support generating the required libraries. The 
-  Linker now supports using this information to ensure required libaries are
-  linked into the module. This minimizes the need to use the <tt>-l</tt> option
-  when using <a href="CommandGuide/html/llvmc.html"><tt>llvmc</tt></a>
-  </li>
-  <li>The LLVM makefiles have been improved to build LLVM faster (2x) and 
-  includes new targets (like dist-check, uninstall). One important change is
-  associated with <a href="http://llvm.cs.uiuc.edu/PR456">PR456</a>. The 
-  libraries and tools will now be built into <tt>$builddir/Debug/{bin,lib}</tt>
-  instead of <tt>$builddir/tools/Debug</tt> and <tt>$builddir/lib/Debug</tt>.
-  Similarly for <tt>Release</tt> and <tt>Profile</tt> builds.
-  </li>
-  <li>The LLVM source code is much more compatible with Microsoft Visual C++,
-  including the JIT and runtime-code generation, though the entire system 
-  may not work with it.
-  </li>
-  <li>The target-to-JIT interfaces <a href="http://llvm.cs.uiuc.edu/PR283">are 
-    now much simpler</a> and more powerful.
-  </li>
-  <li>zlib and libpng are <a href="http://llvm.cs.uiuc.edu/PR417">no longer
-      included in the main LLVM tarball</a>.</li>
-  <li>The LLVM code generator now generates asm writers for the target from
-      an abstract target description, instead of requiring them to be hand 
-      written.</li>
-  <li>LLVM regression and feature tests can now be run with DejaGNU.</li>
-  <li>llvmgcc and llvmg++ now emit source-level line number information, making
-      it possible to map from LLVM code back to source.  This is currently used
-      by llvm-db.</li>
-  <li>Floating point intensive programs on X86 systems run much faster
-      with the LLC code generator and JIT than in 1.3.</li>
-</ol>
+  <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>
 
-</div>
-
-
-<!--=========================================================================-->
-<div class="doc_subsubsection">
-In this release, the following missing features were implemented:
-</div>
-
-<div class="doc_text">
-
-<ol>
-  <li><a href="http://llvm.cs.uiuc.edu/PR419">JIT interface should support
-    arbitrary calls</a>
-  </li>
-  <li>The <tt>llvm-ar</tt> tool was previously incomplete and didn't properly
-  support other ar(1) implementations. This has been corrected. <tt>llvm-ar</tt>
-  now fully supports all archive editing functions, table of contents listing,
-  extraction, and printing. It can also read BSD4.4/MacOSX and SVR4 style 
-  archives. See <a href="CommandGuide/html/llvm-ar.html">llvm-ar</a> for 
-  details.
-  </li>
-</ol>
-
-</div>
-
-<!--=========================================================================-->
-<div class="doc_subsubsection">
-<a name="qualityofimp">In this release, the following Quality of Implementation
-issues were fixed:</a>
-</div>
-
-<div class="doc_text">
-
-<ol>
-  <li><a href="http://llvm.cs.uiuc.edu/PR426">[llvmg++] Tons of warnings 
-    are spewed when linking to libstdc++</a>
-  </li>
-  <li><a href="http://llvm.cs.uiuc.edu/PR352">include/{Support,Config} -> 
-    include/llvm/{Support,Config}</a>
-  </li>
-  <li>The names of the libraries generated by compiling LLVM source have been 
-  changed to ensure they do not conflict with other packages upon installation.
-  Each LLVM library is now prefixed with LLVM and uses mixed clase. For example,
-  the library <tt>libasmparser.a</tt> in 1.3 has become
-  <tt>libLLVMAsmParser.a</tt> in release 1.4.
-  </li>
-  <li><a href="http://llvm.cs.uiuc.edu/PR459">[llvmg++] C++ frontend is expanding 
-    lots of unused inline functions</a></li>
-</ol>
-
-</div>
-
-<!--=========================================================================-->
-<div class="doc_subsubsection">
-In this release, the following build problems were fixed:
-</div>
-
-<div class="doc_text">
-<ol>
-  <li><a href="http://llvm.cs.uiuc.edu/PR256">[autoconf] further standardizing
-    autoconf usage</a>. Various improvements in the configure.ac script were
-  made as well as the makefile system.
-  </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><a href="http://llvm.cs.uiuc.edu/PR362">Ugly code generated for  
-    std::min/std::max</a>
+<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 -globalopt pass now promotes non-address-taken static globals that are
+only accessed in main to SSA registers.</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 optimizer now eliminates simple cases where redundant conditions exist
+    between neighboring blocks.</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 -prune-eh pass now detects no-return functions in addition to the
+    no-unwind functions it did before.</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/PR420">[licm] LICM invalidates alias 
-    analysis info and uses broken information</a> (optimizer crash)</li>
-  <li><a href="http://llvm.cs.uiuc.edu/PR422">[asmwriter] Asmwriter is really 
-    slow for functions with lots of values</a></li>
-  <li><a href="http://llvm.cs.uiuc.edu/PR423">[anders-aa] Andersen's AA is 
-    completely broken in LLVM 1.3</a></li>
-  <li><a href="http://llvm.cs.uiuc.edu/PR430">[bcwriter] Empty compaction 
-    tables defined</a></li>
-  <li><a href="http://llvm.cs.uiuc.edu/PR227">[X86] llc output for functions 
-    w/certain names tickles GNU 'as' bugs</a></li>
-  <li><a href="http://llvm.cs.uiuc.edu/PR472">[cbackend] Static globals are 
-      prototyped as 'extern'</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/PR445">[llvmg++] not enough templates are
-    instantiated</a></li>
-  <li><a href="http://llvm.cs.uiuc.edu/PR450">[llvmg++] Extern const globals 
-    cannot be marked 'constant' if they have nontrivial ctors or dtors</a></li>
-  <li><a href="http://llvm.cs.uiuc.edu/PR461">[llvmgcc] Crash compiling unnamed 
-    bitfield which does not increase struct size</a></li>
-  <li><a href="http://llvm.cs.uiuc.edu/PR424">[llvmgcc] llvmgcc emits invalid 
-    constant exprs</a></li>
-  <li><a href="http://llvm.cs.uiuc.edu/PR421">[llvmg++] Crash in initializing 
-    array with constructors in hard EH situations</a></li>
-  <li><a href="http://llvm.cs.uiuc.edu/PR397">[llvm-gcc] Inline function 
-    redefinitions error due to 'asm' function rename</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>
-  <li><a href="http://llvm.cs.uiuc.edu/PR360">[llvmgcc] Structure field with 
-    non-constant offset crashes llvmgcc</a></li>
-  <li><a href="http://llvm.cs.uiuc.edu/PR447">[llvmg++] Crash compiling 
-    friend with default argument</a></li>
-</ol>
-
-<p>Bugs fixed in the Sparc V9 back-end:</p>
-
-<ol>
-  <li><a href="http://llvm.cs.uiuc.edu/PR428">[sparcv9] regalloc assertion
-    failure with certain indirect calls</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>
@@ -298,14 +350,17 @@ were fixed:</a>
 
 <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.</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
@@ -314,15 +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).  Finally,
-please make sure that there are no directories with spaces in them in your
-PATH environment variable.</p>
-
 </div>
 
 <!-- *********************************************************************** -->
@@ -355,13 +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 following passes are incomplete or buggy: <tt>-pgmdep, -memdep,
-    -ipmodref, -cee, -branch-combine, -instloops, -paths</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-db</tt> tool is in a very early stage of development.</li>
-<li>The "iterative scan" register allocator (enabled with -regalloc=iterativescan)
-    is not stable.</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>
@@ -374,28 +420,16 @@ components, please contact us on the llvmdev list.</p>
 <div class="doc_text">
 
 <ul>
-  <li>In the JIT, <tt>dlsym</tt> on a symbol compiled by the JIT will not work.
-  </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>Linking in static archive files (.a files) is slow by default because 
-  there is no symbol table in the archive. To remedy this, run 
-  <a href="CommandGuide/html/llvm-ranlib.html"><tt>llvm-ranlib</tt></a> on the 
-  archive to add an LLVM symbol table.
-  </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><a href="http://llvm.cs.uiuc.edu/PR427">[bytecode] Assertion on V1
-    Bytecode Files</a>. This bug won't be fixed because V1 bytecode had its own
-    problems, no one is using V1 bytecode any more, and the fix is non-trivial.
-  </li>
 </ul>
 </div>
 
@@ -421,9 +455,6 @@ components, please contact us on the llvmdev list.</p>
 <li>Initialization of global union variables can only be done <a
 href="http://llvm.cs.uiuc.edu/PR162">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>
-
 </ul>
 </div>
 
@@ -464,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>
 
@@ -485,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>
 
@@ -521,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>
@@ -549,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>
@@ -576,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>
 
@@ -592,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>
@@ -637,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>
@@ -645,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>
@@ -666,39 +728,67 @@ several programs in the LLVM test suite</a></li>
 
 <!-- ======================================================================= -->
 <div class="doc_subsection">
-  <a name="ppc-be">Known problems with the PowerPC back-end</a>
+  <a name="alpha-be">Known problems with the Alpha back-end</a>
 </div>
 
 <div class="doc_text">
 
 <ul>
-<li>none yet</li>
+
+<li>On 21164s, some rare FP arithmetic sequences which may trap do not have the
+appropriate nops inserted to ensure restartability.</li>
+
+<li>Defining vararg functions is not supported (but calling them is ok).</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="c-be">Known problems with the C back-end</a>
+  <a name="ia64-be">Known problems with the IA64 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>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><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>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><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>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>
@@ -711,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

@@ -72,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">
 
@@ -1028,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

@@ -787,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>
@@ -946,24 +946,28 @@ 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><th colspan="4"><b>INPUT &amp; OUTPUT OPERATORS</b></th></tr>
 <tr>

llvm/docs/SystemLibrary.html

@@ -8,39 +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="#nodupl">No Duplicate Implementations</a></li>
+    <li><a href="#nounused">No Unused Functionality</a></li>
+    <li><a href="#virtuals">No Virtual Methods</a></li>
+    <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="#nodupl">No Duplicate Implementations</a></li>
-  </ol></li>
-  <li><a href="#design">System Library Design</a>
-  <ol>
-    <li><a href="#nounused">No Unused Functionality</a></li>
-    <li><a href="#highlev">High-Level Interface</a></li>
-    <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="#virtuals">No Virtual Methods</a></li>
-  </ol></li>
-  <li><a href="#detail">System Library Details</a>
-  <ol>
+    <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 Implementation</a></li>
   </ol></li>
 </ul>
 
@@ -52,68 +39,140 @@
 <!-- *********************************************************************** -->
 <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
-  since (theoretically) only <tt>llvm/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>llvm/include/llvm/System</tt>.</p> Note that
-  lib/System is not intended to be a complete operating system wrapper (such as
-  the Adaptive Communications Environment (ACE) or Apache Portable Runtime
-  (APR)), but only to provide the functionality necessary to support LLVM.
+  <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 original work as part of the eXtensible Programming 
-  System (XPS).</p>
+  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. Of necessity, these requirements 
-  must be strictly followed in order to ensure the library's goal is reached.</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>The library must shield LLVM from <em>all</em> system libraries. To obtain
-  system level functionality, LLVM 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 except through the lib/System interface.  Specifically this 
-  means that header files like "unistd.h", "windows.h", "stdio.h", and 
-  "string.h" are verbotten outside the implementation of lib/System.
+  <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="expose">Don't Expose System Headers</a>
+</div>
+<div class="doc_text">
+  <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="c_headers">Use Standard C Headers</a></div>
+<div class="doc_text">
+  <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="cpp_headers">Use Standard C++ Headers</a>
+</div>
+<div class="doc_text">
+  <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="highlev">High Level Interface</a></div>
+<div class="doc_text">
+  <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="nounused">No Unused Functionality</a></div>
+<div class="doc_text">
+  <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="nodupl">No Duplicate Implementations</a>
+</div>
+<div class="doc_text">
+  <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="c_headers">Allow Standard C Headers</a>
-</div>
+<div class="doc_subsection"><a name="virtuals">No Virtual Methods</a></div>
 <div class="doc_text">
-  <p>The <em>standard</em> C headers (the ones beginning with "c") are allowed
-  to be exposed through the lib/System 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="cpp_headers">Allow Standard C++ Headers</a>
-</div>
-<div class="doc_text">
-  <p>The <em>standard</em> C++ headers from the standard C++ library and
-  standard template library are allowed to be exposed through the lib/System
-  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>
+  <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>
 
 <!-- ======================================================================= -->
@@ -124,11 +183,12 @@
   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. lib/System 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.</p>
+  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>
 
 <!-- ======================================================================= -->
@@ -140,6 +200,45 @@
   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">
@@ -173,191 +272,52 @@
   <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 the many call chains and as such can be frequently called. We
+  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="nodupl">No Duplicate Implementations</a>
-</div>
+<div class="doc_subsection"><a name="organization">Code Organization</a></div>
 <div class="doc_text">
-  <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.</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>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="nounused">No Unused Functionality</a></div>
-<div class="doc_text">
-  <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="highlev">High Level Interface</a></div>
-<div class="doc_text">
-  <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="highlev">Minimize Soft Errors</a></div>
-<div class="doc_text">
-  <p>Operating system interfaces will generally provide errors 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". Well call the
-  first group "soft" errors and the second group "hard" 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 "can't" 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>
- 
+  <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>
-Notes:
-10. 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
+  #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.
-
-11. Implementations are separated first by the general class of operating system
-    as provided by the configure script's $build variable. This variable is used
-    to create a link from $BUILD_OBJ_ROOT/lib/System/platform to a directory in
-    $BUILD_SRC_ROOT/lib/System directory with the same name as the $build
-    variable. This provides a retargetable include mechanism. By using the link's
-    name (platform) we can actually include the operating specific
-    implementation. For example, support $build is "Darwin" for MacOS X. If we
-    place:
-      #include "platform/File.cpp"
-    into a a file in lib/System, it will actually include
-    lib/System/Darwin/File.cpp. What this does is quickly differentiate the basic
-    class of operating system that will provide the implementation.
- 
-12. Implementation files in lib/System need may only do two things: (1) define 
-    functions and data that is *TRULY* generic (completely platform agnostic) and
-    (2) #include the platform specific implementation with:
- 
-       #include "platform/Impl.cpp"
- 
-    where Impl is the name of the implementation files.
- 
-13. Platform specific implementation files (platform/Impl.cpp) may only #include
-    other Impl.cpp files found in directories under lib/System. The order of
-    inclusion is very important (from most generic to most specific) so that we
-    don't inadvertently place an implementation in the wrong place. For example,
-    consider a fictitious implementation file named DoIt.cpp. Here's how the
-    #includes should work for a Linux platform
- 
-    lib/System/DoIt.cpp
-      #include "platform/DoIt.cpp"        // platform specific impl. of Doit
-      DoIt
- 
-    lib/System/Linux/DoIt.cpp             // impl that works on all Linux 
-      #include "../Unix/DoIt.cpp"         // generic Unix impl. of DoIt
-      #include "../Unix/SUS/DoIt.cpp      // SUS specific impl. of DoIt
-      #include "../Unix/SUS/v3/DoIt.cpp   // SUSv3 specific impl. of DoIt
- 
-    Note that the #includes in lib/System/Linux/DoIt.cpp are all optional but
-    should be used where the implementation of some functionality can be shared
-    across some set of Unix variants. We don't want to duplicate code across
-    variants if their implementation could be shared.
-</tt></pre>
-</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>
-<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>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="virtuals">No Virtual Methods</a></div>
-<div class="doc_text">
-  <p>To be written.</p>
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section"><a name="detail">System Library Details</a></div>
-<div class="doc_text">
-  <p>To be written.</p>
+  given operating system.  In all cases, the interface and the implementation 
+  must be semantically consistent. </p>
 </div>
 
 <!-- ======================================================================= -->
@@ -367,130 +327,6 @@ Notes:
   for further details on the progress of this work</p>
 </div>
 
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="bug">Rationale For #include Hierarchy</a>
-</div>
-<div class="doc_text">
-  <p>In order to provide different implementations of the lib/System interface
-  for different platforms, it is necessary for the library to "sense" which
-  operating system is being compiled for and conditionally compile only the
-  applicable parts of the library. While several operating system wrapper
-  libraries (e.g. APR, ACE) choose to use #ifdef preprocessor statements in
-  combination with autoconf variable (HAVE_* family), lib/System chooses an
-  alternate strategy. <p>
-  <p>To put it succinctly, the lib/System strategy has traded "#ifdef hell" for 
-  "#include hell". That is, a given implementation file defines one or more
-  functions for a particular operating system variant. The functions defined in
-  that file have no #ifdef's to disambiguate the platform since the file is only
-  compiled on one kind of platform. While this leads to the same function being
-  implemented differently in different files, it is our contention that this
-  leads to better maintenance and easier portability.</p>
-  <p>For example, consider a function having different implementations on a
-  variety of platforms. Many wrapper libraries choose to deal with the different
-  implementations by using #ifdef, like this:</p>
-  <pre><tt>
-      void SomeFunction(void) {
-      #if defined __LINUX
-        // .. Linux implementation
-      #elif defined __WIN32
-        // .. Win32 implementation
-      #elif defined __SunOS
-        // .. SunOS implementation
-      #else
-      #warning "Don't know how to implement SomeFunction on this platform"
-      #endif
-      }
-  </tt></pre>
-  <p>The problem with this is that its very messy to read, especially as the
-  number of operating systems and their variants grow. The above example is
-  actually tame compared to what can happen when the implementation depends on
-  specific flavors and versions of the operating system. In that case you end up
-  with multiple levels of nested #if statements. This is what we mean by "#ifdef
-  hell".</p>
-  <p>To avoid the situation above, we've chosen to locate all functions for a
-  given implementation file for a specific operating system into one place. This
-  has the following advantages:<p>
-  <ul>
-    <li>No "#ifdef hell"</li>
-    <li>When porting, the strategy is quite straight forward: copy the
-    implementation file from a similar operating system to a new directory and
-    re-implement them.<li>
-    <li>Correctness is helped during porting because the new operating system's
-    implementation is wholly contained in a separate directory. There's no
-    chance to make an error in the #if statements and affect some other
-    operating system's implementation.</li>
-  </ul>
-  <p>So, given that we have decided to use #include instead of #if to provide
-  platform specific implementations, there are actually three ways we can go
-  about doing this. None of them are perfect, but we believe we've chosen the
-  lesser of the three evils. Given that there is a variable named $OS which
-  names the platform for which we must build, here's a summary of the three 
-  approaches we could use to determine the correct directory:</p>
-  <ol>
-    <li>Provide the compiler with a -I$(OS) on the command line. This could be
-    provided in only the lib/System makefile.</li>
-    <li>Use autoconf to transform #include statements in the implementation
-    files by using substitutions of @OS@. For example, if we had a file,
-    File.cpp.in, that contained "#include &lt;@OS@/File.cpp&gt;" this would get
-    transformed to "#include &lt;actual/File.cpp&gt;" where "actual" is the
-    actual name of the operating system</li>
-    <li>Create a link from $OBJ_DIR/platform to $SRC_DIR/$OS. This allows us to
-    use a generic directory name to get the correct platform, as in #include
-    &lt;platform/File.cpp&gt;</li>
-  </ol>
-  <p>Let's look at the pitfalls of each approach.</p>
-  <p>In approach #1, we end up with some confusion as to what gets included.
-  Suppose we have lib/System/File.cpp that includes just File.cpp to get the
-  platform specific part of the implementation. In this case, the include
-  directive with the &lt;&gt; syntax will include the right file but the include
-  directive with the "" syntax will recursively include the same file,
-  lib/System/File.cpp. In the case of #include &lt;File.cpp&gt;, the -I options
-  to the compiler are searched first so it works. But in the #include "File.cpp"
-  case, the current directory is searched first. Furthermore, in both cases,
-  neither include directive documents which File.cpp is getting included.</p>
-  <p>In approach #2, we have the problem of needing to reconfigure repeatedly.
-  Developer's generally hate that and we don't want lib/System to be a thorn in
-  everyone's side because it will constantly need updating as operating systems
-  change and as new operating systems are added. The problem occurs when a new
-  implementation file is added to the library. First of all, you have to add a
-  file with the .in suffix, then you have to add that file name to the list of
-  configurable files in the autoconf/configure.ac file, then you have to run
-  AutoRegen.sh to rebuild the configure script, then you have to run the
-  configure script. This is deemed to be a pretty large hassle.</p>
-  <p>In approach #3, we have the problem that not all platforms support links.
-  Fortunately the autoconf macro used to create the link can compensate for
-  this. If a link can't be made, the configure script will copy the correct
-  directory from $BUILD_SRC_DIR to $BUILD_OBJ_DIR under the new name. The only
-  problem with this is that if a copy is made, the copy doesn't get updated if
-  the programmer adds or modifies files in the $BUILD_SRC_DIR. A reconfigure or
-  manual copying is needed to get things to compile.<p>
-  <p>The approach we have taken in lib/System is #3. Here's why:<p>
-  <ul>
-    <li>Approach #1 is rejected because it doesn't document what's actually
-    getting included and the potential for mistakes with alternate include
-    directive forms is high.</li>
-    <li>Approach #2 are both viable and only really impact development when new
-    files are added to the library.</li>
-    <li>However, approach #2 impacts every new file on every platform all the
-    time. With approach #3, only those platforms not supporting links will be
-    affected. The number of platforms not supporting links is very small and
-    they are generally archaic.</li>
-    <li>Given the above, approach #3 seems to have the least impact.</li>
-  </ul>
-</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

@@ -22,15 +22,15 @@
     </ul>
   </li>
   <li><a href="#tree">LLVM Test Suite Tree</a></li>
-  <li><a href="#qmstructure">QMTest Structure</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 and <a
-  href="http://llvm.x10sys.com/rspencer">Reid Spencer</a></p>
+  <p>Written by John T. Criswell, <a
+  href="http://llvm.x10sys.com/rspencer">Reid Spencer</a>, and Tanya Lattner</p>
 </div>
 
 <!--=========================================================================-->
@@ -55,15 +55,12 @@ 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.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.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.netlib.org/f2c">F2C</a></dt>
 <dd>For now, LLVM does not have a Fortran front-end, but using F2C, we can run
@@ -105,30 +102,27 @@ regression tests are in the main "llvm" module under the directory
 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. Or you can do it manually.</p>
-<p>To run all of the simple tests in LLVM, use the master Makefile in the
+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
 </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>
+or<br>
 <pre>
-% gmake -C llvm/test qmtest
+% gmake check
 </pre>
 
-<p>To run only the basic feature tests, QMTest supports the following
-target:</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 Feature.t
+% gmake -C llvm/test TESTSUITE=Regression/Transforms
 </pre>
 
-<p>To run only the regression tests, QMTest supports the following
-target:</p>
-<pre>
-% gmake -C llvm/test Regression.t
-</pre>
+<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>
@@ -151,8 +145,8 @@ programs), run the <tt>llvm-test</tt> tests:</p>
 
 <p>The LLVM test suite contains two major categories of tests: code
 fragments and whole programs. Code fragments are in the <tt>llvm</tt> module
-under the directory under the <tt>llvm/test</tt> directory. The whole programs
-test suite are n the <tt>llvm-test</tt> module under the main directory.</p>
+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>
 
@@ -169,7 +163,7 @@ language front end.</p>
 <p>Code fragments are not complete programs, and they are never executed to
 determine correct behavior.</p> 
 
-<p>Thes code fragment tests are located in the <tt>llvm/test/Features</tt> and 
+<p>These code fragment tests are located in the <tt>llvm/test/Features</tt> and 
 <tt>llvm/test/Regression</tt> directories.</p>
 
 </div>
@@ -253,86 +247,85 @@ 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>
       
-<li><tt>llvm/test/QMTest</tt>
-<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></li>
-
 </ul>
 
 </div>
-
 <!--=========================================================================-->
-<div class="doc_section"><a name="qmstructure">QMTest Structure</a></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 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 <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>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>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>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>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>
 
-<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>
+<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> 
 
-<p>The QMTest namespace is currently composed of the following tests and test
-suites:</p>
+<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> 
 
-<ul>
-<li>Feature
+<dt>%prcontext</dt> 
+<dd>Path to a script that performs grep -C. Use this since not all
+platforms support grep -C.</dd>
 
-<p>These are the feature tests found in the Feature directory.
-They are broken up into the following categories:</p>
+<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>
 
-<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>
+<p>There are also several scripts in the llvm/test/Scripts directory
+that you might find useful when writing <tt>RUN</tt> lines.</p>
 
-  <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>mc
-    <p> Machine code tests.  These tests verify that the LLVM assembly
-    language file can be translated into native assembly code.</p></li>
-
-  <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>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>
-
-<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>
-
-</ul>
+<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>
 
@@ -365,6 +358,32 @@ 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>
 
 <!--=========================================================================-->
@@ -377,18 +396,19 @@ LLVM.</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 only the QMTest driven
+<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 <tt>llvm/tests</tt>.</p>
+<p>For example, to run the Regression tests, type 
+<tt>gmake TESTSUITE=Regression</tt> in <tt>llvm/tests</tt>.</p>
 
 <p>Note that there are no Makefiles in <tt>llvm/test/Features</tt> and
-<tt>llvm/test/Regression</tt>. You must use QMTest from the <tt>llvm/test</tt>
+<tt>llvm/test/Regression</tt>. You must use DejaGNU from the <tt>llvm/test</tt>
 directory to run them.</p>
 
 <p>To run the <tt>llvm-test</tt> suite, you need to use the following steps:
@@ -406,7 +426,7 @@ directory to run them.</p>
     properly configured.</li>
     <li>Use the <tt>configure</tt> script found in the <tt>llvm-test</tt> source
     directory:<br/>
-    <tt>$BUILD_SRC_DIR/configure --with-llvmsrc=$LLVM_SRC_ROOT --with-llvmobj=$LLVM_OBJ_ROOT</tt>
+    <tt>$LLVM_SRC_ROOT/projects/llvm-test/configure --with-llvmsrc=$LLVM_SRC_ROOT --with-llvmobj=$LLVM_OBJ_ROOT</tt>
     </li>
   </ol>
   <li>gmake</li>
@@ -430,11 +450,11 @@ 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 tests in <tt>llvm-test</tt> have no such feature as of this time. If the
+<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>
@@ -454,18 +474,21 @@ 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:
+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
@@ -475,17 +498,16 @@ 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
-export LLVM_LIB_SEARCH_PATH=/proj/work/llvm/cfrontend/install/bytecode-libs
 cd $BASE
 cp /proj/work/llvm/llvm/utils/NightlyTest.pl .
-nice ./NightlyTest.pl -nice -release -verbose -parallel -enable-linscan -noexternals
+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 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>
+<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>
 
 </div>
 
@@ -498,7 +520,7 @@ 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>
+  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>

llvm/docs/UsingLibraries.html

@@ -10,6 +10,7 @@
   <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>
@@ -71,20 +72,24 @@
 <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>
+    <td>LLVM assembly parsing</td></tr>
   <tr><td>LLVMBCReader</td><td><tt>.o</tt></td>
-    <td>LLVM Bytecode Reading</td></tr>
+    <td>LLVM bytecode reading</td></tr>
   <tr><td>LLVMBCWriter</td><td><tt>.o</tt></td>
-    <td>LLVM Bytecode Writing</td></tr>
+    <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>
+    <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</td></tr>
-  <tr><td>LLVMCore</td><td><tt>.o</tt></td>
-    <td>LLVM Core IR</td></tr>
+    <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>
@@ -118,9 +123,11 @@
   <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>
+    <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>
@@ -148,6 +155,312 @@
 </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">

llvm/docs/WritingAnLLVMBackend.html

@@ -91,21 +91,34 @@ implement the following:</p>
       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>Now, for static code generation you also need to write an instruction
-selector for your platform: see <tt>lib/Target/*/*ISelSimple.cpp</tt> which
-is no longer "simple" but it gives you the idea: you have to be able to create
-MachineInstrs for any given LLVM instruction using the <tt>InstVisitor</tt>
-pattern, and produce a <tt>MachineFunction</tt> with
-<tt>MachineBasicBlock</tt>s full of <tt><a
-href="CodeGenerator.html#machineinstr">MachineInstr</a></tt>s for a
-corresponding LLVM Function.  Creating an instruction selector is perhaps the
-most time-consuming part of creating a back-end.</p> 
+<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>
 
@@ -217,10 +230,13 @@ how the C backend is written.</p>
 <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>
+    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>
+    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>

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>
@@ -155,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
@@ -170,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 or 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>
@@ -238,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
@@ -291,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>
@@ -317,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
@@ -334,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;
@@ -362,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
@@ -420,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
@@ -481,7 +485,7 @@ otherwise.</p>
 <div class="doc_text">
 
 <p>The "<tt><a
-href="http://llvm.cs.uiuc.edu/doxygen/structllvm_1_1CallGraphSCCPass.html">CallGraphSCCPass</a></tt>"
+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
@@ -694,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>
 
@@ -722,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>
@@ -943,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>
 
@@ -973,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>
@@ -1007,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>
 
@@ -1212,7 +1216,7 @@ pass is the default implementation for the interface.</p>
 
 <div class="doc_text">
 <p>The <a
-href="http:://llvm.cs.uiuc.edu/doxygen/Statistic_8h-source.html"><tt>Statistic</tt></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
@@ -1263,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>
 
@@ -1287,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
@@ -1324,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
@@ -1365,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
@@ -1473,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)

llvm/docs/doxygen.cfg.in

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

llvm/docs/index.html

@@ -10,6 +10,7 @@
 <div class="doc_title">Documentation for the LLVM System</div>
 
 <div class="doc_text">
+<table class="layout" width="95%"><tr class="layout"><td class="left">
 <ul>
   <li><a href="#llvmdesign">LLVM Design</a></li>
   <li><a href="#userguide">LLVM User Guides</a></li>
@@ -17,6 +18,13 @@
   <li><a href="#subsystems">LLVM Subsystem Documentation</a></li>
   <li><a href="#maillist">LLVM Mailing Lists</a></li>
 </ul>
+</td><td class="right">
+  <form action="http://www.google.com/search" method=get>
+      <input type="hidden" name="sitesearch" value="llvm.cs.uiuc.edu/docs">
+      <input type=text name=q size=25><br>
+      <input type=submit value="Search the LLVM Docs" name="submit">
+  </form>
+</td></tr></table>
 </div>
 
 <div class="doc_author">    
@@ -51,10 +59,15 @@ Discusses how to get up and running quickly with the LLVM infrastructure.
 Everything from unpacking and compilation of the distribution to execution of
 some tools.</li>
 
+<li><a href="GettingStartedVS.html">Getting Started with the LLVM System using
+Microsoft Visual Studio</a> - An addendum to the main Getting Started guide for
+those using Visual Studio on Windows.</li>
+
 <li><a href="CommandGuide/index.html">LLVM Command Guide</a> - A reference
 manual for the LLVM command line utilities ("man" pages for LLVM tools).<br/>
 Current tools:
  <a href="CommandGuide/html/llvm-ar.html">llvm-ar</a>,
+ <a href="CommandGuide/html/llvm-ranlib.html">llvm-ranlib</a>,
  <a href="CommandGuide/html/llvm-as.html">llvm-as</a>,
  <a href="CommandGuide/html/llvm-dis.html">llvm-dis</a>,
  <a href="CommandGuide/html/opt.html">opt</a>,
@@ -70,7 +83,7 @@ Current tools:
  <a href="CommandGuide/html/gccld.html">gccld</a>,
  <a href="CommandGuide/html/stkrc.html">stkrc</a>,
  <a href="CommandGuide/html/bugpoint.html">bugpoint</a>,
- <a href="CommandGuide/html/extract.html">extract</a>,
+ <a href="CommandGuide/html/llvm-extract.html">llvm-extract</a>,
  <a href="CommandGuide/html/llvm-bcanalyzer.html">llvm-bcanalyzer</a>,
  <a href="CommandGuide/html/llvmc.html">llvmc</a>
 </li>
@@ -127,10 +140,6 @@ Provides information on using the command line parsing library.</li>
 Details the LLVM coding standards and provides useful information on writing
 efficient C++ code.</li>
 
-<li><a href="OpenProjects.html">Open Projects</a> - Look here if you are
-interested in doing something with LLVM but aren't sure what needs to be
-done.</li>
-
 <li><a href="ExtendingLLVM.html">Extending LLVM</a> - Look here to see how 
 to add instructions and intrinsics to LLVM.</li>
 
@@ -183,13 +192,17 @@ GC'd programs.</li>
 LLVM</a> - This document describes the design and philosophy behind the LLVM
 source-level debugger.</li>
 
-<li><a href="CommandGuide/html/bugpoint.html">bugpoint</a> - automatic bug 
-finder and test-case reducer description and usage information.</li>
+<li><a href="Bugpoint.html">Bugpoint</a> - automatic bug finder and test-case
+reducer description and usage information.</li>
 
 <li><a href="CompilerDriver.html">Compiler Driver (llvmc)</a> - This document
 describes the design and configuration of the LLVM compiler driver tool,
 <tt>llvmc</tt>.</li>
 
+<li><a href="SystemLibrary.html">System Library</a> - This document describes
+the LLVM System Library (<tt>lib/System</tt>) and how to keep LLVM source code
+portable</li>
+
 </ul>
 
 <!--=======================================================================-->

llvm/docs/llvm.css

@@ -47,11 +47,11 @@ TABLE       { text-align: center; border: 2px solid black;
                      border-bottom: 1px solid #999999; font-size: 12pt;
                      width: 75%; }
 .doc_author     { text-align: left; font-weight: bold; padding-left: 20pt }
-.doc_text       { text-align: left; padding-left: 20pt }
+.doc_text       { text-align: left; padding-left: 20pt; padding-right: 10pt }
 
 .doc_footer     { text-align: left; padding: 0 0 0 0 }
 
-.doc_red        { color: red }
+.doc_hilite     { color: blue; font-weight: bold; }
 
 .doc_table      { text-align: center; width: 90%; 
                   padding: 1px 1px 1px 1px; border: 1px; }
@@ -66,6 +66,7 @@ TABLE       { text-align: center; border: 2px solid black;
                   padding: 0 1em 0 1em;
                   display:table;
                 }
+.doc_notes      { background: #fafafa; border: 1px solid #cecece; padding: 1em }
 
 TABLE.layout    { text-align: left; border: none; border-collapse: collapse;
                   padding: 4px 4px 4px 4px; }

llvm/examples/Fibonacci/fibonacci.cpp

@@ -47,7 +47,7 @@ static Function *CreateFibFunction(Module *M) {
   Value *Two = ConstantSInt::get(Type::IntTy, 2);
 
   // Get pointer to the integer argument of the add1 function...
-  Argument *ArgX = FibF->abegin();   // Get the arg.
+  Argument *ArgX = FibF->arg_begin();   // Get the arg.
   ArgX->setName("AnArg");            // Give it a nice symbolic name for fun.
 
   // Create the true_block.
@@ -64,11 +64,14 @@ static Function *CreateFibFunction(Module *M) {
 
   // create fib(x-1)
   Value *Sub = BinaryOperator::createSub(ArgX, One, "arg", RecurseBB);
-  Value *CallFibX1 = new CallInst(FibF, Sub, "fibx1", RecurseBB);
+  CallInst *CallFibX1 = new CallInst(FibF, Sub, "fibx1", RecurseBB);
+  CallFibX1->setTailCall();
 
   // create fib(x-2)
   Sub = BinaryOperator::createSub(ArgX, Two, "arg", RecurseBB);
-  Value *CallFibX2 = new CallInst(FibF, Sub, "fibx2", RecurseBB);
+  CallInst *CallFibX2 = new CallInst(FibF, Sub, "fibx2", RecurseBB);
+  CallFibX2->setTailCall();
+
 
   // fib(x-1)+fib(x-2)
   Value *Sum = BinaryOperator::createAdd(CallFibX1, CallFibX2,

llvm/examples/HowToUseJIT/HowToUseJIT.cpp

@@ -61,8 +61,8 @@ int main() {
   Value *One = ConstantSInt::get(Type::IntTy, 1);
 
   // Get pointers to the integer argument of the add1 function...
-  assert(Add1F->abegin() != Add1F->aend()); // Make sure there's an arg
-  Argument *ArgX = Add1F->abegin();  // Get the arg
+  assert(Add1F->arg_begin() != Add1F->arg_end()); // Make sure there's an arg
+  Argument *ArgX = Add1F->arg_begin();  // Get the arg
   ArgX->setName("AnArg");            // Give it a nice symbolic name for fun.
 
   // Create the add instruction, inserting it into the end of BB.
@@ -88,6 +88,7 @@ int main() {
   std::vector<Value*> Params;
   Params.push_back(Ten);
   CallInst *Add1CallRes = new CallInst(Add1F, Params, "add1", BB);
+  Add1CallRes->setTailCall(true);
 
   // Create the return instruction and add it to the basic block.
   new ReturnInst(Add1CallRes, BB);

llvm/examples/ModuleMaker/ModuleMaker.cpp

@@ -1,5 +1,12 @@
 //===- examples/ModuleMaker/ModuleMaker.cpp - Example project ---*- C++ -*-===//
 //
+//                     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.
+//
+//===----------------------------------------------------------------------===//
+//
 // This programs is a simple example that creates an LLVM module "from scratch",
 // emitting it as a bytecode file to standard out.  This is just to show how
 // LLVM projects work and to demonstrate some of the LLVM APIs.

llvm/include/llvm/ADT/EquivalenceClasses.h

@@ -7,108 +7,269 @@
 //
 //===----------------------------------------------------------------------===//
 //
-// Generic implementation of equivalence classes and implementation of
-// union-find algorithms A not-so-fancy implementation: 2 level tree i.e root
-// and one more level Overhead of a union = size of the equivalence class being
-// attached Overhead of a find = 1.
+// Generic implementation of equivalence classes through the use Tarjan's
+// efficient union-find algorithm.
 //
 //===----------------------------------------------------------------------===//
 
 #ifndef LLVM_ADT_EQUIVALENCECLASSES_H
 #define LLVM_ADT_EQUIVALENCECLASSES_H
 
-#include <map>
+#include "llvm/ADT/iterator"
+#include "llvm/Support/DataTypes.h"
 #include <set>
-#include <vector>
 
 namespace llvm {
 
+/// EquivalenceClasses - This represents a collection of equivalence classes and
+/// supports three efficient operations: insert an element into a class of its
+/// own, union two classes, and find the class for a given element.  In
+/// addition to these modification methods, it is possible to iterate over all
+/// of the equivalence classes and all of the elements in a class.
+///
+/// This implementation is an efficient implementation that only stores one copy
+/// of the element being indexed per entry in the set, and allows any arbitrary
+/// type to be indexed (as long as it can be ordered with operator<).
+///
+/// Here is a simple example using integers:
+///
+///  EquivalenceClasses<int> EC;
+///  EC.unionSets(1, 2);                // insert 1, 2 into the same set
+///  EC.insert(4); EC.insert(5);        // insert 4, 5 into own sets
+///  EC.unionSets(5, 1);                // merge the set for 1 with 5's set.
+///
+///  for (EquivalenceClasses<int>::iterator I = EC.begin(), E = EC.end();
+///       I != E; ++I) {           // Iterate over all of the equivalence sets.
+///    if (!I->isLeader()) continue;   // Ignore non-leader sets.
+///    for (EquivalenceClasses<int>::member_iterator MI = EC.member_begin(I);
+///         MI != EC.member_end(); ++MI)   // Loop over members in this set.
+///      std::cerr << *MI << " ";  // Print member.
+///    std::cerr << "\n";   // Finish set.
+///  }
+///
+/// This example prints:
+///   4
+///   5 1 2
+///
 template <class ElemTy>
 class EquivalenceClasses {
-  // Maps each element to the element that is the leader of its 
-  // equivalence class.
-  std::map<ElemTy, ElemTy> Elem2LeaderMap;
+  /// ECValue - The EquivalenceClasses data structure is just a set of these.
+  /// Each of these represents a relation for a value.  First it stores the
+  /// value itself, which provides the ordering that the set queries.  Next, it
+  /// provides a "next pointer", which is used to enumerate all of the elements
+  /// in the unioned set.  Finally, it defines either a "end of list pointer" or
+  /// "leader pointer" depending on whether the value itself is a leader.  A
+  /// "leader pointer" points to the node that is the leader for this element,
+  /// if the node is not a leader.  A "end of list pointer" points to the last
+  /// node in the list of members of this list.  Whether or not a node is a
+  /// leader is determined by a bit stolen from one of the pointers.
+  class ECValue {
+    friend class EquivalenceClasses;
+    mutable const ECValue *Leader, *Next;
+    ElemTy Data;
+    // ECValue ctor - Start out with EndOfList pointing to this node, Next is
+    // Null, isLeader = true.
+    ECValue(const ElemTy &Elt)
+      : Leader(this), Next((ECValue*)(intptr_t)1), Data(Elt) {}
 
-  // Maintains the set of leaders
-  std::set<ElemTy> LeaderSet;
-
-  // Caches the equivalence class for each leader
-  std::map<ElemTy, std::set<ElemTy> > LeaderToEqClassMap;
-
-  // Make Element2 the leader of the union of classes Element1 and Element2
-  // Element1 and Element2 are presumed to be leaders of their respective
-  // equivalence classes.
-  void attach(ElemTy Element1, ElemTy Element2) {
-    for (typename std::map<ElemTy, ElemTy>::iterator ElemI = 
-	   Elem2LeaderMap.begin(), ElemE = Elem2LeaderMap.end(); 
-	 ElemI != ElemE; ++ElemI) {
-      if (ElemI->second == Element1)
-	Elem2LeaderMap[ElemI->first] = Element2;
+    const ECValue *getLeader() const {
+      if (isLeader()) return this;
+      if (Leader->isLeader()) return Leader;
+      // Path compression.
+      return Leader = Leader->getLeader();
     }
+    const ECValue *getEndOfList() const {
+      assert(isLeader() && "Cannot get the end of a list for a non-leader!");
+      return Leader;
     }
 
+    void setNext(const ECValue *NewNext) const {
+      assert(getNext() == 0 && "Already has a next pointer!");
+      Next = (const ECValue*)((intptr_t)NewNext | (intptr_t)isLeader());
+    }
+  public:
+    ECValue(const ECValue &RHS) : Leader(this), Next((ECValue*)(intptr_t)1),
+                                  Data(RHS.Data) {
+      // Only support copying of singleton nodes.
+      assert(RHS.isLeader() && RHS.getNext() == 0 && "Not a singleton!");
+    }
+
+    bool operator<(const ECValue &UFN) const { return Data < UFN.Data; }
+
+    bool isLeader() const { return (intptr_t)Next & 1; }
+    const ElemTy &getData() const { return Data; }
+
+    const ECValue *getNext() const {
+      return (ECValue*)((intptr_t)Next & ~(intptr_t)1);
+    }
+
+    template<typename T>
+    bool operator<(const T &Val) const { return Data < Val; }
+  };
+
+  /// TheMapping - This implicitly provides a mapping from ElemTy values to the
+  /// ECValues, it just keeps the key as part of the value.
+  std::set<ECValue> TheMapping;
+
 public:
-  // If an element has not yet in any class, make it a separate new class.
-  // Return the leader of the class containing the element.
-  ElemTy addElement (ElemTy NewElement) {
-    typename std::map<ElemTy, ElemTy>::iterator ElemI = 
-      Elem2LeaderMap.find(NewElement);
-    if (ElemI == Elem2LeaderMap.end()) {
-      Elem2LeaderMap[NewElement] = NewElement;
-      LeaderSet.insert(NewElement);
-      return NewElement;
-    }
-    else
-      return ElemI->second;
+  EquivalenceClasses() {}
+  EquivalenceClasses(const EquivalenceClasses &RHS) {
+    operator=(RHS);
   }
 
-  ElemTy findClass(ElemTy Element) const {
-    typename std::map<ElemTy, ElemTy>::const_iterator I =
-      Elem2LeaderMap.find(Element);
-    return (I == Elem2LeaderMap.end())? (ElemTy) 0 : I->second;
+  const EquivalenceClasses &operator=(const EquivalenceClasses &RHS) {
+    TheMapping.clear();
+    for (iterator I = RHS.begin(), E = RHS.end(); I != E; ++I)
+      if (I->isLeader()) {
+        member_iterator MI = RHS.member_begin(I);
+        member_iterator LeaderIt = member_begin(insert(*MI));
+        for (++MI; MI != member_end(); ++MI)
+          unionSets(LeaderIt, member_begin(insert(*MI)));
+      }
+    return *this;
   }
 
-  /// Attach the set with Element1 to the set with Element2 adding Element1 and
-  /// Element2 to the set of equivalence classes if they are not there already.
-  /// Implication: Make Element1 the element in the smaller set.
-  /// Take Leader[Element1] out of the set of leaders.
-  void unionSetsWith(ElemTy Element1, ElemTy Element2) {
-    // If either Element1 or Element2 does not already exist, include it
-    const ElemTy& leader1 = addElement(Element1);
-    const ElemTy& leader2 = addElement(Element2);
-    assert(leader1 != (ElemTy) 0 && leader2 != (ElemTy) 0);
-    if (leader1 != leader2) {
-      attach(leader1, leader2);
-      LeaderSet.erase(leader1);
+  //===--------------------------------------------------------------------===//
+  // Inspection methods
+  //
+
+  /// iterator* - Provides a way to iterate over all values in the set.
+  typedef typename std::set<ECValue>::const_iterator iterator;
+  iterator begin() const { return TheMapping.begin(); }
+  iterator end() const { return TheMapping.end(); }
+
+  /// member_* Iterate over the members of an equivalence class.
+  ///
+  class member_iterator;
+  member_iterator member_begin(iterator I) const {
+    // Only leaders provide anything to iterate over.
+    return member_iterator(I->isLeader() ? &*I : 0);
   }
+  member_iterator member_end() const {
+    return member_iterator(0);
   }
 
-  // Returns a vector containing all the elements in the equivalence class
-  // including Element1
-  const std::set<ElemTy> & getEqClass(ElemTy Element1) {
-    assert(Elem2LeaderMap.find(Element1) != Elem2LeaderMap.end());
-    const ElemTy classLeader = Elem2LeaderMap[Element1];
-    
-    std::set<ElemTy> & EqClass = LeaderToEqClassMap[classLeader];
-    
-    // If the EqClass vector is empty, it has not been computed yet: do it now
-    if (EqClass.empty()) {
-      for (typename std::map<ElemTy, ElemTy>::iterator
-             ElemI = Elem2LeaderMap.begin(), ElemE = Elem2LeaderMap.end(); 
-           ElemI != ElemE; ++ElemI)
-        if (ElemI->second == classLeader)
-          EqClass.insert(ElemI->first);
-      assert(! EqClass.empty());        // must at least include the leader
+  /// findValue - Return an iterator to the specified value.  If it does not
+  /// exist, end() is returned.
+  iterator findValue(const ElemTy &V) const {
+    return TheMapping.find(V);
   }
 
-    return EqClass;
+  /// getLeaderValue - Return the leader for the specified value that is in the
+  /// set.  It is an error to call this method for a value that is not yet in
+  /// the set.  For that, call getOrInsertLeaderValue(V).
+  const ElemTy &getLeaderValue(const ElemTy &V) const {
+    member_iterator MI = findLeader(V);
+    assert(MI != member_end() && "Value is not in the set!");
+    return *MI;
   }
 
-        std::set<ElemTy>& getLeaderSet()       { return LeaderSet; }
-  const std::set<ElemTy>& getLeaderSet() const { return LeaderSet; }
+  /// getOrInsertLeaderValue - Return the leader for the specified value that is
+  /// in the set.  If the member is not in the set, it is inserted, then
+  /// returned.
+  const ElemTy &getOrInsertLeaderValue(const ElemTy &V) const {
+    member_iterator MI = findLeader(insert(V));
+    assert(MI != member_end() && "Value is not in the set!");
+    return *MI;
+  }
 
-        std::map<ElemTy, ElemTy>& getLeaderMap()       { return Elem2LeaderMap;}
-  const std::map<ElemTy, ElemTy>& getLeaderMap() const { return Elem2LeaderMap;}
+  /// getNumClasses - Return the number of equivalence classes in this set.
+  /// Note that this is a linear time operation.
+  unsigned getNumClasses() const {
+    unsigned NC = 0;
+    for (iterator I = begin(), E = end(); I != E; ++I)
+      if (I->isLeader()) ++NC;
+    return NC;
+  }
+
+
+  //===--------------------------------------------------------------------===//
+  // Mutation methods
+
+  /// insert - Insert a new value into the union/find set, ignoring the request
+  /// if the value already exists.
+  iterator insert(const ElemTy &Data) {
+    return TheMapping.insert(Data).first;
+  }
+
+  /// findLeader - Given a value in the set, return a member iterator for the
+  /// equivalence class it is in.  This does the path-compression part that
+  /// makes union-find "union findy".  This returns an end iterator if the value
+  /// is not in the equivalence class.
+  ///
+  member_iterator findLeader(iterator I) const {
+    if (I == TheMapping.end()) return member_end();
+    return member_iterator(I->getLeader());
+  }
+  member_iterator findLeader(const ElemTy &V) const {
+    return findLeader(TheMapping.find(V));
+  }
+
+
+  /// union - Merge the two equivalence sets for the specified values, inserting
+  /// them if they do not already exist in the equivalence set.
+  member_iterator unionSets(const ElemTy &V1, const ElemTy &V2) {
+    iterator V1I = insert(V1), V2I = insert(V2);
+    return unionSets(findLeader(V1I), findLeader(V2I));
+  }
+  member_iterator unionSets(member_iterator L1, member_iterator L2) {
+    assert(L1 != member_end() && L2 != member_end() && "Illegal inputs!");
+    if (L1 == L2) return L1;   // Unifying the same two sets, noop.
+
+    // Otherwise, this is a real union operation.  Set the end of the L1 list to
+    // point to the L2 leader node.
+    const ECValue &L1LV = *L1.Node, &L2LV = *L2.Node;
+    L1LV.getEndOfList()->setNext(&L2LV);
+
+    // Update L1LV's end of list pointer.
+    L1LV.Leader = L2LV.getEndOfList();
+
+    // Clear L2's leader flag:
+    L2LV.Next = L2LV.getNext();
+
+    // L2's leader is now L1.
+    L2LV.Leader = &L1LV;
+    return L1;
+  }
+
+  class member_iterator : public forward_iterator<ElemTy, ptrdiff_t> {
+    typedef forward_iterator<const ElemTy, ptrdiff_t> super;
+    const ECValue *Node;
+    friend class EquivalenceClasses;
+  public:
+    typedef size_t size_type;
+    typedef typename super::pointer pointer;
+    typedef typename super::reference reference;
+
+    explicit member_iterator() {}
+    explicit member_iterator(const ECValue *N) : Node(N) {}
+    member_iterator(const member_iterator &I) : Node(I.Node) {}
+
+    reference operator*() const {
+      assert(Node != 0 && "Dereferencing end()!");
+      return Node->getData();
+    }
+    reference operator->() const { return operator*(); }
+
+    member_iterator &operator++() {
+      assert(Node != 0 && "++'d off the end of the list!");
+      Node = Node->getNext();
+      return *this;
+    }
+
+    member_iterator operator++(int) {    // postincrement operators.
+      member_iterator tmp = *this;
+      ++*this;
+      return tmp;
+    }
+
+    bool operator==(const member_iterator &RHS) const {
+      return Node == RHS.Node;
+    }
+    bool operator!=(const member_iterator &RHS) const {
+      return Node != RHS.Node;
+    }
+  };
 };
 
 } // End llvm namespace

llvm/include/llvm/ADT/HashExtras.h

@@ -23,12 +23,6 @@
 // Cannot specialize hash template from outside of the std namespace.
 namespace HASH_NAMESPACE {
 
-template <> struct hash<std::string> {
-  size_t operator()(std::string const &str) const {
-    return hash<char const *>()(str.c_str());
-  }
-};
-
 // Provide a hash function for arbitrary pointers...
 template <class T> struct hash<T *> {
   inline size_t operator()(const T *Val) const {
@@ -36,6 +30,12 @@ template <class T> struct hash<T *> {
   }
 };
 
+template <> struct hash<std::string> {
+  size_t operator()(std::string const &str) const {
+    return hash<char const *>()(str.c_str());
+  }
+};
+
 }  // End namespace std
 
 #endif

llvm/include/llvm/ADT/STLExtras.h

@@ -27,39 +27,6 @@ namespace llvm {
 //     Extra additions to <functional>
 //===----------------------------------------------------------------------===//
 
-// bind_obj - Often times you want to apply the member function of an object
-// as a unary functor.  This macro is shorthand that makes it happen less
-// verbosely.
-//
-// Example:
-//  struct Summer { void accumulate(int x); }
-//  vector<int> Numbers;
-//  Summer MyS;
-//  for_each(Numbers.begin(), Numbers.end(),
-//           bind_obj(&MyS, &Summer::accumulate));
-//
-// TODO: When I get lots of extra time, convert this from an evil macro
-//
-#define bind_obj(OBJ, METHOD) std::bind1st(std::mem_fun(METHOD), OBJ)
-
-
-// bitwise_or - This is a simple functor that applys operator| on its two 
-// arguments to get a boolean result.
-//
-template<class Ty>
-struct bitwise_or : public std::binary_function<Ty, Ty, bool> {
-  bool operator()(const Ty& left, const Ty& right) const {
-    return left | right;
-  }
-};
-
-template<class Ty>
-struct less_ptr : public std::binary_function<Ty, Ty, bool> {
-  bool operator()(const Ty* left, const Ty* right) const {
-    return *left < *right;
-  }
-};
-
 template<class Ty>
 struct greater_ptr : public std::binary_function<Ty, Ty, bool> {
   bool operator()(const Ty* left, const Ty* right) const {
@@ -187,79 +154,6 @@ inline ItTy prior(ItTy it)
   return it;
 }
 
-
-//===----------------------------------------------------------------------===//
-//     Extra additions to <algorithm>
-//===----------------------------------------------------------------------===//
-
-// apply_until - Apply a functor to a sequence continually, unless the
-// functor returns true.  Return true if the functor returned true, return false
-// if the functor never returned true.
-//
-template <class InputIt, class Function>
-bool apply_until(InputIt First, InputIt Last, Function Func) {
-  for ( ; First != Last; ++First)
-    if (Func(*First)) return true;
-  return false;
-}
-
-
-// reduce - Reduce a sequence values into a single value, given an initial
-// value and an operator.
-//
-template <class InputIt, class Function, class ValueType>
-ValueType reduce(InputIt First, InputIt Last, Function Func, ValueType Value) {
-  for ( ; First != Last; ++First)
-    Value = Func(*First, Value);
-  return Value;
-}
-
-#if 1   // This is likely to be more efficient
-
-// reduce_apply - Reduce the result of applying a function to each value in a
-// sequence, given an initial value, an operator, a function, and a sequence.
-//
-template <class InputIt, class Function, class ValueType, class TransFunc>
-inline ValueType reduce_apply(InputIt First, InputIt Last, Function Func, 
-			      ValueType Value, TransFunc XForm) {
-  for ( ; First != Last; ++First)
-    Value = Func(XForm(*First), Value);
-  return Value;
-}
-
-#else  // This is arguably more elegant
-
-// reduce_apply - Reduce the result of applying a function to each value in a
-// sequence, given an initial value, an operator, a function, and a sequence.
-//
-template <class InputIt, class Function, class ValueType, class TransFunc>
-inline ValueType reduce_apply2(InputIt First, InputIt Last, Function Func, 
-			       ValueType Value, TransFunc XForm) {
-  return reduce(map_iterator(First, XForm), map_iterator(Last, XForm),
-		Func, Value);
-}
-#endif
-
-
-// reduce_apply_bool - Reduce the result of applying a (bool returning) function
-// to each value in a sequence.  All of the bools returned by the mapped
-// function are bitwise or'd together, and the result is returned.
-//
-template <class InputIt, class Function>
-inline bool reduce_apply_bool(InputIt First, InputIt Last, Function Func) {
-  return reduce_apply(First, Last, bitwise_or<bool>(), false, Func);
-}
-
-
-// map - This function maps the specified input sequence into the specified
-// output iterator, applying a unary function in between.
-//
-template <class InIt, class OutIt, class Functor>
-inline OutIt mapto(InIt Begin, InIt End, OutIt Dest, Functor F) {
-  return copy(map_iterator(Begin, F), map_iterator(End, F), Dest);
-}
-
-
 //===----------------------------------------------------------------------===//
 //     Extra additions to <utility>
 //===----------------------------------------------------------------------===//

llvm/include/llvm/ADT/StringExtras.h

@@ -29,7 +29,7 @@ static inline std::string utohexstr(uint64_t X) {
   if (X == 0) *--BufPtr = '0';  // Handle special case...
 
   while (X) {
-    unsigned char Mod = (unsigned char)X & 15;
+    unsigned char Mod = static_cast<unsigned char>(X) & 15;
     if (Mod < 10)
       *--BufPtr = '0' + Mod;
     else
@@ -100,14 +100,16 @@ static inline std::string itostr(int X) {
 static inline std::string ftostr(double V) {
   char Buffer[200];
   sprintf(Buffer, "%20.6e", V);
-  return Buffer;
+  char *B = Buffer;
+  while (*B == ' ') ++B;
+  return B;
 }
 
 static inline std::string LowercaseString(const std::string &S) {
   std::string result(S);
   for (unsigned i = 0; i < S.length(); ++i)
     if (isupper(result[i]))
-      result[i] = (char)tolower(result[i]);
+      result[i] = char(tolower(result[i]));
   return result;
 }
 

llvm/include/llvm/ADT/hash_map.in

@@ -23,11 +23,13 @@
 //  2.95.x       ::        hash_map
 //  3.0.4       std      ext/hash_map
 //  3.1      __gnu_cxx   ext/hash_map
+//  HP aCC6     std      stdex/rw/hashm*ap.h
 //
 
 #undef HAVE_GNU_EXT_HASH_MAP
 #undef HAVE_STD_EXT_HASH_MAP
 #undef HAVE_GLOBAL_HASH_MAP
+#undef HAVE_RW_STDEX_HASH_MAP_H
 
 #if HAVE_GNU_EXT_HASH_MAP
 // This is for GCC-3.1+ which puts hash in ext/hash_map
@@ -51,12 +53,51 @@
 #  define HASH_NAMESPACE std
 # endif
 
+// HP aCC doesn't include an SGI-like hash_map. For this platform (or
+// any others using Rogue Wave Software's Tools.h++ library), we wrap
+// around them in std::
+#elif HAVE_RW_STDEX_HASH_MAP_H
+# include <rw/stdex/hashmap.h>
+# include <rw/stdex/hashmmap.h>
+# ifndef HASH_NAMESPACE
+#  define HASH_NAMESPACE std
+# endif
+
 // Give a warning if we couldn't find it, instead of (or in addition to)
 // randomly doing something dumb.
 #else
 # warning "Autoconfiguration failed to find the hash_map header file."
 #endif
 
+// we wrap Rogue Wave Tools.h++ rw_hashmap into something SGI-looking, here:
+#ifdef HAVE_RW_STDEX_HASH_MAP_H
+namespace HASH_NAMESPACE {
+
+template <class DataType> struct hash {
+  unsigned int operator()(const unsigned int& x) const {
+      return x;
+  }
+};
+
+template <typename KeyType,
+          typename ValueType,
+          class _HashFcn = hash<KeyType>,
+          class _EqualKey = equal_to<KeyType>,
+          class _A = allocator <ValueType> >
+class hash_map : public rw_hashmap<KeyType, ValueType, class _HashFcn, class _EqualKey, class _A> {
+};
+
+template <typename KeyType,
+          typename ValueType,
+          class _HashFcn = hash<KeyType>,
+          class _EqualKey = equal_to<KeyType>,
+          class _A = allocator <ValueType> >
+class hash_multimap : public rw_hashmultimap<KeyType, ValueType, class _HashFcn, class _EqualKey, class _A> {
+};
+
+} // end HASH_NAMESPACE;
+#endif
+
 using HASH_NAMESPACE::hash_map;
 using HASH_NAMESPACE::hash_multimap;
 using HASH_NAMESPACE::hash;
@@ -65,6 +106,35 @@ using HASH_NAMESPACE::hash;
 // out specializations like stl_bvector.h, causing link conflicts.
 #include <vector>
 
+#ifdef _MSC_VER
+
+// GCC and VC++ have differing ways of implementing hash_maps.  As it's not
+// standardized, that's to be expected.  This adapter class allows VC++
+// hash_map to use GCC's hash classes.
+namespace stdext {
+  template<class Key> struct hash;
+  
+  // Provide a hash function for unsigned ints...
+  template<> struct hash<unsigned int> {
+    inline size_t operator()(unsigned int Val) const {
+      return Val;
+    }
+  };
+
+  template<class Key> class hash_compare<Key, std::less<Key> > {
+    std::less<Key> comp;
+  public:
+    enum { bucket_size = 4 };
+    enum { min_buckets = 8 };
+    hash_compare() {}
+    hash_compare(std::less<Key> pred) : comp(pred) {}
+    size_t operator()(const Key& key) const { return hash<Key>()(key); }
+    bool operator()(const Key& k1, const Key& k2) const { return comp(k1, k2); }
+  };
+}
+
+#endif
+
 #include "llvm/ADT/HashExtras.h"
 
 #endif

llvm/include/llvm/ADT/hash_set.in

@@ -24,11 +24,13 @@
 //  2.95.x       ::        hash_set
 //  3.0.4       std      ext/hash_set
 //  3.1      __gnu_cxx   ext/hash_set
+//  HP aCC6     std      stdex/rw/hashset.h
 //
 
 #undef HAVE_GNU_EXT_HASH_SET
 #undef HAVE_STD_EXT_HASH_SET
 #undef HAVE_GLOBAL_HASH_SET
+#undef HAVE_RW_STDEX_HASH_SET_H
 
 // GCC versions 3.1 and later put hash_set in <ext/hash_set> and in
 // the __gnu_cxx namespace.
@@ -53,12 +55,43 @@
 #  define HASH_NAMESPACE std
 # endif
 
+// HP aCC doesn't include an SGI-like hash_set. For this platform (or
+// any others using Rogue Wave Software's Tools.h++ library), we wrap
+// around them in std::
+#elif HAVE_RW_STDEX_HASH_SET_H
+# include <rw/stdex/hashset.h>
+# ifndef HASH_NAMESPACE
+#  define HASH_NAMESPACE std
+# endif
+
 // Give a warning if we couldn't find it, instead of (or in addition to)
 // randomly doing something dumb.
 #else
 # warning "Autoconfiguration failed to find the hash_set header file."
 #endif
 
+// we wrap Rogue Wave Tools.h++ rw_hashset into something SGI-looking, here:
+#ifdef HAVE_RW_STDEX_HASH_SET_H
+namespace HASH_NAMESPACE {
+
+/*
+template <class DataType> struct hash {
+    unsigned int operator()(const unsigned int& x) const {
+	return x;
+    }
+};
+*/
+
+template <typename ValueType,
+	  class _HashFcn = hash<ValueType>,
+	  class _EqualKey = equal_to<ValueType>,
+	  class _A = allocator <ValueType> >
+class hash_set : public rw_hashset<ValueType, class _HashFcn, class _EqualKey, class _A> {
+};
+
+} // end HASH_NAMESPACE;
+#endif
+
 using HASH_NAMESPACE::hash_set;
 using HASH_NAMESPACE::hash;
 

llvm/include/llvm/ADT/ilist

@@ -58,9 +58,10 @@ struct ilist_traits {
   static void setPrev(NodeTy *N, NodeTy *Prev) { N->setPrev(Prev); }
   static void setNext(NodeTy *N, NodeTy *Next) { N->setNext(Next); }
 
-  static NodeTy *createNode() { return new NodeTy(); }
   static NodeTy *createNode(const NodeTy &V) { return new NodeTy(V); }
 
+  static NodeTy *createSentinel() { return new NodeTy(); }
+  static void destroySentinel(NodeTy *N) { delete N; }
 
   void addNodeToList(NodeTy *NTy) {}
   void removeNodeFromList(NodeTy *NTy) {}
@@ -168,93 +169,6 @@ void operator+(int, ilist_iterator<T>);
 template<typename T>
 void operator+(ilist_iterator<T>,int);
 
-//===----------------------------------------------------------------------===//
-// ilist_compat_iterator<Node> - Compatibility iterator for intrusive list.
-// This makes an ilist<X> act like an std::list<X*>, where you have to
-// dereference stuff multiple times.  This should only be used for temporary
-// migration purposes.  Because we don't support "changing the pointer", we only
-// expose constant pointers.
-//
-template<typename NodeTy>
-class ilist_compat_iterator
-  : public bidirectional_iterator<NodeTy* const, ptrdiff_t> {
-  typedef ilist_traits<NodeTy> Traits;
-  typedef bidirectional_iterator<NodeTy* const, ptrdiff_t> super;
-
-public:
-  typedef size_t size_type;
-  typedef typename super::pointer pointer;
-  typedef typename super::reference reference;
-private:
-  NodeTy *NodePtr;
-public:
-
-  ilist_compat_iterator(NodeTy *NP) : NodePtr(NP) {}
-  ilist_compat_iterator() : NodePtr(0) {}
-
-  // This is templated so that we can allow constructing a const iterator from
-  // a nonconst iterator...
-  template<class node_ty>
-  ilist_compat_iterator(const ilist_compat_iterator<node_ty> &RHS)
-    : NodePtr(RHS.getNodePtrUnchecked()) {}
-
-  // This is templated so that we can allow assigning to a const iterator from
-  // a nonconst iterator...
-  template<class node_ty>
-  const ilist_compat_iterator &operator=(const 
-                                         ilist_compat_iterator<node_ty> &RHS) {
-    NodePtr = RHS.getNodePtrUnchecked();
-    return *this;
-  }
-
-  // Accessors...
-  operator pointer() const {
-    assert(Traits::getNext(NodePtr) != 0 && "Dereferencing end()!");
-    return &NodePtr;
-  }
-
-  reference operator*() const {
-    assert(Traits::getNext(NodePtr) != 0 && "Dereferencing end()!");
-    return NodePtr;
-  }
-  pointer operator->() { return &operator*(); }
-  const pointer operator->() const { return &operator*(); }
-
-  // Comparison operators
-  bool operator==(const ilist_compat_iterator &RHS) const {
-    return NodePtr == RHS.NodePtr;
-  }
-  bool operator!=(const ilist_compat_iterator &RHS) const {
-    return NodePtr != RHS.NodePtr;
-  }
-
-  // Increment and decrement operators...
-  ilist_compat_iterator &operator--() {      // predecrement - Back up
-    NodePtr = Traits::getPrev(NodePtr);
-    assert(NodePtr && "--'d off the beginning of an ilist!");
-    return *this;
-  }
-  ilist_compat_iterator &operator++() {      // preincrement - Advance
-    NodePtr = Traits::getNext(NodePtr);
-    assert(NodePtr && "++'d off the end of an ilist!");
-    return *this;
-  }
-  ilist_compat_iterator operator--(int) {    // postdecrement operators...
-    ilist_compat_iterator tmp = *this;
-    --*this;
-    return tmp;
-  }
-  ilist_compat_iterator operator++(int) {    // postincrement operators...
-    ilist_compat_iterator tmp = *this;
-    ++*this;
-    return tmp;
-  }
-
-  // Internal interface, do not use...
-  pointer getNodePtrUnchecked() const { return NodePtr; }
-};
-
-
 // Allow ilist_iterators to convert into pointers to a node automatically when
 // used by the dyn_cast, cast, isa mechanisms...
 
@@ -301,11 +215,11 @@ public:
   typedef std::reverse_iterator<const_iterator>  const_reverse_iterator;
   typedef std::reverse_iterator<iterator>  reverse_iterator;
 
-  iplist() : Head(Traits::createNode()), Tail(Head) {
+  iplist() : Head(Traits::createSentinel()), Tail(Head) {
     setNext(Head, 0);
     setPrev(Head, 0);
   }
-  ~iplist() { clear(); delete Tail; }
+  ~iplist() { clear(); Traits::destroySentinel(Tail); }
 
   // Iterator creation methods.
   iterator begin()             { return iterator(Head); }
@@ -320,11 +234,6 @@ public:
   const_reverse_iterator rend() const  {return const_reverse_iterator(begin());}
 
 
-  // "compatibility" iterator creation methods.
-  typedef ilist_compat_iterator<NodeTy> compat_iterator;
-  compat_iterator compat_begin() const { return compat_iterator(Head); }
-  compat_iterator compat_end()   const { return compat_iterator(Tail); }
-
   // Miscellaneous inspection routines.
   size_type max_size() const { return size_type(-1); }
   bool empty() const { return Head == Tail; }

llvm/include/llvm/Analysis/AliasAnalysis.h

@@ -100,6 +100,93 @@ public:
   ///
   virtual bool pointsToConstantMemory(const Value *P);
 
+  //===--------------------------------------------------------------------===//
+  /// Simple mod/ref information...
+  ///
+
+  /// ModRefResult - Represent the result of a mod/ref query.  Mod and Ref are
+  /// bits which may be or'd together.
+  ///
+  enum ModRefResult { NoModRef = 0, Ref = 1, Mod = 2, ModRef = 3 };
+
+
+  /// ModRefBehavior - Summary of how a function affects memory in the program.
+  /// Loads from constant globals are not considered memory accesses for this
+  /// interface.  Also, functions may freely modify stack space local to their
+  /// invocation without having to report it through these interfaces.
+  enum ModRefBehavior {
+    // DoesNotAccessMemory - This function does not perform any non-local loads
+    // or stores to memory.
+    //
+    // This property corresponds to the GCC 'const' attribute.
+    DoesNotAccessMemory,
+
+    // AccessesArguments - This function accesses function arguments in
+    // non-volatile and well known ways, but does not access any other memory.
+    //
+    // Clients may call getArgumentAccesses to get specific information about
+    // how pointer arguments are used.
+    AccessesArguments,
+
+    // AccessesArgumentsAndGlobals - This function has accesses function
+    // arguments and global variables in non-volatile and well-known ways, but
+    // does not access any other memory.
+    //
+    // Clients may call getArgumentAccesses to get specific information about
+    // how pointer arguments and globals are used.
+    AccessesArgumentsAndGlobals,
+
+    // OnlyReadsMemory - This function does not perform any non-local stores or
+    // volatile loads, but may read from any memory location.
+    //
+    // This property corresponds to the GCC 'pure' attribute.
+    OnlyReadsMemory,
+
+    // UnknownModRefBehavior - This indicates that the function could not be
+    // classified into one of the behaviors above.
+    UnknownModRefBehavior
+  };
+
+  /// PointerAccessInfo - This struct is used to return results for pointers,
+  /// globals, and the return value of a function.
+  struct PointerAccessInfo {
+    /// V - The value this record corresponds to.  This may be an Argument for
+    /// the function, a GlobalVariable, or null, corresponding to the return
+    /// value for the function.
+    Value *V;
+
+    /// ModRefInfo - Whether the pointer is loaded or stored to/from.
+    ///
+    ModRefResult ModRefInfo;
+
+    /// AccessType - Specific fine-grained access information for the argument.
+    /// If none of these classifications is general enough, the
+    /// getModRefBehavior method should not return AccessesArguments*.  If a
+    /// record is not returned for a particular argument, the argument is never
+    /// dead and never dereferenced.
+    enum AccessType {
+      /// ScalarAccess - The pointer is dereferenced.
+      ///
+      ScalarAccess,
+
+      /// ArrayAccess - The pointer is indexed through as an array of elements.
+      ///
+      ArrayAccess,
+
+      /// ElementAccess ?? P->F only?
+
+      /// CallsThrough - Indirect calls are made through the specified function
+      /// pointer.
+      CallsThrough,
+    };
+  };
+
+  /// getModRefBehavior - Return the behavior of the specified function if
+  /// called from the specified call site.  The call site may be null in which
+  /// case the most generic behavior of this function should be returned.
+  virtual ModRefBehavior getModRefBehavior(Function *F, CallSite CS,
+                                     std::vector<PointerAccessInfo> *Info = 0);
+
   /// doesNotAccessMemory - If the specified function is known to never read or
   /// write memory, return true.  If the function only reads from known-constant
   /// memory, it is also legal to return true.  Functions that unwind the stack
@@ -111,7 +198,9 @@ public:
   ///
   /// This property corresponds to the GCC 'const' attribute.
   ///
-  virtual bool doesNotAccessMemory(Function *F);
+  bool doesNotAccessMemory(Function *F) {
+    return getModRefBehavior(F, CallSite()) == DoesNotAccessMemory;
+  }
 
   /// onlyReadsMemory - If the specified function is known to only read from
   /// non-volatile memory (or not access memory at all), return true.  Functions
@@ -122,18 +211,14 @@ public:
   ///
   /// This property corresponds to the GCC 'pure' attribute.
   ///
-  virtual bool onlyReadsMemory(Function *F);
+  bool onlyReadsMemory(Function *F) {
+    /// FIXME: If the analysis returns more precise info, we can reduce it to
+    /// this.
+    ModRefBehavior MRB = getModRefBehavior(F, CallSite());
+    return MRB == DoesNotAccessMemory || MRB == OnlyReadsMemory;
+  }
 
 
-  //===--------------------------------------------------------------------===//
-  /// Simple mod/ref information...
-  ///
-
-  /// ModRefResult - Represent the result of a mod/ref query.  Mod and Ref are
-  /// bits which may be or'd together.
-  ///
-  enum ModRefResult { NoModRef = 0, Ref = 1, Mod = 2, ModRef = 3 };
-
   /// getModRefInfo - Return information about whether or not an instruction may
   /// read or write memory specified by the pointer operand.  An instruction
   /// that doesn't read or write memory may be trivially LICM'd for example.

llvm/include/llvm/Analysis/DataStructure/DSGraph.h

@@ -16,6 +16,9 @@
 #define LLVM_ANALYSIS_DSGRAPH_H
 
 #include "llvm/Analysis/DataStructure/DSNode.h"
+#include "llvm/ADT/hash_map"
+#include "llvm/ADT/EquivalenceClasses.h"
+#include <list>
 
 namespace llvm {
 
@@ -38,7 +41,12 @@ class DSScalarMap {
 
   typedef hash_set<GlobalValue*> GlobalSetTy;
   GlobalSetTy GlobalSet;
+
+  EquivalenceClasses<GlobalValue*> &GlobalECs;
 public:
+  DSScalarMap(EquivalenceClasses<GlobalValue*> &ECs) : GlobalECs(ECs) {}
+
+  EquivalenceClasses<GlobalValue*> &getGlobalECs() const { return GlobalECs; }
 
   // Compatibility methods: provide an interface compatible with a map of
   // Value* to DSNodeHandle's.
@@ -48,11 +56,60 @@ public:
   iterator end()   { return ValueMap.end(); }
   const_iterator begin() const { return ValueMap.begin(); }
   const_iterator end() const { return ValueMap.end(); }
-  iterator find(Value *V) { return ValueMap.find(V); }
-  const_iterator find(Value *V) const { return ValueMap.find(V); }
-  unsigned count(Value *V) const { return ValueMap.count(V); }
 
-  void erase(Value *V) { erase(find(V)); }
+  GlobalValue *getLeaderForGlobal(GlobalValue *GV) const {
+    EquivalenceClasses<GlobalValue*>::iterator ECI = GlobalECs.findValue(GV);
+    if (ECI == GlobalECs.end()) return GV;
+    return *GlobalECs.findLeader(ECI);
+  }
+
+
+  iterator find(Value *V) {
+    iterator I = ValueMap.find(V);
+    if (I != ValueMap.end()) return I;
+
+    if (GlobalValue *GV = dyn_cast<GlobalValue>(V)) {
+      // If this is a global, check to see if it is equivalenced to something
+      // in the map.
+      GlobalValue *Leader = getLeaderForGlobal(GV);
+      if (Leader != GV)
+        I = ValueMap.find((Value*)Leader);
+    }
+    return I;
+  }
+  const_iterator find(Value *V) const {
+    const_iterator I = ValueMap.find(V);
+    if (I != ValueMap.end()) return I;
+
+    if (GlobalValue *GV = dyn_cast<GlobalValue>(V)) {
+      // If this is a global, check to see if it is equivalenced to something
+      // in the map.
+      GlobalValue *Leader = getLeaderForGlobal(GV);
+      if (Leader != GV)
+        I = ValueMap.find((Value*)Leader);
+    }
+    return I;
+  }
+
+  /// getRawEntryRef - This method can be used by clients that are aware of the
+  /// global value equivalence class in effect.
+  DSNodeHandle &getRawEntryRef(Value *V) {
+    std::pair<iterator,bool> IP =
+      ValueMap.insert(std::make_pair(V, DSNodeHandle()));
+     if (IP.second)   // Inserted the new entry into the map.
+       if (GlobalValue *GV = dyn_cast<GlobalValue>(V))
+         GlobalSet.insert(GV);
+     return IP.first->second;
+  }
+
+  unsigned count(Value *V) const { return ValueMap.find(V) != ValueMap.end(); }
+
+  void erase(Value *V) { erase(ValueMap.find(V)); }
+
+  void eraseIfExists(Value *V) {
+    iterator I = find(V);
+    if (I != end()) erase(I);
+  }
 
   /// replaceScalar - When an instruction needs to be modified, this method can
   /// be used to update the scalar map to remove the old and insert the new.
@@ -64,14 +121,25 @@ public:
     erase(I);
   }
 
-  DSNodeHandle &operator[](Value *V) {
-    std::pair<iterator,bool> IP = 
-      ValueMap.insert(std::make_pair(V, DSNodeHandle()));
-    if (IP.second) {  // Inserted the new entry into the map.
-      if (GlobalValue *GV = dyn_cast<GlobalValue>(V))
-        GlobalSet.insert(GV);
+  /// copyScalarIfExists - If Old exists in the scalar map, make New point to
+  /// whatever Old did.
+  void copyScalarIfExists(Value *Old, Value *New) {
+    iterator I = find(Old);
+    if (I != end())
+      ValueMap.insert(std::make_pair(New, I->second));
   }
-    return IP.first->second;
+
+  /// operator[] - Return the DSNodeHandle for the specified value, creating a
+  /// new null handle if there is no entry yet.
+  DSNodeHandle &operator[](Value *V) {
+    iterator I = ValueMap.find(V);
+    if (I != ValueMap.end())
+      return I->second;   // Return value if already exists.
+
+    if (GlobalValue *GV = dyn_cast<GlobalValue>(V))
+      return AddGlobal(GV);
+
+    return ValueMap.insert(std::make_pair(V, DSNodeHandle())).first->second;
   }
 
   void erase(iterator I) {
@@ -86,28 +154,40 @@ public:
     GlobalSet.clear();
   }
 
+  /// spliceFrom - Copy all entries from RHS, then clear RHS.
+  ///
+  void spliceFrom(DSScalarMap &RHS);
+
   // Access to the global set: the set of all globals currently in the
   // scalar map.
   typedef GlobalSetTy::const_iterator global_iterator;
   global_iterator global_begin() const { return GlobalSet.begin(); }
   global_iterator global_end() const { return GlobalSet.end(); }
+  unsigned global_size() const { return GlobalSet.size(); }
+  unsigned global_count(GlobalValue *GV) const { return GlobalSet.count(GV); }
+private:
+  DSNodeHandle &AddGlobal(GlobalValue *GV);
 };
 
 
 //===----------------------------------------------------------------------===//
 /// DSGraph - The graph that represents a function.
 ///
-struct DSGraph {
+class DSGraph {
+public:
   // Public data-type declarations...
   typedef DSScalarMap ScalarMapTy;
   typedef hash_map<Function*, DSNodeHandle> ReturnNodesTy;
-  typedef hash_set<GlobalValue*> GlobalSetTy;
   typedef ilist<DSNode> NodeListTy;
 
   /// NodeMapTy - This data type is used when cloning one graph into another to
   /// keep track of the correspondence between the nodes in the old and new
   /// graphs.
   typedef hash_map<const DSNode*, DSNodeHandle> NodeMapTy;
+
+  // InvNodeMapTy - This data type is used to represent the inverse of a node
+  // map.
+  typedef hash_multimap<DSNodeHandle, const DSNode*> InvNodeMapTy;
 private:
   DSGraph *GlobalsGraph;   // Pointer to the common graph of global objects
   bool PrintAuxCalls;      // Should this graph print the Aux calls vector?
@@ -121,38 +201,34 @@ private:
   //
   ReturnNodesTy ReturnNodes;
 
-  // FunctionCalls - This vector maintains a single entry for each call
+  // FunctionCalls - This list maintains a single entry for each call
   // instruction in the current graph.  The first entry in the vector is the
   // scalar that holds the return value for the call, the second is the function
   // scalar being invoked, and the rest are pointer arguments to the function.
   // This vector is built by the Local graph and is never modified after that.
   //
-  std::vector<DSCallSite> FunctionCalls;
+  std::list<DSCallSite> FunctionCalls;
 
   // AuxFunctionCalls - This vector contains call sites that have been processed
   // by some mechanism.  In pratice, the BU Analysis uses this vector to hold
   // the _unresolved_ call sites, because it cannot modify FunctionCalls.
   //
-  std::vector<DSCallSite> AuxFunctionCalls;
-
-  // InlinedGlobals - This set records which globals have been inlined from
-  // other graphs (callers or callees, depending on the pass) into this one.
-  // 
-  GlobalSetTy InlinedGlobals;
+  std::list<DSCallSite> AuxFunctionCalls;
 
   /// TD - This is the target data object for the machine this graph is
   /// constructed for.
   const TargetData &TD;
 
   void operator=(const DSGraph &); // DO NOT IMPLEMENT
-
+  DSGraph(const DSGraph&);         // DO NOT IMPLEMENT
 public:
   // Create a new, empty, DSGraph.
-  DSGraph(const TargetData &td)
-    : GlobalsGraph(0), PrintAuxCalls(false), TD(td) {}
+  DSGraph(EquivalenceClasses<GlobalValue*> &ECs, const TargetData &td)
+    : GlobalsGraph(0), PrintAuxCalls(false), ScalarMap(ECs), TD(td) {}
 
   // Compute the local DSGraph
-  DSGraph(const TargetData &td, Function &F, DSGraph *GlobalsGraph);
+  DSGraph(EquivalenceClasses<GlobalValue*> &ECs, const TargetData &TD,
+          Function &F, DSGraph *GlobalsGraph);
 
   // Copy ctor - If you want to capture the node mapping between the source and
   // destination graph, you may optionally do this by specifying a map to record
@@ -162,13 +238,19 @@ public:
   // source.  You need to set a new GlobalsGraph with the setGlobalsGraph
   // method.
   //
-  DSGraph(const DSGraph &DSG);
-  DSGraph(const DSGraph &DSG, NodeMapTy &NodeMap);
+  DSGraph(const DSGraph &DSG, EquivalenceClasses<GlobalValue*> &ECs,
+          unsigned CloneFlags = 0);
   ~DSGraph();
 
   DSGraph *getGlobalsGraph() const { return GlobalsGraph; }
   void setGlobalsGraph(DSGraph *G) { GlobalsGraph = G; }
 
+  /// getGlobalECs - Return the set of equivalence classes that the global
+  /// variables in the program form.
+  EquivalenceClasses<GlobalValue*> &getGlobalECs() const {
+    return ScalarMap.getGlobalECs();
+  }
+
   /// getTargetData - Return the TargetData object for the current target.
   ///
   const TargetData &getTargetData() const { return TD; }
@@ -184,9 +266,13 @@ public:
   /// cause the node to be removed from this list.  This means that if you are
   /// iterating over nodes and doing something that could cause _any_ node to
   /// merge, your node_iterators into this graph can be invalidated.
-  typedef NodeListTy::compat_iterator node_iterator;
-  node_iterator node_begin() const { return Nodes.compat_begin(); }
-  node_iterator node_end()   const { return Nodes.compat_end(); }
+  typedef NodeListTy::iterator node_iterator;
+  node_iterator node_begin() { return Nodes.begin(); }
+  node_iterator node_end()   { return Nodes.end(); }
+
+  typedef NodeListTy::const_iterator node_const_iterator;
+  node_const_iterator node_begin() const { return Nodes.begin(); }
+  node_const_iterator node_end()   const { return Nodes.end(); }
 
   /// getFunctionNames - Return a space separated list of the name of the
   /// functions in this graph (if any)
@@ -207,26 +293,27 @@ public:
   /// getFunctionCalls - Return the list of call sites in the original local
   /// graph...
   ///
-  const std::vector<DSCallSite> &getFunctionCalls() const {
-    return FunctionCalls;
-  }
+  const std::list<DSCallSite> &getFunctionCalls() const { return FunctionCalls;}
+  std::list<DSCallSite> &getFunctionCalls() { return FunctionCalls;}
 
   /// getAuxFunctionCalls - Get the call sites as modified by whatever passes
   /// have been run.
   ///
-  std::vector<DSCallSite> &getAuxFunctionCalls() {
-    return AuxFunctionCalls;
-  }
-  const std::vector<DSCallSite> &getAuxFunctionCalls() const {
+  std::list<DSCallSite> &getAuxFunctionCalls() { return AuxFunctionCalls; }
+  const std::list<DSCallSite> &getAuxFunctionCalls() const {
     return AuxFunctionCalls;
   }
 
-  /// getInlinedGlobals - Get the set of globals that are have been inlined
-  /// (from callees in BU or from callers in TD) into the current graph.
-  ///
-  GlobalSetTy& getInlinedGlobals() {
-    return InlinedGlobals;
-  }
+  // Function Call iteration
+  typedef std::list<DSCallSite>::const_iterator fc_iterator;
+  fc_iterator fc_begin() const { return FunctionCalls.begin(); }
+  fc_iterator fc_end() const { return FunctionCalls.end(); }
+
+
+  // Aux Function Call iteration
+  typedef std::list<DSCallSite>::const_iterator afc_iterator;
+  afc_iterator afc_begin() const { return AuxFunctionCalls.begin(); }
+  afc_iterator afc_end() const { return AuxFunctionCalls.end(); }
 
   /// getNodeForValue - Given a value that is used or defined in the body of the
   /// current function, return the DSNode that it points to.
@@ -240,6 +327,13 @@ public:
     return I->second;
   }
 
+  /// retnodes_* iterator methods: expose iteration over return nodes in the
+  /// graph, which are also the set of functions incorporated in this graph.
+  typedef ReturnNodesTy::const_iterator retnodes_iterator;
+  retnodes_iterator retnodes_begin() const { return ReturnNodes.begin(); }
+  retnodes_iterator retnodes_end() const { return ReturnNodes.end(); }
+
+
   /// getReturnNodes - Return the mapping of functions to their return nodes for
   /// this graph.
   ///
@@ -260,12 +354,28 @@ public:
     return I->second;
   }
 
+  /// containsFunction - Return true if this DSGraph contains information for
+  /// the specified function.
+  bool containsFunction(Function *F) const {
+    return ReturnNodes.count(F);
+  }
+
   /// getGraphSize - Return the number of nodes in this graph.
   ///
   unsigned getGraphSize() const {
     return Nodes.size();
   }
 
+  /// addObjectToGraph - This method can be used to add global, stack, and heap
+  /// objects to the graph.  This can be used when updating DSGraphs due to the
+  /// introduction of new temporary objects.  The new object is not pointed to
+  /// and does not point to any other objects in the graph.  Note that this
+  /// method initializes the type of the DSNode to the declared type of the
+  /// object if UseDeclaredType is true, otherwise it leaves the node type as
+  /// void.
+  DSNode *addObjectToGraph(Value *Ptr, bool UseDeclaredType = true);
+
+
   /// print - Print a dot graph to the specified ostream...
   ///
   void print(std::ostream &O) const;
@@ -286,7 +396,7 @@ public:
   ///
   void maskNodeTypes(unsigned Mask) {
     for (node_iterator I = node_begin(), E = node_end(); I != E; ++I)
-      (*I)->maskNodeTypes(Mask);
+      I->maskNodeTypes(Mask);
   }
   void maskIncompleteMarkers() { maskNodeTypes(~DSNode::Incomplete); }
 
@@ -323,7 +433,6 @@ public:
     DontCloneAuxCallNodes = 1 << 2, CloneAuxCallNodes = 0,
     StripModRefBits       = 1 << 3, KeepModRefBits    = 0,
     StripIncompleteBit    = 1 << 4, KeepIncompleteBit = 0,
-    UpdateInlinedGlobals  = 1 << 5, DontUpdateInlinedGlobals = 0,
   };
 
   void updateFromGlobalGraph();
@@ -336,24 +445,51 @@ public:
                                  const DSNodeHandle &NH2, NodeMapTy &NodeMap,
                                  bool StrictChecking = true);
 
+  /// computeGToGGMapping - Compute the mapping of nodes in the graph to nodes
+  /// in the globals graph.
+  void computeGToGGMapping(NodeMapTy &NodeMap);
 
-  /// cloneInto - Clone the specified DSGraph into the current graph.  The
-  /// translated ScalarMap for the old function is filled into the OldValMap
-  /// member, and the translated ReturnNodes map is returned into ReturnNodes.
-  /// OldNodeMap contains a mapping from the original nodes to the newly cloned
-  /// nodes.
+  /// computeGGToGMapping - Compute the mapping of nodes in the global
+  /// graph to nodes in this graph.
+  void computeGGToGMapping(InvNodeMapTy &InvNodeMap);
+
+  /// computeCalleeCallerMapping - Given a call from a function in the current
+  /// graph to the 'Callee' function (which lives in 'CalleeGraph'), compute the
+  /// mapping of nodes from the callee to nodes in the caller.
+  void computeCalleeCallerMapping(DSCallSite CS, const Function &Callee,
+                                  DSGraph &CalleeGraph, NodeMapTy &NodeMap);
+
+  /// spliceFrom - Logically perform the operation of cloning the RHS graph into
+  /// this graph, then clearing the RHS graph.  Instead of performing this as
+  /// two seperate operations, do it as a single, much faster, one.
+  ///
+  void spliceFrom(DSGraph &RHS);
+
+  /// cloneInto - Clone the specified DSGraph into the current graph.
   ///
   /// The CloneFlags member controls various aspects of the cloning process.
   ///
-  void cloneInto(const DSGraph &G, ScalarMapTy &OldValMap,
-                 ReturnNodesTy &OldReturnNodes, NodeMapTy &OldNodeMap,
-                 unsigned CloneFlags = 0);
+  void cloneInto(const DSGraph &G, unsigned CloneFlags = 0);
 
-  /// mergeInGraph - The method is used for merging graphs together.  If the
-  /// argument graph is not *this, it makes a clone of the specified graph, then
-  /// merges the nodes specified in the call site with the formal arguments in
-  /// the graph.  If the StripAlloca's argument is 'StripAllocaBit' then Alloca
-  /// markers are removed from nodes.
+  /// getFunctionArgumentsForCall - Given a function that is currently in this
+  /// graph, return the DSNodeHandles that correspond to the pointer-compatible
+  /// function arguments.  The vector is filled in with the return value (or
+  /// null if it is not pointer compatible), followed by all of the
+  /// pointer-compatible arguments.
+  void getFunctionArgumentsForCall(Function *F,
+                                   std::vector<DSNodeHandle> &Args) const;
+
+  /// mergeInGraph - This graph merges in the minimal number of
+  /// nodes from G2 into 'this' graph, merging the bindings specified by the
+  /// call site (in this graph) with the bindings specified by the vector in G2.
+  /// If the StripAlloca's argument is 'StripAllocaBit' then Alloca markers are
+  /// removed from nodes.
+  ///
+  void mergeInGraph(const DSCallSite &CS, std::vector<DSNodeHandle> &Args,
+                    const DSGraph &G2, unsigned CloneFlags);
+
+  /// mergeInGraph - This method is the same as the above method, but the
+  /// argument bindings are provided by using the formal arguments of F.
   ///
   void mergeInGraph(const DSCallSite &CS, Function &F, const DSGraph &Graph,
                     unsigned CloneFlags);
@@ -372,10 +508,7 @@ public:
     assert((!N || N->getParentGraph() == this) &&
            "AssertNodeInGraph: Node is not in graph!");
   }
-  void AssertNodeContainsGlobal(const DSNode *N, GlobalValue *GV) const {
-    assert(std::find(N->getGlobals().begin(), N->getGlobals().end(), GV) !=
-           N->getGlobals().end() && "Global value not in node!");
-  }
+  void AssertNodeContainsGlobal(const DSNode *N, GlobalValue *GV) const;
 
   void AssertCallSiteInGraph(const DSCallSite &CS) const;
   void AssertCallNodesInGraph() const;
@@ -430,7 +563,7 @@ public:
   /// mergeCallSite - Merge the nodes reachable from the specified src call
   /// site into the nodes reachable from DestCS.
   ///
-  void mergeCallSite(const DSCallSite &DestCS, const DSCallSite &SrcCS);
+  void mergeCallSite(DSCallSite &DestCS, const DSCallSite &SrcCS);
 
   bool clonedAnyNodes() const { return !NodeMap.empty(); }
 

llvm/include/llvm/Analysis/DataStructure/DSGraphTraits.h

@@ -135,15 +135,13 @@ template <> struct GraphTraits<const DSGraph*> {
   typedef const DSNode NodeType;
   typedef DSNode::const_iterator ChildIteratorType;
 
-  typedef std::pointer_to_unary_function<const DSNode *,const DSNode&> DerefFun;
-
   // nodes_iterator/begin/end - Allow iteration over all nodes in the graph
-  typedef mapped_iterator<DSGraph::node_iterator, DerefFun> nodes_iterator;
+  typedef DSGraph::node_const_iterator nodes_iterator;
   static nodes_iterator nodes_begin(const DSGraph *G) {
-    return map_iterator(G->node_begin(), DerefFun(dereferenceC));
+    return G->node_begin();
   }
   static nodes_iterator nodes_end(const DSGraph *G) {
-    return map_iterator(G->node_end(), DerefFun(dereferenceC));
+    return G->node_end();
   }
 
   static ChildIteratorType child_begin(const NodeType *N) { return N->begin(); }

llvm/include/llvm/Analysis/DataStructure/DSNode.h

@@ -15,6 +15,7 @@
 #define LLVM_ANALYSIS_DSNODE_H
 
 #include "llvm/Analysis/DataStructure/DSSupport.h"
+#include "llvm/ADT/hash_map"
 
 namespace llvm {
 
@@ -212,6 +213,16 @@ public:
   ///
   unsigned getNumLinks() const { return Links.size(); }
 
+  /// edge_* - Provide iterators for accessing outgoing edges.  Some outgoing
+  /// edges may be null.
+  typedef std::vector<DSNodeHandle>::iterator edge_iterator;
+  typedef std::vector<DSNodeHandle>::const_iterator const_edge_iterator;
+  edge_iterator edge_begin() { return Links.begin(); }
+  edge_iterator edge_end() { return Links.end(); }
+  const_edge_iterator edge_begin() const { return Links.begin(); }
+  const_edge_iterator edge_end() const { return Links.end(); }
+
+
   /// mergeTypeInfo - This method merges the specified type into the current
   /// node at the specified offset.  This may update the current node's type
   /// record if this gives more information to the node, it may do nothing to
@@ -272,12 +283,35 @@ public:
   /// also marks the node with the 'G' flag if it does not already have it.
   ///
   void addGlobal(GlobalValue *GV);
-  void mergeGlobals(const std::vector<GlobalValue*> &RHS);
-  const std::vector<GlobalValue*> &getGlobals() const { return Globals; }
 
-  typedef std::vector<GlobalValue*>::const_iterator global_iterator;
-  global_iterator global_begin() const { return Globals.begin(); }
-  global_iterator global_end() const { return Globals.end(); }
+  /// removeGlobal - Remove the specified global that is explicitly in the
+  /// globals list.
+  void removeGlobal(GlobalValue *GV);
+
+  void mergeGlobals(const std::vector<GlobalValue*> &RHS);
+  void clearGlobals() { std::vector<GlobalValue*>().swap(Globals); }
+
+  /// getGlobalsList - Return the set of global leaders that are represented by
+  /// this node.  Note that globals that are in this equivalence class but are
+  /// not leaders are not returned: for that, use addFullGlobalsList().
+  const std::vector<GlobalValue*> &getGlobalsList() const { return Globals; }
+
+  /// addFullGlobalsList - Compute the full set of global values that are
+  /// represented by this node.  Unlike getGlobalsList(), this requires fair
+  /// amount of work to compute, so don't treat this method call as free.
+  void addFullGlobalsList(std::vector<GlobalValue*> &List) const;
+
+  /// addFullFunctionList - Identical to addFullGlobalsList, but only return the
+  /// functions in the full list.
+  void addFullFunctionList(std::vector<Function*> &List) const;
+
+  /// globals_iterator/begin/end - Provide iteration methods over the global
+  /// value leaders set that is merged into this node.  Like the getGlobalsList
+  /// method, these iterators do not return globals that are part of the
+  /// equivalence classes for globals in this node, but aren't leaders.
+  typedef std::vector<GlobalValue*>::const_iterator globals_iterator;
+  globals_iterator globals_begin() const { return Globals.begin(); }
+  globals_iterator globals_end() const { return Globals.end(); }
 
 
   /// maskNodeTypes - Apply a mask to the node types bitfield.
@@ -348,7 +382,7 @@ public:
   /// DSNodes, marking any nodes which are reachable.  All reachable nodes it
   /// adds to the set, which allows it to only traverse visited nodes once.
   ///
-  void markReachableNodes(hash_set<DSNode*> &ReachableNodes);
+  void markReachableNodes(hash_set<const DSNode*> &ReachableNodes) const;
 
 private:
   friend class DSNodeHandle;
@@ -368,7 +402,8 @@ struct ilist_traits<DSNode> {
   static void setPrev(DSNode *N, DSNode *Prev) { N->Prev = Prev; }
   static void setNext(DSNode *N, DSNode *Next) { N->Next = Next; }
 
-  static DSNode *createNode() { return new DSNode(0,0); }
+  static DSNode *createSentinel() { return new DSNode(0,0); }
+  static void destroySentinel(DSNode *N) { delete N; }
   //static DSNode *createNode(const DSNode &V) { return new DSNode(V); }
 
 

llvm/include/llvm/Analysis/DataStructure/DSSupport.h

@@ -15,6 +15,7 @@
 #define LLVM_ANALYSIS_DSSUPPORT_H
 
 #include <functional>
+#include "llvm/ADT/hash_map"
 #include "llvm/ADT/hash_set"
 #include "llvm/Support/CallSite.h"
 
@@ -145,6 +146,15 @@ namespace std {
   inline void swap<llvm::DSNodeHandle>(llvm::DSNodeHandle &NH1, llvm::DSNodeHandle &NH2) { NH1.swap(NH2); }
 }
 
+namespace HASH_NAMESPACE {
+  // Provide a hash function for arbitrary pointers...
+  template <> struct hash<llvm::DSNodeHandle> {
+    inline size_t operator()(const llvm::DSNodeHandle &Val) const {
+      return hash<void*>()(Val.getNode()) ^ Val.getOffset();
+    }
+  };
+}
+
 namespace llvm {
 
 //===----------------------------------------------------------------------===//
@@ -262,6 +272,10 @@ public:
     return CallArgs[i];
   }
 
+  void addPtrArg(const DSNodeHandle &NH) {
+    CallArgs.push_back(NH);
+  }
+
   void swap(DSCallSite &CS) {
     if (this != &CS) {
       std::swap(Site, CS.Site);
@@ -282,13 +296,16 @@ public:
 
     for (unsigned a = 0; a != MinArgs; ++a)
       getPtrArg(a).mergeWith(CS.getPtrArg(a));
+
+    for (unsigned a = MinArgs, e = CS.getNumPtrArgs(); a != e; ++a)
+      CallArgs.push_back(CS.getPtrArg(a));
   }
 
   /// markReachableNodes - This method recursively traverses the specified
   /// DSNodes, marking any nodes which are reachable.  All reachable nodes it
   /// adds to the set, which allows it to only traverse visited nodes once.
   ///
-  void markReachableNodes(hash_set<DSNode*> &Nodes);
+  void markReachableNodes(hash_set<const DSNode*> &Nodes) const;
 
   bool operator<(const DSCallSite &CS) const {
     if (isDirectCall()) {      // This must sort by callee first!

llvm/include/llvm/Analysis/DataStructure/DataStructure.h

@@ -16,14 +16,20 @@
 
 #include "llvm/Pass.h"
 #include "llvm/Target/TargetData.h"
+#include "llvm/ADT/hash_map"
 #include "llvm/ADT/hash_set"
+#include "llvm/ADT/EquivalenceClasses.h"
 
 namespace llvm {
 
 class Type;
 class Instruction;
+class GlobalValue;
+class CallSite;
 class DSGraph;
+class DSCallSite;
 class DSNode;
+class DSNodeHandle;
 
 // FIXME: move this stuff to a private header
 namespace DataStructureAnalysis {
@@ -44,6 +50,10 @@ class LocalDataStructures : public ModulePass {
   // DSInfo, one graph for each function
   hash_map<Function*, DSGraph*> DSInfo;
   DSGraph *GlobalsGraph;
+
+  /// GlobalECs - The equivalence classes for each global value that is merged
+  /// with other global values in the DSGraphs.
+  EquivalenceClasses<GlobalValue*> GlobalECs;
 public:
   ~LocalDataStructures() { releaseMemory(); }
 
@@ -64,6 +74,8 @@ public:
 
   DSGraph &getGlobalsGraph() const { return *GlobalsGraph; }
 
+  EquivalenceClasses<GlobalValue*> &getGlobalECs() { return GlobalECs; }
+
   /// print - Print out the analysis results...
   ///
   void print(std::ostream &O, const Module *M) const;
@@ -91,9 +103,17 @@ protected:
   // DSInfo, one graph for each function
   hash_map<Function*, DSGraph*> DSInfo;
   DSGraph *GlobalsGraph;
-  hash_multimap<Instruction*, Function*> ActualCallees;
+  std::set<std::pair<Instruction*, Function*> > ActualCallees;
+
+  // This map is only maintained during construction of BU Graphs
+  std::map<std::vector<Function*>,
+           std::pair<DSGraph*, std::vector<DSNodeHandle> > > *IndCallGraphMap;
+
+  /// GlobalECs - The equivalence classes for each global value that is merged
+  /// with other global values in the DSGraphs.
+  EquivalenceClasses<GlobalValue*> GlobalECs;
 public:
-  ~BUDataStructures() { releaseMemory(); }
+  ~BUDataStructures() { releaseMyMemory(); }
 
   virtual bool runOnModule(Module &M);
 
@@ -106,37 +126,54 @@ public:
   DSGraph &getDSGraph(const Function &F) const {
     hash_map<Function*, DSGraph*>::const_iterator I =
       DSInfo.find(const_cast<Function*>(&F));
-    assert(I != DSInfo.end() && "Function not in module!");
+    if (I != DSInfo.end())
       return *I->second;
+    return const_cast<BUDataStructures*>(this)->
+                   CreateGraphForExternalFunction(F);
   }
 
   DSGraph &getGlobalsGraph() const { return *GlobalsGraph; }
 
+  EquivalenceClasses<GlobalValue*> &getGlobalECs() { return GlobalECs; }
+
+  DSGraph &CreateGraphForExternalFunction(const Function &F);
+
+  /// deleteValue/copyValue - Interfaces to update the DSGraphs in the program.
+  /// These correspond to the interfaces defined in the AliasAnalysis class.
+  void deleteValue(Value *V);
+  void copyValue(Value *From, Value *To);
+
   /// print - Print out the analysis results...
   ///
   void print(std::ostream &O, const Module *M) const;
 
-  /// releaseMemory - if the pass pipeline is done with this pass, we can
-  /// release our memory...
-  ///
-  virtual void releaseMemory();
+  // FIXME: Once the pass manager is straightened out, rename this to
+  // releaseMemory.
+  void releaseMyMemory();
 
   virtual void getAnalysisUsage(AnalysisUsage &AU) const {
     AU.setPreservesAll();
     AU.addRequired<LocalDataStructures>();
   }
 
-  typedef hash_multimap<Instruction*, Function*> ActualCalleesTy;
+  typedef std::set<std::pair<Instruction*, Function*> > ActualCalleesTy;
   const ActualCalleesTy &getActualCallees() const {
     return ActualCallees;
   }
 
+  typedef ActualCalleesTy::const_iterator callee_iterator;
+  callee_iterator callee_begin(Instruction *I) const {
+    return ActualCallees.lower_bound(std::pair<Instruction*,Function*>(I, 0));
+  }
+
+  callee_iterator callee_end(Instruction *I) const {
+    I = (Instruction*)((char*)I + 1);
+    return ActualCallees.lower_bound(std::pair<Instruction*,Function*>(I, 0));
+  }
+
 private:
   void calculateGraph(DSGraph &G);
 
-  void calculateReachableGraphs(Function *F);
-
-
   DSGraph &getOrCreateGraph(Function *F);
 
   unsigned calculateGraphs(Function *F, std::vector<Function*> &Stack,
@@ -154,6 +191,38 @@ class TDDataStructures : public ModulePass {
   hash_map<Function*, DSGraph*> DSInfo;
   hash_set<Function*> ArgsRemainIncomplete;
   DSGraph *GlobalsGraph;
+  BUDataStructures *BUInfo;
+
+  /// GlobalECs - The equivalence classes for each global value that is merged
+  /// with other global values in the DSGraphs.
+  EquivalenceClasses<GlobalValue*> GlobalECs;
+
+  /// CallerCallEdges - For a particular graph, we keep a list of these records
+  /// which indicates which graphs call this function and from where.
+  struct CallerCallEdge {
+    DSGraph *CallerGraph;        // The graph of the caller function.
+    const DSCallSite *CS;        // The actual call site.
+    Function *CalledFunction;    // The actual function being called.
+
+    CallerCallEdge(DSGraph *G, const DSCallSite *cs, Function *CF)
+      : CallerGraph(G), CS(cs), CalledFunction(CF) {}
+
+    bool operator<(const CallerCallEdge &RHS) const {
+      return CallerGraph < RHS.CallerGraph ||
+            (CallerGraph == RHS.CallerGraph && CS < RHS.CS);
+    }
+  };
+
+  std::map<DSGraph*, std::vector<CallerCallEdge> > CallerEdges;
+
+
+  // IndCallMap - We memoize the results of indirect call inlining operations
+  // that have multiple targets here to avoid N*M inlining.  The key to the map
+  // is a sorted set of callee functions, the value is the DSGraph that holds
+  // all of the caller graphs merged together, and the DSCallSite to merge with
+  // the arguments for each function.
+  std::map<std::vector<Function*>, DSGraph*> IndCallMap;
+
 public:
   ~TDDataStructures() { releaseMyMemory(); }
 
@@ -168,11 +237,19 @@ public:
   DSGraph &getDSGraph(const Function &F) const {
     hash_map<Function*, DSGraph*>::const_iterator I =
       DSInfo.find(const_cast<Function*>(&F));
-    assert(I != DSInfo.end() && "Function not in module!");
-    return *I->second;
+    if (I != DSInfo.end()) return *I->second;
+    return const_cast<TDDataStructures*>(this)->
+        getOrCreateDSGraph(const_cast<Function&>(F));
   }
 
   DSGraph &getGlobalsGraph() const { return *GlobalsGraph; }
+  EquivalenceClasses<GlobalValue*> &getGlobalECs() { return GlobalECs; }
+
+
+  /// deleteValue/copyValue - Interfaces to update the DSGraphs in the program.
+  /// These correspond to the interfaces defined in the AliasAnalysis class.
+  void deleteValue(Value *V);
+  void copyValue(Value *From, Value *To);
 
   /// print - Print out the analysis results...
   ///
@@ -193,11 +270,10 @@ private:
   void markReachableFunctionsExternallyAccessible(DSNode *N,
                                                   hash_set<DSNode*> &Visited);
 
-  void inlineGraphIntoCallees(DSGraph &G);
+  void InlineCallersIntoGraph(DSGraph &G);
   DSGraph &getOrCreateDSGraph(Function &F);
   void ComputePostOrder(Function &F, hash_set<DSGraph*> &Visited,
-                        std::vector<DSGraph*> &PostOrder,
-                        const BUDataStructures::ActualCalleesTy &ActualCallees);
+                        std::vector<DSGraph*> &PostOrder);
 };
 
 
@@ -243,6 +319,110 @@ private:
   void processGraph(DSGraph &G);
 };
 
+
+/// EquivClassGraphs - This is the same as the complete bottom-up graphs, but
+/// with functions partitioned into equivalence classes and a single merged
+/// DS graph for all functions in an equivalence class.  After this merging,
+/// graphs are inlined bottom-up on the SCCs of the final (CBU) call graph.
+///
+struct EquivClassGraphs : public ModulePass {
+  CompleteBUDataStructures *CBU;
+
+  DSGraph *GlobalsGraph;
+
+  // DSInfo - one graph for each function.
+  hash_map<const Function*, DSGraph*> DSInfo;
+
+  /// ActualCallees - The actual functions callable from indirect call sites.
+  ///
+  std::set<std::pair<Instruction*, Function*> > ActualCallees;
+
+  // Equivalence class where functions that can potentially be called via the
+  // same function pointer are in the same class.
+  EquivalenceClasses<Function*> FuncECs;
+
+  /// OneCalledFunction - For each indirect call, we keep track of one
+  /// target of the call.  This is used to find equivalence class called by
+  /// a call site.
+  std::map<DSNode*, Function *> OneCalledFunction;
+
+  /// GlobalECs - The equivalence classes for each global value that is merged
+  /// with other global values in the DSGraphs.
+  EquivalenceClasses<GlobalValue*> GlobalECs;
+
+public:
+  /// EquivClassGraphs - Computes the equivalence classes and then the
+  /// folded DS graphs for each class.
+  ///
+  virtual bool runOnModule(Module &M);
+
+  /// print - Print out the analysis results...
+  ///
+  void print(std::ostream &O, const Module *M) const;
+
+  EquivalenceClasses<GlobalValue*> &getGlobalECs() { return GlobalECs; }
+
+  /// getDSGraph - Return the data structure graph for the specified function.
+  /// This returns the folded graph.  The folded graph is the same as the CBU
+  /// graph iff the function is in a singleton equivalence class AND all its
+  /// callees also have the same folded graph as the CBU graph.
+  ///
+  DSGraph &getDSGraph(const Function &F) const {
+    hash_map<const Function*, DSGraph*>::const_iterator I = DSInfo.find(&F);
+    assert(I != DSInfo.end() && "No graph computed for that function!");
+    return *I->second;
+  }
+
+  bool hasGraph(const Function &F) const {
+    return DSInfo.find(&F) != DSInfo.end();
+  }
+
+  /// ContainsDSGraphFor - Return true if we have a graph for the specified
+  /// function.
+  bool ContainsDSGraphFor(const Function &F) const {
+    return DSInfo.find(&F) != DSInfo.end();
+  }
+
+  /// getSomeCalleeForCallSite - Return any one callee function at
+  /// a call site.
+  ///
+  Function *getSomeCalleeForCallSite(const CallSite &CS) const;
+
+  DSGraph &getGlobalsGraph() const {
+    return *GlobalsGraph;
+  }
+
+  typedef std::set<std::pair<Instruction*, Function*> > ActualCalleesTy;
+  const ActualCalleesTy &getActualCallees() const {
+    return ActualCallees;
+  }
+
+  typedef ActualCalleesTy::const_iterator callee_iterator;
+  callee_iterator callee_begin(Instruction *I) const {
+    return ActualCallees.lower_bound(std::pair<Instruction*,Function*>(I, 0));
+  }
+
+  callee_iterator callee_end(Instruction *I) const {
+    I = (Instruction*)((char*)I + 1);
+    return ActualCallees.lower_bound(std::pair<Instruction*,Function*>(I, 0));
+  }
+
+  virtual void getAnalysisUsage(AnalysisUsage &AU) const {
+    AU.setPreservesAll();
+    AU.addRequired<CompleteBUDataStructures>();
+  }
+
+private:
+  void buildIndirectFunctionSets(Module &M);
+
+  unsigned processSCC(DSGraph &FG, std::vector<DSGraph*> &Stack,
+                      unsigned &NextID,
+                      std::map<DSGraph*, unsigned> &ValMap);
+  void processGraph(DSGraph &FG);
+
+  DSGraph &getOrCreateGraph(Function &F);
+};
+
 } // End llvm namespace
 
 #endif

llvm/include/llvm/Analysis/Dominators.h

@@ -114,7 +114,7 @@ public:
 
   /// print - Convert to human readable form
   ///
-  virtual void print(std::ostream &OS) const;
+  virtual void print(std::ostream &OS, const Module* = 0) const;
 };
 
 //===-------------------------------------
@@ -218,7 +218,7 @@ public:
 
   /// print - Convert to human readable form
   ///
-  virtual void print(std::ostream &OS) const;
+  virtual void print(std::ostream &OS, const Module* = 0) const;
 
   /// dominates - Return true if A dominates B.  This performs the special
   /// checks necessary if A and B are in the same basic block.
@@ -375,7 +375,7 @@ public:
 
   /// print - Convert to human readable form
   ///
-  virtual void print(std::ostream &OS) const;
+  virtual void print(std::ostream &OS, const Module* = 0) const;
 };
 
 
@@ -475,7 +475,7 @@ public:
 
   /// print - Convert to human readable form
   ///
-  virtual void print(std::ostream &OS) const;
+  virtual void print(std::ostream &OS, const Module* = 0) const;
 };
 
 

llvm/include/llvm/Analysis/FindUsedTypes.h

@@ -60,7 +60,7 @@ public:
 
 // Make sure that any clients of this file link in PostDominators.cpp
 static IncludeFile
-FIND_USED_TYPES_INCLUDE_FILE((void*)&FindUsedTypes::stub);
+FIND_USED_TYPES_INCLUDE_FILE((void*)(&FindUsedTypes::stub));
 
 } // End llvm namespace
 

llvm/include/llvm/Analysis/Interval.h

@@ -30,14 +30,14 @@ class BasicBlock;
 
 //===----------------------------------------------------------------------===//
 //
-// Interval Class - An Interval is a set of nodes defined such that every node
-// in the interval has all of its predecessors in the interval (except for the
-// header)
-//
+/// Interval Class - An Interval is a set of nodes defined such that every node
+/// in the interval has all of its predecessors in the interval (except for the
+/// header)
+///
 class Interval {
-  // HeaderNode - The header BasicBlock, which dominates all BasicBlocks in this
-  // interval.  Also, any loops in this interval must go through the HeaderNode.
-  //
+  /// HeaderNode - The header BasicBlock, which dominates all BasicBlocks in this
+  /// interval.  Also, any loops in this interval must go through the HeaderNode.
+  ///
   BasicBlock *HeaderNode;
 public:
   typedef std::vector<BasicBlock*>::iterator succ_iterator;
@@ -53,22 +53,22 @@ public:
 
   inline BasicBlock *getHeaderNode() const { return HeaderNode; }
 
-  // Nodes - The basic blocks in this interval.
-  //
+  /// Nodes - The basic blocks in this interval.
+  ///
   std::vector<BasicBlock*> Nodes;
 
-  // Successors - List of BasicBlocks that are reachable directly from nodes in
-  // this interval, but are not in the interval themselves.
-  // These nodes necessarily must be header nodes for other intervals.
-  //
+  /// Successors - List of BasicBlocks that are reachable directly from nodes in
+  /// this interval, but are not in the interval themselves.
+  /// These nodes necessarily must be header nodes for other intervals.
+  ///
   std::vector<BasicBlock*> Successors;
 
-  // Predecessors - List of BasicBlocks that have this Interval's header block
-  // as one of their successors.
-  //
+  /// Predecessors - List of BasicBlocks that have this Interval's header block
+  /// as one of their successors.
+  ///
   std::vector<BasicBlock*> Predecessors;
 
-  // contains - Find out if a basic block is in this interval
+  /// contains - Find out if a basic block is in this interval
   inline bool contains(BasicBlock *BB) const {
     for (unsigned i = 0; i < Nodes.size(); ++i)
       if (Nodes[i] == BB) return true;
@@ -77,7 +77,7 @@ public:
     //return find(Nodes.begin(), Nodes.end(), BB) != Nodes.end();
   }
 
-  // isSuccessor - find out if a basic block is a successor of this Interval
+  /// isSuccessor - find out if a basic block is a successor of this Interval
   inline bool isSuccessor(BasicBlock *BB) const {
     for (unsigned i = 0; i < Successors.size(); ++i)
       if (Successors[i] == BB) return true;
@@ -86,24 +86,24 @@ public:
     //return find(Successors.begin(), Successors.end(), BB) != Successors.end();
   }
 
-  // Equality operator.  It is only valid to compare two intervals from the same
-  // partition, because of this, all we have to check is the header node for 
-  // equality.
-  //
+  /// Equality operator.  It is only valid to compare two intervals from the
+  /// same partition, because of this, all we have to check is the header node
+  /// for equality.
+  ///
   inline bool operator==(const Interval &I) const {
     return HeaderNode == I.HeaderNode;
   }
 
-  // isLoop - Find out if there is a back edge in this interval...
+  /// isLoop - Find out if there is a back edge in this interval...
   bool isLoop() const;
 
-  // print - Show contents in human readable format...
+  /// print - Show contents in human readable format...
   void print(std::ostream &O) const;
 };
 
-// succ_begin/succ_end - define methods so that Intervals may be used
-// just like BasicBlocks can with the succ_* functions, and *::succ_iterator.
-//
+/// succ_begin/succ_end - define methods so that Intervals may be used
+/// just like BasicBlocks can with the succ_* functions, and *::succ_iterator.
+///
 inline Interval::succ_iterator succ_begin(Interval *I) {
   return I->Successors.begin();
 }
@@ -111,9 +111,9 @@ inline Interval::succ_iterator succ_end(Interval *I)   {
   return I->Successors.end();
 }
   
-// pred_begin/pred_end - define methods so that Intervals may be used
-// just like BasicBlocks can with the pred_* functions, and *::pred_iterator.
-//
+/// pred_begin/pred_end - define methods so that Intervals may be used
+/// just like BasicBlocks can with the pred_* functions, and *::pred_iterator.
+///
 inline Interval::pred_iterator pred_begin(Interval *I) {
   return I->Predecessors.begin();
 }
@@ -127,7 +127,7 @@ template <> struct GraphTraits<Interval*> {
 
   static NodeType *getEntryNode(Interval *I) { return I; }
 
-  // nodes_iterator/begin/end - Allow iteration over all nodes in the graph
+  /// nodes_iterator/begin/end - Allow iteration over all nodes in the graph
   static inline ChildIteratorType child_begin(NodeType *N) { 
     return succ_begin(N);
   }

llvm/include/llvm/Analysis/IntervalPartition.h

@@ -60,7 +60,7 @@ public:
   ~IntervalPartition() { destroy(); }
 
   // print - Show contents in human readable format...
-  virtual void print(std::ostream &O) const;
+  virtual void print(std::ostream &O, const Module* = 0) const;
 
   // getRootInterval() - Return the root interval that contains the starting
   // block of the function.

llvm/include/llvm/Analysis/LoopInfo.h

@@ -74,6 +74,7 @@ public:
 
   /// iterator/begin/end - Return the loops contained entirely within this loop.
   ///
+  const std::vector<Loop*> &getSubLoops() const { return SubLoops; }
   typedef std::vector<Loop*>::const_iterator iterator;
   iterator begin() const { return SubLoops.begin(); }
   iterator end() const { return SubLoops.end(); }
@@ -175,6 +176,21 @@ public:
     Blocks.push_back(BB);
   }
 
+  /// moveToHeader - This method is used to move BB (which must be part of this
+  /// loop) to be the loop header of the loop (the block that dominates all
+  /// others).
+  void moveToHeader(BasicBlock *BB) {
+    if (Blocks[0] == BB) return;
+    for (unsigned i = 0; ; ++i) {
+      assert(i != Blocks.size() && "Loop does not contain BB!");
+      if (Blocks[i] == BB) {
+        Blocks[i] = Blocks[0];
+        Blocks[0] = BB;
+        return;
+      }
+    }
+  }
+
   /// removeBlockFromLoop - This removes the specified basic block from the
   /// current loop, updating the Blocks as appropriate.  This does not update
   /// the mapping in the LoopInfo class.
@@ -214,7 +230,8 @@ public:
   /// block is in no loop (for example the entry node), null is returned.
   ///
   Loop *getLoopFor(const BasicBlock *BB) const {
-    std::map<BasicBlock *, Loop*>::const_iterator I=BBMap.find((BasicBlock*)BB);
+    std::map<BasicBlock *, Loop*>::const_iterator I=
+      BBMap.find(const_cast<BasicBlock*>(BB));
     return I != BBMap.end() ? I->second : 0;
   }
 
@@ -241,7 +258,7 @@ public:
   virtual bool runOnFunction(Function &F);
 
   virtual void releaseMemory();
-  void print(std::ostream &O) const;
+  void print(std::ostream &O, const Module* = 0) const;
 
   /// getAnalysisUsage - Requires dominator sets
   ///
@@ -284,7 +301,7 @@ private:
 
 // Make sure that any clients of this file link in LoopInfo.cpp
 static IncludeFile
-LOOP_INFO_INCLUDE_FILE((void*)&LoopInfo::stub);
+LOOP_INFO_INCLUDE_FILE((void*)(&LoopInfo::stub));
 
 // Allow clients to walk the list of nested loops...
 template <> struct GraphTraits<const Loop*> {

llvm/include/llvm/Analysis/Passes.h

@@ -16,14 +16,92 @@
 #define LLVM_ANALYSIS_PASSES_H
 
 namespace llvm {
+  class FunctionPass;
+  class ImmutablePass;
+  class ModulePass;
   class Pass;
 
   //===--------------------------------------------------------------------===//
   //
-  // createGlobalsModRefPass - This function creates and returns an instance of
-  // the GlobalsModRef alias analysis pass.
+  // createGlobalsModRefPass - This pass provides alias and mod/ref info for
+  // global values that do not have their addresses taken.
   //
   Pass *createGlobalsModRefPass();
+
+  //===--------------------------------------------------------------------===//
+  //
+  // createAliasAnalysisCounterPass - This pass counts alias queries and how the
+  // alias analysis implementation responds.
+  //
+  ModulePass *createAliasAnalysisCounterPass();
+
+  //===--------------------------------------------------------------------===//
+  //
+  // createAAEvalPass - This pass implements a simple N^2 alias analysis
+  // accuracy evaluator.
+  //
+  FunctionPass *createAAEvalPass();
+
+  //===--------------------------------------------------------------------===//
+  //
+  // createNoAAPass - This pass implements a "I don't know" alias analysis.
+  //
+  ImmutablePass *createNoAAPass();
+
+  //===--------------------------------------------------------------------===//
+  //
+  // createBasicAliasAnalysisPass - This pass implements the default alias
+  // analysis.
+  //
+  ImmutablePass *createBasicAliasAnalysisPass();
+
+  //===--------------------------------------------------------------------===//
+  //
+  // createAndersensPass - This pass implements Andersen's interprocedural alias
+  // analysis.
+  //
+  ModulePass *createAndersensPass();
+
+  //===--------------------------------------------------------------------===//
+  //
+  // createBasicVNPass - This pass walks SSA def-use chains to trivially
+  // identify lexically identical expressions.
+  //
+  ImmutablePass *createBasicVNPass();
+
+  //===--------------------------------------------------------------------===//
+  //
+  // createProfileLoaderPass - This pass loads information from a profile dump
+  // file.
+  //
+  ModulePass *createProfileLoaderPass();
+
+  //===--------------------------------------------------------------------===//
+  //
+  // createNoProfileInfoPass - This pass implements the default "no profile".
+  //
+  ImmutablePass *createNoProfileInfoPass();
+
+  //===--------------------------------------------------------------------===//
+  //
+  // createDSAAPass - This pass implements simple context sensitive alias
+  // analysis.
+  //
+  ModulePass *createDSAAPass();
+
+  //===--------------------------------------------------------------------===//
+  //
+  // createDSOptPass - This pass uses DSA to do a series of simple
+  // optimizations.
+  //
+  ModulePass *createDSOptPass();
+
+  //===--------------------------------------------------------------------===//
+  //
+  // createSteensgaardPass - This pass uses the data structure graphs to do a
+  // simple context insensitive alias analysis.
+  //
+  ModulePass *createSteensgaardPass();
 }
 
 #endif

llvm/include/llvm/Analysis/ScalarEvolution.h

@@ -38,11 +38,11 @@ namespace llvm {
   ///
   class SCEV {
     const unsigned SCEVType;      // The SCEV baseclass this node corresponds to
-    unsigned RefCount;
+    mutable unsigned RefCount;
 
     friend class SCEVHandle;
-    void addRef() { ++RefCount; }
-    void dropRef() {
+    void addRef() const { ++RefCount; }
+    void dropRef() const {
       if (--RefCount == 0)
         delete this;
     }
@@ -54,6 +54,16 @@ namespace llvm {
   public:
     SCEV(unsigned SCEVTy) : SCEVType(SCEVTy), RefCount(0) {}
 
+    /// getNegativeSCEV - Return the SCEV object corresponding to -V.
+    ///
+    static SCEVHandle getNegativeSCEV(const SCEVHandle &V);
+
+    /// getMinusSCEV - Return LHS-RHS.
+    ///
+    static SCEVHandle getMinusSCEV(const SCEVHandle &LHS,
+                                   const SCEVHandle &RHS);
+
+
     unsigned getSCEVType() const { return SCEVType; }
 
     /// getValueRange - Return the tightest constant bounds that this value is
@@ -74,6 +84,15 @@ namespace llvm {
     ///
     virtual const Type *getType() const = 0;
 
+    /// replaceSymbolicValuesWithConcrete - If this SCEV internally references
+    /// the symbolic value "Sym", construct and return a new SCEV that produces
+    /// the same value, but which uses the concrete value Conc instead of the
+    /// symbolic value.  If this SCEV does not use the symbolic value, it
+    /// returns itself.
+    virtual SCEVHandle
+    replaceSymbolicValuesWithConcrete(const SCEVHandle &Sym,
+                                      const SCEVHandle &Conc) const = 0;
+
     /// print - Print out the internal representation of this scalar to the
     /// specified stream.  This should really only be used for debugging
     /// purposes.
@@ -102,7 +121,9 @@ namespace llvm {
     virtual const Type *getType() const;
     virtual bool hasComputableLoopEvolution(const Loop *L) const;
     virtual void print(std::ostream &OS) const;
-
+    virtual SCEVHandle
+    replaceSymbolicValuesWithConcrete(const SCEVHandle &Sym,
+                                      const SCEVHandle &Conc) const;
 
     /// Methods for support type inquiry through isa, cast, and dyn_cast:
     static inline bool classof(const SCEVCouldNotCompute *S) { return true; }
@@ -115,7 +136,7 @@ namespace llvm {
     SCEV *S;
     SCEVHandle();  // DO NOT IMPLEMENT
   public:
-    SCEVHandle(SCEV *s) : S(s) {
+    SCEVHandle(const SCEV *s) : S(const_cast<SCEV*>(s)) {
       assert(S && "Cannot create a handle to a null SCEV!");
       S->addRef();
     }
@@ -202,7 +223,7 @@ namespace llvm {
     virtual bool runOnFunction(Function &F);
     virtual void releaseMemory();
     virtual void getAnalysisUsage(AnalysisUsage &AU) const;
-    virtual void print(std::ostream &OS) const;
+    virtual void print(std::ostream &OS, const Module* = 0) const;
   };
 }
 

llvm/include/llvm/Analysis/ScalarEvolutionExpressions.h

@@ -56,6 +56,11 @@ namespace llvm {
 
     virtual const Type *getType() const;
 
+    SCEVHandle replaceSymbolicValuesWithConcrete(const SCEVHandle &Sym,
+                                                 const SCEVHandle &Conc) const {
+      return this;
+    }
+
     virtual void print(std::ostream &OS) const;
 
     /// Methods for support type inquiry through isa, cast, and dyn_cast:
@@ -90,6 +95,14 @@ namespace llvm {
       return Op->hasComputableLoopEvolution(L);
     }
 
+    SCEVHandle replaceSymbolicValuesWithConcrete(const SCEVHandle &Sym,
+                                                 const SCEVHandle &Conc) const {
+      SCEVHandle H = Op->replaceSymbolicValuesWithConcrete(Sym, Conc);
+      if (H == Op)
+        return this;
+      return get(H, Ty);
+    }
+
     /// getValueRange - Return the tightest constant bounds that this value is
     /// known to have.  This method is only valid on integer SCEV objects.
     virtual ConstantRange getValueRange() const;
@@ -132,6 +145,14 @@ namespace llvm {
     /// known to have.  This method is only valid on integer SCEV objects.
     virtual ConstantRange getValueRange() const;
 
+    SCEVHandle replaceSymbolicValuesWithConcrete(const SCEVHandle &Sym,
+                                                 const SCEVHandle &Conc) const {
+      SCEVHandle H = Op->replaceSymbolicValuesWithConcrete(Sym, Conc);
+      if (H == Op)
+        return this;
+      return get(H, Ty);
+    }
+
     virtual void print(std::ostream &OS) const;
 
     /// Methods for support type inquiry through isa, cast, and dyn_cast:
@@ -176,12 +197,23 @@ namespace llvm {
       return true;
     }
 
+    // hasComputableLoopEvolution - Commutative expressions have computable loop
+    // evolutions iff they have at least one operand that varies with the loop,
+    // but that all varying operands are computable.
     virtual bool hasComputableLoopEvolution(const Loop *L) const {
+      bool HasVarying = false;
       for (unsigned i = 0, e = getNumOperands(); i != e; ++i)
-        if (getOperand(i)->hasComputableLoopEvolution(L)) return true;
+        if (!getOperand(i)->isLoopInvariant(L))
+          if (getOperand(i)->hasComputableLoopEvolution(L))
+            HasVarying = true;
+          else
             return false;
+      return HasVarying;
     }
 
+    SCEVHandle replaceSymbolicValuesWithConcrete(const SCEVHandle &Sym,
+                                                 const SCEVHandle &Conc) const;
+
     virtual const char *getOperationStr() const = 0;
 
     virtual const Type *getType() const { return getOperand(0)->getType(); }
@@ -286,6 +318,17 @@ namespace llvm {
              RHS->hasComputableLoopEvolution(L);
     }
 
+    SCEVHandle replaceSymbolicValuesWithConcrete(const SCEVHandle &Sym,
+                                                 const SCEVHandle &Conc) const {
+      SCEVHandle L = LHS->replaceSymbolicValuesWithConcrete(Sym, Conc);
+      SCEVHandle R = RHS->replaceSymbolicValuesWithConcrete(Sym, Conc);
+      if (L == LHS && R == RHS)
+        return this;
+      else
+        return get(L, R);
+    }
+
+
     virtual const Type *getType() const;
 
     void print(std::ostream &OS) const;
@@ -347,8 +390,6 @@ namespace llvm {
 
     virtual bool hasComputableLoopEvolution(const Loop *QL) const {
       if (L == QL) return true;
-      /// FIXME: What if the start or step value a recurrence for the specified
-      /// loop?
       return false;
     }
 
@@ -383,6 +424,8 @@ namespace llvm {
     /// returned.
     SCEVHandle getNumIterationsInRange(ConstantRange Range) const;
 
+    SCEVHandle replaceSymbolicValuesWithConcrete(const SCEVHandle &Sym,
+                                                 const SCEVHandle &Conc) const;
 
     virtual void print(std::ostream &OS) const;
 
@@ -420,6 +463,12 @@ namespace llvm {
       return false; // not computable
     }
 
+    SCEVHandle replaceSymbolicValuesWithConcrete(const SCEVHandle &Sym,
+                                                 const SCEVHandle &Conc) const {
+      if (&*Sym == this) return Conc;
+      return this;
+    }
+
     virtual const Type *getType() const;
 
     virtual void print(std::ostream &OS) const;

llvm/include/llvm/Argument.h

@@ -39,9 +39,6 @@ public:
   ///
   Argument(const Type *Ty, const std::string &Name = "", Function *F = 0);
 
-  /// setName - Specialize setName to handle symbol table majik...
-  virtual void setName(const std::string &name, SymbolTable *ST = 0);
-
   inline const Function *getParent() const { return Parent; }
   inline       Function *getParent()       { return Parent; }
 

llvm/include/llvm/Assembly/AsmAnnotationWriter.h

@@ -27,6 +27,8 @@ class Instruction;
 
 struct AssemblyAnnotationWriter {
 
+  virtual ~AssemblyAnnotationWriter();
+
   // emitFunctionAnnot - This may be implemented to emit a string right before
   // the start of a function.
   virtual void emitFunctionAnnot(const Function *F, std::ostream &OS) {}

llvm/include/llvm/Assembly/Parser.h

@@ -36,7 +36,8 @@ Module *ParseAssemblyFile(const std::string &Filename);// throw (ParseException)
 // ParseException - For when an exceptional event is generated by the parser.
 // This class lets you print out the exception message
 //
-struct ParseException {
+class ParseException {
+public:
   ParseException(const std::string &filename, const std::string &message,
                  int LineNo = -1, int ColNo = -1);
 

llvm/include/llvm/BasicBlock.h

@@ -40,8 +40,9 @@ template <class Ptr, class USE_iterator> class PredIterator;
 
 template<> struct ilist_traits<Instruction>
   : public SymbolTableListTraits<Instruction, BasicBlock, Function> {
-  // createNode is used to create a node that marks the end of the list...
-  static Instruction *createNode();
+  // createSentinel is used to create a node that marks the end of the list...
+  static Instruction *createSentinel();
+  static void destroySentinel(Instruction *I) { delete I; }
   static iplist<Instruction> &getList(BasicBlock *BB);
 };
 
@@ -64,8 +65,6 @@ public:
   /// Instruction iterators...
   typedef InstListType::iterator                              iterator;
   typedef InstListType::const_iterator                  const_iterator;
-  typedef std::reverse_iterator<const_iterator> const_reverse_iterator;
-  typedef std::reverse_iterator<iterator>             reverse_iterator;
 
   /// BasicBlock ctor - If the function parameter is specified, the basic block
   /// is automatically inserted at either the end of the function (if
@@ -75,9 +74,6 @@ public:
              BasicBlock *InsertBefore = 0);
   ~BasicBlock();
 
-  // Specialize setName to take care of symbol table majik
-  virtual void setName(const std::string &name, SymbolTable *ST = 0);
-
   /// getParent - Return the enclosing method, or null if none
   ///
   const Function *getParent() const { return InstList.getParent(); }
@@ -106,7 +102,12 @@ public:
   ///
   void eraseFromParent();
 
-
+  /// getSinglePredecessor - If this basic block has a single predecessor block,
+  /// return the block, otherwise return a null pointer.
+  BasicBlock *getSinglePredecessor();
+  const BasicBlock *getSinglePredecessor() const {
+    return const_cast<BasicBlock*>(this)->getSinglePredecessor();
+  }
 
   //===--------------------------------------------------------------------===//
   /// Instruction iterator methods
@@ -116,11 +117,6 @@ public:
   inline iterator                end  ()       { return InstList.end();   }
   inline const_iterator          end  () const { return InstList.end();   }
 
-  inline reverse_iterator       rbegin()       { return InstList.rbegin(); }
-  inline const_reverse_iterator rbegin() const { return InstList.rbegin(); }
-  inline reverse_iterator       rend  ()       { return InstList.rend();   }
-  inline const_reverse_iterator rend  () const { return InstList.rend();   }
-
   inline size_t                   size() const { return InstList.size();  }
   inline bool                    empty() const { return InstList.empty(); }
   inline const Instruction      &front() const { return InstList.front(); }
@@ -159,14 +155,14 @@ public:
   /// update the PHI nodes that reside in the block.  Note that this should be
   /// called while the predecessor still refers to this block.
   ///
-  void removePredecessor(BasicBlock *Pred);
+  void removePredecessor(BasicBlock *Pred, bool DontDeleteUselessPHIs = false);
 
   /// splitBasicBlock - This splits a basic block into two at the specified
   /// instruction.  Note that all instructions BEFORE the specified iterator
   /// stay as part of the original basic block, an unconditional branch is added
-  /// to the new BB, and the rest of the instructions in the BB are moved to the
-  /// new BB, including the old terminator.  The newly formed BasicBlock is
-  /// returned.  This function invalidates the specified iterator.
+  /// to the original BB, and the rest of the instructions in the BB are moved 
+  /// to the new BB, including the old terminator.  The newly formed BasicBlock
+  /// is returned.  This function invalidates the specified iterator.
   ///
   /// Note that this only works on well formed basic blocks (must have a
   /// terminator), and 'I' must not be the end of instruction list (which would

llvm/include/llvm/Bytecode/Analyzer.h

@@ -22,6 +22,7 @@
 #include "llvm/Bytecode/Format.h"
 #include <string>
 #include <map>
+#include <iostream>
 
 namespace llvm {
 

llvm/include/llvm/Bytecode/Archive.h

@@ -306,7 +306,10 @@ class Archive {
     /// you intend to modify the archive or traverse its contents (e.g. for
     /// printing).
     /// @brief Open and load an archive file
-    static Archive* OpenAndLoad(const sys::Path& filePath);
+    static Archive* OpenAndLoad(
+      const sys::Path& filePath,    ///< The file path to open and load
+      std::string* ErrorMessage = 0 ///< An optional error string
+    );
 
     /// This method opens an existing archive file from \p Filename and reads in
     /// its symbol table without reading in any of the archive's members. This
@@ -325,7 +328,8 @@ class Archive {
     /// @returns an Archive* that represents the archive file.
     /// @brief Open an existing archive and load its symbols.
     static Archive* OpenAndLoadSymbols(
-      const sys::Path& Filename ///< Name of the archive file to open
+      const sys::Path& Filename,   ///< Name of the archive file to open
+      std::string* ErrorMessage=0  ///< An optional error string
     );
 
     /// This destructor cleans up the Archive object, releases all memory, and
@@ -411,6 +415,15 @@ class Archive {
       std::set<ModuleProvider*>& modules  ///< The modules matching \p symbols
     );
 
+    /// This method determines whether the archive is a properly formed llvm
+    /// bytecode archive.  It first makes sure the symbol table has been loaded
+    /// and has a non-zero size.  If it does, then it is an archive.  If not,
+    /// then it tries to load all the bytecode modules of the archive.  Finally,
+    /// it returns whether it was successfull.
+    /// @returns true if the archive is a proper llvm bytecode archive
+    /// @brief Determine whether the archive is a proper llvm bytecode archive.
+    bool isBytecodeArchive();
+
   /// @}
   /// @name Mutators
   /// @{

llvm/include/llvm/Bytecode/BytecodeHandler.h

@@ -321,5 +321,4 @@ public:
 };
 
 }
-// vim: sw=2 ai
 #endif

llvm/include/llvm/CallingConv.h

@@ -0,0 +1,54 @@
+//===-- llvm/CallingConv.h - LLVM Calling Conventions -----------*- C++ -*-===//
+//
+//                     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.
+//
+//===----------------------------------------------------------------------===//
+//
+// This file defines a set of enums which specify the assigned numeric values
+// for known llvm calling conventions.
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef LLVM_CALLINGCONV_H
+#define LLVM_CALLINGCONV_H
+
+namespace llvm {
+
+/// CallingConv Namespace - This namespace contains an enum with a value for
+/// the well-known calling conventions.
+///
+namespace CallingConv {
+  enum ID {
+    // C - The default llvm calling convention, compatible with C.  This
+    // convention is the only calling convention that supports varargs calls.
+    // As with typical C calling conventions, the callee/caller have to tolerate
+    // certain amounts of prototype mismatch.
+    C = 0,
+
+
+    // Generic LLVM calling conventions.  None of these calling conventions
+    // support varargs calls, and all assume that the caller and callee
+    // prototype exactly match.
+
+    // Fast - This calling convention attempts to make calls as fast as possible
+    // (e.g. by passing things in registers).
+    Fast = 8,
+
+    // Cold - This calling convention attempts to make code in the caller as
+    // efficient as possible under the assumption that the call is not commonly
+    // executed.  As such, these calls often preserve all registers so that the
+    // call does not break any live ranges in the caller side.
+    Cold = 9,
+
+    // Target - This is the start of the target-specific calling conventions,
+    // e.g. fastcall and thiscall on X86.
+    FirstTargetCC = 64,
+  };
+} // End CallingConv namespace
+
+} // End llvm namespace
+
+#endif