Added Stacker Reid Spencer's contributions.

llvm-svn: 10498

llvm/CREDITS.TXT

@@ -12,10 +12,6 @@ E: vadve@cs.uiuc.edu
 W: http://www.cs.uiuc.edu/~vadve/
 D: The Sparc64 backend, provider of much wisdom, and motivator for LLVM
 
-N: Nate Begeman
-E: natebegeman@mac.com
-D: Portions of the PowerPC backend
-
 N: Tanya Brethour
 E: tonic@nondot.org
 W: http://nondot.org/~tonic/
@@ -24,8 +20,7 @@ D: The llvm-ar tool
 N: Misha Brukman
 E: brukman+llvm@uiuc.edu
 W: http://misha.brukman.net
-D: Portions of X86 and Sparc JIT compilers, PowerPC backend
-D: Incremental bytecode loader
+D: Portions of X86 and Sparc JIT compilers, incremental bytecode loader
 
 N: Cameron Buschardt
 E: buschard@uiuc.edu
@@ -42,26 +37,14 @@ D: Autoconf support, QMTest database, documentation improvements
 N: Brian Gaeke
 E: gaeke@uiuc.edu
 W: http://www.students.uiuc.edu/~gaeke/
-D: Portions of X86 static and JIT compilers. 
-D: Dynamic trace optimizer 
+D: Portions of X86 static and JIT compilers, reoptimizer framework cleanups
 D: FreeBSD/X86 compatibility fixes, the llvm-nm tool
 
-N: Louis Gerbarg
-D: Portions of the PowerPC backend
-
 N: Chris Lattner
 E: sabre@nondot.org
 W: http://nondot.org/~sabre/
 D: Primary architect of LLVM
 
-N: Vladimir Merzliakov
-E: wanderer@rsu.ru
-D: Test suite fixes for FreeBSD.
-
-N: Vladimir Prus
-E: ghost@cs.msu.su
-D: Made inst_iterator behave like a proper iterator, LowerConstantExprs pass
-
 N: Ruchira Sasanka
 E: sasanka@uiuc.edu
 D: Graph coloring register allocator for the Sparc64 backend
@@ -73,8 +56,7 @@ D: The `paths' pass
 N: Reid Spencer
 E: rspencer@x10sys.com
 W: http://extprosys.sourceforge.net/
-D: 'llvm' namespacification, Stacker FE, VMCore cleanup (SymbolTable, 
-D: Value != Type, CPR removal, bytecode improvements, llvmcs).
+D: Complete 'llvm' namespacification, Stacker, bug fixes, and improvements
 
 N: Bill Wendling
 E: wendling@isanbard.org

llvm/LICENSE.TXT

@@ -4,8 +4,8 @@ LLVM Release License
 University of Illinois/NCSA
 Open Source License
 
-Copyright (c) 2003, 2004 University of Illinois at Urbana-Champaign.
-All rights reserved.
+Copyright (c) 2003, University of Illinois at Urbana-Champaign.  All rights
+reserved.
 
 Developed by:
 
@@ -49,53 +49,3 @@ The LLVM software contains code written by third parties.  Such software will
 have its own individual LICENSE.TXT file in the directory in which it appears.
 This file will describe the copyrights, license, and restrictions which apply
 to that code.
-
-The disclaimer of warranty in the University of Illinois Open Source License
-applies to all code in the LLVM Distribution, and nothing in any of the
-other licenses gives permission to use the names of the LLVM Team or the
-University of Illinois to endorse or promote products derived from this
-Software.
-
-The following pieces of software have additional or alternate copyrights,
-licenses, and/or restrictions:
-
-Program             Directory
--------             ---------
-PowerPC Backend     llvm/lib/Target/PowerPC
-Autoconf:           llvm/autoconf
-                    llvm/projects/ModuleMaker/autoconf
-                    llvm/projects/sample/autoconf
-Burg:               llvm/utils/Burg
-                    llvm/test/Programs/MultiSource/Applications/Burg
-Aha:                llvm/test/Programs/MultiSource/Applications/aha
-SGEFA:              llvm/test/Programs/MultiSource/Applications/sgefa
-SIOD:               llvm/test/Programs/MultiSource/Applications/siod
-Spiff:              llvm/test/Programs/MultiSource/Applications/spiff
-D:                  llvm/test/Programs/MultiSource/Applications/d
-Lambda:             llvm/test/Programs/MultiSource/Applications/lambda-0.1.3
-hbd:                llvm/test/Programs/MultiSource/Applications/hbd
-treecc:             llvm/test/Programs/MultiSource/Applications/treecc
-kimwitu++:          llvm/test/Programs/MultiSource/Applications/kimwitu++
-obsequi:            llvm/test/Programs/MultiSource/Applications/obsequi
-Fhourstones:        llvm/test/Programs/MultiSource/Benchmarks/Fhourstones
-McCat:              llvm/test/Programs/MultiSource/Benchmarks/McCat
-Olden:              llvm/test/Programs/MultiSource/Benchmarks/Olden
-OptimizerEval:      llvm/test/Programs/MultiSource/Benchmarks/OptimizerEval
-Ptrdist:            llvm/test/Programs/MultiSource/Benchmarks/Ptrdist
-LLUBenchmark:       llvm/test/Programs/MultiSource/Benchmarks/llubenchmark
-SIM:                llvm/test/Programs/MultiSource/Benchmarks/sim
-cfrac:              llvm/test/Programs/MultiSource/Benchmarks/MallocBench/cfrac
-espresso:           llvm/test/Programs/MultiSource/Benchmarks/MallocBench/espresso
-gs:                 llvm/test/Programs/MultiSource/Benchmarks/MallocBench/gs
-p2c:                llvm/test/Programs/MultiSource/Benchmarks/MallocBench/p2c
-gawk:               llvm/test/Programs/MultiSource/Benchmarks/MallocBench/gawk
-make:               llvm/test/Programs/MultiSource/Benchmarks/MallocBench/make
-perl:               llvm/test/Programs/MultiSource/Benchmarks/MallocBench/perl
-Dhrystone:          llvm/test/Programs/SingleSource/Benchmarks/Dhrystone
-SingleSource Tests: llvm/test/Programs/SingleSource/Benchmarks/Misc
-                    llvm/test/Programs/SingleSource/CustomChecked
-                    llvm/test/Programs/SingleSource/Gizmos
-GNU Libc:           llvm/runtime/GCCLibraries/libc
-Zlib Library:       llvm/runtime/zlib
-PNG Library:        llvm/runtime/libpng
-

llvm/Makefile

@@ -1,18 +1,14 @@
-#===- ./Makefile -------------------------------------------*- Makefile -*--===#
+##===- ./Makefile ------------------------------------------*- Makefile -*-===##
 # 
 #                     The LLVM Compiler Infrastructure
 #
 # This file was developed by the LLVM research group and is distributed under
 # the University of Illinois Open Source License. See LICENSE.TXT for details.
 # 
-#===------------------------------------------------------------------------===#
+##===----------------------------------------------------------------------===##
 LEVEL = .
-DIRS = lib/Support utils lib tools 
-
-ifneq ($(MAKECMDGOALS),tools-only)
-DIRS += runtime
+DIRS = lib/Support utils lib tools runtime
 OPTIONAL_DIRS = projects
-endif
 
 include $(LEVEL)/Makefile.common
 
@@ -26,27 +22,25 @@ distclean:: clean
 	                  $(LEVEL)/config.log \
 	                  $(LEVEL)/TAGS
 
-tools-only: all
+tools-only:
+	@for dir in lib/Support utils lib tools; do $(MAKE) -C $$dir; done
+
+AUTOCONF = autoconf
+AUTOHEADER = autoheader
+
+configure: autoconf/configure.ac autoconf/aclocal.m4
+	cd autoconf && $(AUTOCONF) -o ../configure configure.ac
+
+include/Config/config.h.in: autoconf/configure.ac autoconf/aclocal.m4
+	$(AUTOHEADER) -I autoconf autoconf/configure.ac
+
+# Install support for llvm include files.
 
-# Install support for llvm include files:
 .PHONY: install-includes
 
 install-includes:
-	$(MKDIR) $(DESTDIR)$(includedir)/llvm
-	cd include && find * -path '*/Internal' -prune -o '(' '!' '(' -name '*~' -o -name .cvsignore ')' -print ')' | grep -v CVS | pax -rwdvpe $(DESTDIR)$(includedir)/llvm
-ifneq ($(BUILD_SRC_ROOT),$(BUILD_OBJ_ROOT))
-	cd $(BUILD_SRC_ROOT)/include && find * -path '*/Internal' -prune -o '(' '!' '(' -name '*~' -o -name .cvsignore ')' -print ')' | grep -v CVS | pax -rwdvpe $(DESTDIR)$(includedir)/llvm
-endif
+	$(MKDIR) $(includedir)/llvm
+	cd include && find * '!' '(' -name '*~' -o -name .cvsignore ')' -print | grep -v CVS | pax -rwdvpe $(includedir)/llvm
 
 install:: install-includes
 
-# Build tags database for Emacs/Xemacs:
-.PHONY: tags
-
-TAGS: tags
-
-all::
-
-tags:
-	find $(wildcard $(SourceDir)/include $(SourceDir)/lib $(SourceDir)/tools) -name '*.cpp' -o -name '*.h' | $(ETAGS) $(ETAGSFLAGS) -
-

llvm/Makefile.common

@@ -1,11 +1,11 @@
-#===-- Makefile.common - Common make rules for LLVM --------*- Makefile -*--===#
+#===-- Makefile.common - Common make rules for LLVM -------*- makefile -*--====
 # 
 #                     The LLVM Compiler Infrastructure
 #
 # This file was developed by the LLVM research group and is distributed under
 # the University of Illinois Open Source License. See LICENSE.TXT for details.
 # 
-#===------------------------------------------------------------------------===#
+##===----------------------------------------------------------------------===##
 #
 # This file is included by all of the LLVM makefiles.  This file defines common
 # rules to do things like compile a .cpp file or generate dependency info.

llvm/Makefile.config.in

@@ -1,84 +1,103 @@
-#===-- Makefile.config - Local configuration for LLVM ------*- Makefile -*--===#
-#
-#                     The LLVM Compiler Infrastructure
-#
-# This file was developed by the LLVM research group and is distributed under
-# the University of Illinois Open Source License. See LICENSE.TXT for details.
-# 
-#===------------------------------------------------------------------------===#
+#===-- Makefile.config - Local configuration for LLVM ------*- makefile -*--====
 #
 # This file is included by Makefile.common.  It defines paths and other
 # values specific to a particular installation of LLVM.
-#
-#===------------------------------------------------------------------------===#
+#===-----------------------------------------------------------------------====
 
+#
 # Target operating system for which LLVM will be compiled.
+#
 OS=@OS@
 
+#
 # Target hardware architecture
+#
 ARCH=@ARCH@
 
-# Endian-ness of the target
-ENDIAN=@ENDIAN@
-
 # Path to the C++ compiler to use.  This is an optional setting, which defaults
 # to whatever your gmake defaults to.
+#
+# Under Linux, for some reason the compiler driver wants to search the PATH to
+# find the system assembler, which breaks if the LLVM assembler is in our path.
+# Hack it to use the assembler in /usr/bin directly.
+#
 CXX = @CXX@
 
-# Path to the CC binary, which use used by testcases for native builds.
+# We have the same problem with the CC binary, which use used by testcases for
+# native builds.
+#
 CC := @CC@
 
-# Path to the Python interpreter
-PYTHON := @PYTHON@
+#
+# Compilation flags for the C and C++ compilers.
+#
 
-# Linker flags.
+#
+# Removing the compiler flags for now.  They interfere with the test suite
+# (which has its own autoconf stuff), and we don't use -DHAVE_CONFIG_H anyway.
+#
+#CPPFLAGS+=@DEFS@
+#CCFLAGS+=@DEFS@
 LDFLAGS+=@LDFLAGS@
 
+#
+# Removed since it prevents the tests from working properly.
+#
+#LIBS+=@LIBS@
+
+#
 # Libraries needed by tools
+#
 TOOLLINKOPTS=@LIBS@
 
-# Path to the library archiver program.
+#
+# Path to the archiver program.
+#
 AR_PATH = @AR@
 
+#
 # The pathnames of the Flex and Bison programs, respectively.
-YACC     = @YACC@
-BISON    = @BISON@
+#
+BISON    = @YACC@
 FLEX     = @LEX@
 
+#
 # Paths to miscellaneous programs.
-RPWD    = pwd
-SED     = sed
-RM      = rm
-ECHO    = echo
+#
+RPWD    = @RPWD@
+SED     = @SED@
+RM      = @RM@
+ECHO    = @ECHO@
 MKDIR   = @abs_top_srcdir@/autoconf/mkinstalldirs
-DATE    = date
-MV      = mv
+DATE    = @DATE@
+MV      = @MV@
 INSTALL = @INSTALL@
 DOT     = @DOT@
 ETAGS   = @ETAGS@
-ETAGSFLAGS = @ETAGSFLAGS@
 
+#
 # Determine the target for which LLVM should generate code.
+#
 LLVMGCCARCH := @target@/3.4-llvm
 
-# Full pathnames of LLVM C/C++ front-end 'cc1' and 'cc1plus' binaries:
-LCC1 = @LLVMCC1@
-LCC1XX = @LLVMCC1PLUS@
-
 # Path to directory where object files should be stored during a build.
 # Set OBJ_ROOT to "." if you do not want to use a separate place for
 # object files.
+# 
+#OBJ_ROOT = .
 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.
+# Path to location for LLVM front-end this should only be specified here if you
+# want to override the value set in Makefile.$(uname)
+#
 LLVMGCCDIR := @LLVMGCCDIR@
 
-# When this variable is set to 1, programs in the llvm/test/Programs hierarchy
+# When this setting is set to true, programs in the llvm/test/Programs hierarchy
 # are not recompiled from source code.  Instead, the bytecode for the file is
 # pulled from the BYTECODE_REPOSITORY directory.  This can be useful when disk
 # space is limited or when you just don't want to spend time running the C
 # frontend.
+#
 #USE_PRECOMPILED_BYTECODE := 1
 @UPB@
 
@@ -86,54 +105,71 @@ LLVMGCCDIR := @LLVMGCCDIR@
 # versions of the test/Programs/* programs.  This is used as the bytecode source
 # when USE_PRECOMPILED_BYTECODE is specified or when source code is not
 # available for the program (such as SPEC).
+#
 BYTECODE_REPOSITORY := @BCR@
 
+# Path to location for purify, this is only needed if you build with
+# ENABLE_PURIFY=1
+# 
+PURIFY = @PURIFY@
+
+#
 # SPEC benchmarks:
-#	If these are set then run the SPEC benchmarks.
+#	Set the USE_SPEC variable to enable the use of the SPEC benchmarks.
 #	You must provide the SPEC benchmarks on your own.
-@USE_SPEC2000@
-@USE_SPEC95@
+#
+@USE_SPEC@
 
-# Path to the SPEC benchmarks.
-SPEC2000_ROOT := @SPEC2000_ROOT@
-SPEC95_ROOT := @SPEC95_ROOT@
-
-# Path to the Povray source code.
-@USE_POVRAY@
-POVRAY_ROOT := @POVRAY_ROOT@
+#
+# Path to the SPEC benchmarks.  If you have the SPEC benchmarks, place the
+# path here.
+#
+#SPEC_ROOT := /home/vadve/shared/benchmarks/speccpu2000/benchspec
+SPEC_ROOT := @SPEC_ROOT@
 
+#
 # Path to the PAPI code.  This is used by the reoptimizer only.
+#
 #PAPIDIR := /home/vadve/shared/papi-2.3.4.1
 PAPIDIR := @PAPIDIR@
 
 # These are options that can either be enabled here, or can be enabled on the
-# make command line (ie, make ENABLE_PROFILING=1):
+# make command line (ie, make ENABLE_PROFILING=1)
+#
 
 # When ENABLE_OPTIMIZED is enabled, Release builds of all of the LLVM code are
 # turned on, and Debug builds are turned off.
+#
 #ENABLE_OPTIMIZED = 1
 @ENABLE_OPTIMIZED@
 
 # When ENABLE_PROFILING is enabled, the llvm source base is built with profile
 # information to allow gprof to be used to get execution frequencies.
+#
 #ENABLE_PROFILING = 1
 
+#
 # This option tells the Makefiles to produce verbose output.
 # It essentially prints the commands that make is executing
+#
 #VERBOSE = 1
 
+# When ENABLE_PURIFY is set to 1, the LLVM tools are linked with purify (which
+# must be locally installed) to allow for some automated memory error debugging.
+#
+#ENABLE_PURIFY = 1
+@ENABLE_PURIFY@
+
+#
 # Enable JIT for this platform
+#
 @JIT@
 
+#
 # Disable LLC diffs for testing.
+#
 @DISABLE_LLC_DIFFS@
 
-# Shared library extension for this platform.
-SHLIBEXT = @SHLIBEXT@
-
-# Executable file extension for this platform.
-EXEEXT = @EXEEXT@
-
 ###########################################################################
 # Directory Configuration
 #	This section of the Makefile determines what is where.  To be
@@ -150,27 +186,37 @@ EXEEXT = @EXEEXT@
 #
 ###########################################################################
 
+#
 # 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))
@@ -179,18 +225,23 @@ LLVM_OBJ_ROOT := $(BUILD_OBJ_ROOT)
 endif
 endif
 
+#
 # Set the LLVM source directory.
 # It is typically the root directory of what we're compiling now.
+#
 ifndef LLVM_SRC_ROOT
 LLVM_SRC_ROOT := $(BUILD_SRC_ROOT)
 endif
 
+#
 # Set SourceDir for backwards compatbility.
+#
 ifndef SourceDir
 SourceDir=$(BUILD_SRC_DIR)
 endif
 
 # Installation directories, as provided by the configure script.
+
 exec_prefix = @exec_prefix@
 prefix = @prefix@
 program_transform_name = @program_transform_name@
@@ -202,7 +253,6 @@ sysconfdir = @sysconfdir@
 sharedstatedir = @sharedstatedir@ 
 localstatedir = @localstatedir@
 libdir = @libdir@
-bytecode_libdir = $(LLVMGCCDIR)/bytecode-libs
 includedir = @includedir@
 infodir = @infodir@
 mandir = @mandir@

llvm/Makefile.rules

@@ -1,11 +1,11 @@
-#===-- Makefile.rules - Common make rules for LLVM ---------*- Makefile -*--===#
-#
+#===-- Makefile.rules - Common make rules for LLVM -------*- makefile -*--====
+# 
 #                     The LLVM Compiler Infrastructure
 #
 # This file was developed by the LLVM research group and is distributed under
 # the University of Illinois Open Source License. See LICENSE.TXT for details.
 # 
-#===------------------------------------------------------------------------===#
+##===----------------------------------------------------------------------===##
 #
 # This file is included by all of the LLVM makefiles.  This file defines common
 # rules to do things like compile a .cpp file or generate dependency info.
@@ -71,14 +71,12 @@ all::$(LLVM_OBJ_ROOT)/config.status
 ifdef SHARED_LIBRARY
 # if SHARED_LIBRARY is specified, the default is to build the dynamic lib
 all:: dynamic
-install:: install-dynamic-library
 endif
 
 ifdef BYTECODE_LIBRARY
 # if BYTECODE_LIBRARY is specified, the default is to build the bytecode lib
 all:: bytecodelib
-install:: install-bytecode-library
-install-bytecode:: install-bytecode-library
+install:: bytecodelib-install
 endif
 
 # Default Rule:  Make sure it's also a :: rule
@@ -93,9 +91,6 @@ test::
 # Default rule for building only bytecode.
 bytecode::
 
-# Default rule for installing only bytecode.
-install-bytecode::
-
 # Print out the directories used for building
 prdirs::
 	@${ECHO} "Build Source Root: " $(BUILD_SRC_ROOT)
@@ -113,7 +108,7 @@ prdirs::
 ###########################################################################
 .SUFFIXES:
 .SUFFIXES: .c .cpp .h .hpp .y .l
-.SUFFIXES: .lo .o .a $(SHLIBEXT) .bc .td
+.SUFFIXES: .lo .o .a .so .bc .td
 .SUFFIXES: .ps .dot .d
 
 #
@@ -121,7 +116,7 @@ prdirs::
 # slightly since GNU Make will not try to find implicit rules for targets
 # which are marked as Phony.
 #
-.PHONY: all dynamic bytecodelib install-bytecode-library
+.PHONY: all dynamic bytecodelib bytecodelib-install
 .PHONY: clean distclean install test bytecode prdirs
 
 ###########################################################################
@@ -244,36 +239,24 @@ endif
 #--------------------------------------------------------------------------
 # Utilities used while building the LLVM tree, which live in the utils dir
 #
-BURG       := $(LLVMTOOLCURRENT)/burg$(EXEEXT)
+BURG       := $(LLVMTOOLCURRENT)/burg
 RunBurg    := $(BURG) $(BURG_OPTS)
-TBLGEN     := $(LLVMTOOLCURRENT)/tblgen$(EXEEXT)
-LGCCLDPROG := $(LLVMTOOLCURRENT)/gccld$(EXEEXT)
+TBLGEN     := $(LLVMTOOLCURRENT)/tblgen
+LGCCLDPROG := $(LLVMTOOLCURRENT)/gccld
 
 #--------------------------------------------------------------------------
 # The LLVM GCC front-end in C and C++ flavors
 #
 LLVMGCC := PATH=$(LLVMTOOLCURRENT):$(PATH) $(LLVMGCCDIR)/bin/gcc
+LCC1    := $(LLVMGCCDIR)/libexec/gcc/$(LLVMGCCARCH)/cc1
 LLVMGXX := PATH=$(LLVMTOOLCURRENT):$(PATH) $(LLVMGCCDIR)/bin/g++
+LCC1XX  := $(LLVMGCCDIR)/libexec/gcc/$(LLVMGCCARCH)/cc1plus
 
 #--------------------------------------------------------------------------
-# The compiled LLVM tools
+# Some of the compiled LLVM tools which are used for compilation of runtime
+# libraries.
 #
-
-LLVMAS  := $(LLVMTOOLCURRENT)/llvm-as$(EXEEXT)
-# Find the location of the platform specific LLVM GCC libraries
-LLVMGCCLIBDIR=$(dir $(shell $(LLVMGCC) -print-file-name=libgcc.a))
-# LLVM Tool Definitions (LLVMGCC, LLVMGXX, LLVMAS are provided by
-# Makefile.rules) 
-LLI       = $(LLVMTOOLCURRENT)/lli$(EXEEXT)
-LLC       = $(LLVMTOOLCURRENT)/llc$(EXEEXT)
-LGCCAS    = $(LLVMTOOLCURRENT)/gccas$(EXEEXT)
-LGCCLD    = $(LGCCLDPROG) -L$(LLVMGCCLIBDIR) -L$(LLVMGCCDIR)/lib
-LDIS      = $(LLVMTOOLCURRENT)/llvm-dis$(EXEEXT)
-LOPT      = $(LLVMTOOLCURRENT)/opt$(EXEEXT)
-LLINK     = $(LLVMTOOLCURRENT)/llvm-link$(EXEEXT)
-LPROF     = $(LLVMTOOLCURRENT)/llvm-prof$(EXEEXT)
-LANALYZE  = $(LLVMTOOLCURRENT)/analyze$(EXEEXT)
-LBUGPOINT = $(LLVMTOOLCURRENT)/bugpoint$(EXEEXT)
+LLVMAS  := $(LLVMTOOLCURRENT)/llvm-as
 
 
 ###########################################################################
@@ -307,16 +290,13 @@ CPPFLAGS += -D_GNU_SOURCE
 # Pull in limit macros from stdint.h, even in C++:
 CPPFLAGS += -D__STDC_LIMIT_MACROS
 
-### FIXME: this is GCC specific
-CPPFLAGS += -DATTR_DEPRECATED='__attribute__ ((deprecated))'
-
 CompileCommonOpts := -Wall -W -Wwrite-strings -Wno-unused
 CompileOptimizeOpts := -O3 -DNDEBUG -finline-functions
 
 #
 # Compile commands with libtool.
 #
-Compile  := $(LIBTOOL) --tag=CXX --mode=compile $(CXX) -c $(CPPFLAGS) $(CXXFLAGS) $(CompileCommonOpts)
+Compile  := $(LIBTOOL) --mode=compile $(CXX) -c $(CPPFLAGS) $(CXXFLAGS) $(CompileCommonOpts)
 CompileC  := $(LIBTOOL) --mode=compile $(CC) -c $(CPPFLAGS) $(CFLAGS) $(CompileCommonOpts)
 
 # Compile a cpp file, don't link...
@@ -337,7 +317,7 @@ CompileCP := $(CompileC) $(CompileOptimizeOpts) $(PROFILE)
 # Link final executable
 #	(Note that we always link with the C++ compiler).
 #
-Link     := $(LIBTOOL) --tag=CXX --mode=link $(CXX)
+Link     := $(LIBTOOL) --mode=link $(CXX)
 
 # link both projlib and llvmlib libraries
 LinkG    := $(Link) -g -L$(PROJLIBDEBUGSOURCE)  -L$(LLVMLIBDEBUGSOURCE) $(STRIP)
@@ -355,7 +335,7 @@ LinkP    := $(LinkP) $(TOOLLINKOPTSB)
 endif
 
 # Create one .o file from a bunch of .o files...
-Relink := ${LIBTOOL} --tag=CXX --mode=link $(CXX)
+Relink := ${LIBTOOL} --mode=link $(CXX)
 
 #
 # Configure where the item being compiled should go.
@@ -373,7 +353,7 @@ Depend   := $(CXX) -MM -I$(LEVEL)/include $(CPPFLAGS)
 DependC  := $(CC)  -MM -I$(LEVEL)/include $(CPPFLAGS) 
 
 # Archive a bunch of .o files into a .a file...
-AR       = $(AR_PATH) cr
+AR       = ${AR_PATH} cq 
 
 #----------------------------------------------------------
 
@@ -383,8 +363,7 @@ AR       = $(AR_PATH) cr
 # 
 ifndef Source
 Source  := $(notdir $(ExtraSource) $(wildcard $(SourceDir)/*.cpp \
-                    $(SourceDir)/*.cc $(SourceDir)/*.c $(SourceDir)/*.y \
-                    $(SourceDir)/*.l))
+                    $(SourceDir)/*.c $(SourceDir)/*.y $(SourceDir)/*.l))
 endif
 
 #
@@ -409,14 +388,14 @@ RObjectsG := $(addprefix $(BUILD_OBJ_DIR)/Debug/,$(RObjs))
 #---------------------------------------------------------
 
 ifdef DIRS
-all install clean test bytecode stripped-bytecode install-bytecode::
+all install clean test bytecode stripped-bytecode::
 	$(VERB) for dir in ${DIRS}; do \
 		if [ ! -f $$dir/Makefile ]; \
 		then \
 			$(MKDIR) $$dir; \
 			cp $(SourceDir)/$$dir/Makefile $$dir/Makefile; \
 		fi; \
-		($(MAKE) -C $$dir $@ $(MFLAGS)) || exit 1; \
+		($(MAKE) -C $$dir $@) || exit 1; \
 	done
 endif
 
@@ -428,20 +407,19 @@ clean    :: $(addsuffix /.makeclean   , $(PARALLEL_DIRS))
 test     :: $(addsuffix /.maketest    , $(PARALLEL_DIRS))
 bytecode :: $(addsuffix /.makebytecode, $(PARALLEL_DIRS))
 stripped-bytecode :: $(addsuffix /.makestripped-bytecode, $(PARALLEL_DIRS))
-install-bytecode :: $(addsuffix /.makeinstall-bytecode, $(PARALLEL_DIRS))
 
-%/.makeall %/.makeinstall %/.makeclean %/.maketest %/.makebytecode %/.makestripped-bytecode %/.makeinstall-bytecode:
+%/.makeall %/.makeinstall %/.makeclean %/.maketest %/.makebytecode %/.makestripped-bytecode:
 	$(VERB) if [ ! -f $(@D)/Makefile ]; \
 	then \
 		$(MKDIR) $(@D); \
 		cp $(SourceDir)/$(@D)/Makefile $(@D)/Makefile; \
 	fi; \
-	$(MAKE) -C $(@D) $(subst $(@D)/.make,,$@) $(MFLAGS)
+	$(MAKE) -C $(@D) $(subst $(@D)/.make,,$@)
 endif
 
 # Handle directories that may or may not exist
 ifdef OPTIONAL_DIRS
-all install clean test bytecode stripped-bytecode install-bytecode::
+all install clean test bytecode stripped-bytecode::
 	$(VERB) for dir in ${OPTIONAL_DIRS}; do \
 		if [ -d $(SourceDir)/$$dir ]; \
 		then\
@@ -450,7 +428,7 @@ all install clean test bytecode stripped-bytecode install-bytecode::
 				$(MKDIR) $$dir; \
 				cp $(SourceDir)/$$dir/Makefile $$dir/Makefile; \
 			fi; \
-			($(MAKE) -C$$dir $@ $(MFLAGS)) || exit 1; \
+			($(MAKE) -C$$dir $@) || exit 1; \
 		fi \
 	done
 endif
@@ -476,55 +454,44 @@ endif
 #  of it.  For this reason, sometimes it's useful to use libraries as .a files.
 ###########################################################################
 
-# Install rule for making bytecode library directory if it does not exist.
-# Trigger this by making libraries that need to be installed here depend on it.
-$(DESTDIR)$(bytecode_libdir):
-	$(MKDIR) $@
-
 ifdef LIBRARYNAME
 
 # Make sure there isn't any extranous whitespace on the LIBRARYNAME option
 LIBRARYNAME := $(strip $(LIBRARYNAME))
 
-LIBNAME_O    := $(DESTLIBRELEASE)/lib$(LIBRARYNAME)$(SHLIBEXT)
-LIBNAME_P    := $(DESTLIBPROFILE)/lib$(LIBRARYNAME)$(SHLIBEXT)
-LIBNAME_G    := $(DESTLIBDEBUG)/lib$(LIBRARYNAME)$(SHLIBEXT)
-LIBNAME_CUR  := $(DESTLIBCURRENT)/lib$(LIBRARYNAME)$(SHLIBEXT)
+LIBNAME_O    := $(DESTLIBRELEASE)/lib$(LIBRARYNAME).so
+LIBNAME_P    := $(DESTLIBPROFILE)/lib$(LIBRARYNAME).so
+LIBNAME_G    := $(DESTLIBDEBUG)/lib$(LIBRARYNAME).so
 LIBNAME_AO   := $(DESTLIBRELEASE)/lib$(LIBRARYNAME).a
 LIBNAME_AP   := $(DESTLIBPROFILE)/lib$(LIBRARYNAME).a
 LIBNAME_AG   := $(DESTLIBDEBUG)/lib$(LIBRARYNAME).a
-LIBNAME_ACUR := $(DESTLIBCURRENT)/lib$(LIBRARYNAME).a
 LIBNAME_OBJO := $(DESTLIBRELEASE)/$(LIBRARYNAME).o
 LIBNAME_OBJP := $(DESTLIBPROFILE)/$(LIBRARYNAME).o
 LIBNAME_OBJG := $(DESTLIBDEBUG)/$(LIBRARYNAME).o
-LIBNAME_OBJCUR := $(DESTLIBCURRENT)/$(LIBRARYNAME).o
 LIBNAME_BC   := $(DESTLIBBYTECODE)/lib$(LIBRARYNAME).bc
 
-
 #--------------------------------------------------------------------
 # Library Targets
 #	Modify the top level targets to build the desired libraries.
 #--------------------------------------------------------------------
 
 # dynamic target builds a shared object version of the library...
-dynamic:: $(LIBNAME_CUR)
+dynamic:: $(DESTLIBCURRENT)/lib$(LIBRARYNAME).so
 bytecodelib:: $(LIBNAME_BC)
-install-bytecode-library:: $(DESTDIR)$(bytecode_libdir)/lib$(LIBRARYNAME).bc
+bytecodelib-install:: $(LLVMGCCDIR)/bytecode-libs/lib$(LIBRARYNAME).bc
 
-$(DESTDIR)$(bytecode_libdir)/lib$(LIBRARYNAME).bc: $(LIBNAME_BC) $(DESTDIR)$(bytecode_libdir)
+$(LLVMGCCDIR)/bytecode-libs/lib$(LIBRARYNAME).bc: $(LIBNAME_BC)
 	@${ECHO} ======= Installing $(LIBRARYNAME) bytecode library =======
 	cp $< $@
 
 # Does the library want a .o version built?
 ifndef DONT_BUILD_RELINKED
-all:: $(LIBNAME_OBJCUR)
-install:: install-single-object-library
+all:: $(DESTLIBCURRENT)/$(LIBRARYNAME).o
 endif
 
 # Does the library want an archive version built?
 ifdef BUILD_ARCHIVE
-all:: $(LIBNAME_ACUR)
-install:: install-archive-library
+all:: $(DESTLIBCURRENT)/lib$(LIBRARYNAME).a
 endif
 
 #--------------------------------------------------------------------
@@ -569,10 +536,6 @@ $(LIBNAME_G): $(ObjectsG) $(LibSubDirs) $(DESTLIBDEBUG)/.dir
 	$(VERB) $(LIBTOOL) --mode=install $(INSTALL) $*.la $(DESTLIBCURRENT)
 	@${ECHO} ======= Finished building $(LIBRARYNAME) dynamic debug library =======
 
-install-dynamic-library: $(LIBNAME_CUR)
-	$(MKDIR) $(DESTDIR)$(libdir)
-	$(VERB) $(LIBTOOL) --mode=install $(INSTALL) $(LIBNAME_CUR) $(DESTDIR)$(libdir)/lib$(LIBRARYNAME)$(SHLIBEXT)
-
 #
 # Rules for building static archive libraries.
 #
@@ -594,9 +557,6 @@ $(LIBNAME_AG): $(ObjectsG) $(LibSubDirs) $(DESTLIBDEBUG)/.dir
 	$(VERB) $(Link) -g $(STRIP) -o $@ $(ObjectsG) $(LibSubDirs) -static
 	@${ECHO} ======= Finished building $(LIBRARYNAME) archive debug library =======
 
-install-archive-library: $(LIBNAME_ACUR)
-	$(MKDIR) $(DESTDIR)$(libdir)
-	$(VERB) $(LIBTOOL) --mode=install $(INSTALL) $(LIBNAME_ACUR) $(DESTDIR)$(libdir)/lib$(LIBRARYNAME).a
 
 #
 # Rules for building .o libraries.
@@ -624,10 +584,23 @@ $(LIBNAME_OBJG): $(ObjectsG) $(LibSubDirs) $(DESTLIBDEBUG)/.dir
 	@${ECHO} "Linking `basename $@`"
 	$(VERB) $(Relink) -o $@ $(RObjectsG) $(LibSubDirs)
 
-install-single-object-library: $(LIBNAME_OBJCUR)
-	$(MKDIR) $(DESTDIR)$(libdir)
-	$(VERB) $(LIBTOOL) --mode=install $(INSTALL) $(LIBNAME_OBJCUR) $(DESTDIR)$(libdir)/$(LIBRARYNAME).o
+endif
 
+#------------------------------------------------------------------------
+# Create a TAGS database for emacs
+#------------------------------------------------------------------------
+
+ifneq ($(ETAGS),false)
+ifeq ($(LEVEL), .)
+SRCDIRS := $(wildcard $(SourceDir)/include $(SourceDir)/lib $(SourceDir)/tools)
+
+tags:
+	$(ETAGS) -l c++ `find $(SRCDIRS) -name '*.cpp' -o -name '*.h'`
+all:: tags
+endif
+else
+tags:
+	${ECHO} "Cannot build $@: The program etags is not installed"
 endif
 
 #------------------------------------------------------------------------
@@ -708,8 +681,8 @@ $(TOOLEXENAME_P): $(ObjectsP) $(USED_LIB_PATHS_P) $(DESTTOOLPROFILE)/.dir
 	@${ECHO} ======= Finished building $(TOOLNAME) profile executable =======
 
 install:: $(TOOLEXENAMES)
-	$(MKDIR) $(DESTDIR)$(bindir)
-	$(LIBTOOL) --mode=install $(INSTALL_PROGRAM) -c -m 0755 $(TOOLEXENAMES) $(DESTDIR)$(bindir)/$(TOOLNAME)
+	$(MKDIR) $(bindir)
+	$(LIBTOOL) --mode=install $(INSTALL_PROGRAM) -c -m 0755 $(TOOLEXENAMES) $(bindir)/$(TOOLNAME)
 
 endif
 
@@ -718,7 +691,6 @@ endif
 #---------------------------------------------------------
 .PRECIOUS: $(BUILD_OBJ_DIR)/Depend/.dir $(BUILD_OBJ_DIR)/BytecodeObj/.dir
 .PRECIOUS: $(BUILD_OBJ_DIR)/Debug/.dir $(BUILD_OBJ_DIR)/Release/.dir
-.PRECIOUS: $(BUILD_OBJ_DIR)/Profile/.dir
 
 # Create .lo files in the ObjectFiles directory from the .cpp and .c files...
 $(BUILD_OBJ_DIR)/Release/%.lo: %.cpp $(BUILD_OBJ_DIR)/Release/.dir
@@ -824,10 +796,7 @@ clean::
 	$(VERB) $(RM) -rf $(BUILD_OBJ_DIR)/Debug $(BUILD_OBJ_DIR)/Release
 	$(VERB) $(RM) -rf $(BUILD_OBJ_DIR)/Profile $(BUILD_OBJ_DIR)/Depend
 	$(VERB) $(RM) -rf $(BUILD_OBJ_DIR)/BytecodeObj
-	$(VERB) $(RM) -f core core.[0-9][0-9]* *.o *.d *~ *.flc
-ifneq ($(strip $(SHLIBEXT)),) # Extra paranoia - make real sure SHLIBEXT is set
-	$(VERB)	$(RM) -f *$(SHLIBEXT)
-endif
+	$(VERB) $(RM) -f core core.[0-9][0-9]* *.o *.d *.so *~ *.flc
 	$(VERB) $(RM) -f $(LEX_OUTPUT) $(YACC_OUTPUT)
 
 ###########################################################################

llvm/README.txt

@@ -1 +1,128 @@
-This file is a placeholder; see docs/index.html for documentation.
+                       The LLVM Compiler Infrastructure
+                           http://llvm.cs.uiuc.edu
+
+Welcome to LLVM!
+----------------
+This file is intended to do four things:
+(1) help you get started using LLVM;
+(2) tell you how to get questions about LLVM answered;
+(3) tell you where to find documentation for different kinds of questions; and
+(4) tell you about three LLVM-related mailing lists.
+
+
+Getting Started with LLVM
+-------------------------
+
+(1) For license information:
+    llvm/LICENSE.txt
+
+(2) Installing and compiling LLVM:
+    llvm/docs/GettingStarted.html
+
+(3) Learn about features and limitations of this release:
+    llvm/docs/ReleaseNotes.html
+
+(4) Learn how to write a pass within the LLVM system:
+	llvm/docs/WritingAnLLVMPass.html
+
+(5) Learn how to start a new development project using LLVM, where your
+    new source code can live anywhere (outside or inside the LLVM tree),
+    while using LLVM header files and libraries:
+    llvm/docs/Projects.html
+
+
+Getting Help with LLVM
+----------------------
+
+(1) If you have questions or development problems not answered in the
+    documentation, send e-mail to llvmdev@cs.uiuc.edu.  This mailing list is
+    monitored by all the people in the LLVM group at Illinois, and you should
+    expect prompt first responses.
+
+(2) To report a bug, submit a bug report as described in the document:
+    http://llvm.cs.uiuc.edu/docs/HowToSubmitABug.html
+
+(3) We now use Bugzilla to track bugs, so you can check the status of
+    previous bugs at:
+    http://llvm.cs.uiuc.edu/bugs/query.cgi
+
+LLVM Documentation
+------------------
+
+All the documents mentioned below except the design overview tech report
+are included as part of the LLVM release (in llvm/docs/*):
+
+LLVM Design Overview:
+    LLVM : A Compilation Framework for Lifelong Program Analysis
+    and Transformation:
+        http://llvm.cs.uiuc.edu/pubs/2003-09-30-LifelongOptimizationTR.html
+
+LLVM User Guides:
+
+    Download and Installation Instructions:
+        llvm/docs/GettingStarted.html
+
+    LLVM Command Guide:
+        llvm/docs/CommandGuide/index.html
+
+    LLVM Assembly Language:
+        llvm/docs/LangRef.html
+
+    LLVM Test Suite Guide:
+        llvm/docs/TestingGuide.html
+
+LLVM Programming Documentation:
+
+    LLVM Programmers Manual:
+        llvm/docs/ProgrammersManual.html
+
+    Writing an LLVM Pass:
+        llvm/docs/WritingAnLLVMPass.html
+
+    Alias Analysis in LLVM:
+        llvm/docs/AliasAnalysis.html
+
+    Command Line Library:
+        llvm/docs/CommandLine.html
+
+    Coding Standards:
+        llvm/docs/CodingStandards.html
+
+Other LLVM Resources:
+
+    Submitting a Bug:
+        http://llvm.cs.uiuc.edu/docs/HowToSubmitABug.html
+
+    Open Projects:
+        llvm/docs/OpenProjects.html
+
+    Creating a new LLVM Project:
+        llvm/docs/Projects.html
+
+Mailing Lists
+--------------
+There are three mailing lists for providing LLVM users with information:
+
+(1) LLVM Announcements List:
+    http://mail.cs.uiuc.edu/mailman/listinfo/llvm-announce
+
+    This is a low volume list that provides important announcements regarding
+    LLVM.  It is primarily intended to announce new releases, major updates to
+    the software, etc.  This list is highly recommended for anyone that uses
+    LLVM.
+
+(2) LLVM Developers List:
+    http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
+
+    This list is for people who want to be included in technical discussions
+    of LLVM.  People post to this list when they have questions about writing
+    code for or using the LLVM tools.  It is relatively low volume.
+
+(3) LLVM Commits List
+    http://mail.cs.uiuc.edu/mailman/listinfo/llvm-commits
+
+    This list contains all commit messages that are made when LLVM developers
+    commit code changes to the CVS archive.  It is useful for those who want to
+    stay on the bleeding edge of LLVM development. This list is very high
+    volume.
+

llvm/autoconf/AutoRegen.sh

@@ -1,21 +0,0 @@
-#!/bin/sh
-die () {
-	echo "$@" 1>&2
-	exit 1
-}
-test -d autoconf && test -f autoconf/configure.ac && cd autoconf
-[ -f configure.ac ] || die "Can't find 'autoconf' dir; please cd into it first"
-echo "Regenerating aclocal.m4 with aclocal"
-aclocal || die "aclocal failed"
-autoconf --version | egrep '2\.5[0-9]' > /dev/null
-if test $? -ne 0
-then
-	die "Your autoconf was not detected as being 2.5x"
-fi
-echo "Note: Warnings about 'AC_CONFIG_SUBDIRS: you should use literals' are ok"
-echo "Regenerating configure with autoconf 2.5x"
-autoconf -o ../configure configure.ac || die "autoconf failed"
-cd ..
-echo "Regenerating config.h.in with autoheader 2.5x"
-autoheader -I autoconf autoconf/configure.ac || die "autoheader failed"
-exit 0

llvm/autoconf/aclocal.m4

@@ -5888,8 +5888,10 @@ if test "$ac_cv_cxx_namespaces" = yes; then
 fi
 ])
 
+#
 # Check for hash_map extension.  This is from
 # http://www.gnu.org/software/ac-archive/htmldoc/ac_cxx_have_ext_hash_map.html
+#
 AC_DEFUN([AC_CXX_HAVE_STD_EXT_HASH_MAP],
 [AC_CACHE_CHECK([whether the compiler has <ext/hash_map> defining template class std::hash_map],
  ac_cv_cxx_have_std_ext_hash_map,
@@ -5902,12 +5904,9 @@ using namespace std;
 #endif],[hash_map<int, int> t;],
   [ac_cv_cxx_have_std_ext_hash_map=yes], [ac_cv_cxx_have_std_ext_hash_map=no])
   AC_LANG_RESTORE])
- HAVE_STD_EXT_HASH_MAP=0
- if test "$ac_cv_cxx_have_std_ext_hash_map" = yes
- then
-   HAVE_STD_EXT_HASH_MAP=1
- fi
- AC_SUBST(HAVE_STD_EXT_HASH_MAP)])
+ if test "$ac_cv_cxx_have_std_ext_hash_map" = yes; then
+   AC_DEFINE(HAVE_STD_EXT_HASH_MAP,,[Define if the compiler has a header <ext/hash_map> that defines template class std::hash_map.])
+ fi])
 
 AC_DEFUN([AC_CXX_HAVE_GNU_EXT_HASH_MAP],
 [AC_CACHE_CHECK([whether the compiler has <ext/hash_map> defining template class __gnu_cxx::hash_map],
@@ -5921,12 +5920,9 @@ using namespace __gnu_cxx;
 #endif],[hash_map<int,int> t; ],
   [ac_cv_cxx_have_gnu_ext_hash_map=yes],[ac_cv_cxx_have_gnu_ext_hash_map=no])
   AC_LANG_RESTORE])
- HAVE_GNU_EXT_HASH_MAP=0
- if test "$ac_cv_cxx_have_gnu_ext_hash_map" = yes
- then
-   HAVE_GNU_EXT_HASH_MAP=1
- fi
- AC_SUBST(HAVE_GNU_EXT_HASH_MAP)])
+ if test "$ac_cv_cxx_have_gnu_ext_hash_map" = yes; then
+   AC_DEFINE(HAVE_GNU_EXT_HASH_MAP,,[Define if the compiler has a header <ext/hash_map> that defines template class __gnu_cxx::hash_map.])
+ fi])
 
 AC_DEFUN([AC_CXX_HAVE_GLOBAL_HASH_MAP],
 [AC_CACHE_CHECK([whether the compiler has <hash_map> defining template class ::hash_map],
@@ -5937,20 +5933,18 @@ AC_DEFUN([AC_CXX_HAVE_GLOBAL_HASH_MAP],
   AC_TRY_COMPILE([#include <hash_map>],[hash_map<int,int> t; ],
   [ac_cv_cxx_have_global_hash_map=yes], [ac_cv_cxx_have_global_hash_map=no])
   AC_LANG_RESTORE])
- HAVE_GLOBAL_HASH_MAP=0
- if test "$ac_cv_cxx_have_global_hash_map" = yes
- then
-   HAVE_GLOBAL_HASH_MAP=1
- fi
- AC_SUBST(HAVE_GLOBAL_HASH_MAP)])
+ if test "$ac_cv_cxx_have_global_hash_map" = yes; then
+   AC_DEFINE(HAVE_GLOBAL_HASH_MAP,,[Define if the compiler has a header <hash_map> that defines template class ::hash_map.])
+ fi])
 
 AC_DEFUN([AC_CXX_HAVE_HASH_MAP],
 [AC_CXX_HAVE_STD_EXT_HASH_MAP
  AC_CXX_HAVE_GNU_EXT_HASH_MAP
  AC_CXX_HAVE_GLOBAL_HASH_MAP])
-
+#
 # Check for hash_set extension.  This is modified from
 # http://www.gnu.org/software/ac-archive/htmldoc/ac_cxx_have_ext_hash_set.html
+#
 AC_DEFUN([AC_CXX_HAVE_STD_EXT_HASH_SET],
 [AC_CACHE_CHECK([whether the compiler has <ext/hash_set> defining template class std::hash_set],
  ac_cv_cxx_have_std_ext_hash_set,
@@ -5963,12 +5957,9 @@ using namespace std;
 #endif],[hash_set<int> t; ],
   [ac_cv_cxx_have_std_ext_hash_set=yes], [ac_cv_cxx_have_std_ext_hash_set=no])
   AC_LANG_RESTORE])
- HAVE_STD_EXT_HASH_SET=0
- if test "$ac_cv_cxx_have_std_ext_hash_set" = yes
- then
-   HAVE_STD_EXT_HASH_SET=1
- fi
- AC_SUBST(HAVE_STD_EXT_HASH_SET)])
+ if test "$ac_cv_cxx_have_std_ext_hash_set" = yes; then
+   AC_DEFINE(HAVE_STD_EXT_HASH_SET,,[Define if the compiler has a header <ext/hash_set> that defines template class std::hash_set.])
+ fi])
 
 AC_DEFUN([AC_CXX_HAVE_GNU_EXT_HASH_SET],
 [AC_CACHE_CHECK(
@@ -5983,12 +5974,9 @@ using namespace __gnu_cxx;
 #endif],[hash_set<int> t; ],
   [ac_cv_cxx_have_gnu_ext_hash_set=yes], [ac_cv_cxx_have_gnu_ext_hash_set=no])
   AC_LANG_RESTORE])
- HAVE_GNU_EXT_HASH_SET=0
- if test "$ac_cv_cxx_have_gnu_ext_hash_set" = yes
- then
-   HAVE_GNU_EXT_HASH_SET=1
- fi
- AC_SUBST(HAVE_GNU_EXT_HASH_SET)])
+ if test "$ac_cv_cxx_have_gnu_ext_hash_set" = yes; then
+   AC_DEFINE(HAVE_GNU_EXT_HASH_SET,,[Define if the compiler has a header <ext/hash_set> that defines template class __gnu_cxx::hash_set.])
+ fi])
 
 AC_DEFUN([AC_CXX_HAVE_GLOBAL_HASH_SET],
 [AC_CACHE_CHECK([whether the compiler has <hash_set> defining template class ::hash_set],
@@ -5999,20 +5987,19 @@ AC_DEFUN([AC_CXX_HAVE_GLOBAL_HASH_SET],
   AC_TRY_COMPILE([#include <hash_set>],[hash_set<int> t; return 0;],
   [ac_cv_cxx_have_global_hash_set=yes], [ac_cv_cxx_have_global_hash_set=no])
   AC_LANG_RESTORE])
- HAVE_GLOBAL_HASH_SET=0
- if test "$ac_cv_cxx_have_global_hash_set" = yes
- then
-   HAVE_GLOBAL_HASH_SET=1
- fi
- AC_SUBST(HAVE_GLOBAL_HASH_SET)])
+ if test "$ac_cv_cxx_have_global_hash_set" = yes; then
+   AC_DEFINE(HAVE_GLOBAL_HASH_SET,,[Define if the compiler has a header <hash_set> that defines template class ::hash_set.])
+ fi])
 
 AC_DEFUN([AC_CXX_HAVE_HASH_SET],
 [AC_CXX_HAVE_STD_EXT_HASH_SET
  AC_CXX_HAVE_GNU_EXT_HASH_SET
  AC_CXX_HAVE_GLOBAL_HASH_SET])
 
+#
 # Check for standard iterator extension.  This is modified from
 # http://www.gnu.org/software/ac-archive/htmldoc/ac_cxx_have_ext_hash_set.html
+#
 AC_DEFUN([AC_CXX_HAVE_STD_ITERATOR],
 [AC_CACHE_CHECK(whether the compiler has the standard iterator,
 ac_cv_cxx_have_std_iterator,
@@ -6026,12 +6013,10 @@ using namespace std;
   ac_cv_cxx_have_std_iterator=yes, ac_cv_cxx_have_std_iterator=no)
   AC_LANG_RESTORE
 ])
-HAVE_STD_ITERATOR=0
-if test "$ac_cv_cxx_have_std_iterator" = yes
-then
-   HAVE_STD_ITERATOR=1
+if test "$ac_cv_cxx_have_std_iterator" = yes; then
+   AC_DEFINE(HAVE_STD_ITERATOR,,[define if the compiler has STL iterators])
 fi
-AC_SUBST(HAVE_STD_ITERATOR)])
+])
 
 #
 # Check for bidirectional iterator extension.  This is modified from
@@ -6050,15 +6035,15 @@ using namespace std;
   ac_cv_cxx_have_bi_iterator=yes, ac_cv_cxx_have_bi_iterator=no)
   AC_LANG_RESTORE
 ])
-HAVE_BI_ITERATOR=0
-if test "$ac_cv_cxx_have_bi_iterator" = yes
-then
-   HAVE_BI_ITERATOR=1
+if test "$ac_cv_cxx_have_bi_iterator" = yes; then
+   AC_DEFINE(HAVE_BI_ITERATOR,,[define if the compiler has bidirectional iterator])
 fi
-AC_SUBST(HAVE_BI_ITERATOR)])
+])
 
+#
 # Check for forward iterator extension.  This is modified from
 # http://www.gnu.org/software/ac-archive/htmldoc/ac_cxx_have_ext_hash_set.html
+#
 AC_DEFUN([AC_CXX_HAVE_FWD_ITERATOR],
 [AC_CACHE_CHECK(whether the compiler has forward iterators,
 ac_cv_cxx_have_fwd_iterator,
@@ -6072,12 +6057,41 @@ using namespace std;
   ac_cv_cxx_have_fwd_iterator=yes, ac_cv_cxx_have_fwd_iterator=no)
   AC_LANG_RESTORE
 ])
-HAVE_FWD_ITERATOR=0
-if test "$ac_cv_cxx_have_fwd_iterator" = yes
-then
-   HAVE_FWD_ITERATOR=1
+if test "$ac_cv_cxx_have_fwd_iterator" = yes; then
+   AC_DEFINE(HAVE_FWD_ITERATOR,,[define if the compiler has STL iterators])
 fi
-AC_SUBST(HAVE_FWD_ITERATOR)])
+])
+
+#
+# Check for slist extension.  This is from
+# http://www.gnu.org/software/ac-archive/htmldoc/ac_cxx_have_ext_slist.html
+#
+AC_DEFUN([AC_CXX_HAVE_EXT_SLIST],
+[AC_CACHE_CHECK(whether the compiler has ext/slist,
+ac_cv_cxx_have_ext_slist,
+[AC_REQUIRE([AC_CXX_NAMESPACES])
+  AC_LANG_SAVE
+  AC_LANG_CPLUSPLUS
+  AC_TRY_COMPILE([#include <ext/slist>
+#ifdef HAVE_NAMESPACES
+using namespace std;
+#endif],[slist<int> s; return 0;],
+  ac_cv_cxx_have_ext_slist=std, ac_cv_cxx_have_ext_slist=no)
+  AC_TRY_COMPILE([#include <ext/slist>
+#ifdef HAVE_NAMESPACES
+using namespace __gnu_cxx;
+#endif],[slist<int> s; return 0;],
+  ac_cv_cxx_have_ext_slist=gnu, ac_cv_cxx_have_ext_slist=no)
+
+  AC_LANG_RESTORE
+])
+if test "$ac_cv_cxx_have_ext_slist" = std; then
+   AC_DEFINE(HAVE_EXT_SLIST,std,[define if the compiler has ext/slist])
+fi
+if test "$ac_cv_cxx_have_ext_slist" = gnu; then
+   AC_DEFINE(HAVE_EXT_SLIST,gnu,[define if the compiler has ext/slist])
+fi
+])
 
 #
 # Check for FLEX.  This is modified from
@@ -6097,10 +6111,6 @@ fi
 # Check for Bison.  This is modified from
 # http://www.gnu.org/software/ac-archive/htmldoc/ac_cxx_namespaces.html
 #
-# This macro verifies that Bison is installed.  If successful, then
-# 1) YACC is set to bison -y (to emulate YACC calls)
-# 2) BISON is set to bison
-#
 AC_DEFUN([AC_PROG_BISON],
 [AC_CACHE_CHECK(,
 ac_cv_has_bison,
@@ -6109,7 +6119,7 @@ ac_cv_has_bison,
 if test "$YACC" != "bison -y"; then
   AC_MSG_ERROR([bison not found but required])
 else
-  AC_SUBST(BISON,[bison],[location of bison])
+  AC_SUBST(YACC,[bison],[location of bison])
 fi
 ])
 
@@ -6210,7 +6220,6 @@ AC_DEFUN([AC_CONFIG_MAKEFILE],
 # http://www.gnu.org/software/ac-archive/htmldoc/ac_cxx_have_ext_slist.html
 AC_DEFUN([AC_C_PRINTF_A],
 [
-        AC_MSG_CHECKING([for printf %a format specifier])
 	AC_LANG_SAVE
 	AC_LANG_C
 	AC_RUN_IFELSE(
@@ -6230,7 +6239,6 @@ AC_DEFUN([AC_C_PRINTF_A],
 		                 return (0);]]]),
 		ac_c_printf_a=yes,ac_c_printf_a=no)
 	AC_LANG_RESTORE
-        AC_MSG_RESULT($ac_c_printf_a)
 	if test "$ac_c_printf_a" = "yes"; then
 		AC_DEFINE([HAVE_PRINTF_A],[1],[Define to have the %a format string])
 	fi
@@ -6241,7 +6249,6 @@ AC_DEFUN([AC_C_PRINTF_A],
 #
 AC_DEFUN([AC_LINK_USE_R],
 [
-  AC_MSG_CHECKING([for compiler -Wl,-R<path> option])
   AC_LANG_SAVE
   AC_LANG_C
   oldcflags="$CFLAGS"
@@ -6249,58 +6256,8 @@ AC_DEFUN([AC_LINK_USE_R],
   AC_LINK_IFELSE([int main() { return 0; }],[ac_cv_link_use_r=yes],[ac_cv_link_use_r=no])
   CFLAGS="$oldcflags"
   AC_LANG_RESTORE
-  AC_MSG_RESULT($ac_cv_link_use_r)
   if test "$ac_cv_link_use_r" = yes
   then
     AC_DEFINE([HAVE_LINK_R],[1],[Define if you can use -Wl,-R. to pass -R. to the linker, in order to add the current directory to the dynamic linker search path.])
   fi
 ])
-
-
-dnl AC_SINGLE_CXX_CHECK(DEFINEVAR, CACHEVAR, FUNCTION, HEADER, PROGRAM)
-dnl                     $1,        $2,       $3,       $4,     $5
-dnl 
-AC_DEFUN([AC_SINGLE_CXX_CHECK],
-[AC_CACHE_CHECK([for $3 in $4], [$2],
- [AC_LANG_PUSH(C++)
-  AC_COMPILE_IFELSE(AC_LANG_SOURCE([$5]),[$2=yes],[$2=no])
- AC_LANG_POP(C++)])
- if test "$$2" = "yes"
- then
-   AC_DEFINE($1, 1, [Define to 1 if your compiler defines $3 in the $4
-                     header file.])
- fi])
-
-AC_DEFUN([AC_FUNC_ISNAN],[
-AC_SINGLE_CXX_CHECK([HAVE_ISNAN_IN_MATH_H],    [ac_cv_func_isnan_in_math_h],   
-                    [isnan], [<math.h>],
-                    [#include <math.h>
-                     int foo(float f) {return isnan(f);}])
-AC_SINGLE_CXX_CHECK([HAVE_ISNAN_IN_CMATH],     [ac_cv_func_isnan_in_cmath],    
-                    [isnan], [<cmath>],
-                    [#include <cmath>
-                     int foo(float f) {return isnan(f);}])
-AC_SINGLE_CXX_CHECK([HAVE_STD_ISNAN_IN_CMATH], [ac_cv_func_std_isnan_in_cmath],
-                    [std::isnan], [<cmath>],
-                    [#include <cmath>
-                     using std::isnan; int foo(float f) {return isnan(f);}])
-])
-
-AC_DEFUN([AC_FUNC_ISINF],[
-AC_SINGLE_CXX_CHECK([HAVE_ISINF_IN_MATH_H],    [ac_cv_func_isinf_in_math_h],   
-                    [isinf], [<math.h>],
-                    [#include <math.h>
-                     int foo(float f) {return isinf(f);}])
-AC_SINGLE_CXX_CHECK([HAVE_ISINF_IN_CMATH],     [ac_cv_func_isinf_in_cmath],    
-                    [isinf], [<cmath>],
-                    [#include <cmath>
-                     int foo(float f) {return isinf(f);}])
-AC_SINGLE_CXX_CHECK([HAVE_STD_ISINF_IN_CMATH], [ac_cv_func_std_isinf_in_cmath],
-                    [std::isinf], [<cmath>],
-                    [#include <cmath>
-                     using std::isinf; int foo(float f) {return isinf(f);}])
-AC_SINGLE_CXX_CHECK([HAVE_FINITE_IN_IEEEFP_H], [ac_cv_func_finite_in_ieeefp_h],
-                    [finite], [<ieeefp.h>],
-                    [#include <ieeefp.h>
-                     int foo(float f) {return finite(f);}])
-])

llvm/autoconf/configure.ac

@@ -1,5 +1,21 @@
-dnl Initialize autoconf
-AC_INIT([[LLVM]],[[1.3]],[llvmbugs@cs.uiuc.edu])
+dnl Autoconf requirements
+dnl AC_INIT(package, version, bug-report-address)
+dnl information on the package
+dnl checks for programs
+dnl checks for libraries
+dnl checks for header files
+dnl checks for types
+dnl checks for structures
+dnl checks for compiler characteristics
+dnl checks for library functions
+dnl checks for system services
+dnl AC_CONFIG_FILES([file...])
+dnl AC_OUTPUT
+
+dnl **************************************************************************
+dnl * Initialize
+dnl **************************************************************************
+AC_INIT([[[LLVM]]],[[[1.1]]],[llvmbugs@cs.uiuc.edu])
 
 dnl Place all of the extra autoconf files into the config subdirectory
 AC_CONFIG_AUX_DIR([autoconf])
@@ -14,7 +30,9 @@ then
 	fi
 fi
 
+dnl
 dnl Configure all of the projects present in our source tree.
+dnl
 for i in `ls ${srcdir}/projects`
 do
   if test ${i} != "CVS"
@@ -26,18 +44,8 @@ do
   fi
 done
 
-dnl Configure header files
+dnl Configure a header file
 AC_CONFIG_HEADERS(include/Config/config.h)
-
-dnl Configure other output file
-AC_CONFIG_FILES(Makefile.config
- include/Support/DataTypes.h
- include/Support/ThreadSupport.h
- include/Support/hash_map
- include/Support/hash_set
- include/Support/iterator)
-
-dnl Do special configuration of Makefiles
 AC_CONFIG_MAKEFILE(Makefile)
 AC_CONFIG_MAKEFILE(Makefile.common)
 AC_CONFIG_MAKEFILE(lib/Makefile)
@@ -48,9 +56,9 @@ AC_CONFIG_MAKEFILE(test/QMTest/llvm.py)
 AC_CONFIG_MAKEFILE(test/QMTest/llvmdb.py)
 AC_CONFIG_MAKEFILE(test/Programs/Makefile)
 AC_CONFIG_MAKEFILE(test/Programs/Makefile.programs)
-AC_CONFIG_MAKEFILE(test/Programs/Makefile.tests)
 AC_CONFIG_MAKEFILE(test/Programs/TEST.aa.Makefile)
 AC_CONFIG_MAKEFILE(test/Programs/TEST.dsgraph.report)
+AC_CONFIG_MAKEFILE(test/Programs/TEST.micro.report)
 AC_CONFIG_MAKEFILE(test/Programs/TEST.aa.report)
 AC_CONFIG_MAKEFILE(test/Programs/TEST.example.Makefile)
 AC_CONFIG_MAKEFILE(test/Programs/TEST.nightly.Makefile)
@@ -61,12 +69,10 @@ AC_CONFIG_MAKEFILE(test/Programs/TEST.dsgraph.Makefile)
 AC_CONFIG_MAKEFILE(test/Programs/TEST.jit.report)
 AC_CONFIG_MAKEFILE(test/Programs/TEST.typesafe.Makefile)
 AC_CONFIG_MAKEFILE(test/Programs/TEST.dsgraph.gnuplot)
-AC_CONFIG_MAKEFILE(test/Programs/TEST.vtl.Makefile)
+AC_CONFIG_MAKEFILE(test/Programs/TEST.micro.Makefile)
 AC_CONFIG_MAKEFILE(test/Programs/External/Makefile)
 AC_CONFIG_MAKEFILE(test/Programs/External/SPEC/Makefile)
 AC_CONFIG_MAKEFILE(test/Programs/External/SPEC/Makefile.spec)
-AC_CONFIG_MAKEFILE(test/Programs/External/SPEC/Makefile.spec2000)
-AC_CONFIG_MAKEFILE(test/Programs/External/SPEC/Makefile.spec95)
 AC_CONFIG_MAKEFILE(test/Programs/MultiSource/Makefile)
 AC_CONFIG_MAKEFILE(test/Programs/MultiSource/Makefile.multisrc)
 AC_CONFIG_MAKEFILE(test/Programs/MultiSource/Benchmarks/FreeBench/analyzer/test.in)
@@ -84,12 +90,15 @@ AC_CONFIG_MAKEFILE(test/Programs/MultiSource/Benchmarks/FreeBench/pifft/Makefile
 AC_CONFIG_MAKEFILE(test/Programs/MultiSource/Benchmarks/FreeBench/pifft/test.in)
 AC_CONFIG_MAKEFILE(test/Programs/SingleSource/Makefile)
 AC_CONFIG_MAKEFILE(test/Programs/SingleSource/Makefile.singlesrc)
-AC_CONFIG_MAKEFILE(test/Programs/SingleSource/UnitTests/SetjmpLongjmp/Makefile)
 AC_CONFIG_MAKEFILE(tools/Makefile)
 AC_CONFIG_MAKEFILE(utils/Makefile)
 AC_CONFIG_MAKEFILE(projects/Makefile)
 
-dnl Find the install program (needs to be done before canonical stuff)
+dnl **************************************************************************
+dnl * Determine which system we are building on
+dnl **************************************************************************
+
+dnl Check the install program (needs to be done before canonical stuff)
 AC_PROG_INSTALL
 
 dnl Check which host for which we're compiling.  This will tell us which LLVM
@@ -106,6 +115,7 @@ case $build in
 			   AC_SUBST(LLVMGCCDIR,[/home/vadve/lattner/local/x86/llvm-gcc/])
 			 fi
 	         ;;
+
 	*-*-solaris*)
              AC_SUBST(OS,[SunOS])
 			 if test -d /home/vadve/lattner/local/sparc/llvm-gcc
@@ -113,15 +123,11 @@ case $build in
 	           AC_SUBST(LLVMGCCDIR,[/home/vadve/lattner/local/sparc/llvm-gcc/])
 			 fi
 	         ;;
-	*-*-cygwin*)
-             AC_SUBST(OS,[Cygwin])
-	         ;;
+
 	*-*-darwin*)
              AC_SUBST(OS,[Darwin])
 	         ;;
-	*-*-aix*)
-             AC_SUBST(OS,[AIX])
-	         ;;
+
 	*)       AC_SUBST(OS,[Unknown])
 	         ;;
 esac
@@ -148,6 +154,10 @@ case $target in
 	                  ;;
 esac
 
+dnl **************************************************************************
+dnl * Check for programs.
+dnl **************************************************************************
+
 dnl Check for compilation tools
 AC_PROG_CXX
 AC_PROG_CC(gcc)
@@ -158,6 +168,7 @@ if test "$GCC" != "yes"
 then
 	AC_MSG_ERROR([gcc required but not found])
 fi
+
 if test "$GXX" != "yes"
 then
 	AC_MSG_ERROR([g++ required but not found])
@@ -167,41 +178,86 @@ dnl Verify that GCC is version 3.0 or higher
 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])
+	AC_MSG_ERROR([gcc 3.x required])
 fi
 
-dnl Check for GNU Make.  We use its extensions too, so don't build without it
+dnl Check for GNU Make.  We use its extensions to, so don't build without it
 CHECK_GNU_MAKE
 if test -z "$_cv_gnu_make_command"
 then
 	AC_MSG_ERROR([GNU Make required but not found])
 fi
 
-dnl Checks for other tools
+dnl Check for compiler-compiler tools (reminds me of Little Caesar's Pizza)
 AC_PROG_FLEX
 AC_PROG_BISON
+
+dnl Check for libtool
 AC_PROG_LIBTOOL
 
-dnl Checks for tools we can get away with not having:
-AC_PATH_PROG(DOT,[dot],[true dot])
-AC_PATH_PROG(ETAGS,[etags],[true etags])
-dnl Check if we know how to tell etags we are using C++:
-etags_version=`$ETAGS --version 2>&1`
-case "$etags_version" in
-	*[Ee]xuberant*) ETAGSFLAGS="--language-force=c++" ;;
-	*GNU\ Emacs*) ETAGSFLAGS="-l c++" ;;
-	*) ETAGSFLAGS="" ;;
-esac
-AC_SUBST(ETAGSFLAGS,$ETAGSFLAGS)
-AC_PATH_PROG(PYTHON,[python],[true python])
-if test "$PYTHON" = "false"
+dnl Check for our special programs
+AC_PATH_PROG(RPWD,[pwd],[false])
+if test ${RPWD} = "false"
 then
-	AC_MSG_WARN([Python is required for the test suite, but it was not found])
+	AC_MSG_ERROR([pwd required but not found])
 fi
-AC_PATH_PROG(QMTEST,[qmtest],[true qmtest])
-if test "$QMTEST" = "false"
+
+AC_PATH_PROG(AR,[ar],[false])
+if test ${AR} = "false"
 then
-	AC_MSG_WARN([QMTest is required for the test suite, but it was not found])
+	AC_MSG_ERROR([ar required but not found])
+fi
+
+AC_PATH_PROG(SED,[sed],[false])
+if test ${SED} = "false"
+then
+	AC_MSG_ERROR([sed required but not found])
+fi
+
+AC_PATH_PROG(RM,[rm],[false])
+if test ${RM} = "false"
+then
+	AC_MSG_ERROR([rm required but not found])
+fi
+
+AC_PATH_PROG(ECHO,[echo],[false])
+if test ${ECHO} = "false"
+then
+	AC_MSG_ERROR([echo required but not found])
+fi
+
+AC_PATH_PROG(MKDIR,[mkdir],[false])
+if test ${MKDIR} = "false"
+then
+	AC_MSG_ERROR([mkdir required but not found])
+fi
+
+AC_PATH_PROG(DATE,[date],[false])
+if test ${DATE} = "false"
+then
+	AC_MSG_ERROR([date required but not found])
+fi
+
+AC_PATH_PROG(MV,[mv],[false])
+if test ${MV} = "false"
+then
+	AC_MSG_ERROR([mv required but not found])
+fi
+
+AC_PATH_PROG(DOT,[dot],[false])
+
+AC_PATH_PROG(ETAGS,[etags],[false])
+
+AC_PATH_PROG(PYTHON,[python],[false])
+if test ${PYTHON} = "false"
+then
+	AC_MSG_WARN([python required but not found])
+fi
+
+AC_PATH_PROG(QMTEST,[qmtest],[false])
+if test ${QMTEST} = "false"
+then
+	AC_MSG_WARN([qmtest required but not found])
 fi
 
 dnl Verify that the version of python available is high enough for qmtest
@@ -215,17 +271,20 @@ then
 	then
 		if test "$pyminor" -lt "2"
 		then
-			AC_MSG_WARN([QMTest requires Python 2.2 or later])
+			AC_MSG_WARN([Python 2.2 or greater required for qmtest])
 		fi
 	fi
 else
-	AC_MSG_WARN([QMTest requires Python 2.2 or later])
+	AC_MSG_WARN([Python 2.2 or greater required for qmtest])
 fi
 
 dnl Verify that the source directory is valid
 AC_CONFIG_SRCDIR(["Makefile.config.in"])
 
-dnl Checks for libraries:
+dnl **************************************************************************
+dnl * Check for libraries.
+dnl **************************************************************************
+
 dnl libelf is for sparc only; we can ignore it if we don't have it
 AC_CHECK_LIB(elf, elf_begin)
 
@@ -237,34 +296,46 @@ AC_SEARCH_LIBS(mallinfo,malloc,AC_DEFINE([HAVE_MALLINFO],[1],[Define if mallinfo
 
 dnl pthread locking functions are optional - but llvm will not be thread-safe
 dnl without locks.
-AC_SEARCH_LIBS(pthread_mutex_lock,pthread,HAVE_PTHREAD_MUTEX_LOCK=1,HAVE_PTHREAD_MUTEX_LOCK=0)
-AC_SUBST(HAVE_PTHREAD_MUTEX_LOCK)
+AC_SEARCH_LIBS(pthread_mutex_lock,pthread,AC_DEFINE(HAVE_PTHREAD_MUTEX_LOCK,1,[Define if PThread mutexes (e.g., pthread_mutex_lock) are available in the system's thread library.]))
 
-dnl Checks for header files.
-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.
+dnl
+dnl The math libraries are used by the test code, but not by the actual LLVM
+dnl code.
+dnl
+dnl AC_CHECK_LIB(m, cos)
+
+dnl **************************************************************************
+dnl * Checks for header files.
+dnl *	Chances are, if the standard C or POSIX type header files are missing,
+dnl *	then LLVM just isn't going to compile.  However, it is possible that
+dnl *	the necessary functions/macros will be included from other
+dnl *	(non-standard and non-obvious) header files.
+dnl *
+dnl *	So, we'll be gracious, give it a chance, and try to go on without
+dnl *	them.
+dnl **************************************************************************
 AC_HEADER_STDC
 AC_HEADER_SYS_WAIT
 
-dnl Checks for POSIX and other various system-specific header files
-AC_CHECK_HEADERS(fcntl.h limits.h sys/time.h unistd.h malloc.h sys/mman.h sys/resource.h dlfcn.h link.h execinfo.h windows.h)
+dnl Check for ANSI C/POSIX header files
+AC_CHECK_HEADERS(assert.h fcntl.h limits.h sys/time.h unistd.h errno.h signal.h math.h)
 
-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_HEADER([sys/types.h],
-                [INCLUDE_SYS_TYPES_H='#include <sys/types.h>'],
-                [INCLUDE_SYS_TYPES_H=''])
-AC_SUBST(INCLUDE_SYS_TYPES_H)
-AC_CHECK_HEADER([inttypes.h],
-                [INCLUDE_INTTYPES_H='#include <inttypes.h>'],
-                [INCLUDE_INTTYPES_H=''])
-AC_SUBST(INCLUDE_INTTYPES_H)
-AC_CHECK_HEADER([stdint.h],
-                [INCLUDE_STDINT_H='#include <stdint.h>'],
-                [INCLUDE_STDINT_H=''])
-AC_SUBST(INCLUDE_STDINT_H)
+dnl Check for system specific header files
+AC_CHECK_HEADERS(malloc.h sys/mman.h sys/resource.h)
 
+dnl Check for header files associated with dlopen and friends
+AC_CHECK_HEADERS(dlfcn.h link.h)
+
+dnl **************************************************************************
+dnl * Checks for typedefs, structures, and compiler characteristics.
+dnl **************************************************************************
+
+dnl Check for const and inline keywords
+AC_C_CONST
+AC_C_INLINE
+
+dnl Check for machine endian-ness
+AC_C_BIGENDIAN(AC_DEFINE([ENDIAN_BIG],[],[Define if the machine is Big-Endian]),AC_DEFINE([ENDIAN_LITTLE],[],[Define if the machine is Little-Endian]))
 
 dnl Check for types
 AC_TYPE_PID_T
@@ -277,41 +348,62 @@ AC_STRUCT_TM
 dnl Check for various C features
 AC_C_PRINTF_A
 
-dnl Check for the endianness of the target
-AC_C_BIGENDIAN(AC_SUBST([ENDIAN],[big]),AC_SUBST([ENDIAN],[little]))
-
 dnl Check for C++ extensions
 AC_CXX_HAVE_HASH_MAP
 AC_CXX_HAVE_HASH_SET
+AC_CXX_HAVE_EXT_SLIST
 AC_CXX_HAVE_STD_ITERATOR
 AC_CXX_HAVE_BI_ITERATOR
 AC_CXX_HAVE_FWD_ITERATOR
 
-AC_FUNC_ISNAN
-AC_FUNC_ISINF
-
-dnl Checks for library functions.
+dnl **************************************************************************
+dnl * Checks for library functions.
+dnl **************************************************************************
 AC_FUNC_ALLOCA
+AC_PROG_GCC_TRADITIONAL
+AC_FUNC_MEMCMP
 AC_FUNC_MMAP
-if test "$ac_cv_func_mmap_fixed_mapped" = "no"
-then
-	AC_MSG_WARN([mmap() required but not found])
-fi
 AC_FUNC_MMAP_FILE
-if test "$ac_cv_func_mmap_file" = "no"
+if test ${ac_cv_func_mmap_file} = "no"
 then
-	AC_MSG_WARN([mmap() of files required but not found])
+	AC_MSG_ERROR([mmap() of files required but not found])
 fi
 AC_HEADER_MMAP_ANONYMOUS
 AC_TYPE_SIGNAL
-AC_CHECK_FUNCS(getcwd gettimeofday strdup strtoq strtoll backtrace isatty mkstemp getrusage)
+AC_CHECK_FUNCS(getcwd gettimeofday strcspn strdup strerror strspn strstr strtod strtol strtoq strtoll)
+
+dnl
+dnl Need to check mmap for MAP_PRIVATE, MAP_ANONYMOUS, MAP_ANON, MAP_FIXED
+dnl MAP_FIXED is only needed for Sparc
+dnl MAP_ANON is used for Sparc and BSD
+dnl Everyone should have MAP_PRIVATE
+dnl
+
+dnl Check for certain functions (even if we've already found them) so that we
+dnl can quit with an error if they are unavailable.
+dnl
+dnl As the code is made more portable (i.e. less reliant on these functions,
+dnl these checks should go away.
+AC_CHECK_FUNC(mmap,,AC_MSG_ERROR([Function mmap() required but not found]))
 AC_CHECK_FUNC(mprotect,,AC_MSG_ERROR([Function mprotect() required but not found]))
 
 dnl Determine if the linker supports the -R option.
-AC_LINK_USE_R
+AC_LINK_USE_R()
 
-dnl --enable/--with command-line options:
-dnl Check whether they want to do an optimized build:
+dnl **************************************************************************
+dnl * Enable various compile-time options
+dnl **************************************************************************
+
+dnl Purify Option
+AC_ARG_ENABLE(purify,AC_HELP_STRING([--enable-purify],[Compile with purify (default is NO)]),,enableval="no")
+if test ${enableval} = "no"
+then
+	AC_SUBST(ENABLE_PURIFY,[[]])
+else
+	AC_SUBST(ENABLE_PURIFY,[[ENABLE_PURIFY=1]])
+fi
+
+dnl Optimized Option
 AC_ARG_ENABLE(optimized,AC_HELP_STRING([--enable-optimized],[Compile with optimizations enabled (default is NO)]),,enableval=no)
 if test ${enableval} = "no"
 then
@@ -320,50 +412,27 @@ else
 	AC_SUBST(ENABLE_OPTIMIZED,[[ENABLE_OPTIMIZED=1]])
 fi
 
-AC_DEFUN(EXTERNAL_BENCHMARK,
-[m4_define([allcapsname],translit($1,a-z,A-Z))
- AC_ARG_ENABLE($1,
- AC_HELP_STRING([--enable-$1=ARG], 
-                [Use $1 as a benchmark (srcs in DIR)]),
- checkresult=$enableval,
- checkresult=auto)
-AC_MSG_CHECKING([for $1 benchmark sources])
-case "$checkresult" in
-auto|yes)
-    defaultdir=$2
-	if test -d "$defaultdir"
+dnl Spec Benchmarks
+AC_ARG_ENABLE(spec2000,AC_HELP_STRING([--enable-spec],[Compile SPEC 2000 benchmarks (default is NO)]),,enableval=no)
+if test ${enableval} = "no"
+then
+	if test -d /home/vadve/shared/benchmarks/speccpu2000/benchspec
 	then
-		AC_SUBST(allcapsname()[_ROOT],[$defaultdir])
-		AC_SUBST([USE_]allcapsname(),[USE_]allcapsname()=1)
-        checkresult="yes, found in $defaultdir"
-    else
-        checkresult=no
-    fi
-    ;;
-no)
-    AC_SUBST(allcapsname()[_ROOT],[])
-    AC_SUBST([USE_]allcapsname(),[])
-    checkresult=no
-    ;;
-*)  if test -d "$checkresult"
-    then
-        AC_SUBST(allcapsname()[_ROOT],"$checkresult")
-        AC_SUBST([USE_]allcapsname(),[USE_]allcapsname()=1)
-        checkresult="yes, in $checkresult"
-    else
-        AC_SUBST(allcapsname()[_ROOT],[])
-        AC_SUBST([USE_]allcapsname(),[])
-        checkresult="no, not found in $checkresult"
-    fi
-    ;;
-esac
-AC_MSG_RESULT($checkresult)
-m4_undefine([allcapsname])
-])
-
-EXTERNAL_BENCHMARK(spec95,/home/vadve/shared/benchmarks/spec95/benchspec)
-EXTERNAL_BENCHMARK(spec2000,/home/vadve/shared/benchmarks/speccpu2000/benchspec)
-EXTERNAL_BENCHMARK(povray,/home/vadve/shared/benchmarks/povray31)
+		AC_SUBST(SPEC_ROOT,[/home/vadve/shared/benchmarks/speccpu2000/benchspec])
+		AC_SUBST(USE_SPEC,[[USE_SPEC=1]])
+	else
+		AC_SUBST(USE_SPEC,[[]])
+		AC_SUBST(SPEC_ROOT,[])
+	fi
+else
+	if test ${enableval} = ""
+	then
+		AC_SUBST(SPEC_ROOT,[/home/vadve/shared/benchmarks/speccpu2000/benchspec])
+	else
+		AC_SUBST(SPEC_ROOT,[${enableval}])
+	fi
+	AC_SUBST(USE_SPEC,[[USE_SPEC=1]])
+fi
 
 dnl Precompiled Bytecode Option
 AC_ARG_ENABLE(precompiled_bytecode,AC_HELP_STRING([--enable-precompiled_bytecode],[Use pre-compiled bytecode (default is NO)]),,enableval=no)
@@ -374,6 +443,7 @@ else
 	AC_SUBST(UPB,[[USE_PRECOMPILED_BYTECODE=1]])
 fi
 
+
 dnl LLC Diff Option
 AC_ARG_ENABLE(llc_diffs,AC_HELP_STRING([--enable-llc_diffs],[Enable LLC Diffs when testing (default is YES)]),,enableval=yes)
 if test ${enableval} = "no"
@@ -385,6 +455,7 @@ fi
 
 dnl JIT Option
 AC_ARG_ENABLE(jit,AC_HELP_STRING([--enable-jit],[Enable Just In Time Compiling (default is YES)]),,enableval=default)
+
 if test ${enableval} = "no"
 then
 	AC_SUBST(JIT,[[]])
@@ -402,8 +473,13 @@ else
 	esac
 fi
 
-dnl Find the LLVM GCC-based C/C++ front end
+dnl **************************************************************************
+dnl * Set the location of various third-party software packages
+dnl **************************************************************************
+
+dnl Location of the LLVM C front end
 AC_ARG_WITH(llvmgccdir,AC_HELP_STRING([--with-llvmgccdir],[Location of LLVM GCC front-end]),AC_SUBST(LLVMGCCDIR,[$withval]))
+
 AC_MSG_CHECKING([for llvm-gcc])
 LLVM_GCC_CHECK=no
 if test -d "$LLVMGCCDIR"
@@ -419,6 +495,7 @@ if test "$LLVM_GCC_CHECK" = "no"
 then
     llvmgccwarn=yes
 fi
+
 AC_MSG_CHECKING([whether llvm-gcc is sane])
 LLVM_GCC_SANE=no
 if test -x "$LLVM_GCC_CHECK"
@@ -430,10 +507,6 @@ then
 		LLVM_GCC_SANE=yes
 	fi
 	rm conftest.c
-	llvmcc1path=`"$LLVM_GCC_CHECK" --print-prog-name=cc1`
-	AC_SUBST(LLVMCC1,$llvmcc1path)
-	llvmcc1pluspath=`"$LLVM_GCC_CHECK" --print-prog-name=cc1plus`
-	AC_SUBST(LLVMCC1PLUS,$llvmcc1pluspath)
 fi
 AC_MSG_RESULT($LLVM_GCC_SANE)
 if test "$LLVM_GCC_SANE" = "no"
@@ -447,20 +520,18 @@ AC_ARG_WITH(bcrepos,AC_HELP_STRING([--with-bcrepos],[Location of Bytecode Reposi
 dnl Location of PAPI
 AC_ARG_WITH(papi,AC_HELP_STRING([--with-papi],[Location of PAPI]),AC_SUBST(PAPIDIR,[$withval]),AC_SUBST(PAPIDIR,[/home/vadve/shared/Sparc/papi-2.3.4.1]))
 
-dnl Get libtool's idea of what the shared library suffix is.
-dnl (This is a hack; it relies on undocumented behavior.)
-AC_MSG_CHECKING([for shared library suffix])
-eval "SHLIBEXT=$shrext"
-AC_MSG_RESULT($SHLIBEXT)
-dnl Propagate it to the Makefiles and config.h (for gccld & bugpoint).
-AC_SUBST(SHLIBEXT,$SHLIBEXT)
-AC_DEFINE_UNQUOTED(SHLIBEXT,"$SHLIBEXT",
-                   [Extension that shared libraries have, e.g., ".so".])
+dnl Location of the purify program
+AC_ARG_WITH(purify,AC_HELP_STRING([--with-purify],[Location of purify program]),AC_SUBST(PURIFY,[$withval]))
 
-dnl Create the output files
-AC_OUTPUT()
+dnl **************************************************************************
+dnl * Configure other software packages (via AC_CONFIG_SUBDIRS)
+dnl **************************************************************************
+
+dnl **************************************************************************
+dnl * Create the output files
+dnl **************************************************************************
+AC_OUTPUT(Makefile.config)
 
-dnl Warn loudly if llvm-gcc was not obviously working
 if test $llvmgccwarn = yes
 then
 	AC_MSG_WARN([***** llvm C/C++ front end was not found, or does not])
@@ -470,4 +541,3 @@ then
 	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.])
 fi
-

llvm/docs/CFEBuildInstrs.html

@@ -1,9 +1,8 @@
-<!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 Transitional//EN">
 <html>
 <head>
-  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
-  <link rel="stylesheet" href="llvm.css" type="text/css" media="screen">
+  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
+  <link rel="stylesheet" href="llvm.css" type="text/css" media="screen" />
   <title>Bootstrapping the LLVM C/C++ Front-End</title>
 </head>
 <body>
@@ -14,17 +13,12 @@
 
 <ol>
   <li><a href="#cautionarynote">A Cautionary Note</a>
-    <ul>
-      <li><a href="#cygwin">Building under Cygwin</a></li>
-    </ul>
-  </li>
-  <li><a href="#instructions">Instructions</a></li>
-  <li><a href="#license">License Information</a></li>
+  <li><a href="#instructions">Instructions</a>
+  <li><a href="#license">License Information</a>
 </ol>
 
-<div class="doc_author">    
-  <p>Written by Brian R. Gaeke and 
-     <a href="http://nondot.org/sabre">Chris Lattner</a></p>
+<div class="doc_text">    
+  <p><b>Written by Brian R. Gaeke</b></p>
 </div>
 
 <!-- *********************************************************************** -->
@@ -51,23 +45,6 @@ process, and you should <b>only</b> try to do it if:</p>
 <p>We welcome patches to help make this process simpler.</p>
 </div>
 
-<!--=========================================================================-->
-<div class="doc_subsection">
-  <a name="cygwin">Building under Cygwin</a>
-</div>
-<!--=========================================================================-->
-
-<div class="doc_text">
-<p>If you are building LLVM and the C front-end under Cygwin, please note that
-the LLVM and GCC makefiles do not correctly handle spaces in paths.  To deal
-with this issue, make sure that your LLVM and GCC source and build trees are 
-located in a top-level directory (like <tt>/cygdrive/c/llvm</tt> and 
-<tt>/cygdrive/c/llvm-cfrontend</tt>), not in a directory that contains a space
-(which includes your "home directory", because it lives under the "Documents 
-and Settings" directory).  We welcome patches to fix this issue.
-</p>
-</div>
-
 <!-- *********************************************************************** -->
 <div class="doc_section">
   <a name="instructions">Instructions</a>
@@ -81,11 +58,12 @@ and Settings" directory).  We welcome patches to fix this issue.
 <pre>
  % cd llvm
  % ./configure [options...]
- % gmake 
+ % gmake tools-only
 </pre>
-    <p>This will build all of the LLVM tools and libraries, but you will see 
-       warnings about missing the C front-end (certain runtime libraries can't
-       be built without it).  Ignore these warnings for now.</p></li>
+    <p>The use of the non-default target "tools-only" means that the
+    LLVM tools and libraries will build, and the binaries will be
+    deposited in llvm/tools/Debug, but the runtime (bytecode)
+    libraries will not build.</p></li>
 
 <li><p>Add the directory containing the tools to your PATH.</p>
 <pre>
@@ -94,6 +72,9 @@ and Settings" directory).  We welcome patches to fix this issue.
 
 <li><p>Unpack the C/C++ front-end source into cfrontend/src.</p></li>
 
+<li><p>Edit src/configure.  Change the first line (starting w/ #!) to
+       contain the correct full pathname of sh.</p></li>
+
 <li><p>Make "build" and "install" directories as siblings of the "src"
        tree.</p>
 <pre>
@@ -104,52 +85,53 @@ and Settings" directory).  We welcome patches to fix this issue.
  % set CFEINSTALL = `pwd`/install
 </pre></li>
 
-
 <li><p>Configure, build, and install the C front-end:</p>
 
 <p>
-<b>Linux/x86:</b><br>
-<b>MacOS X/PowerPC</b> (requires dlcompat library):
+<b>Linux/x86:</b>
 </p>
 
 <pre>
  % cd build
  % ../src/configure --prefix=$CFEINSTALL --disable-threads --disable-nls --disable-shared \
    --enable-languages=c,c++
- % gmake
+ % gmake all-gcc
  % setenv LLVM_LIB_SEARCH_PATH `pwd`/gcc 
  % gmake all; gmake install
 </pre>
 
-<p><b>Cygwin/x86:</b></p>
-
-<pre>
- % cd build
- % ../src/configure --prefix=$CFEINSTALL --disable-threads --disable-nls --disable-shared \
-   --enable-languages=c,c++ --disable-c-mbchar
- % gmake
- % setenv LLVM_LIB_SEARCH_PATH `pwd`/gcc 
- % gmake all; gmake install
-</pre>
-
-<p><b>Solaris/SPARC:</b></p>
-
 <p>
-For Solaris/SPARC, LLVM only supports the SPARC V9.  Therefore, the
-configure command line should specify sparcv9, as shown below. Also,
-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>).
+<b>Solaris/Sparc:</b>
+</p>
+
+<p>
+For Solaris/Sparc, LLVM only supports SparcV9.  Therefore, the configure
+command line should like something like this:
 </p>
 
 <pre>
  % cd build
- % ../src/configure --prefix=$CFEINSTALL --disable-threads --disable-nls \
-   --disable-shared --enable-languages=c,c++ --host=sparcv9-sun-solaris2.8 \
-   --disable-c-mbchar
- % gmake
+ % ../src/configure --prefix=$CFEINSTALL --disable-threads --disable-nls --disable-shared \
+   --enable-languages=c,c++ --host=sparcv9-sun-solaris2.8
+ % gmake all-gcc
  % setenv LLVM_LIB_SEARCH_PATH `pwd`/gcc 
- % gmake all; gmake install
+ % gmake all
+</pre>
+
+<p>
+At this point, libstdc++ may fail to build because of wchar errors (look for
+errors that reference <tt>vfwscanf</tt> or <tt>wcstof</tt>).  If that happens,
+edit <tt>sparcv9-sun-solaris2.8/libstdc++-v3/config.h</tt> and comment out the
+line that defines <tt>_GLIBCXX_USE_WCHAR_T</tt>.
+</p>
+
+<p>
+Then, continue as below:
+</p>
+
+<pre>
+ % gmake all
+ % gmake install
 </pre>
 
  <p><b>Common Problem:</b> You may get error messages regarding the fact
@@ -160,13 +142,13 @@ functions from C as referenced from C++, so we typically configure with
   <li><p><b>Fix 1:</b> If you have system header files that include
    inline assembly, you may have to modify them to remove the inline
    assembly, and install the modified versions in
-   <code>$CFEINSTALL/<i>target-triplet</i>/sys-include</code>.</li>
+   <code>$CFEINSTALL/<i>target-triplet</i>/sys-include</code>.</p></li>
 
   <li><b>Fix 2:</b> If you are building the C++ front-end on a CPU we
    haven't tried yet, you will probably have to edit the appropriate
    version of atomicity.h under
    <code>src/libstdc++-v3/config/cpu/<i>name-of-cpu</i>/atomicity.h</code>
-   and apply a patch so that it does not use inline assembly.</li>
+   and apply a patch so that it does not use inline assembly.</p></li>
  </ul>
 
  <p><b>Porting to a new architecture:</b> If you are porting the new front-end
@@ -197,9 +179,11 @@ 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>Go back into the LLVM source tree proper. Edit Makefile.config
+to redefine <code>LLVMGCCDIR</code> to the full pathname of the
+<code>$CFEINSTALL</code> directory, which is the directory you just
+installed the C front-end into. (The ./configure script is likely to
+have set this to a directory which does not exist on your system.)</p></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
@@ -209,14 +193,11 @@ described in "Fix 1" above, you must now copy those header files from
 libgcc.a library, which you can find by running
 <code>$CFEINSTALL/bin/gcc --print-libgcc-file-name</code>.)</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>
+<li><p>Build and install the runtime (bytecode) libraries by running:</p>
 <pre>
- % gmake
+ % gmake -C runtime
  % mkdir $CFEINSTALL/bytecode-libs
- % gmake -C runtime install-bytecode
+ % gmake -C runtime install
  % setenv LLVM_LIB_SEARCH_PATH $CFEINSTALL/bytecode-libs
 </pre></li>
 
@@ -226,7 +207,9 @@ following means:</p>
   <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>
- </ul></li>
+ </ul>
+  </p>
+</li>
 </ol>
 </div>
 
@@ -247,26 +230,6 @@ The software also has the following additional copyrights:
 </p>
 
 <pre>
-
-Copyright (c) 2003, 2004 University of Illinois at Urbana-Champaign.
-All rights reserved.
-
-Developed by:
-
-    LLVM Team
-
-    University of Illinois at Urbana-Champaign
-
-    http://llvm.cs.uiuc.edu
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
-FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL THE
-CONTRIBUTORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS WITH THE
-SOFTWARE.
-
 Copyright (c) 1994
 Hewlett-Packard Company
 
@@ -291,19 +254,16 @@ purpose.  It is provided "as is" without express or implied warranty.
 </pre>
 </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>
-
-  Brian Gaeke<br>
-  <a href="http://llvm.cs.uiuc.edu">LLVM Compiler Infrastructure</a><br>
+<div class="doc_footer">
+  <address>Brian Gaeke</address>
+  <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
+  <br>
   Last modified: $Date$
-</address>
+</div>
 
 </body>
 </html>

llvm/docs/CodeGenerator.html

@@ -1,644 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
-                      "http://www.w3.org/TR/html4/strict.dtd">
-<html>
-<head>
-  <title>The LLVM Target-Independent Code Generator</title>
-  <link rel="stylesheet" href="llvm.css" type="text/css">
-</head>
-<body>
-
-<div class="doc_title">
-  The LLVM Target-Independent Code Generator
-</div>
-
-<ol>
-  <li><a href="#introduction">Introduction</a>
-    <ul>
-      <li><a href="#required">Required components in the code generator</a></li>
-      <li><a href="#high-level-design">The high-level design of the code generator</a></li>
-      <li><a href="#tablegen">Using TableGen for target description</a></li>
-    </ul>
-  </li>
-  <li><a href="#targetdesc">Target description classes</a>
-    <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="#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>
-      <li><a href="#targetjitinfo">The <tt>TargetJITInfo</tt> class</a></li>
-    </ul>
-  </li>
-  <li><a href="#codegendesc">Machine code description classes</a>
-    <ul>
-      <li><a href="#machineinstr">The <tt>MachineInstr</tt> class</a></li>
-    </ul>
-  </li>
-  <li><a href="#codegenalgs">Target-independent code generation algorithms</a>
-  </li>
-  <li><a href="#targetimpls">Target description implementations</a>
-    <ul>
-      <li><a href="#x86">The X86 backend</a></li>
-    </ul>
-  </li>
-
-</ol>
-
-<div class="doc_author">
-  <p>Written by <a href="mailto:sabre@nondot.org">Chris Lattner</a></p>
-</div>
-
-<div class="doc_warning">
-  <p>Warning: This is a work in progress.</p>
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
-  <a name="introduction">Introduction</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>The LLVM target-independent code generator is a framework that provides a
-suite of reusable components for translating the LLVM internal representation to
-the machine code for a specified target -- either in assembly form (suitable for
-a static compiler) or in binary machine code format (usable for a JIT compiler).
-The LLVM target-independent code generator consists of five main components:</p>
-
-<ol>
-<li><a href="#targetdesc">Abstract target description</a> interfaces which
-capture important properties about various aspects of the machine, independently
-of how they will be used.  These interfaces are defined in
-<tt>include/llvm/Target/</tt>.</li>
-
-<li>Classes used to represent the <a href="#codegendesc">machine code</a> being
-generated for a target.  These classes are intended to be abstract enough to
-represent the machine code for <i>any</i> target machine.  These classes are
-defined in <tt>include/llvm/CodeGen/</tt>.</li>
-
-<li><a href="#codegenalgs">Target-independent algorithms</a> used to implement
-various phases of native code generation (register allocation, scheduling, stack
-frame representation, etc).  This code lives in <tt>lib/CodeGen/</tt>.</li>
-
-<li><a href="#targetimpls">Implementations of the abstract target description
-interfaces</a> for particular targets.  These machine descriptions make use of
-the components provided by LLVM, and can optionally provide custom
-target-specific passes, to build complete code generators for a specific target.
-Target descriptions live in <tt>lib/Target/</tt>.</li>
-
-<li><a href="#jit">The target-independent JIT components</a>.  The LLVM JIT is
-completely target independent (it uses the <tt>TargetJITInfo</tt> structure to
-interface for target-specific issues.  The code for the target-independent
-JIT lives in <tt>lib/ExecutionEngine/JIT</tt>.</li>
-
-</ol>
-
-<p>
-Depending on which part of the code generator you are interested in working on,
-different pieces of this will be useful to you.  In any case, you should be
-familiar with the <a href="#targetdesc">target description</a> and <a
-href="#codegendesc">machine code representation</a> classes.  If you want to add
-a backend for a new target, you will need to <a href="#targetimpls">implement the
-target description</a> classes for your new target and understand the <a
-href="LangRef.html">LLVM code representation</a>.  If you are interested in
-implementing a new <a href="#codegenalgs">code generation algorithm</a>, it
-should only depend on the target-description and machine code representation
-classes, ensuring that it is portable.
-</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="required">Required components in the code generator</a>
-</div>
-
-<div class="doc_text">
-
-<p>The two pieces of the LLVM code generator are the high-level interface to the
-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
-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>
-
-<p>This design has two important implications.  The first is that LLVM can
-support completely non-traditional code generation targets.  For example, the C
-backend does not require register allocation, instruction selection, or any of
-the other standard components provided by the system.  As such, it only
-implements these two interfaces, and does its own thing.  Another example of a
-code generator like this is a (purely hypothetical) backend that converts LLVM
-to the GCC RTL form and uses GCC to emit machine code for a target.</p>
-
-<p>This design also implies that it is possible to design and
-implement radically different code generators in the LLVM system that do not
-make use of any of the built-in components.  Doing so is not recommended at all,
-but could be required for radically different targets that do not fit into the
-LLVM machine description model: programmable FPGAs for example.</p>
-
-<p><b>Important Note:</b> For historical reasons, the LLVM SparcV9 code
-generator uses almost entirely different code paths than described in this
-document.  For this reason, there are some deprecated interfaces (such as
-<tt>TargetRegInfo</tt> and <tt>TargetSchedInfo</tt>), which are only used by the
-V9 backend and should not be used by any other targets.  Also, all code in the
-<tt>lib/Target/SparcV9</tt> directory and subdirectories should be considered
-deprecated, and should not be used as the basis for future code generator work.
-The SparcV9 backend is slowly being merged into the rest of the
-target-independent code generators, but this is a low-priority process with no
-predictable completion date.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="high-level-design">The high-level design of the code generator</a>
-</div>
-
-<div class="doc_text">
-
-<p>The LLVM target-indendent 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>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>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>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>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>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>
-
-</ol>
-
-<p>
-The code generator is based on the assumption that the instruction selector will
-use an optimal pattern matching selector to create high-quality sequences of
-native instructions.  Alternative code generator designs based on pattern 
-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 
-compilation.</p>
-
-<p>
-In addition to these stages, target implementations can insert arbitrary
-target-specific passes into the flow.  For example, the X86 target uses a
-special pass to handle the 80x87 floating point stack architecture.  Other
-targets with unusual requirements can be supported with custom passes as needed.
-</p>
-
-</div>
-
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="tablegen">Using TableGen for target description</a>
-</div>
-
-<div class="doc_text">
-
-<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).
-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.
-</p>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
-  <a name="targetdesc">Target description classes</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<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>
-
-<p>All of the target description classes (except the <tt><a
-href="#targetdata">TargetData</a></tt> class) are designed to be subclassed by
-the concrete target implementation, and have virtual methods implemented.  To
-get to these implementations, the <tt><a
-href="#targetmachine">TargetMachine</a></tt> class provides accessors that
-should be implemented by the target.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="targetmachine">The <tt>TargetMachine</tt> class</a>
-</div>
-
-<div class="doc_text">
-
-<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
-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
-code generator components are to be used, the other interfaces should be
-implemented as well.</p>
-
-</div>
-
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="targetdata">The <tt>TargetData</tt> class</a>
-</div>
-
-<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>
-
-</div>
-
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="mregisterinfo">The <tt>MRegisterInfo</tt> class</a>
-</div>
-
-<div class="doc_text">
-
-<p>The <tt>MRegisterInfo</tt> class (which will eventually be renamed to
-<tt>TargetRegisterInfo</tt>) is used to describe the register file of the
-target and any interactions between the registers.</p>
-
-<p>Registers in the code generator are represented in the code generator by
-unsigned numbers.  Physical registers (those that actually exist in the target
-description) are unique small numbers, and virtual registers are generally
-large.</p>
-
-<p>Each register in the processor description has an associated
-<tt>MRegisterDesc</tt> entry, which provides a textual name for the register
-(used for assembly output and debugging dumps), a set of aliases (used to
-indicate that one register overlaps with another), and some flag bits.
-</p>
-
-<p>In addition to the per-register description, the <tt>MRegisterInfo</tt> class
-exposes a set of processor specific register classes (instances of the
-<tt>TargetRegisterClass</tt> class).  Each register class contains sets of
-registers that have the same properties (for example, they are all 32-bit
-integer registers).  Each SSA virtual register created by the instruction
-selector has an associated register class.  When the register allocator runs, it
-replaces virtual registers with a physical register in the set.</p>
-
-<p>
-The target-specific implementations of these classes is auto-generated from a <a
-href="TableGenFundamentals.html">TableGen</a> description of the register file.
-</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="targetinstrinfo">The <tt>TargetInstrInfo</tt> class</a>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="targetframeinfo">The <tt>TargetFrameInfo</tt> class</a>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="targetjitinfo">The <tt>TargetJITInfo</tt> class</a>
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
-  <a name="codegendesc">Machine code description classes</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>
-At the high-level, LLVM code is translated to a machine specific representation
-formed out of MachineFunction, MachineBasicBlock, and <a 
-href="#machineinstr"><tt>MachineInstr</tt></a> instances
-(defined in include/llvm/CodeGen).  This representation is completely target
-agnostic, representing instructions in their most abstract form: an opcode and a
-series of operands.  This representation is designed to support both SSA
-representation for machine code, as well as a register allocated, non-SSA form.
-</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="machineinstr">The <tt>MachineInstr</tt> class</a>
-</div>
-
-<div class="doc_text">
-
-<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>
-
-<p>The opcode number is an 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 
-semantics of the instruction are): for that you must refer to the 
-<tt><a href="#targetinstrinfo">TargetInstrInfo</a></tt> class.</p> 
-
-<p>The operands of a machine instruction can be of several different types:
-they can be a register reference, constant integer, basic block reference, etc.
-In addition, a machine operand should be marked as a def or a use of the value
-(though only registers are allowed to be defs).</p>
-
-<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 
-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>
-
-<pre>
-  %r3 = add %i1, %i2
-</pre>
-
-<p>If the first operand is a def, and it is also easier to <a 
-href="#buildmi">create instructions</a> whose only def is the first 
-operand.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
-  <a name="buildmi">Using the <tt>MachineInstrBuilder.h</tt> functions</a>
-</div>
-
-<div class="doc_text">
-
-<p>Machine instructions are created by using the <tt>BuildMI</tt> functions,
-located in the <tt>include/llvm/CodeGen/MachineInstrBuilder.h</tt> file.  The
-<tt>BuildMI</tt> functions make it easy to build arbitrary machine 
-instructions.  Usage of the <tt>BuildMI</tt> functions look like this: 
-</p>
-
-<pre>
-  // Create a 'DestReg = mov 42' (rendered in X86 assembly as 'mov DestReg, 42')
-  // instruction.  The '1' specifies how many operands will be added.
-  MachineInstr *MI = BuildMI(X86::MOV32ri, 1, DestReg).addImm(42);
-
-  // Create the same instr, but insert it at the end of a basic block.
-  MachineBasicBlock &amp;MBB = ...
-  BuildMI(MBB, X86::MOV32ri, 1, DestReg).addImm(42);
-
-  // Create the same instr, but insert it before a specified iterator point.
-  MachineBasicBlock::iterator MBBI = ...
-  BuildMI(MBB, MBBI, X86::MOV32ri, 1, DestReg).addImm(42);
-
-  // Create a 'cmp Reg, 0' instruction, no destination reg.
-  MI = BuildMI(X86::CMP32ri, 2).addReg(Reg).addImm(0);
-  // Create an 'sahf' instruction which takes no operands and stores nothing.
-  MI = BuildMI(X86::SAHF, 0);
-
-  // Create a self looping branch instruction.
-  BuildMI(MBB, X86::JNE, 1).addMBB(&amp;MBB);
-</pre>
-
-<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.
-</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
-  <a name="fixedregs">Fixed (aka preassigned) registers</a>
-</div>
-
-<div class="doc_text">
-
-<p>One important issue that the code generator needs to be aware of is the
-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 
-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>
-
-<p>For example, consider this simple LLVM example:</p>
-
-<pre>
-  int %test(int %X, int %Y) {
-    %Z = div int %X, %Y
-    ret int %Z
-  }
-</pre>
-
-<p>The X86 instruction selector produces this machine code for the div 
-and ret (use 
-"<tt>llc X.bc -march=x86 -print-machineinstrs</tt>" to get this):</p>
-
-<pre>
-        ;; Start of div
-        %EAX = mov %reg1024           ;; Copy X (in reg1024) into EAX
-        %reg1027 = sar %reg1024, 31
-        %EDX = mov %reg1027           ;; Sign extend X into EDX
-        idiv %reg1025                 ;; Divide by Y (in reg1025)
-        %reg1026 = mov %EAX           ;; Read the result (Z) out of EAX
-
-        ;; Start of ret
-        %EAX = mov %reg1026           ;; 32-bit return value goes in EAX
-        ret
-</pre>
-
-<p>By the end of code generation, the register allocator has coallesced
-the registers and deleted the resultant identity moves, producing the
-following code:</p>
-
-<pre>
-        ;; X is in EAX, Y is in ECX
-        mov %EAX, %EDX
-        sar %EDX, 31
-        idiv %ECX
-        ret 
-</pre>
-
-<p>This approach is extremely general (if it can handle the X86 architecture, 
-it can handle anything!) and allows all of the target specific
-knowledge about the instruction stream to be isolated in the instruction 
-selector.  Note that physical registers should have a short lifetime for good 
-code generation, and all physical registers are assumed dead on entry and
-exit of basic blocks (before register allocation).  Thus if you need a value
-to be live across basic block boundaries, it <em>must</em> live in a virtual 
-register.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
-  <a name="ssa">Machine code SSA form</a>
-</div>
-
-<div class="doc_text">
-
-<p><tt>MachineInstr</tt>'s are initially instruction 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
-single definition.</p>
-
-<p>After register allocation, machine code is no longer in SSA-form, as there 
-are no virtual registers left in the code.</p>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
-  <a name="targetimpls">Target description implementations</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>This section of the document explains any features or design decisions that
-are specific to the code generator for a particular target.</p>
-
-</div>
-
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="x86">The X86 backend</a>
-</div>
-
-<div class="doc_text">
-
-<p>
-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 
-implementations.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
-  <a name="x86_memory">Representing X86 addressing modes in MachineInstrs</a>
-</div>
-
-<div class="doc_text">
-
-<p>
-The x86 has a very, uhm, 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>
-
-<pre>
-   Base+[1,2,4,8]*IndexReg+Disp32
-</pre>
-
-<p>Wow, that's crazy.  In order to represent this, LLVM tracks no less that 4
-operands for each memory operand of this form.  This means that the "load" form
-of 'mov' has the following "Operands" in this order:</p>
-
-<pre>
-Index:        0     |    1        2       3           4
-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>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
-  <a name="x86_names">Instruction naming</a>
-</div>
-
-<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>
-
-<p>
-<tt>ADD8rr</tt> -&gt; add, 8-bit register, 8-bit register<br>
-<tt>IMUL16rmi</tt> -&gt; imul, 16-bit register, 16-bit memory, 16-bit immediate<br>
-<tt>IMUL16rmi8</tt> -&gt; imul, 16-bit register, 16-bit memory, 8-bit immediate<br>
-<tt>MOVSX32rm16</tt> -&gt; movsx, 32-bit register, 16-bit memory
-</p>
-
-</div>
-
-<!-- *********************************************************************** -->
-<hr>
-<address>
-  <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
-  src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a>
-  <a href="http://validator.w3.org/check/referer"><img
-  src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /></a>
-
-  <a href="mailto:sabre@nondot.org">Chris Lattner</a><br>
-  <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a><br>
-  Last modified: $Date$
-</address>
-
-</body>
-</html>

llvm/docs/CodingStandards.html

@@ -28,6 +28,7 @@
         <ol>
           <li><a href="#ci_warningerrors">Treat Compiler Warnings Like
               Errors</a></li>
+          <li><a href="#ci_cpp_features">Which C++ features can I use?</a></li>
           <li><a href="#ci_portable_code">Write Portable Code</a></li>
         </ol></li>
     </ol></li>
@@ -45,17 +46,14 @@
         <ol>
           <li><a href="#hl_assert">Assert Liberally</a></li>
           <li><a href="#hl_preincrement">Prefer Preincrement</a></li>
-          <li><a href="#hl_avoidendl">Avoid std::endl</a></li>
+          <li><a href="#hl_avoidendl">Avoid endl</a></li>
           <li><a href="#hl_exploitcpp">Exploit C++ to its Fullest</a></li>
         </ol></li>
+      <li><a href="#iterators">Writing Iterators</a></li>
     </ol></li>
   <li><a href="#seealso">See Also</a></li>
 </ol>
 
-<div class="doc_author">
-  <p>Written by <a href="mailto:sabre@nondot.org">Chris Lattner</a></p>
-</div>
-
 
 <!-- *********************************************************************** -->
 <div class="doc_section">
@@ -114,7 +112,8 @@ knows they should comment, so should you.  :)  Although we all should probably
 comment our code more than we do, there are a few very critical places that
 documentation is very useful:</p>
 
-<b>File Headers</b>
+<ol>
+<li><h4>File Headers</h4> 
 
 <p>Every source file should have a header on it that
 describes the basic purpose of the file.  If a file does not have a header, it
@@ -122,42 +121,30 @@ should not be checked into CVS.  Most source trees will probably have a standard
 file header format.  The standard format for the LLVM source tree looks like
 this:</p>
 
-<div class="doc_code">
 <pre>
 //===-- llvm/Instruction.h - Instruction class definition -------*- 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 contains the declaration of the Instruction class, which is the
 // base class for all of the VM instructions.
 //
 //===----------------------------------------------------------------------===//
 </pre>
-</div>
 
-<p>A few things to note about this particular format:  The "<tt>-*- C++
+<p>A few things to note about this particular format.  The "<tt>-*- C++
 -*-</tt>" string on the first line is there to tell Emacs that the source file
-is a C++ file, not a C file (Emacs assumes .h files are C files by default).
-Note that this tag is not necessary in .cpp files.  The name of the file is also
-on the first line, along with a very short description of the purpose of the
-file.  This is important when printing out code and flipping though lots of
-pages.</p>
-
-<p>The next section in the file is a concise note that defines the license that
-the file is released under.  This makes it perfectly clear what terms the source
-code can be distributed under.</p>
+is a C++ file, not a C file (Emacs assumes .h files are C files by default [Note
+that tag this is not necessary in .cpp files]).  The name of the file is also on
+the first line, along with a very short description of the purpose of the file.
+This is important when printing out code and flipping though lots of pages.</p>
 
 <p>The main body of the description does not have to be very long in most cases.
 Here it's only two lines.  If an algorithm is being implemented or something
 tricky is going on, a reference to the paper where it is published should be
 included, as well as any notes or "gotchas" in the code to watch out for.</p>
 
-<b>Class overviews</b>
+</li>
+
+<li><h4>Class overviews</h4>
 
 <p>Classes are one fundemental part of a good object oriented design.  As such,
 a class definition should have a comment block that explains what the class is
@@ -165,8 +152,9 @@ used for... if it's not obvious.  If it's so completely obvious your grandma
 could figure it out, it's probably safe to leave it out.  Naming classes
 something sane goes a long ways towards avoiding writing documentation. :)</p>
 
+</li>
 
-<b>Method information</b>
+<li><h4>Method information</h4>
 
 <p>Methods defined in a class (as well as any global functions) should also be
 documented properly.  A quick note about what it does any a description of the
@@ -178,6 +166,9 @@ the goal metric.</p>
 <p>Good things to talk about here are what happens when something unexpected
 happens: does the method return null?  Abort?  Format your hard disk?</p>
 
+</li>
+</ol>
+
 </div>
 
 <!-- _______________________________________________________________________ -->
@@ -213,22 +204,21 @@ These nest properly and are better behaved in general than C style comments.</p>
 
 <p>Immediately after the <a href="#scf_commenting">header file comment</a> (and
 include guards if working on a header file), the <a
-href="#hl_dontinclude">minimal</a> list of <tt>#include</tt>s required by the
-file should be listed.  We prefer these <tt>#include</tt>s to be listed in this
-order:</p>
+href="hl_dontinclude">minimal</a> list of #includes required by the file should
+be listed.  We prefer these #includes to be listed in this order:</p>
 
 <ol>
   <li><a href="#mmheader">Main Module header</a></li>
   <li><a href="#hl_privateheaders">Local/Private Headers</a></li>
-  <li><tt>llvm/*</tt></li>
-  <li><tt>llvm/Analysis/*</tt></li>
-  <li><tt>llvm/Assembly/*</tt></li>
-  <li><tt>llvm/Bytecode/*</tt></li>
-  <li><tt>llvm/CodeGen/*</tt></li>
+  <li>llvm/*</li>
+  <li>llvm/Analysis/*</li>
+  <li>llvm/Assembly/*</li>
+  <li>llvm/Bytecode/*</li>
+  <li>llvm/CodeGen/*</li>
   <li>...</li>
-  <li><tt>Support/*</tt></li>
-  <li><tt>Config/*</tt></li>
-  <li>System <tt>#includes</tt></li>
+  <li>Support/*</li>
+  <li>Config/*</li>
+  <li>System #includes</li>
 </ol>
 
 <p>... and each catagory should be sorted by name.</p>
@@ -318,26 +308,22 @@ a good thorough set of warnings, and stick to them.  At least in the case of
 syntax of the code slightly.  For example, an warning that annoys me occurs when
 I write code like this:</p>
 
-<div class="doc_code">
 <pre>
-if (V = getValue()) {
-  ...
-}
+  if (V = getValue()) {
+    ..
+  }
 </pre>
-</div>
 
 <p><tt>gcc</tt> will warn me that I probably want to use the <tt>==</tt>
 operator, and that I probably mistyped it.  In most cases, I haven't, and I
 really don't want the spurious errors.  To fix this particular problem, I
 rewrite the code like this:</p>
 
-<div class="doc_code">
 <pre>
-if ((V = getValue())) {
-  ...
-}
+  if ((V = getValue())) {
+    ..
+  }
 </pre>
-</div>
 
 <p>...which shuts <tt>gcc</tt> up.  Any <tt>gcc</tt> warning that annoys you can
 be fixed by massaging the code appropriately.</p>
@@ -347,6 +333,40 @@ be fixed by massaging the code appropriately.</p>
 
 </div>
 
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+  <a name="ci_cpp_features">Which C++ features can I use?</a>
+</div>
+
+<div class="doc_text">
+
+<p>Compilers are finally catching up to the C++ standard.  Most compilers
+implement most features, so you can use just about any features that you would
+like.  In the LLVM source tree, I have chosen to not use these features:</p>
+
+<ol>
+<li><p>Exceptions: Exceptions are very useful for error reporting and handling
+exceptional conditions.  I do not use them in LLVM because they do have an
+associated performance impact (by restricting restructuring of code), and parts
+of LLVM are designed for performance critical purposes.</p>
+
+<p>Just like most of the rules in this document, this isn't a hard and fast
+requirement.  Exceptions are used in the Parser, because it simplifies error
+reporting <b>significantly</b>, and the LLVM parser is not at all in the
+critical path.</p>
+</li>
+
+<li>RTTI: RTTI has a large cost in terms of executable size, and compilers are
+not yet very good at stomping out "dead" class information blocks.  Because of
+this, typeinfo and dynamic cast are not used.</li>
+</ol>
+
+<p>Other features, such as templates (without partial specialization) can be
+used freely.  The general goal is to have clear, consise, performant code... if
+a technique assists with that then use it.</p>
+
+</div>
+
 <!-- _______________________________________________________________________ -->
 <div class="doc_subsubsection">
   <a name="ci_portable_code">Write Portable Code</a>
@@ -460,7 +480,7 @@ class itself... just make them private (or protected), and all is well.</p>
 </div>
 
 <!-- ======================================================================= -->
-<div class="doc_subsection">
+<div class="doc_text">
   <a name="micro">The Low Level Issues</a>
 </div>
 
@@ -484,30 +504,26 @@ in the assertion statement (which is printed if the assertion is tripped). This
 helps the poor debugging make sense of why an assertion is being made and
 enforced, and hopefully what to do about it.  Here is one complete example:</p>
 
-<div class="doc_code">
 <pre>
-inline Value *getOperand(unsigned i) { 
-  assert(i &lt; Operands.size() &amp;&amp; "getOperand() out of range!");
-  return Operands[i]; 
-}
+  inline Value *getOperand(unsigned i) { 
+    assert(i &lt; Operands.size() &amp;&amp; "getOperand() out of range!");
+    return Operands[i]; 
+  }
 </pre>
-</div>
 
 <p>Here are some examples:</p>
 
-<div class="doc_code">
 <pre>
-assert(Ty-&gt;isPointerType() &amp;&amp; "Can't allocate a non pointer type!");
+  assert(Ty-&gt;isPointerType() &amp;&amp; "Can't allocate a non pointer type!");
 
-assert((Opcode == Shl || Opcode == Shr) &amp;&amp; "ShiftInst Opcode invalid!");
+  assert((Opcode == Shl || Opcode == Shr) &amp;&amp; "ShiftInst Opcode invalid!");
 
-assert(idx &lt; getNumSuccessors() &amp;&amp; "Successor # out of range!");
+  assert(idx &lt; getNumSuccessors() &amp;&amp; "Successor # out of range!");
 
-assert(V1.getType() == V2.getType() &amp;&amp; "Constant types must be identical!");
+  assert(V1.getType() == V2.getType() &amp;&amp; "Constant types must be identical!");
 
-assert(isa&lt;PHINode&gt;(Succ-&gt;front()) &amp;&amp; "Only works on PHId BBs!");
+  assert(isa&lt;PHINode&gt;(Succ-&gt;front()) &amp;&amp; "Only works on PHId BBs!");
 </pre>
-</div>
 
 <p>You get the idea...</p>
 
@@ -521,9 +537,9 @@ assert(isa&lt;PHINode&gt;(Succ-&gt;front()) &amp;&amp; "Only works on PHId BBs!"
 
 <div class="doc_text">
 
-<p>Hard fast rule: Preincrement (<tt>++X</tt>) may be no slower than
-postincrement (<tt>X++</tt>) and could very well be a lot faster than it.  Use
-preincrementation whenever possible.</p>
+<p>Hard fast rule: Preincrement (++X) may be no slower than postincrement (X++)
+and could very well be a lot faster than it.  Use preincrementation whenever
+possible.</p>
 
 <p>The semantics of postincrement include making a copy of the value being
 incremented, returning it, and then preincrementing the "work value".  For
@@ -534,26 +550,25 @@ get in the habit of always using preincrement, and you won't have a problem.</p>
 
 </div>
 
+
 <!-- _______________________________________________________________________ -->
 <div class="doc_subsubsection">
-  <a name="hl_avoidendl">Avoid std::endl</a>
+  <a name="hl_avoidendl">Avoid endl</a>
 </div>
 
 <div class="doc_text">
 
-<p>The <tt>std::endl</tt> modifier, when used with iostreams outputs a newline
-to the output stream specified.  In addition to doing this, however, it also
-flushes the output stream.  In other words, these are equivalent:</p>
+<p>The <tt>endl</tt> modifier, when used with iostreams outputs a newline to the
+output stream specified.  In addition to doing this, however, it also flushes
+the output stream.  In other words, these are equivalent:</p>
 
-<div class="doc_code">
 <pre>
-std::cout &lt;&lt; std::endl;
-std::cout &lt;&lt; '\n' &lt;&lt; std::flush;
+  cout &lt;&lt; endl;
+  cout &lt;&lt; "\n" &lt;&lt; flush;
 </pre>
-</div>
 
 <p>Most of the time, you probably have no reason to flush the output stream, so
-it's better to use a literal <tt>'\n'</tt>.</p>
+it's better to use a literal <tt>"\n"</tt>.</p>
 
 </div>
 
@@ -564,11 +579,11 @@ it's better to use a literal <tt>'\n'</tt>.</p>
 
 <div class="doc_text">
 
-<p>C++ is a powerful language.  With a firm grasp on its capabilities, you can
-make write effective, consise, readable and maintainable code all at the same
-time.  By staying consistent, you reduce the amount of special cases that need
-to be remembered.  Reducing the total number of lines of code you write is a
-good way to avoid documentation, and avoid giving bugs a place to hide.</p>
+<p>C++ is a powerful language.  With a firm grasp on its capabilities, you can make
+write effective, consise, readable and maintainable code all at the same time.
+By staying consistent, you reduce the amount of special cases that need to be
+remembered.  Reducing the total number of lines of code you write is a good way
+to avoid documentation, and avoid giving bugs a place to hide.</p>
 
 <p>For these reasons, come to know and love the contents of your local
 &lt;algorithm&gt; header file.  Know about &lt;functional&gt; and what it can do
@@ -576,6 +591,331 @@ for you.  C++ is just a tool that wants you to master it. :)</p>
 
 </div>
 
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+  <a name="iterators">Writing Iterators</a>
+</div>
+
+<div class="doc_text">
+
+<p>Here's a pretty good summary of how to write your own data structure iterators
+in a way that is compatible with the STL, and with a lot of other code out there
+(slightly edited by Chris):</p>
+
+<pre>
+From: Ross Smith &lt;ross.s@ihug.co.nz&gt;
+Newsgroups: comp.lang.c++.moderated
+Subject: Writing iterators (was: Re: Non-template functions that take iterators)
+Date: 28 Jun 2001 12:07:10 -0400
+
+Andre Majorel wrote:
+&gt; Any pointers handy on "writing STL-compatible iterators for
+&gt; dummies ?"
+
+I'll give it a try...
+
+The usual situation requiring user-defined iterators is that you have
+a type that bears some resemblance to an STL container, and you want
+to provide iterators so it can be used with STL algorithms. You need
+to ask three questions:
+
+First, is this simply a wrapper for an underlying collection of
+objects that's held somewhere as a real STL container, or is it a
+"virtual container" for which iteration is (under the hood) more
+complicated than simply incrementing some underlying iterator (or
+pointer or index or whatever)? In the former case you can frequently
+get away with making your container's iterators simply typedefs for
+those of the underlying container; your begin() function would call
+member_container.begin(), and so on.
+
+Second, do you only need read-only iterators, or do you need separate
+read-only (const) and read-write (non-const) iterators?
+
+Third, which kind of iterator (input, output, forward, bidirectional,
+or random access) is appropriate? If you're familiar with the
+properties of the iterator types (if not, visit
+<a href="http://www.sgi.com/tech/stl/">http://www.sgi.com/tech/stl/</a>), the appropriate choice should be
+obvious from the semantics of the container.
+
+I'll start with forward iterators, as the simplest case that's likely
+to come up in normal code. Input and output iterators have some odd
+properties and rarely need to be implemented in user code; I'll leave
+them out of discussion. Bidirectional and random access iterators are
+covered below.
+
+The exact behaviour of a forward iterator is spelled out in the
+Standard in terms of a set of expressions with specified behaviour,
+rather than a set of member functions, which leaves some leeway in how
+you actually implement it. Typically it looks something like this
+(I'll start with the const-iterator-only situation):
+
+  #include &lt;iterator&gt;
+
+  class container {
+    public:
+      typedef something_or_other value_type;
+      class const_iterator:
+        public std::iterator&lt;std::forward_iterator_tag, value_type&gt; {
+          friend class container;
+          public:
+            const value_type&amp; operator*() const;
+            const value_type* operator-&gt;() const;
+            const_iterator&amp; operator++();
+            const_iterator operator++(int);
+            friend bool operator==(const_iterator lhs,
+                                   const_iterator rhs);
+            friend bool operator!=(const_iterator lhs,
+                                   const_iterator rhs);
+          private:
+            //...
+        };
+      //...
+  };
+
+An iterator should always be derived from an instantiation of the
+std::iterator template. The iterator's life cycle functions
+(constructors, destructor, and assignment operator) aren't declared
+here; in most cases the compiler-generated ones are sufficient. The
+container needs to be a friend of the iterator so that the container's
+begin() and end() functions can fill in the iterator's private members
+with the appropriate values.
+
+<i>[Chris's Note: I prefer to not make my iterators friends.  Instead, two
+ctor's are provided for the iterator class: one to start at the end of the
+container, and one at the beginning.  Typically this is done by providing
+two constructors with different signatures.]</i>
+
+There are normally only three member functions that need nontrivial
+implementations; the rest are just boilerplate.
+
+  const container::value_type&amp;
+    container::const_iterator::operator*() const {
+      // find the element and return a reference to it
+    }
+
+  const container::value_type*
+    container::const_iterator::operator-&gt;() const {
+      return &amp;**this;
+    }
+
+If there's an underlying real container, operator*() can just return a
+reference to the appropriate element. If there's no actual container
+and the elements need to be generated on the fly -- what I think of as
+a "virtual container" -- things get a bit more complicated; you'll
+probably need to give the iterator a value_type member object, and
+fill it in when you need to. This might be done as part of the
+increment operator (below), or if the operation is nontrivial, you
+might choose the "lazy" approach and only generate the actual value
+when one of the dereferencing operators is called.
+
+The operator-&gt;() function is just boilerplate around a call to
+operator*().
+
+  container::const_iterator&amp;
+    container::const_iterator::operator++() {
+      // the incrementing logic goes here
+      return *this;
+    }
+
+  container::const_iterator
+    container::const_iterator::operator++(int) {
+      const_iterator old(*this);
+      ++*this;
+      return old;
+    }
+
+Again, the incrementing logic will usually be trivial if there's a
+real container involved, more complicated if you're working with a
+virtual container. In particular, watch out for what happens when you
+increment past the last valid item -- this needs to produce an
+iterator that will compare equal to container.end(), and making this
+work is often nontrivial for virtual containers.
+
+The post-increment function is just boilerplate again (and
+incidentally makes it obvious why all the experts recommend using
+pre-increment wherever possible).
+
+  bool operator==(container::const_iterator lhs,
+                  container::const_iterator rhs) {
+    // equality comparison goes here
+  }
+
+  bool operator!=(container::const_iterator lhs,
+                  container::const_iterator rhs) {
+    return !(lhs == rhs);
+  }
+
+For a real container, the equality comparison will usually just
+compare the underlying iterators (or pointers or indices or whatever).
+The semantics of comparisons for virtual container iterators are often
+tricky. Remember that iterator comparison only needs to be defined for
+iterators into the same container, so you can often simplify things by
+taking for granted that lhs and rhs both point into the same container
+object. Again, the second function is just boilerplate.
+
+It's a matter of taste whether iterator arguments are passed by value
+or reference; I've shown tham passed by value to reduce clutter, but
+if the iterator contains several data members, passing by reference
+may be better.
+
+That convers the const-iterator-only situation. When we need separate
+const and mutable iterators, one small complication is added beyond
+the simple addition of a second class.
+
+  class container {
+    public:
+      typedef something_or_other value_type;
+      class const_iterator;
+      class iterator:
+        public std::iterator&lt;std::forward_iterator_tag, value_type&gt; {
+          friend class container;
+          friend class container::const_iterator;
+          public:
+            value_type&amp; operator*() const;
+            value_type* operator-&gt;() const;
+            iterator&amp; operator++();
+            iterator operator++(int);
+            friend bool operator==(iterator lhs, iterator rhs);
+            friend bool operator!=(iterator lhs, iterator rhs);
+          private:
+            //...
+        };
+      class const_iterator:
+        public std::iterator&lt;std::forward_iterator_tag, value_type&gt; {
+          friend class container;
+          public:
+            const_iterator();
+            const_iterator(const iterator&amp; i);
+            const value_type&amp; operator*() const;
+            const value_type* operator-&gt;() const;
+            const_iterator&amp; operator++();
+            const_iterator operator++(int);
+            friend bool operator==(const_iterator lhs,
+                                   const_iterator rhs);
+            friend bool operator!=(const_iterator lhs,
+                                   const_iterator rhs);
+          private:
+            //...
+        };
+      //...
+  };
+
+There needs to be a conversion from iterator to const_iterator (so
+that mixed-type operations, such as comparison between an iterator and
+a const_iterator, will work). This is done here by giving
+const_iterator a conversion constructor from iterator (equivalently,
+we could have given iterator an operator const_iterator()), which
+requires const_iterator to be a friend of iterator, so it can copy its
+data members. (It also requires the addition of an explicit default
+constructor to const_iterator, since the existence of another
+user-defined constructor inhibits the compiler-defined one.)
+
+Bidirectional iterators add just two member functions to forward
+iterators:
+
+  class iterator:
+    public std::iterator&lt;std::bidirectional_iterator_tag, value_type&gt; {
+      public:
+        //...
+        iterator&amp; operator--();
+        iterator operator--(int);
+        //...
+    };
+
+I won't detail the implementations, they're obvious variations on
+operator++().
+
+Random access iterators add several more member and friend functions:
+
+  class iterator:
+    public std::iterator&lt;std::random_access_iterator_tag, value_type&gt; {
+      public:
+        //...
+        iterator&amp; operator+=(difference_type rhs);
+        iterator&amp; operator-=(difference_type rhs);
+        friend iterator operator+(iterator lhs, difference_type rhs);
+        friend iterator operator+(difference_type lhs, iterator rhs);
+        friend iterator operator-(iterator lhs, difference_type rhs);
+        friend difference_type operator-(iterator lhs, iterator rhs);
+        friend bool operator&lt;(iterator lhs, iterator rhs);
+        friend bool operator&gt;(iterator lhs, iterator rhs);
+        friend bool operator&lt;=(iterator lhs, iterator rhs);
+        friend bool operator&gt;=(iterator lhs, iterator rhs);
+        //...
+    };
+
+  container::iterator&amp;
+    container::iterator::operator+=(container::difference_type rhs) {
+      // add rhs to iterator position
+      return *this;
+    }
+
+  container::iterator&amp;
+    container::iterator::operator-=(container::difference_type rhs) {
+      // subtract rhs from iterator position
+      return *this;
+    }
+
+  container::iterator operator+(container::iterator lhs,
+                                container::difference_type rhs) {
+    return iterator(lhs) += rhs;
+  }
+
+  container::iterator operator+(container::difference_type lhs,
+                                container::iterator rhs) {
+    return iterator(rhs) += lhs;
+  }
+
+  container::iterator operator-(container::iterator lhs,
+                                container::difference_type rhs) {
+    return iterator(lhs) -= rhs;
+  }
+
+  container::difference_type operator-(container::iterator lhs,
+                                       container::iterator rhs) {
+    // calculate distance between iterators
+  }
+
+  bool operator&lt;(container::iterator lhs, container::iterator rhs) {
+    // perform less-than comparison
+  }
+
+  bool operator&gt;(container::iterator lhs, container::iterator rhs) {
+    return rhs &lt; lhs;
+  }
+
+  bool operator&lt;=(container::iterator lhs, container::iterator rhs) {
+    return !(rhs &lt; lhs);
+  }
+
+  bool operator&gt;=(container::iterator lhs, container::iterator rhs) {
+    return !(lhs &lt; rhs);
+  }
+
+Four of the functions (operator+=(), operator-=(), the second
+operator-(), and operator&lt;()) are nontrivial; the rest are
+boilerplate.
+
+One feature of the above code that some experts may disapprove of is
+the declaration of all the free functions as friends, when in fact
+only a few of them need direct access to the iterator's private data.
+I originally got into the habit of doing this simply to keep the
+declarations together; declaring some functions inside the class and
+some outside seemed awkward. Since then, though, I've been told that
+there's a subtle difference in the way name lookup works for functions
+declared inside a class (as friends) and outside, so keeping them
+together in the class is probably a good idea for practical as well as
+aesthetic reasons.
+
+I hope all this is some help to anyone who needs to write their own
+STL-like containers and iterators.
+
+-- 
+Ross Smith &lt;ross.s@ihug.co.nz&gt; The Internet Group, Auckland, New Zealand
+</pre>
+
+</div>
+
 <!-- *********************************************************************** -->
 <div class="doc_section">
   <a name="seealso">See Also</a>
@@ -589,12 +929,10 @@ sources.  Two particularly important books for our work are:</p>
 
 <ol>
 
-<li><a href="http://www.aw-bc.com/catalog/academic/product/0,1144,0201310155,00.html">Effective
+<li><a href="http://www.aw.com/product/0,2627,0201924889,00.html">Effective
 C++</a> by Scott Meyers.  There is an online version of the book (only some
 chapters though) <a
-href="http://www.awlonline.com/cseng/meyerscddemo/">available as well</a>.  Also
-interesting and useful are "More Effective C++" and "Effective STL" by the same
-author.</li>
+href="http://www.awlonline.com/cseng/meyerscddemo/">available as well</a>.</li>
 
 <li><a href="http://cseng.aw.com/book/0,3828,0201633620,00.html">Large-Scale C++
 Software Design</a> by John Lakos</li>
@@ -609,16 +947,13 @@ something. :)</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>
 
-  <a href="mailto:sabre@nondot.org">Chris Lattner</a><br>
-  <a href="http://llvm.cs.uiuc.edu">LLVM Compiler Infrastructure</a><br>
+<div class="doc_footer">
+  <address><a href="mailto:sabre@nondot.org">Chris Lattner</a></address>
+  <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
+  <br>
   Last modified: $Date$
-</address>
+</div>
 
 </body>
 </html>

llvm/docs/CommandGuide/Makefile

@@ -1,23 +0,0 @@
-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=$@
-
-man/man1/%.1: %.pod
-	pod2man --release=1.3 --center="LLVM Command Guide" $< $@
-
-ps/%.ps: man/man1/%.1
-	groff -Tps -man $< > $@
-
-clean:
-	rm -f pod2htm*.*~~ $(HTML) $(MAN) $(PS)
-

llvm/docs/CommandGuide/analyze.html

@@ -0,0 +1,81 @@
+<html>
+<title>
+LLVM: analyze tool
+</title>
+
+<body bgcolor=white>
+
+<center><h1>LLVM: <tt>analyze</tt> tool</h1></center>
+<HR>
+
+<h3>NAME</h3>
+<tt>analyze</tt>
+
+<h3>SYNOPSIS</h3>
+<tt>analyze [options] [filename]</tt>
+
+<h3>DESCRIPTION</h3>
+
+The <tt>analyze</tt> command performs various analysis of LLVM assembly code or
+bytecode.  It will usually print the results on standard output, but in a few
+cases, it will print output to standard error or generate a file with the
+analysis output (which is usually done when the output is meant for another
+program).
+<p>
+If filename is omitted or is -, <tt>analyze</tt> reads its input from standard
+input.  It first attempts to interpret its input as LLVM bytecode.  If it
+encounters an error, it then attempts to parse the input as LLVM assembly
+language.
+
+<h3>OPTIONS</h3>
+
+<ul>
+	<li> -help
+	<br>
+	Print a summary of command line options.
+	<p>
+
+	<li> -stats
+	<br>
+	Print statistics.
+	<p>
+
+	<li> -time-passes
+	<br>
+	Record the amount of time needed for each pass and print it to standard
+	error.
+	<p>
+
+	<li> -q
+	<br>
+	Quiet mode.  With this option, analysis pass names are not printed.
+	<p>
+
+	<li> -load &lt;plugin.so&gt;
+	<br>
+	Load the specified dynamic object with name plugin.so.  This file
+	should contain additional analysis passes that register themselves with
+	the <tt>analyze</tt> program after being loaded.
+	<p>
+
+	After being loaded, additional command line options are made available
+	for running the passes made available by plugin.so.  Use
+	'<tt><tt>analyze</tt> -load &lt;plugin.so&gt; -help</tt>' to see the new
+	list of available analysis passes.
+	<p>
+</ul>
+
+<h3>EXIT STATUS</h3>
+
+If <tt>analyze</tt> succeeds, it will exit with 0.  Otherwise, if an error
+occurs, it will exit with a non-zero value.
+
+<h3>SEE ALSO</h3>
+
+<a href="opt.html"><tt>opt</tt></a>
+
+<HR>
+Maintained by the <a href="http://llvm.cs.uiuc.edu">LLVM Team</a>.
+</body>
+</html>
+

llvm/docs/CommandGuide/analyze.pod

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

llvm/docs/CommandGuide/bugpoint.html

@@ -12,15 +12,15 @@
 <h3>SYNOPSIS</h3>
 <tt>bugpoint [options] [input LLVM ll/bc files] [LLVM passes] --args &lt;program arguments&gt;...</tt>
 
-<img src="img/Debugging.gif" width=444 height=314 align=right>
+<img src="../Debugging.gif" width=444 height=314 align=right>
 <h3>DESCRIPTION</h3>
 
 The <tt>bugpoint</tt> tool narrows down the source of
 problems in LLVM tools and passes.  It can be used to debug three types of
-failures: optimizer crashes, miscompilations by optimizers, or bad native
-code generation (including problems in the static and JIT compilers).  It aims 
-to reduce large test cases to small, useful ones.  For example,
-if <tt><a href="CommandGuide/gccas.html">gccas</a></tt> crashes while optimizing a file, it
+failures: optimizer crashes, miscompilations by optimizers, or invalid native
+code generation.  It aims to reduce large test cases to small, useful ones. 
+For example,
+if <tt><a href="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>
 
@@ -30,13 +30,11 @@ 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
 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
+of this, it may appear to do a lot of stupid things or miss obvious
 simplifications.  <tt>bugpoint</tt> 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 <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>
+is still worth it. :-) <p>
 
 <a name="automaticdebuggerselection">
 <h4>Automatic Debugger Selection</h4>
@@ -45,62 +43,67 @@ executing it) takes a long time.<p>
 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),
+any of the passes crash, or if they produce malformed output,
 <tt>bugpoint</tt> starts the <a href="#crashdebug">crash debugger</a>.<p>
 
 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
+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>
+executing it
+with the <a href="#opt_run-">selected</a> code generator.  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>
 
-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>
+Otherwise, <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>
 
 <a name="crashdebug">
 <h4>Crash debugger</h4>
 
-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>
+If an optimizer crashes, <tt>bugpoint</tt> will try as hard as it can to
+reduce the list of passes and the size of the test program.  First,
+<tt>bugpoint</tt> figures out which combination of passes triggers the bug. This
+is useful when debugging a problem exposed by <tt>gccas</tt>, for example,
+because it runs over 25 optimizations.<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
+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,
 <tt>bugpoint</tt> deletes any individual LLVM instructions whose absence does
 not eliminate the failure.  At the end, <tt>bugpoint</tt> should tell you what
 passes crash, give you a bytecode file, and give you instructions on how to
-reproduce the failure with <tt><a href="CommandGuide/opt.html">opt</a></tt>, <tt><a
-href="CommandGuide/analyze.html">analyze</a></tt>, or <tt><a href="CommandGuide/llc.html">llc</a></tt>.<p>
+reproduce the failure with <tt><a href="opt.html">opt</a></tt> or
+<tt><a href="analyze.html">analyze</a></tt>.<p>
 
 <a name="codegendebug">
 <h4>Code generator debugger</h4>
 
-<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
+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>
+"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>
+
+If you are using the code generator debugger and get an error message that
+says "UNSUPPORTED: external function used as a global initializer!", try using
+the <tt>-run-llc</tt> option instead of the <tt>-run-jit</tt> option.  This is
+due to an unimplemented feature in the code generator debugger.<p>
 
 <a name="miscompilationdebug">
 <h4>Miscompilation debugger</h4>
@@ -123,7 +126,7 @@ 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
+    outputs 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.
@@ -145,23 +148,18 @@ non-obvious ways.  Here are some hints and tips:<p>
     <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><tt>bugpoint</tt> cannot debug problems with the LLVM linker. If
+<li><tt>bugpoint</tt> cannot debug problems with the linker. If
     <tt>bugpoint</tt> crashes before you see its "All input ok" message,
     you might try <tt>llvm-link -v</tt> on the same set of input files. If
     that also crashes, you may be experiencing a linker bug.
-
-<li>If your program is <b>supposed</b> to crash, <tt>bugpoint</tt> will be
-    confused. One way to deal with this is to cause bugpoint to ignore the exit
-    code from your program, by giving it the <tt>-check-exit-code=false</tt>
-    option.
     
 </ol>
 
 <h3>OPTIONS</h3>
 
 <ul>
-	<li><tt>-additional-so &lt;library&gt;</tt><br>
-    Load <tt>&lt;library&gt;</tt> into the test program whenever it is run.
+	<li><tt>-additional-so &lt;library.so&gt;</tt><br>
+    Load <tt>&lt;library.so&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>
 
@@ -177,23 +175,7 @@ non-obvious ways.  Here are some hints and tips:<p>
         part of the <tt>-args</tt> option, not as options to <tt>bugpoint</tt>
         itself.<p>
 
-	<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>
-
-	<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>
+	<li><tt>-disable-{adce,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
@@ -207,14 +189,14 @@ non-obvious ways.  Here are some hints and tips:<p>
     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>
+	<a name="opt_load"><li> <tt>-load &lt;plugin.so&gt;</tt><br>
+	Load the dynamic object <tt>&lt;plugin.so&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>
+	<tt>bugpoint -load &lt;plugin.so&gt; -help</tt>
 	<p>
 
 	<a name="opt_output"><li><tt>-output &lt;filename&gt;</tt><br>
@@ -224,9 +206,6 @@ non-obvious ways.  Here are some hints and tips:<p>
     <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
@@ -239,6 +218,10 @@ non-obvious ways.  Here are some hints and tips:<p>
 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.
 
+<h3>SEE ALSO</h3>
+<a href="opt.html"><tt>opt</tt></a>,
+<a href="analyze.html"><tt>analyze</tt></a>
+
 <HR>
 Maintained by the <a href="http://llvm.cs.uiuc.edu">LLVM Team</a>.
 </body>

llvm/docs/CommandGuide/bugpoint.pod

@@ -1,249 +0,0 @@
-=pod
-
-=head1 NAME
-
-bugpoint - automatic test case reduction tool
-
-=head1 SYNOPSIS
-
-B<bugpoint> [I<options>] [I<input LLVM ll/bc files>] [I<LLVM passes>] B<--args>
-I<program arguments>
-
-=head1 DESCRIPTION
-
-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
-
-=head1 OPTIONS
-
-=over 
-
-=item B<--additional-so> F<library>
-
-Load the dynamic shared object F<library> 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.
-
-=item B<--args> I<program args>
-
-Pass all arguments specified after -args to the test program whenever it runs.
-Note that if any of the I<program args> start with a '-', you should use:
-
-    bugpoint [bugpoint args] --args -- [program args]
-
-The "--" right after the B<--args> option tells B<bugpoint> to consider any
-options starting with C<-> to be part of the B<--args> option, not as options to
-B<bugpoint> itself.
-
-=item B<--tool-args> I<tool args>
-
-Pass all arguments specified after --tool-args to the LLVM tool under test
-(B<llc>, B<lli>, etc.) whenever it runs.  You should use this option in the
-following way:
-
-    bugpoint [bugpoint args] --tool-args -- [tool args]
-
-The "--" right after the B<--tool-args> option tells B<bugpoint> to consider any
-options starting with C<-> to be part of the B<--tool-args> option, not as
-options to B<bugpoint> itself. (See B<--args>, above.)
-
-=item B<--check-exit-code>=I<{true,false}>
-
-Assume a non-zero exit code or core dump from the test program is a failure.
-Defaults to true.
-
-=item B<--disable-{dce,simplifycfg}>
-
-Do not run the specified passes to clean up and reduce the size of the test
-program. By default, B<bugpoint> uses these passes internally when attempting to
-reduce test programs.  If you're trying to find a bug in one of these passes,
-B<bugpoint> may crash.
-
-=item B<--help>
-
-Print a summary of command line options.
-
-=item B<--input> F<filename>
-
-Open F<filename> and redirect the standard input of the test program, whenever
-it runs, to come from that file.
-
-=item B<--load> F<plugin>
-
-Load the dynamic object F<plugin> into B<bugpoint> 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 B<--help> and B<--load> options together; for example:
-
-    bugpoint --load myNewPass.so --help
-
-=item B<--output> F<filename>
-
-Whenever the test program produces output on its standard output stream, it
-should match the contents of F<filename> (the "reference output"). If you
-do not use this option, B<bugpoint> will attempt to generate a reference output
-by compiling the program with the C backend and running it.
-
-=item B<--profile-info-file> F<filename>
-
-Profile file loaded by B<--profile-loader>.
-
-=item B<--run-{int,jit,llc,cbe}>
-
-Whenever the test program is compiled, B<bugpoint> 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.
-
-=back
-
-=head1 EXIT STATUS
-
-If B<bugpoint> succeeds in finding a problem, it will exit with 0.  Otherwise,
-if an error occurs, it will exit with a non-zero value.
-
-=head1 SEE ALSO
-
-L<opt|opt>, L<analyze|analyze>
-
-=head1 AUTHOR
-
-Maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
-
-=cut

llvm/docs/CommandGuide/extract.html

@@ -0,0 +1,70 @@
+<html>
+<title>
+LLVM: extract tool
+</title>
+
+<body bgcolor=white>
+
+<center>
+<h1>LLVM: <tt>extract</tt> tool</h1>
+</center>
+<HR>
+
+<h3>NAME</h3>
+<tt>extract</tt>
+
+<h3>
+SYNOPSIS
+</h3>
+
+<tt>extract [options] [filename]</tt>
+<h3>
+DESCRIPTION
+</h3>
+
+The <tt>extract</tt> 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.
+<p>
+
+In addition to extracting the bytecode of the specified function,
+<tt>extract</tt> will also remove unreachable global variables, prototypes, and
+unused types.
+<p>
+
+The <tt>extract</tt> command reads its input from standard input if filename is
+omitted or if filename is -.  The output is always written to standard output.
+
+<h3>
+OPTIONS
+</h3>
+
+<ul>
+	<li>-func &lt;function&gt;
+	<br>
+	Extract the specified function from the LLVM bytecode.
+	<p>
+
+	<li> -help
+	<br>
+	Print a summary of command line options.
+	<p>
+</ul>
+
+<h3>
+EXIT STATUS
+</h3>
+
+If <tt>extract</tt> succeeds, it will exit with 0.  Otherwise, if an error
+occurs, it will exit with a non-zero value.
+
+<h3>
+SEE ALSO
+</h3>
+<a href="bugpoint.html"><tt>bugpoint</tt></a>
+
+<HR>
+Maintained by the <a href="http://llvm.cs.uiuc.edu">LLVM Team</a>.
+</body>
+</html>
+

llvm/docs/CommandGuide/extract.pod

@@ -1,72 +0,0 @@
-=pod
-
-=head1 NAME
-
-extract - extract a function from an LLVM module
-
-=head1 SYNOPSIS
-
-B<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 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
-unused types.
-
-The B<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).
-
-=head1 OPTIONS
-
-=over
-
-=item B<-f>
-
-Force overwrite.  Normally, B<extract> will refuse to overwrite an
-output file that already exists.  With this option, B<extract>
-will overwrite the output file and replace it with new bytecode.
-
-=item B<--func> I<function-name>
-
-Extract the function named I<function-name> from the LLVM bytecode.
-
-=item B<--help>
-
-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.
-
-=back
-
-=head1 EXIT STATUS
-
-If B<extract> succeeds, it will exit with 0.  Otherwise, if an error
-occurs, it will exit with a non-zero value.
-
-=head1 SEE ALSO
-
-L<bugpoint|bugpoint>
-
-=head1 AUTHORS
-
-Maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
-
-=cut

llvm/docs/CommandGuide/gccas.html

@@ -0,0 +1,79 @@
+<html>
+<title>LLVM: gccas tool</title>
+
+<body bgcolor=white>
+
+<center>
+<h1>LLVM: <tt>gccas</tt> tool</h1>
+</center>
+<HR>
+
+<h3>NAME</h3>
+<tt>gccas</tt>
+
+<h3>SYNOPSIS</h3>
+<tt>gccas [options] &lt; filename&gt;</tt>
+
+<h3>DESCRIPTION</h3>
+
+The <tt>gccas</tt> utility takes an LLVM assembly file generated by the <a
+href="llvmgcc.html">C</a> or <a href="llvmgxx.html">C++</a> frontends and
+converts it into an LLVM bytecode file.  It is primarily used by the GCC front
+end, and as such, attempts to mimic the interface provided by the default system
+assembler so that it can act as a "drop-in" replacement.<p>
+
+<tt>gccas</tt> performs a number of optimizations on the input program.<p>
+
+<h3>
+OPTIONS
+</h3>
+
+<ul>
+	<li> -help
+	<br>
+	Print a summary of command line options.
+	<p>
+
+	<li> -o &lt;filename&gt;
+	<br>
+	Specify the output filename which will hold the assembled bytecode.
+	<p>
+
+	<li>-disable-inlining
+	<br>
+	Disable the inlining pass.  By default, it is enabled.
+	<p>
+
+	<li> -stats
+	<br>
+	Print statistics.
+	<p>
+
+	<li> -time-passes
+	<br>
+	Record the amount of time needed for each pass and print it to standard
+	error.
+	<p>
+
+	<li> -verify
+	<br>
+	Verify each pass result.
+	<p>
+</ul>
+
+<h3>
+EXIT STATUS
+</h3>
+
+If <tt>gccas</tt> succeeds, it will exit with 0.  Otherwise, if an error occurs,
+it will exit with a non-zero value.
+
+<h3>SEE ALSO</h3>
+<a href="llvm-as.html"><tt>llvm-as</tt></a>
+<a href="gccld.html"><tt>gccld</tt></a>
+
+<HR>
+Maintained by the <a href="http://llvm.cs.uiuc.edu">LLVM Team</a>.
+</body>
+</html>
+

llvm/docs/CommandGuide/gccas.pod

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

llvm/docs/CommandGuide/gccld.html

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

llvm/docs/CommandGuide/gccld.pod

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

llvm/docs/CommandGuide/html/.cvsignore

@@ -1 +0,0 @@
-*html

llvm/docs/CommandGuide/html/manpage.css

@@ -1,256 +0,0 @@
-/* Based on http://www.perldoc.com/css/perldoc.css */
-
-@import url("../llvm.css");
-
-body { font-family: Arial,Helvetica; }
-
-blockquote { margin: 10pt;  }
-
-h1, a { color: #336699; }
-
-
-/*** Top menu style ****/
-.mmenuon { 
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #ff6600; font-size: 10pt;
- }
-.mmenuoff { 
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #ffffff; font-size: 10pt;
-}	  
-.cpyright {
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #ffffff; font-size: xx-small;
-}
-.cpyrightText {
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #ffffff; font-size: xx-small;
-}
-.sections { 
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #336699; font-size: 11pt;
-}	 
-.dsections { 
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #336699; font-size: 12pt;
-}	
-.slink { 
- font-family: Arial,Helvetica; font-weight: normal; text-decoration: none;
- color: #000000; font-size: 9pt;
-}	 
-
-.slink2 { font-family: Arial,Helvetica; text-decoration: none; color: #336699; }	 
-
-.maintitle { 
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #336699; font-size: 18pt;
-}	 
-.dblArrow {
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #336699; font-size: small;
-}
-.menuSec {
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #336699; font-size: small;
-}
-
-.newstext {
- font-family: Arial,Helvetica; font-size: small;
-}
-
-.linkmenu {
- font-family: Arial,Helvetica; color: #000000; font-weight: bold;
- text-decoration: none;
-}
-
-P {
- font-family: Arial,Helvetica;
-}
-
-PRE {
-    font-size: 10pt;
-}
-.quote { 
- font-family: Times; text-decoration: none;
- color: #000000; font-size: 9pt; font-style: italic;
-}	
-.smstd { font-family: Arial,Helvetica; color: #000000; font-size: x-small; } 
-.std { font-family: Arial,Helvetica; color: #000000; } 
-.meerkatTitle { 
- font-family: sans-serif; font-size: x-small;  color: black;    }
-
-.meerkatDescription { font-family: sans-serif; font-size: 10pt; color: black }
-.meerkatCategory { 
- font-family: sans-serif; font-size: 9pt; font-weight: bold; font-style: italic; 
- color: brown; }
-.meerkatChannel { 
- font-family: sans-serif; font-size: 9pt; font-style: italic; color: brown; }
-.meerkatDate { font-family: sans-serif; font-size: xx-small; color: #336699; }
-
-.tocTitle {
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #333333; font-size: 10pt;
-}
-
-.toc-item {
- font-family: Arial,Helvetica; font-weight: bold; 
- color: #336699; font-size: 10pt; text-decoration: underline;
-}
-
-.perlVersion {
- font-family: Arial,Helvetica; font-weight: bold; 
- color: #336699; font-size: 10pt; text-decoration: none;
-}
-
-.podTitle {
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #000000;
-}
-
-.docTitle {
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #000000; font-size: 10pt;
-}
-.dotDot {
- font-family: Arial,Helvetica; font-weight: bold; 
- color: #000000; font-size: 9pt;
-}
-
-.docSec {
- font-family: Arial,Helvetica; font-weight: normal; 
- color: #333333; font-size: 9pt;
-}
-.docVersion {
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #336699; font-size: 10pt;
-}
-
-.docSecs-on {
- font-family: Arial,Helvetica; font-weight: normal; text-decoration: none;
- color: #ff0000; font-size: 10pt;
-}
-.docSecs-off {
- font-family: Arial,Helvetica; font-weight: normal; text-decoration: none;
- color: #333333; font-size: 10pt;
-}
-
-h2 {
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #336699; font-size: medium;
-}
-h1 {
- font-family: Verdana,Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #336699; font-size: large;
-}
-
-DL {
- font-family: Arial,Helvetica; font-weight: normal; text-decoration: none;
- color: #333333; font-size: 10pt;
-}
-
-UL > LI > A {
- font-family: Arial,Helvetica; font-weight: bold;
- color: #336699; font-size: 10pt;
-}
-
-.moduleInfo {
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #333333; font-size: 11pt;
-}
-
-.moduleInfoSec {
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #336699; font-size: 10pt;
-}
-
-.moduleInfoVal {
- font-family: Arial,Helvetica; font-weight: normal; text-decoration: underline;
- color: #000000; font-size: 10pt;
-}
-
-.cpanNavTitle {
- font-family: Arial,Helvetica; font-weight: bold; 
- color: #ffffff; font-size: 10pt;
-}
-.cpanNavLetter {
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; 
- color: #333333; font-size: 9pt;
-}
-.cpanCat {
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; 
- color: #336699; font-size: 9pt;
-}
-
-.bttndrkblue-bkgd-top {
-	background-color: #225688;
-	background-image: url(/global/mvc_objects/images/bttndrkblue_bgtop.gif);
-}
-.bttndrkblue-bkgd-left {
-	background-color: #225688;
-	background-image: url(/global/mvc_objects/images/bttndrkblue_bgleft.gif);
-}
-.bttndrkblue-bkgd {
-	padding-top: 0px;
-	padding-bottom: 0px;
-	margin-bottom: 0px;
-	margin-top: 0px;
-	background-repeat: no-repeat;
-	background-color: #225688;
-	background-image: url(/global/mvc_objects/images/bttndrkblue_bgmiddle.gif);
-	vertical-align: top;
-}
-.bttndrkblue-bkgd-right {
-	background-color: #225688;
-	background-image: url(/global/mvc_objects/images/bttndrkblue_bgright.gif);
-}
-.bttndrkblue-bkgd-bottom {
-	background-color: #225688;
-	background-image: url(/global/mvc_objects/images/bttndrkblue_bgbottom.gif);
-}
-.bttndrkblue-text a {
-	color: #ffffff;
-	text-decoration: none;
-}
-a.bttndrkblue-text:hover {
-	color: #ffDD3C;
-	text-decoration: none;
-}
-.bg-ltblue {
-	background-color: #f0f5fa;
-} 
-
-.border-left-b {
-	background: #f0f5fa url(/i/corner-leftline.gif) repeat-y;
-} 
-
-.border-right-b {
-	background: #f0f5fa url(/i/corner-rightline.gif) repeat-y;
-} 
-
-.border-top-b {
-	background: #f0f5fa url(/i/corner-topline.gif) repeat-x;
-} 
-
-.border-bottom-b {
-	background: #f0f5fa url(/i/corner-botline.gif) repeat-x;
-} 
-
-.border-right-w {
-	background: #ffffff url(/i/corner-rightline.gif) repeat-y;
-} 
-
-.border-top-w {
-	background: #ffffff url(/i/corner-topline.gif) repeat-x;
-} 
-
-.border-bottom-w {
-	background: #ffffff url(/i/corner-botline.gif) repeat-x;
-} 
-
-.bg-white {
-	background-color: #ffffff;
-} 
-
-.border-left-w {
-	background: #ffffff url(/i/corner-leftline.gif) repeat-y;
-} 

llvm/docs/CommandGuide/index.html

@@ -1,135 +1,123 @@
-<!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 Transitional//EN">
 <html>
 <head>
   <title>LLVM Command Guide</title>
-  <link rel="stylesheet" href="../llvm.css" type="text/css">
 </head>
-<body>
 
-<div class="doc_title">
-  LLVM Command Guide
-</div>
+<body bgcolor=white>
 
-<div class="doc_text">
+<center><h1>LLVM Command Guide<br></h1></center>
 
-<p>These documents are HTML versions of the <a href="man/man1/">man pages</a>
-for all of the LLVM tools.  These pages describe how to use the LLVM commands
-and what their options are.  Note that these pages do not describe all of the 
-options available for all tools.  To get a complete listing, pass the 
-<tt>--help</tt> (general options) or <tt>--help-hidden</tt> (general+debugging
-options) arguments to the tool you are interested in.</p>
+This document is the reference manual for the LLVM utilities.  It will
+show you how to use the LLVM commands and what all of their options
+are.
 
-</div>
+<table width=100% border=0>
+<tr><td valign=top width=50%>
 
-<!-- *********************************************************************** -->
-<div class="doc_section">
-  <a name="basic">Basic Commands</a>
-</div>
-<!-- *********************************************************************** -->
+<!--===============================================================-->
+<center><h2><a name="llvmcmds">Basic Commands</a><hr></h2></center>
+<!--===============================================================-->
 
-<div class="doc_text">
+<dl compact>
+	<dt><A href="llvm-as.html"><b>llvm-as</b></A>
+	<dd>
+	Assemble a human-readable LLVM program into LLVM bytecode.
+	<p>
 
-<ul>
+	<dt><A href="llvm-dis.html"><b>llvm-dis</b></A>
+	<dd>
+	Disassemble an LLVM bytecode file into human-readable form.
+	<p>
 
-<li><a href="html/llvm-as.html"><b>llvm-as</b></a> - 
-    assemble a human-readable .ll file into bytecode</li>
+	<dt><A href="analyze.html"><b>analyze</b></A>
+	<dd>
+	Analyze an LLVM bytecode file.
+	<p>
 
-<li><a href="html/llvm-dis.html"><b>llvm-dis</b></a> -
-    disassemble a bytecode file into a human-readable .ll file</li>
+	<dt><A href="opt.html"><b>opt</b></A>
+	<dd>
+	Optimize an LLVM bytecode file.
+	<p>
 
-<li><a href="html/opt.html"><b>opt</b></a> -
-    run a series of LLVM-to-LLVM optimizations on a bytecode file</li>
+	<dt><A href="llc.html"><b>llc</b></A>
+	<dd>
+	Compile an LLVM bytecode program into native machine code.
+        <p>
 
-<li><a href="html/llc.html"><b>llc</b></a> - 
-    generate native machine code for a bytecode file</li>
+	<dt><A href="lli.html"><b>lli</b></A>
+	<dd>
+	Run an LLVM bytecode program using either an interpreter or a
+	JIT compiler.
+	<p>
 
-<li><a href="html/lli.html"><b>lli</b></a> - 
-    directly run a program compiled to bytecode using a JIT compiler or 
-    interpreter</li>
+	<dt><A href="llvm-link.html"><b>llvm-link</b></A>
+	<dd>
+	Link several LLVM bytecode files together into one LLVM
+	bytecode file.
+	<p>
 
-<li><a href="html/llvm-link.html"><b>llvm-link</b></A>
-    link several bytecode files into one</li>
+	<dt><A href="llvm-nm.html"><b>llvm-nm</b></A>
+	<dd>
+	Print out the names and types of symbols in an LLVM bytecode file.
+	<p>
 
-<li><a href="html/analyze.html"><b>analyze</b></a> -
-    run LLVM analyses on a bytecode file and print the results</li>
+	<dt><A href="llvm-prof.html"><b>llvm-prof</b></A>
+	<dd>
+        Transform raw '<tt>llvmprof.out</tt>' data into a human readable report.
+	<p>
+</dl>
 
-<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>
+</td><td valign=top width=50%>
 
-<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>
+<!--===============================================================-->
+<center><h2><a name="llvmcmds">C and C++ Front-end Commands</a><hr></h2></center>
+<!--===============================================================-->
 
-</ul>
+<dl compact>
+	<dt><A href="llvmgcc.html"><b>llvmgcc</b></A>
+	<dd>
+	GCC-based C front end for LLVM.
+	<p>
 
-</div>
+	<dt><A href="llvmgxx.html"><b>llvmg++</b></A>
+	<dd>
+	GCC-based C++ front end for LLVM.
+	<p>
 
-<!-- *********************************************************************** -->
-<div class="doc_section">
-  <a name="frontend">C, C++, and Stacker Front-end Commands</a>
-</div>
-<!-- *********************************************************************** -->
+	<dt><A href="gccas.html"><b>gccas</b></A>
+	<dd>
+	LLVM assembler used by GCC and other native compiler tools.
+	<p>
 
-<div class="doc_text">
-<ul>
+	<dt><A href="gccld.html"><b>gccld</b></A>
+	<dd>
+	LLVM linker used by GCC and other native compiler tools.
+</dl>
 
-<li><a href="html/llvmgcc.html"><b>llvmgcc</b></a> -
-    GCC-based C front-end for LLVM
+<!--===============================================================-->
+<center><h2><a name="llvmcmds">Debugging Tools</a><hr></h2></center>
+<!--===============================================================-->
 
-<li><a href="html/llvmgxx.html"><b>llvmg++</b></a> -
-    GCC-based C++ front-end for LLVM</li>
+<dl compact>
+	<dt><A href="bugpoint.html"><b>bugpoint</b></A>
+	<dd>
+	Trace an LLVM bytecode program and reduce its failure to a
+	simple testcase.
+	<p>
 
-<li><a href="html/gccas.html"><b>gccas</b></a> -
-    compile-time optimizer used by llvm-g++ and llvm-gcc</li>
-
-<li><a href="html/gccld.html"><b>gccld</b></a> -
-    linker and link-time optimizer used by llvm-g++ and llvm-gcc</li>
-
-<li><a href="html/stkrc.html"><b>stkrc</b></a> -
-    front-end compiler for the <a href="../Stacker.html">Stacker</a> 
-    language</li>
-
-</ul>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
-  <a name="debug">Debugging Tools</a>
-</div>
-<!-- *********************************************************************** -->
+	<dt><A href="extract.html"><b>extract</b></A>
+	<dd>
+	Extract a function from an LLVM bytecode file.
+</dl>
+</td></tr></table>
 
 
-<div class="doc_text">
-
-<ul>
-
-<li><a href="html/bugpoint.html"><b>bugpoint</b></a> -
-    automatic test-case reducer</li>
-
-<li><a href="html/extract.html"><b>extract</b></a> -
-    extract a function from an LLVM bytecode file</li>
-
-<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>
-
-</ul>
-
-</div>
-
-<!-- *********************************************************************** -->
-
-<hr>
-<address>
-  <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
-  src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a>
-  <a href="http://validator.w3.org/check/referer"><img
-  src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"></a>
-
-  <a href="http://llvm.cs.uiuc.edu">LLVM Compiler Infrastructure</a><br>
-  Last modified: $Date$
-</address>
+<hr><font size=-1>
+Maintained by the 
+<a href="http://llvm.cs.uiuc.edu">LLVM Team</a>.<br>
+Last modified: $Date$
+</font>
 
 </body>
 </html>

llvm/docs/CommandGuide/llc.html

@@ -0,0 +1,198 @@
+<html>
+<title>LLVM: llc tool</title>
+
+<body bgcolor=white>
+
+<center><h1>LLVM: <tt>llc</tt> tool</h1></center>
+<HR>
+
+<h3>NAME</h3>
+<tt>llc</tt>
+
+<h3>SYNOPSIS</h3>
+<tt>llc [options] [filename]</tt>
+
+<h3>DESCRIPTION</h3>
+
+The <tt>llc</tt> 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.
+<p>
+The choice of architecture for the output assembly code is determined as
+follows:
+
+<ul>
+	<li>
+	If the user has specified an architecture with the -m option, use that
+	architecture.
+	<p>
+
+	<li>
+	Examine the input LLVM bytecode file:
+	<ul>
+		<li>
+		If it specifies little endian and a pointer size of 32 bits, select the
+		x86 architecture.
+		<p>
+		
+		<li>
+		If it specifies big endian and a pointer size of 64 bit pointers,
+		select the SparcV9 architecture.
+	</ul>
+	<p>
+
+	<li>
+	If <tt>llc</tt> was compiled on an architecture for which it can
+	generate code, select the architecture upon which <tt>llc</tt> was
+	compiled.
+	<p>
+
+	<li>
+	Print a message to the user asking him or her to specify the output
+	architecture explicitly.
+</ul>
+
+<p>
+
+If filename is not specified, or if filename is -, <tt>llc</tt> reads its input
+from standard input.  Otherwise, it will read its input from filename.
+<p>
+
+If the -o option is left unspecified, then <tt>llc</tt> will send its output to standard
+output if the input is from standard input.  If the -o option specifies -, then
+the output will also be sent to standard output.
+<p>
+
+If no -o option is specified and an input file other than - is specified, then
+<tt>llc</tt> creates the output filename as follows:
+
+<ul>
+	<li>
+	If the file ends in .bc, then the .bc suffix is removed, and the .s suffix
+	is appended.
+	<p>
+	<li>
+	Otherwise, the .s suffix is appended to the input filename.
+</ul>
+
+<h3>
+OPTIONS
+</h3>
+<ul>
+	<li>-f                   
+	<br>
+	Overwrite output files
+	<p>
+
+	<li>-m&lt;arch&gt;
+	<br>
+	Specify the architecture for which to generate assembly.  Valid
+	architectures are:
+
+	<dl compact>
+		<di> x86
+		<dd>IA-32 (Pentium and above)</dd>
+
+		<di> sparc
+		<dd>SPARC V9</dd>
+	</dl>
+	<p>
+
+	<li>-o &lt;filename&gt;
+	<br>
+	Specify the output filename.
+	<p>
+
+	<li> -help
+	<br>
+	Print a summary of command line options.
+	<p>
+
+	<li> -stats
+	<br>
+	Print statistics.
+	<p>
+
+	<li> -time-passes
+	<br>
+	Record the amount of time needed for each pass and print it to standard
+	error.
+	<p>
+
+</ul>
+<h4>X86 Specific Options</h4>
+<ul>
+	<li>-disable-fp-elim
+	<br>
+	Disable frame pointer elimination optimization.
+	<p>
+
+	<li>-disable-pattern-isel
+	<br>
+	Use the 'simple' X86 instruction selector (the default).
+	<p>
+
+	<li>-print-machineinstrs
+	<br>
+	Print generated machine code.
+	<p>
+
+	<li>-regalloc=&lt;ra&gt;
+	<br>
+        Specify the register allocator to use. The default is <i>simple</i>.
+        Valid register allocators are:
+	<dl compact>
+		<di> simple
+		<dd>Very simple register allocator</dd>
+
+		<di> local
+		<dd>Local register allocator</dd>
+	</dl>
+	<p>
+
+</ul>
+
+<h4>Sparc Specific Options</h4>
+<ul>
+	<li>-disable-peephole
+	<br>
+	Disable peephole optimization pass.
+	<p>
+
+	<li>-disable-preopt
+	<br>
+	Disable optimizations prior to instruction selection.
+	<p>
+
+	<li>-disable-sched
+	<br>
+	Disable local scheduling pass.
+	<p>
+
+	<li>-disable-strip
+	<br>
+	Do not strip the LLVM bytecode included in executable.
+	<p>
+
+	<li>-enable-maps
+	<br>
+	Emit LLVM-to-MachineCode mapping info to assembly.
+	<p>
+</ul>
+
+
+<h3>EXIT STATUS</h3>
+
+If <tt>llc</tt> succeeds, it will exit with 0.  Otherwise, if an error occurs,
+it will exit with a non-zero value.
+
+<h3>
+SEE ALSO
+</h3>
+<a href="lli.html"><tt>lli</tt></a>
+
+<HR>
+Maintained by the <a href="http://llvm.cs.uiuc.edu">LLVM Team</a>.
+</body>
+</html>
+

llvm/docs/CommandGuide/llc.pod

@@ -1,206 +0,0 @@
-=pod
-
-=head1 NAME
-
-llc - LLVM static compiler
-
-=head1 SYNOPSIS
-
-B<llc> [I<options>] [I<filename>]
-
-=head1 DESCRIPTION
-
-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.
-
-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
-
-=head1 OPTIONS
-
-If I<filename> is - or omitted, B<llc> reads LLVM bytecode from standard input.
-Otherwise, it will read LLVM bytecode from I<filename>.
-
-If the B<-o> option is omitted, then B<llc> will send its output to standard
-output if the input is from standard input.  If the B<-o> option specifies -,
-then the output will also be sent to standard output.
-
-If no B<-o> option is specified and an input file other than - is specified,
-then B<llc> creates the output filename by taking the input filename,
-removing any existing F<.bc> extension, and adding a F<.s> suffix.
-
-Other B<llc> options are as follows:
-
-=over
-
-=item B<-f>
-
-Overwrite output files. By default, B<llc> will refuse to overwrite
-an output file which already exists.
-
-=item B<-march>=I<arch>
-
-Specify the architecture for which to generate assembly.  Valid
-architectures are:
-
-=over
-
-=item I<x86>
-
-Intel IA-32 (Pentium and above)
-
-=item I<sparcv9>
-
-64-bit SPARC V9
-
-=item I<c>
-
-Emit C code, not assembly
-
-=back
-
-=item B<-enable-correct-eh-support>
-
-Instruct the B<-lowerinvoke> pass to insert code for correct exception handling
-support.  This is expensive and is by default omitted for efficiency.
-
-=item B<-help>
-
-Print a summary of command line options.
-
-=item B<-stats>
-
-Print statistics recorded by code-generation passes.
-
-=item B<-time-passes>
-
-Record the amount of time needed for each pass and print a report to standard
-error.
-
-=back
-
-=head2 Intel IA-32-specific Options
-
-=over
-
-=item B<--disable-fp-elim>
-
-Disable frame pointer elimination optimization.
-
-=item B<--disable-pattern-isel>
-
-Use the 'simple' X86 instruction selector (the default).
-
-=item B<--print-machineinstrs>
-
-Print generated machine code.
-
-=item B<--regalloc>=I<allocator>
-
-Specify the register allocator to use. The default I<allocator> is I<local>.
-Valid register allocators are:
-
-=over
-
-=item I<simple>
-
-Very simple "always spill" register allocator
-
-=item I<local>
-
-Local register allocator
-
-=item I<linearscan>
-
-Linear scan global register allocator
-
-=item I<iterativescan>
-
-Iterative scan global register allocator
-
-=back
-
-=item B<--spiller>=I<spiller>
-
-Specify the spiller to use for register allocators that support it.  Currently
-this option is used only by the linear scan register allocator. The default
-I<spiller> is I<local>.  Valid spillers are:
-
-=over
-
-=item I<simple>
-
-Simple spiller
-
-=item I<local>
-
-Local spiller
-
-=back
-
-=back
-
-=head2 SPARCV9-specific Options
-
-=over
-
-=item B<--disable-peephole>
-
-Disable peephole optimization pass.
-
-=item B<--disable-sched>
-
-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
-
-If B<llc> succeeds, it will exit with 0.  Otherwise, if an error occurs,
-it will exit with a non-zero value.
-
-=head1 SEE ALSO
-
-L<lli|lli>
-
-=head1 AUTHORS
-
-Maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
-
-=cut

llvm/docs/CommandGuide/lli.html

@@ -0,0 +1,107 @@
+<html>
+<title>
+LLVM: lli tool
+</title>
+
+<body bgcolor=white>
+
+<center>
+<h1>LLVM: <tt>lli</tt> tool</h1>
+</center>
+<HR>
+
+<h3>
+NAME
+</h3>
+
+<tt>lli</tt>
+
+<h3>
+SYNOPSIS
+</h3>
+
+<tt>lli [options] [filename] [args ...]</tt>
+<h3>
+DESCRIPTION
+</h3>
+
+<tt>lli</tt> directly executes programs in LLVM format. 
+It takes a program in LLVM
+bytecode format and executes it using a just-in-time
+compiler, if one is available for the current architecture, or an interpreter.
+<tt>lli</tt> takes all of the same code generator options as the
+<tt><a href="llc.html">llc</a></tt> tool, but they are only applicable when
+the just-in-time compiler is being used.
+<p>
+
+If filename is not specified, then <tt>lli</tt> reads the LLVM bytecode for
+the program from standard input.
+<p>
+The optional "args" specified on the command line are passed to the
+program as arguments.
+<p>
+
+
+<h3>
+OPTIONS
+</h3>
+
+<ul>
+	<li> <tt>-help</tt>
+	<br>
+	Print a summary of command line options.
+	<p>
+
+	<li> <tt>-stats</tt>
+	<br>
+	Print statistics from the code-generation passes. This is only meaningful
+    for the just-in-time compiler, at present.
+	<p>
+
+	<li> <tt>-time-passes</tt>
+	<br>
+	Record the amount of time needed for each code-generation pass and print
+    it to standard error.
+	<p>
+
+	<li> <tt>-march=&lt;arch&gt;</tt>
+	<br>
+    Use the specified non-default architecture when selecting a code generator
+    for the just-in-time compiler. This may result in a crash if you pick an
+    architecture which is not compatible with the hardware you are running
+    <tt>lli</tt> on.
+	<p>
+
+    <li> <tt>-force-interpreter={false,true}</tt>
+    <br>
+    If set to true, use the interpreter even if a just-in-time compiler is
+    available for this architecture. Defaults to false.
+    <p>
+
+    <li> <tt>-f=&lt;name&gt;</tt>
+    <br>
+    Call the function named <tt>&lt;name&gt;</tt> to start the program.
+    Note: The function is assumed to have the C signature <tt>int
+    <tt>&lt;name&gt;</tt> (int, char **, char **)</tt>. 
+    If you try to use this option to call a function of incompatible type,
+    undefined behavior may result. Defaults to "main".
+    <p>
+
+</ul>
+
+<h3>
+EXIT STATUS
+</h3>
+
+If <tt>lli</tt> fails to load the program, it will exit with an exit code of 1.
+Otherwise, it will return the exit code of the program it executes.
+
+<h3>
+SEE ALSO
+</h3>
+<a href="llc.html"><tt>llc</tt></a>
+
+<HR>
+Maintained by the <a href="http://llvm.cs.uiuc.edu">LLVM Team</a>.
+</body>
+</html>

llvm/docs/CommandGuide/lli.pod

@@ -1,76 +0,0 @@
-=pod
-
-=head1 NAME
-
-lli - directly execute programs from LLVM bytecode
-
-=head1 SYNOPSIS
-
-B<lli> [I<options>] [I<filename>] [I<program args>]
-
-=head1 DESCRIPTION
-
-B<lli> directly executes programs in LLVM bytecode format.  It takes a program
-in LLVM bytecode format and executes it using a just-in-time compiler, if one is
-available for the current architecture, or an interpreter.  B<lli> takes all of
-the same code generator options as L<llc|llc>, but they are only effective when
-B<lli> is using the just-in-time compiler.
-
-If I<filename> is not specified, then B<lli> reads the LLVM bytecode for the
-program from standard input.
-
-The optional I<args> specified on the command line are passed to the program as
-arguments.
-
-=head1 OPTIONS
-
-=over
-
-=item B<-help>
-
-Print a summary of command line options.
-
-=item B<-stats>
-
-Print statistics from the code-generation passes. This is only meaningful for
-the just-in-time compiler, at present.
-
-=item B<-time-passes>
-
-Record the amount of time needed for each code-generation pass and print it to
-standard error.
-
-=item B<-march>=I<arch>
-
-Use the specified non-default architecture arch when selecting a code generator
-for the just-in-time compiler. This may result in a crash if you pick an
-architecture which is not compatible with the hardware you are running B<lli> on.
-
-=item B<-force-interpreter>=I<{false,true}>
-
-If set to true, use the interpreter even if a just-in-time compiler is available
-for this architecture. Defaults to false.
-
-=item B<-f>=I<name>
-
-Call the function named I<name> to start the program.  Note: The
-function is assumed to have the C signature C<int> I<name> C<(int,
-char **, char **)>.  If you try to use this option to call a function of
-incompatible type, undefined behavior may result. Defaults to C<main>.
-
-=back
-
-=head1 EXIT STATUS
-
-If B<lli> fails to load the program, it will exit with an exit code of 1.
-Otherwise, it will return the exit code of the program it executes.
-
-=head1 SEE ALSO
-
-L<llc|llc>
-
-=head1 AUTHOR
-
-Maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
-
-=cut

llvm/docs/CommandGuide/llvm-as.html

@@ -0,0 +1,97 @@
+<html>
+<title>
+LLVM: llvm-as tool
+</title>
+
+<body bgcolor=white>
+
+<center><h1>LLVM: <tt>llvm-as</tt> tool</h1></center>
+<HR>
+
+<h3>NAME</h3>
+<tt>llvm-as</tt>
+
+<h3>SYNOPSIS</h3>
+<tt>llvm-as [options] [filename]</tt>
+
+<h3>DESCRIPTION</h3>
+
+The <tt>llvm-as</tt> command is the LLVM assembler.  It reads a file containing
+human readable LLVM assembly language, translates it to LLVM bytecode, and
+writes the result into a file or to standard output.
+<p>
+
+If filename is omitted or is -, then <tt>llvm-as</tt> reads its input from
+standard input.
+<p>
+
+If an output file is not specified with the <tt>-o</tt> option, then
+<tt>llvm-as</tt> sends its output to a file or standard output by the following
+logic:
+
+<ul>
+	<li>
+	If the input is standard input, then the output is standard output.
+	<p>
+
+	<li>
+	If the input is a file that ends with .ll, then the output file is of
+	the same name, except that the suffix is changed to .bc.
+	<p>
+
+	<li>
+	If the input is a file that does not end with the .ll suffix, then the
+	output file has the same name as the input file, except that the .bc
+	suffix is appended.
+	<p>
+</ul>
+
+<h3>OPTIONS</h3>
+
+<ul>
+	<li> -f
+	<br>
+	Force overwrite.  Normally, <tt>llvm-as</tt> will refuse to overwrite an
+	output file that already exists.  With this option, <tt>llvm-as</tt>
+	will overwrite the output file and replace it with new bytecode.
+	<p>
+
+	<li> -help
+	<br>
+	Print a summary of command line options.
+	<p>
+
+	<li> -o &lt;filename&gt;
+	<br>
+	Specify the output filename.  If filename is -, then <tt>llvm-as</tt>
+	sends its output to standard output.
+	<p>
+
+	<li> -stats
+	<br>
+	Print statistics.
+	<p>
+
+	<li> -time-passes
+	<br>
+	Record the amount of time needed for each pass and print it to standard
+	error.
+	<p>
+</ul>
+
+<h3>EXIT STATUS</h3>
+
+If <tt>llvm-as</tt> succeeds, it will exit with 0.  Otherwise, if an error
+occurs, it will exit with a non-zero value.
+
+<h3>SEE ALSO</h3>
+
+<a href="llvm-dis.html"><tt>llvm-dis</tt></a>
+<a href="gccas.html"><tt>gccas</tt></a>
+
+
+<HR>
+Maintained by the <a href="http://llvm.cs.uiuc.edu">LLVM Team</a>.
+</body>
+</html>
+

llvm/docs/CommandGuide/llvm-as.pod

@@ -1,86 +0,0 @@
-=pod
-
-=head1 NAME
-
-llvm-as - LLVM assembler
-
-=head1 SYNOPSIS
-
-B<llvm-as> [I<options>] [I<filename>]
-
-=head1 DESCRIPTION
-
-The B<llvm-as> command invokes the LLVM assembler.  It reads a file containing
-human-readable LLVM assembly language, translates it to LLVM bytecode, and
-writes the result into a file or to standard output.
-
-If F<filename> is omitted or is C<->, then B<llvm-as> reads its input from
-standard input.
-
-If an output file is not specified with the B<-o> option, then
-B<llvm-as> sends its output to a file or standard output by following
-these rules:
-
-=over 
-
-=item *
-
-If the input is standard input, then the output is standard output.
-
-=item *
-
-If the input is a file that ends with C<.ll>, then the output file is of
-the same name, except that the suffix is changed to C<.bc>.
-
-=item *
-
-If the input is a file that does not end with the C<.ll> suffix, then the
-output file has the same name as the input file, except that the C<.bc>
-suffix is appended.
-
-=back
-
-=head1 OPTIONS
-
-=over
-
-=item B<-f>
-
-Force overwrite.  Normally, B<llvm-as> will refuse to overwrite an
-output file that already exists.  With this option, B<llvm-as>
-will overwrite the output file and replace it with new bytecode.
-
-=item B<--help>
-
-Print a summary of command line options.
-
-=item B<-o> F<filename>
-
-Specify the output file name.  If F<filename> is C<->, then B<llvm-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
-
-If B<llvm-as> succeeds, it will exit with 0.  Otherwise, if an error
-occurs, it will exit with a non-zero value.
-
-=head1 SEE ALSO
-
-L<llvm-dis|llvm-dis>, L<gccas|gccas>
-
-=head1 AUTHORS
-
-Maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
-
-=cut

llvm/docs/CommandGuide/llvm-bcanalyzer.pod

@@ -1,66 +0,0 @@
-=pod
-
-=head1 NAME
-
-llvm-bcanalyzer - LLVM bytecode analyzer
-
-=head1 SYNOPSIS
-
-B<llvm-bcanalyzer> [I<options>] [I<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. 
-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>
-
-Causes B<llvm-bcanalyzer> to abbreviate its output by writing out only a module 
-level summary. The details for individual functions are not displayed.
-
-=item B<-dump>
-
-Causes B<llvm-bcanalyzer> to dump the bytecode in a human readable format. This 
-format is significantly different from LLVM assembly and provides details about 
-the encoding of the bytecode file. 
-
-=item B<-verify>
-
-Causes B<llvm-bcanalyzer> to verify the module produced by by reading the 
-bytecode. This ensures that the statistics generated are based on a consistent
-module.
-
-=item B<--help>
-
-Print a summary of command line options.
-
-=back
-
-=head1 EXIT STATUS
-
-If B<llvm-bcanalyzer> succeeds, it will exit with 0.  Otherwise, if an error
-occurs, it will exit with a non-zero value, usually 1.
-
-=head1 SEE ALSO
-
-L<llvm-dis|llvm-dis>, L<http://llvm.cs.uiuc.edu/docs/BytecodeFormat.html>
-
-=head1 AUTHORS
-
-Maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
-
-=cut

llvm/docs/CommandGuide/llvm-db.pod

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

llvm/docs/CommandGuide/llvm-dis.html

@@ -0,0 +1,99 @@
+<html>
+<title>
+LLVM: llvm-dis tool
+</title>
+
+<body bgcolor=white>
+
+<center><h1>LLVM: <tt>llvm-dis</tt> tool</h1></center>
+<HR>
+
+<h3>NAME</h3>
+<tt>llvm-dis</tt>
+
+<h3>SYNOPSIS</h3>
+<tt>llvm-dis [options] [filename]</tt>
+
+<h3>DESCRIPTION</h3>
+
+The <tt>llvm-dis</tt> command is the LLVM disassembler.  It takes an LLVM
+bytecode file and converts it into LLVM assembly language or C source code with
+equivalent functionality.
+<p>
+
+If filename is omitted, <tt>llvm-dis</tt> reads its input from standard input.
+<p>
+
+The default output file for <tt>llvm-dis</tt> is determined by the following logic:
+<ul>
+	<li>
+	If the input is standard input or the file -, then the output is
+	standard output.
+	<p>
+
+	<li>
+	If the input filename ends in .bc, then the output filename will be
+	identical, except that the .bc suffix will be replaced by the .ll or .c
+	suffix (for LLVM assembly language and C code, respectively).
+	<p>
+
+	<li>
+	If the input filename does not end in .bc, then the output filename will
+	be identical to the input filename, except that the .ll or .c suffix
+	will be appended to the filename (for LLVM assembly language and C code,
+	respectively).
+</ul>
+
+<h3>OPTIONS</h3>
+
+<ul>
+	<li> -llvm
+	<br>
+	Instruct <tt>llvm-dis</tt> to generate LLVM assembly code in human
+	readable format.  This is the default behavior.
+	<p>
+
+	<li> -c
+	<br>
+	Instruct <tt>llvm-dis</tt> to generate C source code.
+	<p>
+
+	<li> -f
+	<br>
+	Force overwrite.  Normally, <tt>llvm-dis</tt> will refuse to overwrite
+	an output file that already exists.  With this option, <tt>llvm-dis</tt>
+	will overwrite the output file.
+	<p>
+
+	<li> -help
+	<br>
+	Print a summary of command line options.
+	<p>
+
+	<li> -o &lt;filename&gt;
+	<br>
+	Specify the output filename.  If filename is -, then the output is sent
+	to standard output.
+	<p>
+
+	<li> -time-passes
+	<br>
+	Record the amount of time needed for each pass and print it to standard
+	error.
+	<p>
+</ul>
+
+<h3>EXIT STATUS</h3>
+
+If <tt>llvm-dis</tt> succeeds, it will exit with 0.  Otherwise, if an error
+occurs, it will exit with a non-zero value.
+
+<h3>SEE ALSO</h3>
+
+<a href="llvm-as.html"><tt>llvm-as</tt></a>
+
+<HR>
+Maintained by the <a href="http://llvm.cs.uiuc.edu">LLVM Team</a>.
+</body>
+</html>
+

llvm/docs/CommandGuide/llvm-dis.pod

@@ -1,65 +0,0 @@
-=pod
-
-=head1 NAME
-
-llvm-dis - LLVM disassembler
-
-=head1 SYNOPSIS
-
-B<llvm-dis> [I<options>] [I<filename>]
-
-=head1 DESCRIPTION
-
-The B<llvm-dis> command is the LLVM disassembler.  It takes an LLVM
-bytecode file and converts it into human-readable LLVM assembly language.
-
-If filename is omitted or specified as C<->, B<llvm-dis> reads its
-input from standard input.
-
-If the input is being read from standard input, then B<llvm-dis>
-will send its output to standard output by default.  Otherwise, the
-output will be written to a file named after the input file, with
-a C<.ll> suffix added (any existing C<.bc> suffix will first be
-removed).  You can override the choice of output file using the
-B<-o> option.
-
-=head1 OPTIONS
-
-=over
-
-=item B<-f>
-
-Force overwrite.  Normally, B<llvm-dis> will refuse to overwrite
-an output file that already exists.  With this option, B<llvm-dis>
-will overwrite the output file.
-
-=item B<--help>
-
-Print a summary of command line options.
-
-=item B<-o> F<filename>
-
-Specify the output file name.  If F<filename> is -, 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
-
-If B<llvm-dis> succeeds, it will exit with 0.  Otherwise, if an error
-occurs, it will exit with a non-zero value.
-
-=head1 SEE ALSO
-
-L<llvm-as|llvm-as>
-
-=head1 AUTHORS
-
-Maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
-
-=cut

llvm/docs/CommandGuide/llvm-link.html

@@ -0,0 +1,88 @@
+<html>
+<title>
+LLVM: llvm-link tool
+</title>
+
+<body bgcolor=white>
+
+<center><h1>LLVM: <tt>llvm-link</tt> tool</h1></center>
+<HR>
+
+<h3>NAME</h3>
+<tt>llvm-link</tt>
+
+<h3>SYNOPSIS</h3>
+<tt>llvm-link [options] &lt;filename&gt; [filename ...]</tt>
+
+<h3>DESCRIPTION</h3>
+
+The <tt>llvm-link</tt> command takes several LLVM bytecode files and links them
+together into a single LLVM bytecode file.  It writes the output file to
+standard output, unless the -o option is used to specify a filename.
+<p>
+
+The <tt>llvm-link</tt> command attempts to load the input files from the current
+directory.  If that fails, it looks for each file in each of the
+directories specified by the -L options on the command line.  The library search
+paths are global; each one is searched for every input file if necessary.  The
+directories are searched in the order they were specified on the command line.
+
+<h3>
+OPTIONS
+</h3>
+
+<ul>
+	<li>-L &lt;directory&gt;
+	<br>
+	Add the specified directory to the library search path.  When looking
+	for libraries, <tt>llvm-link</tt> will look in pathname for libraries.
+	This option can be specified multiple times; <tt>llvm-link</tt> will
+	search inside these directories in the order in which they were
+	specified on the command line.
+	<p>
+
+	<li>-f
+	<br>
+	Overwrite output files.  By default, <tt>llvm-link</tt> will not
+	overwrite an output file if it alreadys exists.
+	<p>
+
+	<li>-o &lt;filename&gt;
+	<br>
+	Output filename.  If filename is -, then <tt>llvm-link</tt> will write
+	its output to standard output.
+	<p>
+
+	<li>-d
+	<br>
+	If specified, <tt>llvm-link</tt> prints a human-readable version of the
+	output bytecode file to standard error.
+	<p>
+
+	<li>-help
+	<br>
+	Print a summary of command line options.
+	<p>
+
+	<li>-v
+	<br>
+	Verbose mode.  Print information about what <tt>llvm-link</tt> is doing.
+    This typically includes a message for each bytecode file linked in
+    and for each library found.
+</ul>
+
+<h3>
+EXIT STATUS
+</h3>
+
+If <tt>llvm-link</tt> succeeds, it will exit with 0.  Otherwise, if an error
+occurs, it will exit with a non-zero value.
+
+<h3>SEE ALSO</h3>
+<a href="gccld.html"><tt>gccld</tt></a>
+
+<HR>
+Maintained by the <a href="http://llvm.cs.uiuc.edu">LLVM Team</a>.
+</body>
+</html>
+

llvm/docs/CommandGuide/llvm-link.pod

@@ -1,75 +0,0 @@
-=pod
-
-=head1 NAME
-
-llvm-link - LLVM linker
-
-=head1 SYNOPSIS
-
-B<llvm-link> [I<options>] I<filename ...>
-
-=head1 DESCRIPTION
-
-The B<llvm-link> command takes several LLVM bytecode files and links them
-together into a single LLVM bytecode file.  It writes the output file to
-standard output, unless the B<-o> option is used to specify a filename.
-
-The B<llvm-link> command attempts to load the input files from the current
-directory.  If that fails, it looks for each file in each of the directories
-specified by the B<-L> options on the command line.  The library search paths
-are global; each one is searched for every input file if necessary.  The
-directories are searched in the order they were specified on the command line.
-
-=head1 OPTIONS
-
-=over
-
-=item B<-L> F<directory>
-
-Add the specified F<directory> to the library search path.  When looking for
-libraries, B<llvm-link> will look in pathname for libraries.  This option can be
-specified multiple times; B<llvm-link> will search inside these directories in
-the order in which they were specified on the command line.
-
-=item B<-f>
-
-Overwrite output files.  By default, B<llvm-link> will not overwrite an output
-file if it alreadys exists.
-
-=item B<-o> F<filename>
-
-Specify the output file name.  If F<filename> is C<->, then B<llvm-link> will
-write its output to standard output.
-
-=item B<-d>
-
-If specified, B<llvm-link> prints a human-readable version of the output
-bytecode file to standard error.
-
-=item B<--help>
-
-Print a summary of command line options.
-
-=item B<-v>
-
-Verbose mode.  Print information about what B<llvm-link> is doing.  This
-typically includes a message for each bytecode file linked in and for each
-library found.
-
-=back
-
-=head1 EXIT STATUS
-
-If B<llvm-link> succeeds, it will exit with 0.  Otherwise, if an error
-occurs, it will exit with a non-zero value.
-
-=head1 SEE ALSO
-
-L<gccld>
-
-=head1 AUTHORS
-
-Maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
-
-=cut
-

llvm/docs/CommandGuide/llvm-nm.html

@@ -0,0 +1,118 @@
+<html>
+<title>
+LLVM: llvm-nm tool
+</title>
+
+<body bgcolor=white>
+
+<center><h1>LLVM: <tt>llvm-nm</tt> tool</h1></center>
+<HR>
+
+<h3>NAME</h3>
+<tt>llvm-nm</tt>
+
+<h3>SYNOPSIS</h3>
+<tt>llvm-nm [options] [filenames...]</tt>
+
+<h3>DESCRIPTION</h3>
+
+<p>The <tt>llvm-nm</tt> utility lists the names of symbols from the
+LLVM bytecode files, or <tt>ar(1)</tt> archives containing LLVM
+bytecode files, named on the command line. Each symbol is listed along
+with some simple information about its provenance. If no filename is specified,
+or - is used as a filename, <tt>llvm-nm</tt> will process a bytecode file
+on its standard input stream.</p>
+
+<p><tt>llvm-nm</tt>'s default output format is the traditional BSD
+<tt>nm(1)</tt> output format. Each such output record consists of an
+(optional) 8-digit hexadecimal address, followed by a type code
+character, followed by a name, for each symbol. One record is printed
+per line; fields are separated by spaces. When the address is omitted,
+it is replaced by 8 spaces.</p>
+
+<p>Type code characters currently supported, and their meanings, are
+as follows:</p>
+
+<table border>
+<tr><td>U</td><td>Named object is referenced but undefined in this
+              bytecode file</td></tr>
+<tr><td>C</td><td>Common (multiple defs link together into one
+              def)</td></tr>
+<tr><td>W</td><td>Weak reference (multiple defs link together into zero or
+              one defs)</td></tr>
+<tr><td>t</td><td>Local function (text) object</td></tr>
+<tr><td>T</td><td>Global function (text) object</td></tr>
+<tr><td>d</td><td>Local data object</td></tr>
+<tr><td>D</td><td>Global data object</td></tr>
+<tr><td>?</td><td>Something unrecognizable</td></tr>
+</table>
+
+<p>Because LLVM bytecode files typically contain objects that are not
+considered to have addresses until they are linked into an executable
+image or dynamically compiled "just-in-time", <tt>llvm-nm</tt> does
+not print an address for any symbol, even symbols which are defined in
+the bytecode file.</p>
+
+<h3>OPTIONS</h3>
+
+<ul>
+	<li> -P
+	<br>
+        Use POSIX.2 output format. Alias for --format=posix.
+	<p>
+	<li> -B    (default)
+	<br>
+        Use BSD output format. Alias for --format=bsd.
+	<p>
+
+	<li> -help
+	<br>
+	Print a summary of command-line options and their meanings.
+	<p>
+
+	<li> -defined-only
+	<br>
+	Print only symbols defined in this bytecode file (as opposed
+        to symbols which may be referenced by objects in this file,
+        but not defined in this file.)
+	<p>
+
+	<li> -extern-only, -g
+	<br>
+	Print only symbols whose definitions are external; that is,
+        accessible from other bytecode files.
+	<p>
+
+	<li> -undefined-only, -u
+	<br>
+	Print only symbols referenced but not defined in this bytecode
+        file.
+	<p>
+
+	<li> -format=<i>fmt</i>, -f
+	<br>
+	Select an output format; <i>fmt</i> may be sysv, posix, or
+        bsd. The default is bsd.
+	<p>
+</ul>
+
+<h3>BUGS</h3>
+
+<tt>llvm-nm</tt> cannot demangle C++ mangled
+names, like GNU <tt>nm(1)</tt> can.
+
+<h3>EXIT STATUS</h3>
+
+<tt>llvm-nm</tt> exits with an exit code of zero.
+
+<h3>SEE ALSO</h3>
+
+<a href="llvm-dis.html"><tt>llvm-dis</tt></a>,
+<tt>ar(1)</tt>,
+<tt>nm(1)</tt>
+
+<HR>
+Maintained by the <a href="http://llvm.cs.uiuc.edu">LLVM Team</a>.
+</body>
+</html>
+

llvm/docs/CommandGuide/llvm-nm.pod

@@ -1,122 +0,0 @@
-=pod
-
-=head1 NAME
-
-llvm-nm - list LLVM bytecode file's symbol table
-
-=head1 SYNOPSIS
-
-B<llvm-nm> [I<options>] [I<filenames...>]
-
-=head1 DESCRIPTION
-
-The B<llvm-nm> utility lists the names of symbols from the LLVM bytecode files,
-or B<ar> archives containing LLVM bytecode files, named on the command line.
-Each symbol is listed along with some simple information about its provenance.
-If no filename is specified, or I<-> is used as a filename, B<llvm-nm> will
-process a bytecode file on its standard input stream.
-
-B<llvm-nm>'s default output format is the traditional BSD B<nm> output format.
-Each such output record consists of an (optional) 8-digit hexadecimal address,
-followed by a type code character, followed by a name, for each symbol. One
-record is printed per line; fields are separated by spaces. When the address is
-omitted, it is replaced by 8 spaces.
-
-Type code characters currently supported, and their meanings, are as follows:
-
-=over
-
-=item U
-
-Named object is referenced but undefined in this bytecode file
-
-=item C
-
-Common (multiple defs link together into one def)
-
-=item W
-
-Weak reference (multiple defs link together into zero or one defs)
-
-=item t
-
-Local function (text) object
-
-=item T
-
-Global function (text) object
-
-=item d
-
-Local data object
-
-=item D
-
-Global data object
-
-=item ?
-
-Something unrecognizable
-
-=back
-
-Because LLVM bytecode files typically contain objects that are not considered to
-have addresses until they are linked into an executable image or dynamically
-compiled "just-in-time", B<llvm-nm> does not print an address for any symbol,
-even symbols which are defined in the bytecode file.
-
-=head1 OPTIONS
-
-=over
-
-=item B<-P>
-
-Use POSIX.2 output format. Alias for B<--format=posix>.
-
-=item B<-B>    (default)
-
-Use BSD output format. Alias for B<--format=bsd>.
-
-=item B<--help>
-
-Print a summary of command-line options and their meanings.
-
-=item B<--defined-only>
-
-Print only symbols defined in this bytecode file (as opposed to
-symbols which may be referenced by objects in this file, but not
-defined in this file.)
-
-=item B<--extern-only>, B<-g>
-
-Print only symbols whose definitions are external; that is, accessible
-from other bytecode files.
-
-=item B<--undefined-only>, B<-u>
-
-Print only symbols referenced but not defined in this bytecode file.
-
-=item B<--format=>I<fmt>, B<-f>
-
-Select an output format; I<fmt> may be I<sysv>, I<posix>, or I<bsd>. The
-default is I<bsd>.
-
-=back
-
-=head1 BUGS
-
-B<llvm-nm> cannot demangle C++ mangled names, like GNU B<nm> can.
-
-=head1 EXIT STATUS
-
-B<llvm-nm> exits with an exit code of zero.
-
-=head1 SEE ALSO
-
-L<llvm-dis|llvm-dis>, L<ar(1)>, L<nm(1)>
-
-=head1 AUTHOR
-
-Maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
-
-=cut

llvm/docs/CommandGuide/llvm-prof.html

@@ -0,0 +1,52 @@
+<html>
+<title>LLVM: llvm-prof tool</title>
+
+<body bgcolor=white>
+
+<center><h1>LLVM: <tt>llvm-prof</tt> tool</h1></center>
+<HR>
+
+<h3>NAME</h3>
+<tt>llvm-prof</tt>
+
+<h3>SYNOPSIS</h3>
+<tt>llvm-prof [options] [bytecode file] [LLVM passes]</tt>
+
+<h3>DESCRIPTION</h3>
+
+The <tt>llvm-prof</tt> tool reads in an '<tt>llvmprof.out</tt>' file, a bytecode
+file for the program, and produces a human readable report, suitable for
+determining where the program hotspots are.<p>
+
+This program is often used in conjunction with the <tt>utils/profile.sh</tt>
+script.  This script automatically instruments a program, runs it with the JIT,
+then runs <tt>llvm-prof</tt> to format a report.  To get more information about
+<tt>utils/profile.sh</tt>, execute it with the <tt>--help</tt> option.<p>
+
+<h3>OPTIONS</h3>
+
+<ul>
+	<li><tt>--annotated-llvm</tt> or <tt>-A</tt><br>
+
+        In addition to the normal report printed, print out the code for the
+        program, annotated we execution frequency information. This can be
+        particularly useful when trying to visualize how frequently basic blocks
+        are executed.  This is most useful with basic block profiling
+        information or better.<p>
+
+	<li><tt>--print-all-code</tt><br>
+
+        Using this option enables the <tt>--annotated-llvm</tt> option, but it
+        prints the entire module, instead of just the most commonly executed
+        functions.<p>
+</ul>
+
+<h3>EXIT STATUS</h3>
+
+<tt>llvm-prof</tt> returns 1 if it cannot load the bytecode file or the profile
+information, otherwise it exits with zero.
+
+<HR>
+Maintained by the <a href="http://llvm.cs.uiuc.edu">LLVM Team</a>.
+</body>
+</html>

llvm/docs/CommandGuide/llvm-prof.pod

@@ -1,57 +0,0 @@
-=pod
-
-=head1 NAME
-
-llvm-prof - print execution profile of LLVM program
-
-=head1 SYNOPSIS
-
-B<llvm-prof> [I<options>] [I<bytecode file>] [I<llvmprof.out>]
-
-=head1 DESCRIPTION
-
-The B<llvm-prof> tool reads in an F<llvmprof.out> file (which can
-optionally use a specific file with the third program argument), a bytecode file
-for the program, and produces a human readable report, suitable for determining
-where the program hotspots are.
-
-This program is often used in conjunction with the F<utils/profile.pl>
-script.  This script automatically instruments a program, runs it with the JIT,
-then runs B<llvm-prof> to format a report.  To get more information about
-F<utils/profile.pl>, execute it with the B<--help> option.
-
-=head1 OPTIONS
-
-=over
-
-=item B<--annotated-llvm> or B<-A>
-
-In addition to the normal report printed, print out the code for the
-program, annotated with execution frequency information. This can be
-particularly useful when trying to visualize how frequently basic blocks
-are executed.  This is most useful with basic block profiling
-information or better.
-
-=item B<--print-all-code>
-
-Using this option enables the B<--annotated-llvm> option, but it
-prints the entire module, instead of just the most commonly executed
-functions.
-
-=item B<--time-passes>
-
-Record the amount of time needed for each pass and print it to standard
-error.
-
-=back
-
-=head1 EXIT STATUS
-
-B<llvm-prof|llvm-prof> returns 1 if it cannot load the bytecode file or the
-profile information. Otherwise, it exits with zero.
-
-=head1 AUTHOR
-
-B<llvm-prof> is maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
-
-=cut

llvm/docs/CommandGuide/llvmgcc.html

@@ -0,0 +1,113 @@
+<html>
+<title>
+LLVM: llvmgcc tool
+</title>
+
+<body bgcolor=white>
+
+<center>
+<h1>LLVM: <tt>llvmgcc</tt> tool</h1>
+</center>
+<HR>
+
+<h3>NAME</h3>
+<tt>llvmgcc</tt>
+
+<h3>
+SYNOPSIS
+</h3>
+
+<tt>llvmgcc [options] filename</tt>
+<h3>
+DESCRIPTION
+</h3>
+
+The <tt>llvmgcc</tt> command is the LLVM C front end.  It is a modified version
+of the <a href="http://gcc.gnu.org">GNU Compiler Collection</a> (GCC) that takes
+C programs and compiles them into LLVM bytecode or assembly language, depending
+upon the options.
+<p>
+
+Unless the <tt>-S</tt> option is specified, <tt>llvmgcc</tt> will use the
+<a href="gccas.html"><tt>gccas</tt></a> program to perform some optimizations
+and create an LLVM bytecode file. Unless the <tt>-c</tt> option is specified,
+<tt>llvmgcc</tt> will also use the <a href="gccld.html"><tt>gccld</tt></a>
+program to perform further optimizations and link the resulting bytecode
+file(s) with support libraries to create an executable program.
+<p>
+
+Being derived from GCC, llvmgcc 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.
+<p>
+
+Below you will find several commonly used options:
+
+<h3>
+OPTIONS
+</h3>
+
+<ul>
+	<li> -S
+	<br>
+	Do not generate an LLVM bytecode file.  Rather, compile the source file
+	into an LLVM assembly language file.
+	<p>
+
+	<li> -c
+	<br>
+	Do not generate a linked bytecode executable.  Rather, compile the source
+	file into an LLVM bytecode file.  This bytecode file can then be linked
+	with other bytecode files later to generate a full LLVM executable.
+	<p>
+
+	<li> -o <i>filename</i>
+	<br>
+	Specify the output file to be <i>filename</i>.
+	<p>
+
+	<li> -I <i>directory</i>
+	<br>
+	Add a directory to the header file search path.  This option can be
+	repeated.
+	<p>
+
+	<li> -L <i>directory</i>
+	<br>
+	Add <i>directory</i> to the library search path.  This option can be
+	repeated.
+	<p>
+
+	<li> -l<i>name</i>
+	<br>
+	Link in the library lib<i>name</i>.[bc | a | so].  This library should
+	be a bytecode library.
+	<p>
+
+	<li>-Wl,<i>option</i>
+	<br>
+	Pass <i>option</i> to the linker program, <a
+	href="gccld.html"><tt>gccld</tt></a>.
+	<p>
+</ul>
+
+<h3>
+EXIT STATUS
+</h3>
+
+If <tt>llvmgcc</tt> succeeds, it will exit with 0.  Otherwise, if an error
+occurs, it will exit with a non-zero value.
+
+<h3>
+SEE ALSO
+</h3>
+<A HREF="llvmgxx.html"><tt>llvmg++</tt></A>,
+<A HREF="gccas.html"><tt>gccas</tt></A>,
+<A HREF="gccld.html"><tt>gccld</tt></A>,
+and the Info documentation for <tt>gcc</tt>.
+
+<HR>
+Maintained by the <a href="http://llvm.cs.uiuc.edu">LLVM Team</a>.
+</body>
+</html>
+

llvm/docs/CommandGuide/llvmgcc.pod

@@ -1,87 +0,0 @@
-=pod
-
-=head1 NAME
-
-llvmgcc - LLVM C front-end
-
-=head1 SYNOPSIS
-
-B<llvmgcc> [I<options>] I<filename>
-
-=head1 DESCRIPTION
-
-The B<llvmgcc> 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
-L<gccas|gccas> program to perform some optimizations and create an
-LLVM bytecode file. Unless the B<-c> option is specified, B<llvmgcc>
-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
-of gcc's features and accepts most of gcc's options.  It handles a
-number of gcc's extensions to the C programming language.
-
-=head1 OPTIONS
-
-=over
-
-=item B<--help>
-
-Print a summary of command line options.
-
-=item B<-S>
-
-Do not generate an LLVM bytecode file.  Rather, compile the source
-file into an LLVM assembly language file.
-
-=item B<-c>
-
-Do not generate a linked executable.  Rather, compile the source
-file into an LLVM bytecode file.  This bytecode file can then be
-linked with other bytecode files later on to generate a full LLVM
-executable.
-
-=item B<-o> I<filename>
-
-Specify the output file to be I<filename>.
-
-=item B<-I> I<directory>
-
-Add a directory to the header file search path.  This option can be
-repeated.
-
-=item B<-L> I<directory>
-
-Add I<directory> to the library search path.  This option can be
-repeated.
-
-=item B<-l>I<name>
-
-Link in the library libI<name>.[bc | a | so].  This library should
-be a bytecode library.
-
-=item B<-Wl,>I<option>
-
-Pass I<option> to the linker (usually gccld).
-
-=back
-
-=head1 EXIT STATUS
-
-If B<llvmgcc> 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>
-
-=head1 AUTHORS
-
-Maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
-
-=cut
-

llvm/docs/CommandGuide/llvmgxx.html

@@ -0,0 +1,107 @@
+<html>
+<title>
+LLVM: llvmg++ tool
+</title>
+
+<body bgcolor=white>
+
+<center>
+<h1>LLVM: <tt>llvmg++</tt> tool</h1>
+</center>
+<HR>
+
+<h3>NAME</h3>
+<tt>llvmg++</tt>
+
+<h3>SYNOPSIS</h3>
+<tt>llvmg++ [options] filename</tt>
+
+<h3>DESCRIPTION</h3>
+
+The <tt>llvmg++</tt> 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.
+<p>
+
+Unless the <tt>-S</tt> option is specified, <tt>llvmg++</tt> will use the
+<a href="gccas.html"><tt>gccas</tt></a> program to perform some optimizations
+and create an LLVM bytecode file. Unless the <tt>-c</tt> option is specified,
+<tt>llvmg++</tt> will also use the <a href="gccld.html"><tt>gccld</tt></a>
+program to perform further optimizations and link the resulting bytecode
+file(s) with support libraries to create an executable program.
+<p>
+
+Being derived from the <a href="http://gcc.gnu.org">GNU Compiler Collection</a>,
+<tt>llvmg++</tt> 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.
+<p>
+
+Below you will find several commonly used options:
+
+<h3>
+OPTIONS
+</h3>
+
+<ul>
+	<li> -S
+	<br>
+	Do not generate an LLVM bytecode file.  Rather, compile the source file
+	into an LLVM assembly language file.
+	<p>
+
+	<li> -c
+	<br>
+	Do not generate a linked executable.  Rather, compile the source file
+	into an LLVM bytecode file.  This bytecode file can then be linked with
+	other bytecode files later on to generate a full LLVM executable.
+	<p>
+
+	<li> -o <i>filename</i>
+	<br>
+	Specify the output file to be <i>filename</i>.
+	<p>
+
+	<li> -I <i>directory</i>
+	<br>
+	Add a directory to the header file search path.  This option can be
+	repeated.
+	<p>
+
+	<li> -L <i>directory</i>
+	<br>
+	Add <i>directory</i> to the library search path.  This option can be
+	repeated.
+	<p>
+
+	<li> -l<i>name</i>
+	<br>
+	Link in the library lib<i>name</i>.[bc | a | so].  This library should
+	be a bytecode library.
+	<p>
+
+	<li>-Wl,<i>option</i>
+	<br>
+	Pass <i>option</i> to the linker (usually gccld).
+	<p>
+
+</ul>
+
+<h3>
+EXIT STATUS
+</h3>
+
+If <tt>llvmg++</tt> succeeds, it will exit with 0.  Otherwise, if an error
+occurs, it will exit with a non-zero value.
+
+<h3>
+SEE ALSO
+</h3>
+<A HREF="llvmgcc.html"><tt>llvmg++</tt></A>,
+<A HREF="gccas.html"><tt>gccas</tt></A>,
+<A HREF="gccld.html"><tt>gccld</tt></A>
+
+<HR>
+Maintained by the <a href="http://llvm.cs.uiuc.edu">LLVM Team</a>.
+</body>
+</html>
+

llvm/docs/CommandGuide/llvmgxx.pod

@@ -1,87 +0,0 @@
-=pod
-
-=head1 NAME
-
-llvmg++ - LLVM C++ front-end
-
-=head1 SYNOPSIS
-
-B<llvmg++> [I<options>] I<filename>
-
-=head1 DESCRIPTION
-
-The B<llvmg++> 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
-L<gccas|gccas> program to perform some optimizations and create an
-LLVM bytecode file. Unless the B<-c> option is specified, B<llvmg++>
-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
-of g++'s features and accepts most of g++'s options.  It handles a
-number of g++'s extensions to the C++ programming language.
-
-=head1 OPTIONS
-
-=over
-
-=item B<--help>
-
-Print a summary of command line options.
-
-=item B<-S>
-
-Do not generate an LLVM bytecode file.  Rather, compile the source
-file into an LLVM assembly language file.
-
-=item B<-c>
-
-Do not generate a linked executable.  Rather, compile the source
-file into an LLVM bytecode file.  This bytecode file can then be
-linked with other bytecode files later on to generate a full LLVM
-executable.
-
-=item B<-o> I<filename>
-
-Specify the output file to be I<filename>.
-
-=item B<-I> I<directory>
-
-Add a directory to the header file search path.  This option can be
-repeated.
-
-=item B<-L> I<directory>
-
-Add I<directory> to the library search path.  This option can be
-repeated.
-
-=item B<-l>I<name>
-
-Link in the library libI<name>.[bc | a | so].  This library should
-be a bytecode library.
-
-=item B<-Wl,>I<option>
-
-Pass I<option> to the linker (usually gccld).
-
-=back
-
-=head1 EXIT STATUS
-
-If B<llvmg++> 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>
-
-=head1 AUTHORS
-
-Maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
-
-=cut
-

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

@@ -1 +0,0 @@
-*.1

llvm/docs/CommandGuide/manpage.css

@@ -1,256 +0,0 @@
-/* Based on http://www.perldoc.com/css/perldoc.css */
-
-@import url("../llvm.css");
-
-body { font-family: Arial,Helvetica; }
-
-blockquote { margin: 10pt;  }
-
-h1, a { color: #336699; }
-
-
-/*** Top menu style ****/
-.mmenuon { 
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #ff6600; font-size: 10pt;
- }
-.mmenuoff { 
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #ffffff; font-size: 10pt;
-}	  
-.cpyright {
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #ffffff; font-size: xx-small;
-}
-.cpyrightText {
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #ffffff; font-size: xx-small;
-}
-.sections { 
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #336699; font-size: 11pt;
-}	 
-.dsections { 
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #336699; font-size: 12pt;
-}	
-.slink { 
- font-family: Arial,Helvetica; font-weight: normal; text-decoration: none;
- color: #000000; font-size: 9pt;
-}	 
-
-.slink2 { font-family: Arial,Helvetica; text-decoration: none; color: #336699; }	 
-
-.maintitle { 
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #336699; font-size: 18pt;
-}	 
-.dblArrow {
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #336699; font-size: small;
-}
-.menuSec {
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #336699; font-size: small;
-}
-
-.newstext {
- font-family: Arial,Helvetica; font-size: small;
-}
-
-.linkmenu {
- font-family: Arial,Helvetica; color: #000000; font-weight: bold;
- text-decoration: none;
-}
-
-P {
- font-family: Arial,Helvetica;
-}
-
-PRE {
-    font-size: 10pt;
-}
-.quote { 
- font-family: Times; text-decoration: none;
- color: #000000; font-size: 9pt; font-style: italic;
-}	
-.smstd { font-family: Arial,Helvetica; color: #000000; font-size: x-small; } 
-.std { font-family: Arial,Helvetica; color: #000000; } 
-.meerkatTitle { 
- font-family: sans-serif; font-size: x-small;  color: black;    }
-
-.meerkatDescription { font-family: sans-serif; font-size: 10pt; color: black }
-.meerkatCategory { 
- font-family: sans-serif; font-size: 9pt; font-weight: bold; font-style: italic; 
- color: brown; }
-.meerkatChannel { 
- font-family: sans-serif; font-size: 9pt; font-style: italic; color: brown; }
-.meerkatDate { font-family: sans-serif; font-size: xx-small; color: #336699; }
-
-.tocTitle {
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #333333; font-size: 10pt;
-}
-
-.toc-item {
- font-family: Arial,Helvetica; font-weight: bold; 
- color: #336699; font-size: 10pt; text-decoration: underline;
-}
-
-.perlVersion {
- font-family: Arial,Helvetica; font-weight: bold; 
- color: #336699; font-size: 10pt; text-decoration: none;
-}
-
-.podTitle {
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #000000;
-}
-
-.docTitle {
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #000000; font-size: 10pt;
-}
-.dotDot {
- font-family: Arial,Helvetica; font-weight: bold; 
- color: #000000; font-size: 9pt;
-}
-
-.docSec {
- font-family: Arial,Helvetica; font-weight: normal; 
- color: #333333; font-size: 9pt;
-}
-.docVersion {
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #336699; font-size: 10pt;
-}
-
-.docSecs-on {
- font-family: Arial,Helvetica; font-weight: normal; text-decoration: none;
- color: #ff0000; font-size: 10pt;
-}
-.docSecs-off {
- font-family: Arial,Helvetica; font-weight: normal; text-decoration: none;
- color: #333333; font-size: 10pt;
-}
-
-h2 {
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #336699; font-size: medium;
-}
-h1 {
- font-family: Verdana,Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #336699; font-size: large;
-}
-
-DL {
- font-family: Arial,Helvetica; font-weight: normal; text-decoration: none;
- color: #333333; font-size: 10pt;
-}
-
-UL > LI > A {
- font-family: Arial,Helvetica; font-weight: bold;
- color: #336699; font-size: 10pt;
-}
-
-.moduleInfo {
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #333333; font-size: 11pt;
-}
-
-.moduleInfoSec {
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #336699; font-size: 10pt;
-}
-
-.moduleInfoVal {
- font-family: Arial,Helvetica; font-weight: normal; text-decoration: underline;
- color: #000000; font-size: 10pt;
-}
-
-.cpanNavTitle {
- font-family: Arial,Helvetica; font-weight: bold; 
- color: #ffffff; font-size: 10pt;
-}
-.cpanNavLetter {
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; 
- color: #333333; font-size: 9pt;
-}
-.cpanCat {
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; 
- color: #336699; font-size: 9pt;
-}
-
-.bttndrkblue-bkgd-top {
-	background-color: #225688;
-	background-image: url(/global/mvc_objects/images/bttndrkblue_bgtop.gif);
-}
-.bttndrkblue-bkgd-left {
-	background-color: #225688;
-	background-image: url(/global/mvc_objects/images/bttndrkblue_bgleft.gif);
-}
-.bttndrkblue-bkgd {
-	padding-top: 0px;
-	padding-bottom: 0px;
-	margin-bottom: 0px;
-	margin-top: 0px;
-	background-repeat: no-repeat;
-	background-color: #225688;
-	background-image: url(/global/mvc_objects/images/bttndrkblue_bgmiddle.gif);
-	vertical-align: top;
-}
-.bttndrkblue-bkgd-right {
-	background-color: #225688;
-	background-image: url(/global/mvc_objects/images/bttndrkblue_bgright.gif);
-}
-.bttndrkblue-bkgd-bottom {
-	background-color: #225688;
-	background-image: url(/global/mvc_objects/images/bttndrkblue_bgbottom.gif);
-}
-.bttndrkblue-text a {
-	color: #ffffff;
-	text-decoration: none;
-}
-a.bttndrkblue-text:hover {
-	color: #ffDD3C;
-	text-decoration: none;
-}
-.bg-ltblue {
-	background-color: #f0f5fa;
-} 
-
-.border-left-b {
-	background: #f0f5fa url(/i/corner-leftline.gif) repeat-y;
-} 
-
-.border-right-b {
-	background: #f0f5fa url(/i/corner-rightline.gif) repeat-y;
-} 
-
-.border-top-b {
-	background: #f0f5fa url(/i/corner-topline.gif) repeat-x;
-} 
-
-.border-bottom-b {
-	background: #f0f5fa url(/i/corner-botline.gif) repeat-x;
-} 
-
-.border-right-w {
-	background: #ffffff url(/i/corner-rightline.gif) repeat-y;
-} 
-
-.border-top-w {
-	background: #ffffff url(/i/corner-topline.gif) repeat-x;
-} 
-
-.border-bottom-w {
-	background: #ffffff url(/i/corner-botline.gif) repeat-x;
-} 
-
-.bg-white {
-	background-color: #ffffff;
-} 
-
-.border-left-w {
-	background: #ffffff url(/i/corner-leftline.gif) repeat-y;
-} 

llvm/docs/CommandGuide/opt.html

@@ -0,0 +1,120 @@
+<html>
+<title>LLVM: opt tool</title>
+
+<body bgcolor=white>
+
+<center><h1>LLVM: <tt>opt</tt> tool</h1></center>
+<HR>
+
+<h3>NAME</h3>
+<tt>opt</tt>
+
+<h3>SYNOPSIS</h3>
+<tt>opt [options] [filename]</tt>
+
+<h3>DESCRIPTION</h3>
+
+The <tt>opt</tt> command is the modular LLVM optimizer.  It takes LLVM bytecode
+as input, runs the specified optimizations on it, and then outputs the optimized
+LLVM bytecode.
+<p>
+
+The optimizations available via <tt>opt</tt> depend upon what libraries were
+linked into it as well as any additional libraries that have been loaded with
+the <tt>-load</tt> option.  Use the <tt>-help</tt> option to determine what
+optimizations you can use.
+<p>
+
+If no filename is specified on the command line, <tt>opt</tt> reads its input
+from standard input.
+<p>
+
+If an output filename is not specified with the <tt>-o</tt> option, <tt>opt</tt>
+writes its output to the standard output.
+
+
+<h3>OPTIONS</h3>
+
+<ul>
+	<li> -f
+	<br>
+	Force overwrite.  Normally, <tt>opt</tt> will refuse to overwrite an
+	output file that already exists.  With this option, <tt>opt</tt> will
+	overwrite the output file and replace it with new bytecode.
+	<p>
+
+	<li> -help
+	<br>
+	Print a summary of command line options.
+	<p>
+
+	<li> -o &lt;filename&gt;
+	<br>
+	Specify the output filename.
+	<p>
+
+	<li> -stats
+	<br>
+	Print statistics.
+	<p>
+
+	<li> -time-passes
+	<br>
+	Record the amount of time needed for each pass and print it to standard
+	error.
+	<p>
+
+	<li> -debug
+	<br>
+	If this is a debug build, this option will enable debug printouts from
+	passes which use the <tt>DEBUG</tt> macro.  See the <a
+	href="../ProgrammersManual.html#DEBUG">Programmer's Manual</a> for more
+	information.
+	<p>
+<!--
+	<li> -internalize-public-api-file &lt;filename&gt;
+	<br>
+	Preserve the symbol names listed in the file filename.
+	<p>
+
+	<li> -internalize-public-api-list=&lt;list&gt;
+	<br>
+	Perserve the symbol names specified.
+	<p>
+-->
+
+	<li> -q
+	<br>
+	Quiet mode.  Do not print messages on whether the program was modified.
+	<p>
+
+	<li> -load &lt;plugin.so&gt;
+	<br>
+	Load the dynamic object &lt;plugin.so&gt;.  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>opt -load  &lt;plugin.so&gt; -help</tt>
+	<p>
+
+	<li> -p
+	<br>
+	Print module after each transformation.
+	<p>
+</ul>
+
+<h3>EXIT STATUS</h3>
+
+If <tt>opt</tt> succeeds, it will exit with 0.  Otherwise, if an error occurs,
+it will exit with a non-zero value.
+
+<h3>SEE ALSO</h3>
+
+<a href="analyze.html"><tt>analyze</tt></a>
+
+<HR>
+Maintained by the <a href="http://llvm.cs.uiuc.edu">LLVM Team</a>.
+</body>
+</html>
+

llvm/docs/CommandGuide/opt.pod

@@ -1,97 +0,0 @@
-=pod
-
-=head1 NAME
-
-opt - LLVM optimizer
-
-=head1 SYNOPSIS
-
-B<opt> [I<options>] [I<filename>]
-
-=head1 DESCRIPTION
-
-The B<opt> command is the modular LLVM optimizer.  It takes LLVM
-bytecode as input, runs the specified optimizations on it, and then
-outputs the optimized LLVM bytecode.
-
-The optimizations available via B<opt> depend upon what libraries
-were linked into it as well as any additional libraries that have
-been loaded with the B<-load> option.  Use the B<-help> option to
-determine what optimizations you can use.
-
-If no filename is specified on the command line, B<opt> reads its
-input from standard input.
-
-If an output filename is not specified with the B<-o> option, B<opt>
-writes its output to the standard output.
-
-=head1 OPTIONS
-
-=over
-
-=item B<-f>
-
-Force overwrite.  Normally, B<opt> will refuse to overwrite an
-output file that already exists.  With this option, B<opt> will
-overwrite the output file and replace it with new bytecode.
-
-=item B<-help>
-
-Print a summary of command line options.
-
-=item B<-o> I<filename>
-
-Specify the output filename.
-
-=item B<-profile-info-file> I<filename>
-
-Specify the name of the file loaded by the -profile-loader option.
-
-=item B<-stats>
-
-Print statistics.
-
-=item B<-time-passes>
-
-Record the amount of time needed for each pass and print it to standard
-error.
-
-=item B<-debug>
-
-If this is a debug build, this option will enable debug printouts
-from passes which use the I<DEBUG()> macro.  See the B<LLVM Programmer's
-Manual>, section I<#DEBUG> for more information.
-
-=item B<-load>=I<plugin>
-
-Load the dynamic object I<plugin>.  This object should register new
-optimization passes.  Once loaded, the object will add new command line
-options to enable various optimizations.  To see the new complete list
-of optimizations, use the B<-help> and B<-load> options together:
-
-=over
-
-B<opt -load>=I<plugin> B<-help>
-
-=back
-
-=item B<-p>
-
-Print module after each transformation.
-
-=back
-
-=head1 EXIT STATUS
-
-If B<opt> succeeds, it will exit with 0.  Otherwise, if an error
-occurs, it will exit with a non-zero value.
-
-=head1 SEE ALSO
-
-L<analyze|analyze>
-
-=head1 AUTHORS
-
-Maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
-
-=cut

llvm/docs/CommandGuide/ps/.cvsignore

@@ -1 +0,0 @@
-*ps

llvm/docs/CommandGuide/stkrc.pod

@@ -1,96 +0,0 @@
-=pod
-
-=head1 NAME
-
-stkrc - Stacker Compiler
-
-=head1 SYNOPSIS
-
-B<stkrc> [I<options>] [I<filename>]
-
-=head1 DESCRIPTION
-
-The B<stkrc> command is the compiler for the Stacker language. Stacker is a
-simple stack based, Forth-like language that was written as a demonstration
-language for LLVM. For details on the language, please see
-L<http://llvm.cs.uiuc.edu/docs/Stacker.html> . The B<stkrc> compiler is fairly 
-minimal. It compiles to bytecode only and doesn't perform any optimizations.
-The output of stkrc (a bytecode file) can be piped through other LLVM tools
-for optimization and linking.
-
-If F<filename> is omitted or is C<->, then B<stkrc> reads its input 
-from standard input. This is useful for combining the tool into a pipeline.
-
-If an output file is not specified with the B<-o> option, then
-B<llvm-as> sends its output to a file or standard output by following
-these rules:
-
-=over 
-
-=item *
-
-If the input is standard input, then the output is standard output.
-
-=item *
-
-If the input is a file that ends with C<.st>, then the output file is of
-the same name, except that the suffix is changed to C<.bc>.
-
-=item *
-
-If the input is a file that does not end with the C<.st> suffix, then the
-output file has the same name as the input file, except that the C<.bc>
-suffix is appended.
-
-=back
-
-=head1 OPTIONS
-
-=over
-
-=item B<-o> F<filename>
-
-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 acquired during compilation.
-
-=item B<-time-passes>
-
-Record the amount of time needed for each pass and print it to standard
-error.
-
-=item B<-f>
-
-Force the output to be written. Normally, B<stkrc> won't overwrite an existing
-bytecode file. This option overrides that behavior. 
-
-=item B<-s> F<stacksize>
-
-Specify the stack size for the program. The default stack size, 1024, should be
-sufficient for most programs. For very large programs, especially those that 
-recurse a lot, you might want to provide a larger value. Each unit of this
-value consumes 8 bytes of memory.
-
-=item B<-help>
-
-Print a summary of command line options.
-
-=back
-
-=head1 EXIT STATUS
-
-If B<stkrc> succeeds, it will exit with 0.  Otherwise, if an error
-occurs, it will exit with a non-zero value, usually 1.
-
-=head1 SEE ALSO
-
-L<llvm-as>, L<http://llvm.cs.uiuc.edu/docs/Stacker.html>
-
-=head1 AUTHORS
-
-Maintained by the LLVM Team (L<http://llvm.cs.uiuc.edu>).
-
-=cut

llvm/docs/CommandLine.html

@@ -84,8 +84,8 @@
     </ol></li>
 </ol>
 
-<div class="doc_author">
-  <p>Written by <a href="mailto:sabre@nondot.org">Chris Lattner</a></p>
+<div class="doc_text">
+  <p><b>Written by <a href="mailto:sabre@nondot.org">Chris Lattner</a></b></p>
 </div>
 
 <!-- *********************************************************************** -->
@@ -215,10 +215,10 @@ we would like to support the unix standard '<tt>-o &lt;filename&gt;</tt>' option
 to specify where to put the output.  With the CommandLine library, this is
 represented like this:</p>
 
-<a name="value_desc_example"></a>
-<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>
+<p><tt>
+<a name="value_desc_example">
+<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>"));</a>
+</tt></p>
 
 <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
@@ -493,7 +493,7 @@ enum OptLevel {
     clEnumVal(O1, "<i>Enable trivial optimizations</i>"),
     clEnumVal(O2, "<i>Enable default optimizations</i>"),
     clEnumVal(O3, "<i>Enable expensive optimizations</i>"),
-   clEnumValEnd));
+   0));
 
 ...
   if (OptimizationLevel &gt;= O2) doPartialRedundancyElimination(...);
@@ -503,8 +503,7 @@ enum OptLevel {
 <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
 that are listed in the declaration (Note that the declaration list must be
-terminated with the "<tt>clEnumValEnd</tt>" argument!).  The CommandLine 
-library enforces
+terminated with the "<tt>0</tt>" argument!).  The CommandLine library enforces
 that the user can only specify one of the options, and it ensure that only valid
 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
@@ -541,7 +540,7 @@ enum OptLevel {
     clEnumVal(O1        , "<i>Enable trivial optimizations</i>"),
     clEnumVal(O2        , "<i>Enable default optimizations</i>"),
     clEnumVal(O3        , "<i>Enable expensive optimizations</i>"),
-   clEnumValEnd));
+   0));
 
 ...
   if (OptimizationLevel == Debug) outputDebugInfo(...);
@@ -582,7 +581,7 @@ enum DebugLev {
     clEnumValN(nodebuginfo, "none", "<i>disable debug information</i>"),
      clEnumVal(quick,               "<i>enable quick debug information</i>"),
      clEnumVal(detailed,            "<i>enable detailed debug information</i>"),
-    clEnumValEnd));
+    0));
 </pre>
 
 <p>This definition defines an enumerated command line variable of type "<tt>enum
@@ -649,7 +648,7 @@ enum Opts {
     clEnumVal(constprop         , "<i>Constant Propagation</i>"),
    clEnumValN(inlining, "<i>inline</i>", "<i>Procedure Integration</i>"),
     clEnumVal(strip             , "<i>Strip Symbols</i>"),
-  clEnumValEnd));
+  0));
 </pre>
 
 <p>This defines a variable that is conceptually of the type
@@ -871,14 +870,13 @@ name).</p>
 <p>There are several limitations to when <tt>cl::ConsumeAfter</tt> options can
 be specified.  For example, only one <tt>cl::ConsumeAfter</tt> can be specified
 per program, there must be at least one <a href="#positional">positional
-argument</a> specified, there must not be any <a href="#cl::list">cl::list</a>
-positional arguments, and the <tt>cl::ConsumeAfter</tt> option should be a <a
+argument</a> specified, and the <tt>cl::ConsumeAfter</tt> option should be a <a
 href="#cl::list">cl::list</a> option.</p>
 
 </div>
 
 <!-- ======================================================================= -->
-<div class="doc_subsection">
+<div class="subsection">
   <a name="storage">Internal vs External Storage</a>
 </div>
 
@@ -935,7 +933,7 @@ attribute:</p>
 <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>,
+Debug("<i>debug</i>", <a href="#cl::desc">cl::desc</a>("<i>Enable debug output</i>")</a>, <a href="#cl::Hidden">cl::Hidden</a>,
       <a href="#cl::location">cl::location</a>(DebugFlag));
 </pre>
 
@@ -999,8 +997,7 @@ 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
-<b>clEnumValEnd terminated</b> list of (option, value, description) triplets 
-that
+<b>null terminated</b> list of (option, value, description) triplets that
 specify the option name, the value mapped to, and the description shown in the
 <tt>--help</tt> for the tool.  Because the generic parser is used most
 frequently with enum values, two macros are often useful:
@@ -1244,7 +1241,6 @@ input option into (potentially multiple) prefix and grouping options.  The
 strategy basically looks like this:</p>
 
 <p><tt>parse(string OrigInput) {</tt>
-
 <ol>
 <li><tt>string input = OrigInput;</tt>
 <li><tt>if (isOption(input)) return getOption(input).parse();</tt>&nbsp;&nbsp;&nbsp;&nbsp;<i>// Normal option</i>
@@ -1258,11 +1254,11 @@ strategy basically looks like this:</p>
 &nbsp;&nbsp;input = OrigInput;<br>
 &nbsp;&nbsp;while (!isOption(input) &amp;&amp; !input.empty()) input.pop_back();<br>
 }</tt>
-<li><tt>if (!OrigInput.empty()) error();</tt></li>
+<li><tt>if (!OrigInput.empty()) error();</tt>
+</tt>
 
 </ol>
-
-<p><tt>}</tt></p>
+<tt>}</tt></p>
 
 </div>
 
@@ -1287,19 +1283,10 @@ options are equivalent when <tt>cl::CommaSeparated</tt> is specified:
 makes sense to be used in a case where the option is allowed to accept one or
 more values (i.e. it is a <a href="#cl::list">cl::list</a> option).</li>
 
-<li><a name="cl::PositionalEatsArgs">The
-<b><tt>cl::PositionalEatsArgs</tt></b></a> modifier (which only applies to
-positional arguments, and only makes sense for lists) indicates that positional
-argument should consume any strings after it (including strings that start with
-a "-") up until another recognized positional argument.  For example, if you
-have two "eating" positional arguments "<tt>pos1</tt>" and "<tt>pos2</tt>" the
-string "<tt>-pos1 -foo -bar baz -pos2 -bork</tt>" would cause the "<tt>-foo -bar
--baz</tt>" strings to be applied to the "<tt>-pos1</tt>" option and the
-"<tt>-bork</tt>" string to be applied to the "<tt>-pos2</tt>" option.</li>
-
 </ul>
 
-<p>So far, these are the only two miscellaneous option modifiers.</p>
+<p>So far, the only miscellaneous option modifier is the
+<tt>cl::CommaSeparated</tt> modifier.</p>
 
 </div>
 
@@ -1701,16 +1688,12 @@ tutorial.</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>
-
-  <a href="mailto:sabre@nondot.org">Chris Lattner</a><br>
-  <a href="http://llvm.cs.uiuc.edu">LLVM Compiler Infrastructure</a><br>
+<div class="doc_footer">
+  <address><a href="mailto:sabre@nondot.org">Chris Lattner</a></address>
+  <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
+  <br>
   Last modified: $Date$
-</address>
+</div>
 
 </body>
 </html>

llvm/docs/ExtendingLLVM.html

@@ -1,238 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
-                      "http://www.w3.org/TR/html4/strict.dtd">
-<html>
-<head>
-  <title>Extending LLVM: Adding instructions, intrinsics, types, etc.</title>
-  <link rel="stylesheet" href="llvm.css" type="text/css">
-</head>
-
-<body>
-
-<div class="doc_title">
-  Extending LLVM: Adding instructions, intrinsics, types, etc.
-</div>
-
-<ol>
-  <li><a href="#introduction">Introduction and Warning</a></li>
-  <li><a href="#intrinsic">Adding a new intrinsic function</a></li>
-  <li><a href="#instruction">Adding a new instruction</a></li>
-  <li><a href="#type">Adding a new type</a>
-  <ol>
-    <li><a href="#fund_type">Adding a new fundamental type</a></li>
-    <li><a href="#derived_type">Adding a new derived type</a></li>
-  </ol></li>
-</ol>
-
-<div class="doc_author">    
-  <p>Written by <a href="http://misha.brukman.net">Misha Brukman</a></p>
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
-  <a name="introduction">Introduction and Warning</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>During the course of using LLVM, you may wish to customize it for your
-research project or for experimentation. At this point, you may realize that
-you need to add something to LLVM, whether it be a new fundamental type, a new
-intrinsic function, or a whole new instruction.</p>
-
-<p>When you come to this realization, stop and think. Do you really need to
-extend LLVM? Is it a new fundamental capability that LLVM does not support at
-its current incarnation or can it be synthesized from already pre-existing LLVM
-elements? If you are not sure, ask on the <a
-href="http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVM-dev</a> list. The
-reason is that extending LLVM will get involved as you need to update all the
-different passes that you intend to use with your extension, and there are
-<em>many</em> LLVM analyses and transformations, so it may be quite a bit of
-work.</p>
-
-<p>Adding an <a href="#intrinsic">intrinsic function</a> is easier than adding
-an instruction, and is transparent to optimization passes which treat it as an
-unanalyzable function.  If your added functionality can be expressed as a
-function call, an intrinsic function is the method of choice for LLVM
-extension.</p>
-
-<p>Before you invest a significant amount of effort into a non-trivial
-extension, <span class="doc_warning">ask on the list</span> if what you are
-looking to do can be done with already-existing infrastructure, or if maybe
-someone else is already working on it. You will save yourself a lot of time and
-effort by doing so.</p>
-
-<p>Finally, these are my notes, and since my extensions are not complete, I may
-be missing steps. If you find some omissions, please let me know <a
-href="http://misha.brukman.net/contact.html">directly</a> or post on <a
-href="http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVM-dev</a>.</p>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
-  <a name="intrinsic">Adding a new intrinsic function</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>Adding a new intrinsic function to LLVM is much easier than adding a new
-instruction.  Almost all extensions to LLVM should start as an intrinsic
-function and then be turned into an instruction if warranted.</p>
-
-<ol>
-<li><tt>llvm/docs/LangRef.html</tt>:
-    Document the intrinsic.  Decide whether it is code generator specific and
-    what the restrictions are.  Talk to other people about it so that you are
-    sure it's a good idea.</li>
-
-<li><tt>llvm/include/llvm/Intrinsics.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>
-
-<li><tt>llvm/lib/VMCore/Function.cpp (<tt>Function::getIntrinsicID()</tt>)</tt>:
-    Identify the new intrinsic function, returning the enum for the intrinsic
-    that you added.</li>
-
-<li><tt>llvm/lib/Analysis/BasicAliasAnalysis.cpp</tt>: If the new intrinsic does
-    not access memory or does not write to memory, add it to the relevant list
-    of functions.</li>
-
-<li><tt>llvm/lib/Transforms/Utils/Local.cpp</tt>: If it is possible to constant
-    propagate 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 (ie, it cannot be lowered).
-You should also add support to the code generator in question.</p>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
-  <a name="instruction">Adding a new instruction</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p><span class="doc_warning">WARNING: adding instructions changes the bytecode
-format, and it will take some effort to maintain compatibility with
-the previous version.</span> Only add an instruction if it is absolutely
-necessary.</p>
-
-<ol>
-
-<li><tt>llvm/include/llvm/Instruction.def</tt>:
-    add a number for your instruction and an enum name</li>
-
-<li><tt>llvm/include/llvm/Instructions.h</tt>:
-    add a definition for the class that will represent your instruction</li>
-
-<li><tt>llvm/include/llvm/Support/InstVisitor.h</tt>:
-    add a prototype for a visitor to your new instruction type</li>
-
-<li><tt>llvm/lib/AsmParser/Lexer.l</tt>:
-    add a new token to parse your instruction from assembly text file</li>
-
-<li><tt>llvm/lib/AsmParser/llvmAsmParser.y</tt>:
-    add the grammar on how your instruction can be read and what it will
-    construct as a result</li>
-
-<li><tt>llvm/lib/Bytecode/Reader/InstructionReader.cpp</tt>:
-    add a case for your instruction and how it will be parsed from bytecode</li>
-
-<li><tt>llvm/lib/VMCore/Instruction.cpp</tt>:
-    add a case for how your instruction will be printed out to assembly</li>
-
-<li><tt>llvm/lib/VMCore/Instructions.cpp</tt>:
-    implement the class you defined in <tt>llvm/include/llvm/Instructions.h</tt></li>
-
-</ol>
-
-<p>Also, you need to implement (or modify) any analyses or passes that you want
-to understand this new instruction.</p>
-
-</div>
-
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
-  <a name="type">Adding a new type</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p><span class="doc_warning">WARNING: adding new types changes the bytecode
-format, and will break compatibility with currently-existing LLVM
-installations.</span> Only add new types if it is absolutely necessary.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="fund_type">Adding a fundamental type</a>
-</div>
-
-<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 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>;
-    initialize the static <tt>Type*</tt></li>
-
-<li><tt>llvm/lib/AsmReader/Lexer.l</tt>:
-    add ability to parse in the type from text assembly</li>
-
-<li><tt>llvm/lib/AsmReader/llvmAsmParser.y</tt>:
-    add a token for that type</li>
-
-</ol>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="derived_type">Adding a derived type</a>
-</div>
-
-<div class="doc_text">
-
-<p>TODO</p>
-
-</div>
-
-<!-- *********************************************************************** -->
-
-<hr>
-<address>
-  <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
-  src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a>
-  <a href="http://validator.w3.org/check/referer"><img
-  src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /></a>
-
-  <a href="http://misha.brukman.net">Misha Brukman</a><br>
-  <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
-  <br>
-  Last modified: $Date$
-</address>
-
-</body>
-</html>

llvm/docs/FAQ.html

@@ -3,7 +3,7 @@
 <html>
 <head>
   <title>LLVM: Frequently Asked Questions</title>
-  <style type="text/css">
+  <style>
     @import url("llvm.css");
     .question { font-weight: bold }
     .answer   { margin-left: 2em  }
@@ -48,9 +48,7 @@
   errors.</li>
   <li>I've built LLVM and am testing it, but the tests freeze.</li>
   <li>Why do test results differ when I perform different types of builds?</li>
-  <li>Compiling LLVM with GCC 3.3.2 fails, what should I do?</li>
-  <li>When I use the test suite, all of the C Backend tests fail.  What is
-      wrong?</li>
+  <li>Compiling LLVM with GCC 3.3 on SuSE 9 fails, what should I do?</li>
   </ol></li>
 
   <li><a href="#cfe">Using the GCC Front End</a>
@@ -63,7 +61,7 @@
 
     <li>
     When I compile code using the LLVM GCC front end, it complains that it
-    cannot find libcrtend.a.
+    cannot find crtend.o.
     </li>
   </ol>
   </li>
@@ -72,19 +70,10 @@
   <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
-          <tt>_GLOBAL__I__tmp_webcompile...</tt> stuff that happens when I
-          #include &lt;iostream&gt;?</li>
   </ol>
   </li>
 </ol>
 
-<div class="doc_author">
-  <p>Written by <a href="http://llvm.cs.uiuc.edu">The LLVM Team</a></p>
-</div>
-
-
 <!-- *********************************************************************** -->
 <div class="doc_section">
   <a name="license">License</a>
@@ -121,7 +110,7 @@ Source Initiative (OSI).</p>
 <div class="answer">
 <p>Yes.  The modified source distribution must retain the copyright notice and
 follow the three bulletted conditions listed in the <a
-href="http://llvm.cs.uiuc.edu/releases/1.2/LICENSE.TXT">LLVM license</a>.</p>
+href="http://llvm.cs.uiuc.edu/releases/1.0/LICENSE.TXT">LLVM license</a>.</p>
 </div>
 
 <div class="question">
@@ -236,7 +225,7 @@ it:</p>
   <li><p>Run <tt>configure</tt> with an alternative <tt>PATH</tt> that is
   correct. In a Borne compatible shell, the syntax would be:</p>
 		
-      <p><tt>PATH=[the path without the bad program] ./configure ...</tt></p>
+      <p><tt>PATH=<the path without the bad program> ./configure ...</tt></p>
 
       <p>This is still somewhat inconvenient, but it allows <tt>configure</tt>
       to do its work without having to adjust your <tt>PATH</tt>
@@ -340,37 +329,12 @@ build.</p>
 </div>
 
 <div class="question">
-<p>Compiling LLVM with GCC 3.3.2 fails, what should I do?</p>
+<p>Compiling LLVM with GCC 3.3 on SuSE 9 fails, what should I do?</p>
 </div>
 
 <div class="answer">
-<p>This is <a href="http://gcc.gnu.org/PR?13392">a bug in GCC</a>, and 
-   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>
+<p>This is a bug in the customized version of GCC shipped with SuSE, and affects
+   projects other than LLVM.  Complain loudly to SuSE.  :)</p>
 </div>
 
 <!-- *********************************************************************** -->
@@ -423,13 +387,13 @@ not linking on your system because the feature isn't available on your system.
 <div class="question">
 <p>
 When I compile code using the LLVM GCC front end, it complains that it cannot
-find libcrtend.a.
+find crtend.o.
 </p>
 </div>
 
 <div class="answer">
 <p>
-In order to find libcrtend.a, you must have the directory in which it lives in
+In order to find crtend.o, 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.
@@ -442,9 +406,11 @@ directory inside of the LLVM GCC distribution.
   <a name="cfe_code">Questions about code generated by the GCC front-end</a>
 </div>
 
-<div class="question"><p>
+<div class="question">
+<p>
 What is this <tt>__main()</tt> call that gets inserted into <tt>main()</tt>?
-</p></div>
+</p>
+</div>
 
 <div class="answer">
 <p>
@@ -460,74 +426,20 @@ The actual implementation of <tt>__main</tt> lives in the
 <tt>llvm/runtime/GCCLibraries/crtend/</tt> directory in the source-base, and is
 linked in automatically when you link the program.
 </p>
+
 </div>
 
-<!--=========================================================================-->
 
-<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"><p>
-What is this <tt>llvm.global_ctors</tt> and <tt>_GLOBAL__I__tmp_webcompile...</tt> stuff that happens when I #include &lt;iostream&gt;?
-</p></div>
-
-<div class="answer">
-<p>
-If you #include the &lt;iostream&gt; header into a C++ translation unit, the
-file will probably use the <tt>std::cin</tt>/<tt>std::cout</tt>/... global
-objects.  However, C++ does not guarantee an order of initialization between
-static objects in different translation units, so if a static ctor/dtor in your
-.cpp file used <tt>std::cout</tt>, for example, the object would not necessarily
-be automatically initialized before your use.
-</p>
-
-<p>
-To make <tt>std::cout</tt> and friends work correctly in these scenarios, the
-STL that we use declares a static object that gets created in every translation
-unit that includes &lt;iostream&gt;.  This object has a static constructor and
-destructor that initializes and destroys the global iostream objects before they
-could possibly be used in the file.  The code that you see in the .ll file
-corresponds to the constructor and destructor registration code.
-</p>
-
-<p>
-If you would like to make it easier to <b>understand</b> the LLVM code generated
-by the compiler in the demo page, consider using printf instead of iostreams to
-print values.
-</p>
-</div>
 
+<!-- *********************************************************************** -->
 <!-- *********************************************************************** -->
 
 <hr>
-<address>
-  <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
-  src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a>
-  <a href="http://validator.w3.org/check/referer"><img
-  src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"></a>
-
-  <a href="http://llvm.cs.uiuc.edu">LLVM Compiler Infrastructure</a><br>
+<div class="doc_footer">
+  <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
+  <br>
   Last modified: $Date$
-</address>
+</div>
 
 </body>
 </html>

llvm/docs/GarbageCollection.html

@@ -1,533 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
-                      "http://www.w3.org/TR/html4/strict.dtd">
-<html>
-<head>
-  <title>Accurate Garbage Collection with LLVM</title>
-  <link rel="stylesheet" href="llvm.css" type="text/css">
-</head>
-<body>
-
-<div class="doc_title">
-  Accurate Garbage Collection with LLVM
-</div>
-
-<ol>
-  <li><a href="#introduction">Introduction</a>
-    <ul>
-    <li><a href="#feature">GC features provided and algorithms supported</a></li>
-    </ul>
-  </li>
-
-  <li><a href="#interfaces">Interfaces for user programs</a>
-    <ul>
-    <li><a href="#roots">Identifying GC roots on the stack: <tt>llvm.gcroot</tt></a></li>
-    <li><a href="#allocate">Allocating memory from the GC</a></li>
-    <li><a href="#barriers">Reading and writing references to the heap</a></li>
-    <li><a href="#explicit">Explicit invocation of the garbage collector</a></li>
-    </ul>
-  </li>
-
-  <li><a href="#gcimpl">Implementing a garbage collector</a>
-    <ul>
-    <li><a href="#llvm_gc_readwrite">Implementing <tt>llvm_gc_read</tt> and <tt>llvm_gc_write</tt></a></li>
-    <li><a href="#callbacks">Callback functions used to implement the garbage collector</a></li>
-    </ul>
-  </li>
-  <li><a href="#gcimpls">GC implementations available</a>
-    <ul>
-    <li><a href="#semispace">SemiSpace - A simple copying garbage collector</a></li>
-    </ul>
-  </li>
-
-<!--
-  <li><a href="#codegen">Implementing GC support in a code generator</a></li>
--->
-</ol>
-
-<div class="doc_author">
-  <p>Written by <a href="mailto:sabre@nondot.org">Chris Lattner</a></p>
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
-  <a name="introduction">Introduction</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>Garbage collection is a widely used technique that frees the programmer from
-having to know the life-times of heap objects, making software easier to produce
-and maintain.  Many programming languages rely on garbage collection for
-automatic memory management.  There are two primary forms of garbage collection:
-conservative and accurate.</p>
-
-<p>Conservative garbage collection often does not require any special support
-from either the language or the compiler: it can handle non-type-safe
-programming languages (such as C/C++) and does not require any special
-information from the compiler.  The [LINK] Boehm collector is an example of a
-state-of-the-art conservative collector.</p>
-
-<p>Accurate garbage collection requires the ability to identify all pointers in
-the program at run-time (which requires that the source-language be type-safe in
-most cases).  Identifying pointers at run-time requires compiler support to
-locate all places that hold live pointer variables at run-time, including the
-<a href="#roots">processor stack and registers</a>.</p>
-
-<p>
-Conservative garbage collection is attractive because it does not require any
-special compiler support, but it does have problems.  In particular, because the
-conservative garbage collector cannot <i>know</i> that a particular word in the
-machine is a pointer, it cannot move live objects in the heap (preventing the
-use of compacting and generational GC algorithms) and it can occasionally suffer
-from memory leaks due to integer values that happen to point to objects in the
-program.  In addition, some aggressive compiler transformations can break
-conservative garbage collectors (though these seem rare in practice).
-</p>
-
-<p>
-Accurate garbage collectors do not suffer from any of these problems, but they
-can suffer from degraded scalar optimization of the program.  In particular,
-because the runtime must be able to identify and update all pointers active in
-the program, some optimizations are less effective.  In practice, however, the
-locality and performance benefits of using aggressive garbage allocation
-techniques dominates any low-level losses.
-</p>
-
-<p>
-This document describes the mechanisms and interfaces provided by LLVM to
-support accurate garbage collection.
-</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="feature">GC features provided and algorithms supported</a>
-</div>
-
-<div class="doc_text">
-
-<p>
-LLVM provides support for a broad class of garbage collection algorithms,
-including compacting semi-space collectors, mark-sweep collectors, generational
-collectors, and even reference counting implementations.  It includes support
-for <a href="#barriers">read and write barriers</a>, and associating <a
-href="#roots">meta-data with stack objects</a> (used for tagless garbage
-collection).  All LLVM code generators support garbage collection, including the
-C backend.
-</p>
-
-<p>
-We hope that the primitive support built into LLVM is sufficient to support a
-broad class of garbage collected languages, including Scheme, ML, scripting
-languages, Java, C#, etc.  That said, the implemented garbage collectors may
-need to be extended to support language-specific features such as finalization,
-weak references, or other features.  As these needs are identified and
-implemented, they should be added to this specification.
-</p>
-
-<p>
-LLVM does not currently support garbage collection of multi-threaded programs or
-GC-safe points other than function calls, but these will be added in the future
-as there is interest.
-</p>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
-  <a name="interfaces">Interfaces for user programs</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>This section describes the interfaces provided by LLVM and by the garbage
-collector run-time that should be used by user programs.  As such, this is the
-interface that front-end authors should generate code for.
-</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="roots">Identifying GC roots on the stack: <tt>llvm.gcroot</tt></a>
-</div>
-
-<div class="doc_text">
-
-<div class="doc_code"><tt>
-  void %llvm.gcroot(&lt;ty&gt;** %ptrloc, &lt;ty2&gt;* %metadata)
-</tt></div>
-
-<p>
-The <tt>llvm.gcroot</tt> intrinsic is used to inform LLVM of a pointer variable
-on the stack.  The first argument contains the address of the variable on the
-stack, and the second contains a pointer to metadata that should be associated
-with the pointer (which <b>must</b> be a constant or global value address).  At
-runtime, the <tt>llvm.gcroot</tt> intrinsic stores a null pointer into the
-specified location to initialize the pointer.</p>
-
-<p>
-Consider the following fragment of Java code:
-</p>
-
-<pre>
-       {
-         Object X;   // A null-initialized reference to an object
-         ...
-       }
-</pre>
-
-<p>
-This block (which may be located in the middle of a function or in a loop nest),
-could be compiled to this LLVM code:
-</p>
-
-<pre>
-Entry:
-   ;; In the entry block for the function, allocate the
-   ;; stack space for X, which is an LLVM pointer.
-   %X = alloca %Object*
-   ...
-
-   ;; "CodeBlock" is the block corresponding to the start
-   ;;  of the scope above.
-CodeBlock:
-   ;; Initialize the object, telling LLVM that it is now live.
-   ;; Java has type-tags on objects, so it doesn't need any
-   ;; metadata.
-   call void %llvm.gcroot(%Object** %X, sbyte* null)
-   ...
-
-   ;; As the pointer goes out of scope, store a null value into
-   ;; it, to indicate that the value is no longer live.
-   store %Object* null, %Object** %X
-   ...
-</pre>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="allocate">Allocating memory from the GC</a>
-</div>
-
-<div class="doc_text">
-
-<div class="doc_code"><tt>
-  sbyte *%llvm_gc_allocate(unsigned %Size)
-</tt></div>
-
-<p>The <tt>llvm_gc_allocate</tt> function is a global function defined by the
-garbage collector implementation to allocate memory.  It returns a
-zeroed-out block of memory of the appropriate size.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="barriers">Reading and writing references to the heap</a>
-</div>
-
-<div class="doc_text">
-
-<div class="doc_code"><tt>
-  sbyte *%llvm.gcread(sbyte *, sbyte **)<br>
-  void %llvm.gcwrite(sbyte*, sbyte*, sbyte**)
-</tt></div>
-
-<p>Several of the more interesting garbage collectors (e.g., generational
-collectors) need to be informed when the mutator (the program that needs garbage
-collection) reads or writes object references into the heap.  In the case of a
-generational collector, it needs to keep track of which "old" generation objects
-have references stored into them.  The amount of code that typically needs to be
-executed is usually quite small (and not on the critical path of any 
-computation), so the overall performance impact of the inserted code is 
-tolerable.</p>
-
-<p>To support garbage collectors that use read or write barriers, LLVM provides
-the <tt>llvm.gcread</tt> and <tt>llvm.gcwrite</tt> intrinsics.  The first
-intrinsic has exactly the same semantics as a non-volatile LLVM load and the
-second has the same semantics as a non-volatile LLVM store, with the
-additions that they also take a pointer to the start of the memory
-object as an argument.  At code generation
-time, these intrinsics are replaced with calls into the garbage collector
-(<tt><a href="#llvm_gc_readwrite">llvm_gc_read</a></tt> and <tt><a
-href="#llvm_gc_readwrite">llvm_gc_write</a></tt> respectively), which are then
-inlined into the code.
-</p>
-
-<p>
-If you are writing a front-end for a garbage collected language, every load or
-store of a reference from or to the heap should use these intrinsics instead of
-normal LLVM loads/stores.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="initialize">Garbage collector startup and initialization</a>
-</div>
-
-<div class="doc_text">
-
-<div class="doc_code"><tt>
-  void %llvm_gc_initialize(unsigned %InitialHeapSize)
-</tt></div>
-
-<p>
-The <tt>llvm_gc_initialize</tt> function should be called once before any other
-garbage collection functions are called.  This gives the garbage collector the
-chance to initialize itself and allocate the heap spaces.  The initial heap size
-to allocate should be specified as an argument.
-</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="explicit">Explicit invocation of the garbage collector</a>
-</div>
-
-<div class="doc_text">
-
-<div class="doc_code"><tt>
-  void %llvm_gc_collect()
-</tt></div>
-
-<p>
-The <tt>llvm_gc_collect</tt> function is exported by the garbage collector
-implementations to provide a full collection, even when the heap is not
-exhausted.  This can be used by end-user code as a hint, and may be ignored by
-the garbage collector.
-</p>
-
-</div>
-
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
-  <a name="gcimpl">Implementing a garbage collector</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>
-Implementing a garbage collector for LLVM is fairly straight-forward.  The LLVM
-garbage collectors are provided in a form that makes them easy to link into the
-language-specific runtime that a language front-end would use.  They require
-functionality from the language-specific runtime to get information about <a
-href="#gcdescriptors">where pointers are located in heap objects</a>.
-</p>
-
-<p>The
-implementation must include the <a
-href="#allocate"><tt>llvm_gc_allocate</tt></a> and <a
-href="#explicit"><tt>llvm_gc_collect</tt></a> functions, and it must implement
-the <a href="#llvm_gc_readwrite">read/write barrier</a> functions as well.  To
-do this, it will probably have to <a href="#traceroots">trace through the roots
-from the stack</a> and understand the <a href="#gcdescriptors">GC descriptors
-for heap objects</a>.  Luckily, there are some <a href="#gcimpls">example
-implementations</a> available.
-</p>
-</div>
-
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="llvm_gc_readwrite">Implementing <tt>llvm_gc_read</tt> and <tt>llvm_gc_write</tt></a>
-</div>
-
-<div class="doc_text">
-  <div class="doc_code"><tt>
-    void *llvm_gc_read(void*, void **)<br>
-    void llvm_gc_write(void*, void *, void**)
- </tt></div>
-
-<p>
-These functions <i>must</i> be implemented in every garbage collector, even if
-they do not need read/write barriers.  In this case, just load or store the
-pointer, then return.
-</p>
-
-<p>
-If an actual read or write barrier is needed, it should be straight-forward to
-implement it.
-</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="callbacks">Callback functions used to implement the garbage collector</a>
-</div>
-
-<div class="doc_text">
-<p>
-Garbage collector implementations make use of call-back functions that are
-implemented by other parts of the LLVM system.
-</p>
-</div>
-
-<!--_________________________________________________________________________-->
-<div class="doc_subsubsection">
-  <a name="traceroots">Tracing GC pointers from the program stack</a>
-</div>
-
-<div class="doc_text">
-  <div class="doc_code"><tt>
-     void llvm_cg_walk_gcroots(void (*FP)(void **Root, void *Meta));
-  </tt></div>
-
-<p>
-The <tt>llvm_cg_walk_gcroots</tt> function is a function provided by the code
-generator that iterates through all of the GC roots on the stack, calling the
-specified function pointer with each record.  For each GC root, the address of
-the pointer and the meta-data (from the <a
-href="#gcroot"><tt>llvm.gcroot</tt></a> intrinsic) are provided.
-</p>
-</div>
-
-<!--_________________________________________________________________________-->
-<div class="doc_subsubsection">
-  <a name="staticroots">Tracing GC pointers from static roots</a>
-</div>
-
-<div class="doc_text">
-TODO
-</div>
-
-
-<!--_________________________________________________________________________-->
-<div class="doc_subsubsection">
-  <a name="gcdescriptors">Tracing GC pointers from heap objects</a>
-</div>
-
-<div class="doc_text">
-<p>
-The three most common ways to keep track of where pointers live in heap objects
-are (listed in order of space overhead required):</p>
-
-<ol>
-<li>In languages with polymorphic objects, pointers from an object header are
-usually used to identify the GC pointers in the heap object.  This is common for
-object-oriented languages like Self, Smalltalk, Java, or C#.</li>
-
-<li>If heap objects are not polymorphic, often the "shape" of the heap can be
-determined from the roots of the heap or from some other meta-data [<a
-href="#appel89">Appel89</a>, <a href="#goldberg91">Goldberg91</a>, <a
-href="#tolmach94">Tolmach94</a>].  In this case, the garbage collector can
-propagate the information around from meta data stored with the roots.  This
-often eliminates the need to have a header on objects in the heap.  This is
-common in the ML family.</li>
-
-<li>If all heap objects have pointers in the same locations, or pointers can be
-distinguished just by looking at them (e.g., the low order bit is clear), no
-book-keeping is needed at all.  This is common for Lisp-like languages.</li>
-</ol>
-
-<p>The LLVM garbage collectors are capable of supporting all of these styles of
-language, including ones that mix various implementations.  To do this, it
-allows the source-language to associate meta-data with the <a
-href="#roots">stack roots</a>, and the heap tracing routines can propagate the
-information.  In addition, LLVM allows the front-end to extract GC information
-from in any form from a specific object pointer (this supports situations #1 and
-#3).
-</p>
-
-<p><b>Making this efficient</b></p>
-
-
-
-</div>
-
-
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
-  <a name="gcimpls">GC implementations available</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>
-To make this more concrete, the currently implemented LLVM garbage collectors
-all live in the <tt>llvm/runtime/GC/*</tt> directories in the LLVM source-base.
-If you are interested in implementing an algorithm, there are many interesting
-possibilities (mark/sweep, a generational collector, a reference counting
-collector, etc), or you could choose to improve one of the existing algorithms.
-</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="semispace">SemiSpace - A simple copying garbage collector</a>
-</div>
-
-<div class="doc_text">
-<p>
-SemiSpace is a very simple copying collector.  When it starts up, it allocates
-two blocks of memory for the heap.  It uses a simple bump-pointer allocator to
-allocate memory from the first block until it runs out of space.  When it runs
-out of space, it traces through all of the roots of the program, copying blocks
-to the other half of the memory space.
-</p>
-
-</div>
-
-<!--_________________________________________________________________________-->
-<div class="doc_subsubsection">
-  Possible Improvements
-</div>
-
-<div class="doc_text">
-
-<p>
-If a collection cycle happens and the heap is not compacted very much (say less
-than 25% of the allocated memory was freed), the memory regions should be
-doubled in size.</p>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
-  <a name="references">References</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p><a name="appel89">[Appel89]</a> Runtime Tags Aren't Necessary. Andrew
-W. Appel. Lisp and Symbolic Computation 19(7):703-705, July 1989.</p>
-
-<p><a name="goldberg91">[Goldberg91]</a> Tag-free garbage collection for
-strongly typed programming languages.  Benjamin Goldberg. ACM SIGPLAN
-PLDI'91.</p>
-
-<p><a name="tolmach94">[Tolmach94]</a> Tag-free garbage collection using
-explicit type parameters.  Andrew Tolmach.  Proceedings of the 1994 ACM
-conference on LISP and functional programming.</p>
-
-</div>
-
-<!-- *********************************************************************** -->
-
-<hr>
-<address>
-  <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
-  src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a>
-  <a href="http://validator.w3.org/check/referer"><img
-  src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"></a>
-
-  <a href="mailto:sabre@nondot.org">Chris Lattner</a><br>
-  <a href="http://llvm.cs.uiuc.edu">LLVM Compiler Infrastructure</a><br>
-  Last modified: $Date$
-</address>
-
-</body>
-</html>

llvm/docs/GettingStarted.html

@@ -18,7 +18,6 @@
     <ol>
       <li><a href="#hardware">Hardware</a>
       <li><a href="#software">Software</a>
-      <li><a href="#brokengcc">Broken versions of GCC</a>
     </ol></li>
 
   <li><a href="#starting">Getting Started with LLVM</a>
@@ -31,7 +30,6 @@
       <li><a href="#config">Local LLVM Configuration</a>
       <li><a href="#compile">Compiling the LLVM Suite Source Code</a>
       <li><a href="#objfiles">The Location of LLVM Object Files</a>
-      <li><a href="#optionalconfig">Optional Configuration Items</a>
     </ol></li>
 
   <li><a href="#layout">Program layout</a>
@@ -50,15 +48,12 @@
   <li><a href="#links">Links</a>
 </ul>
 
-<div class="doc_author">
-  <p>Written by: 
-    <a href="mailto:criswell@uiuc.edu">John Criswell</a>, 
-    <a href="mailto:sabre@nondot.org">Chris Lattner</a>,
-    <a href="http://misha.brukman.net">Misha Brukman</a>, 
-    <a href="http://www.cs.uiuc.edu/~vadve">Vikram Adve</a>, and
-    <a href="mailto:gshi1@uiuc.edu">Guochun Shi</a>.
-  </p>
-</div>
+<p>By: 
+  <a href="mailto:gshi1@uiuc.edu">Guochun Shi</a>,
+  <a href="mailto:sabre@nondot.org">Chris Lattner</a>,
+  <a href="mailto:criswell@uiuc.edu">John Criswell</a>, 
+  <a href="http://misha.brukman.net">Misha Brukman</a>, and
+  <a href="http://www.cs.uiuc.edu/~vadve">Vikram Adve</a>.</p>
 
 
 <!-- *********************************************************************** -->
@@ -101,8 +96,8 @@ from the LLVM suite.</p>
     <ol>
       <li><tt>cd <i>where-you-want-the-C-front-end-to-live</i></tt>
       <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>
+      <li><b>Sparc Only:</b><br>
+      <tt>cd cfrontend/sparc<br>
           ./fixheaders</tt>
     </ol></li>
 
@@ -111,11 +106,11 @@ from the LLVM suite.</p>
     <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>
+      <li><tt>gunzip --stdout llvm.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>):
+    <li>With anonymous CVS access:
     <ol>
       <li><tt>cd <i>where-you-want-llvm-to-live</i></tt></li>
       <li><tt>cvs -d
@@ -145,15 +140,14 @@ 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>
+      <li>Set your LLVM_LIB_SEARCH_PATH environment variable.
+      <li><tt>gmake -k |& tee gnumake.out
+      &nbsp;&nbsp;&nbsp;# this is csh or tcsh syntax</tt>
   </ol>
 
 </ol>
 
-<p>Consult the <a href="#starting">Getting Started with LLVM</a> section for
+<p>Consult the <a href="starting">Getting Started with LLVM</a> section for
 detailed information on configuring and compiling LLVM.  See <a
 href="#environment">Setting Up Your Environment</a> for tips that simplify
 working with the GCC front end and LLVM tools.  Go to <a href="#layout">Program
@@ -188,45 +182,51 @@ software you will need.</p>
 
   <li>Linux on x86 (Pentium and above)
   <ul>
-    <li>Approximately 2.6 GB of Free Disk Space
+    <li>Approximately 918 MB of Free Disk Space
     <ul>
-      <li>Source code: 57 MB</li>
-      <li>Object code: 2.5 GB</li>
-      <li>GCC front end: 30 MB</li>
-    </ul></li>
-  </ul>
-  </li>
-
-  <li>Solaris on SparcV9 (Ultrasparc)
-  <ul>
-    <li>Approximately 2.6 GB of Free Disk Space
-      <ul>
-        <li>Source code: 57 MB</li>
-        <li>Object code: 2.5 GB</li>
-        <li>GCC front end: 46 MB</li>
-      </ul></li>
-  </ul>
-  </li>
-
-  <li>FreeBSD on x86 (Pentium and above)
-  <ul>
-    <li>Approximately 1 GB of Free Disk Space
-    <ul>
-      <li>Source code: 57 MB</li>
+      <li>Source code: 28 MB</li>
       <li>Object code: 850 MB</li>
       <li>GCC front end: 40 MB</li>
     </ul></li>
   </ul>
   </li>
 
+  <p></p>
+
+  <li>Solaris on SparcV9 (Ultrasparc)
+  <ul>
+    <li>Approximately 1.52 GB of Free Disk Space
+      <ul>
+        <li>Source code: 28 MB</li>
+        <li>Object code: 1470 MB</li>
+        <li>GCC front end: 50 MB</li>
+      </ul></li>
+  </ul>
+  </li>
+
+  <p></p>
+
+  <li>FreeBSD on x86 (Pentium and above)
+  <ul>
+    <li>Approximately 918 MB of Free Disk Space
+    <ul>
+      <li>Source code: 28 MB</li>
+      <li>Object code: 850 MB</li>
+      <li>GCC front end: 40 MB</li>
+    </ul></li>
+  </ul>
+  </li>
+
+  <p></p>
+
   <li>MacOS X on PowerPC
   <ul>
-    <li>Experimental support for static native code generation
-    <li>Approximately 1.6 GB of Free Disk Space
+    <li>No native code generation
+    <li>Approximately 1.20 GB of Free Disk Space
       <ul>
-        <li>Source code: 57 MB</li>
-        <li>Object code: 1.5 GB</li>
-        <li>GCC front end: 36 MB</li>
+        <li>Source code: 28 MB</li>
+        <li>Object code: 1160 MB</li>
+        <li>GCC front end: 40 MB</li>
       </ul></li>
   </ul>
 
@@ -240,7 +240,8 @@ generation should work as well, although the generated native code may not work
 on your platform.</p>
 
 <p>The GCC front end is not very portable at the moment.  If you want to get it
-to work on another platform, you can download a copy of the source and <a href="CFEBuildInstrs.html">try to compile it</a> on your platform.</p>
+to work on another platform, you can download a copy of the source and try to
+compile it on your platform.</p>
 
 </div>
 
@@ -256,7 +257,7 @@ installed:</p>
 
 <ul>
   <li><a href="http://gcc.gnu.org">GCC 3.x with C and C++ language
-  support</a>  (See <a href="#brokengcc">below</a> for specific version info)</li>
+  support</a></li>
 
   <li><a href="http://savannah.gnu.org/projects/make">GNU Make</a></li>
 
@@ -269,85 +270,39 @@ installed:</p>
 LLVM:</p>
 
 <ul>
-  <li><A href="http://www.gnu.org/software/automake">GNU Automake</A></li>
-  <li><A href="http://www.gnu.org/software/autoconf">GNU Autoconf</A></li>
+  <li><A href="http://www.gnu.org/software/autoconf">GNU Autoconf</A>
   <li><A href="http://savannah.gnu.org/projects/m4">GNU M4</A>
 
       <p>If you want to make changes to the configure scripts, you will need GNU
       autoconf (2.57 or higher), and consequently, GNU M4 (version 1.4 or
-      higher). You will also need automake. Any old version of
-      automake from 1.4p5 on should work; we only use aclocal from that
-      package.</p></li>
+      higher).</p></li>
 
-  <li><A href="http://www.codesourcery.com/qm/qmtest">QMTest 2.0.3</A></li>
+  <li><A href="http://www.codesourcery.com/qm/qmtest">QMTest</A></li>
   <li><A href="http://www.python.org">Python</A>
 
-      <p>
-      These are needed to use the LLVM test suite.  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:</p>
-      <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>
+      <p>These are needed to use the LLVM test suite.</p></li>
 
 </ul>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="brokengcc">Broken versions of GCC</a>
-</div>
-
-<div class="doc_text">
-
-<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
-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
-us know</a>.  Please use the "<tt>gcc -v</tt>" command to find out which version
-of GCC you are using.
-</p>
-
-<p><b>GCC versions prior to 3.0</b>: GCC 2.96.x and before had several
-problems in the STL that effectively prevent it from compiling LLVM.
-</p>
-
-<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>
-
-</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 and to give you some basic information about the LLVM environment.</p>
+LLVM and to give you some basic information about the LLVM environment.
+A <a href="#starting">complete guide to installation</a> is provided in the
+next section.</p>
 
 <p>The later sections of this guide describe the <a
 href="#layout">general layout</a> of the the LLVM source tree, a <a
 href="#tutorial">simple example</a> using the LLVM tool chain, and <a
 href="#links">links</a> to find more information about LLVM or to get
 help via e-mail.</p>
+
 </div>
 
+<!-- *********************************************************************** -->
+<div class="doc_section">
+  <a name="starting"><b>Getting Started with LLVM</b></a>
+</div>
+<!-- *********************************************************************** -->
+
 <!-- ======================================================================= -->
 <div class="doc_subsection">
   <a name="terminology">Terminology and Notation</a>
@@ -362,7 +317,7 @@ 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>
+<dl compact>
     <dt>SRC_ROOT
     <dd>
     This is the top level directory of the LLVM source tree.
@@ -398,7 +353,7 @@ 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>.
 
-<dl>
+<dl compact>
     <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
@@ -416,7 +371,7 @@ You can set these on the command line, or better yet, set them in your
 
 <!-- ======================================================================= -->
 <div class="doc_subsection">
-  <a name="unpack">Unpacking the LLVM Archives</a>
+  <a name="unpack">Unpacking the LLVM Archives</a></h3>
 </div>
 
 <div class="doc_text">
@@ -429,24 +384,24 @@ file is a TAR archive that is compressed with the gzip program.
 </p>
 
 <p> The files are as follows:
-<dl>
-    <dt>llvm-1.3.tar.gz
+<dl compact>
+    <dt>llvm-1.1.tar.gz
     <dd>This is the source code to the LLVM suite.
     <p>
 
-    <dt>cfrontend-1.3.sparc-sun-solaris2.8.tar.gz
+    <dt>cfrontend-1.1.sparc-sun-solaris2.8.tar.gz
     <dd>This is the binary release of the GCC front end for Solaris/Sparc.
     <p>
 
-    <dt>cfrontend-1.3.i686-redhat-linux-gnu.tar.gz
+    <dt>cfrontend-1.1.i686-redhat-linux-gnu.tar.gz
     <dd>This is the binary release of the GCC front end for Linux/x86.
     <p>
 
-    <dt>cfrontend-1.3.i386-unknown-freebsd5.1.tar.gz
+    <dt>cfrontend-1.1.i386-unknown-freebsd5.1.tar.gz
     <dd>This is the binary release of the GCC front end for FreeBSD/x86.
     <p>
 
-    <dt>cfrontend-1.3.powerpc-apple-darwin7.0.0.tar.gz
+    <dt>cfrontend-1.1.powerpc-apple-darwin7.0.0.tar.gz
     <dd>This is the binary release of the GCC front end for MacOS X/PPC.
 </dl>
 
@@ -454,7 +409,7 @@ file is a TAR archive that is compressed with the gzip program.
 
 <!-- ======================================================================= -->
 <div class="doc_subsection">
-  <a name="checkout">Checkout LLVM from CVS</a>
+  <a name="checkout">Checkout LLVM from CVS</a></h3>
 </div>
 
 <div class="doc_text">
@@ -475,48 +430,28 @@ follows:</p>
 directory and fully populate it with the LLVM source code, Makefiles,
 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>
-
+<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:
 <ul>
-<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>
+  <li>
+  Release 1.1: <b>RELEASE_11</b>
+  </li>
+
+  <li>
+  Release 1.0: <b>RELEASE_1</b>
+  </li>
 </ul>
+</p>
 
-<p>If you would like to get the GCC front end source code, you can also get it
-from the CVS repository:</p>
+<p>Note that the GCC front end is not included in the CVS repository. You
+should have downloaded the binary distribution for your platform.</p>
 
-<pre>
-  cvs -z3 -d :pserver:anon@llvm-cvs.cs.uiuc.edu:/var/cvs/llvm co llvm-gcc
-</pre>
-
-<p>Please note that you must follow <a href="CFEBuildInstrs.html">these 
-instructions</a> to successfully build the LLVM C front-end.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsubsection">
-  <a name="mirrors">LLVM CVS Mirrors</a>
-</div>
-
-<div class="doc_text">
-
-<p>If the main CVS server is overloaded or inaccessible, you can try one of
-these user-hosted mirrors:</p>
-
-<ul>
-<li><a href="http://llvm.x10sys.com/">Mirror hosted by eXtensible Systems
-Inc.</a></li>
-</ul>
 </div>
 
 <!-- ======================================================================= -->
 <div class="doc_subsection">
-  <a name="installcf">Install the GCC Front End</a>
+  <a name="installcf">Install the GCC Front End</a></h3>
 </div>
 
 <div class="doc_text">
@@ -537,7 +472,7 @@ location must be specified when the LLVM suite is configured.</p>
 <p>If you are using Solaris/Sparc or MacOS X/PPC, you will need to fix the
 header files:</p>
 
-<p><tt>cd cfrontend/<i>platform</i><br>
+<p><tt>cd cfrontend/sparc<br>
    ./fixheaders</tt></p>
 
 <p>The binary versions of the GCC front end may not suit all of your needs.  For
@@ -592,10 +527,10 @@ script to configure the build system:</p>
 
 <p>The following options can be used to set or enable LLVM specific options:</p>
 
-<dl>
+<dl compact>
   <dt><i>--with-llvmgccdir=LLVMGCCDIR</i>
   <dd>
-    Path to the location where the LLVM GCC front end binaries and
+    Path to the location where the LLVM C front end binaries and
     associated libraries were installed.  This must be specified as an
     absolute pathname.
     <p>
@@ -621,19 +556,6 @@ script to configure the build system:</p>
     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>
 
 <p>To configure LLVM, follow these steps:</p>
@@ -672,7 +594,7 @@ version of the GCC front end on our research machines.</p>
 <p>Once you have configured LLVM, you can build it.  There are three types of
 builds:</p>
 
-<dl>
+<dl compact>
     <dt>Debug Builds
     <dd>
     These builds are the default when one types <tt>gmake</tt> (unless the
@@ -703,11 +625,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>
-
-<p>
-If you have multiple processors in your machine, you may wish to use some of
+<p>If you have multiple processors in your machine, you may wish to use some of
 the parallel build options provided by GNU Make.  For example, you could use the
 command:</p>
 
@@ -716,7 +634,7 @@ command:</p>
 <p>There are several special targets which are useful when working with the LLVM
 source code:</p>
 
-<dl>
+<dl compact>
   <dt><tt>gmake clean</tt>
   <dd>
   Removes all files generated by the build.  This includes object files,
@@ -743,7 +661,7 @@ source code:</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>
 
-<dl>
+<dl compact>
   <dt><tt>gmake ENABLE_OPTIMIZED=1</tt>
   <dd>
   Perform a Release (Optimized) build.
@@ -794,10 +712,10 @@ platforms or configurations using the same source tree.</p>
 <p>The LLVM build will place files underneath <i>OBJ_ROOT</i> in directories
 named after the build type:</p>
 
-<dl>
+<dl compact>
   <dt>Debug Builds
   <dd>
-  <dl>
+  <dl compact>
     <dt>Tools
     <dd><tt><i>OBJ_ROOT</i>/tools/Debug</tt>
     <dt>Libraries
@@ -807,7 +725,7 @@ named after the build type:</p>
 
   <dt>Release Builds
   <dd>
-  <dl>
+  <dl compact>
     <dt>Tools
     <dd><tt><i>OBJ_ROOT</i>/tools/Release</tt>
     <dt>Libraries
@@ -817,7 +735,7 @@ named after the build type:</p>
 
   <dt>Profile Builds
   <dd>
-  <dl>
+  <dl compact>
     <dt>Tools
     <dd><tt><i>OBJ_ROOT</i>/tools/Profile</tt>
     <dt>Libraries
@@ -827,35 +745,6 @@ named after the build type:</p>
 
 </div>
 
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="optionalconfig">Optional Configuration Items</a>
-</div>
-
-<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>"
-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>
-
-<pre>
-   $ mount -t binfmt_misc none /proc/sys/fs/binfmt_misc
-   $ echo ':llvm:M::llvm::/path/to/lli:' > /proc/sys/fs/binfmt_misc/register
-   $ chmod u+x hello.bc                (if needed)
-   $ ./hello.bc
-</pre>
-
-<p>
-This allows you to execute LLVM bytecode files directly.  Thanks to Jack
-Cummings for pointing this out!
-</p>
-
-</div>
-
-
 <!-- *********************************************************************** -->
 <div class="doc_section">
   <a name="layout"><b>Program Layout</b></a>
@@ -865,7 +754,7 @@ Cummings for pointing this out!
 <div class="doc_text">
 
 <p>One useful source of information about the LLVM source base is the LLVM <a
-href="http://www.doxygen.org">doxygen</a> documentation available at <tt><a
+href="http://www.doxygen.org">doxygen</a> documentation, available at <tt><a
 href="http://llvm.cs.uiuc.edu/doxygen/">http://llvm.cs.uiuc.edu/doxygen/</a></tt>.
 The following is a brief introduction to code layout:</p>
 
@@ -924,7 +813,7 @@ library. The three main subdirectories of this directory are:</p>
 almost all code exists in libraries, making it very easy to share code among the
 different <a href="#tools">tools</a>.</p>
 
-<dl>
+<dl compact>
   <dt><tt>llvm/lib/VMCore/</tt><dd> This directory holds the core LLVM
   source files that implement core classes like Instruction and BasicBlock.
 
@@ -949,7 +838,7 @@ different <a href="#tools">tools</a>.</p>
 
   <dt><tt>llvm/lib/Target/</tt><dd> This directory contains files that
   describe various target architectures for code generation.  For example,
-  the llvm/lib/Target/SparcV9 directory holds the Sparc machine
+  the llvm/lib/Target/Sparc directory holds the Sparc machine
   description.<br>
     
   <dt><tt>llvm/lib/CodeGen/</tt><dd> This directory contains the major parts
@@ -1002,30 +891,33 @@ the LLVM infrastructure.</p>
 <p>The <b>tools</b> directory contains the executables built out of the
 libraries above, which form the main part of the user interface.  You can
 always get help for a tool by typing <tt>tool_name --help</tt>.  The
-following is a brief introduction to the most important tools:</p>
+following is a brief introduction to the most important tools.</p>
 
-<dl>
-  <dt><tt><b>analyze</b></tt> <dd><tt>analyze</tt> is used to run a specific
+<dl compact>
+  <dt>
+
+  <dt><tt><b>analyze</b></tt><dd> <tt>analyze</tt> is used to run a specific
   analysis on an input LLVM bytecode file and print out the results.  It is
   primarily useful for debugging analyses, or familiarizing yourself with
   what an analysis does.<p>
 
-  <dt><tt><b>bugpoint</b></tt> <dd><tt>bugpoint</tt> is used to debug
+  <dt><tt><b>bugpoint</b></tt><dd> <tt>bugpoint</tt> is used to debug
   optimization passes or code generation backends by narrowing down the
   given test case to the minimum number of passes and/or instructions that
   still cause a problem, whether it is a crash or miscompilation. See <a
   href="HowToSubmitABug.html">HowToSubmitABug.html</a> for more information
   on using <tt>bugpoint</tt>.<p>
 
-  <dt><tt><b>llvm-ar</b></tt> <dd>The archiver produces an archive containing
+  <dt><tt><b>llvm-ar</b></tt><dd>The archiver produces an archive containing
   the given LLVM bytecode files, optionally with an index for faster
   lookup.<p>
   
-  <dt><tt><b>llvm-as</b></tt> <dd>The assembler transforms the human readable
+  <dt><tt><b>llvm-as</b></tt><dd>The assembler transforms the human readable
   LLVM assembly to LLVM bytecode.<p>
 
   <dt><tt><b>llvm-dis</b></tt><dd>The disassembler transforms the LLVM
-  bytecode to human readable LLVM assembly.<p>
+  bytecode to human readable LLVM assembly.  Additionally, it can convert
+  LLVM bytecode to C, which is enabled with the <tt>-c</tt> option.<p>
 
   <dt><tt><b>llvm-link</b></tt><dd> <tt>llvm-link</tt>, not surprisingly,
   links multiple LLVM modules into a single program.<p>
@@ -1039,9 +931,8 @@ following is a brief introduction to the most important tools:</p>
   functionality was compiled in), and will execute the code <i>much</i>
   faster than the interpreter.<p>
 
-  <dt><tt><b>llc</b></tt><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
-  the -march=c option).<p>
+  <dt><tt><b>llc</b></tt><dd> <tt>llc</tt> is the LLVM backend compiler,
+  which translates LLVM bytecode to a SPARC or x86 assembly file.<p>
 
   <dt><tt><b>llvmgcc</b></tt><dd> <tt>llvmgcc</tt> is a GCC-based C frontend
   that has been retargeted to emit LLVM code as the machine code output.  It
@@ -1050,9 +941,8 @@ following is a brief introduction to the most important tools:</p>
   <tt>llvmgcc</tt> tool is currently not included in the LLVM CVS tree
   because it is quite large and not very interesting.<p>
 
-  <blockquote>
-    <dl>
-    <dt><tt><b>gccas</b></tt> <dd>This tool is invoked by the
+  <ol>
+    <dt><tt><b>gccas</b></tt><dd> This tool is invoked by the
     <tt>llvmgcc</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
@@ -1064,19 +954,19 @@ following is a brief introduction to the most important tools:</p>
     `<tt>as</tt>' utility so that the gcc frontend itself did not have to be
     modified to interface to a "weird" assembler.<p>
 
-    <dt><tt><b>gccld</b></tt> <dd><tt>gccld</tt> links together several LLVM
+    <dt><tt><b>gccld</b></tt><dd> <tt>gccld</tt> links together several LLVM
     bytecode files into one bytecode file and does some optimization.  It is
     the linker invoked by the GCC frontend when multiple .o files need to be
     linked together.  Like <tt>gccas</tt>, the command line interface of
     <tt>gccld</tt> is designed to match the system linker, to aid
-    interfacing with the GCC frontend.</dl><p>
-  </blockquote>
+    interfacing with the GCC frontend.<p>
+  </ol>
 
   <dt><tt><b>opt</b></tt><dd> <tt>opt</tt> reads LLVM bytecode, applies a
   series of LLVM to LLVM transformations (which are specified on the command
   line), and then outputs the resultant bytecode.  The '<tt>opt --help</tt>'
   command is a good way to get a list of the program transformations
-  available in LLVM.
+  available in LLVM.<p>
 
 </dl>
 
@@ -1093,19 +983,19 @@ following is a brief introduction to the most important tools:</p>
 of the utilities are actually required as part of the build process because they
 are code generators for parts of LLVM infrastructure.</p>
 
-<dl>
-  <dt><tt><b>Burg/</b></tt> <dd><tt>Burg</tt> is an instruction selector
+<dl compact>
+  <td><tt><b>Burg/</b></tt><dd> <tt>Burg</tt> is an instruction selector
   generator -- it builds trees on which it then performs pattern-matching to
   select instructions according to the patterns the user has specified. Burg
   is currently used in the Sparc V9 backend.<p>
 
-  <dt><tt><b>codegen-diff</b></tt> <dd><tt>codegen-diff</tt> is a script
+  <dt><tt><b>codegen-diff</b></tt><dd> <tt>codegen-diff</tt> is a script
   that finds differences between code that LLC generates and code that LLI
   generates. This is a useful tool if you are debugging one of them,
   assuming that the other generates correct output. For the full user
   manual, run <tt>`perldoc codegen-diff'</tt>.<p>
 
-  <dt><tt><b>cvsupdate</b></tt> <dd><tt>cvsupdate</tt> is a script that will
+  <dt><tt><b>cvsupdate</b></tt><dd> <tt>cvsupdate</tt> is a script that will
   update your CVS tree, but produce a much cleaner and more organized output
   than simply running <tt>`cvs -z3 up -dP'</tt> will. For example, it will group
   together all the new and updated files and modified files in separate
@@ -1113,20 +1003,20 @@ are code generators for parts of LLVM infrastructure.</p>
   top of your LLVM CVS tree, running <tt>utils/cvsupdate</tt> is the
   preferred way of updating the tree.<p>
 
-  <dt><tt><b>emacs/</b></tt> <dd>The <tt>emacs</tt> directory contains
+  <dt><tt><b>emacs/</b></tt><dd> The <tt>emacs</tt> directory contains
   syntax-highlighting files which will work with Emacs and XEmacs editors,
   providing syntax highlighting support for LLVM assembly files and TableGen
   description files. For information on how to use the syntax files, consult
   the <tt>README</tt> file in that directory.<p>
 
-  <dt><tt><b>getsrcs.sh</b></tt> <dd>The <tt>getsrcs.sh</tt> script finds
+  <dt><tt><b>getsrcs.sh</b></tt><dd> The <tt>getsrcs.sh</tt> script finds
   and outputs all non-generated source files, which is useful if one wishes
   to do a lot of development across directories and does not want to
   individually find each file. One way to use it is to run, for example:
   <tt>xemacs `utils/getsources.sh`</tt> from the top of your LLVM source
   tree.<p>
   
-  <dt><tt><b>makellvm</b></tt> <dd>The <tt>makellvm</tt> script compiles all
+  <dt><tt><b>makellvm</b></tt><dd> The <tt>makellvm</tt> script compiles all
   files in the current directory and then compiles and links the tool that
   is the first argument. For example, assuming you are in the directory
   <tt>llvm/lib/Target/Sparc</tt>, if <tt>makellvm</tt> is in your path,
@@ -1135,17 +1025,17 @@ are code generators for parts of LLVM infrastructure.</p>
   causing a re-linking of LLC.<p>
 
   <dt><tt><b>NightlyTest.pl</b></tt> and
-  <tt><b>NightlyTestTemplate.html</b></tt> <dd>These files are used in a
+  <tt><b>NightlyTestTemplate.html</b></tt><dd> These files are used in a
   cron script to generate nightly status reports of the functionality of
   tools, and the results can be seen by following the appropriate link on
   the <a href="http://llvm.cs.uiuc.edu/">LLVM homepage</a>.<p>
 
-  <dt><tt><b>TableGen/</b></tt> <dd>The <tt>TableGen</tt> directory contains
+  <dt><tt><b>TableGen/</b></tt><dd> The <tt>TableGen</tt> directory contains
   the tool used to generate register descriptions, instruction set
   descriptions, and even assemblers from common TableGen description
   files.<p>
 
-  <dt><tt><b>vim/</b></tt> <dd>The <tt>vim</tt> directory contains
+  <dt><tt><b>vim/</b></tt><dd> The <tt>vim</tt> directory contains
   syntax-highlighting files which will work with the VIM editor, providing
   syntax highlighting support for LLVM assembly files and TableGen
   description files. For information on how to use the syntax files, consult
@@ -1176,16 +1066,11 @@ are code generators for parts of LLVM infrastructure.</p>
   <li><p>Next, compile the C file into a LLVM bytecode file:</p>
       <p><tt>% llvmgcc 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></li>
+      file with <tt>lli</tt>, making the result directly executable.</p></li>
 
   <li><p>Run the program. To make sure the program ran, execute one of the
       following commands:</p>
@@ -1201,19 +1086,18 @@ are code generators for parts of LLVM infrastructure.</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>
+  <li><p>Compile the program to native Sparc assembly using the code
+      generator (assuming you are currently on a Sparc system):</p>
 
       <p><tt>% llc hello.bc -o hello.s</tt></p>
 
-  <li><p>Assemble the native assembly language file into a program:</p>
+  <li><p>Assemble the native sparc assemble file into a program:</p>
 
-      <p><b>Solaris:</b><tt>% /opt/SUNWspro/bin/cc -xarch=v9 hello.s -o hello.native</tt></p>
-      <p><b>Others:</b><tt>% gcc hello.s -o hello.native</tt></p>
+      <p><tt>% /opt/SUNWspro/bin/cc -xarch=v9 hello.s -o hello.sparc</tt></p>
 
-  <li><p>Execute the native code program:</p>
+  <li><p>Execute the native sparc program:</p>
 
-      <p><tt>% ./hello.native</tt></p></li>
+      <p><tt>% ./hello.sparc</tt></p></li>
 
 </ol>
 
@@ -1260,11 +1144,6 @@ out:</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>
-
   <a href="mailto:sabre@nondot.org">Chris Lattner</a><br>
   <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a><br>
   Last modified: $Date$

llvm/docs/HistoricalNotes/2001-04-16-DynamicCompilation.txt

@@ -1,49 +1,12 @@
 By Chris:
 
-LLVM has been designed with two primary goals in mind.  First we strive to 
-enable the best possible division of labor between static and dynamic 
-compilers, and second, we need a flexible and powerful interface 
-between these two complementary stages of compilation.  We feel that 
-providing a solution to these two goals will yield an excellent solution 
-to the performance problem faced by modern architectures and programming 
-languages.
+LLVM has been designed with two primary goals in mind.  First we strive to enable the best possible division of labor between static and dynamic compilers, and second, we need a flexible and powerful interface between these two complementary stages of compilation.  We feel that providing a solution to these two goals will yield an excellent solution to the performance problem faced by modern architectures and programming languages.
 
-A key insight into current compiler and runtime systems is that a 
-compiler may fall in anywhere in a "continuum of compilation" to do its 
-job.  On one side, scripting languages statically compile nothing and 
-dynamically compile (or equivalently, interpret) everything.  On the far 
-other side, traditional static compilers process everything statically and 
-nothing dynamically.  These approaches have typically been seen as a 
-tradeoff between performance and portability.  On a deeper level, however, 
-there are two reasons that optimal system performance may be obtained by a
-system somewhere in between these two extremes: Dynamic application 
-behavior and social constraints.
+A key insight into current compiler and runtime systems is that a compiler may fall in anywhere in a "continuum of compilation" to do its job.  On one side, scripting languages statically compile nothing and dynamically compile (or equivalently, interpret) everything.  On the far other side, traditional static compilers process everything statically and nothing dynamically.  These approaches have typically been seen as a tradeoff between performance and portability.  On a deeper level, however, there are two reasons that optimal system performance may be obtained by a system somewhere in between these two extremes: Dynamic application behavior and social constraints.
 
-From a technical perspective, pure static compilation cannot ever give 
-optimal performance in all cases, because applications have varying dynamic
-behavior that the static compiler cannot take into consideration.  Even 
-compilers that support profile guided optimization generate poor code in 
-the real world, because using such optimization tunes that application 
-to one particular usage pattern, whereas real programs (as opposed to 
-benchmarks) often have several different usage patterns.
+From a technical perspective, pure static compilation cannot ever give optimal performance in all cases, because applications have varying dynamic behavior that the static compiler cannot take into consideration.  Even compilers that support profile guided optimization generate poor code in the real world, because using such optimization tunes that application to one particular usage pattern, whereas real programs (as opposed to benchmarks) often have several different usage patterns.
 
-On a social level, static compilation is a very shortsighted solution to 
-the performance problem.  Instruction set architectures (ISAs) continuously 
-evolve, and each implementation of an ISA (a processor) must choose a set 
-of tradeoffs that make sense in the market context that it is designed for.  
-With every new processor introduced, the vendor faces two fundamental 
-problems: First, there is a lag time between when a processor is introduced 
-to when compilers generate quality code for the architecture.  Secondly, 
-even when compilers catch up to the new architecture there is often a large 
-body of legacy code that was compiled for previous generations and will 
-not or can not be upgraded.  Thus a large percentage of code running on a 
-processor may be compiled quite sub-optimally for the current 
-characteristics of the dynamic execution environment.
+On a social level, static compilation is a very shortsighted solution to the performance problem.  Instruction set architectures (ISAs) continuously evolve, and each implementation of an ISA (a processor) must choose a set of tradeoffs that make sense in the market context that it is designed for.  With every new processor introduced, the vendor faces two fundamental problems: First, there is a lag time between when a processor is introduced to when compilers generate quality code for the architecture.  Secondly, even when compilers catch up to the new architecture there is often a large body of legacy code that was compiled for previous generations and will not or can not be upgraded.  Thus a large percentage of code running on a processor may be compiled quite sub-optimally for the current characteristics of the dynamic execution environment.
+
+For these reasons, LLVM has been designed from the beginning as a long-term solution to these problems.  Its design allows the large body of platform independent, static, program optimizations currently in compilers to be reused unchanged in their current form.  It also provides important static type information to enable powerful dynamic and link time optimizations to be performed quickly and efficiently.  This combination enables an increase in effective system performance for real world environments.
 
-For these reasons, LLVM has been designed from the beginning as a long-term 
-solution to these problems.  Its design allows the large body of platform 
-independent, static, program optimizations currently in compilers to be 
-reused unchanged in their current form.  It also provides important static 
-type information to enable powerful dynamic and link time optimizations 
-to be performed quickly and efficiently.  This combination enables an 
-increase in effective system performance for real world environments.

llvm/docs/HowToSubmitABug.html

@@ -11,6 +11,8 @@
   How to submit an LLVM bug report
 </div>
 
+<div>
+
 <table border="0" width="100%">
 <tr>
 <td valign="top">
@@ -29,14 +31,12 @@
 
 </ol>
 
-<div class="doc_author">
-  <p>Written by <a href="mailto:sabre@nondot.org">Chris Lattner</a> and
-                <a href="http://misha.brukman.net">Misha Brukman</a></p>
-</div>
+<p><b>Written by <a href="mailto:sabre@nondot.org">Chris Lattner</a> and
+                 <a href="http://misha.brukman.net">Misha Brukman</a></b></p>
 
 </td>
 <td align="right">
-  <img src="img/Debugging.gif" alt="Debugging" width="444" height="314">
+  <img src="Debugging.gif" width="444" height="314">
 </td>
 </tr>
 </table>
@@ -96,14 +96,12 @@ buggy or if it's one of the LLVM tools that has problems.</p>
 <tt><b>gccas</b></tt>, or <tt><b>gccld</b></tt>), run the
 <tt><b>llvm-gcc</b></tt> command line as you were when the crash occurred, but
 add a <tt>-v</tt> option to the command line.  The compiler will print out a
-bunch of stuff, and should end with telling you that one of
-<tt><b>cc1</b>/<b>cc1plus</b></tt>, <tt><b>gccas</b></tt>, or
-<tt><b>gccld</b></tt> crashed.</p>
+bunch of stuff, and should end with telling you that one of <tt><b>cc1</b></tt>,
+<tt><b>gccas</b></tt>, or <tt><b>gccld</b></tt> crashed.</p>
 
 <ul>
 
-  <li>If <tt><b>cc1</b></tt> or <tt><b>cc1plus</b></tt> crashed, you found a
-  problem with the front-end.
+  <li>If <tt><b>cc1</b></tt> crashed, you found a problem with the front-end.
   Jump ahead to the section on <a href="#front-end">front-end bugs</a>.</li>
 
   <li>If <tt><b>gccas</b></tt> crashed, you found a bug in <a href="#gccas">one
@@ -147,9 +145,9 @@ along with a brief description of the error it caused.</p>
 compilation, compile your test-case to a <tt>.s</tt> file with the
 <tt>-save-temps</tt> option to <tt><b>llvm-gcc</b></tt>. Then run:</p>
 
-<div class="doc_code">
-<p><tt><b>gccas</b> -debug-pass=Arguments &lt; /dev/null -o - &gt; /dev/null</tt></p>
-</div>
+<pre>
+  <b>gccas</b> -debug-pass=Arguments &lt; /dev/null -o - &gt; /dev/null
+</pre>
 
 <p>... which will print a list of arguments, indicating the list of passes that
 <tt><b>gccas</b></tt> runs.  Once you have the input file and the list of
@@ -170,11 +168,10 @@ compilation, gather all of the <tt>.o</tt> bytecode files and libraries that are
 being linked together (the "<tt><b>llvm-gcc</b> -v</tt>" output should include
 the full list of objects linked).  Then run:</p>
 
-<div class="doc_code">
-<p><tt><b>llvm-as</b> &lt; /dev/null &gt; null.bc<br>
-<b>gccld</b> -debug-pass=Arguments null.bc</tt>
-</p>
-</div>
+<pre>
+  <b>llvm-as</b> &lt; /dev/null &gt; null.bc
+  <b>gccld</b> -debug-pass=Arguments null.bc
+</pre><p>
 
 <p>... which will print a list of arguments, indicating the list of passes that
 <tt><b>gccld</b></tt> runs.  Once you have the input files and the list of
@@ -195,21 +192,19 @@ files and a list of passes which crash when run on the specified input.  In
 order to reduce the list of passes (which is probably large) and the input to
 something tractable, use the <tt><b>bugpoint</b></tt> tool as follows:</p>
 
-<div class="doc_code">
-<p><tt><b>bugpoint</b> &lt;input files&gt; &lt;list of passes&gt;</tt></p>
-</div>
+<pre>
+  <b>bugpoint</b> &lt;input files&gt; &lt;list of passes&gt;
+</pre><p>
 
 <p><tt><b>bugpoint</b></tt> will print a bunch of output as it reduces the
 test-case, but it should eventually print something like this:</p>
 
-<div class="doc_code">
-<p><tt>
-...<br>
-Emitted bytecode to 'bugpoint-reduced-simplified.bc'<br>
-<br>
-*** You can reproduce the problem with: opt bugpoint-reduced-simplified.bc -licm<br>
-</tt></p>
-</div>
+<pre>
+  ...
+  Emitted bytecode to 'bugpoint-reduced-simplified.bc'
+
+  *** You can reproduce the problem with: opt bugpoint-reduced-simplified.bc -licm
+</pre>
 
 <p>Once you complete this, please send the LLVM bytecode file and the command
 line to reproduce the problem to the llvmbugs mailing list.</p>
@@ -230,21 +225,13 @@ from producing invalid LLVM code (i.e., code not in SSA form, using values
 before defining them, etc.) which the verifier will check for after a pass
 finishes its run.</p>
 
-<p>If it looks like the LLVM compiler is miscompiling a program, the very first
-thing to check is to make sure it is not using undefined behavior.  In
-particular, check to see if the program <a
-href="http://valgrind.kde.org/">valgrind</a>s clean, passes purify, or some
-other memory checker tool.  Many of the "LLVM bugs" that we have chased down
-ended up being bugs in the program being compiled, not LLVM.</p>
+<p>To debug a miscompilation, you should choose which program you wish to run
+the output through, e.g. C backend, the JIT, or LLC, and a selection of passes,
+one of which may be causing the error, and run, for example:</p>
 
-<p>Once you determine that the program itself is not buggy, you should choose 
-which code generator you wish to compile the program with (e.g. C backend, the 
-JIT, or LLC) and optionally a series of LLVM passes to run.  For example:</p>
-
-<div class="doc_code">
-<p><tt>
-<b>bugpoint</b> -run-cbe [... optzn passes ...] file-to-test.bc --args -- [program arguments]</tt></p>
-</div>
+<pre>
+  <b>bugpoint</b> -run-cbe [... optimization passes ...] file-to-test.bc
+</pre>
 
 <p><tt>bugpoint</tt> will try to narrow down your list of passes to the one pass
 that causes an error, and simplify the bytecode file as much as it can to assist
@@ -271,35 +258,15 @@ Backend, and then link in the shared object it generates.</p>
 
 <p>To debug the JIT:</p>
 
-<div class="doc_code">
 <pre>
-bugpoint -run-jit -output=[correct output file] [bytecode file]  \
-         --tool-args -- [arguments to pass to lli]               \
-         --args -- [program arguments]
+  <b>bugpoint</b> -run-jit -output=[correct output file] [bytecodefile]
 </pre>
-</div>
 
 <p>Similarly, to debug the LLC, one would run:</p>
 
-<div class="doc_code">
 <pre>
-bugpoint -run-llc -output=[correct output file] [bytecode file]  \
-         --tool-args -- [arguments to pass to llc]               \
-         --args -- [program arguments]
+  <b>bugpoint</b> -run-llc -output=[correct output file] [bytecodefile]
 </pre>
-</div>
-
-<p><b>Special note:</b> if you are debugging MultiSource or SPEC tests that
-already exist in the <tt>llvm/test</tt> hierarchy, there is an easier way to
-debug the JIT, LLC, and CBE, using the pre-written Makefile targets, which
-will pass the program options specified in the Makefiles:</p>
-
-<div class="doc_code">
-<p><tt>
-cd llvm/test/../../program<br>
-make bugpoint-jit
-</tt></p>
-</div>
 
 <p>At the end of a successful <tt>bugpoint</tt> run, you will be presented
 with two bytecode files: a <em>safe</em> file which can be compiled with the C
@@ -311,50 +278,41 @@ the following:</p>
 
 <ol>
 
-<li><p>Regenerate the shared object from the safe bytecode file:</p>
+  <li>Regenerate the shared object from the safe bytecode file:<br>
 
-<div class="doc_code">
-<p><tt>
-<b>llc</b> -march=c safe.bc -o safe.c<br>
-<b>gcc</b> -shared safe.c -o safe.so
-</tt></p>
-</div></li>
+<pre>
+  <b>llvm-dis</b> -c safe.bc -o safe.c<br>
+  <b>gcc</b> -shared safe.c -o safe.so
+</pre></li>
 
-<li><p>If debugging LLC, compile test bytecode native and link with the shared
-    object:</p>
+  <li>If debugging LLC, compile test bytecode native and link with the shared object:<br>
 
-<div class="doc_code">
-<p><tt>
-<b>llc</b> test.bc -o test.s -f<br>
-<b>gcc</b> test.s safe.so -o test.llc<br>
-./test.llc [program options]
-</tt></p>
-</div></li>
-    
-<li><p>If debugging the JIT, load the shared object and supply the test
-    bytecode:</p>
+<pre>
+  <b>llc</b> test.bc -o test.s -f<br>
+  gcc test.s safe.so -o test.llc<br>
+  ./test.llc [program options]
+</pre></li>
+      
+<p>If debugging the JIT, load the shared object and supply the test
+bytecode:</p>
 
-<div class="doc_code">
-<p><tt><b>lli</b> -load=safe.so test.bc [program options]</tt></p>
-</div></li>  
+<pre>
+  <b>lli</b> -load=safe.so test.bc [program options]
+</pre></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>
+<hr>
+<div class="doc_footer">
+  <address><a href="mailto:sabre@nondot.org">Chris Lattner</a></address>
   <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
   <br>
   Last modified: $Date$
-</address>
+</div>
 
 </body>
 </html>

llvm/docs/LLVMVsTheWorld.html

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

llvm/docs/ObjectFiles.html

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

llvm/docs/OpenProjects.html

@@ -15,8 +15,8 @@
   <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="#NightlyTest">Improving the Nightly Tester</a></li>
     <li><a href="#programs">Compile programs with the LLVM Compiler</a></li>
     <li><a href="#llvm_ir">Extend the LLVM intermediate representation</a></li>
     <li><a href="#misc_imp">Miscellaneous Improvements</a></li>
@@ -24,7 +24,6 @@
 
   <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>
@@ -33,11 +32,6 @@
   </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>
@@ -58,12 +52,9 @@ contributions.</p>
 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>
+or to suggest other projects to add to this page.  Another good place to look
+for ideas is the <a href="http://llvm.cs.uiuc.edu/bugs/">LLVM bug
+tracker</a>.</p>
 
 </div>
 
@@ -81,22 +72,6 @@ can use improvement...</p>
 
 </div>
 
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="code-cleanups">Implementing Code Cleanup bugs</a>
-</div>
-
-<div class="doc_text">
-
-<p>
-The <a href="http://llvm.cs.uiuc.edu/bugs/">LLVM bug tracker</a> occasionally
-has <a href="http://llvm.cs.uiuc.edu/bugs/buglist.cgi?short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=code-cleanup&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Bug+Number&field0-0-0=noop&type0-0-0=noop&value0-0-0=">"code-cleanup" bugs</a> filed in it.  Taking one of these and fixing it is a good
-way to get your feet wet in the LLVM code and discover how some of its components
-work.
-</p>
-
-</div>
-
 <!-- ======================================================================= -->
 <div class="doc_subsection">
   <a name="glibc">Port glibc to LLVM</a>
@@ -105,8 +80,8 @@ work.
 <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
+href="http://www.gnu.org/software/libc/porting.html">port</a> <a
+href="http://www.gnu.org/software/glibc/">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
@@ -114,6 +89,28 @@ library and the <tt>stdio</tt> related functions... low-level system calls like
 
 </div>
 
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+  <a name="NightlyTest">Improving the Nightly Tester</a>
+</div>
+
+<div class="doc_text">
+
+<p>The <a href="/testresults/">Nightly Tester</a> is a simple perl script
+(located in <tt>utils/NightlyTest.pl</tt>) which runs every night to generate a
+daily report.  It could use the following improvements:</p>
+
+<ol>
+<li>Graphs - It would be great to have gnuplot graphs to keep track of how the
+    tree is changing over time.  We already gather a several statistics, it
+    just necessary to add the script-fu to gnuplotize it.</li>
+
+<li>Regression tests - We should run the regression tests in addition to the
+    program tests...</li>
+</ol>
+
+</div>
+
 <!-- ======================================================================= -->
 <div class="doc_subsection">
   <a name="programs">Compile programs with the LLVM Compiler</a>
@@ -143,6 +140,10 @@ all the back-ends: CBE, llc, and lli.</p>
 <div class="doc_text">
 
 <ol>
+
+<li>Add a new conditional move instruction: <tt>X = select bool Cond, Y,
+    Z</tt></li>
+
 <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
@@ -165,6 +166,11 @@ all the back-ends: CBE, llc, and lli.</p>
     would also then have to implement the reader for this index in
     <tt>gccld</tt>.</li>
 
+<li>Improve the efficiency of the bytecode loader/writer</li>
+
+<li>Extend the FunctionPassManager to use a ModuleProvider to stream functions
+    in on demand.  This would improve the efficiency of the JIT.</li>
+
 <li>Rework the PassManager to be more flexible</li>
 
 <li>Some transformations and analyses only work on reducible flow graphs.  It
@@ -188,24 +194,12 @@ Irreducible Loops</a>.</li>
 
 <div class="doc_text">
 
-<p>Sometimes creating new things is more fun than improving existing things.
+<p>Sometimes creating new things is more fun that improving existing things.
 These projects tend to be more involved and perhaps require more work, but can
 also be very rewarding.</p>
 
 </div>
 
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="newfeaturebugs">Implementing new feature PRs</a>
-</div>
-
-<div class="doc_text">
-
-<p>Many ideas for feature requests are stored in LLVM bugzilla.  Just <a href="http://llvm.org/bugs/buglist.cgi?short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=new-feature&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&namedcmd=All+PRs&newqueryname=&order=Bug+Number&field0-0-0=noop&type0-0-0=noop&value0-0-0=">search for bugs with a "new-feature" keyword</a>.</p>
-
-</div>
-
 <!-- ======================================================================= -->
 <div class="doc_subsection">
   <a name="pointeranalysis">Pointer and Alias Analysis</a>
@@ -225,6 +219,9 @@ themselves.  It seems natural to want to take advantage of this...</p>
 <li>Implement a flow-sensitive context-insensitive alias analysis algorithm<br>
   - Just an efficient local algorithm perhaps?</li>
 
+<li>Implement an interface to update analyses in response to common code motion
+    transformations</li>
+
 <li>Implement alias-analysis-based optimizations:
   <ul>
   <li>Dead store elimination</li>
@@ -241,11 +238,11 @@ themselves.  It seems natural to want to take advantage of this...</p>
 
 <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>We are getting to the point where we really need a unified infrastructure for
+profile guided optimizations.  It would be wonderful to be able to write profile
+guided transformations which can be performed either at static compile time
+(compile time or offline optimization time) or at runtime in a JIT type setup.
+The LLVM transformation itself shouldn't need to know how it is being used.</p>
 
 <p>Ideas for profile guided transformations:</p>
 
@@ -257,23 +254,6 @@ transformations as well as improvements to the current profiling system.
 <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>
 
 <!-- ======================================================================= -->
@@ -286,8 +266,12 @@ profiling code to work with the generic profiling interfaces.</li>
 <ol>
 <li>Implement a Dependence Analysis Infrastructure<br>
      - Design some way to represent and query dep analysis</li>
+<li>Implement a faster Dominator Set Construction Algorithm<br>
+     - A linear time or nearly so algorithm</li>
 <li>Implement a strength reduction pass</li>
 <li>Value range propagation pass</li>
+<li>Implement an unswitching pass</li>
+<li>Write a loop unroller, with a simple heuristic for when to unroll</li>
 </ol>
 
 </div>
@@ -300,44 +284,24 @@ profiling code to work with the generic profiling interfaces.</li>
 <div class="doc_text">
 
 <ol>
+<li>Implement a global register allocator</li>
 <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">
+<div class="doc_subsection">
   <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 frontend for some language (Java? OCaml? Forth?)</li>
 <li>Write a new backend for a target (IA64? MIPS? MMIX?)</li>
-<li>Write a disassembler for machine code that would use TableGen to output 
-<tt>MachineInstr</tt>s for transformations, optimizations, etc.</li>
-<li>Random test vector generator: Use a C grammar to generate random C code;
-run it through llvm-gcc, then run a random set of passes on it using opt.
-Try to crash opt. When opt crashes, use bugpoint to reduce the test case and
-mail the result to yourself.  Repeat ad infinitum.</li>
-<li>Design a simple, recognizable logo.</li>
 </ol>
 
 </div>
@@ -345,16 +309,12 @@ mail the result to yourself.  Repeat ad infinitum.</li>
 <!-- *********************************************************************** -->
 
 <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>
+<div class="doc_footer">
+  <address><a href="mailto:sabre@nondot.org">Chris Lattner</a></address>
+  <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
+  <br>
   Last modified: $Date$
-</address>
+</div>
 
 </body>
 </html>

llvm/docs/Projects.html

@@ -1,451 +1,391 @@
-<!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 Transitional//EN">
 <html>
-<head>
-  <title>Creating an LLVM Project</title>
-  <link rel="stylesheet" href="llvm.css" type="text/css">
-</head>
-<body>
-
-<div class="doc_title">Creating an LLVM Project</div>
-
-<ol>
-<li><a href="#overview">Overview</a></li>
-<li><a href="#create">Create a project from the Sample Project</a></li>
-<li><a href="#source">Source tree layout</a></li>
-<li><a href="#makefiles">Writing LLVM-style Makefiles</a>
-  <ol>
-  <li><a href="#reqVars">Required Variables</a></li>
-  <li><a href="#varsBuildDir">Variables for Building Subdirectories</a></li>
-  <li><a href="#varsBuildLib">Variables for Building Libraries</a></li>
-  <li><a href="#varsBuildProg">Variables for Building Programs</a></li>
-  <li><a href="#miscVars">Miscellaneous Variables</a></li>
-  </ol></li>
-<li><a href="#objcode">Placement of object code</a></li>
-<li><a href="#help">Further help</a></li>
-</ol>
-
-<div class="doc_author">
-  <p>Written by John Criswell</p>
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section"><a name="overview">Overview</a></div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>The LLVM build system is designed to facilitate the building of third party
-projects that use LLVM header files, libraries, and tools.  In order to use
-these facilities, a Makefile from a project must do the following things:</p>
-
-<ol>
-<li>Set environment variables.There are several environment variables that a
-Makefile needs to set to use the LLVM build system:
-
-<ul>
-  <li><tt>LLVM_SRC_ROOT</tt> - The root of the LLVM source tree.</li>
-  <li><tt>LLVM_OBJ_ROOT</tt> - The root of the LLVM object tree.</li>
-  <li><tt>BUILD_SRC_ROOT</tt> - The root of the project's source tree.</li>
-  <li><tt>BUILD_OBJ_ROOT</tt> - The root of the project's object tree.</li>
-  <li><tt>BUILD_SRC_DIR</tt> - The directory containing the current source to be
-  compiled.</li>
-  <li><tt>BUILD_OBJ_DIR</tt> - The directory where the current source will place
-  the new object files.  This should always be the current directory.</li>
-  <li><tt>LEVEL</tt> - The relative path from the current directory to the root
-  of the object tree.</li>
-</ul></li>
-<li>Include <tt>Makefile.config</tt> from <tt>$(LLVM_OBJ_ROOT)</tt>.</li>
-<li>Include <tt>Makefile.rules</tt> from <tt>$(LLVM_SRC_ROOT)</tt>.</li>
-</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>
-</ol>
-
-<p>This document assumes that you will base your project off of 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>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
-  <a name="create">Create a Project from the Sample Project</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>Follow these simple steps to start your project:</p>
-
-<ol>
-<li>Copy the <tt>llvm/projects/sample</tt> directory to any place of your
-choosing.  You can place it anywhere you like.  Rename the directory to match
-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>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>
-</div>
-
-<p>You must be using Autoconf version 2.57 or higher.</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.
-  </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>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
-  <a name="source">Source Tree Layout</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>In order to use the LLVM build system, you will want to organize your
-source code so that it can benefit from the build system's features.
-Mainly, you want your source tree layout to look similar to the LLVM
-source tree layout.  The best way to do this is to just copy the
-project tree from <tt>llvm/projects/sample</tt> and modify it to meet
-your needs, but you can certainly add to it if you want.</p>
-
-<p>Underneath your top level directory, you should have the following
-directories:</p>
-
-<dl>
-  <dt><b>lib</b>
-  <dd>
-  This subdirectory should contain all of your library source
-  code.  For each library that you build, you will have one
-  directory in <b>lib</b> that will contain that library's source
-  code.
-
-  <p>
-  Libraries can be object files, archives, or dynamic libraries.
-  The <b>lib</b> directory is just a convenient place for libraries
-  as it places them all in a directory from which they can be linked
-  later.
-
-  <dt><b>include</b>
-  <dd>
-  This subdirectory should contain any header files that are
-  global to your project.  By global, we mean that they are used
-  by more than one library or executable of your project.
-  <p>
-  By placing your header files in <b>include</b>, they will be
-  found automatically by the LLVM build system.  For example, if
-  you have a file <b>include/jazz/note.h</b>, then your source
-  files can include it simply with <b>#include "jazz/note.h"</b>.
-
-  <dt><b>tools</b>
-  <dd>
-  This subdirectory should contain all of your source
-  code for executables.  For each program that you build, you
-  will have one directory in <b>tools</b> that will contain that
-  program's source code.
-  <p>
-
-  <dt><b>test</b>
-  <dd>
-  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:
-  <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>
-
-    <li>
-    The LLVM source tree provides benchmarks and programs which 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
-    need to find a way to use the source provided within that directory
-    on your own.
-  </ul>
-</dl>
-
-<p>Typically, you will want to build your <b>lib</b> directory first followed by
-your <b>tools</b> directory.</p>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
-  <a name="makefiles">Writing LLVM Style Makefiles</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>The LLVM build system provides a convenient way to build libraries and
-executables.  Most of your project Makefiles will only need to define a few
-variables.  Below is a list of the variables one can set and what they can
-do:</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="reqVars">Required Variables</a>
-</div>
-
-<div class="doc_text">
-
-<dl>
-  <dt>LEVEL
-  <dd>
-  This variable is the relative path from this Makefile to the
-  top directory of your project's source code.  For example, if
-  your source code is in <tt>/tmp/src</tt>, then the Makefile in
-  <tt>/tmp/src/jump/high</tt> would set <tt>LEVEL</tt> to <tt>"../.."</tt>.
-</dl>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="varsBuildDir">Variables for Building Subdirectories</a>
-</div>
-
-<div class="doc_text">
-
-<dl>
-  <dt>DIRS
-  <dd>
-  This is a space separated list of subdirectories that should be
-  built.  They will be built, one at a time, in the order
-  specified.
-  <p>
-
-  <dt>PARALLEL_DIRS
-  <dd>
-  This is a list of directories that can be built in parallel.
-  These will be built after the directories in DIRS have been
-  built.
-  <p>
-
-  <dt>OPTIONAL_DIRS
-  <dd>
-  This is a list of directories that can be built if they exist,
-  but will not cause an error if they do not exist.  They are
-  built serially in the order in which they are listed.
-</dl>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="varsBuildLib">Variables for Building Libraries</a>
-</div>
-
-<div class="doc_text">
-
-<dl>
-  <dt>LIBRARYNAME
-  <dd>
-  This variable contains the base name of the library that will
-  be built.  For example, to build a library named
-  <tt>libsample.a</tt>, LIBRARYNAME should be set to
-  <tt>sample</tt>.
-  <p>
-
-  <dt>BUILD_ARCHIVE
-  <dd>
-  By default, a library is a <tt>.o</tt> file that is linked
-  directly into a program.  To build an archive (also known as
-  a static library), set the BUILD_ARCHIVE variable.
-  <p>
-
-  <dt>SHARED_LIBRARY
-  <dd>
-  If SHARED_LIBRARY is defined in your Makefile, a shared
-  (or dynamic) library will be built.
-</dl>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="varsBuildProg">Variables for Building Programs</a>
-</div>
-
-<div class="doc_text">
-
-<dl>
-  <dt>TOOLNAME
-  <dd>
-  This variable contains the name of the program that will
-  be built.  For example, to build an executable named
-  <tt>sample</tt>, TOOLNAME should be set to <tt>sample</tt>.
-  <p>
-
-  <dt>USEDLIBS
-  <dd>
-  This variable holds a space separated list of libraries that
-  should be linked into the program.  These libraries must either
-  be LLVM libraries or libraries that come from your <b>lib</b>
-  directory.  The libraries must be specified by their base name.
-  For example, to link libsample.a, you would set USEDLIBS to
-  <tt>sample</tt>.
-  <p>
-  Note that this works only for statically linked libraries.
-  <p>
-
-  <dt>LIBS
-  <dd>
-  To link dynamic libraries, add <tt>-l&lt;library base name&gt;</tt> to
-  the LIBS variable.  The LLVM build system will look in the same places
-  for dynamic libraries as it does for static libraries.
-  <p>
-  For example, to link <tt>libsample.so</tt>, you would have the
-  following line in your <tt>Makefile</tt>:
-  <p>
-  <tt>
-  LIBS += -lsample
-  </tt>
-</dl>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="miscVars">Miscellaneous Variables</a>
-</div>
-
-<div class="doc_text">
-
-<dl>
-  <dt>ExtraSource
-  <dd>
-  This variable contains a space separated list of extra source
-  files that need to be built.  It is useful for including the
-  output of Lex and Yacc programs.
-  <p>
-
-  <dt>CFLAGS
-  <dt>CPPFLAGS
-  <dd>
-  This variable can be used to add options to the C and C++
-  compiler, respectively.  It is typically used to add options
-  that tell the compiler the location of additional directories
-  to search for header files.
-  <p>
-  It is highly suggested that you append to CFLAGS and CPPFLAGS as
-  opposed to overwriting them.  The master Makefiles may already
-  have useful options in them that you may not want to overwrite.
-  <p>
-</dl>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
-  <a name="objcode">Placement of Object Code</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>The final location of built libraries and executables will depend upon
-whether you do a Debug, Release, or Profile build.</p>
-
-<dl>
-  <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>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>Release</tt>, or <tt>Profile</tt> for a debug, optimized, or profiled
-  build, respectively.
-</dl>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
-  <a name="help">Further Help</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>If you have any questions or need any help creating an LLVM project,
-the LLVM team would be more than happy to help.  You can always post your
-questions to the <a
-href="http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVM Developers
-Mailing List</a>.</p>
-
-</div>
-  
-<!-- *********************************************************************** -->
+	<head>
+		<title>Creating an LLVM Project</title>
+	</head>
+
+	<body bgcolor=white>
+
+	<center><h1>Creating an LLVM Project<br></h1></center>
+
+	<!--===============================================================-->
+	<h2><a name="a">Overview</a><hr></h2>
+	<!--===============================================================-->
+
+	The LLVM build system is designed to facilitate the building of third party
+	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:
+
+	<ol>
+		<li>Set environment variables.
+		<p>
+		There are several environment variables that a Makefile needs to set to
+		use the LLVM build system:
+		<dl compact>
+			<dt>LLVM_SRC_ROOT
+			<dd>
+			The root of the LLVM source tree.
+			<p>
+
+			<dt>LLVM_OBJ_ROOT
+			<dd>
+			The root of the LLVM object tree.
+			<p>
+
+			<dt>BUILD_SRC_ROOT
+			<dd>
+			The root of the project's source tree.
+			<p>
+
+			<dt>BUILD_OBJ_ROOT
+			<dd>
+			The root of the project's object tree.
+			<p>
+
+			<dt>BUILD_SRC_DIR
+			<dd>
+			The directory containing the current source to be compiled.
+			<p>
+
+			<dt>BUILD_OBJ_DIR
+			<dd>
+			The directory where the current source will place the new object
+			files.  This should always be the current directory.
+			<p>
+
+			<dt>LEVEL
+			<dd>
+			The relative path from the current directory to the root of the
+			object tree.
+			<p>
+		</dl>
+
+		<li>Include the LLVM Makefile.config from $(LLVM_OBJ_ROOT).
+		<p>
+
+		<li>Include the LLVM Makefile.rules from $(LLVM_SRC_ROOT).
+	</ol>
+
+	There are two ways that you can set all of these variables:
+	<ol>
+		<li>
+		You can write your own Makefiles which hard-code these values.
+
+		<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.
+	</ol>
+
+	This document assumes that you will base your project off of 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>
+
+	<!--===============================================================-->
+	<h2><a name="a">Create a Project from the Sample Project</a><hr></h2>
+	<!--===============================================================-->
+
+	Follow these simple steps to start your project:
+
+	<ol>
+		<li>
+		Copy the <tt>llvm/projects/sample</tt> directory to any place
+		of your choosing.  You can place it anywhere you like.  Rename the
+		directory to match the name of your project.
+		<p>
+
+		<li>
+		Add your source code and Makefiles to your source tree.
+		<p>
+
+		<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.
+
+		<p>
+		After updating <tt>autoconf/configure.ac</tt>, regenerate the
+		configure script with these commands:
+		<p>
+		<tt>
+		cd autoconf<br>
+		autoconf -o ../configure
+		</tt>
+
+		<p>
+
+		You must be using Autoconf version 2.57 or higher.
+		<p>
+
+		<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 compact>
+			<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.
+		</dl>
+	</ol>
+
+	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.
+
+	<!--===============================================================-->
+	<h2><a name="Source Tree Layout">Source Tree Layout</a><hr></h2>
+	<!--===============================================================-->
+
+	In order to use the LLVM build system, you will want to organize your
+	source code so that it can benefit from the build system's features.
+	Mainly, you want your source tree layout to look similar to the LLVM
+	source tree layout.  The best way to do this is to just copy the
+	project tree from <tt>llvm/projects/sample</tt> and modify it to meet
+	your needs, but you can certainly add to it if you want.
+
+	Underneath your top level directory, you should have the following
+	directories:
+
+	<dl compact>
+		<dt><b>lib</b>
+		<dd>
+		This subdirectory should contain all of your library source
+		code.  For each library that you build, you will have one
+		directory in <b>lib</b> that will contain that library's source
+		code.
+
+		<p>
+		Libraries can be object files, archives, or dynamic libraries.
+		The <b>lib</b> directory is just a convenient place for libraries
+		as it places them all in a directory from which they can be linked
+		later.
+
+		<dt><b>include</b>
+		<dd>
+		This subdirectory should contain any header files that are
+		global to your project.  By global, we mean that they are used
+		by more than one library or executable of your project.
+		<p>
+		By placing your header files in <b>include</b>, they will be
+		found automatically by the LLVM build system.  For example, if
+		you have a file <b>include/jazz/note.h</b>, then your source
+		files can include it simply with <b>#include "jazz/note.h"</b>.
+
+		<dt><b>tools</b>
+		<dd>
+		This subdirectory should contain all of your source
+		code for executables.  For each program that you build, you
+		will have one directory in <b>tools</b> that will contain that
+		program's source code.
+		<p>
+
+		<dt><b>test</b>
+		<dd>
+		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:
+		<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>
+
+			<li>
+			The LLVM source tree provides benchmarks and programs which 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
+			need to find a way to use the source provided within that directory
+			on your own.
+		</ul>
+	</dl>
+
+	Typically, you will want to build your <b>lib</b> directory first
+	followed by your <b>tools</b> directory.
+
+	<!--===============================================================-->
+	<h2><a name="Makefile Variables">Writing LLVM Style Makefiles</a><hr></h2>
+	<!--===============================================================-->
+	The LLVM build system provides a convenient way to build libraries and
+	executables.  Most of your project Makefiles will only need to define a few
+	variables.  Below is a list of the variables one can set and what they can
+	do:
+
+	<h3> Required Variables </h3>
+	<dl compact>
+		<dt>LEVEL
+		<dd>
+		This variable is the relative path from this Makefile to the
+		top directory of your project's source code.  For example, if
+		your source code is in /tmp/src, then the Makefile in
+		/tmp/src/jump/high would set LEVEL to "../..".
+	</dl>
+
+	<h3> Variables for Building Subdirectories</h3>
+	<dl compact>
+		<dt>DIRS
+		<dd>
+		This is a space separated list of subdirectories that should be
+		built.  They will be built, one at a time, in the order
+		specified.
+		<p>
+
+		<dt>PARALLEL_DIRS
+		<dd>
+		This is a list of directories that can be built in parallel.
+		These will be built after the directories in DIRS have been
+		built.
+		<p>
+
+		<dt>OPTIONAL_DIRS
+		<dd>
+		This is a list of directories that can be built if they exist,
+		but will not cause an error if they do not exist.  They are
+		built serially in the order in which they are listed.
+	</dl>
+
+	<h3> Variables for Building Libraries</h3>
+	<dl compact>
+		<dt>LIBRARYNAME
+		<dd>
+		This variable contains the base name of the library that will
+		be built.  For example, to build a library named
+		<tt>libsample.a</tt>, LIBRARYNAME should be set to
+		<tt>sample</tt>.
+		<p>
+
+		<dt>BUILD_ARCHIVE
+		<dd>
+		By default, a library is a <tt>.o</tt> file that is linked
+		directly into a program.  To build an archive (also known as
+		a static library), set the BUILD_ARCHIVE variable.
+		<p>
+
+		<dt>SHARED_LIBRARY
+		<dd>
+		If SHARED_LIBRARY is defined in your Makefile, a shared
+		(or dynamic) library will be built.
+	</dl>
+
+	<h3> Variables for Building Programs</h3>
+	<dl compact>
+		<dt>TOOLNAME
+		<dd>
+		This variable contains the name of the program that will
+		be built.  For example, to build an executable named
+		<tt>sample</tt>, TOOLNAME should be set to <tt>sample</tt>.
+		<p>
+
+		<dt>USEDLIBS
+		<dd>
+		This variable holds a space separated list of libraries that
+		should be linked into the program.  These libraries must either
+		be LLVM libraries or libraries that come from your <b>lib</b>
+		directory.  The libraries must be specified by their base name.
+		For example, to link libsample.a, you would set USEDLIBS to
+		<tt>sample</tt>.
+		<p>
+		Note that this works only for statically linked libraries.
+		<p>
+
+		<dt>LIBS
+		<dd>
+		To link dynamic libraries, add <tt>-l&lt;library base name&gt;</tt> to
+		the LIBS variable.  The LLVM build system will look in the same places
+		for dynamic libraries as it does for static libraries.
+		<p>
+		For example, to link <tt>libsample.so</tt>, you would have the
+		following line in your <tt>Makefile</tt>:
+		<p>
+		<tt>
+		LIBS+=-lsample
+		</tt>
+	</dl>
+
+	<h3> Miscellaneous Variables</h3>
+	<dl compact>
+		<dt>ExtraSource
+		<dd>
+		This variable contains a space separated list of extra source
+		files that need to be built.  It is useful for including the
+		output of Lex and Yacc programs.
+		<p>
+
+		<dt>CFLAGS
+		<dt>CPPFLAGS
+		<dd>
+		This variable can be used to add options to the C and C++
+		compiler, respectively.  It is typically used to add options
+		that tell the compiler the location of additional directories
+		to search for header files.
+		<p>
+		It is highly suggested that you append to CFLAGS and CPPFLAGS as
+		opposed to overwriting them.  The master Makefiles may already
+		have useful options in them that you may not want to overwrite.
+		<p>
+	</dl>
+
+	<!--===============================================================-->
+	<h2><a name="objcode">Placement of Object Code</a><hr></h2>
+	<!--===============================================================-->
+
+	The final location of built libraries and executables will depend upon
+	whether you do a Debug, Release, or Profile build.
+
+	<dl compact>
+		<dt>Libraries
+		<dd>
+		All libraries (static and dynamic) will be stored in
+		BUILD_OBJ_ROOT/lib/&lt;type&gt;, 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 BUILD_OBJ_ROOT/lib/&lt;type&gt;,
+		where type is <tt>Debug</tt>, <tt>Release</tt>, or <tt>Profile</tt> for
+		a debug, optimized, or profiled build, respectively.
+	</dl>
+
+	<!--===============================================================-->
+	<h2><a name="help">Further Help</a><hr></h2>
+	<!--===============================================================-->
+
+	If you have any questions or need any help creating an LLVM project,
+	the LLVM team would be more than happy to help.  You can always post your
+  questions to the <a
+  href="http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVM Developers
+  Mailing List</a>.
+	
 <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:criswell@uiuc.edu">John Criswell</a><br>
-  <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
-  <br>
-  Last modified: $Date$
-</address>
+<address><a href="mailto:criswell@uiuc.edu">John Criswell</a></address><br>
+<a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a><br>
+Last modified: $Date$
 
 </body>
 </html>

llvm/docs/ReleaseNotes.html

@@ -3,33 +3,31 @@
 <html>
 <head>
   <link rel="stylesheet" href="llvm.css" type="text/css">
-  <title>LLVM 1.3 Release Notes</title>
+  <title>LLVM 1.1 Release Notes</title>
 </head>
 <body>
 
-<div class="doc_title">LLVM 1.3 Release Notes</div>
+<div class="doc_title">LLVM 1.1 Release Notes</div>
  
 <ol>
   <li><a href="#intro">Introduction</a></li>
   <li><a href="#whatsnew">What's New?</a></li>
-  <li><a href="GettingStarted.html">Installation Instructions</a></li>
   <li><a href="#portability">Portability and Supported Platforms</a></li>
+  <li><a href="#install-instructions">Installation Instructions</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="#sparc-be">Known problems with the Sparc 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>
+<div class="doc_text">
+  <p><b>Written by the <a href="http://llvm.cs.uiuc.edu">LLVM team</a></b><p>
 </div>
 
 <!-- *********************************************************************** -->
@@ -41,10 +39,10 @@
 <div class="doc_text">
 
 <p>This document contains the release notes for the LLVM compiler
-infrastructure, release 1.3.  Here we describe the status of LLVM, including any
+infrastructure, release 1.1.  Here we describe the status of LLVM, including any
 known problems and bug fixes from the previous release.  The most up-to-date
 version of this document can be found on the <a
-href="http://llvm.cs.uiuc.edu/releases/1.3/">LLVM 1.3 web site</a>.  If you are
+href="http://llvm.cs.uiuc.edu/releases/1.1/">LLVM 1.1 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>
 
@@ -69,92 +67,94 @@ href="http://llvm.cs.uiuc.edu/releases/">releases page</a>.</p>
 
 <div class="doc_text">
 
-<p>This is the fourth public release of the LLVM compiler infrastructure.  This
-release primarily improves the <a href="#codequality">performance of the
-code</a> produced by all aspects of the LLVM compiler, adds many <a
-href="#newfeatures">new features</a>, <a href="#bugfix">fixes a few
-bugs</a>, speeds up the compiler, and introduces a new (experimental)
-PowerPC code generator.</p>
+<p>This is the second public release of the LLVM compiler infrastructure.  This
+release is primarily a bugfix release, dramatically improving the C/C++
+front-end and improving support for C++ in the LLVM core.  This release also
+includes a few new features, such as a simple profiler, support for Mac OS X,
+better interoperability with external source bases, a new example language
+front-end, and improvements in a few optimizations.  The performance of several
+LLVM components has been improved, and several gratuitous type-safety issues in
+the C front-end have been fixed.</p>
 
-<p> At this time, LLVM is known to correctly compile and run all C &amp; C++
-SPEC CPU95 &amp; 2000 benchmarks, the Olden benchmarks, and the Ptrdist 
-benchmarks, and <b>many</b> other programs.  LLVM now also works
-with a broad variety of C++ programs.</p>
+<p>At this time, LLVM is known to correctly compile and run all non-unwinding C
+&amp; C++ SPEC CPU2000 benchmarks, the Olden benchmarks, and the Ptrdist
+benchmarks.  It has also been used to compile <b>many</b> other programs.  LLVM
+now also works with a broad variety of C++ programs, though it has still
+received much less testing than the C front-end.
+</p>
+
+<p>
+The LLVM native code generators are very stable but do not currently support
+unwinding (exception throwing or <tt>longjmp</tt>ing), which prevent them from
+working with programs like the <tt>253.perlbmk</tt> in SPEC CPU2000.  The C
+backend and the rest of LLVM supports these programs, so you can
+still use LLVM with them.  Support for unwinding will be added in a future
+release.
+</p>
 
-</div>
 
 <!--=========================================================================-->
 <div class="doc_subsubsection">
-<a name="newfeatures">This release implements the following new features:</a>
+This release implements the following new features:
 </div>
 
-<div class="doc_text">
-
 <ol>
-<li>The LLVM <a href="LangRef.html#i_select"><tt>select</tt></a> instruction is
-now fully implemented and supported by all transformations, native code
-generators, and the interpreter.</li>
-<li>Bugpoint can now narrow down code-generation bugs to a loop nest, where
-before it could only narrow them down to a function being miscompiled.</li>
-<li><a href="http://llvm.cs.uiuc.edu/PR40">Bugpoint can now debug arbitrary
-modes of llc</a> and lli, by passing them command line flags (e.g.
-<tt>-regalloc=linearscan</tt>).</li>
-<li>The Control Flow Graph in the native code generators is no longer
-constrained to be the same as the CFG for the LLVM input code.</li>
-<li>The LLVM induction variable analysis routines have been rewritten.</li>
-<li>LLVM now has new loop unrolling and loop unswitching passes.</li>
-<li>The induction variable substitution pass performs linear function test
-replacement and exit value replacement optimizations.</li>
-<li>LLVM now has first-class support for <a
-href="GarbageCollection.html">Accurate Garbage Collection</a>, enabling the use
-of aggressive copying and generational collectors.</li>
-<li>LLVM now includes a simple implementation of <a 
-href="AliasAnalysis.html#anders-aa">Andersen's interprocedural alias 
-analysis</a> algorithm.</li>
-<li>Bugpoint can <a href="http://llvm.cs.uiuc.edu/PR327">extract individual
-basic blocks</a> to track down reduce miscompilation testcases.</li>
-<li>LLVM and the C front-end now work under Win32 using the
-<a href="http://www.cygwin.com">Cygwin</a> runtime libraries.  
-This includes the JIT compiler.</li>
-<li>The LLVM code generator is now being <a
-href="CodeGenerator.html">documented</a>.</li>
-<li>LLVM includes a new tool, <a 
-href="CommandGuide/html/llvm-bcanalyzer.html">llvm-bcanalyzer</a>,  This tool 
-can compute various statistics and dump information about LLVM bytecode
-encoding.</li>
-<li>The <a href="BytecodeFormat.html">LLVM bytecode file format</a> is now 
-documented.</li>
-<li>LLVM now provides an <a
-href="LangRef.html#i_isunordered">llvm.isunordered</a> intrinsic for efficient
-implementation of unordered floating point comparisons.</li>
-<li>The llvmgcc front-end now supports the GCC builtins for ISO C99 floating
-point comparison macros (e.g., <tt>__builtin_islessequal</tt>).</li>
-<li>We now generate <a href="CommandGuide/">HTML documentation and man pages</a>
-for the tools from a single source (perl-style POD files).</li>
-<li>The LLVM code generator can now dynamically load targets from shared 
-objects.</li>
-<li>LLVM now includes a "skeleton" target, which makes it easier to get 
-started porting LLVM to new architectures.</li>
-<li>The linear scan register allocator is now enabled by default in the 
-target-independent code generator.</li>
-<li>LLVM now includes a dead store elimination pass.</li>
-<li>Bugpoint can now debug miscompilations that lead to the program going 
-into an infinite loop.</li>
-<li>LLVM now provides interfaces to support ML-style pattern matching on the 
-LLVM IR.</li>
-<li>LLVM now includes a <a 
-href="AliasAnalysis.html#globalsmodref">context-sensitive mod/ref analysis</a> 
-for global variables, which is now enabled by default in gccld.</li>
-<li>LLVM can now autogenerate assembly printers for code generators from the 
-tablegen description of the target (before they were hand coded).</li>
-<li>All LLVM tools will now respond to the 
-<a href="http://llvm.cs.uiuc.edu/PR413"><tt>--version</tt> option</a> which 
-will tell you the version of LLVM on which the tool is based.</li>
-<li>An experimental PowerPC backend has been added, capable of compiling several
-SPEC benchmarks.</li>
-</ol>
+<li><a
+href="http://mail.cs.uiuc.edu/pipermail/llvmdev/2003-November/000528.html">A new
+LLVM profiler, similar to gprof,</a> is available.</li>
 
-</div>
+<li>LLVM and the C/C++ front-end now compile on Mac OS X!  Mac OS X users can
+now explore the LLVM optimizer with the C backend and interpreter.  Note that
+LLVM requires GCC 3.3 on Mac OS X.</li>
+
+<li>LLVM has been <a
+href="http://mail.cs.uiuc.edu/pipermail/llvmdev/2003-November/000554.html">moved
+into an 'llvm' C++ namespace</a> for easier integration with third-party
+code. Note that due to lack of namespace support in GDB 5.x, you will probably
+want to upgrade to GDB 6 or better to debug LLVM code.</li>
+
+<li>
+The build system now copies Makefiles dynamically from the source tree to the
+object tree as subdirectories are built.  This means that:
+  <ol>
+  <li>
+  New directories can be added to the source tree, and the build will
+  automatically pick them up (i.e. no need to edit <tt>configure.ac</tt> and
+  re-run <tt>configure</tt>).
+  </li>
+
+  <li>
+  You will need to build LLVM from the top of the object tree once to ensure
+  that all of the Makefiles are copied into the object tree subdirectories.
+  </li>
+  </ol>
+</li>
+
+<li>A front-end for "Stacker" (a simple Forth-like language) is now
+    <a href="http://llvm.cs.uiuc.edu/PR136">included in the main LLVM tree</a>.
+    Additionally, Reid Spencer, the author, contributed a document
+    <a href="Stacker.html">describing his experiences writing Stacker and the language itself</a>.
+    This document is invaluable for others writing front-ends targetting LLVM.</li>
+
+<li>The <tt>configure</tt> script will now configure all projects placed in the
+<tt>llvm/projects</tt> directory.</li>
+
+<li>The <tt>-tailcallelim</tt> pass can now introduce "accumulator" variables
+    to transform functions in many common cases that it could not before.</li>
+
+<li>The <tt>-licm</tt> pass can now sink instructions out the bottom of loops
+in addition to being able to hoist them out the top.</li>
+
+<li>The <tt>-basicaa</tt> pass (the default alias analysis pass) has been
+upgraded to be <a href="http://llvm.cs.uiuc.edu/PR86">significantly more 
+precise</a>.</li>
+
+<li>LLVM 1.1 implements a simple size optimization for LLVM bytecode files.  
+    This means that the 1.1 files are smaller than 1.0, but LLVM 1.0 won't 
+    read 1.1 bytecode files.</li>
+
+<li><a href="http://llvm.cs.uiuc.edu/PR140">The gccld program produces a runner script that includes command-line options to load the necessary shared objects.</a></li>
+</ol>
 
 
 <!--=========================================================================-->
@@ -162,178 +162,138 @@ SPEC benchmarks.</li>
 In this release, the following missing features were implemented:
 </div>
 
-<div class="doc_text">
-
 <ol>
-<li><a href="http://llvm.cs.uiuc.edu/PR82">LLVM cannot handle structures with
-more than 256 elements</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR38">[bugpoint] External functions used in
-non-instruction entities, such as global constant initializer</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR178">Stacker does not handle targets 
-with 64-bit pointers.</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR290">Bugpoint doesn't support
-uses of external fns by immediate constant exprs</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR407">Can't add function passes that 
-depend on immutable passes to the FunctionPassManager</a>.</li>
-<li><a href="http://llvm.cs.uiuc.edu/PR308">Archive file reader doesn't
-understand abbreviated names in headers</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR88">The interpreter does not support
+invoke or unwind</a></li>
+
+<li><a href="http://llvm.cs.uiuc.edu/PR99">Interpreter does not support the
+<tt>vaarg</tt> instruction</a></li>
+
+<li><a href="http://llvm.cs.uiuc.edu/PR117">llvm-nm cannot read archive
+files</a></li>
+
+<li><a href="http://llvm.cs.uiuc.edu/PR146">Interpreter does not handle
+setne constant expression</a></li>
 </ol>
 
-</div>
 
 <!--=========================================================================-->
 <div class="doc_subsubsection">
-<a name="qualityofimp">In this release, the following Quality of Implementation
-issues were fixed:</a>
+In this release, the following Quality of Implementation issues were
+fixed:
 </div>
 
-<div class="doc_text">
-
 <ol>
-<li><a href="http://llvm.cs.uiuc.edu/PR305">LLVM tools will happily spew
-bytecode onto your terminal</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR329">[llvmgcc] type names are not emitted
-for structure typedefs</a></li>
-<li>All documentation is now conformant to the HTML 4.01 (Strict) level.</li>
-<li>The spurious "WARNING: Found global types that are not compatible" warning
-produced when linking C++ programs has been fixed.</li>
-<li><a href="http://llvm.cs.uiuc.edu/PR391">lli Doesn't Handle Exceptions From 
-Bytecode Reader</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR392">Global Vars Have (Somewhat) Limited 
-  Type Range</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR341">operator&lt;&lt; on a Value* now
-prints the address of the object instead of its contents.</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR402">Bytecode Enhancements
-Needed</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR404">[loopsimplify] Loop simplify is
-really slow on 252.eon</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR122">[code-cleanup] SymbolTable class
-cleanup, Type should not derive from Value, eliminate ConstantPointerRef
-class</a>.</li>
-<li>The memory footprint of the LLVM IR has been reduced substantially.</li>
-<li>The LLVM linker and many core classes have been sped up substantially.</li>
+
+<li>The C++ front-end now compiles functions to 
+    <a href="http://llvm.cs.uiuc.edu/PR29">use the linkonce linkage type</a> 
+    more, giving the optimizer more freedom.</li>
+
+<li>The C front-end now <a href="http://llvm.cs.uiuc.edu/PR84">generates 
+    type-safe code</a> in several cases that it did not before, allowing
+    optimization of code that could not be optimized previously.</li>
+
+<li>The LLVM build system has been taught to catch some common configuration 
+    problems that <a href="http://llvm.cs.uiuc.edu/PR96">caused it to get 
+    horribly confused</a>.</li>
+
+<li>The LLVM header files are now 
+    <a href="http://llvm.cs.uiuc.edu/PR114">-Wold-style-cast clean</a>.</li>
+
+<li>The LLVM bytecode reader has been <a
+href="http://llvm.cs.uiuc.edu/PR127">sped up a lot</a> (up to 4x in some
+cases).</li>
+
+<li>In C++, methods and functions in anonymous namespaces <a href="http://llvm.cs.uiuc.edu/PR85">now get internal linkage</a>.</li>
+
+<li>Constant initializers now generate loops instead of potentially <a href="http://llvm.cs.uiuc.edu/PR75">huge amounts of straight-line code</a>.</li>
+
+<li>Code for running C++ destructors is now properly shared when possible.  Before, the C++ front-end
+<a href="http://llvm.cs.uiuc.edu/PR11">generated N^2 amounts of duplicated cleanup code</a> in some cases.</li>
+
+<li>The JIT used to <a href="http://llvm.cs.uiuc.edu/PR177">generate code for 
+    all functions pointed to by globals</a> before the program 
+    started execution.  Now, it waits until the first time the functions are
+    called to
+    compile them.  This dramatically speeds up short runs of large C++ programs,
+    which often have large numbers of functions pointed to by vtables.</li>
 </ol>
 
-</div>
 
 <!--=========================================================================-->
 <div class="doc_subsubsection">
-In this release, the following build problems were fixed:
+In this release, the following bugs in the previous release were fixed:
 </div>
 
-<div class="doc_text">
-<ol>
-<li><a href="http://llvm.cs.uiuc.edu/PR301">Minor configure bugs with
--disable/enable-povray and -disable-spec</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR289">shell scripts output by gccld don't
-work if you change PATH</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR364">[llvmgcc] llvmgcc does not compile 
-with gcc 3.4</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR373">[llvmgcc] obstack.h relies on 
-obsolete casts-as-lvalues GCC extension</a></li>
-</ol>
-</div>
-
-<!--=========================================================================-->
-<div class="doc_subsubsection">
-<a name="codequality">This release includes the following Code Quality
-improvements:</a>
-</div>
-
-<div class="doc_text">
-<ol>
-<li>Fixed: <a href="http://llvm.cs.uiuc.edu/PR309">[vmcore] Code quality problem
-due to long operand of getelementptr</a></li>
-
-<li>The X86 backend now generates substantially better code for 64-bit integer
-and floating point operations.</li>
-
-<li>The -inline pass no longer inlines mutually recursive functions until it
-hits the inlining threshold.</li>
-
-<li>The -inline pass no longer misses obvious inlining opportunities just
-because the callee eventually calls into an external function.</li>
-
-<li>The -simplifycfg pass can now "if convert" simple statements into the 
-<tt>select</tt> instruction.</li>
-
-<li>The -loopsimplify pass can now break <a
-href="http://llvm.cs.uiuc.edu/PR35">natural loops with multiple backedges</a>
-into multiple nested loops.  This enables a variety of subsequent
-optimizations.</li>
-
-<li>The -adce pass can now eliminate calls to functions that do not not write to
-memory.</li>
-
-<li>The link-time optimizer now runs the -prune-eh pass (to remove unused
-exception handlers).</li>
-
-<li>The link-time optimizer now runs dead store elimination and uses a simple
-interprocedural alias analysis.</li>
-
-<li>The -simplifycfg pass can now eliminate simple correlated branches (such as
-"<tt>if (A &lt; B &amp;&amp; A &lt; B)</tt>", and can turn short-circuiting
-operators into the strict versions when useful (such as "<tt>if (A &lt; B || A
-&gt; C)</tt>" into "<tt>if (A &lt; B | A &gt; C)</tt>"</li>
-
-<li>LLVM now has infrastructure for (simple and sparse conditional) constant
-propagation of function calls.  It currently supports a few math library
-functions like sqrt/sin/cos/etc.</li>
-
-<li>The C backend now emits <a href="http://llvm.cs.uiuc.edu/PR334">syntactic
-loops</a> in the code to help C compilers whose optimizers do not recognize 
-loops formed from gotos (like GCC).</li>
-
-<li>The SparcV9 backend no longers <a 
-href="http://llvm.cs.uiuc.edu/PR368">spills the null constant to the constant 
-pool</a>.</li>
-</ol>
-</div>
-
-<!--=========================================================================-->
-<div class="doc_subsubsection">
-<a name="bugfix">In this release, the following bugs in the previous release
-were fixed:</a>
-</div>
-
-<div class="doc_text">
-
-<p>Bugs fixed in the LLVM Core:</p>
+<p>Bugs in the LLVM Core:</p>
 
 <ol>
-<li><a href="http://llvm.cs.uiuc.edu/PR306">[loopsimplify] Loop simplify
-incorrectly updates dominator information</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR310">[tailduplicate] DemoteRegToStack
-breaks SSA form</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR313">[X86] JIT miscompiles unsigned short
-to floating point cast</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR330">[vmcore] Linker causes erroneous
-asssertion</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR332">[adce] Crash handling unreachable
-code that unwinds</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR333">[sparcv9] LLC can't emit 2 functions
-of the same name, both having constant pools</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR337">[livevar] Live variables missed
-physical register use of aliased definition</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR369">[X86] stackifier crash on floating 
-point setcc X, X</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR57">[inliner] Inlining invoke with PHI in unwind target is broken</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR58">[linker] linkonce globals should link successfully to external globals</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR64">[constmerge] Constant merging pass merges constants with external linkage</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR66">[scalarrepl] Scalar Replacement of aggregates is decimating structures it shouldn't be</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR70">[instcombine] Resolving invoke inserts cast after terminator</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR71">llvm-as crashes when labels are used in phi nodes</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR72">[build problem] Callgraph.cpp not pulled in from libipa.a</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR77">Variables in scope of output setjmp
+calls should be volatile</a> (Note that this does not affect correctness on
+many platforms, such as X86).</li>
+<li><a href="http://llvm.cs.uiuc.edu/PR83">[X86] Emission of global bool initializers broken</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR91">[gccld] The -r (relinking) option does not work correctly</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR92">[bcreader] Cannot read shift constant expressions from bytecode file</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR93">[lowersetjmp] Lowersetjmp pass breaks dominance properties!</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR95">SymbolTable::getUniqueName is very inefficient</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR97">bugpoint must not pass -R&lt;directory&gt; to Mach-O linker</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR98">[buildscripts] Building into objdir with .o in it fails</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR101">[setjmp/longjmp] Linking C programs which use setjmp/longjmp sometimes fail with references to the C++ runtime library!</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR107">AsmParser Misses Symbol Redefinition Error</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR108">gccld -Lfoo -lfoo fails to find ./foo/libfoo.a</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR110">[bcreader] Incorrect cast causes misread forward constant references</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR116">[adce] ADCE considers blocks without postdominators to be unreachable</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR123">[X86] div and rem constant exprs invalidate iterators!</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR130">[vmcore] Symbol table doesn't rename colliding variables during type resolution</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR138">Archive reader does not understand 4.4BSD/Mac OS X long filenames</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR30">[llvm-ar] Command line arguments have funny syntax</a></li>
 </ol>
 
+
 <p>Bugs in the C/C++ front-end:</p>
 
 <ol>
-<li><a href="http://llvm.cs.uiuc.edu/PR298">[llvmgcc] Variable length array
-indexing miscompiled</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR326">[llvmgcc] Crash on use of undeclared
-enum type</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR355">[llvmgcc] Errors handling function 
-prototypes that take opaque structs by-value</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR374">[llvmgcc] Crash compiling variable 
-length array of structures</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR377">[llvmgcc] miscompilation of staticly
-initialized unsigned bitfields</a></li>
-<li><a href="http://llvm.cs.uiuc.edu/PR396">[llvm-gcc] Crash casting function to void</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR59">C++ frontend can crash when compiling virtual base classes</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR62">C backend fails on constant cast expr to ptr-to-anonymous struct</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR63">#ident is not recognized by C frontend</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR65">C front-end miscompiles the builtin_expect intrinsic!</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR67">1.0 precompiled libstdc++ does not include wchar_t support</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR68">llvmgcc asserts when compiling functions renamed with asm's</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR69">C frontend crashes on some programs with lots of types.</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR79">llvm-gcc crashes compiling global union initializer</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR80">C front-end crash on empty structure</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR81">CFrontend crashes when compiling C99 compound expressions</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR87">llvm-gcc infinite loops on "case MAXINT:"</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR89">[C++] Catch blocks make unparsable labels</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR90">[C++] Initializing array with constructible objects fail</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR94">llvm-gcc tries to add bools</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR104">[c++] C++ Frontend lays out superclasses like anonymous bitfields!</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR54">C front-end miscompiles unsigned enums whose LLVM types are signed</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR112">Casting a string constant to void crashes llvm-gcc</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR125">[llvmg++] Enum types are incorrectly shrunk to smaller than 'int' size</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR128">[llvmg++] Cannot use pointer to member to initialize global</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR131">[llvm-gcc] ?: operator as lvalue not implemented</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR133">[C/C++] Bogus warning about taking the address of 'register' variable</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR113">crash assigning into an array in a struct which contains a bitfield</a>.</li>
+<li><a href="http://llvm.cs.uiuc.edu/PR6">Oversized integer bitfields cause crash</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR141">[llvm-gcc] Bitfields &amp; large array don't mix well</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR132">[llvm-gcc] Complex division is not supported</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR143">[llvm-gcc] Illegal union field reference</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR148">[llvmg++] Front-end attempts to return structure by value</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR152">[llvmg++] Pointer to member initializers not supported in constructors</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR155">[llvm-gcc] crash on union initialization</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR124">[llvm-g++] ?: expressions do not run correct number of destructors!</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR157">[llvm-gcc] Pointer & constant results in invalid shift</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR165">[llvmg++] call through array of pointers to member functions causes assertion</a></li>
 </ol>
+
 </div>
 
 <!-- *********************************************************************** -->
@@ -344,30 +304,15 @@ initialized unsigned bitfields</a></li>
 
 <div class="doc_text">
 
-<p>LLVM is known to work in the following platforms:</p>
-
-<ul>
-<li>Intel and AMD machines running Red Hat Linux and FreeBSD (and probably 
-    other unix-like systems).</li>
-<li>Sun UltraSPARC workstations running Solaris 8.</li>
-<li>Intel and AMD machines running on Win32 with the Cygwin libraries.</li>
-<li>PowerPC-based Mac OS X boxes, running 10.2 and above.  Note that no JIT
-support is available yet, and LLC support is beta.  The C backend can be used
-to produce stable code for this platform.</li>
-</ul>
-
-<p>The core LLVM infrastructure uses
-<a href="http://www.gnu.org/software/autoconf/">GNU autoconf</a> to adapt itself
-to the machine and operating system on which it is built.  However, minor
-porting may be required to get LLVM to work on new platforms.  We welcome your
-portability patches and reports of successful builds or error messages.</p>
-
-<p>Note that the LLVM build system does not currently support directories with 
-spaces on them when running on Win32/cygwin.  We strongly recommend running
-LLVM and the C frontend out of a top-level directory without spaces (e.g., 
-<tt>/cygdrive/c/llvm</tt>).  Also, make sure to install <b>all</b> of the 
-cygwin packages.  By default, many important tools are not installed that 
-are needed by the LLVM build process or test suite (e.g., /bin/time).</p>
+<p>LLVM has been extensively tested on Intel and AMD machines running Red
+Hat Linux and has been tested on Sun UltraSPARC workstations running Solaris 8.
+Additionally, 
+LLVM works on Mac OS X 10.3 and above, but only with the C backend or 
+interpreter (no native backend for the PowerPC is available yet).
+The core LLVM infrastructure uses "autoconf" for portability, so hopefully we
+work on more platforms than that.  However, it is likely that we
+missed something and that minor porting is required to get LLVM to work on 
+new platforms.  We welcome portability patches and error messages.</p>
 
 </div>
 
@@ -387,32 +332,11 @@ there isn't already one.</p>
 
 </div>
 
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="experimental">Experimental features included with this release</a>
-</div>
+<!-- _______________________________________________________________________ -->
+<!--
+</ul><h4><a name="portability"><hr size=0>Portability Problems</h4><ul>
+-->
 
-<div class="doc_text">
-
-<p>The following components of this LLVM release are either untested, known to
-be broken or unreliable, or are in early development.  These components should
-not be relied on, and bugs should not be filed against them, but they may be
-useful to some people.  In particular, if you would like to work on one of these
-components, please contact us on the llvmdev list.</p>
-
-<ul>
-<li>The PowerPC backend is incomplete and is known to miscompile several SPEC
-benchmarks. The file <tt>llvm/lib/Target/PowerPC/README.txt</tt> has
-details.</li>
-<li>The following passes are incomplete or buggy: <tt>-pgmdep, -memdep,
-    -ipmodref, -cee</tt></li>
-<li>The <tt>-pre</tt> pass is incomplete (there are cases it doesn't handle that
-    it should) and not thoroughly tested.</li>
-<li>The <tt>llvm-ar</tt> tool is incomplete and probably buggy.</li>
-<li>The <tt>llvm-db</tt> tool is in a very early stage of development.</li>
-</ul>
-
-</div>
 
 <!-- ======================================================================= -->
 <div class="doc_subsection">
@@ -430,17 +354,28 @@ work.</li>
 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 (there is no symbol
+<li>It is not possible to <tt>dlopen</tt> an LLVM bytecode file in the JIT.</li>
+
+<li>Linking in static archive files (.a files) is very slow (there is no symbol
 table in the archive).</li>
 
-<li>The gccld program <a href="http://llvm.cs.uiuc.edu/PR139">does not link
-objects/archives in the order specified on the command line.</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR82">LLVM cannot handle structures with
+more than 256 elements</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>
+The gccld program 
+<a href="http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=139">
+does not link objects/archives in the order specified on the command line.
+</a>
+</li>
+
+<li>
+<a href="http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=174">
+Tail duplication does not update SSA form correctly.
+</a>
+</li>
 </ul>
+
 </div>
 
 <!-- ======================================================================= -->
@@ -449,7 +384,9 @@ register file.</li>
 </div>
 
 <!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">Bugs</div>
+<div class="doc_subsubsection">
+  Bugs
+</div>
 
 <div class="doc_text">
 <ul>
@@ -462,13 +399,26 @@ register file.</li>
     }
 </pre></li>
 
-<li>Initialization of global union variables can only be done <a
-href="http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=162">with the largest union
-member</a>.</li>
+<li>
+Initialization of global union variables can only be done
+<a href="http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=162">with the largest
+union member</a>.
+</li>
 
-<li><a href="http://llvm.cs.uiuc.edu/PR244">[llvm-gcc] Error when an implicitly
-external function is re-declared as static</a></li>
+<li>
+<a href="http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=182">
+Functions marked "extern inline" are not compiled into LLVM with linkonce
+linkage.
+</a>
+</li>
 
+
+<li>
+The memory management functions in the libc runtime
+<a href="http://llvm.cs.uiuc.edu/PR186">need weak linkage so that they can be
+overridden.
+</a>
+</li>
 </ul>
 </div>
 
@@ -501,12 +451,14 @@ work:
     the following extensions are known to <b>not be</b> supported:
   <ol>
   <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Local-Labels.html#Local%20Labels">Local Labels</a>: Labels local to a block.</li>
+  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html#Labels%20as%20Values">Labels as Values</a>: Getting pointers to labels and computed gotos.</li>
   <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html#Nested%20Functions">Nested Functions</a>: As in Algol and Pascal, lexical scoping of functions.</li>
   <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Constructing-Calls.html#Constructing%20Calls">Constructing Calls</a>: Dispatching a call to another function.</li>
   <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Extended%20Asm">Extended Asm</a>: Assembler instructions with C expressions as operands.</li>
   <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Constraints.html#Constraints">Constraints</a>: Constraints for asm operands.</li>
   <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Asm-Labels.html#Asm%20Labels">Asm Labels</a>: Specifying the assembler name to use for a C symbol.</li>
   <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/Return-Address.html#Return%20Address">Return Address</a>: Getting the return or frame address of a function.</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>
@@ -564,18 +516,16 @@ work:
       We support all builtins which have a C language equivalent (e.g., 
          <tt>__builtin_cos</tt>),  <tt>__builtin_alloca</tt>, 
          <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>
+         <tt>__builtin_constant_p</tt>, and <tt>__builtin_expect</tt> (ignored).</li>
+
   </ol>
 
   <p>The following extensions <b>are</b> known to be supported:</p>
 
   <ol>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html#Labels%20as%20Values">Labels as Values</a>: Getting pointers to labels and computed gotos.</li>
   <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html#Statement%20Exprs">Statement Exprs</a>:   Putting statements and declarations inside expressions.</li>
   <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Typeof.html#Typeof">Typeof</a>: <code>typeof</code>: referring to the type of an expression.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc-3.4.0/gcc/Lvalues.html#Lvalues">Lvalues</a>: Using <code>?:</code>, "<code>,</code>" and casts in lvalues.</li>
+  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Lvalues.html#Lvalues">Lvalues</a>: Using <code>?:</code>, "<code>,</code>" and casts in lvalues.</li>
   <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Conditionals.html#Conditionals">Conditionals</a>: Omitting the middle operand of a <code>?:</code> expression.</li>
   <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Long-Long.html#Long%20Long">Long Long</a>: Double-word integers.</li>
   <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Complex.html#Complex">Complex</a>:   Data types for complex numbers.</li>
@@ -602,7 +552,6 @@ or arrays as values.</li>
   <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Alternate-Keywords.html#Alternate%20Keywords">Alternate Keywords</a>:<code>__const__</code>, <code>__asm__</code>, etc., for header files.</li>
   <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Incomplete-Enums.html#Incomplete%20Enums">Incomplete Enums</a>:  <code>enum foo;</code>, with details to follow.</li>
   <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Function-Names.html#Function%20Names">Function Names</a>: Printable strings which are the name of the current function.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Return-Address.html#Return%20Address">Return Address</a>: Getting the return or frame address of a function.</li>
   <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Unnamed-Fields.html#Unnamed%20Fields">Unnamed Fields</a>: Unnamed struct/union fields within structs/unions.</li>
   <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#Attribute%20Syntax">Attribute Syntax</a>: Formal syntax for attributes.</li>
   </ol></li>
@@ -629,7 +578,9 @@ Please report any bugs or problems.</p>
 </div>
 
 <!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">Bugs</div>
+<div class="doc_subsubsection">
+  Bugs
+</div>
 
 <div class="doc_text">
 
@@ -637,14 +588,12 @@ 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>
-
+<li>
+<a href="http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=137">
+Code is generated for empty classes.
+</a>
+</li>
 </ul>
-
 </div>
 
 <!-- _______________________________________________________________________ -->
@@ -690,21 +639,35 @@ 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>The X86 code generator <a
+href="http://llvm.cs.uiuc.edu/PR16">does not currently
+support the <tt>unwind</tt> instruction</a>, so code that throws a C++ exception
+or calls the C <tt>longjmp</tt> function will abort.</li>
+
 </ul>
 
 </div>
 
 <!-- ======================================================================= -->
 <div class="doc_subsection">
-  <a name="sparcv9-be">Known problems with the SparcV9 back-end</a>
+  <a name="sparc-be">Known problems with the Sparc back-end</a>
 </div>
 
 <div class="doc_text">
 
 <ul>
-<li><a href="http://llvm.cs.uiuc.edu/PR60">[sparcv9] SparcV9 backend miscompiles
-several programs in the LLVM test suite</a></li>
+
+<li>The Sparc code generator <a
+href="http://llvm.cs.uiuc.edu/PR15">does not currently
+support the <tt>unwind</tt> instruction</a>, so code that throws a C++ exception
+or calls the C <tt>longjmp</tt> function will abort.</li>
+
+<li>
+<a href="http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=167">
+The llc program can crash on legal code.
+</a>
+</li>
 </ul>
 
 </div>
@@ -760,7 +723,7 @@ lists</a>.</p>
 
 <hr>
 <address>
-  <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+  <a href="http://jigsaw.w3.org/css-validator/"><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>

llvm/docs/Stacker.html

@@ -1,18 +1,12 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
-                      "http://www.w3.org/TR/html4/strict.dtd">
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
 <html>
 <head>
-  <title>Stacker: An Example Of Using LLVM</title>
+    <title>Stacker: An Example Of Using LLVM</title>
   <link rel="stylesheet" href="llvm.css" type="text/css">
-  <style>
-    table, tr, td { border: 2px solid gray }
-    table { border-collapse: collapse; margin-bottom: 2em }
-  </style>
 </head>
 <body>
-
 <div class="doc_title">Stacker: An Example Of Using LLVM</div>
-
+<hr>
 <ol>
   <li><a href="#abstract">Abstract</a></li>
   <li><a href="#introduction">Introduction</a></li>
@@ -25,17 +19,19 @@
       <li><a href="#gep">The Wily GetElementPtrInst</a></li>
       <li><a href="#linkage">Getting Linkage Types Right</a></li>
       <li><a href="#constants">Constants Are Easier Than That!</a></li>
-    </ol></li>
+    </ol>
+  </li>
   <li><a href="#lexicon">The Stacker Lexicon</a>
     <ol>
-      <li><a href="#stack">The Stack</a></li>
-      <li><a href="#punctuation">Punctuation</a></li>
-      <li><a href="#comments">Comments</a></li>
-      <li><a href="#literals">Literals</a></li>
-      <li><a href="#words">Words</a></li>
-      <li><a href="#style">Standard Style</a></li>
-      <li><a href="#builtins">Built-Ins</a></li>
-    </ol></li>
+      <li><a href="#stack">The Stack</a>
+      <li><a href="#punctuation">Punctuation</a>
+      <li><a href="#comments">Comments</a>
+      <li><a href="#literals">Literals</a>
+      <li><a href="#words">Words</a>
+      <li><a href="style">Standard Style</a>
+      <li><a href="#builtins">Built-Ins</a>
+    </ol>
+  </li>
   <li><a href="#example">Prime: A Complete Example</a></li>
   <li><a href="#internal">Internal Code Details</a>
     <ol>
@@ -48,19 +44,20 @@
       <li><a href="#tests">Test Programs</a></li>
       <li><a href="#exercise">Exercise</a></li>
       <li><a href="#todo">Things Remaining To Be Done</a></li>
-    </ol></li>
+    </ol>
+  </li>
 </ol>
-
-<div class="doc_author">
-  <p>Written by <a href="mailto:rspencer@x10sys.com">Reid Spencer</a></p>
+<div class="doc_text">
+<p><b>Written by <a href="mailto:rspencer@x10sys.com">Reid Spencer</a> </b></p>
+<p> </p>
 </div>
-
+<hr>
 <!-- ======================================================================= -->
-<div class="doc_section"><a name="abstract">Abstract</a></div>
+<div class="doc_section"> <a name="abstract">Abstract </a></div>
 <div class="doc_text">
 <p>This document is another way to learn about LLVM. Unlike the 
 <a href="LangRef.html">LLVM Reference Manual</a> or 
-<a href="ProgrammersManual.html">LLVM Programmer's Manual</a>, here we learn
+<a href="ProgrammersManual.html">LLVM Programmer's Manual</a>, we learn
 about LLVM through the experience of creating a simple programming language
 named Stacker.  Stacker was invented specifically as a demonstration of
 LLVM. The emphasis in this document is not on describing the
@@ -73,10 +70,11 @@ compiler system.</p>
 <p>Amongst other things, LLVM is a platform for compiler writers.
 Because of its exceptionally clean and small IR (intermediate
 representation), compiler writing with LLVM is much easier than with
-other system. As proof, I wrote the entire compiler (language definition, 
-lexer, parser, code generator, etc.) in about <em>four days</em>! 
-That's important to know because it shows how quickly you can get a new
-language running when using LLVM. Furthermore, this was the <em >first</em> 
+other systems. As proof, the author of Stacker wrote the entire
+compiler (language definition, lexer, parser, code generator, etc.) in
+about <em>four days</em>! That's important to know because it shows 
+how quickly you can get a new
+language up when using LLVM. Furthermore, this was the <em >first</em> 
 language the author ever created using LLVM. The learning curve is 
 included in that four days.</p>
 <p>The language described here, Stacker, is Forth-like. Programs
@@ -131,38 +129,39 @@ I noted that most of the important LLVM IR (Intermediate Representation) C++
 classes were derived from the Value class. The full power of that simple
 design only became fully understood once I started constructing executable
 expressions for Stacker.</p>
-
 <p>This really makes your programming go faster. Think about compiling code
 for the following C/C++ expression: <code>(a|b)*((x+1)/(y+1))</code>. Assuming
 the values are on the stack in the order a, b, x, y, this could be
 expressed in stacker as: <code>1 + SWAP 1 + / ROT2 OR *</code>.
-You could write a function using LLVM that computes this expression like 
-this: </p>
-
-<div class="doc_code"><pre>
+You could write a function using LLVM that computes this expression like this: </p>
+<pre><code>
 Value* 
-expression(BasicBlock* bb, Value* a, Value* b, Value* x, Value* y )
+expression(BasicBlock*bb, Value* a, Value* b, Value* x, Value* y )
 {
-    ConstantSInt* one = ConstantSInt::get(Type::IntTy, 1);
-    BinaryOperator* or1 = BinaryOperator::createOr(a, b, "", bb);
-    BinaryOperator* add1 = BinaryOperator::createAdd(x, one, "", bb);
-    BinaryOperator* add2 = BinaryOperator::createAdd(y, one, "", bb);
-    BinaryOperator* div1 = BinaryOperator::createDiv(add1, add2, "", bb);
-    BinaryOperator* mult1 = BinaryOperator::createMul(or1, div1, "", bb);
+    Instruction* tail = bb->getTerminator();
+    ConstantSInt* one = ConstantSInt::get( Type::IntTy, 1);
+    BinaryOperator* or1 = 
+	BinaryOperator::create( Instruction::Or, a, b, "", tail );
+    BinaryOperator* add1 = 
+	BinaryOperator::create( Instruction::Add, x, one, "", tail );
+    BinaryOperator* add2 =
+	BinaryOperator::create( Instruction::Add, y, one, "", tail );
+    BinaryOperator* div1 = 
+	BinaryOperator::create( Instruction::Div, add1, add2, "", tail);
+    BinaryOperator* mult1 = 
+	BinaryOperator::create( Instruction::Mul, or1, div1, "", tail );
+
     return mult1;
 }
-</pre></div>
-
-<p>"Okay, big deal," you say?  It is a big deal. Here's why. Note that I didn't
+</code></pre>
+<p>"Okay, big deal," you say.  It is a big deal. Here's why. Note that I didn't
 have to tell this function which kinds of Values are being passed in. They could be
-<code>Instruction</code>s, <code>Constant</code>s, <code>GlobalVariable</code>s, or
-any of the other subclasses of <code>Value</code> that LLVM supports.
-Furthermore, if you specify Values that are incorrect for this sequence of 
+<code>Instruction</code>s, <code>Constant</code>s, <code>GlobalVariable</code>s, 
+etc. Furthermore, if you specify Values that are incorrect for this sequence of 
 operations, LLVM will either notice right away (at compilation time) or the LLVM 
-Verifier will pick up the inconsistency when the compiler runs. In either case 
-LLVM prevents you from making a type error that gets passed through to the 
-generated program.  This <em>really</em> helps you write a compiler that 
-always generates correct code!<p>
+Verifier will pick up the inconsistency when the compiler runs. In no case will 
+you make a type error that gets passed through to the generated program. 
+This <em>really</em> helps you write a compiler that always generates correct code!<p>
 <p>The second point is that we don't have to worry about branching, registers,
 stack variables, saving partial results, etc. The instructions we create 
 <em>are</em> the values we use. Note that all that was created in the above
@@ -222,11 +221,11 @@ should be constructed. In general, here's what I learned:
     before. This makes for some very clean compiler design.</li>
 </ol>
 <p>The foregoing is such an important principal, its worth making an idiom:</p>
-<pre>
-BasicBlock* bb = new BasicBlock();
+<pre><code>
+BasicBlock* bb = new BasicBlock();</li>
 bb->getInstList().push_back( new Branch( ... ) );
 new Instruction(..., bb->getTerminator() );
-</pre>
+</code></pre>
 <p>To make this clear, consider the typical if-then-else statement
 (see StackerCompiler::handle_if() method).  We can set this up
 in a single function using LLVM in the following way: </p>
@@ -236,26 +235,26 @@ BasicBlock*
 MyCompiler::handle_if( BasicBlock* bb, SetCondInst* condition )
 {
     // Create the blocks to contain code in the structure of if/then/else
-    BasicBlock* then_bb = new BasicBlock(); 
-    BasicBlock* else_bb = new BasicBlock();
-    BasicBlock* exit_bb = new BasicBlock();
+    BasicBlock* then = new BasicBlock(); 
+    BasicBlock* else = new BasicBlock();
+    BasicBlock* exit = new BasicBlock();
 
     // Insert the branch instruction for the "if"
-    bb->getInstList().push_back( new BranchInst( then_bb, else_bb, condition ) );
+    bb->getInstList().push_back( new BranchInst( then, else, condition ) );
 
     // Set up the terminating instructions
-    then->getInstList().push_back( new BranchInst( exit_bb ) );
-    else->getInstList().push_back( new BranchInst( exit_bb ) );
+    then->getInstList().push_back( new BranchInst( exit ) );
+    else->getInstList().push_back( new BranchInst( exit ) );
 
     // Fill in the then part .. details excised for brevity
-    this->fill_in( then_bb );
+    this->fill_in( then );
 
     // Fill in the else part .. details excised for brevity
-    this->fill_in( else_bb );
+    this->fill_in( else );
 
     // Return a block to the caller that can be filled in with the code
     // that follows the if/then/else construct.
-    return exit_bb;
+    return exit;
 }
 </pre>
 <p>Presumably in the foregoing, the calls to the "fill_in" method would add 
@@ -265,18 +264,15 @@ terminator). Furthermore, they could even recurse back to <code>handle_if</code>
 should they encounter another if/then/else statement, and it will just work.</p>
 <p>Note how cleanly this all works out. In particular, the push_back methods on
 the <code>BasicBlock</code>'s instruction list. These are lists of type 
-<code>Instruction</code> (which is also of type <code>Value</code>). To create 
-the "if" branch we merely instantiate a <code>BranchInst</code> that takes as 
-arguments the blocks to branch to and the condition to branch on. The 
-<code>BasicBlock</code> objects act like branch labels! This new 
-<code>BranchInst</code> terminates the <code>BasicBlock</code> provided 
-as an argument. To give the caller a way to keep inserting after calling 
-<code>handle_if</code>, we create an <code>exit_bb</code> block which is
-returned 
-to the caller.  Note that the <code>exit_bb</code> block is used as the 
-terminator for both the <code>then_bb</code> and the <code>else_bb</code>
-blocks. This guarantees that no matter what else <code>handle_if</code>
-or <code>fill_in</code> does, they end up at the <code>exit_bb</code> block.
+<code>Instruction</code> which also happen to be <code>Value</code>s. To create 
+the "if" branch, we merely instantiate a <code>BranchInst</code> that takes as 
+arguments the blocks to branch to and the condition to branch on. The blocks
+act like branch labels! This new <code>BranchInst</code> terminates
+the <code>BasicBlock</code> provided as an argument. To give the caller a way
+to keep inserting after calling <code>handle_if</code>, we create an "exit" block
+which is returned to the caller.  Note that the "exit" block is used as the 
+terminator for both the "then" and the "else" blocks. This guarantees that no
+matter what else "handle_if" or "fill_in" does, they end up at the "exit" block.
 </p>
 </div>
 <!-- ======================================================================= -->
@@ -301,21 +297,20 @@ read the Language Reference and Programmer's Manual a couple times each, I still
 missed a few <em>very</em> key points:
 </p>
 <ul>
-<li>GetElementPtrInst gives you back a Value for the last thing indexed.</li>
-<li>All global variables in LLVM  are <em>pointers</em>.</li>
-<li>Pointers must also be dereferenced with the GetElementPtrInst
-instruction.</li>
+    <li>GetElementPtrInst gives you back a Value for the last thing indexed.</em>
+    <li>All global variables in LLVM  are <em>pointers</em>.
+    <li>Pointers must also be dereferenced with the GetElementPtrInst instruction.
 </ul>
 <p>This means that when you look up an element in the global variable (assuming
 it's a struct or array), you <em>must</em> deference the pointer first! For many
 things, this leads to the idiom:
 </p>
-<pre>
-std::vector&lt;Value*&gt; index_vector;
+<pre><code>
+std::vector<Value*> index_vector;
 index_vector.push_back( ConstantSInt::get( Type::LongTy, 0 );
 // ... push other indices ...
 GetElementPtrInst* gep = new GetElementPtrInst( ptr, index_vector );
-</pre>
+</code></pre>
 <p>For example, suppose we have a global variable whose type is [24 x int]. The
 variable itself represents a <em>pointer</em> to that array. To subscript the
 array, we need two indices, not just one. The first index (0) dereferences the
@@ -323,8 +318,8 @@ pointer. The second index subscripts the array. If you're a "C" programmer, this
 will run against your grain because you'll naturally think of the global array
 variable and the address of its first element as the same. That tripped me up
 for a while until I realized that they really do differ .. by <em>type</em>.
-Remember that LLVM is strongly typed. Everything has a type.  
-The "type" of the global variable is [24 x int]*. That is, it's
+Remember that LLVM is a strongly typed language itself. Everything
+has a type.  The "type" of the global variable is [24 x int]*. That is, it's
 a pointer to an array of 24 ints.  When you dereference that global variable with
 a single (0) index, you now have a "[24 x int]" type.  Although
 the pointer value of the dereferenced global and the address of the zero'th element
@@ -337,7 +332,7 @@ a lot of compiler writing headaches down the road.</p>
 <div class="doc_subsection"><a name="linkage"></a>Getting Linkage Types Right</div>
 <div class="doc_text">
 <p>Linkage types in LLVM can be a little confusing, especially if your compiler
-writing mind has affixed firm concepts to particular words like "weak",
+writing mind has affixed very hard concepts to particular words like "weak",
 "external", "global", "linkonce", etc. LLVM does <em>not</em> use the precise
 definitions of, say, ELF or GCC, even though they share common terms. To be fair,
 the concepts are related and similar but not precisely the same. This can lead
@@ -347,19 +342,16 @@ different. I recommend you read the
 carefully. Then, read it again.<p>
 <p>Here are some handy tips that I discovered along the way:</p>
 <ul>
-    <li><em>Uninitialized means external.</em> That is, the symbol is declared in the current
-    module and can be used by that module, but it is not defined by that module.</li>
-    <li><em>Setting an initializer changes a global' linkage type.</em> Setting an 
-    initializer changes a global's linkage type from whatever it was to a normal, 
-    defined global (not external). You'll need to call the setLinkage() method to 
-    reset it if you specify the initializer after the GlobalValue has been constructed. 
-    This is important for LinkOnce and Weak linkage types.</li> 
-    <li><em>Appending linkage can keep track of things.</em> Appending linkage can 
-    be used to keep track of compilation information at runtime. It could be used, 
-    for example, to build a full table of all the C++ virtual tables or hold the 
-    C++ RTTI data, or whatever. Appending linkage can only be applied to arrays. 
-    All arrays with the same name in each module are concatenated together at link 
-    time.</li>
+    <li>Uninitialized means external. That is, the symbol is declared in the current
+    module and can be used by that module but it is not defined by that module.</li>
+    <li>Setting an initializer changes a global's linkage type from whatever it was
+    to a normal, defined global (not external). You'll need to call the setLinkage()
+    method to reset it if you specify the initializer after the GlobalValue has been
+    constructed. This is important for LinkOnce and Weak linkage types.</li> 
+    <li>Appending linkage can be used to keep track of compilation information at
+    runtime. It could be used, for example, to build a full table of all the C++
+    virtual tables or hold the C++ RTTI data, or whatever. Appending linkage can 
+    only be applied to arrays. The arrays are concatenated together at link time.</li>
 </ul>
 </div>
 <!-- ======================================================================= -->
@@ -431,7 +423,7 @@ the stack manipulating words that you wish to define <code>name</code> as. <p>
 # This is a comment to end of line
 ( This is an enclosed comment )
 </code></pre>
-<p>See the <a href="#example">example</a> program to see comments in use in 
+<p>See the <a href="#example">example</a> program to see how this works in 
 a real program.</p>
 </div>
 <!-- ======================================================================= -->
@@ -454,9 +446,9 @@ the stack. It is assumed that the programmer knows how the stack
 transformation he applies will affect the program.</p>
 <p>Words in a definition come in two flavors: built-in and programmer
 defined. Simply mentioning the name of a previously defined or declared
-programmer-defined word causes that word's stack actions to be invoked. It
+programmer-defined word causes that word's definition to be invoked. It
 is somewhat like a function call in other languages. The built-in
-words have various effects, described <a href="#builtins">below</a>.</p>
+words have various effects, described below.</p>
 <p>Sometimes you need to call a word before it is defined. For this, you can
 use the <code>FORWARD</code> declaration. It looks like this:</p>
 <p><code>FORWARD name ;</code></p>
@@ -467,11 +459,6 @@ unit. Anything declared with <code>FORWARD</code> is an external symbol for
 linking.</p>
 </div>
 <!-- ======================================================================= -->
-<div class="doc_subsection"><a name="style"></a>Standard Style</div>
-<div class="doc_text">
-<p>TODO</p>
-</div>
-<!-- ======================================================================= -->
 <div class="doc_subsection"><a name="builtins"></a>Built In Words</div>
 <div class="doc_text">
 <p>The built-in words of the Stacker language are put in several groups 
@@ -484,10 +471,9 @@ depending on what they do. The groups are as follows:</p>
     their operands. <br/> The words are: &lt;&lt; &gt;&gt; XOR AND NOT</li>
     <li><em>Arithmetic</em>: These words perform arithmetic computations on
     their operands. <br/> The words are: ABS NEG + - * / MOD */ ++ -- MIN MAX</li>
-    <li><em>Stack</em>These words manipulate the stack directly by moving
-    its elements around.<br/> The words are: DROP DROP2 NIP NIP2 DUP DUP2 
-    SWAP SWAP2 OVER OVER2 ROT ROT2 RROT RROT2 TUCK TUCK2 PICK SELECT ROLL</li>
-    <li><em>Memory</em>These words allocate, free, and manipulate memory
+    <li><em>Stack</em>: These words manipulate the stack directly by moving
+    its elements around.<br/> The words are: DROP DUP SWAP OVER ROT DUP2 DROP2 PICK TUCK</li>
+    <li><em>Memory</em>: These words allocate, free, and manipulate memory
     areas outside the stack.<br/>The words are: MALLOC FREE GET PUT</li>
     <li><em>Control</em>: These words alter the normal left to right flow
     of execution.<br/>The words are: IF ELSE ENDIF WHILE END RETURN EXIT RECURSE</li>
@@ -514,18 +500,12 @@ using the following construction:</p>
     <li><em>p</em> - a pointer to a malloc'd memory block</li>
 </ol>
 </div>
-<div class="doc_text" >
-    <table class="doc_table">
+<div class="doc_text">
+<table class="doc_table" >
 <tr class="doc_table"><td colspan="4">Definition Of Operation Of Built In Words</td></tr>
-<tr class="doc_table"><td colspan="4"><b>LOGICAL OPERATIONS</b></td></tr>
-<tr class="doc_table">
-    <td>Word</td>
-    <td>Name</td>
-    <td>Operation</td>
-    <td>Description</td>
-</tr>
-<tr class="doc_table">
-    <td>&lt;</td>
+<tr class="doc_table"><td colspan="4">LOGICAL OPERATIONS</td></tr>
+<tr class="doc_table"><td>Word</td><td>Name</td><td>Operation</td><td>Description</td></tr>
+<tr class="doc_table"><td>&lt;</td>
     <td>LT</td>
     <td>w1 w2 -- b</td>
     <td>Two values (w1 and w2) are popped off the stack and
@@ -581,13 +561,8 @@ using the following construction:</p>
     <td> -- b</td>
     <td>The boolean value TRUE (-1) is pushed on to the stack.</td>
 </tr>
-<tr><td colspan="4"><b>BITWISE OPERATORS</b></td></tr>
-<tr>
-    <td>Word</td>
-    <td>Name</td>
-    <td>Operation</td>
-    <td>Description</td>
-</tr>
+<tr><td colspan="4">BITWISE OPERATIONS</td></tr>
+<tr><td>Word</td><td>Name</td><td>Operation</td><td>Description</td></tr>
 <tr><td>&lt;&lt;</td>
     <td>SHL</td>
     <td>w1 w2 -- w1&lt;&lt;w2</td>
@@ -623,13 +598,8 @@ using the following construction:</p>
     are bitwise exclusive OR'd together and pushed back on the stack. 
     For example, The sequence 1 3 XOR yields 2.</td>
 </tr>
-<tr><td colspan="4"><b>ARITHMETIC OPERATORS</b></td></tr>
-<tr>
-    <td>Word</td>
-    <td>Name</td>
-    <td>Operation</td>
-    <td>Description</td>
-</tr>
+<tr><td colspan="4">ARITHMETIC OPERATIONS</td></tr>
+<tr><td>Word</td><td>Name</td><td>Operation</td><td>Description</td></tr>
 <tr><td>ABS</td>
     <td>ABS</td>
     <td>w -- |w|</td>
@@ -704,13 +674,8 @@ using the following construction:</p>
     <td>Two values are popped off the stack. The larger value is pushed back
 	on to the stack.</td>
 </tr>
-<tr><td colspan="4"><b>STACK MANIPULATION OPERATORS</b></td></tr>
-<tr>
-    <td>Word</td>
-    <td>Name</td>
-    <td>Operation</td>
-    <td>Description</td>
-</tr>
+<tr><td colspan="4">STACK MANIPULATION OPERATIONS</td></tr>
+<tr><td>Word</td><td>Name</td><td>Operation</td><td>Description</td></tr>
 <tr><td>DROP</td>
     <td>DROP</td>
     <td>w -- </td>
@@ -739,12 +704,12 @@ using the following construction:</p>
     <td>DUP</td>
     <td>w1 -- w1 w1</td>
     <td>One value is popped off the stack. That value is then pushed on to
-	the stack twice to duplicate the top stack vaue.</td>
+	the stack twice to duplicate the top stack value.</td>
 </tr>
 <tr><td>DUP2</td>
     <td>DUP2</td>
     <td>w1 w2 -- w1 w2 w1 w2</td>
-    <td>The top two values on the stack are duplicated. That is, two vaues
+    <td>The top two values on the stack are duplicated. That is, two values
 	are popped off the stack. They are alternately pushed back on the
 	stack twice each.</td>
 </tr>
@@ -761,7 +726,7 @@ using the following construction:</p>
     <td>The top four stack items are swapped in pairs. That is, two values
 	are popped and retained. Then, two more values are popped and retained.
 	The values are pushed back on to the stack in the reverse order but
-	in pairs.</td>
+	in pairs.</p>
 </tr>
 <tr><td>OVER</td>
     <td>OVER</td>
@@ -849,13 +814,8 @@ using the following construction:</p>
     how much to rotate. That is, ROLL with n=1 is the same as ROT and 
     ROLL with n=2 is the same as ROT2.</td>
 </tr>
-<tr><td colspan="4"><b>MEMORY OPERATORS</b></td></tr>
-<tr>
-    <td>Word</td>
-    <td>Name</td>
-    <td>Operation</td>
-    <td>Description</td>
-</tr>
+<tr><td colspan="4">MEMORY OPERATIONS</td></tr>
+<tr><td>Word</td><td>Name</td><td>Operation</td><td>Description</td></tr>
 <tr><td>MALLOC</td>
     <td>MALLOC</td>
     <td>w1 -- p</td>
@@ -902,13 +862,8 @@ using the following construction:</p>
 	pushed back on the stack so this doesn't count as a "use ptr"
 	in the FREE idiom.</td>
 </tr>
-<tr><td colspan="4"><b>CONTROL FLOW OPERATORS</b></td></tr>
-<tr>
-    <td>Word</td>
-    <td>Name</td>
-    <td>Operation</td>
-    <td>Description</td>
-</tr>
+<tr><td colspan="4">CONTROL FLOW OPERATIONS</td></tr>
+<tr><td>Word</td><td>Name</td><td>Operation</td><td>Description</td></tr>
 <tr><td>RETURN</td>
     <td>RETURN</td>
     <td> --  </td>
@@ -969,13 +924,8 @@ using the following construction:</p>
 	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>
 </tr>
-<tr><td colspan="4"><b>INPUT &amp; OUTPUT OPERATORS</b></td></tr>
-<tr>
-    <td>Word</td>
-    <td>Name</td>
-    <td>Operation</td>
-    <td>Description</td>
-</tr>
+<tr><td colspan="4">INPUT &amp; OUTPUT OPERATIONS</td></tr>
+<tr><td>Word</td><td>Name</td><td>Operation</td><td>Description</td></tr>
 <tr><td>SPACE</td>
     <td>SPACE</td>
     <td> --  </td>
@@ -999,32 +949,30 @@ using the following construction:</p>
 <tr><td>&gt;d</td>
     <td>OUT_STR</td>
     <td> -- </td>
-    <td>A value is popped from the stack. It is put out as a decimal
-    integer.</td>
+    <td>A value is popped from the stack. It is put out as a decimal integer.</td>
 </tr>
 <tr><td>&gt;c</td>
     <td>OUT_CHR</td>
     <td> -- </td>
-    <td>A value is popped from the stack. It is put out as an ASCII
-    character.</td>
+    <td>A value is popped from the stack. It is put out as an ASCII character.</td>
 </tr>
 <tr><td>&lt;s</td>
     <td>IN_STR</td>
     <td> -- s </td>
-    <td>A string is read from the input via the scanf(3) format string " %as".
-    The resulting string is pushed on to the stack.</td>
+    <td>A string is read from the input via the scanf(3) format string " %as". The
+	resulting string is pushed on to the stack.</td>
 </tr>
 <tr><td>&lt;d</td>
     <td>IN_STR</td>
     <td> -- w </td>
-    <td>An integer is read from the input via the scanf(3) format string " %d".
-    The resulting value is pushed on to the stack</td>
+    <td>An integer is read from the input via the scanf(3) format string " %d". The
+	resulting value is pushed on to the stack</td>
 </tr>
 <tr><td>&lt;c</td>
     <td>IN_CHR</td>
     <td> -- w </td>
-    <td>A single character is read from the input via the scanf(3) format string
-    " %c". The value is converted to an integer and pushed on to the stack.</td>
+    <td>A single character is read from the input via the scanf(3) format string 
+	" %c". The value is converted to an integer and pushed on to the stack.</td>
 </tr>
 <tr><td>DUMP</td>
     <td>DUMP</td>
@@ -1034,14 +982,13 @@ using the following construction:</p>
 	to see instantly the net effect of the definition.</td>
 </tr>
 </table>
-
 </div>
 <!-- ======================================================================= -->
 <div class="doc_section"> <a name="example">Prime: A Complete Example</a></div>
 <div class="doc_text">
 <p>The following fully documented program highlights many features of both
 the Stacker language and what is possible with LLVM. The program has two modes
-of operation. If you provide numeric arguments to the program, it checks to see
+of operations. If you provide numeric arguments to the program, it checks to see
 if those arguments are prime numbers and prints out the results. Without any 
 arguments, the program prints out any prime numbers it finds between 1 and one 
 million (there's a lot of them!). The source code comments below tell the 
@@ -1061,7 +1008,7 @@ remainder of the story.
 ################################################################################
 # Utility definitions
 ################################################################################
-: print &gt;d CR ;
+: print >d CR ;
 : it_is_a_prime TRUE ;
 : it_is_not_a_prime FALSE ;
 : continue_loop TRUE ;
@@ -1071,10 +1018,10 @@ remainder of the story.
 # This definition tries an actual division of a candidate prime number. It
 # determines whether the division loop on this candidate should continue or
 # not.
-# STACK&lt;:
+# STACK<:
 #    div - the divisor to try
 #    p   - the prime number we are working on
-# STACK&gt;:
+# STACK>:
 #    cont - should we continue the loop ?
 #    div - the next divisor to try
 #    p   - the prime number we are working on
@@ -1100,7 +1047,7 @@ remainder of the story.
 #    cont - should we continue the loop (ignored)?
 #    div - the divisor to try
 #    p   - the prime number we are working on
-# STACK&gt;:
+# STACK>:
 #    cont - should we continue the loop ?
 #    div - the next divisor to try
 #    p   - the prime number we are working on
@@ -1125,9 +1072,9 @@ remainder of the story.
 # definition which returns a loop continuation value (which we also seed with
 # the value 1).  After the loop, we check the divisor. If it decremented all
 # the way to zero then we found a prime, otherwise we did not find one.
-# STACK&lt;:
+# STACK<:
 #   p - the prime number to check
-# STACK&gt;:
+# STACK>:
 #   yn - boolean indicating if its a prime or not
 #   p - the prime number checked
 ################################################################################
@@ -1148,18 +1095,18 @@ remainder of the story.
 
 ################################################################################
 # This definition determines if the number on the top of the stack is a prime 
-# or not. It does this by testing if the value is degenerate (&lt;= 3) and 
+# or not. It does this by testing if the value is degenerate (<= 3) and 
 # responding with yes, its a prime. Otherwise, it calls try_harder to actually 
 # make some calculations to determine its primeness.
-# STACK&lt;:
+# STACK<:
 #    p - the prime number to check
-# STACK&gt;:
+# STACK>:
 #    yn - boolean indicating if its a prime or not
 #    p  - the prime number checked
 ################################################################################
 : is_prime 
     DUP 			( save the prime number )
-    3 &gt;= IF			( see if its &lt;= 3 )
+    3 >= IF			( see if its <= 3 )
         it_is_a_prime  		( its <= 3 just indicate its prime )
     ELSE 
         try_harder 		( have to do a little more work )
@@ -1169,11 +1116,11 @@ remainder of the story.
 ################################################################################
 # This definition is called when it is time to exit the program, after we have 
 # found a sufficiently large number of primes.
-# STACK&lt;: ignored
-# STACK&gt;: exits
+# STACK<: ignored
+# STACK>: exits
 ################################################################################
 : done 
-    "Finished" &gt;s CR 		( say we are finished )
+    "Finished" >s CR 		( say we are finished )
     0 EXIT 			( exit nicely )
 ;
 
@@ -1184,14 +1131,14 @@ remainder of the story.
 # If it is a prime, it prints it. Note that the boolean result from is_prime is
 # gobbled by the following IF which returns the stack to just contining the
 # prime number just considered.
-# STACK&lt;: 
+# STACK<: 
 #    p - one less than the prime number to consider
-# STAC&gt;K
+# STACK>
 #    p+1 - the prime number considered
 ################################################################################
 : consider_prime 
     DUP 			( save the prime number to consider )
-    1000000 &lt; IF 		( check to see if we are done yet )
+    1000000 < IF 		( check to see if we are done yet )
         done 			( we are done, call "done" )
     ENDIF 
     ++ 				( increment to next prime number )
@@ -1205,11 +1152,11 @@ remainder of the story.
 # This definition starts at one, prints it out and continues into a loop calling
 # consider_prime on each iteration. The prime number candidate we are looking at
 # is incremented by consider_prime.
-# STACK&lt;: empty
-# STACK&gt;: empty
+# STACK<: empty
+# STACK>: empty
 ################################################################################
 : find_primes 
-    "Prime Numbers: " &gt;s CR	( say hello )
+    "Prime Numbers: " >s CR	( say hello )
     DROP			( get rid of that pesky string )
     1 				( stoke the fires )
     print			( print the first one, we know its prime )
@@ -1222,17 +1169,17 @@ remainder of the story.
 #
 ################################################################################
 : say_yes
-    &gt;d				( Print the prime number )
+    >d				( Print the prime number )
     " is prime."		( push string to output )
-    &gt;s				( output it )
+    >s				( output it )
     CR				( print carriage return )
     DROP			( pop string )
 ;
 
 : say_no
-    &gt;d				( Print the prime number )
+    >d				( Print the prime number )
     " is NOT prime."		( push string to put out )
-    &gt;s				( put out the string )
+    >s				( put out the string )
     CR				( print carriage return )
     DROP			( pop string )
 ;
@@ -1240,10 +1187,10 @@ remainder of the story.
 ################################################################################
 # This definition processes a single command line argument and determines if it
 # is a prime number or not.
-# STACK&lt;:
+# STACK<:
 #    n - number of arguments
 #    arg1 - the prime numbers to examine
-# STACK&gt;:
+# STACK>:
 #    n-1 - one less than number of arguments
 #    arg2 - we processed one argument
 ################################################################################
@@ -1260,7 +1207,7 @@ remainder of the story.
 
 ################################################################################
 # The MAIN program just prints a banner and processes its arguments.
-# STACK&lt;:
+# STACK<:
 #    n - number of arguments
 #    ... - the arguments
 ################################################################################
@@ -1272,13 +1219,13 @@ remainder of the story.
     
 ################################################################################
 # The MAIN program just prints a banner and processes its arguments.
-# STACK&lt;: arguments
+# STACK<: arguments
 ################################################################################
 : MAIN 
     NIP				( get rid of the program name )
     --				( reduce number of arguments )
     DUP				( save the arg counter )
-    1 &lt;= IF			( See if we got an argument )
+    1 <= IF			( See if we got an argument )
         process_arguments	( tell user if they are prime )
     ELSE
         find_primes		( see how many we can find )
@@ -1321,32 +1268,32 @@ directory contains everything, as follows:</p>
 <div class="doc_subsection"><a name="lexer"></a>The Lexer</div>
 <div class="doc_text">
 <p>See projects/Stacker/lib/compiler/Lexer.l</p>
-</div>
+</p></div>
 <!-- ======================================================================= -->
 <div class="doc_subsection"><a name="parser"></a>The Parser</div>
 <div class="doc_text">
 <p>See projects/Stacker/lib/compiler/StackerParser.y</p>
-</div>
+</p></div>
 <!-- ======================================================================= -->
 <div class="doc_subsection"><a name="compiler"></a>The Compiler</div>
 <div class="doc_text">
 <p>See projects/Stacker/lib/compiler/StackerCompiler.cpp</p>
-</div>
+</p></div>
 <!-- ======================================================================= -->
 <div class="doc_subsection"><a name="runtime"></a>The Runtime</div>
 <div class="doc_text">
 <p>See projects/Stacker/lib/runtime/stacker_rt.c</p>
-</div>
+</p></div>
 <!-- ======================================================================= -->
 <div class="doc_subsection"><a name="driver"></a>Compiler Driver</div>
 <div class="doc_text">
 <p>See projects/Stacker/tools/stkrc/stkrc.cpp</p>
-</div>
+</p></div>
 <!-- ======================================================================= -->
 <div class="doc_subsection"><a name="tests"></a>Test Programs</div>
 <div class="doc_text">
 <p>See projects/Stacker/test/*.st</p>
-</div>
+</p></div>
 <!-- ======================================================================= -->
 <div class="doc_subsection"> <a name="exercise">Exercise</a></div>
 <div class="doc_text">
@@ -1362,53 +1309,43 @@ operations. The work will almost be completely limited to the
 by the compiler. That means you don't have to futz around with figuring out how
 to get the keyword recognized. It already is.  The part of the compiler that
 you need to implement is the <code>ROLL</code> case in the 
-<code>StackerCompiler::handle_word(int)</code> method.</p> See the
-implementations of PICK and SELECT in the same method to get some hints about
-how to complete this exercise.<p>
+<code>StackerCompiler::handle_word(int)</code> method.</p> See the implementations 
+of PICk and SELECT in the same method to get some hints about how to complete
+this exercise.<p>
 <p>Good luck!</p>
 </div>
 <!-- ======================================================================= -->
-<div class="doc_subsection"><a name="todo">Things Remaining To Be Done</a></div>
+<div class="doc_subsection"> <a name="todo">Things Remaining To Be Done</a></div>
 <div class="doc_text">
 <p>The initial implementation of Stacker has several deficiencies. If you're
 interested, here are some things that could be implemented better:</p>
 <ol>
     <li>Write an LLVM pass to compute the correct stack depth needed by the
-    program. Currently the stack is set to a fixed number which means programs
-    with large numbers of definitions might fail.</li>
+    program.</li>
     <li>Write an LLVM pass to optimize the use of the global stack. The code
     emitted currently is somewhat wasteful. It gets cleaned up a lot by existing
     passes but more could be done.</li>
     <li>Add -O -O1 -O2 and -O3 optimization switches to the compiler driver to
     allow LLVM optimization without using "opt."</li>
-    <li>Make the compiler driver use the LLVM linking facilities (with IPO)
-    before depending on GCC to do the final link.</li>
+    <li>Make the compiler driver use the LLVM linking facilities (with IPO) before 
+    depending on GCC to do the final link.</li>
     <li>Clean up parsing. It doesn't handle errors very well.</li>
     <li>Rearrange the StackerCompiler.cpp code to make better use of inserting
     instructions before a block's terminating instruction. I didn't figure this
-    technique out until I was nearly done with LLVM. As it is, its a bad example
+    technique out until I was nearly done with LLVM. As it is, its a bad example 
     of how to insert instructions!</li>
     <li>Provide for I/O to arbitrary files instead of just stdin/stdout.</li>
-    <li>Write additional built-in words; with inspiration from FORTH</li>
+    <li>Write additional built-in words.</li>
     <li>Write additional sample Stacker programs.</li>
-    <li>Add your own compiler writing experiences and tips in the 
-    <a href="#lessons">Lessons I Learned About LLVM</a> section.</li>
+    <li>Add your own compiler writing experiences and tips in the <a href="#lessons">
+    Lessons I Learned About LLVM</a> section.</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:rspencer@x10sys.com">Reid Spencer</a><br>
-  <a href="http://llvm.cs.uiuc.edu">LLVM Compiler Infrastructure</a><br>
-  Last modified: $Date$
-</address>
-
+<div class="doc_footer">
+<address><a href="mailto:rspencer@x10sys.com">Reid Spencer</a></address>
+<a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a> 
+<br>Last modified: $Date$ </div>
 </body>
 </html>

llvm/docs/SystemLibrary.html

@@ -1,203 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
-                      "http://www.w3.org/TR/html4/strict.dtd">
-<html>
-<head>
-  <title>System Library</title>
-  <link rel="stylesheet" href="llvm.css" type="text/css">
-</head>
-<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>
-  <ol>
-    <li><a href="#headers">Hide System Header Files</a></li>
-    <li><a href="#nofunc">No Exposed Functions</a></li>
-    <li><a href="#nodata">No Exposed Data</a></li>
-    <li><a href="#xcptns">No Exceptions</a></li>
-    <li><a href="#errors">Standard Error Codes</a></li>
-    <li><a href="#overhead">Minimize Overhead</a></li>
-  </ol></li>
-  <li><a href="#design">System Library Design</a>
-  <ol>
-    <li><a href="#opaque">Use Opaque Classes</a></li>
-    <li><a href="#common">Common Implementations</a></li>
-    <li><a href="#multi_imps">Multiple Implementations</a></li>
-    <li><a href="#lowlevel">Use Low Level Interfaces</a></li>
-    <li><a href="#memalloc">No Memory Allocation</a></li>
-    <li><a href="#virtuals">No Virtual Methods</a></li>
-  </ol></li>
-  <li><a href="#detail">System Library Details</a>
-  <ol>
-    <li><a href="#bug">Tracking Bugzilla Bug: 351</a></li>
-    <li><a href="#refimpl">Reference Implementatation</a></li>
-  </ol></li>
-</ul>
-
-<div class="doc_author">
-  <p>Written by <a href="rspencer@x10sys.com">Reid Spencer</a></p>
-</div>
-
-
-<!-- *********************************************************************** -->
-<div class="doc_section"><a name="abstract">Abstract</a></div>
-<div class="doc_text">
-  <p>This document describes the requirements, design, and implementation 
-  details of LLVM's System Library. The library is composed of the header files
-  in <tt>llvm/include/llvm/System</tt> and the source files in 
-  <tt>llvm/lib/System</tt>. The goal of this library is to completely shield 
-  LLVM from the variations in operating system interfaces. By centralizing 
-  LLVM's use of operating system interfaces, we make it possible for the LLVM
-  tool chain and runtime libraries to be more easily ported to new platforms.
-  The library also unclutters the rest of LLVM from #ifdef use and special
-  cases for specific operating systems.</p>
-  <p>The System Library was donated to LLVM by Reid Spencer who formulated the
-  original design as part of the eXtensible Programming System (XPS) which is
-  based, in part, on LLVM.</p>
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
-  <a name="requirements">System Library Requirements</a>
-</div>
-<div class="doc_text">
-  <p>The System library's requirements are aimed at shielding LLVM from the
-  variations in operating system interfaces. The following sections define the
-  requirements needed to fulfill this objective.</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="headers">Hide System Header Files</a></div>
-<div class="doc_text">
-  <p>To be written.</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="nofunc">No Exposed Functions</a></div>
-<div class="doc_text">
-  <p>To be written.</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="nodata">No Exposed Data</a></div>
-<div class="doc_text">
-  <p>To be written.</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="xcptns">No Exceptions</a></div>
-<div class="doc_text">
-  <p>To be written.</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="errors">Standard Error Codes</a></div>
-<div class="doc_text">
-  <p>To be written.</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="overhead">Minimize Overhead</a></div>
-<div class="doc_text">
-  <p>To be written.</p>
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section"><a name="design">System Library Design</a></div>
-<div class="doc_text">
-  <p>In order to fulfill the requirements of the system library, strict design
-  objectives must be maintained in the library as it evolves.  The goal here 
-  is to provide interfaces to operating system concepts (files, memory maps, 
-  sockets, signals, locking, etc) efficiently and in such a way that the 
-  remainder of LLVM is completely operating system agnostic.</p>
-</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="low_level">Use Low Level Interfaces</a>
-</div>
-<div class="doc_text">
-  <p>To be written.</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="memalloc">No Memory Allocation</a></div>
-<div class="doc_text">
-  <p>To be written.</p>
-</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>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="bug">Bug 351</a></div>
-<div class="doc_text">
-  <p>See <a href="http://llvm.cs.uiuc.edu/PR351">bug 351</a>
-  for further details on the progress of this work</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="refimpl">Reference Implementation</a>
-</div>
-<div class="doc_text">
-  <p>The <tt>linux</tt> implementation of the system library will always be the
-  reference implementation. This means that (a) the concepts defined by the
-  linux must be identically replicated in the other implementations and (b) the
-  linux implementation must always be complete (provide implementations for all
-  concepts).</p>
-</div>
-
-<!-- *********************************************************************** -->
-
-<hr>
-<address>
-  <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
-  src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a>
-  <a href="http://validator.w3.org/check/referer"><img
-  src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"></a>
-
-  <a href="mailto:rspencer@x10sys.com">Reid Spencer</a><br>
-  <a href="http://llvm.cs.uiuc.edu">LLVM Compiler Infrastructure</a><br>
-  Last modified: $Date$
-</address>
-</body>
-</html>

llvm/docs/TableGenFundamentals.html

@@ -1,565 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
-                      "http://www.w3.org/TR/html4/strict.dtd">
-<html>
-<head>
-  <title>TableGen Fundamentals</title>
-  <link rel="stylesheet" href="llvm.css" type="text/css">
-</head>
-<body>
-
-<div class="doc_title">TableGen Fundamentals</div>
-
-<div class="doc_text">
-<ul>
-  <li><a href="#introduction">Introduction</a>
-  <ol>
-    <li><a href="#concepts">Basic concepts</a></li>
-    <li><a href="#example">An example record</a></li>
-    <li><a href="#running">Running TableGen</a></li>
-  </ol></li>
-  <li><a href="#syntax">TableGen syntax</a>
-  <ol>
-    <li><a href="#primitives">TableGen primitives</a>
-    <ol>
-      <li><a href="#comments">TableGen comments</a></li>
-      <li><a href="#types">The TableGen type system</a></li>
-      <li><a href="#values">TableGen values and expressions</a></li>
-    </ol></li>
-    <li><a href="#classesdefs">Classes and definitions</a>
-    <ol>
-      <li><a href="#valuedef">Value definitions</a></li>
-      <li><a href="#recordlet">'let' expressions</a></li>
-      <li><a href="#templateargs">Class template arguments</a></li>
-    </ol></li>
-    <li><a href="#filescope">File scope entities</a>
-    <ol>
-      <li><a href="#include">File inclusion</a></li>
-      <li><a href="#globallet">'let' expressions</a></li>
-    </ol></li>
-  </ol></li>
-  <li><a href="#backends">TableGen backends</a>
-  <ol>
-    <li><a href="#">todo</a></li>
-  </ol></li>
-</ul>
-</div>
-
-<div class="doc_author">
-  <p>Written by <a href="mailto:sabre@nondot.org">Chris Lattner</a></p>
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section"><a name="introduction">Introduction</a></div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>TableGen's purpose is to help a human develop and maintain records of
-domain-specific information.  Because there may be a large number of these
-records, it is specifically designed to allow writing flexible descriptions and
-for common features of these records to be factored out.  This reduces the
-amount of duplication in the description, reduces the chance of error, and
-makes it easier to structure domain specific information.</p>
-
-<p>The core part of TableGen <a href="#syntax">parses a file</a>, instantiates
-the declarations, and hands the result off to a domain-specific "<a
-href="#backends">TableGen backend</a>" for processing.  The current major user
-of TableGen is the <a href="CodeGenerator.html">LLVM code generator</a>.</p>
-
-<p>Note that if you work on TableGen much, and use emacs or vim, that you can
-find an emacs "TableGen mode" and a vim language file in
-<tt>llvm/utils/emacs</tt> and <tt>llvm/utils/vim</tt> directory of your LLVM
-distribution, respectively.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="running">Basic concepts</a></div>
-
-<div class="doc_text">
-
-<p>TableGen files consist of two key parts: 'classes' and 'definitions', both
-of which are considered 'records'.</p>
-
-<p><b>TableGen records</b> have a unique name, a list of values, and a list of
-superclasses.  The list of values is main data that TableGen builds for each
-record, it is this that holds the domain specific information for the
-application.  The interpretation of this data is left to a specific <a
-href="#backends">TableGen backend</a>, but the structure and format rules are
-taken care of and fixed by TableGen.</p>
-
-<p><b>TableGen definitions</b> are the concrete form of 'records'.  These
-generally do not have any undefined values, and are marked with the
-'<tt>def</tt>' keyword.</p>
-
-<p><b>TableGen classes</b> are abstract records that are used to build and
-describe other records.  These 'classes' allow the end-user to build
-abstractions for either the domain they are targetting (such as "Register",
-"RegisterClass", and "Instruction" in the LLVM code generator) or for the
-implementor to help factor out common properties of records (such as "FPInst",
-which is used to represent floating point instructions in the X86 backend).
-TableGen keeps track of all of the classes that are used to build up a
-definition, so the backend can find all definitions of a particular class, such
-as "Instruction".</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="example">An example record</a></div>
-
-<div class="doc_text">
-
-<p>With no other arguments, TableGen parses the specified file and prints out
-all of the classes, then all of the definitions.  This is a good way to see what
-the various definitions expand to fully.  Running this on the <tt>X86.td</tt>
-file prints this (at the time of this writing):</p>
-
-<pre>
-...
-<b>def</b> ADDrr8 {    <i>// Instruction X86Inst I2A8 Pattern</i>
-  <b>string</b> Name = "add";
-  <b>string</b> Namespace = "X86";
-  <b>list</b>&lt;Register&gt; Uses = [];
-  <b>list</b>&lt;Register&gt; Defs = [];
-  <b>bit</b> isReturn = 0;
-  <b>bit</b> isBranch = 0;
-  <b>bit</b> isCall = 0;
-  <b>bit</b> isTwoAddress = 1;
-  <b>bit</b> isTerminator = 0;
-  <b>dag</b> Pattern = (set R8, (plus R8, R8));
-  <b>bits</b>&lt;8&gt; Opcode = { 0, 0, 0, 0, 0, 0, 0, 0 };
-  Format Form = MRMDestReg;
-  <b>bits</b>&lt;5&gt; FormBits = { 0, 0, 0, 1, 1 };
-  ArgType Type = Arg8;
-  <b>bits</b>&lt;3&gt; TypeBits = { 0, 0, 1 };
-  <b>bit</b> hasOpSizePrefix = 0;
-  <b>bit</b> printImplicitUses = 0;
-  <b>bits</b>&lt;4&gt; Prefix = { 0, 0, 0, 0 };
-  FPFormat FPForm = ?;
-  <b>bits</b>&lt;3&gt; FPFormBits = { 0, 0, 0 };
-}
-...
-</pre>
-
-<p>This definition corresponds to an 8-bit register-register add instruction in
-the X86.  The string after the '<tt>def</tt>' string indicates the name of the
-record ("<tt>ADDrr8</tt>" in this case), and the comment at the end of the line
-indicates the superclasses of the definition.  The body of the record contains
-all of the data that TableGen assembled for the record, indicating that the
-instruction is part of the "X86" namespace, should be printed as "<tt>add</tt>"
-in the assembly file, it is a two-address instruction, has a particular
-encoding, etc.  The contents and semantics of the information in the record is
-specific to the needs of the X86 backend, and is only shown as an example.</p>
-
-<p>As you can see, a lot of information is needed for every instruction
-supported by the code generator, and specifying it all manually would be
-unmaintainble, prone to bugs, and tiring to do in the first place.  Because we
-are using TableGen, all of the information was derived from the following
-definition:</p>
-
-<pre>
-<b>def</b> ADDrr8   : I2A8&lt;"add", 0x00, MRMDestReg&gt;,
-               Pattern&lt;(set R8, (plus R8, R8))&gt;;
-</pre>
-
-<p>This definition makes use of the custom I2A8 (two address instruction with
-8-bit operand) class, which is defined in the X86-specific TableGen file to
-factor out the common features that instructions of its class share.  A key
-feature of TableGen is that it allows the end-user to define the abstractions
-they prefer to use when describing their information.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="running">Running TableGen</a></div>
-
-<div class="doc_text">
-
-<p>TableGen runs just like any other LLVM tool.  The first (optional) argument
-specifies the file to read.  If a filename is not specified, <tt>tblgen</tt>
-reads from standard input.</p>
-
-<p>To be useful, one of the <a href="#backends">TableGen backends</a> must be
-used.  These backends are selectable on the command line (type '<tt>tblgen
---help</tt>' for a list).  For example, to get a list of all of the definitions
-that subclass a particular type (which can be useful for building up an enum
-list of these records), use the <tt>--print-enums</tt> option:</p>
-
-<pre>
-$ tblgen X86.td -print-enums -class=Register
-AH, AL, AX, BH, BL, BP, BX, CH, CL, CX, DH, DI, DL, DX,
-EAX, EBP, EBX, ECX, EDI, EDX, ESI, ESP, FP0, FP1, FP2, FP3, FP4, FP5, FP6,
-SI, SP, ST0, ST1, ST2, ST3, ST4, ST5, ST6, ST7, 
-
-$ tblgen X86.td -print-enums -class=Instruction 
-ADCrr32, ADDri16, ADDri16b, ADDri32, ADDri32b, ADDri8, ADDrr16, ADDrr32,
-ADDrr8, ADJCALLSTACKDOWN, ADJCALLSTACKUP, ANDri16, ANDri16b, ANDri32, ANDri32b,
-ANDri8, ANDrr16, ANDrr32, ANDrr8, BSWAPr32, CALLm32, CALLpcrel32, ...
-</pre>
-
-<p>The default backend prints out all of the records, as described <a
-href="#example">above</a>.</p>
-
-<p>If you plan to use TableGen for some purpose, you will most likely have to
-<a href="#backends">write a backend</a> that extracts the information specific
-to what you need and formats it in the appropriate way.</p>
-
-</div>
-
-
-<!-- *********************************************************************** -->
-<div class="doc_section"><a name="syntax">TableGen syntax</a></div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-<p>TableGen doesn't care about the meaning of data (that is up to the backend
-to define), but it does care about syntax, and it enforces a simple type system.
-This section describes the syntax and the constructs allowed in a TableGen file.
-</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="primitives">TableGen primitives</a></div>
-
-<!-- -------------------------------------------------------------------------->
-<div class="doc_subsubsection"><a name="comments">TableGen comments</a></div>
-
-<div class="doc_text">
-<p>TableGen supports BCPL style "<tt>//</tt>" comments, which run to the end of
-the line, and it also supports <b>nestable</b> "<tt>/* */</tt>" comments.</p>
-</div>
-
-<!-- -------------------------------------------------------------------------->
-<div class="doc_subsubsection">
-  <a name="types">The TableGen type system</a>
-</div>
-
-<div class="doc_text">
-<p>TableGen files are strongly typed, in a simple (but complete) type-system.
-These types are used to perform automatic conversions, check for errors, and to
-help interface designers constrain the input that they allow.  Every <a
-href="#valuedef">value definition</a> is required to have an associated type.
-</p>
-
-<p>TableGen supports a mixture of very low-level types (such as <tt>bit</tt>)
-and very high-level types (such as <tt>dag</tt>).  This flexibility is what
-allows it to describe a wide range of information conveniently and compactly.
-The TableGen types are:</p>
-
-<ul>
-<li>"<tt><b>bit</b></tt>" - A 'bit' is a boolean value that can hold either 0 or
-1.</li>
-
-<li>"<tt><b>int</b></tt>" - The 'int' type represents a simple 32-bit integer
-value, such as 5.</li>
-
-<li>"<tt><b>string</b></tt>" - The 'string' type represents an ordered sequence
-of characters of arbitrary length.</li>
-
-<li>"<tt><b>bits</b>&lt;n&gt;</tt>" - A 'bits' type is an arbitrary, but fixed,
-size integer that is broken up into individual bits.  This type is useful
-because it can handle some bits being defined while others are undefined.</li>
-
-<li>"<tt><b>list</b>&lt;ty&gt;</tt>" - This type represents a list whose
-elements are some other type.  The contained type is arbitrary: it can even be
-another list type.</li>
-
-<li>Class type - Specifying a class name in a type context means that the
-defined value must be a subclass of the specified class.  This is useful in
-conjunction with the "list" type, for example, to constrain the elements of the
-list to a common base class (e.g., a <tt><b>list</b>&lt;Register&gt;</tt> can
-only contain definitions derived from the "<tt>Register</tt>" class).</li>
-
-<li>"<tt><b>code</b></tt>" - This represents a big hunk of text.  NOTE: I don't
-remember why this is distinct from string!</li>
-
-<li>"<tt><b>dag</b></tt>" - This type represents a nestable directed graph of
-elements.</li>
-</ul>
-
-<p>To date, these types have been sufficient for describing things that
-TableGen has been used for, but it is straight-forward to extend this list if
-needed.</p>
-
-</div>
-
-<!-- -------------------------------------------------------------------------->
-<div class="doc_subsubsection">
-  <a name="values">TableGen values and expressions</a>
-</div>
-
-<div class="doc_text">
-
-<p>TableGen allows for a pretty reasonable number of different expression forms
-when building up values.  These forms allow the TableGen file to be written in a
-natural syntax and flavor for the application.  The current expression forms
-supported include:</p>
-
-<ul>
-<li><tt>?</tt> - uninitialized field</li>
-<li><tt>0b1001011</tt> - binary integer value</li>
-<li><tt>07654321</tt> - octal integer value (indicated by a leading 0)</li>
-<li><tt>7</tt> - decimal integer value</li>
-<li><tt>0x7F</tt> - hexadecimal integer value</li>
-<li><tt>"foo"</tt> - string value</li>
-<li><tt>[{ ... }]</tt> - code fragment</li>
-<li><tt>[ X, Y, Z ]</tt> - list value.</li>
-<li><tt>{ a, b, c }</tt> - initializer for a "bits&lt;3&gt;" value</li>
-<li><tt>value</tt> - value reference</li>
-<li><tt>value{17}</tt> - access to one bit of a value</li>
-<li><tt>value{15-17}</tt> - access to multiple bits of a value</li>
-<li><tt>DEF</tt> - reference to a record definition</li>
-<li><tt>X.Y</tt> - reference to the subfield of a value</li>
-<li><tt>list[4-7,17,2-3]</tt> - A slice of the 'list' list, including elements 
-4,5,6,7,17,2, and 3 from it.  Elements may be included multiple times.</li>
-<li><tt>(DEF a, b)</tt> - a dag value.  The first element is required to be a
-record definition, the remaining elements in the list may be arbitrary other
-values, including nested `<tt>dag</tt>' values.</li>
-</ul>
-
-<p>Note that all of the values have rules specifying how they convert to values
-for different types.  These rules allow you to assign a value like "7" to a
-"bits&lt;4&gt;" value, for example.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="classesdefs">Classes and definitions</a>
-</div>
-
-<div class="doc_text">
-
-<p>As mentioned in the <a href="#concepts">intro</a>, classes and definitions
-(collectively known as 'records') in TableGen are the main high-level unit of
-information that TableGen collects.  Records are defined with a <tt>def</tt> or
-<tt>class</tt> keyword, the record name, and an optional list of "<a
-href="#templateargs">template arguments</a>".  If the record has superclasses,
-they are specified as a comma seperated list that starts with a colon character
-(":").  If <a href="#valuedef">value definitions</a> or <a href="#recordlet">let
-expressions</a> are needed for the class, they are enclosed in curly braces
-("{}"); otherwise, the record ends with a semicolon.  Here is a simple TableGen
-file:</p>
-
-<pre>
-<b>class</b> C { <b>bit</b> V = 1; }
-<b>def</b> X : C;
-<b>def</b> Y : C {
-  <b>string</b> Greeting = "hello";
-}
-</pre>
-
-<p>This example defines two definitions, <tt>X</tt> and <tt>Y</tt>, both of
-which derive from the <tt>C</tt> class.  Because of this, they both get the
-<tt>V</tt> bit value.  The <tt>Y</tt> definition also gets the Greeting member
-as well.</p>
-
-<p>In general, classes are useful for collecting together the commonality
-between a group of records and isolating it in a single place.  Also, classes
-permit the specification of default values for their subclasses, allowing the
-subclasses to override them as they wish.</p>
-
-</div>
-
-<!---------------------------------------------------------------------------->
-<div class="doc_subsubsection">
-  <a name="valuedef">Value definitions</a>
-</div>
-
-<div class="doc_text">
-<p>Value definitions define named entries in records.  A value must be defined
-before it can be referred to as the operand for another value definition or
-before the value is reset with a <a href="#recordlet">let expression</a>.  A
-value is defined by specifying a <a href="#types">TableGen type</a> and a name.
-If an initial value is available, it may be specified after the type with an
-equal sign.  Value definitions require terminating semicolons.</p>
-</div>
-
-<!-- -------------------------------------------------------------------------->
-<div class="doc_subsubsection">
-  <a name="recordlet">'let' expressions</a>
-</div>
-
-<div class="doc_text">
-<p>A record-level let expression is used to change the value of a value
-definition in a record.  This is primarily useful when a superclass defines a
-value that a derived class or definition wants to override.  Let expressions
-consist of the '<tt>let</tt>' keyword followed by a value name, an equal sign
-("="), and a new value.  For example, a new class could be added to the example
-above, redefining the <tt>V</tt> field for all of its subclasses:</p>
-
-<pre>
-<b>class</b> D : C { let V = 0; }
-<b>def</b> Z : D;
-</pre>
-
-<p>In this case, the <tt>Z</tt> definition will have a zero value for its "V"
-value, despite the fact that it derives (indirectly) from the <tt>C</tt> class,
-because the <tt>D</tt> class overrode its value.</p>
-
-</div>
-
-<!-- -------------------------------------------------------------------------->
-<div class="doc_subsubsection">
-  <a name="templateargs">Class template arguments</a>
-</div>
-
-<div class="doc_text">
-<p>TableGen permits the definition of parameterized classes as well as normal
-concrete classes.  Parameterized TableGen classes specify a list of variable
-bindings (which may optionally have defaults) that are bound when used.  Here is
-a simple example:</p>
-
-<pre>
-<b>class</b> FPFormat&lt;<b>bits</b>&lt;3&gt; val&gt; {
-  <b>bits</b>&lt;3&gt; Value = val;
-}
-<b>def</b> NotFP      : FPFormat&lt;0&gt;;
-<b>def</b> ZeroArgFP  : FPFormat&lt;1&gt;;
-<b>def</b> OneArgFP   : FPFormat&lt;2&gt;;
-<b>def</b> OneArgFPRW : FPFormat&lt;3&gt;;
-<b>def</b> TwoArgFP   : FPFormat&lt;4&gt;;
-<b>def</b> SpecialFP  : FPFormat&lt;5&gt;;
-</pre>
-
-<p>In this case, template arguments are used as a space efficient way to specify
-a list of "enumeration values", each with a "Value" field set to the specified
-integer.</p>
-
-<p>The more esoteric forms of <a href="#values">TableGen expressions</a> are
-useful in conjunction with template arguments.  As an example:</p>
-
-<pre>
-<b>class</b> ModRefVal&lt;<b>bits</b>&lt;2&gt; val&gt; {
-  <b>bits</b>&lt;2&gt; Value = val;
-}
-
-<b>def</b> None   : ModRefVal&lt;0&gt;;
-<b>def</b> Mod    : ModRefVal&lt;1&gt;;
-<b>def</b> Ref    : ModRefVal&lt;2&gt;;
-<b>def</b> ModRef : ModRefVal&lt;3&gt;;
-
-<b>class</b> Value&lt;ModRefVal MR&gt; {
-  <i>// decode some information into a more convenient format, while providing
-  // a nice interface to the user of the "Value" class.</i>
-  <b>bit</b> isMod = MR.Value{0};
-  <b>bit</b> isRef = MR.Value{1};
-
-  <i>// other stuff...</i>
-}
-
-<i>// Example uses</i>
-<b>def</b> bork : Value&lt;Mod&gt;;
-<b>def</b> zork : Value&lt;Ref&gt;;
-<b>def</b> hork : Value&lt;ModRef&gt;;
-</pre>
-
-<p>This is obviously a contrived example, but it shows how template arguments
-can be used to decouple the interface provided to the user of the class from the
-actual internal data representation expected by the class.  In this case,
-running <tt>tblgen</tt> on the example prints the following definitions:</p>
-
-<pre>
-<b>def</b> bork {      <i>// Value</i>
-  bit isMod = 1;
-  bit isRef = 0;
-}
-<b>def</b> hork {      <i>// Value</i>
-  bit isMod = 1;
-  bit isRef = 1;
-}
-<b>def</b> zork {      <i>// Value</i>
-  bit isMod = 0;
-  bit isRef = 1;
-}
-</pre>
-
-<p> This shows that TableGen was able to dig into the argument and extract a
-piece of information that was requested by the designer of the "Value" class.
-For more realistic examples, please see existing users of TableGen, such as the
-X86 backend.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="filescope">File scope entities</a>
-</div>
-
-<!-- -------------------------------------------------------------------------->
-<div class="doc_subsubsection">
-  <a name="include">File inclusion</a>
-</div>
-
-<div class="doc_text">
-<p>TableGen supports the '<tt>include</tt>' token, which textually substitutes
-the specified file in place of the include directive.  The filename should be
-specified as a double quoted string immediately after the '<tt>include</tt>'
-keyword.  Example:</p>
-
-<pre>
-<b>include</b> "foo.td"
-</pre>
-
-</div>
-
-<!-- -------------------------------------------------------------------------->
-<div class="doc_subsubsection">
-  <a name="globallet">'let' expressions</a>
-</div>
-
-<div class="doc_text">
-<p> "let" expressions at file scope are similar to <a href="#recordlet">"let"
-expressions within a record</a>, except they can specify a value binding for
-multiple records at a time, and may be useful in certain other cases.
-File-scope let expressions are really just another way that TableGen allows the
-end-user to factor out commonality from the records.</p>
-
-<p>File-scope "let" expressions take a comma-seperated list of bindings to
-apply, and one of more records to bind the values in.  Here are some
-examples:</p>
-
-<pre>
-<b>let</b> isTerminator = 1, isReturn = 1 <b>in</b>
-  <b>def</b> RET : X86Inst&lt;"ret", 0xC3, RawFrm, NoArg&gt;;
-
-<b>let</b> isCall = 1 <b>in</b>
-  <i>// All calls clobber the non-callee saved registers...</i>
-  <b>let</b> Defs = [EAX, ECX, EDX, FP0, FP1, FP2, FP3, FP4, FP5, FP6] in {
-    <b>def</b> CALLpcrel32 : X86Inst&lt;"call", 0xE8, RawFrm, NoArg&gt;;
-    <b>def</b> CALLr32     : X86Inst&lt;"call", 0xFF, MRMS2r, Arg32&gt;;
-    <b>def</b> CALLm32     : X86Inst&lt;"call", 0xFF, MRMS2m, Arg32&gt;;
-  }
-</pre>
-
-<p>File-scope "let" expressions are often useful when a couple of definitions
-need to be added to several records, and the records do not otherwise need to be
-opened, as in the case with the CALL* instructions above.</p>
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section"><a name="backends">TableGen backends</a></div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-<p>How they work, how to write one.  This section should not contain details
-about any particular backend, except maybe -print-enums as an example.  This
-should highlight the APIs in <tt>TableGen/Record.h</tt>.</p>
-</div>
-
-<!-- *********************************************************************** -->
-
-<hr>
-<address>
-  <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
-  src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a>
-  <a href="http://validator.w3.org/check/referer"><img
-  src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /></a>
-
-  <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/TestingGuide.html

@@ -1,10 +1,11 @@
-<!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 Transitional//EN">
 <html>
 <head>
-  <title>LLVM Test Suite Guide</title>
-  <link rel="stylesheet" href="llvm.css" type="text/css">
+    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
+    <link rel="stylesheet" href="llvm.css" type="text/css" media="screen" />
+    <title>LLVM Test Suite Guide</title>
 </head>
+
 <body>
       
 <div class="doc_title">
@@ -15,406 +16,414 @@
 <li><a href="#overview">Overview</a></li>
 <li><a href="#Requirements">Requirements</a></li>
 <li><a href="#quick">Quick Start</a></li>
-<li><a href="#org">LLVM Test Suite Organization</a>
+<li><a href="#org">LLVM Test Suite Organization</a></li>
 <ul>
   <li><a href="#codefragments">Code Fragments</a></li>
   <li><a href="#wholeprograms">Whole Programs</a></li>
-</ul></li>
+</ul>
 <li><a href="#tree">LLVM Test Suite Tree</a></li>
 <li><a href="#qmstructure">QMTest Structure</a></li>
 <li><a href="#progstructure">Programs Structure</a></li>
 <li><a href="#run">Running the LLVM Tests</a></li>
-<li><a href="#nightly">Running the nightly tester</a></li>
+<p><b>Written by John T. Criswell</b></p>
 </ol>
 
-<div class="doc_author">
-  <p>Written by John T. Criswell</p>
-</div>
+	<!--===============================================================-->
+	<div class="doc_section"><a name="overview">Overview</a></div>
+	<!--===============================================================-->
 
-<!--===============================================================-->
-<div class="doc_section"><a name="overview">Overview</a></div>
-<!--===============================================================-->
+        <div class="doc_text">
+	<p>
+        This document is the reference manual for the LLVM test suite.  It
+	documents the structure of the LLVM test suite, the tools needed to
+	use it, and how to add and run tests.
+        </p>
+        </div>
 
-<div class="doc_text">
+	<!--===============================================================-->
+	<div class="doc_section"><a name="Requirements">Requirements</a></div>
+	<!--===============================================================-->
 
-<p>This document is the reference manual for the LLVM test suite.  It documents
-the structure of the LLVM test suite, the tools needed to use it, and how to add
-and run tests.</p>
+        <div class="doc_text">
+        <p>
+	In order to use the LLVM test suite, you will need all of the software
+	required to build LLVM, plus the following:
+        </p>
+	<dl compact>
+		<dt><A HREF="http://www.qmtest.com">QMTest</A></dt>
+		<dd>The LLVM test suite uses QMTest to organize and
+                run tests.</dd>
 
-</div>
+		<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>
+	</dl>
+        </div>
 
-<!--===============================================================-->
-<div class="doc_section"><a name="Requirements">Requirements</a></div>
-<!--===============================================================-->
+	<!--===============================================================-->
+	<div class="doc_section"><a name="quick">Quick Start</a></div>
+	<!--===============================================================-->
 
-<div class="doc_text">
+        <div class="doc_text">
+        <p>
+        The tests are located in the LLVM source tree under the directory
+        <tt>llvm/test</tt>. To run all of the tests in LLVM, use the Master
+        Makefile in that directory:
+	</p>
+	<pre>
+	 % gmake -C llvm/test
+	</pre>
 
-<p>In order to use the LLVM test suite, you will need all of the software
-required to build LLVM, plus the following:</p>
+	<p>
+	To run only the code fragment tests (i.e. those that do basic testing of
+	LLVM), run the tests organized by QMTest:
+	</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>
+	<pre>
+	 % gmake -C llvm/test qmtest
+	</pre>
 
-  <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>
-</dl>
+	<p>
+	To run only the tests that compile and execute whole programs, run the
+	Programs tests:
+	</p>
 
-</div>
+	<pre>
+	 % gmake -C llvm/test/Programs
+	</pre>
+        </div>
 
-<!--===============================================================-->
-<div class="doc_section"><a name="quick">Quick Start</a></div>
-<!--===============================================================-->
+	<!--===============================================================-->
+	<div class="doc_section"><h2><a name="org">LLVM Test Suite
+        Organization </a></h2></div>
+	<!--===============================================================-->
 
-<div class="doc_text">
+        <div class="doc_text">
+	<p>The LLVM test suite contains two major categories of tests: code
+        fragments and whole programs.</p>
+        </div>
 
-<p> The tests are located in the LLVM source tree under the directory
-<tt>llvm/test</tt>. To run all of the tests in LLVM, use the Master Makefile in
-that directory:</p>
+        <div class="doc_subsection"><a name="codefragments">Code Fragments</a> 
+        </div>
 
-<pre>
- % gmake -C llvm/test
-</pre>
+        <div class="doc_text">
+                <p>
+		Code fragments are small pieces of code that test a specific
+		feature of LLVM or trigger a specific bug in LLVM.  They are
+		usually written in LLVM assembly language, but can be
+		written in other languages if the test targets a
+                particular language front end.
+		</p><p>
+		Code fragments are not complete programs, and they are
+                never executed to determine correct behavior.
+		</p><p>
+		The tests in the Features and
+                Regression directories contain code fragments.
+                </p>
+        </div>
 
-<p>To run only the code fragment tests (i.e. those that do basic testing of
-LLVM), run the tests organized by QMTest:</p>
+        <div class="doc_subsection"><a name="wholeprograms">Whole Programs</a> 
+        </div>
 
-<pre>
- % gmake -C llvm/test qmtest
-</pre>
+        <div class="doc_text">
+		<p>
+                Whole Programs are pieces of code which can be compiled and
+                linked into a stand-alone program that can be executed.  These
+                programs are generally written in high level languages such as C
+                or C++, but sometimes they are written straight in LLVM
+                assembly.
+		</p><p>
+		These programs are compiled and then executed using several
+		different methods (native compiler, LLVM C backend, LLVM JIT,
+		LLVM native code generation, etc).  The output of these programs
+		is compared to ensure that LLVM is compiling the program
+		correctly.
+		</p><p>
+		In addition to compiling and executing programs, whole program
+		tests serve as a way of benchmarking LLVM performance, both in
+		terms of the efficiency of the programs generated as well as the
+		speed with which LLVM compiles, optimizes, and generates code.
+		</p><p>
+		The Programs directory contains all tests which compile and
+		benchmark whole programs.
+                </p>
+        </div>
 
-<p>To run only the tests that compile and execute whole programs, run the
-Programs tests:</p>
+	<!--===============================================================-->
+	<div class="doc_section"><h2><a name="tree">LLVM Test Suite Tree</a>
+        </div>
+	<!--===============================================================-->
 
-<pre>
- % gmake -C llvm/test/Programs
-</pre>
-
-</div>
-
-<!--===============================================================-->
-<div class="doc_section"><a name="org">LLVM Test Suite Organization</a></div>
-<!--===============================================================-->
-
-<div class="doc_text">
-
-<p>The LLVM test suite contains two major categories of tests: code
-fragments and whole programs.</p>
-
-</div>
-
-<div class="doc_subsection"><a name="codefragments">Code Fragments</a> 
-</div>
-
-<div class="doc_text">
-
-<p>Code fragments are small pieces of code that test a specific feature of LLVM
-or trigger a specific bug in LLVM.  They are usually written in LLVM assembly
-language, but can be written in other languages if the test targets a particular
-language front end.</p>
-
-<p>Code fragments are not complete programs, and they are never executed to
-determine correct behavior.</p> 
-
-<p>The tests in the Features and Regression directories contain code
-fragments.</p>
-
-</div>
-
-<div class="doc_subsection"><a name="wholeprograms">Whole Programs</a></div>
-
-<div class="doc_text">
-
-<p>Whole Programs are pieces of code which can be compiled and linked into a
-stand-alone program that can be executed.  These programs are generally written
-in high level languages such as C or C++, but sometimes they are written
-straight in LLVM assembly.</p>
-  
-<p>These programs are compiled and then executed using several different
-methods (native compiler, LLVM C backend, LLVM JIT, LLVM native code generation,
-etc).  The output of these programs is compared to ensure that LLVM is compiling
-the program correctly.</p>
-
-<p>In addition to compiling and executing programs, whole program tests serve as
-a way of benchmarking LLVM performance, both in terms of the efficiency of the
-programs generated as well as the speed with which LLVM compiles, optimizes, and
-generates code.</p>
-
-<p>The Programs directory contains all tests which compile and benchmark whole
-programs.</p> 
-
-</div>
-
-<!--===============================================================-->
-<div class="doc_section"><a name="tree">LLVM Test Suite Tree</a></div>
-<!--===============================================================-->
-
-<div class="doc_text">
-
-<p>Each type of test in the LLVM test suite has its own directory. The major
-subtrees of the test suite directory tree are as follows:</p>
-      
-<ul>
-  <li>Features 
-    <p>This directory contains sample codes that test various features of the
-    LLVM language.  These pieces of sample code are run through various
-    assembler, disassembler, and optimizer passes.</p>
-
-  <li>Regression
-    <p>This directory contains regression tests for LLVM.  When a bug is found
-    in LLVM, a regression test containing just enough code to reproduce the
-    problem should be written and placed somewhere underneath this directory.
-    In most cases, this will be a small piece of LLVM assembly language code,
-    often distilled from an actual application or benchmark.</p>
-
-  <li>Programs
-    <p>The Programs directory contains programs that can be compiled with LLVM
-    and executed.  These programs are compiled using the native compiler and
-    various LLVM backends.  The output from the program compiled with the native
-    compiler is assumed correct; the results from the other programs are
-    compared to the native program output and pass if they match.  </p>
-  
-    <p> In addition for testing correctness, the Programs directory also
-    performs timing tests of various LLVM optimizations.  It also records
-    compilation times for the compilers and the JIT.  This information can be
-    used to compare the effectiveness of LLVM's optimizations and code
-    generation.</p>
-    
-    <p>The Programs directory is subdivided into several smaller subdirectories:
-    </p>
-
-    <ul>
-      <li>Programs/SingleSource
-        <p>The SingleSource directory contains test programs that are only a
-        single source file in size.  These are usually small benchmark programs
-        or small programs that calculate a particular value.  Several such
-        programs are grouped together in each directory.</p></li>
-
-      <li>Programs/MultiSource
-        <p>The MultiSource directory contains subdirectories which contain
-        entire programs with multiple source files.  Large benchmarks and whole
-        applications go here.</p></li>
-
-      <li>Programs/External
-        <p>The External directory contains Makefiles for building code that is
-        external to (i.e. not distributed with) LLVM.  The most prominent member
-        of this directory is the SPEC 2000 benchmark suite.  The presence and
-        location of these external programs is configured by the LLVM
-        <tt>configure</tt> script.</p></li>
+        <div class="doc_text">
+	<p>Each type of test in the LLVM test suite has its own directory. The
+        major subtrees of the test suite directory tree are as follows:</p>
         
-    </ul></li>
+	<ul>
+		<li>Features
+		<p>
+                This directory contains sample codes that test various features
+		of the LLVM language.  These pieces of sample code are run
+		through various assembler, disassembler, and optimizer passes.
+		</p>
 
-  <li>QMTest
-    <p>This directory contains the QMTest information files.  Inside this
-    directory are QMTest administration files and the Python code that
-    implements the LLVM test and database classes.</p>
+		<li>Regression
+                <p>
+		This directory contains regression tests for LLVM.  When a bug
+		is found in LLVM, a regression test containing just enough
+		code to reproduce the problem should be written and placed
+		somewhere underneath this directory.  In most cases, this
+		will be a small piece of LLVM assembly language code, often
+		distilled from an actual application or benchmark.
+		</p>
 
-</ul>
+		<li>Programs
+		<p>
+                The Programs directory contains programs that can be compiled
+		with LLVM and executed.  These programs are compiled using the
+		native compiler and various LLVM backends.  The output from the
+		program compiled with the native compiler is assumed correct;
+		the results from the other programs are compared to the native
+		program output and pass if they match.
+		</p><p>
+		In addition for testing correctness, the Programs directory
+		also performs timing tests of various LLVM optimizations.
+		It also records compilation times for the compilers and the
+		JIT.  This information can be used to compare the
+		effectiveness of LLVM's optimizations and code generation.
+		</p><p>
+		The Programs directory is subdivided into several smaller
+		subdirectories:
+                </p>
 
-</div>
+		<ul>
+			<li>Programs/SingleSource
+                        <p>
+			The SingleSource directory contains test programs that
+			are only a single source file in size.  These are
+			usually small benchmark programs or small programs that
+			calculate a particular value.  Several such programs are
+			grouped together in each directory.
+			</p>
 
-<!--===============================================================-->
-<div class="doc_section"><a name="qmstructure">QMTest Structure</a></div>
-<!--===============================================================-->
+			<li>Programs/MultiSource
+                        <p>
+                        The MultiSource directory contains subdirectories which
+                        contain entire programs with multiple source files.
+                        Large benchmarks and whole applications go here.
+			</p>
 
-<div class="doc_text">
+			<li>Programs/External
+                        <p>
+			The External directory contains Makefiles for building
+			code that is external to (i.e. not distributed with)
+			LLVM.  The most prominent member of this directory is
+			the SPEC 2000 benchmark suite.  The presence and
+			location of these external programs is configured by the
+			LLVM <tt>configure</tt> script.
+                        </p>
+		</ul>
 
-<p>The LLVM test suite is partially driven by QMTest and partially
-driven by GNU Make.  Specifically, the Features and Regression tests
-are all driven by QMTest.  The Programs directory is currently
-driven by a set of Makefiles.</p>
+		<p>
 
-<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>
+		<li>QMTest
+                <p>
+		This directory contains the QMTest information files.  Inside
+		this directory are QMTest administration files and the Python
+		code that implements the LLVM test and database classes.
+                </p>
+	</ul>
+        </div>
 
-<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>
+	<!--===============================================================-->
+	<div class="doc_section"><h2><a name="qmstructure">QMTest Structure</a>
+        </div>
+	<!--===============================================================-->
 
-<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>
+        <div class="doc_text">
+	<p>
+        The LLVM test suite is partially driven by QMTest and partially
+	driven by GNU Make.  Specifically, the Features and Regression tests
+	are all driven by QMTest.  The Programs directory is currently
+	driven by a set of Makefiles.
+	</p><p>
+	The QMTest system needs to have several pieces of information
+	available; these pieces of configuration information are known
+	collectively as the "context" in QMTest parlance.  Since the context
+	for LLVM is relatively large, the master Makefile in llvm/test
+	sets it for you.
+	</p><p>
+	The LLVM database class makes the subdirectories of llvm/test a
+	QMTest test database.  For each directory that contains tests driven by
+	QMTest, it knows what type of test the source file is and how to run it.
+	</p><p>
+	Hence, the QMTest namespace is essentially what you see in the
+	Feature and Regression directories, but there is some magic that
+	the database class performs (as described below).
+	</p><p>
+	The QMTest namespace is currently composed of the following tests and
+	test suites:
+        </p>
 
-<p>The QMTest namespace is currently composed of the following tests and test
-suites:</p>
+	<ul>
+		<li>Feature
+                <p>
+		These are the feature tests found in the Feature directory.
+		They are broken up into the following categories:
+                </p>
+		<ul>
+			<li>ad
+			<p>
+			Assembler/Disassembler tests.  These tests verify that a
+			piece of LLVM assembly language can be assembled into
+			bytecode and then disassembled into the original
+			assembly language code.  It does this several times to
+			ensure that assembled output can be disassembled and
+			disassembler output can be assembled.  It also verifies
+			that the give assembly language file can be assembled
+			correctly.
+                        </p>
 
-<ul>
-  <li>Feature
-              <p>
-  These are the feature tests found in the Feature directory.
-  They are broken up into the following categories:
-              </p>
-  <ul>
-    <li>ad
-      <p>Assembler/Disassembler tests.  These tests verify that a piece of LLVM
-      assembly language can be assembled into bytecode and then disassembled
-      into the original assembly language code.  It does this several times to
-      ensure that assembled output can be disassembled and disassembler output
-      can be assembled.  It also verifies that the give assembly language file
-      can be assembled correctly.</p></li>
+			<li>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>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>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>
+		</ul>
 
-    <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>
 
-  <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>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>
+	</ul>
+        </div>
 
-  <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>
+	<!--===============================================================-->
+	<div class="doc_section"><h2><a name="progstructure">Programs
+        Structure</a></div>
+	<!--===============================================================-->
 
-</ul>
-      
-</div>
+        <div class="doc_text">
+        <p>
+	As mentioned previously, the Programs tree in llvm/test provides three
+	types of tests: MultiSource, SingleSource, and External.  Each tree is
+	then subdivided into several categories, including applications,
+	benchmarks, regression tests, code that is strange grammatically, etc.
+	These organizations should be relatively self explanatory.
+	</p><p>
+	In addition to the regular Programs tests, the Programs tree also
+	provides a mechanism for compiling the programs in different ways.  If
+	the variable TEST is defined on the gmake command line, the test system
+	will include a Makefile named <tt>TEST.&lt;value of TEST
+	variable&gt;.Makefile</tt>.  This Makefile can modify build rules to
+        yield different results.
+	</p><p>
+	For example, the LLVM nightly tester uses <tt>TEST.nightly.Makefile</tt>
+        to create the nightly test reports.  To run the nightly tests, run
+	<tt>gmake TEST=nightly</tt>.
+	</p><p>
+	There are several TEST Makefiles available in the tree.  Some of them
+	are designed for internal LLVM research and will not work outside of the
+	LLVM research group.  They may still be valuable, however, as a guide to
+	writing your own TEST Makefile for any optimization or analysis passes
+	that you develop with LLVM.
+        </p>
+        </div>
 
-<!--===============================================================-->
-<div class="doc_section"><a name="progstructure">Programs Structure</a></div>
-<!--===============================================================-->
+	<!--===============================================================-->
+	<div class="doc_section"><h2><a name="run">Running the LLVM Tests</a>
+        </div>
+	<!--===============================================================-->
 
-<div class="doc_text">
+        <div class="doc_text">
+        <p>
+	First, all tests are executed within the LLVM object directory tree.
+	They <i>are not</i> executed inside of the LLVM source tree.  This is
+	because the test suite creates temporary files during execution.
+	</p><p>
+	The master Makefile in llvm/test is capable of running both the
+	QMTest driven tests and the Programs tests.  By default, it will run
+	all of the tests.
+	</p><p>
+	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>
+	For example, to run the Regression.LLC tests, type
+	<tt>gmake Regression.LLC.t</tt> in llvm/tests.
+	</p><p>
+	Note that the Makefiles in llvm/test/Features and llvm/test/Regression
+	are gone.  You must now use QMTest from the llvm/test directory to run
+	them.
+	</p><p>
+	To run the Programs test, cd into the llvm/test/Programs directory and
+	type <tt>gmake</tt>.  Alternatively, you can type <tt>gmake
+	TEST=&lt;type&gt; test</tt> to run one of the specialized tests in
+	llvm/test/Programs/TEST.&lt;type&gt;.Makefile.  For example, you could
+	run the nightly tester tests using the following commands:
+	</p>
 
-<p>As mentioned previously, the Programs tree in llvm/test provides three types
-of tests: MultiSource, SingleSource, and External.  Each tree is then subdivided
-into several categories, including applications, benchmarks, regression tests,
-code that is strange grammatically, etc.  These organizations should be
-relatively self explanatory.</p>
+	<pre>
+	 % cd llvm/test/Programs
+	 % gmake TEST=nightly test
+	</pre>
 
-<p>In addition to the regular Programs tests, the Programs tree also provides a
-mechanism for compiling the programs in different ways.  If the variable TEST is
-defined on the gmake command line, the test system will include a Makefile named
-<tt>TEST.&lt;value of TEST variable&gt;.Makefile</tt>.  This Makefile can modify
-build rules to yield different results.</p>
-
-<p>For example, the LLVM nightly tester uses <tt>TEST.nightly.Makefile</tt> to
-create the nightly test reports.  To run the nightly tests, run <tt>gmake
-TEST=nightly</tt>.</p>
-
-<p>There are several TEST Makefiles available in the tree.  Some of them are
-designed for internal LLVM research and will not work outside of the LLVM
-research group.  They may still be valuable, however, as a guide to writing your
-own TEST Makefile for any optimization or analysis passes that you develop with
-LLVM.</p>
-      
-</div>
-
-<!--===============================================================-->
-<div class="doc_section"><a name="run">Running the LLVM Tests</a></div>
-<!--===============================================================-->
-
-<div class="doc_text">
-
-<p>First, all tests are executed within the LLVM object directory tree.  They
-<i>are not</i> executed inside of the LLVM source tree.  This is because the
-test suite creates temporary files during execution.  </p>
-
-<p>The master Makefile in llvm/test is capable of running both the QMTest driven
-tests and the Programs tests.  By default, it will run all of the tests.</p>
-
-<p>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>For example, to run the Regression.LLC tests, type <tt>gmake
-Regression.LLC.t</tt> in llvm/tests.</p>
-
-<p>Note that the Makefiles in llvm/test/Features and llvm/test/Regression are
-gone. You must now use QMTest from the llvm/test directory to run them.</p>
-
-<p>To run the Programs test, cd into the llvm/test/Programs directory and type
-<tt>gmake</tt>.  Alternatively, you can type <tt>gmake TEST=&lt;type&gt;
-test</tt> to run one of the specialized tests in
-llvm/test/Programs/TEST.&lt;type&gt;.Makefile. For example, you could run the
-nightly tester tests using the following commands:</p>
-
-<pre>
- % cd llvm/test/Programs
- % gmake TEST=nightly test
-</pre>
-
-<p>Regardless of which test you're running, the results are printed on standard
-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,
-the result for such tests will be XFAIL (eXpected FAILure).  In this way, you
-can tell the difference between an expected and unexpected failure.</p>
-
-<p>The Programs tests have no such feature as of this time. If the test passes,
-only warnings and other miscellaneous output will be generated.  If a test
-fails, a large &lt;program&gt; FAILED message will be displayed.  This will help
-you separate benign warnings from actual test failures.</p>
-
-</div>
-
-<!--===============================================================-->
-<div class="doc_section"><a name="nightly">Running the nightly tester</a></div>
-<!--===============================================================-->
-
-<div class="doc_text">
-
-<p>
-The <a href="http://llvm.cs.uiuc.edu/testresults/">LLVM Nightly Testers</a>
-automatically check out an LLVM tree, build it, run the "nightly" 
-program test (described above) and all of the regression tests, then 
-delete the checked out tree.  This tester is designed to ensure that 
-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>
-
-<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
-</pre>
-
-<p>
-Take a look at the NightlyTest.pl file to see what all of the flags and 
-strings do.  If you start running the nightly tests, please let us know and 
-we'll link your page to the global tester page.  Thanks!
-</p>
-      
-</div>
+	<p>
+	Regardless of which test you're running, the results are printed on
+	standard 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, the result for such tests will be XFAIL (eXpected FAILure).  In
+	this way, you can tell the difference between an expected and unexpected
+	failure.
+	</p><p>
+	The Programs tests have no such feature as of this time.  If the test
+	passes, only warnings and other miscellaneous output will be generated.
+	If a test fails, a large &lt;program&gt; FAILED message will be
+	displayed.  This will help you separate benign warnings from actual test
+	failures.
+        </p>
+        </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>
+<hr><font size="-1">
+<address>John T. Criswell</address>
+<a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
+<br>
+Last modified: $Date$
+</font>
 
-  John T. Criswell<br>
-  <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a><br>
-  Last modified: $Date$
-</address>
 </body>
 </html>

llvm/docs/doxygen.cfg

@@ -201,7 +201,7 @@ DISTRIBUTE_GROUP_DOC   = NO
 # The TAB_SIZE tag can be used to set the number of spaces in a tab. 
 # Doxygen uses this value to replace tabs by spaces in code fragments.
 
-TAB_SIZE               = 2
+TAB_SIZE               = 8
 
 # The GENERATE_TODOLIST tag can be used to enable (YES) or 
 # disable (NO) the todo list. This list is created by putting \todo 
@@ -301,7 +301,7 @@ WARN_LOGFILE           =
 # directories like "/usr/src/myproject". Separate the files or directories with
 # spaces.
 
-INPUT                  = .. ./doxygen.intro
+INPUT                  = ..
 
 # If the value of the INPUT tag contains directories, you can use the 
 # FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp 
@@ -411,7 +411,7 @@ ALPHABETICAL_INDEX     = YES
 # the COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns 
 # in which this list will be split (can be a number in the range [1..20])
 
-COLS_IN_ALPHA_INDEX    = 4
+COLS_IN_ALPHA_INDEX    = 5
 
 # In case all classes in a project start with a common prefix, all 
 # classes will be put under the same header in the alphabetical index. 
@@ -439,20 +439,20 @@ HTML_OUTPUT            = .
 # each generated HTML page. If it is left blank doxygen will generate a 
 # standard header.
 
-HTML_HEADER            = doxygen.header
+HTML_HEADER            = 
 
 # The HTML_FOOTER tag can be used to specify a personal HTML footer for 
 # each generated HTML page. If it is left blank doxygen will generate a 
 # standard footer.
 
-HTML_FOOTER            = doxygen.footer
+HTML_FOOTER            = 
 
 # The HTML_STYLESHEET tag can be used to specify a user defined cascading 
 # style sheet that is used by each HTML page. It can be used to 
 # fine-tune the look of the HTML output. If the tag is left blank doxygen 
 # will generate a default style sheet
 
-HTML_STYLESHEET        = doxygen.css
+HTML_STYLESHEET        = 
 
 # If the HTML_ALIGN_MEMBERS tag is set to YES, the members of classes, 
 # files or namespaces will be aligned in HTML using tables. If set to 
@@ -861,3 +861,38 @@ DOT_CLEANUP            = YES
 # used. If set to NO the values of all tags below this one will be ignored.
 
 SEARCHENGINE           = NO
+
+# The CGI_NAME tag should be the name of the CGI script that 
+# starts the search engine (doxysearch) with the correct parameters. 
+# A script with this name will be generated by doxygen.
+
+CGI_NAME               = 
+
+# The CGI_URL tag should be the absolute URL to the directory where the 
+# cgi binaries are located. See the documentation of your http daemon for 
+# details.
+
+CGI_URL                = 
+
+# The DOC_URL tag should be the absolute URL to the directory where the 
+# documentation is located. If left blank the absolute path to the 
+# documentation, with file:// prepended to it, will be used.
+
+DOC_URL                = 
+
+# The DOC_ABSPATH tag should be the absolute path to the directory where the 
+# documentation is located. If left blank the directory on the local machine 
+# will be used.
+
+DOC_ABSPATH            = 
+
+# The BIN_ABSPATH tag must point to the directory where the doxysearch binary 
+# is installed.
+
+BIN_ABSPATH            = 
+
+# The EXT_DOC_PATHS tag can be used to specify one or more paths to 
+# documentation generated for other projects. This allows doxysearch to search 
+# the documentation for these projects as well.
+
+EXT_DOC_PATHS          = 

llvm/docs/doxygen.css

@@ -1,90 +0,0 @@
-BODY { background: white; color: black; font-family: Verdana,Arial,sans-serif; }
-H1 { text-align: center; }
-H2 { text-align: center; }
-H3 { text-align: center; }
-CAPTION { font-weight: bold }
-A.qindex {}
-A.qindexRef {}
-A.el { text-decoration: none; font-weight: bold }
-A.elRef { font-weight: bold }
-A.code { text-decoration: none; font-weight: normal; color: #4444ee }
-A.codeRef { font-weight: normal; color: #4444ee }
-A:link {
-        cursor: pointer;
-        text-decoration: none;
-        font-weight: bolder;
-}
-A:visited {
-        cursor: pointer;
-        text-decoration: underline;
-        font-weight: bolder;
-}
-A:hover {
-        cursor: pointer;
-        text-decoration: underline;
-        font-weight: bolder;
-}
-A:active {
-        cursor: pointer;
-        text-decoration: underline;
-        font-weight: bolder;
-        font-style: italic;
-}
-DL.el { margin-left: -1cm }
-DIV.fragment { width: 100%; border: none; background-color: #eeeeee }
-DIV.ah { background-color: black; font-weight: bold; color: #ffffff; margin-bottom: 3px; margin-top: 3px }
-TD.md { background-color: #f2f2ff; font-weight: bold; }
-TD.mdname1 { background-color: #f2f2ff; font-weight: bold; color: #602020; }
-TD.mdname { background-color: #f2f2ff; font-weight: bold; color: #602020; width: 600px; }
-DIV.groupHeader { margin-left: 16px; margin-top: 12px; margin-bottom: 6px; font-weight: bold }
-DIV.groupText { margin-left: 16px; font-style: italic; font-size: smaller }
-TD.indexkey { 
-   background-color: #eeeeff; 
-   font-weight: bold; 
-   padding-right  : 10px; 
-   padding-top    : 2px; 
-   padding-left   : 10px; 
-   padding-bottom : 2px; 
-   margin-left    : 0px; 
-   margin-right   : 0px; 
-   margin-top     : 2px; 
-   margin-bottom  : 2px  
-}
-TD.indexvalue { 
-   background-color: #eeeeff; 
-   font-style: italic; 
-   padding-right  : 10px; 
-   padding-top    : 2px; 
-   padding-left   : 10px; 
-   padding-bottom : 2px; 
-   margin-left    : 0px; 
-   margin-right   : 0px; 
-   margin-top     : 2px; 
-   margin-bottom  : 2px  
-}
-span.keyword       { color: #008000 }
-span.keywordtype   { color: #604020 }
-span.keywordflow   { color: #e08000 }
-span.comment       { color: #800000 }
-span.preprocessor  { color: #806020 }
-span.stringliteral { color: #002080 }
-span.charliteral   { color: #008080 }
-
-.footer {
-        font-size: 80%;
-        font-weight: bold;
-        text-align: center;
-        vertical-align: middle;
-}
-.title {
-  font-size: 25pt; 
-  color: black; background: url("../img/lines.gif");
-  font-weight: bold;
-  border-width: 1px;
-  border-style: solid none solid none;
-  text-align: center;
-  vertical-align: middle;
-  padding-left: 8pt;
-  padding-top: 1px;
-  padding-bottom: 2px
-}

llvm/docs/doxygen.footer

@@ -1,10 +0,0 @@
-<hr>
-
-<p class="footer">
-Generated on $datetime for <a href="http://llvm.cs.uiuc.edu">LLVM</a> by
-<a href="http://www.doxygen.org">doxygen $doxygenversion</a><br/>
-Copyright &copy; 2003,2004 University of Illinois at Urbana-Champaign. All
-Rights Reserved.</p>
-
-</body>
-</html>

llvm/docs/doxygen.header

@@ -1,9 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<html><head>
-<meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1"/>
-<meta name="keywords" content="LLVM,Low Level Virtual Machine,C++,doxygen,API,documentation"/>
-<meta name="description" content="C++ source code API documentation for the Low Level Virtual Machine (LLVM)."/>
-<title>LLVM: $title</title>
-<link href="doxygen.css" rel="stylesheet" type="text/css"/>
-</head><body>
-<p class="title">LLVM API Documentation</p>

llvm/docs/doxygen.intro

@@ -1,25 +0,0 @@
-////////////////////////////////////////////////////////////////////////////////
-/// @file doxygen.intro
-/// @author Reid Spencer <rspencer@x10sys.com> 
-/// @date 2003/12/30
-/// @brief LLVM API documentation introduction.
-////////////////////////////////////////////////////////////////////////////////
-///
-/// @mainpage LLVM:Low Level Virtual Machine
-///
-/// @section main_intro Introduction
-/// Welcome to the Low Level Virtual Machine (LLVM)
-///
-/// This documentation describes the @b internal software that makes 
-/// up LLVM, not the @b external use of  LLVM. There are no instructions
-/// here on how to use LLVM, only the APIs that make up the software. For usage 
-/// instructions, please see the programmer's guide or reference manual.
-///
-/// @section main_caveat Caveat 
-/// This documentation is generated directly from the source code with doxygen. 
-/// Since LLVM is constantly under active development, what you're about to
-/// read is out of date! However, it may still be useful since certain portions
-/// of LLVM are very stable. 
-///
-/// @section main_changelog Change Log
-/// - Original content written 12/30/2003 by Reid Spencer

llvm/docs/index.html

@@ -1,200 +1,279 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
-                      "http://www.w3.org/TR/html4/strict.dtd">
 <html>
-<head>
-  <title>Documentation for the LLVM System</title>
-  <link rel="stylesheet" href="llvm.css" type="text/css">
-</head>
+<title>
+The LLVM Compiler Infrastructure
+</title>
+
 <body>
 
-<div class="doc_title">Documentation for the LLVM System</div>
-
-<div class="doc_text">
-<ul>
-  <li><a href="#llvmdesign">LLVM Design</a></li>
-  <li><a href="#userguide">LLVM User Guides</a></li>
-  <li><a href="#llvmprog">General LLVM Programming Documentation</a></li>
-  <li><a href="#subsystems">LLVM Subsystem Documentation</a></li>
-  <li><a href="#maillist">LLVM Mailing Lists</a></li>
-</ul>
-</div>
-
-<div class="doc_author">    
-  <p>Written by <a href="http://llvm.cs.uiuc.edu">The LLVM Team</a></p>
-</div>
-
-<!--=======================================================================-->
-<div class="doc_section"><a name="llvmdesign">LLVM Design</a></div>
-<!--=======================================================================-->
-
-<ul>
-<li><a href="pubs/2004-01-30-CGO-LLVM.html"> LLVM: A Compilation Framework for
-Lifelong Program Analysis &amp; Transformation</a>: - Describes
-the LLVM instruction set and compilation strategy.  This should be the first
-document you read to get an overview of LLVM.</li>
-
-<li><a href="LangRef.html">LLVM Reference Manual</a> - Defines the LLVM
-intermediate representation, the assembly form of the different nodes, and
-provides reference information about the different tools in LLVM.</li>
-
-<li><a href="BytecodeFormat.html">LLVM Bytecode File Format</a></li>
-
-</ul>
-
-<!--=======================================================================-->
-<div class="doc_section"><a name="userguide">LLVM User Guides</a></div>
-<!--=======================================================================-->
-
-<ul>
-<li><a href="GettingStarted.html">The LLVM Getting Started Guide</a> -
-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="CommandGuide/index.html">LLVM Command Guide</a> - A reference
-manual for the LLVM command line utilities ("man" pages for LLVM tools).</li>
-
-<li><a href="FAQ.html">Frequently Asked Questions</a> - A list of common
-questions and problems and their solutions.</li>
-
-<li><a href="ReleaseNotes.html">Release notes for the current release</a> 
-- This describes new features, known bugs, and other limitations.</li>
-
-<li><a href="HowToSubmitABug.html">How to Submit A Bug Report</a> -
-Instructions for properly submitting information about any bugs you run into in
-the LLVM system.</li>
-
-<li><a href="TestingGuide.html">LLVM Test Suite Guide</a> - A reference
-manual for using the LLVM test suite.</li>
-
-<li><a href="CFEBuildInstrs.html">How to build the C/C++ front-end</a> -
-Instructions for building the front-end from source.</li>
-
-<li><a name="irc">You can probably find help on the unofficial LLVM IRC 
-channel</a>.  We often are on irc.oftc.net in the #llvm channel.  If you are 
-using the mozilla browser, and have chatzilla installed, you can join by <a 
-href="irc://irc.oftc.net/llvm">clicking here</a>.</li>
-
-</ul>
-
-
-<!--=======================================================================-->
-<div class="doc_section"><a name="llvmprog">General LLVM Programming Documentation</a></div>
-<!--=======================================================================-->
-
-<ul>
-<li><a href="ProgrammersManual.html">The LLVM Programmers Manual</a> -
-Introduction to the general layout of the LLVM sourcebase, important classes
-and APIs, and some tips &amp; tricks.</li>
-
-<li><a href="Projects.html">LLVM Project Guide</a> - How-to guide and
-templates for new projects that <em>use</em> the LLVM infrastructure.  The
-templates (directory organization, Makefiles, and test tree) allow the project
-code to be located outside (or inside) the <tt>llvm/</tt> tree, while using LLVM
-header files and libraries.</li>
-
-<li><a href="CommandLine.html">CommandLine library Reference Manual</a> -
-Provides information on using the command line parsing library.</li>
-
-<li><a href="CodingStandards.html">Recommended LLVM Coding standards</a> -
-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>
-
-<li><a href="CodingStandards.html">Coding Standards</a> - Guidelines for
-hacking LLVM source.</li>
-
-<li><a href="http://llvm.cs.uiuc.edu/doxygen/">Doxygen generated 
-documentation</a> (<a href="http://llvm.cs.uiuc.edu/doxygen/inherits.html">
-classes</a>)</li>
-
-<li><a href="http://llvm.cs.uiuc.edu/cvsweb/cvsweb.cgi/llvm">CVSWeb CVS Tree 
-Browser</a></li>
-
-</ul>
-
-<!--=======================================================================-->
-<div class="doc_section"><a name="subsystems">LLVM Subsystem Documentation</a></div>
-<!--=======================================================================-->
-
-<ul>
-
-<li><a href="WritingAnLLVMPass.html">Writing an LLVM Pass</a> - Information
-on how to write LLVM transformations and analyses.</li>
-
-<li><a href="CodeGenerator.html">The LLVM Target-Independent Code
-Generator</a> - The design and implementation of the LLVM code generator.
-Useful if you are working on retargetting LLVM to a new architecture, designing
-a new codegen pass, or enhancing existing components.</li>
-
-<li><a href="TableGenFundamentals.html">TableGen Fundamentals</a> -
-Describes the TableGen tool, which is used heavily by the LLVM code
-generator.</li>
-
-<li><a href="AliasAnalysis.html">Alias Analysis in LLVM</a> - Information
-on how to write a new alias analysis implementation or how to use existing
-analyses.</li>
-
-<li><a href="Stacker.html">The Stacker Cronicles</a> - This document
-describes both the Stacker language and LLVM frontend, but also some details
-about LLVM useful for those writing front-ends.</li>
-
-<li><a href="GarbageCollection.html">Accurate Garbage Collection with
-LLVM</a> - The interfaces source-language compilers should use for compiling
-GC'd programs.</li>
-
-<li><a href="SourceLevelDebugging.html">Source Level Debugging with
-LLVM</a> - This document describes the design and philosophy behind the LLVM
-source-level debugger.</li>
-
-<li><a href="Bugpoint.html">Bugpoint</a> automatic bug finder and
-test-case reducer description and usage information.</li>
-
-</ul>
-
-<!--=======================================================================-->
-<div class="doc_section"><a name="maillist">LLVM Mailing Lists</a></div>
-<!--=======================================================================-->
-
-<ul>
-<li>The <a href="http://mail.cs.uiuc.edu/mailman/listinfo/llvm-announce">
-LLVM Announcements List</a>: This is a low volume list that provides important 
-announcements regarding LLVM.  It gets email about once a month.</li>
-
-<li>The <a href="http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev">Developer's
-List</a>: This list is for people who want to be included in technical 
-discussions of LLVM. People post to this list when they have questions about 
-writing code for or using the LLVM tools. It is relatively low volume.</li>
-
-<li>The <a href="http://mail.cs.uiuc.edu/pipermail/llvmbugs/">Bugs &amp;
-Patches Archive</a>: This list gets emailed every time a bug is opened and
-closed, and when people submit patches to be included in LLVM.  It is higher 
-volume than the LLVMdev list.</li>
-
-<li>The <a href="http://mail.cs.uiuc.edu/pipermail/llvm-commits/">CVS Commits
-Archive</a>: This list contains all commit messages that are made when LLVM 
-developers commit code changes to the CVS archive. It is useful for those who 
-want to stay on the bleeding edge of LLVM development. This list is very high
-volume.</li>
-
-</ul>
-
-<!-- *********************************************************************** -->
+<center>
+<h1>
+                       The LLVM Compiler Infrastructure
+                                 <br>
+        <a href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a>
+</h1>
+</center>
 
 <hr>
-<address>
-  <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
-  src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a>
-  <a href="http://validator.w3.org/check/referer"><img
-  src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"></a>
 
-  <a href="http://llvm.cs.uiuc.edu">LLVM Compiler Infrastructure</a><br>
-  Last modified: $Date$
-</address>
+<h2>
+Welcome to LLVM!
+</h2>
+This file is intended to do four things:
+<ol>
+	<li>
+	help you get started using LLVM;
+	</li>
+
+	<li>
+	tell you how to get questions about LLVM answered;
+	</li>
+
+	<li>
+	tell you where to find documentation for different kinds of questions; and
+	</li>
+
+	<li>
+	tell you about three LLVM-related mailing lists.
+	</li>
+</ol>
+
+
+<hr>
+
+<h2>
+Getting Started with LLVM
+</h2>
+
+<dl compact>
+    <dt>
+    For license information:
+    <dd>
+        <a href="../LICENSE.TXT">llvm/LICENSE.TXT</a>
+        <p>
+
+    <dt>
+    Installing and compiling LLVM:
+    <dd>
+        <a href="GettingStarted.html">llvm/docs/GettingStarted.html</a>
+        <p>
+
+    <dt>
+    Learn about features and limitations of this release:
+    <dd>
+        <a href="ReleaseNotes.html">llvm/docs/ReleaseNotes.html</a>
+        <p>
+
+    <dt>
+    Learn how to write a pass within the LLVM system:
+    <dd>
+        <a href="WritingAnLLVMPass.html">llvm/docs/WritingAnLLVMPass.html </a>
+        <p>
+
+    <dt>
+    Learn how to start a new development project using LLVM, where your
+    new source code can live anywhere (outside or inside the LLVM tree),
+    while using LLVM header files and libraries:
+    <dd>
+        <a href="Projects.html">llvm/docs/Projects.html</a>
+</dl>
+
+<hr>
+
+<h2>
+Getting Help with LLVM
+</h2>
+
+<ol>
+        <li>
+        If you have questions or development problems not answered in the
+        documentation, send e-mail to llvmdev@cs.uiuc.edu.  This mailing list is
+        monitored by all the people in the LLVM group at Illinois, and you
+        should expect prompt first responses.
+        </li>
+
+        <li>
+        To report a bug, submit a bug report as described in the document:
+        <a href="http://llvm.cs.uiuc.edu/docs/HowToSubmitABug.html">
+        http://llvm.cs.uiuc.edu/docs/HowToSubmitABug.html</a>
+        </li>
+
+        <li>
+        We now use Bugzilla to track bugs, so you can check the status of
+        previous bugs at:
+        <a href="http://llvm.cs.uiuc.edu/bugs/query.cgi">
+        http://llvm.cs.uiuc.edu/bugs/query.cgi </a>
+        </li>
+</ol>
+
+<hr>
+
+<h2>
+LLVM Documentation
+</h2>
+
+All the documents mentioned below except the design overview tech report
+are included as part of the LLVM release (in llvm/docs/*):
+
+<h3>
+LLVM Design Overview:
+</h3>
+
+<dl compact>
+    <dt>
+    LLVM : A Compilation Framework for Lifelong Program Analysis
+    and Transformation:
+    <dd>
+        <a href="http://llvm.cs.uiuc.edu/pubs/2003-09-30-LifelongOptimizationTR.html">
+        http://llvm.cs.uiuc.edu/pubs/2003-09-30-LifelongOptimizationTR.html </a>
+
+</dl>
+
+<h3>
+LLVM User Guides:
+</h3>
+
+<dl compact>
+    <dt>
+    Download and Installation Instructions:
+    <dd>
+        <a href="GettingStarted.html"> llvm/docs/GettingStarted.html</a>
+        <p>
+
+    <dt>
+    LLVM Command Guide:
+    <dd>
+        <a href="CommandGuide/index.html">
+        llvm/docs/CommandGuide/index.html</a>
+        <p>
+
+    <dt>
+    LLVM Assembly Language:
+    <dd>
+        <a href="LangRef.html"> llvm/docs/LangRef.html</a>
+        <p>
+
+    <dt>
+    LLVM Test Suite Guide:
+    <dd>
+        <a href="TestingGuide.html"> llvm/docs/TestingGuide.html</a>
+        <p>
+</dl>
+
+<h3>
+LLVM Programming Documentation:
+</h3>
+
+<dl compact>
+    <dt>
+    LLVM Programmers Manual:
+    <dd>
+        <a href="ProgrammersManual.html"> llvm/docs/ProgrammersManual.html</a>
+        <p>
+
+    <dt>
+    Writing an LLVM Pass:
+    <dd>
+        <a href="WritingAnLLVMPass.html"> llvm/docs/WritingAnLLVMPass.html</a>
+        <p>
+
+    <dt>
+    Alias Analysis in LLVM:
+    <dd>
+        <a href="AliasAnalysis.html"> llvm/docs/AliasAnalysis.html</a>
+        <p>
+
+    <dt>
+    The Stacker Cronicles
+    <dd>
+        <a href="Stacker.html">The Stacker Cronicles</a>
+   - This document describes both the Stacker language and
+                    LLVM frontend, but also some details about LLVM useful for
+                    those writing front-ends.<p>
+
+
+    <dt>
+    Command Line Library:
+    <dd>
+        <a href="CommandLine.html"> llvm/docs/CommandLine.html</a>
+        <p>
+
+    <dt>
+    Coding Standards:
+    <dd>
+        <a href="CodingStandards.html"> llvm/docs/CodingStandards.html</a>
+        <p>
+</dl>
+
+<h3>
+Other LLVM Resources:
+</h3>
+
+<dl compact>
+    <dt>
+    Building the LLVM C/C++ front-end:
+    <dd>
+      <a href="CFEBuildInstrs.html">llvm/docs/CFEBuildInstrs.html</a>
+      <p>
+    <dt>
+    Submitting a Bug:
+    <dd>
+        <a href="http://llvm.cs.uiuc.edu/docs/HowToSubmitABug.html">
+        http://llvm.cs.uiuc.edu/docs/HowToSubmitABug.html</a>
+        <p>
+
+    <dt>
+    Open Projects:
+    <dd>
+        <a href="OpenProjects.html"> llvm/docs/OpenProjects.html</a>
+        <p>
+
+    <dt>
+    Creating a new LLVM Project:
+    <dd>
+        <a href="Projects.html"> llvm/docs/Projects.html</a>
+        <p>
+</dl>
+
+<hr>
+
+<h2>
+Mailing Lists
+</h2>
+There are three mailing lists for providing LLVM users with information:
+
+<ol>
+    <li> LLVM Announcements List:<br>
+    <a href="http://mail.cs.uiuc.edu/mailman/listinfo/llvm-announce">
+    http://mail.cs.uiuc.edu/mailman/listinfo/llvm-announce</a>
+
+    <p>
+    This is a low volume list that provides important announcements regarding
+    LLVM.  It is primarily intended to announce new releases, major updates to
+    the software, etc.  This list is highly recommended for anyone that uses
+    LLVM.
+    </p>
+
+    <li> LLVM Developers List:<br>
+    <a href="http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev">
+    http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev</a>
+
+    <p>
+    This list is for people who want to be included in technical discussions
+    of LLVM.  People post to this list when they have questions about writing
+    code for or using the LLVM tools.  It is relatively low volume.
+    </p>
+
+    <li> LLVM Commits List<br>
+    <a href="http://mail.cs.uiuc.edu/mailman/listinfo/llvm-commits">
+    http://mail.cs.uiuc.edu/mailman/listinfo/llvm-commits</a>
+
+    <p>
+    This list contains all commit messages that are made when LLVM developers
+    commit code changes to the CVS archive.  It is useful for those who want to
+    stay on the bleeding edge of LLVM development. This list is very high
+    volume.
+    </p>
+</ol>
+</body>
+</html>
 

llvm/docs/llvm.css

@@ -16,45 +16,36 @@ address     { clear: right; }
  */
 /* Common for title and header */
 .doc_title, .doc_section, .doc_subsection { 
-  color: black; background: url("img/lines.gif");
+  color: #ffffff; background: #330077;
   font-family: "Georgia,Palatino,Times,Roman"; font-weight: bold;
-  border-width: 1px;
-  border-style: solid none solid none;
-  text-align: center;
-  vertical-align: middle;
   padding-left: 8pt;
   padding-top: 1px;
   padding-bottom: 2px
 }
 
 .doc_title      { text-align: left;   font-size: 25pt }
-.doc_section    { text-align: center; font-size: 22pt;
-                  margin: 20pt 0pt 5pt 0pt; }
-.doc_subsection { width: 75%;
-                  text-align: left;  font-size: 12pt; padding: 4pt 4pt 4pt 4pt;
-                  margin: 1.5em 0.5em 0.5em 0.5em }
+.doc_section    { text-align: center; font-size: 22pt; }
+.doc_subsection { background: #441188; width: 50%;
+                  text-align: left;   font-size: 12pt; padding: 4pt 4pt 4pt 4pt;
+                  margin: 1.5em 0.5em 1.5em 0.5em }
 
-.doc_subsubsection { margin: 2.0em 0.5em 0.5em 0.5em;
+/* In the future, the 2nd level subsection style may want to become this:
+.doc_subsubsection { margin: 1.5em 0.5em 1.5 0.5em;
                      font-weight: bold; font-style: oblique;
-                     border-bottom: 1px solid #999999; font-size: 12pt;
-                     width: 75%; }
-.doc_author     { text-align: left; font-weight: bold; padding-left: 20pt }
+                     border-bottom: 2px dotted #999999 }
+*/
+
+/* However, to be consistent with the rest of current documentation which is not
+   all yet using stylesheets, we try to emulate the former layout. */
+.doc_subsubsection { margin: 1.5em 0.5em 1.5em 0.5em;
+                     font-weight: bold;
+                     border-top: 2px solid #cecece }
+
 .doc_text       { text-align: left; padding-left: 20pt }
 
 .doc_footer     { text-align: left; padding: 0 0 0 0 }
 
 .doc_red        { color: red }
 
-.doc_table      { text-align: center; width: 90%; 
-                  padding: 1px 1px 1px 1px; border: 1px; }
+.doc_table	{ text-align: center; width: 90%; padding: 1 1 1 1; border: 1 1 1 1 ; }
 
-.doc_table_nw   { text-align: center; border: 1px; 
-    		  padding: 1px 1px 1px 1px; }
-
-.doc_warning    { color: red; font-weight: bold }
-
-.doc_code       { border: solid 1px gray; background: #eeeeee;
-                  margin: 0 1em 0 1em; 
-                  padding: 0 1em 0 1em;
-                  display:table;
-                }

llvm/include/Config/alloca.h

@@ -23,23 +23,27 @@
  *	2) If alloca.h cannot be found, then try stdlib.h.  Some platforms
  *	   (notably FreeBSD) defined alloca() there.
  */
-#ifdef _MSC_VER
-/* noop on Visual C++ */
-#elif defined(HAVE_ALLOCA_H)
-#include <alloca.h>
-#elif !defined(__GNUC__)
-#	ifdef _AIX
- #		pragma alloca
+#ifndef __GNUC__
+#	ifdef HAVE_ALLOCA_H
+#		include <alloca.h>
 #	else
-#		ifndef alloca
-			char * alloca ();
+#		ifdef _AIX
+ #			pragma alloca
+#		else
+#			ifndef alloca
+				char * alloca ();
+#			endif
 #		endif
 #	endif
 #else
-#	ifdef HAVE_STDLIB_H
-#		include <stdlib.h>
+#	ifdef HAVE_ALLOCA_H
+#		include <alloca.h>
 #	else
-#		error "The function alloca() is required but not found!"
+#		ifdef HAVE_STDLIB_H
+#			include <stdlib.h>
+#		else
+#			error "The function alloca() is required but not found!"
+#		endif
 #	endif
 #endif
 

llvm/include/Config/config.h.in

@@ -8,6 +8,12 @@
 /* Define to 1 if using `alloca.c'. */
 #undef C_ALLOCA
 
+/* Define if the machine is Big-Endian */
+#undef ENDIAN_BIG
+
+/* Define if the machine is Little-Endian */
+#undef ENDIAN_LITTLE
+
 /* Define to 1 if you have `alloca', as a function or macro. */
 #undef HAVE_ALLOCA
 
@@ -15,8 +21,11 @@
    */
 #undef HAVE_ALLOCA_H
 
-/* Define to 1 if you have the `backtrace' function. */
-#undef HAVE_BACKTRACE
+/* Define to 1 if you have the <assert.h> header file. */
+#undef HAVE_ASSERT_H
+
+/* define if the compiler has bidirectional iterator */
+#undef HAVE_BI_ITERATOR
 
 /* Define to 1 if you have the <dlfcn.h> header file. */
 #undef HAVE_DLFCN_H
@@ -24,15 +33,17 @@
 /* Define if dlopen() is available on this platform. */
 #undef HAVE_DLOPEN
 
-/* Define to 1 if you have the <execinfo.h> header file. */
-#undef HAVE_EXECINFO_H
+/* Define to 1 if you have the <errno.h> header file. */
+#undef HAVE_ERRNO_H
+
+/* define if the compiler has ext/slist */
+#undef HAVE_EXT_SLIST
 
 /* Define to 1 if you have the <fcntl.h> header file. */
 #undef HAVE_FCNTL_H
 
-/* Define to 1 if your compiler defines finite in the <ieeefp.h> header file.
-   */
-#undef HAVE_FINITE_IN_IEEEFP_H
+/* define if the compiler has STL iterators */
+#undef HAVE_FWD_ITERATOR
 
 /* Define to 1 if you have the `getcwd' function. */
 #undef HAVE_GETCWD
@@ -40,33 +51,31 @@
 /* Define to 1 if you have the `getpagesize' function. */
 #undef HAVE_GETPAGESIZE
 
-/* Define to 1 if you have the `getrusage' function. */
-#undef HAVE_GETRUSAGE
-
 /* Define to 1 if you have the `gettimeofday' function. */
 #undef HAVE_GETTIMEOFDAY
 
+/* Define if the compiler has a header <hash_map> that defines template class
+   ::hash_map. */
+#undef HAVE_GLOBAL_HASH_MAP
+
+/* Define if the compiler has a header <hash_set> that defines template class
+   ::hash_set. */
+#undef HAVE_GLOBAL_HASH_SET
+
+/* Define if the compiler has a header <ext/hash_map> that defines template
+   class __gnu_cxx::hash_map. */
+#undef HAVE_GNU_EXT_HASH_MAP
+
+/* Define if the compiler has a header <ext/hash_set> that defines template
+   class __gnu_cxx::hash_set. */
+#undef HAVE_GNU_EXT_HASH_SET
+
 /* Define to 1 if the system has the type `int64_t'. */
 #undef HAVE_INT64_T
 
 /* Define to 1 if you have the <inttypes.h> header file. */
 #undef HAVE_INTTYPES_H
 
-/* Define to 1 if you have the `isatty' function. */
-#undef HAVE_ISATTY
-
-/* Define to 1 if your compiler defines isinf in the <cmath> header file. */
-#undef HAVE_ISINF_IN_CMATH
-
-/* Define to 1 if your compiler defines isinf in the <math.h> header file. */
-#undef HAVE_ISINF_IN_MATH_H
-
-/* Define to 1 if your compiler defines isnan in the <cmath> header file. */
-#undef HAVE_ISNAN_IN_CMATH
-
-/* Define to 1 if your compiler defines isnan in the <math.h> header file. */
-#undef HAVE_ISNAN_IN_MATH_H
-
 /* Define to 1 if you have the `elf' library (-lelf). */
 #undef HAVE_LIBELF
 
@@ -86,12 +95,12 @@
 /* Define to 1 if you have the <malloc.h> header file. */
 #undef HAVE_MALLOC_H
 
+/* Define to 1 if you have the <math.h> header file. */
+#undef HAVE_MATH_H
+
 /* Define to 1 if you have the <memory.h> header file. */
 #undef HAVE_MEMORY_H
 
-/* Define to 1 if you have the `mkstemp' function. */
-#undef HAVE_MKSTEMP
-
 /* Define to 1 if you have a working `mmap' system call. */
 #undef HAVE_MMAP
 
@@ -108,29 +117,57 @@
 /* Define to have the %a format string */
 #undef HAVE_PRINTF_A
 
+/* Define if PThread mutexes (e.g., pthread_mutex_lock) are available in the
+   system's thread library. */
+#undef HAVE_PTHREAD_MUTEX_LOCK
+
+/* Define to 1 if you have the <signal.h> header file. */
+#undef HAVE_SIGNAL_H
+
 /* Define to 1 if you have the <stdint.h> header file. */
 #undef HAVE_STDINT_H
 
 /* Define to 1 if you have the <stdlib.h> header file. */
 #undef HAVE_STDLIB_H
 
-/* Define to 1 if your compiler defines std::isinf in the <cmath> header file.
-   */
-#undef HAVE_STD_ISINF_IN_CMATH
+/* Define if the compiler has a header <ext/hash_map> that defines template
+   class std::hash_map. */
+#undef HAVE_STD_EXT_HASH_MAP
 
-/* Define to 1 if your compiler defines std::isnan in the <cmath> header file.
-   */
-#undef HAVE_STD_ISNAN_IN_CMATH
+/* Define if the compiler has a header <ext/hash_set> that defines template
+   class std::hash_set. */
+#undef HAVE_STD_EXT_HASH_SET
+
+/* define if the compiler has STL iterators */
+#undef HAVE_STD_ITERATOR
+
+/* Define to 1 if you have the `strcspn' function. */
+#undef HAVE_STRCSPN
 
 /* Define to 1 if you have the `strdup' function. */
 #undef HAVE_STRDUP
 
+/* Define to 1 if you have the `strerror' function. */
+#undef HAVE_STRERROR
+
 /* Define to 1 if you have the <strings.h> header file. */
 #undef HAVE_STRINGS_H
 
 /* Define to 1 if you have the <string.h> header file. */
 #undef HAVE_STRING_H
 
+/* Define to 1 if you have the `strspn' function. */
+#undef HAVE_STRSPN
+
+/* Define to 1 if you have the `strstr' function. */
+#undef HAVE_STRSTR
+
+/* Define to 1 if you have the `strtod' function. */
+#undef HAVE_STRTOD
+
+/* Define to 1 if you have the `strtol' function. */
+#undef HAVE_STRTOL
+
 /* Define to 1 if you have the `strtoll' function. */
 #undef HAVE_STRTOLL
 
@@ -161,9 +198,6 @@
 /* Define to 1 if you have the <unistd.h> header file. */
 #undef HAVE_UNISTD_H
 
-/* Define to 1 if you have the <windows.h> header file. */
-#undef HAVE_WINDOWS_H
-
 /* Define to the address where bug reports for this package should be sent. */
 #undef PACKAGE_BUGREPORT
 
@@ -182,9 +216,6 @@
 /* Define as the return type of signal handlers (`int' or `void'). */
 #undef RETSIGTYPE
 
-/* Extension that shared libraries have, e.g., ".so". */
-#undef SHLIBEXT
-
 /* If using the C implementation of alloca, define if you know the
    direction of stack growth for your system; otherwise it will be
    automatically deduced at run-time.
@@ -206,6 +237,13 @@
    `char[]'. */
 #undef YYTEXT_POINTER
 
+/* Define to empty if `const' does not conform to ANSI C. */
+#undef const
+
+/* Define as `__inline' if that's what the C compiler calls it, or to nothing
+   if it is not supported. */
+#undef inline
+
 /* Define to `int' if <sys/types.h> does not define. */
 #undef pid_t
 

llvm/include/Config/dlfcn.h

@@ -16,8 +16,17 @@
 
 #include "Config/config.h"
 
+/*
+ * According to the man pages on dlopen(), we sometimes need link.h.  So,
+ * go grab it just in case.
+ */
 #ifdef HAVE_DLFCN_H
 #include <dlfcn.h>
+
+#ifdef HAVE_LINK_H
+#include <link.h>
+#endif
+
 #endif
 
 #endif

llvm/include/Config/errno.h

@@ -7,19 +7,17 @@
  ******************************************************************************
  *
  * Description:
- *	This header file is the autoconf replacement for windows.h (if it lives
+ *	This header file is the autoconf replacement for errno.h (if it lives
  *	on the system).
  */
 
-#ifndef LLVM_CONFIG_WINDOWS_H
-#define LLVM_CONFIG_WINDOWS_H
+#ifndef _CONFIG_ERRNO_H
+#define _CONFIG_ERRNO_H
 
 #include "Config/config.h"
 
-#ifdef HAVE_WINDOWS_H
-#include <windows.h>
-#undef min
-#undef max
+#ifdef HAVE_ERRNO_H
+#include <errno.h>
 #endif
 
 #endif

llvm/include/Config/link.h

@@ -0,0 +1,23 @@
+/* 
+ *                     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.
+ * 
+ ******************************************************************************
+ *
+ * Description:
+ *	This header file is the autoconf replacement for link.h (if it lives
+ *	on the system).
+ */
+
+#ifndef _CONFIG_LINK_H
+#define _CONFIG_LINK_H
+
+#include "Config/config.h"
+
+#ifdef HAVE_LINK_H
+#include <link.h>
+#endif
+
+#endif

llvm/include/Config/pagesize.h

@@ -1,49 +0,0 @@
-/* 
- *                     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 header file provides a platform-independent way of quering page size.
- */
-
-#ifndef PAGESIZE_H
-#define PAGESIZE_H
-
-#include "Config/unistd.h"
-#include <sys/param.h>
-
-namespace llvm {
-
-/* Compatibility chart:
- *
- * Linux/x86:        _SC_PAGESIZE, _SC_PAGE_SIZE
- * MacOS X/PowerPC:  v. 10.2: NBPG, 
- *                   v. 10.3: _SC_PAGESIZE
- * Solaris/Sparc:    _SC_PAGESIZE, _SC_PAGE_SIZE
- */
-
-/**
- * GetPageSize - wrapper to return page size in bytes for various 
- *  architecture/OS combinations
- */ 
-unsigned GetPageSize() {
-#ifdef _SC_PAGESIZE
-  return sysconf(_SC_PAGESIZE);
-#elif defined(_SC_PAGE_SIZE)
-  return sysconf(_SC_PAGE_SIZE);
-#elif defined(NBPG)
-#ifndef CLSIZE
-#define CLSIZE 1
-#endif
-  return NBPG * CLSIZE;
-#else
-  return 4096; /* allocate 4KB as a fall-back */
-#endif
-}
-
-}
-
-#endif

llvm/include/Config/stdlib.h

@@ -0,0 +1,23 @@
+/* 
+ *                     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.
+ * 
+ *===----------------------------------------------------------------------===//
+ *
+ * Description:
+ *	This header file is the autoconf replacement for stdlib.h (if it lives
+ *	on the system).
+ */
+
+#ifndef _CONFIG_STDLIB_H
+#define _CONFIG_STDLIB_H
+
+#include "Config/config.h"
+
+#ifdef HAVE_STDLIB_H
+#include <stdlib.h>
+#endif
+
+#endif

llvm/include/Config/string.h

@@ -0,0 +1,23 @@
+/* 
+ *                     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.
+ * 
+ *===----------------------------------------------------------------------===//
+ *
+ * Description:
+ *	This header file is the autoconf replacement for string.h (if it lives
+ *	on the system).
+ */
+
+#ifndef _CONFIG_STRING_H
+#define _CONFIG_STRING_H
+
+#include "Config/config.h"
+
+#ifdef HAVE_STRING_H
+#include <string.h>
+#endif
+
+#endif

llvm/include/Config/sys/mman.h

@@ -20,7 +20,7 @@
 
 #include "Config/config.h"
 
-#if defined(HAVE_SYS_MMAN_H) && !defined(_MSC_VER)
+#ifdef HAVE_SYS_MMAN_H
 #include <sys/mman.h>
 #endif
 

llvm/include/Config/sys/resource.h

@@ -1,4 +1,4 @@
-/*===-- Config/sys/resource.h -----------------------------------*- C++ -*-===//
+/*===-- Config/sys/resource.h - Annotation classes --------------*- C++ -*-===//
  * 
  *                     The LLVM Compiler Infrastructure
  *
@@ -18,16 +18,22 @@
 
 #include "Config/config.h"
 
-#if defined(HAVE_SYS_RESOURCE_H) && !defined(_MSC_VER)
+#ifdef HAVE_SYS_RESOURCE_H
 
 /*
  * In LLVM, we use sys/resource.h to use getrusage() and maybe some other
  * stuff.  Some man pages say that you also need sys/time.h and unistd.h.
  * So, to be paranoid, we will try to include all three if possible.
  */
-#include "Config/sys/time.h"
+#ifdef HAVE_SYS_TIME_H
+#include <sys/time.h>
+#endif
+
 #include <sys/resource.h>
-#include "Config/unistd.h"
+
+#ifdef HAVE_UNISTD_H
+#include <unistd.h>
+#endif
 
 #endif
 

llvm/include/Config/sys/stat.h

@@ -1,4 +1,4 @@
-/*===-- Config/sys/stat.h -----------------------------------*- ----C++ -*-===//
+/*===-- Config/sys/stat.h - Annotation classes --------------*- ----C++ -*-===//
  * 
  *                     The LLVM Compiler Infrastructure
  *
@@ -21,9 +21,5 @@
 #include <sys/stat.h>
 #endif
 
-#if defined(_MSC_VER)
-#define S_ISREG(X) ((X) & _S_IFREG)
-#endif
-
 #endif
 

llvm/include/Config/sys/time.h

@@ -1,4 +1,4 @@
-/*===-- Config/sys/time.h ---------------------------------------*- C++ -*-===//
+/*===-- Config/sys/time.h - Annotation classes ------------------*- C++ -*-===//
  * 
  *                     The LLVM Compiler Infrastructure
  *
@@ -17,7 +17,7 @@
 
 #include "Config/config.h"
 
-#if defined(HAVE_SYS_TIME_H) && !defined(_MSC_VER)
+#ifdef HAVE_SYS_TIME_H
 #include <sys/time.h>
 #endif
 

llvm/include/Config/sys/types.h

@@ -1,4 +1,4 @@
-/*===-- Config/sys/types.h --------------------------------------*- C++ -*-===//
+/*===-- Config/sys/types.h - Annotation classes --------------*- C++ -*-===//
  * 
  *                     The LLVM Compiler Infrastructure
  *