Fix bugs section.

llvm-svn: 46992

llvm/.cvsignore

@@ -1,10 +0,0 @@
-mklib
-Makefile.config
-config.log
-config.status
-cvs.out
-autom4te.cache
-configure.out
-LLVM-*
-_distcheckdir
-llvm.spec

llvm/CREDITS.TXT

@@ -15,7 +15,8 @@ D: The Sparc64 backend, provider of much wisdom, and motivator for LLVM
 
 N: Owen Anderson
 E: resistor@mac.com
-D: LCSSA pass and related LoopUnswitch work, TargetData refactoring, random improvements
+D: LCSSA pass and related LoopUnswitch work
+D: GVNPRE pass, TargetData refactoring, random improvements
 
 N: Henrik Bach
 D: MingW Win32 API portability layer
@@ -28,6 +29,11 @@ D: Target-independent code generator and analysis improvements
 N: Daniel Berlin
 E: dberlin@dberlin.org
 D: ET-Forest implementation.
+D: Sparse bitmap
+
+N: Neil Booth
+E: neil@daikokuya.co.uk
+D: APFloat implementation.  
 
 N: Misha Brukman
 E: brukman+llvm@uiuc.edu
@@ -62,7 +68,7 @@ D: Native Win32 API portability layer
 
 N: John T. Criswell
 E: criswell@uiuc.edu
-D: Autoconf support, QMTest database, documentation improvements
+D: Original Autoconf support, documentation improvements, bug fixes
 
 N: Rafael Avila de Espindola
 E: rafael.espindola@gmail.com
@@ -95,6 +101,21 @@ N: Dan Gohman
 E: djg@cray.com
 D: Miscellaneous bug fixes
 
+N: David Greene
+E: greened@obbligato.org
+D: Miscellaneous bug fixes
+D: Register allocation refactoring
+
+N: Gordon Henriksen
+E: gordonhenriksen@mac.com
+D: Pluggable GC support
+D: C interface
+D: Ocaml bindings
+
+N: Raul Fernandes Herbster
+E: raul@dsc.ufcg.edu.br
+D: JIT support for ARM
+
 N: Paolo Invernizzi
 E: arathorn@fastwebnet.it
 D: Visual C++ compatibility fixes 
@@ -110,6 +131,10 @@ D: Support for packed types
 N: Dale Johannesen
 E: dalej@apple.com
 D: ARM constant islands improvements
+D: Tail merging improvements
+D: Rewrite X87 back end
+D: Use APFloat for floating point constants widely throughout compiler
+D: Implement X87 long double
 
 N: Eric Kidd
 W: http://randomhacks.net/
@@ -127,7 +152,9 @@ D: Author of the original C backend
 
 N: Christopher Lamb
 E: christopher.lamb@gmail.com
-D: aligned load/store support
+D: aligned load/store support, parts of noalias and restrict support
+D: vreg subreg infrastructure, X86 codegen improvements based on subregs
+D: address spaces
 
 N: Jim Laskey
 E: jlaskey@apple.com
@@ -141,7 +168,7 @@ E: sabre@nondot.org
 W: http://nondot.org/~sabre/
 D: Primary architect of LLVM
 
-N: Tanya Lattner (formerly Tanya Brethour)
+N: Tanya Lattner (Tanya Brethour)
 E: tonic@nondot.org
 W: http://nondot.org/~tonic/
 D: The initial llvm-ar tool, converted regression testsuite to dejagnu
@@ -158,10 +185,15 @@ N: Nick Lewycky
 E: nicholas@mxc.ca
 D: PredicateSimplifier pass
 
+N: Bruno Cardoso Lopes
+E: bruno.cardoso@gmail.com
+W: http://www.brunocardoso.org
+D: The Mips backend
+
 N: Duraid Madina
 E: duraid@octopus.com.au
 W: http://kinoko.c.u-tokyo.ac.jp/~duraid/
-D: IA64 backend
+D: IA64 backend, BigBlock register allocator
 
 N: Michael McCracken
 E: michael.mccracken@gmail.com
@@ -171,6 +203,10 @@ N: Vladimir Merzliakov
 E: wanderer@rsu.ru
 D: Test suite fixes for FreeBSD
 
+N: Scott Michel
+E: scottm@aero.org
+D: Added STI Cell SPU backend.
+
 N: Morten Ofstad
 E: morten@hue.no
 D: Visual C++ compatibility fixes 
@@ -179,7 +215,7 @@ N: Devang Patel
 E: dpatel@apple.com
 D: LTO tool, PassManager rewrite, Loop Pass Manager, Loop Rotate
 D: GCC PCH Integration (llvm-gcc), llvm-gcc improvements
-D: Optimizer improvements
+D: Optimizer improvements, Loop Index Split
 
 N: Vladimir Prus
 W: http://vladimir_prus.blogspot.com
@@ -192,12 +228,16 @@ D: MSIL backend
 
 N: Duncan Sands
 E: baldrick@free.fr
-D: Ada front-end
+D: Ada front-end, exception handling improvements
 
 N: Ruchira Sasanka
 E: sasanka@uiuc.edu
 D: Graph coloring register allocator for the Sparc64 backend
 
+N: Arnold Schwaighofer
+E: arnold.schwaighofer@gmail.com
+D: Tail call optimization for the x86 backend
+
 N: Anand Shukla
 E: ashukla@cs.uiuc.edu
 D: The `paths' pass
@@ -205,7 +245,7 @@ D: The `paths' pass
 N: Reid Spencer
 E: rspencer@reidspencer.com
 W: http://reidspencer.com/
-D: http://wiki.llvm.org/index.php/User:Reid
+D: Lots of stuff, see: http://wiki.llvm.org/index.php/User:Reid
 
 N: Adam Treat
 E: manyoso@yahoo.com
@@ -219,4 +259,6 @@ D: Thread Local Storage implementation
 N: Bill Wendling
 E: isanbard@gmail.com
 W: http://web.mac.com/bwendling/
-D: The `Lower Setjmp/Longjmp' pass, improvements to the -lowerswitch pass.
+D: Darwin exception handling
+D: MMX & SSSE3 instructions
+D: SPEC2006 support

llvm/LICENSE.TXT

@@ -4,7 +4,7 @@ LLVM Release License
 University of Illinois/NCSA
 Open Source License
 
-Copyright (c) 2003-2007 University of Illinois at Urbana-Champaign.
+Copyright (c) 2003-2008 University of Illinois at Urbana-Champaign.
 All rights reserved.
 
 Developed by:
@@ -66,4 +66,7 @@ Compiler Driver     llvm/tools/llvmc
 Autoconf            llvm/autoconf
                     llvm/projects/ModuleMaker/autoconf
                     llvm/projects/sample/autoconf
-GNU Libc            llvm/runtime/GCCLibraries/libc
+Boost C++ Libraries llvm/include : docs/BOOST_LICENSE_1_0.txt
+CellSPU backend     llvm/lib/Target/CellSPU/README.txt
+
+

llvm/Makefile

@@ -2,8 +2,8 @@
 # 
 #                     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 distributed under the University of Illinois Open Source
+# License. See LICENSE.TXT for details.
 # 
 #===------------------------------------------------------------------------===#
 
@@ -19,8 +19,8 @@ LEVEL := .
 #
 DIRS := lib/System lib/Support utils lib/VMCore lib tools/llvm-config \
         tools runtime docs
-        
-OPTIONAL_DIRS := examples projects
+
+OPTIONAL_DIRS := examples projects bindings
 EXTRA_DIST := test llvm.spec include win32 Xcode
 
 include $(LEVEL)/Makefile.config 
@@ -37,6 +37,11 @@ ifeq ($(MAKECMDGOALS),libs-only)
   OPTIONAL_DIRS :=
 endif
 
+ifeq ($(MAKECMDGOALS),install-libs)
+  DIRS := $(filter-out tools runtime docs, $(DIRS))
+  OPTIONAL_DIRS := $(filter bindings, $(OPTIONAL_DIRS))
+endif
+
 ifeq ($(MAKECMDGOALS),tools-only)
   DIRS := $(filter-out runtime docs, $(DIRS))
   OPTIONAL_DIRS :=
@@ -46,7 +51,7 @@ endif
 # build LLVM.
 ifeq ($(MAKECMDGOALS),install)
   DIRS := $(filter-out utils, $(DIRS))
-  OPTIONAL_DIRS :=
+  OPTIONAL_DIRS := $(filter bindings, $(OPTIONAL_DIRS))
 endif
 
 # Include the main makefile machinery.
@@ -81,6 +86,7 @@ dist-hook::
 
 tools-only: all
 libs-only: all
+install-libs: install
 
 #------------------------------------------------------------------------
 # Make sure the generated headers are up-to-date. This must be kept in
@@ -128,4 +134,12 @@ show-footprint:
 	$(Verb) du -sk $(ExmplDir)
 	$(Verb) du -sk $(ObjDir)
 
+build-for-llvm-top:
+	$(Verb) if test ! -f ./config.status ; then \
+	  ./configure --prefix="$(LLVM_TOP)/install" \
+	    --with-llvm-gcc="$(LLVM_TOP)/llvm-gcc" ; \
+	fi
+	$(Verb) $(MAKE) tools-only
+
 .PHONY: srpm rpm
+

llvm/Makefile.common

@@ -2,8 +2,8 @@
 # 
 #                     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 distributed under the University of Illinois Open Source
+# License. See LICENSE.TXT for details.
 # 
 #===------------------------------------------------------------------------===#
 #

llvm/Makefile.config.in

@@ -2,8 +2,8 @@
 #
 #                     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 distributed under the University of Illinois Open Source
+# License. See LICENSE.TXT for details.
 # 
 #===------------------------------------------------------------------------===#
 #
@@ -83,7 +83,7 @@ PROJ_docsdir    := $(DESTDIR)$(PROJ_prefix)/docs/llvm
 PROJ_etcdir     := $(DESTDIR)$(PROJ_prefix)/etc/llvm
 PROJ_includedir := $(DESTDIR)$(PROJ_prefix)/include
 PROJ_infodir    := $(DESTDIR)$(PROJ_prefix)/info
-PROJ_mandir     := $(DESTDIR)$(PROJ_prefix)/man
+PROJ_mandir     := $(DESTDIR)$(PROJ_prefix)/share/man
 
 # Determine if we're on a unix type operating system
 LLVM_ON_UNIX:=@LLVM_ON_UNIX@
@@ -105,9 +105,6 @@ BUILD_EXEEXT=@BUILD_EXEEXT@
 # Target triple (cpu-vendor-os) for which we should generate code
 TARGET_TRIPLE=@target@
 
-# Targets that we should build
-TARGETS_TO_BUILD=@TARGETS_TO_BUILD@
-
 # Extra options to compile LLVM with
 EXTRA_OPTIONS=@EXTRA_OPTIONS@
 
@@ -152,10 +149,11 @@ PERL       := @PERL@
 BZIP2      := @BZIP2@
 DOT        := @DOT@
 DOXYGEN    := @DOXYGEN@
-ETAGS      := @ETAGS@
-ETAGSFLAGS := @ETAGSFLAGS@
 GROFF      := @GROFF@
 GZIP       := @GZIP@
+OCAMLC     := @OCAMLC@
+OCAMLOPT   := @OCAMLOPT@
+OCAMLDEP   := @OCAMLDEP@
 POD2HTML   := @POD2HTML@
 POD2MAN    := @POD2MAN@
 RUNTEST    := @RUNTEST@
@@ -167,6 +165,9 @@ HAVE_PTHREAD := @HAVE_PTHREAD@
 
 LIBS       := @LIBS@
 
+# Targets that we should build
+TARGETS_TO_BUILD=@TARGETS_TO_BUILD@
+
 # Path to location for LLVM C/C++ front-end. You can modify this if you
 # want to override the value set by configure.
 LLVMGCCDIR := @LLVMGCCDIR@
@@ -209,6 +210,11 @@ OBJ_ROOT := .
 #DISABLE_ASSERTIONS = 1
 @DISABLE_ASSERTIONS@
 
+# When ENABLE_EXPENSIVE_CHECKS is enabled, builds of all of the LLVM
+# code will include expensive checks, otherwise they are excluded.
+#ENABLE_EXPENSIVE_CHECKS = 0
+@ENABLE_EXPENSIVE_CHECKS@
+
 # When DEBUG_RUNTIME is enabled, the runtime libraries will retain debug
 # symbols.
 #DEBUG_RUNTIME = 1
@@ -253,3 +259,17 @@ NOLINKALL := @NOLINKALL@
 # Get the value of HUGE_VAL_SANITY which will be either "yes" or "no" depending
 # on the check.
 HUGE_VAL_SANITY = @HUGE_VAL_SANITY@
+
+# Bindings that we should build
+BINDINGS_TO_BUILD := @BINDINGS_TO_BUILD@
+ALL_BINDINGS      := @ALL_BINDINGS@
+OCAML_LIBDIR      := @OCAML_LIBDIR@
+
+# When compiling under Mingw/Cygwin, executables such as tblgen
+# expect Windows paths, whereas the build system uses Unix paths.
+# The function SYSPATH transforms Unix paths into Windows paths.
+ifneq (,$(findstring -mno-cygwin, $(CXX)))
+  SYSPATH = $(shell echo $(1) | cygpath -m -f -)
+else
+  SYSPATH = $(1)
+endif

llvm/Makefile.rules

@@ -2,8 +2,8 @@
 #
 #                     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 distributed under the University of Illinois Open Source
+# License. See LICENSE.TXT for details.
 # 
 #===------------------------------------------------------------------------===#
 #
@@ -23,7 +23,7 @@ RecursiveTargets := all clean clean-all install uninstall install-bytecode
 LocalTargets     := all-local clean-local clean-all-local check-local \
                     install-local printvars uninstall-local \
 		    install-bytecode-local
-TopLevelTargets  := check dist dist-check dist-clean tags dist-gzip dist-bzip2 \
+TopLevelTargets  := check dist dist-check dist-clean dist-gzip dist-bzip2 \
                     dist-zip
 UserTargets      := $(RecursiveTargets) $(LocalTargets) $(TopLevelTargets)
 InternalTargets  := preconditions distdir dist-hook
@@ -38,7 +38,7 @@ InternalTargets  := preconditions distdir dist-hook
 VPATH=$(PROJ_SRC_DIR)
 
 #--------------------------------------------------------------------
-# Reset the list of suffixes we know how to build
+# Reset the list of suffixes we know how to build.
 #--------------------------------------------------------------------
 .SUFFIXES:
 .SUFFIXES: .c .cpp .cc .h .hpp .y .l .lo .o .a .bc .td .ps .dot .ll
@@ -199,6 +199,7 @@ install-bytecode:: install-bytecode-local
 # Variables derived from configuration we are building
 #--------------------------------------------------------------------
 
+CPP.Defines :=
 # OPTIMIZE_OPTION - The optimization level option we want to build LLVM with
 # this can be overridden on the make command line.
 ifneq ($(OS),MingW)
@@ -209,9 +210,10 @@ endif
 
 ifdef ENABLE_PROFILING
   BuildMode := Profile
-  CXX.Flags := $(OPTIMIZE_OPTION) -pg -g
-  C.Flags   := $(OPTIMIZE_OPTION) -pg -g
-  LD.Flags  := $(OPTIMIZE_OPTION) -pg -g
+  CXX.Flags += $(OPTIMIZE_OPTION) -pg -g
+  C.Flags   += $(OPTIMIZE_OPTION) -pg -g
+  LD.Flags  += $(OPTIMIZE_OPTION) -pg -g
+  KEEP_SYMBOLS := 1
 else
   ifeq ($(ENABLE_OPTIMIZED),1)
     BuildMode := Release
@@ -227,14 +229,14 @@ else
       EXTRA_OPTIONS += -fstrict-aliasing
     endif
 
-    CXX.Flags := $(OPTIMIZE_OPTION) $(OmitFramePointer)
-    C.Flags   := $(OPTIMIZE_OPTION) $(OmitFramePointer)
-    LD.Flags  := $(OPTIMIZE_OPTION)
+    CXX.Flags += $(OPTIMIZE_OPTION) $(OmitFramePointer)
+    C.Flags   += $(OPTIMIZE_OPTION) $(OmitFramePointer)
+    LD.Flags  += $(OPTIMIZE_OPTION)
   else
     BuildMode := Debug
-    CXX.Flags := -g
-    C.Flags   := -g
-    LD.Flags  := -g
+    CXX.Flags += -g
+    C.Flags   += -g
+    LD.Flags  += -g
     KEEP_SYMBOLS := 1
   endif
 endif
@@ -253,11 +255,17 @@ endif
 # then disable assertions by defining the appropriate preprocessor symbols.
 ifdef DISABLE_ASSERTIONS
   BuildMode := $(BuildMode)-Asserts
-  CXX.Flags += -DNDEBUG
-  C.Flags   += -DNDEBUG
+  CPP.Defines += -DNDEBUG
 else
-  CXX.Flags += -D_DEBUG
-  C.Flags   += -D_DEBUG
+  CPP.Defines += -D_DEBUG
+endif
+
+# If ENABLE_EXPENSIVE_CHECKS=1 is specified (make command line or 
+# configured), then enable expensive checks by defining the 
+# appropriate preprocessor symbols.
+ifdef ENABLE_EXPENSIVE_CHECKS
+  BuildMode := $(BuildMode)+Checks
+  CPP.Defines += -D_GLIBCXX_DEBUG
 endif
 
 ifeq ($(ENABLE_PIC),1)
@@ -267,7 +275,8 @@ endif
 
 CXX.Flags     += $(CXXFLAGS) -Woverloaded-virtual
 C.Flags       += $(CFLAGS)
-CPP.BaseFlags += $(CPPFLAGS)
+CPP.Defines   += $(CPPFLAGS)
+CPP.BaseFlags += $(CPP.Defines)
 LD.Flags      += $(LDFLAGS)
 AR.Flags      := cru
 LibTool.Flags := --tag=CXX
@@ -474,8 +483,14 @@ LTInstall     = $(LIBTOOL) $(LibTool.Flags) --mode=install $(INSTALL) \
 ProgInstall   = $(INSTALL) $(Install.StripFlag) -m 0755 
 ScriptInstall = $(INSTALL) -m 0755 
 DataInstall   = $(INSTALL) -m 0644
-TableGen      = $(TBLGEN) -I $(PROJ_SRC_DIR) -I$(PROJ_SRC_ROOT)/include \
-                -I $(PROJ_SRC_ROOT)/lib/Target      
+
+# When compiling under Mingw/Cygwin, the tblgen tool expects Windows
+# paths. In this case, the SYSPATH function (defined in
+# Makefile.config) transforms Unix paths into Windows paths.
+TableGen      = $(TBLGEN) -I $(call SYSPATH, $(PROJ_SRC_DIR)) \
+                -I $(call SYSPATH, $(PROJ_SRC_ROOT)/include) \
+                -I $(call SYSPATH, $(PROJ_SRC_ROOT)/lib/Target)
+
 Archive       = $(AR) $(AR.Flags)
 LArchive      = $(LLVMToolDir)/llvm-ar rcsf
 ifdef RANLIB
@@ -1070,23 +1085,28 @@ ifndef DISABLE_AUTO_DEPENDENCIES
 # Create .lo files in the ObjDir directory from the .cpp and .c files...
 #---------------------------------------------------------
 
+DEPEND_OPTIONS = -MMD -MP -MF "$(ObjDir)/$*.d.tmp" \
+         -MT "$(ObjDir)/$*.lo" -MT "$(ObjDir)/$*.o" -MT "$(ObjDir)/$*.d"
+         
+# If the build succeeded, move the dependency file over.  If it failed, put an
+# empty file there.
+DEPEND_MOVEFILE = then $(MV) -f "$(ObjDir)/$*.d.tmp" "$(ObjDir)/$*.d"; \
+                  else $(RM) "$(ObjDir)/$*.d.tmp"; exit 1; fi
+
 $(ObjDir)/%.lo $(ObjDir)/%.o: %.cpp $(ObjDir)/.dir $(BUILT_SOURCES)
 	$(Echo) "Compiling $*.cpp for $(BuildMode) build " $(PIC_FLAG)
-	$(Verb) if $(MAYBE_PIC_Compile.CXX) -MD -MT $@ -MP -MF $(ObjDir)/$*.LACXXd $< -o $@ ;\
-	  then $(MV) -f "$(ObjDir)/$*.LACXXd" "$(ObjDir)/$*.d"; \
-	  else $(RM) -f "$(ObjDir)/$*.LACXXd"; exit 1; fi
+	$(Verb) if $(MAYBE_PIC_Compile.CXX) $(DEPEND_OPTIONS) $< -o $(ObjDir)/$*.o ; \
+	        $(DEPEND_MOVEFILE)
 
 $(ObjDir)/%.lo $(ObjDir)/%.o: %.cc $(ObjDir)/.dir $(BUILT_SOURCES)
 	$(Echo) "Compiling $*.cc for $(BuildMode) build" $(PIC_FLAG)
-	$(Verb) if $(MAYBE_PIC_Compile.CXX) -MD -MT $@ -MP -MF $(ObjDir)/$*.LACXXd $< -o $@ ;\
-	then $(MV) -f "$(ObjDir)/$*.LACXXd" "$(ObjDir)/$*.d"; \
-	else $(RM) -f "$(ObjDir)/$*.LACXXd"; exit 1; fi
+	$(Verb) if $(MAYBE_PIC_Compile.CXX) $(DEPEND_OPTIONS) $< -o $(ObjDir)/$*.o ; \
+	        $(DEPEND_MOVEFILE)
 
 $(ObjDir)/%.lo $(ObjDir)/%.o: %.c $(ObjDir)/.dir $(BUILT_SOURCES)
 	$(Echo) "Compiling $*.c for $(BuildMode) build" $(PIC_FLAG)
-	$(Verb) if $(MAYBE_PIC_Compile.C) -MD -MT $@ -MP -MF $(ObjDir)/$*.LACd $< -o $@ ; \
-	then $(MV) -f "$(ObjDir)/$*.LACd" "$(ObjDir)/$*.d"; \
-	else $(RM) -f "$(ObjDir)/$*.LACd"; exit 1; fi
+	$(Verb) if $(MAYBE_PIC_Compile.C) $(DEPEND_OPTIONS) $< -o $(ObjDir)/$*.o ; \
+	        $(DEPEND_MOVEFILE)
 
 #---------------------------------------------------------
 # Create .bc files in the ObjDir directory from .cpp .cc and .c files...
@@ -1234,57 +1254,57 @@ $(INCFiles) : %.inc : $(ObjDir)/%.inc.tmp
 $(TARGET:%=$(ObjDir)/%GenRegisterNames.inc.tmp): \
 $(ObjDir)/%GenRegisterNames.inc.tmp : %.td $(ObjDir)/.dir
 	$(Echo) "Building $(<F) register names with tblgen"
-	$(Verb) $(TableGen) -gen-register-enums -o $@ $<
+	$(Verb) $(TableGen) -gen-register-enums -o $(call SYSPATH, $@) $<
 
 $(TARGET:%=$(ObjDir)/%GenRegisterInfo.h.inc.tmp): \
 $(ObjDir)/%GenRegisterInfo.h.inc.tmp : %.td $(ObjDir)/.dir
 	$(Echo) "Building $(<F) register information header with tblgen"
-	$(Verb) $(TableGen) -gen-register-desc-header -o $@ $<
+	$(Verb) $(TableGen) -gen-register-desc-header -o $(call SYSPATH, $@) $<
 
 $(TARGET:%=$(ObjDir)/%GenRegisterInfo.inc.tmp): \
 $(ObjDir)/%GenRegisterInfo.inc.tmp : %.td $(ObjDir)/.dir
 	$(Echo) "Building $(<F) register info implementation with tblgen"
-	$(Verb) $(TableGen) -gen-register-desc -o $@ $<
+	$(Verb) $(TableGen) -gen-register-desc -o $(call SYSPATH, $@) $<
 
 $(TARGET:%=$(ObjDir)/%GenInstrNames.inc.tmp): \
 $(ObjDir)/%GenInstrNames.inc.tmp : %.td $(ObjDir)/.dir
 	$(Echo) "Building $(<F) instruction names with tblgen"
-	$(Verb) $(TableGen) -gen-instr-enums -o $@ $<
+	$(Verb) $(TableGen) -gen-instr-enums -o $(call SYSPATH, $@) $<
 
 $(TARGET:%=$(ObjDir)/%GenInstrInfo.inc.tmp): \
 $(ObjDir)/%GenInstrInfo.inc.tmp : %.td $(ObjDir)/.dir
 	$(Echo) "Building $(<F) instruction information with tblgen"
-	$(Verb) $(TableGen) -gen-instr-desc -o $@ $<
+	$(Verb) $(TableGen) -gen-instr-desc -o $(call SYSPATH, $@) $<
 
 $(TARGET:%=$(ObjDir)/%GenAsmWriter.inc.tmp): \
 $(ObjDir)/%GenAsmWriter.inc.tmp : %.td $(ObjDir)/.dir
 	$(Echo) "Building $(<F) assembly writer with tblgen"
-	$(Verb) $(TableGen) -gen-asm-writer -o $@ $<
+	$(Verb) $(TableGen) -gen-asm-writer -o $(call SYSPATH, $@) $<
 
 $(TARGET:%=$(ObjDir)/%GenAsmWriter1.inc.tmp): \
 $(ObjDir)/%GenAsmWriter1.inc.tmp : %.td $(ObjDir)/.dir
 	$(Echo) "Building $(<F) assembly writer #1 with tblgen"
-	$(Verb) $(TableGen) -gen-asm-writer -asmwriternum=1 -o $@ $< 
+	$(Verb) $(TableGen) -gen-asm-writer -asmwriternum=1 -o $(call SYSPATH, $@) $< 
 
 $(TARGET:%=$(ObjDir)/%GenCodeEmitter.inc.tmp): \
 $(ObjDir)/%GenCodeEmitter.inc.tmp: %.td $(ObjDir)/.dir
 	$(Echo) "Building $(<F) code emitter with tblgen"
-	$(Verb) $(TableGen) -gen-emitter -o $@ $<
+	$(Verb) $(TableGen) -gen-emitter -o $(call SYSPATH, $@) $<
 
 $(TARGET:%=$(ObjDir)/%GenDAGISel.inc.tmp): \
 $(ObjDir)/%GenDAGISel.inc.tmp : %.td $(ObjDir)/.dir
 	$(Echo) "Building $(<F) instruction selector implementation with tblgen"
-	$(Verb) $(TableGen) -gen-dag-isel -o $@ $<
+	$(Verb) $(TableGen) -gen-dag-isel -o $(call SYSPATH, $@) $<
 
 $(TARGET:%=$(ObjDir)/%GenSubtarget.inc.tmp): \
 $(ObjDir)/%GenSubtarget.inc.tmp : %.td $(ObjDir)/.dir
 	$(Echo) "Building $(<F) subtarget information with tblgen"
-	$(Verb) $(TableGen) -gen-subtarget -o $@ $<
+	$(Verb) $(TableGen) -gen-subtarget -o $(call SYSPATH, $@) $<
 
 $(TARGET:%=$(ObjDir)/%GenCallingConv.inc.tmp): \
 $(ObjDir)/%GenCallingConv.inc.tmp : %.td $(ObjDir)/.dir
 	$(Echo) "Building $(<F) calling convention information with tblgen"
-	$(Verb) $(TableGen) -gen-callingconv -o $@ $<
+	$(Verb) $(TableGen) -gen-callingconv -o $(call SYSPATH, $@) $<
 
 clean-local::
 	-$(Verb) $(RM) -f $(INCFiles)
@@ -1359,15 +1379,12 @@ all:: $(YaccFiles:%.y=$(PROJ_SRC_DIR)/%.cpp.cvs)
 %.h: %.y
 
 # Rule for building the bison based parsers...
-$(PROJ_SRC_DIR)/%.cpp $(PROJ_SRC_DIR)/%.h : $(PROJ_SRC_DIR)/%.y
 ifneq ($(BISON),)
+$(PROJ_SRC_DIR)/%.cpp $(PROJ_SRC_DIR)/%.h : $(PROJ_SRC_DIR)/%.y
 	$(Echo) "Bisoning $*.y"
 	$(Verb) $(BISON) -v -d -p $(<F:%Parser.y=%) -o $*.tab.c $<
 	$(Verb) $(MV) -f $*.tab.c $(PROJ_SRC_DIR)/$*.cpp
 	$(Verb) $(MV) -f $*.tab.h $(PROJ_SRC_DIR)/$*.h
-else
-	$(Echo) "Bison of $*.y SKIPPED -- bison not found"
-endif
 
 # IFF the .y file has changed since it was last checked into CVS, copy the .y
 # file to .y.cvs and the generated .cpp/.h file to .cpp.cvs/.h.cvs.  We use this
@@ -1380,6 +1397,16 @@ $(PROJ_SRC_DIR)/%.cpp.cvs: $(PROJ_SRC_DIR)/%.cpp
        $(CP) $(PROJ_SRC_DIR)/$*.y $(PROJ_SRC_DIR)/$*.y.cvs; \
        $(CP) $(PROJ_SRC_DIR)/$*.h $(PROJ_SRC_DIR)/$*.h.cvs)
 
+else
+$(PROJ_SRC_DIR)/%.cpp : $(PROJ_SRC_DIR)/%.cpp.cvs
+	$(Echo) "Bison of $*.y SKIPPED, bison not found -- copying .cpp.cvs"
+	$(Verb)$(CP) $(PROJ_SRC_DIR)/$*.cpp.cvs $(PROJ_SRC_DIR)/$*.cpp
+
+$(PROJ_SRC_DIR)/%.h : $(PROJ_SRC_DIR)/%.h.cvs
+	$(Echo) "Bison of $*.y SKIPPED, bison not found -- copying .h.cvs"
+	$(Verb)$(CP) $(PROJ_SRC_DIR)/$*.h.cvs $(PROJ_SRC_DIR)/$*.h
+endif
+
 
 $(YaccFiles:%.y=$(ObjDir)/%.o): $(ObjDir)/%.o : $(PROJ_SRC_DIR)/%.cpp
 
@@ -1423,25 +1450,6 @@ endif
 clean-all-local::
 	-$(Verb) $(RM) -rf Debug Release Profile
 
-# Build tags database for Emacs/Xemacs:
-tags:: TAGS CTAGS
-
-TAGS: 
-	find $(PROJ_SRC_ROOT)/include $(PROJ_SRC_ROOT)/lib \
-          $(PROJ_SRC_ROOT)/tools $(PROJ_SRC_ROOT)/examples \
-          $(PROJ_OBJ_ROOT)/include $(PROJ_OBJ_ROOT)/lib \
-          $(PROJ_OBJ_ROOT)/tools $(PROJ_OBJ_ROOT)/examples \
-        -name '*.cpp' -o -name '*.h' | \
-        $(ETAGS) $(ETAGSFLAGS) -
-
-CTAGS:
-	find $(PROJ_SRC_ROOT)/include $(PROJ_SRC_ROOT)/lib \
-          $(PROJ_SRC_ROOT)/tools $(PROJ_SRC_ROOT)/examples \
-          $(PROJ_OBJ_ROOT)/include $(PROJ_OBJ_ROOT)/lib \
-          $(PROJ_OBJ_ROOT)/tools $(PROJ_OBJ_ROOT)/examples \
-          \( -name '*.cpp' -o -name '*.h' \) -print | \
-          ctags -ImtT -o $(PROJ_OBJ_ROOT)/CTAGS -L -
-
 
 ###############################################################################
 # DEPENDENCIES: Include the dependency files if we should
@@ -1449,13 +1457,13 @@ CTAGS:
 ifndef DISABLE_AUTO_DEPENDENCIES
 
 # If its not one of the cleaning targets
-ifneq ($(strip $(filter-out clean clean-local dist-clean,$(MAKECMDGOALS)))),)
+ifneq ($(strip $(filter-out clean clean-local dist-clean,$(MAKECMDGOALS))),)
 
 # Get the list of dependency files
 DependFiles := $(basename $(filter %.cpp %.c %.cc, $(Sources)))
 DependFiles := $(DependFiles:%=$(PROJ_OBJ_DIR)/$(BuildMode)/%.d)
 
--include /dev/null $(DependFiles)
+-include $(DependFiles) ""
 
 endif
 

llvm/ModuleInfo.txt

@@ -0,0 +1,4 @@
+DepModule: 
+BuildCmd: ./build-for-llvm-top.sh
+CleanCmd: make clean
+InstallCmd: make install

llvm/autoconf/.cvsignore

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

llvm/autoconf/AutoRegen.sh

@@ -3,16 +3,29 @@ die () {
 	echo "$@" 1>&2
 	exit 1
 }
+
+### NOTE: ############################################################"
+### The below two variables specify the auto* versions
+### periods should be escaped with backslash, for use by grep
+want_autoconf_version='2\.60'
+want_autoheader_version=$want_autoconf_version
+### END NOTE #########################################################"
+
+
 outfile=configure
 configfile=configure.ac
+
+want_autoconf_version_clean=`echo $want_autoconf_version | sed -e 's/\\\\//g'`
+want_autoheader_version_clean=`echo $want_autoheader_version | sed -e 's/\\\\//g'`
+
 test -d autoconf && test -f autoconf/$configfile && cd autoconf
 test -f $configfile || die "Can't find 'autoconf' dir; please cd into it first"
-autoconf --version | grep '2\.60' > /dev/null
-test $? -eq 0 || die "Your autoconf was not detected as being 2.60"
+autoconf --version | grep $want_autoconf_version > /dev/null
+test $? -eq 0 || die "Your autoconf was not detected as being $want_autoconf_version_clean"
 aclocal --version | grep '^aclocal.*1\.9\.6' > /dev/null
 test $? -eq 0 || die "Your aclocal was not detected as being 1.9.6"
-autoheader --version | grep '^autoheader.*2\.60' > /dev/null
-test $? -eq 0 || die "Your autoheader was not detected as being 2.60"
+autoheader --version | grep '^autoheader.*'$want_autoheader_version > /dev/null
+test $? -eq 0 || die "Your autoheader was not detected as being $want_autoheader_version_clean"
 libtool --version | grep '1\.5\.22' > /dev/null
 test $? -eq 0 || die "Your libtool was not detected as being 1.5.22"
 echo ""
@@ -27,9 +40,9 @@ echo ""
 echo "Regenerating aclocal.m4 with aclocal 1.9.6"
 cwd=`pwd`
 aclocal --force -I $cwd/m4 || die "aclocal failed"
-echo "Regenerating configure with autoconf 2.60"
+echo "Regenerating configure with autoconf $want_autoconf_version_clean"
 autoconf --force --warnings=all -o ../$outfile $configfile || die "autoconf failed"
 cd ..
-echo "Regenerating config.h.in with autoheader 2.60"
+echo "Regenerating config.h.in with autoheader $want_autoheader_version_clean"
 autoheader --warnings=all -I autoconf -I autoconf/m4 autoconf/$configfile || die "autoheader failed"
 exit 0

llvm/autoconf/configure.ac

@@ -1,12 +1,12 @@
 dnl === configure.ac --------------------------------------------------------===
 dnl                     The LLVM Compiler Infrastructure
 dnl
-dnl This file was developed by the LLVM research group and is distributed under
-dnl the University of Illinois Open Source License. See LICENSE.TXT for details.
-dnl 
+dnl This file is distributed under the University of Illinois Open Source
+dnl License. See LICENSE.TXT for details.
+dnl
 dnl===-----------------------------------------------------------------------===
 dnl This is the LLVM configuration script. It is processed by the autoconf
-dnl program to produce a script named configure. This script contains the 
+dnl program to produce a script named configure. This script contains the
 dnl configuration checks that LLVM needs in order to support multiple platforms.
 dnl This file is composed of 10 sections per the recommended organization of
 dnl autoconf input defined in the autoconf documentation. As this file evolves,
@@ -31,12 +31,12 @@ dnl===
 dnl===-----------------------------------------------------------------------===
 dnl Initialize autoconf and define the package name, version number and
 dnl email address for reporting bugs.
-AC_INIT([[llvm]],[[2.0cvs]],[llvmbugs@cs.uiuc.edu])
+AC_INIT([[llvm]],[[2.2]],[llvmbugs@cs.uiuc.edu])
 
 dnl Provide a copyright substitution and ensure the copyright notice is included
 dnl in the output of --version option of the generated configure script.
-AC_SUBST(LLVM_COPYRIGHT,["Copyright (c) 2003-2007 University of Illinois at Urbana-Champaign."])
-AC_COPYRIGHT([Copyright (c) 2003-2007 University of Illinois at Urbana-Champaign.])
+AC_SUBST(LLVM_COPYRIGHT,["Copyright (c) 2003-2008 University of Illinois at Urbana-Champaign."])
+AC_COPYRIGHT([Copyright (c) 2003-2008 University of Illinois at Urbana-Champaign.])
 
 dnl Indicate that we require autoconf 2.59 or later. Ths is needed because we
 dnl use some autoconf macros only available in 2.59.
@@ -46,8 +46,8 @@ dnl Verify that the source directory is valid. This makes sure that we are
 dnl configuring LLVM and not some other package (it validates --srcdir argument)
 AC_CONFIG_SRCDIR([lib/VMCore/Module.cpp])
 
-dnl Place all of the extra autoconf files into the config subdirectory. Tell 
-dnl various tools where the m4 autoconf macros are. 
+dnl Place all of the extra autoconf files into the config subdirectory. Tell
+dnl various tools where the m4 autoconf macros are.
 AC_CONFIG_AUX_DIR([autoconf])
 
 dnl Quit if the source directory has already been configured.
@@ -76,8 +76,9 @@ do
       llvm-java)    AC_CONFIG_SUBDIRS([projects/llvm-java]) ;;
       llvm-tv)      AC_CONFIG_SUBDIRS([projects/llvm-tv])   ;;
       llvm-poolalloc) AC_CONFIG_SUBDIRS([projects/llvm-poolalloc]) ;;
+      poolalloc)    AC_CONFIG_SUBDIRS([projects/poolalloc]) ;;
       llvm-kernel)  AC_CONFIG_SUBDIRS([projects/llvm-kernel]) ;;
-      *)              
+      *)
         AC_MSG_WARN([Unknown project (${i}) won't be configured automatically])
         ;;
     esac
@@ -91,8 +92,8 @@ dnl===
 dnl===-----------------------------------------------------------------------===
 
 dnl Check the target for which we're compiling and the host that will do the
-dnl compilations. This will tell us which LLVM compiler will be used for 
-dnl compiling SSA into object code. This needs to be done early because 
+dnl compilations. This will tell us which LLVM compiler will be used for
+dnl compiling SSA into object code. This needs to be done early because
 dnl following tests depend on it.
 AC_CANONICAL_TARGET
 
@@ -101,75 +102,75 @@ dnl the System library to the correct build platform.
 AC_CACHE_CHECK([type of operating system we're going to host on],
                [llvm_cv_os_type],
 [case $host in
-  *-*-aix*) 
+  *-*-aix*)
     llvm_cv_link_all_option="-Wl,--whole-archive"
     llvm_cv_no_link_all_option="-Wl,--no-whole-archive"
-    llvm_cv_os_type="AIX" 
+    llvm_cv_os_type="AIX"
     llvm_cv_platform_type="Unix" ;;
-  *-*-irix*) 
+  *-*-irix*)
     llvm_cv_link_all_option="-Wl,--whole-archive"
     llvm_cv_no_link_all_option="-Wl,--no-whole-archive"
-    llvm_cv_os_type="IRIX" 
+    llvm_cv_os_type="IRIX"
     llvm_cv_platform_type="Unix" ;;
-  *-*-cygwin*) 
+  *-*-cygwin*)
     llvm_cv_link_all_option="-Wl,--whole-archive"
     llvm_cv_no_link_all_option="-Wl,--no-whole-archive"
-    llvm_cv_os_type="Cygwin" 
+    llvm_cv_os_type="Cygwin"
     llvm_cv_platform_type="Unix" ;;
-  *-*-darwin*) 
+  *-*-darwin*)
     llvm_cv_link_all_option="-Wl,-all_load"
     llvm_cv_link_all_option="-Wl,-noall_load"
     llvm_cv_os_type="Darwin"
     llvm_cv_platform_type="Unix" ;;
-  *-*-freebsd*) 
+  *-*-freebsd*)
     llvm_cv_link_all_option="-Wl,--whole-archive"
     llvm_cv_no_link_all_option="-Wl,--no-whole-archive"
-    llvm_cv_os_type="FreeBSD" 
+    llvm_cv_os_type="FreeBSD"
     llvm_cv_platform_type="Unix" ;;
-  *-*-openbsd*) 
+  *-*-openbsd*)
     llvm_cv_link_all_option="-Wl,--whole-archive"
     llvm_cv_no_link_all_option="-Wl,--no-whole-archive"
-    llvm_cv_os_type="OpenBSD" 
+    llvm_cv_os_type="OpenBSD"
     llvm_cv_platform_type="Unix" ;;
-  *-*-netbsd*) 
+  *-*-netbsd*)
     llvm_cv_link_all_option="-Wl,--whole-archive"
     llvm_cv_no_link_all_option="-Wl,--no-whole-archive"
-    llvm_cv_os_type="NetBSD" 
+    llvm_cv_os_type="NetBSD"
     llvm_cv_platform_type="Unix" ;;
-  *-*-hpux*) 
+  *-*-hpux*)
     llvm_cv_link_all_option="-Wl,--whole-archive"
     llvm_cv_no_link_all_option="-Wl,--no-whole-archive"
-    llvm_cv_os_type="HP-UX" 
+    llvm_cv_os_type="HP-UX"
     llvm_cv_platform_type="Unix" ;;
-  *-*-interix*) 
+  *-*-interix*)
     llvm_cv_link_all_option="-Wl,--whole-archive"
     llvm_cv_no_link_all_option="-Wl,--no-whole-archive"
     llvm_cv_os_type="Interix"
     llvm_cv_platform_type="Unix" ;;
-  *-*-linux*) 
+  *-*-linux*)
     llvm_cv_link_all_option="-Wl,--whole-archive"
     llvm_cv_no_link_all_option="-Wl,--no-whole-archive"
     llvm_cv_os_type="Linux"
     llvm_cv_platform_type="Unix" ;;
-  *-*-solaris*) 
+  *-*-solaris*)
     llvm_cv_link_all_option="-Wl,-z,allextract"
     llvm_cv_no_link_all_option="-Wl,-z,defaultextract"
     llvm_cv_os_type="SunOS"
     llvm_cv_platform_type="Unix" ;;
-  *-*-win32*) 
+  *-*-win32*)
     llvm_cv_link_all_option="-Wl,--whole-archive"
     llvm_cv_no_link_all_option="-Wl,--no-whole-archive"
     llvm_cv_os_type="Win32"
     llvm_cv_platform_type="Win32" ;;
-  *-*-mingw*) 
+  *-*-mingw*)
     llvm_cv_link_all_option="-Wl,--whole-archive"
     llvm_cv_no_link_all_option="-Wl,--no-whole-archive"
-    llvm_cv_os_type="MingW" 
+    llvm_cv_os_type="MingW"
     llvm_cv_platform_type="Win32" ;;
-  *) 
-    llvm_cv_link_all_option="" 
+  *)
+    llvm_cv_link_all_option=""
     llvm_cv_no_link_all_option=""
-    llvm_cv_os_type="Unknown" 
+    llvm_cv_os_type="Unknown"
     llvm_cv_platform_type="Unknown" ;;
 esac])
 
@@ -190,13 +191,13 @@ dnl Set the "LLVM_ON_*" variables based on llvm_cvs_platform_type
 dnl This is used by lib/System to determine the basic kind of implementation
 dnl to use.
 case $llvm_cv_platform_type in
-  Unix)  
-    AC_DEFINE([LLVM_ON_UNIX],[1],[Define if this is Unixish platform]) 
+  Unix)
+    AC_DEFINE([LLVM_ON_UNIX],[1],[Define if this is Unixish platform])
     AC_SUBST(LLVM_ON_UNIX,[1])
     AC_SUBST(LLVM_ON_WIN32,[0])
     ;;
-  Win32) 
-    AC_DEFINE([LLVM_ON_WIN32],[1],[Define if this is Win32ish platform]) 
+  Win32)
+    AC_DEFINE([LLVM_ON_WIN32],[1],[Define if this is Win32ish platform])
     AC_SUBST(LLVM_ON_UNIX,[0])
     AC_SUBST(LLVM_ON_WIN32,[1])
     ;;
@@ -214,6 +215,7 @@ AC_CACHE_CHECK([target architecture],[llvm_cv_target_arch],
   alpha*-*)               llvm_cv_target_arch="Alpha" ;;
   ia64-*)                 llvm_cv_target_arch="IA64" ;;
   arm-*)                  llvm_cv_target_arch="ARM" ;;
+  mips-*)                 llvm_cv_target_arch="Mips" ;;
   *)                      llvm_cv_target_arch="Unknown" ;;
 esac])
 
@@ -229,15 +231,15 @@ AC_C_BIGENDIAN(AC_SUBST([ENDIAN],[big]),AC_SUBST([ENDIAN],[little]))
 
 dnl Check for build platform executable suffix if we're crosscompiling
 if test "$cross_compiling" = yes; then
-  AC_SUBST(LLVM_CROSS_COMPILING, [1])  
+  AC_SUBST(LLVM_CROSS_COMPILING, [1])
   AC_BUILD_EXEEXT
 else
   AC_SUBST(LLVM_CROSS_COMPILING, [0])
 fi
 
-dnl Check to see if there's a "CVS" (or .svn) directory indicating that this 
+dnl Check to see if there's a "CVS" (or .svn) directory indicating that this
 dnl build is being done from a checkout. This sets up several defaults for the
-dnl command line switches. When we build with a CVS directory, we get a 
+dnl command line switches. When we build with a CVS directory, we get a
 dnl debug with assertions turned on. Without, we assume a source release and we
 dnl get an optimized build without assertions. See --enable-optimized and
 dnl --enable-assertions below
@@ -274,6 +276,17 @@ else
   AC_SUBST(DISABLE_ASSERTIONS,[[DISABLE_ASSERTIONS=1]])
 fi
 
+dnl --enable-expensive-checks : check whether they want to turn on expensive debug checks:
+AC_ARG_ENABLE(expensive-checks,AS_HELP_STRING(
+  [--enable-expensive-checks,Compile with expensive debug checks enabled (default is NO)]),, enableval="no")
+if test ${enableval} = "yes" ; then
+  AC_SUBST(ENABLE_EXPENSIVE_CHECKS,[[ENABLE_EXPENSIVE_CHECKS=1]])
+  AC_SUBST(EXPENSIVE_CHECKS,[[yes]])
+else
+  AC_SUBST(ENABLE_EXPENSIVE_CHECKS,[[]])
+  AC_SUBST(EXPENSIVE_CHECKS,[[no]])
+fi
+
 dnl --enable-debug-runtime : should runtime libraries have debug symbols?
 AC_ARG_ENABLE(debug-runtime,
    AS_HELP_STRING([--enable-debug-runtime,Build runtime libs with debug symbols (default is NO)]),,enableval=no)
@@ -300,6 +313,7 @@ else
     Alpha)   AC_SUBST(TARGET_HAS_JIT,1) ;;
     IA64)    AC_SUBST(TARGET_HAS_JIT,0) ;;
     ARM)     AC_SUBST(TARGET_HAS_JIT,0) ;;
+    Mips)    AC_SUBST(TARGET_HAS_JIT,0) ;;
     *)       AC_SUBST(TARGET_HAS_JIT,0) ;;
   esac
 fi
@@ -349,7 +363,7 @@ AC_ARG_ENABLE([targets],AS_HELP_STRING([--enable-targets],
     [Build specific host targets: all,host-only,{target-name} (default=all)]),,
     enableval=all)
 case "$enableval" in
-  all) TARGETS_TO_BUILD="X86 Sparc PowerPC Alpha IA64 ARM" ;;
+  all) TARGETS_TO_BUILD="X86 Sparc PowerPC Alpha IA64 ARM Mips CellSPU CBackend MSIL" ;;
   host-only)
     case "$llvm_cv_target_arch" in
       x86)     TARGETS_TO_BUILD="X86" ;;
@@ -359,8 +373,10 @@ case "$enableval" in
       Alpha)   TARGETS_TO_BUILD="Alpha" ;;
       IA64)    TARGETS_TO_BUILD="IA64" ;;
       ARM)     TARGETS_TO_BUILD="ARM" ;;
+      Mips)    TARGETS_TO_BUILD="Mips" ;;
+      CellSPU|SPU) TARGETS_TO_BUILD="CellSPU" ;;
       *)       AC_MSG_ERROR([Can not set target to build]) ;;
-    esac 
+    esac
     ;;
   *)for a_target in `echo $enableval|sed -e 's/,/ /g' ` ; do
       case "$a_target" in
@@ -371,12 +387,15 @@ case "$enableval" in
         alpha)   TARGETS_TO_BUILD="Alpha $TARGETS_TO_BUILD" ;;
         ia64)    TARGETS_TO_BUILD="IA64 $TARGETS_TO_BUILD" ;;
         arm)     TARGETS_TO_BUILD="ARM $TARGETS_TO_BUILD" ;;
+        mips)    TARGETS_TO_BUILD="Mips $TARGETS_TO_BUILD" ;;
+        spu)     TARGETS_TO_BUILD="CellSPU $TARGETS_TO_BUILD" ;;
+        cbe)     TARGETS_TO_BUILD="CBackend $TARGETS_TO_BUILD" ;;
+        msil)    TARGETS_TO_BUILD="MSIL $TARGETS_TO_BUILD" ;;
         *) AC_MSG_ERROR([Unrecognized target $a_target]) ;;
       esac
-  done 
+  done
   ;;
 esac
-TARGETS_TO_BUILD="CBackend MSIL $TARGETS_TO_BUILD"
 AC_SUBST(TARGETS_TO_BUILD,$TARGETS_TO_BUILD)
 
 dnl Prevent the CBackend from using printf("%a") for floating point so older
@@ -405,6 +424,28 @@ case "$withval" in
   *) AC_MSG_ERROR([Invalid path for --with-llvmgccdir. Provide full path]) ;;
 esac
 
+dnl Allow a specific llvm-gcc compiler to be used with this LLVM config.
+AC_ARG_WITH(llvmgcc,
+  AS_HELP_STRING([--with-llvmgcc],
+    [Specify location of llvm-gcc driver (default searches PATH)]),
+    LLVMGCC=$with_llvmgcc
+      WITH_LLVMGCCDIR="",)
+
+dnl Allow a specific llvm-g++ compiler to be used with this LLVM config.
+AC_ARG_WITH(llvmgxx,
+  AS_HELP_STRING([--with-llvmgxx],
+    [Specify location of llvm-g++ driver (default searches PATH)]),
+    LLVMGXX=$with_llvmgxx
+    WITH_LLVMGCCDIR="",)
+
+if test -n "$LLVMGCC" && test -z "$LLVMGXX"; then
+   AC_MSG_ERROR([Invalid llvm-g++. Use --with-llvmgxx when --with-llvmgcc is used]);
+fi
+
+if test -n "$LLVMGXX" && test -z "$LLVMGCC"; then
+   AC_MSG_ERROR([Invalid llvm-gcc. Use --with-llvmgcc when --with-llvmgxx is used]);
+fi
+
 dnl Specify extra build options
 AC_ARG_WITH(extra-options,
   AS_HELP_STRING([--with-extra-options],
@@ -416,6 +457,38 @@ case "$withval" in
 esac
 AC_SUBST(EXTRA_OPTIONS,$EXTRA_OPTIONS)
 
+dnl Allow specific bindings to be specified for building (or not)
+AC_ARG_ENABLE([bindings],AS_HELP_STRING([--enable-bindings],
+    [Build specific language bindings: all,auto,none,{binding-name} (default=auto)]),,
+    enableval=default)
+BINDINGS_TO_BUILD=""
+case "$enableval" in
+  yes | default | auto) BINDINGS_TO_BUILD="auto" ;;
+  all ) BINDINGS_TO_BUILD="ocaml" ;;
+  none | no) BINDINGS_TO_BUILD="" ;;
+  *)for a_binding in `echo $enableval|sed -e 's/,/ /g' ` ; do
+      case "$a_binding" in
+        ocaml) BINDINGS_TO_BUILD="ocaml $BINDINGS_TO_BUILD" ;;
+        *) AC_MSG_ERROR([Unrecognized binding $a_binding]) ;;
+      esac
+  done
+  ;;
+esac
+
+dnl Allow the ocaml libdir to be overridden. This could go in a configure
+dnl script for bindings/ocaml/configure, except that its auto value depends on
+dnl OCAMLC, which is found here to support tests.
+AC_ARG_WITH([ocaml-libdir],
+  [AS_HELP_STRING([--with-ocaml-libdir],
+    [Specify install location for ocaml bindings (default is stdlib)])],
+  [],
+  [withval=auto])
+case "$withval" in
+  auto) with_ocaml_libdir="$withval" ;;
+  /* | [[A-Za-z]]:[[\\/]]*) with_ocaml_libdir="$withval" ;;
+  *) AC_MSG_ERROR([Invalid path for --with-ocaml-libdir. Provide full path]) ;;
+esac
+
 dnl===-----------------------------------------------------------------------===
 dnl===
 dnl=== SECTION 4: Check for programs we need and that they are the right version
@@ -495,6 +568,7 @@ LLVM_PROG_PERL([5.006])
 AC_SUBST(PERL)
 if test x"$PERL" = xnone; then
    AC_SUBST(HAVE_PERL,0)
+   AC_MSG_ERROR([perl is required but was not found, please install it])
 else
    AC_SUBST(HAVE_PERL,1)
 fi
@@ -504,8 +578,8 @@ AC_PROG_INSTALL
 
 dnl Checks for documentation and testing tools that we can do without. If these
 dnl are not found then they are set to "true" which always succeeds but does
-dnl nothing. This just lets the build output show that we could have done 
-dnl something if the tool was available. 
+dnl nothing. This just lets the build output show that we could have done
+dnl something if the tool was available.
 AC_PATH_PROG(BZIP2,[bzip2],[echo "Skipped: bzip2 not found"])
 AC_PATH_PROG(DOXYGEN,[doxygen],[echo "Skipped: doxygen not found"])
 AC_PATH_PROG(GROFF,[groff],[echo "Skipped: groff not found"])
@@ -515,6 +589,9 @@ AC_PATH_PROG(POD2MAN,[pod2man],[echo "Skipped: pod2man not found"])
 AC_PATH_PROG(RUNTEST,[runtest],[echo "Skipped: runtest not found"])
 DJ_AC_PATH_TCLSH
 AC_PATH_PROG(ZIP,[zip],[echo "Skipped: zip not found"])
+AC_PATH_PROG(OCAMLC,[ocamlc],[echo "Skipped: ocamlc not found"])
+AC_PATH_PROG(OCAMLOPT,[ocamlopt],[echo "Skipped: ocamlopt not found"])
+AC_PATH_PROG(OCAMLDEP,[ocamldep],[echo "Skipped: ocamldep not found"])
 
 dnl Determine if the linker supports the -R option.
 AC_LINK_USE_R
@@ -531,27 +608,22 @@ if test "$lt_cv_dlopen_self" = "yes" ; then
               [Define if dlopen(0) will open the symbols of the program])
 fi
 
-dnl Check if we know how to tell etags we are using C++:
-etags_version=`$ETAGS --version 2>&1`
-case "$etags_version" in
-	*[Ee]xuberant*) ETAGSFLAGS="--language-force=c++" ;;
-	*GNU\ Emacs*) ETAGSFLAGS="-l c++" ;;
-	*) ETAGSFLAGS="" ;;
-esac
-AC_SUBST(ETAGSFLAGS,$ETAGSFLAGS)
-
 if test "$WITH_LLVMGCCDIR" = "default" ; then
   LLVMGCC="llvm-gcc${EXEEXT}"
   LLVMGXX="llvm-g++${EXEEXT}"
   AC_PATH_PROG(LLVMGCC, $LLVMGCC, [])
   AC_PATH_PROG(LLVMGXX, $LLVMGXX, [])
 else
-  LLVMGCC="$WITH_LLVMGCCDIR/bin/llvm-gcc${EXEEXT}"
-  LLVMGXX="$WITH_LLVMGCCDIR/bin/llvm-g++${EXEEXT}"
+  if test -z "$LLVMGCC"; then
+    LLVMGCC="$WITH_LLVMGCCDIR/bin/llvm-gcc${EXEEXT}"
+  fi
+  if test -z "$LLVMGXX"; then
+    LLVMGXX="$WITH_LLVMGCCDIR/bin/llvm-g++${EXEEXT}"
+  fi
   AC_SUBST(LLVMGCC,$LLVMGCC)
   AC_SUBST(LLVMGXX,$LLVMGXX)
 fi
-  
+
 AC_MSG_CHECKING([tool compatibility])
 
 dnl Ensure that compilation tools are GCC or a GNU compatible compiler such as
@@ -562,7 +634,7 @@ dnl "icc -no-gcc" emits no gcc signature BUT is still compatible
 ICC=no
 IXX=no
 case $CC in
-  icc*|icpc*) 
+  icc*|icpc*)
     ICC=yes
     IXX=yes
     ;;
@@ -584,7 +656,7 @@ fi
 dnl Verify that GCC is version 3.0 or higher
 if test "$GCC" = "yes"
 then
-  gccmajor=`$CC --version | head -n 1 | sed 's/[[^0-9]]*\([[0-9.]]\).*/\1/'` 
+  gccmajor=`$CC --version | head -n 1 | sed 's/[[^0-9]]*\([[0-9.]]\).*/\1/'`
   if test "$gccmajor" -lt "3"
   then
     AC_MSG_ERROR([gcc 3.x required, but you have a lower version])
@@ -617,7 +689,7 @@ fi
 dnl lt_dlopen may be required for plugin support.
 AC_SEARCH_LIBS(lt_dlopen,ltdl,AC_DEFINE([HAVE_LT_DLOPEN],[1],
               [Define if lt_dlopen() is available on this platform]),
-              AC_MSG_WARN([lt_dlopen() not found - plugin support might 
+              AC_MSG_WARN([lt_dlopen() not found - plugin support might
                            not be available]))
 
 dnl dlopen() is required for plugin support.
@@ -676,10 +748,11 @@ AC_HEADER_TIME
 
 AC_CHECK_HEADERS([dlfcn.h execinfo.h fcntl.h inttypes.h limits.h link.h])
 AC_CHECK_HEADERS([malloc.h setjmp.h signal.h stdint.h unistd.h utime.h])
-AC_CHECK_HEADERS([windows.h sys/mman.h sys/param.h sys/resource.h sys/time.h])
+AC_CHECK_HEADERS([windows.h])
+AC_CHECK_HEADERS([sys/mman.h sys/param.h sys/resource.h sys/time.h])
 AC_CHECK_HEADERS([sys/types.h malloc/malloc.h mach/mach.h])
 if test "$ENABLE_THREADS" -eq 1 ; then
-  AC_CHECK_HEADER(pthread.h,
+  AC_CHECK_HEADERS(pthread.h,
                   AC_SUBST(HAVE_PTHREAD, 1),
 		   AC_SUBST(HAVE_PTHREAD, 0))
 else
@@ -709,7 +782,8 @@ dnl===
 dnl===-----------------------------------------------------------------------===
 
 AC_CHECK_FUNCS([backtrace ceilf floorf roundf rintf nearbyintf getcwd ])
-AC_CHECK_FUNCS([getpagesize getrusage getrlimit setrlimit gettimeofday])
+AC_CHECK_FUNCS([powf fmodf strtof round ])
+AC_CHECK_FUNCS([getpagesize getrusage getrlimit setrlimit gettimeofday ])
 AC_CHECK_FUNCS([isatty mkdtemp mkstemp ])
 AC_CHECK_FUNCS([mktemp realpath sbrk setrlimit strdup strerror strerror_r ])
 AC_CHECK_FUNCS([strtoll strtoq sysconf malloc_zone_statistics ])
@@ -728,11 +802,11 @@ AC_CXX_HAVE_FWD_ITERATOR
 AC_FUNC_ISNAN
 AC_FUNC_ISINF
 
-dnl Check for mmap support.We also need to know if /dev/zero is required to 
-dnl be opened for allocating RWX memory.  
+dnl Check for mmap support.We also need to know if /dev/zero is required to
+dnl be opened for allocating RWX memory.
 dnl Make sure we aren't attempting to configure for an unknown system
 if test "$llvm_cv_platform_type" = "Unix" ; then
-  AC_FUNC_MMAP 
+  AC_FUNC_MMAP
   AC_FUNC_MMAP_FILE
   AC_NEED_DEV_ZERO_FOR_MMAP
 
@@ -752,6 +826,9 @@ dnl=== SECTION 9: Additional checks, variables, etc.
 dnl===
 dnl===-----------------------------------------------------------------------===
 
+dnl Check, whether __dso_handle is present
+AC_CHECK_FUNCS([__dso_handle])
+
 dnl See if the llvm-gcc executable can compile to LLVM assembly
 AC_CACHE_CHECK([whether llvm-gcc is sane],[llvm_cv_llvmgcc_sanity],
 [llvm_cv_llvmgcc_sanity="no"
@@ -765,7 +842,7 @@ if test -x "$LLVMGCC" ; then
   rm conftest.c
 fi])
 
-dnl Since we have a sane llvm-gcc, identify it and its sub-tools 
+dnl Since we have a sane llvm-gcc, identify it and its sub-tools
 if test "$llvm_cv_llvmgcc_sanity" = "yes" ; then
   AC_MSG_CHECKING([llvm-gcc component support])
   llvmcc1path=`"$LLVMGCC" --print-prog-name=cc1`
@@ -785,12 +862,12 @@ if test "$llvm_cv_llvmgcc_sanity" = "yes" ; then
   AC_MSG_RESULT([ok])
 fi
 
-dnl Propagate the shared library extension that the libltdl checks did to 
+dnl Propagate the shared library extension that the libltdl checks did to
 dnl the Makefiles so we can use it there too
 AC_SUBST(SHLIBEXT,$libltdl_cv_shlibext)
 
 # Translate the various configuration directories and other basic
-# information into substitutions that will end up in Makefile.config.in 
+# information into substitutions that will end up in Makefile.config.in
 # that these configured values can be used by the makefiles
 if test "${prefix}" = "NONE" ; then
   prefix="/usr/local"
@@ -818,26 +895,79 @@ AC_SUBST(LLVM_CONFIGTIME)
 
 # Place the various directores into the config.h file as #defines so that we
 # can know about the installation paths within LLVM.
-AC_DEFINE_UNQUOTED(LLVM_PREFIX,"$LLVM_PREFIX", 
+AC_DEFINE_UNQUOTED(LLVM_PREFIX,"$LLVM_PREFIX",
                    [Installation prefix directory])
-AC_DEFINE_UNQUOTED(LLVM_BINDIR, "$LLVM_BINDIR", 
+AC_DEFINE_UNQUOTED(LLVM_BINDIR, "$LLVM_BINDIR",
                    [Installation directory for binary executables])
-AC_DEFINE_UNQUOTED(LLVM_LIBDIR, "$LLVM_LIBDIR", 
+AC_DEFINE_UNQUOTED(LLVM_LIBDIR, "$LLVM_LIBDIR",
                    [Installation directory for libraries])
-AC_DEFINE_UNQUOTED(LLVM_DATADIR, "$LLVM_DATADIR", 
+AC_DEFINE_UNQUOTED(LLVM_DATADIR, "$LLVM_DATADIR",
                    [Installation directory for data files])
-AC_DEFINE_UNQUOTED(LLVM_DATADIR, "$LLVM_DOCSDIR", 
+AC_DEFINE_UNQUOTED(LLVM_DOCSDIR, "$LLVM_DOCSDIR",
                    [Installation directory for documentation])
-AC_DEFINE_UNQUOTED(LLVM_ETCDIR, "$LLVM_ETCDIR", 
+AC_DEFINE_UNQUOTED(LLVM_ETCDIR, "$LLVM_ETCDIR",
                    [Installation directory for config files])
-AC_DEFINE_UNQUOTED(LLVM_INCLUDEDIR, "$LLVM_INCLUDEDIR", 
+AC_DEFINE_UNQUOTED(LLVM_INCLUDEDIR, "$LLVM_INCLUDEDIR",
                    [Installation directory for include files])
-AC_DEFINE_UNQUOTED(LLVM_INFODIR, "$LLVM_INFODIR", 
+AC_DEFINE_UNQUOTED(LLVM_INFODIR, "$LLVM_INFODIR",
                    [Installation directory for .info files])
-AC_DEFINE_UNQUOTED(LLVM_MANDIR, "$LLVM_MANDIR", 
+AC_DEFINE_UNQUOTED(LLVM_MANDIR, "$LLVM_MANDIR",
                    [Installation directory for man pages])
-AC_DEFINE_UNQUOTED(LLVM_CONFIGTIME, "$LLVM_CONFIGTIME", 
+AC_DEFINE_UNQUOTED(LLVM_CONFIGTIME, "$LLVM_CONFIGTIME",
                    [Time at which LLVM was configured])
+AC_DEFINE_UNQUOTED(LLVM_HOSTTRIPLE, "$host",
+	 	   [Host triple we were built on])
+
+# Determine which bindings to build.
+if test "$BINDINGS_TO_BUILD" = auto ; then
+  BINDINGS_TO_BUILD=""
+  if test "x$OCAMLC" != x -a "x$OCAMLDEP" != x ; then
+    BINDINGS_TO_BUILD="ocaml $BINDINGS_TO_BUILD"
+  fi
+fi
+AC_SUBST(BINDINGS_TO_BUILD,$BINDINGS_TO_BUILD)
+
+# This isn't really configurey, but it avoids having to repeat the list in
+# other files.
+AC_SUBST(ALL_BINDINGS,ocaml)
+
+# Do any work necessary to ensure that bindings have what they need.
+binding_prereqs_failed=0
+for a_binding in $BINDINGS_TO_BUILD ; do
+  case "$a_binding" in
+  ocaml)
+    if test "x$OCAMLC" = x ; then
+      AC_MSG_WARN([--enable-bindings=ocaml specified, but ocamlc not found. Try configure OCAMLC=/path/to/ocamlc])
+      binding_prereqs_failed=1
+    fi
+    if test "x$OCAMLDEP" = x ; then
+      AC_MSG_WARN([--enable-bindings=ocaml specified, but ocamldep not found. Try configure OCAMLDEP=/path/to/ocamldep])
+      binding_prereqs_failed=1
+    fi
+    if test "x$OCAMLOPT" = x ; then
+      AC_MSG_WARN([--enable-bindings=ocaml specified, but ocamlopt not found. Try configure OCAMLOPT=/path/to/ocamlopt])
+      dnl ocamlopt is optional!
+    fi
+    if test "x$with_ocaml_libdir" != xauto ; then
+      AC_SUBST(OCAML_LIBDIR,$with_ocaml_libdir)
+    else
+      ocaml_stdlib="`"$OCAMLC" -where`"
+      if test "$LLVM_PREFIX" '<' "$ocaml_stdlib" -a "$ocaml_stdlib" '<' "$LLVM_PREFIX~"
+      then
+        # ocaml stdlib is beneath our prefix; use stdlib
+        AC_SUBST(OCAML_LIBDIR,$ocaml_stdlib)
+      else
+        # ocaml stdlib is outside our prefix; use libdir/ocaml
+        AC_SUBST(OCAML_LIBDIR,$LLVM_LIBDIR/ocaml)
+      fi
+    fi
+    ;;
+  esac
+done
+if test "$binding_prereqs_failed" = 1 ; then
+  AC_MSG_ERROR([Prequisites for bindings not satisfied. Fix them or use configure --disable-bindings.])
+fi
+
 
 dnl===-----------------------------------------------------------------------===
 dnl===
@@ -880,7 +1010,8 @@ AC_CONFIG_MAKEFILE(test/Makefile.tests)
 AC_CONFIG_MAKEFILE(tools/Makefile)
 AC_CONFIG_MAKEFILE(utils/Makefile)
 AC_CONFIG_MAKEFILE(projects/Makefile)
+AC_CONFIG_MAKEFILE(bindings/Makefile)
+AC_CONFIG_MAKEFILE(bindings/ocaml/Makefile.ocaml)
 
 dnl Finally, crank out the output
 AC_OUTPUT
-

llvm/autoconf/m4/libtool.m4

@@ -1905,7 +1905,7 @@ AC_DEFUN([AC_LIBTOOL_WIN32_DLL],
 AC_DEFUN([AC_ENABLE_SHARED],
 [define([enable_shared_default], ifelse($1, no, no, yes))dnl
 AC_ARG_ENABLE([shared],
-    [AS_HELP_STRING([--enable-shared@<:@=PKGS@:>@],[build shared libraries @<:@default=enable_shared_default@:>@])],
+    AS_HELP_STRING([--enable-shared@<:@=PKGS@:>@],[build shared libraries @<:@default=enable_shared_default@:>@]),
     [p=${PACKAGE-default}
     case $enableval in
     yes) enable_shared=yes ;;
@@ -1943,7 +1943,7 @@ AC_ENABLE_SHARED(no)
 AC_DEFUN([AC_ENABLE_STATIC],
 [define([enable_static_default], ifelse($1, no, no, yes))dnl
 AC_ARG_ENABLE([static],
-    [AS_HELP_STRING([--enable-static@<:@=PKGS@:>@],[build static libraries @<:@default=enable_static_default@:>@])],
+    AS_HELP_STRING([--enable-static@<:@=PKGS@:>@],[build static libraries @<:@default=enable_static_default@:>@]),
     [p=${PACKAGE-default}
     case $enableval in
     yes) enable_static=yes ;;
@@ -1981,7 +1981,7 @@ AC_ENABLE_STATIC(no)
 AC_DEFUN([AC_ENABLE_FAST_INSTALL],
 [define([enable_Fast_install_default], ifelse($1, no, no, yes))dnl
 AC_ARG_ENABLE([fast-install],
-    [AS_HELP_STRING([--enable-fast-install@<:@=PKGS@:>@],[optimize for fast installation @<:@default=enable_Fast_install_default@:>@])],
+    AS_HELP_STRING([--enable-fast-install@<:@=PKGS@:>@],[optimize for fast installation @<:@default=enable_Fast_install_default@:>@]),
     [p=${PACKAGE-default}
     case $enableval in
     yes) enable_fast_install=yes ;;

llvm/bindings/Makefile

@@ -0,0 +1,16 @@
+##===- bindings/Makefile -----------------------------------*- Makefile -*-===##
+# 
+#                     The LLVM Compiler Infrastructure
+#
+# This file is distributed under the University of Illinois Open Source
+# License. See LICENSE.TXT for details.
+# 
+##===----------------------------------------------------------------------===##
+
+LEVEL := ..
+
+include $(LEVEL)/Makefile.config
+
+PARALLEL_DIRS = $(BINDINGS_TO_BUILD)
+
+include $(LEVEL)/Makefile.common

llvm/bindings/README.txt

@@ -0,0 +1,3 @@
+This directory contains bindings for the LLVM compiler infrastructure to allow
+programs written in languages other than C or C++ to take advantage of the LLVM
+infrastructure--for instance, a self-hosted compiler front-end.

llvm/bindings/ocaml/Makefile

@@ -0,0 +1,13 @@
+##===- bindings/ocaml/Makefile -----------------------------*- Makefile -*-===##
+# 
+#                     The LLVM Compiler Infrastructure
+#
+# This file is distributed under the University of Illinois Open Source
+# License. See LICENSE.TXT for details.
+# 
+##===----------------------------------------------------------------------===##
+
+LEVEL := ../..
+DIRS = llvm bitreader bitwriter analysis executionengine
+
+include $(LEVEL)/Makefile.common

llvm/bindings/ocaml/Makefile.ocaml

@@ -0,0 +1,323 @@
+##===- tools/ml/Makefile -----------------------------------*- Makefile -*-===##
+# 
+#                     The LLVM Compiler Infrastructure
+#
+# This file is distributed under the University of Illinois Open Source
+# License. See LICENSE.TXT for details.
+# 
+##===----------------------------------------------------------------------===##
+# 
+# An ocaml library is a unique project type in the context of LLVM, so rules are
+# here rather than in Makefile.rules.
+# 
+# Reference materials on installing ocaml libraries:
+# 
+#   https://fedoraproject.org/wiki/Packaging/OCaml
+#   http://pkg-ocaml-maint.alioth.debian.org/ocaml_packaging_policy.txt
+# 
+##===----------------------------------------------------------------------===##
+
+include $(LEVEL)/Makefile.config
+
+# CFLAGS needs to be set before Makefile.rules is included.
+CXX.Flags += -I"$(shell $(OCAMLC) -where)"
+C.Flags += -I"$(shell $(OCAMLC) -where)"
+
+include $(LEVEL)/Makefile.common
+
+# Intentionally ignore PROJ_prefix here. We want the ocaml stdlib. However, the
+# user can override this with OCAML_LIBDIR or configure --with-ocaml-libdir=.
+PROJ_libocamldir := $(DESTDIR)$(OCAML_LIBDIR)
+OcamlDir := $(LibDir)/ocaml
+
+# Info from llvm-config and similar
+ifdef UsedComponents
+UsedLibs = $(shell $(LLVM_CONFIG) --libs $(UsedComponents))
+UsedLibNames = $(shell $(LLVM_CONFIG) --libnames $(UsedComponents))
+endif
+
+# Tools
+OCAMLCFLAGS += -I $(OcamlDir) -I $(ObjDir)
+OCAMLAFLAGS += $(patsubst %,-cclib %, \
+                 $(filter-out -L$(LibDir),-l$(LIBRARYNAME) \
+                                          $(shell $(LLVM_CONFIG) --ldflags)) \
+                                          $(UsedLibs))
+ 
+# -g was introduced in 3.10.0.
+#ifneq ($(ENABLE_OPTIMIZED),1)
+#  OCAMLDEBUGFLAG := -g
+#endif
+
+Compile.CMI  := $(strip $(OCAMLC) -c $(OCAMLCFLAGS) $(OCAMLDEBUGFLAG) -o)
+Compile.CMO  := $(strip $(OCAMLC) -c $(OCAMLCFLAGS) $(OCAMLDEBUGFLAG) -o)
+Archive.CMA  := $(strip $(OCAMLC) -a -custom $(OCAMLAFLAGS) $(OCAMLDEBUGFLAG) \
+                                  -o)
+
+Compile.CMX  := $(strip $(OCAMLOPT) -c $(OCAMLCFLAGS) $(OCAMLDEBUGFLAG) -o)
+Archive.CMXA := $(strip $(OCAMLOPT) -a $(OCAMLAFLAGS) $(OCAMLDEBUGFLAG) -o)
+
+# Source files
+OcamlSources1 := $(sort $(wildcard $(PROJ_SRC_DIR)/*.ml))
+OcamlHeaders1 := $(OcamlSources1:.ml=.mli)
+
+OcamlSources := $(OcamlSources1:$(PROJ_SRC_DIR)/%=$(ObjDir)/%)
+OcamlHeaders := $(OcamlHeaders1:$(PROJ_SRC_DIR)/%=$(ObjDir)/%)
+
+# Intermediate files
+LibraryCMA   := $(ObjDir)/$(LIBRARYNAME).cma
+LibraryCMXA  := $(ObjDir)/$(LIBRARYNAME).cmxa
+ObjectsCMI   := $(OcamlSources:%.ml=%.cmi)
+ObjectsCMO   := $(OcamlSources:%.ml=%.cmo)
+ObjectsCMX   := $(OcamlSources:%.ml=%.cmx)
+
+# Output files
+#   The .cmo files are the only intermediates; all others are to be installed.
+LibraryA   := $(OcamlDir)/lib$(LIBRARYNAME).a
+OutputCMA  := $(LibraryCMA:$(ObjDir)/%.cma=$(OcamlDir)/%.cma)
+OutputCMXA := $(LibraryCMXA:$(ObjDir)/%.cmxa=$(OcamlDir)/%.cmxa)
+OutputsCMI := $(ObjectsCMI:$(ObjDir)/%.cmi=$(OcamlDir)/%.cmi)
+OutputsCMX := $(ObjectsCMX:$(ObjDir)/%.cmx=$(OcamlDir)/%.cmx)
+OutputLibs := $(UsedLibNames:%=$(OcamlDir)/%)
+
+# Installation targets
+DestA    := $(PROJ_libocamldir)/lib$(LIBRARYNAME).a
+DestCMA  := $(PROJ_libocamldir)/$(LIBRARYNAME).cma
+DestCMXA := $(PROJ_libocamldir)/$(LIBRARYNAME).cmxa
+DestLibs := $(UsedLibNames:%=$(PROJ_libocamldir)/%)
+
+
+##===- Dependencies -------------------------------------------------------===##
+# Copy the sources into the intermediate directory because older ocamlc doesn't
+# support -o except when linking (outputs are placed next to inputs).
+
+$(ObjDir)/%.mli: $(PROJ_SRC_DIR)/%.mli $(ObjDir)/.dir
+	$(Verb) $(CP) -f $< $@
+
+$(ObjDir)/%.ml: $(PROJ_SRC_DIR)/%.ml $(ObjDir)/.dir
+	$(Verb) $(CP) -f $< $@
+
+$(ObjDir)/$(LIBRARYNAME).ocamldep: $(OcamlSources) $(OcamlHeaders) \
+                                   $(OcamlDir)/.dir $(ObjDir)/.dir
+	$(Verb) $(OCAMLDEP) $(OCAMLCFLAGS) $(OcamlSources) $(OcamlHeader) > $@
+
+$(ObjectsCMI): $(UsedOcamlInterfaces:%=$(OcamlDir)/%.cmi)
+
+-include $(ObjDir)/$(LIBRARYNAME).ocamldep
+
+
+##===- Build static library from C sources --------------------------------===##
+
+all-local:: $(LibraryA)
+clean-local:: clean-a
+install-local:: install-a
+uninstall-local:: uninstall-a
+
+$(LibraryA): $(ObjectsO) $(OcamlDir)/.dir
+	$(Echo) "Building $(BuildMode) $(notdir $@)"
+	-$(Verb) $(RM) -f $@
+	$(Verb) $(Archive) $@ $(ObjectsO)
+	$(Verb) $(Ranlib) $@
+
+clean-a::
+	-$(Verb) $(RM) -f $(LibraryA)
+
+install-a:: $(LibraryA)
+	$(Echo) "Installing $(BuildMode) $(DestA)"
+	$(Verb) $(MKDIR) $(PROJ_libocamldir)
+	$(Verb) $(LTInstall) $(LibraryA) $(DestA)
+	$(Verb) 
+
+uninstall-a::
+	$(Echo) "Uninstalling $(DestA)"
+	-$(Verb) $(RM) -f $(DestA)
+
+
+##===- Deposit dependent libraries adjacent to Ocaml libs -----------------===##
+
+all-local:: build-deplibs
+clean-local:: clean-deplibs
+install-local:: install-deplibs
+uninstall-local:: uninstall-deplibs
+
+build-deplibs: $(OutputLibs)
+
+$(OcamlDir)/%.a: $(LibDir)/%.a
+	$(Verb) ln -sf $< $@
+
+$(OcamlDir)/%.o: $(LibDir)/%.o
+	$(Verb) ln -sf $< $@
+
+clean-deplibs:
+	$(Verb) rm -f $(OutputLibs)
+
+install-deplibs:
+	$(Verb) for i in $(DestLibs:$(PROJ_libocamldir)/%=%); do \
+	  ln -sf "$(PROJ_libdir)/$$i" "$(PROJ_libocamldir)/$$i"; \
+	done
+
+uninstall-deplibs:
+	$(Verb) rm -f $(DestLibs)
+
+
+##===- Build ocaml interfaces (.mli's -> .cmi's) --------------------------===##
+
+all-local:: build-cmis
+clean-local:: clean-cmis
+install-local:: install-cmis
+uninstall-local:: uninstall-cmis
+
+build-cmis: $(OutputsCMI)
+
+$(OcamlDir)/%.cmi: $(ObjDir)/%.cmi $(OcamlDir)/.dir
+	$(Verb) $(CP) -f $< $@
+
+$(ObjDir)/%.cmi: $(ObjDir)/%.mli $(ObjDir)/.dir
+	$(Echo) "Compiling $(notdir $<) for $(BuildMode) build"
+	$(Verb) $(Compile.CMI) $@ $<
+
+clean-cmis::
+	-$(Verb) $(RM) -f $(OutputsCMI)
+
+# Also install the .mli's (headers) as documentation.
+install-cmis: $(OutputsCMI) $(OcamlHeaders)
+	$(Verb) $(MKDIR) $(PROJ_libocamldir)
+	$(Verb) for i in $(OutputsCMI:$(OcamlDir)/%=%); do \
+	  $(EchoCmd) "Installing $(BuildMode) $(PROJ_libocamldir)/$$i"; \
+	  $(DataInstall) $(OcamlDir)/$$i "$(PROJ_libocamldir)/$$i"; \
+	done
+	$(Verb) for i in $(OcamlHeaders:$(ObjDir)/%=%); do \
+	  $(EchoCmd) "Installing $(BuildMode) $(PROJ_libocamldir)/$$i"; \
+	  $(DataInstall) $(ObjDir)/$$i "$(PROJ_libocamldir)/$$i"; \
+	done
+
+uninstall-cmis::
+	$(Verb) for i in $(OutputsCMI:$(OcamlDir)/%=%); do \
+	  $(EchoCmd) "Uninstalling $(PROJ_libocamldir)/$$i"; \
+	  $(RM) -f "$(PROJ_libocamldir)/$$i"; \
+	done
+	$(Verb) for i in $(OcamlHeaders:$(ObjDir)/%=%); do \
+	  $(EchoCmd) "Uninstalling $(PROJ_libocamldir)/$$i"; \
+	  $(RM) -f "$(PROJ_libocamldir)/$$i"; \
+	done
+
+
+##===- Build ocaml bytecode archive (.ml's -> .cmo's -> .cma) -------------===##
+
+all-local:: $(OutputCMA)
+clean-local:: clean-cma
+install-local:: install-cma
+uninstall-local:: uninstall-cma
+
+$(OutputCMA): $(LibraryCMA) $(OcamlDir)/.dir
+	$(Verb) $(CP) -f $< $@
+
+$(LibraryCMA): $(ObjectsCMO) $(OcamlDir)/.dir
+	$(Echo) "Archiving $(notdir $@) for $(BuildMode) build"
+	$(Verb) $(Archive.CMA) $@ $(ObjectsCMO)
+
+$(ObjDir)/%.cmo: $(ObjDir)/%.ml
+	$(Echo) "Compiling $(notdir $<) for $(BuildMode) build"
+	$(Verb) $(Compile.CMO) $@ $<
+
+clean-cma::
+	$(Verb) $(RM) -f $(OutputCMA) $(UsedLibNames:%=$(OcamlDir)/%)
+
+install-cma:: $(OutputCMA)
+	$(Echo) "Installing $(BuildMode) $(DestCMA)"
+	$(Verb) $(MKDIR) $(PROJ_libocamldir)
+	$(Verb) $(DataInstall) $(OutputCMA) "$(DestCMA)"
+
+uninstall-cma::
+	$(Echo) "Uninstalling $(DestCMA)"
+	-$(Verb) $(RM) -f $(DestCMA)
+
+
+##===- Build optimized ocaml archive (.ml's -> .cmx's -> .cmxa, .a) -------===##
+
+# The ocamlopt compiler is supported on a set of targets disjoint from LLVM's.
+# If unavailable, 'configure' will not define OCAMLOPT in Makefile.config.
+ifdef OCAMLOPT
+
+all-local:: $(OutputCMXA) $(OutputsCMX)
+clean-local:: clean-cmxa
+install-local:: install-cmxa
+uninstall-local:: uninstall-cmxa
+
+$(OutputCMXA): $(LibraryCMXA)
+	$(Verb) $(CP) -f $< $@
+	$(Verb) $(CP) -f $(<:.cmxa=.a) $(@:.cmxa=.a)
+
+$(OcamlDir)/%.cmx: $(ObjDir)/%.cmx
+	$(Verb) $(CP) -f $< $@
+
+$(LibraryCMXA): $(ObjectsCMX)
+	$(Echo) "Archiving $(notdir $@) for $(BuildMode) build"
+	$(Verb) $(Archive.CMXA) $@ $(ObjectsCMX)
+	$(Verb) $(RM) -f $(@:.cmxa=.o)
+
+$(ObjDir)/%.cmx: $(ObjDir)/%.ml
+	$(Echo) "Compiling optimized $(notdir $<) for $(BuildMode) build"
+	$(Verb) $(Compile.CMX) $@ $<
+
+clean-cmxa::
+	$(Verb) $(RM) -f $(OutputCMXA) $(OutputCMXA:.cmxa=.o) $(OutputsCMX)
+
+install-cmxa:: $(OutputCMXA) $(OutputsCMX)
+	$(Verb) $(MKDIR) $(PROJ_libocamldir)
+	$(Echo) "Installing $(BuildMode) $(DestCMXA)"
+	$(Verb) $(DataInstall) $(OutputCMXA) $(DestCMXA)
+	$(Echo) "Installing $(BuildMode) $(DestCMXA:.cmxa=.a)"
+	$(Verb) $(DataInstall) $(OutputCMXA:.cmxa=.a) $(DestCMXA:.cmxa=.a)
+	$(Verb) for i in $(OutputsCMX:$(OcamlDir)/%=%); do \
+	  $(EchoCmd) "Installing $(BuildMode) $(PROJ_libocamldir)/$$i"; \
+	  $(DataInstall) $(OcamlDir)/$$i "$(PROJ_libocamldir)/$$i"; \
+	done
+
+uninstall-cmxa::
+	$(Echo) "Uninstalling $(DestCMXA)"
+	$(Verb) $(RM) -f $(DestCMXA)
+	$(Echo) "Uninstalling $(DestCMXA:.cmxa=.a)"
+	$(Verb) $(RM) -f $(DestCMXA:.cmxa=.a)
+	$(Verb) for i in $(OutputsCMX:$(OcamlDir)/%=%); do \
+	  $(EchoCmd) "Uninstalling $(PROJ_libocamldir)/$$i"; \
+	  $(RM) -f $(PROJ_libocamldir)/$$i; \
+	done
+
+endif
+
+
+##===- Debugging gunk -----------------------------------------------------===##
+printvars:: printcamlvars
+
+printcamlvars::
+	$(Echo) "LLVM_CONFIG  : " '$(LLVM_CONFIG)'
+	$(Echo) "OCAMLCFLAGS  : " '$(OCAMLCFLAGS)'
+	$(Echo) "OCAMLAFLAGS  : " '$(OCAMLAFLAGS)'
+	$(Echo) "OCAMLC       : " '$(OCAMLC)'
+	$(Echo) "OCAMLOPT     : " '$(OCAMLOPT)'
+	$(Echo) "OCAMLDEP     : " '$(OCAMLDEP)'
+	$(Echo) "Compile.CMI  : " '$(Compile.CMI)'
+	$(Echo) "Compile.CMO  : " '$(Compile.CMO)'
+	$(Echo) "Archive.CMA  : " '$(Archive.CMA)'
+	$(Echo) "Compile.CMX  : " '$(Compile.CMX)'
+	$(Echo) "Archive.CMXA : " '$(Archive.CMXA)'
+	$(Echo) "CAML_LIBDIR  : " '$(CAML_LIBDIR)'
+	$(Echo) "LibraryCMA   : " '$(LibraryCMA)'
+	$(Echo) "LibraryCMXA  : " '$(LibraryCMXA)'
+	$(Echo) "OcamlSources1: " '$(OcamlSources1)'
+	$(Echo) "OcamlSources : " '$(OcamlSources)'
+	$(Echo) "OcamlHeaders : " '$(OcamlHeaders)'
+	$(Echo) "ObjectsCMI   : " '$(ObjectsCMI)'
+	$(Echo) "ObjectsCMO   : " '$(ObjectsCMO)'
+	$(Echo) "ObjectsCMX   : " '$(ObjectsCMX)'
+	$(Echo) "OCAML_LIBDIR : " '$(OCAML_LIBDIR)'
+	$(Echo) "DestA        : " '$(DestA)'
+	$(Echo) "DestCMA      : " '$(DestCMA)'
+	$(Echo) "DestCMXA     : " '$(DestCMXA)'
+	$(Echo) "UsedLibs     : " '$(UsedLibs)'
+	$(Echo) "UsedLibNames : " '$(UsedLibNames)'
+
+.PHONY: printcamlvars   build-cmis \
+            clean-a     clean-cmis     clean-cma     clean-cmxa \
+          install-a   install-cmis   install-cma   install-cmxa \
+		uninstall-a uninstall-cmis uninstall-cma uninstall-cmxa

llvm/bindings/ocaml/analysis/Makefile

@@ -0,0 +1,20 @@
+##===- bindings/ocaml/analysis/Makefile --------------------*- Makefile -*-===##
+# 
+#                     The LLVM Compiler Infrastructure
+#
+# This file is distributed under the University of Illinois Open Source
+# License. See LICENSE.TXT for details.
+# 
+##===----------------------------------------------------------------------===##
+# 
+# This is the makefile for the Objective Caml Llvm_analysis interface.
+# 
+##===----------------------------------------------------------------------===##
+
+LEVEL := ../../..
+LIBRARYNAME := llvm_analysis
+DONT_BUILD_RELINKED := 1
+UsedComponents := analysis
+UsedOcamlInterfaces := llvm
+
+include ../Makefile.ocaml

llvm/bindings/ocaml/analysis/analysis_ocaml.c

@@ -0,0 +1,60 @@
+/*===-- analysis_ocaml.c - LLVM Ocaml Glue ----------------------*- C++ -*-===*\
+|*                                                                            *|
+|*                     The LLVM Compiler Infrastructure                       *|
+|*                                                                            *|
+|* This file is distributed under the University of Illinois Open Source      *|
+|* License. See LICENSE.TXT for details.                                      *|
+|*                                                                            *|
+|*===----------------------------------------------------------------------===*|
+|*                                                                            *|
+|* This file glues LLVM's ocaml interface to its C interface. These functions *|
+|* are by and large transparent wrappers to the corresponding C functions.    *|
+|*                                                                            *|
+|* Note that these functions intentionally take liberties with the CAMLparamX *|
+|* macros, since most of the parameters are not GC heap objects.              *|
+|*                                                                            *|
+\*===----------------------------------------------------------------------===*/
+
+#include "llvm-c/Analysis.h"
+#include "caml/alloc.h"
+#include "caml/mlvalues.h"
+#include "caml/memory.h"
+
+
+/* Llvm.llmodule -> string option */
+CAMLprim value llvm_verify_module(LLVMModuleRef M) {
+  CAMLparam0();
+  CAMLlocal2(String, Option);
+  
+  char *Message;
+  int Result = LLVMVerifyModule(M, LLVMReturnStatusAction, &Message);
+  
+  if (0 == Result) {
+    Option = Val_int(0);
+  } else {
+    Option = alloc(1, 0);
+    String = copy_string(Message);
+    Store_field(Option, 0, String);
+  }
+  
+  LLVMDisposeMessage(Message);
+  
+  CAMLreturn(Option);
+}
+
+/* Llvm.llvalue -> bool */
+CAMLprim value llvm_verify_function(LLVMValueRef Fn) {
+  return Val_bool(LLVMVerifyFunction(Fn, LLVMReturnStatusAction) == 0);
+}
+
+/* Llvm.llmodule -> unit */
+CAMLprim value llvm_assert_valid_module(LLVMModuleRef M) {
+  LLVMVerifyModule(M, LLVMAbortProcessAction, 0);
+  return Val_unit;
+}
+
+/* Llvm.llvalue -> unit */
+CAMLprim value llvm_assert_valid_function(LLVMValueRef Fn) {
+  LLVMVerifyFunction(Fn, LLVMAbortProcessAction);
+  return Val_unit;
+}

llvm/bindings/ocaml/analysis/llvm_analysis.ml

@@ -0,0 +1,19 @@
+(*===-- llvm_analysis.ml - LLVM Ocaml Interface -----------------*- C++ -*-===*
+ *
+ *                     The LLVM Compiler Infrastructure
+ *
+ * This file is distributed under the University of Illinois Open Source
+ * License. See LICENSE.TXT for details.
+ *
+ *===----------------------------------------------------------------------===*)
+
+
+external verify_module : Llvm.llmodule -> string option = "llvm_verify_module"
+
+external verify_function : Llvm.llvalue -> bool = "llvm_verify_function"
+
+external assert_valid_module : Llvm.llmodule -> unit
+                             = "llvm_assert_valid_module"
+
+external assert_valid_function : Llvm.llvalue -> unit
+                               = "llvm_assert_valid_function"

llvm/bindings/ocaml/analysis/llvm_analysis.mli

@@ -0,0 +1,36 @@
+(*===-- llvm_analysis.mli - LLVM Ocaml Interface ----------------*- C++ -*-===*
+ *
+ *                     The LLVM Compiler Infrastructure
+ *
+ * This file is distributed under the University of Illinois Open Source
+ * License. See LICENSE.TXT for details.
+ *
+ *===----------------------------------------------------------------------===
+ *
+ * This interface provides an ocaml API for LLVM IR analyses, the classes in
+ * the Analysis library.
+ *
+ *===----------------------------------------------------------------------===*)
+
+
+(** [verify_module m] returns [None] if the module [m] is valid, and
+    [Some reason] if it is invalid. [reason] is a string containing a
+    human-readable validation report. See [llvm::verifyModule]. **)
+external verify_module : Llvm.llmodule -> string option = "llvm_verify_module"
+
+(** [verify_function f] returns [None] if the function [f] is valid, and
+    [Some reason] if it is invalid. [reason] is a string containing a
+    human-readable validation report. See [llvm::verifyFunction]. **)
+external verify_function : Llvm.llvalue -> bool = "llvm_verify_function"
+
+(** [verify_module m] returns if the module [m] is valid, but prints a
+    validation report to [stderr] and aborts the program if it is invalid. See 
+    [llvm::verifyModule]. **)
+external assert_valid_module : Llvm.llmodule -> unit
+                             = "llvm_assert_valid_module"
+
+(** [verify_function f] returns if the function [f] is valid, but prints a
+    validation report to [stderr] and aborts the program if it is invalid. See 
+    [llvm::verifyFunction]. **)
+external assert_valid_function : Llvm.llvalue -> unit
+                               = "llvm_assert_valid_function"

llvm/bindings/ocaml/bitreader/Makefile

@@ -0,0 +1,20 @@
+##===- bindings/ocaml/bitreader/Makefile -------------------*- Makefile -*-===##
+# 
+#                     The LLVM Compiler Infrastructure
+#
+# This file is distributed under the University of Illinois Open Source
+# License. See LICENSE.TXT for details.
+# 
+##===----------------------------------------------------------------------===##
+# 
+# This is the makefile for the Objective Caml Llvm_bitreader interface.
+# 
+##===----------------------------------------------------------------------===##
+
+LEVEL := ../../..
+LIBRARYNAME := llvm_bitreader
+DONT_BUILD_RELINKED := 1
+UsedComponents := bitreader
+UsedOcamlInterfaces := llvm
+
+include ../Makefile.ocaml

llvm/bindings/ocaml/bitreader/bitreader_ocaml.c

@@ -0,0 +1,72 @@
+/*===-- bitwriter_ocaml.c - LLVM Ocaml Glue ---------------------*- C++ -*-===*\
+|*                                                                            *|
+|*                     The LLVM Compiler Infrastructure                       *|
+|*                                                                            *|
+|* This file is distributed under the University of Illinois Open Source      *|
+|* License. See LICENSE.TXT for details.                                      *|
+|*                                                                            *|
+|*===----------------------------------------------------------------------===*|
+|*                                                                            *|
+|* This file glues LLVM's ocaml interface to its C interface. These functions *|
+|* are by and large transparent wrappers to the corresponding C functions.    *|
+|*                                                                            *|
+\*===----------------------------------------------------------------------===*/
+
+#include "llvm-c/BitReader.h"
+#include "caml/alloc.h"
+#include "caml/fail.h"
+#include "caml/memory.h"
+
+
+/* Can't use the recommended caml_named_value mechanism for backwards
+   compatibility reasons. This is largely equivalent. */
+static value llvm_bitreader_error_exn;
+
+CAMLprim value llvm_register_bitreader_exns(value Error) {
+  llvm_bitreader_error_exn = Field(Error, 0);
+  register_global_root(&llvm_bitreader_error_exn);
+  return Val_unit;
+}
+
+static void llvm_raise(value Prototype, char *Message) {
+  CAMLparam1(Prototype);
+  CAMLlocal1(CamlMessage);
+  
+  CamlMessage = copy_string(Message);
+  LLVMDisposeMessage(Message);
+  
+  raise_with_arg(Prototype, CamlMessage);
+  abort(); /* NOTREACHED */
+#ifdef CAMLnoreturn
+  CAMLnoreturn; /* Silences warnings, but is missing in some versions. */
+#endif
+}
+
+
+/*===-- Modules -----------------------------------------------------------===*/
+
+/* Llvm.llmemorybuffer -> Llvm.module */
+CAMLprim value llvm_get_module_provider(LLVMMemoryBufferRef MemBuf) {
+  CAMLparam0();
+  CAMLlocal2(Variant, MessageVal);
+  char *Message;
+  
+  LLVMModuleProviderRef MP;
+  if (LLVMGetBitcodeModuleProvider(MemBuf, &MP, &Message))
+    llvm_raise(llvm_bitreader_error_exn, Message);
+  
+  CAMLreturn((value) MemBuf);
+}
+
+/* Llvm.llmemorybuffer -> Llvm.llmodule */
+CAMLprim value llvm_parse_bitcode(LLVMMemoryBufferRef MemBuf) {
+  CAMLparam0();
+  CAMLlocal2(Variant, MessageVal);
+  LLVMModuleRef M;
+  char *Message;
+  
+  if (LLVMParseBitcode(MemBuf, &M, &Message))
+    llvm_raise(llvm_bitreader_error_exn, Message);
+  
+  CAMLreturn((value) M);
+}

llvm/bindings/ocaml/bitreader/llvm_bitreader.ml

@@ -0,0 +1,19 @@
+(*===-- llvm_bitreader.ml - LLVM Ocaml Interface ----------------*- C++ -*-===*
+ *
+ *                     The LLVM Compiler Infrastructure
+ *
+ * This file is distributed under the University of Illinois Open Source
+ * License. See LICENSE.TXT for details.
+ *
+ *===----------------------------------------------------------------------===*)
+
+
+exception Error of string
+
+external register_exns : exn -> unit = "llvm_register_bitreader_exns"
+let _ = register_exns (Error "")
+
+external get_module_provider : Llvm.llmemorybuffer -> Llvm.llmoduleprovider
+                             = "llvm_get_module_provider"
+external parse_bitcode : Llvm.llmemorybuffer -> Llvm.llmodule
+                       = "llvm_parse_bitcode"

llvm/bindings/ocaml/bitreader/llvm_bitreader.mli

@@ -0,0 +1,30 @@
+(*===-- llvm_bitreader.mli - LLVM Ocaml Interface ---------------*- C++ -*-===*
+ *
+ *                     The LLVM Compiler Infrastructure
+ *
+ * This file is distributed under the University of Illinois Open Source
+ * License. See LICENSE.TXT for details.
+ *
+ *===----------------------------------------------------------------------===
+ *
+ * This interface provides an ocaml API for the LLVM bitcode reader, the
+ * classes in the Bitreader library.
+ *
+ *===----------------------------------------------------------------------===*)
+
+
+exception Error of string
+
+(** [read_bitcode_file path] reads the bitcode for a new module [m] from the
+    file at [path]. Returns [Success m] if successful, and [Failure msg]
+    otherwise, where [msg] is a description of the error encountered.
+    See the function [llvm::getBitcodeModuleProvider]. **)
+external get_module_provider : Llvm.llmemorybuffer -> Llvm.llmoduleprovider
+                             = "llvm_get_module_provider"
+
+(** [parse_bitcode mb] parses the bitcode for a new module [m] from the memory
+    buffer [mb]. Returns [Success m] if successful, and [Failure msg] otherwise,
+    where [msg] is a description of the error encountered.
+    See the function [llvm::ParseBitcodeFile]. **)
+external parse_bitcode : Llvm.llmemorybuffer -> Llvm.llmodule
+                       = "llvm_parse_bitcode"

llvm/bindings/ocaml/bitwriter/Makefile

@@ -0,0 +1,20 @@
+##===- bindings/ocaml/bitwriter/Makefile -------------------*- Makefile -*-===##
+# 
+#                     The LLVM Compiler Infrastructure
+#
+# This file is distributed under the University of Illinois Open Source
+# License. See LICENSE.TXT for details.
+# 
+##===----------------------------------------------------------------------===##
+# 
+# This is the makefile for the Objective Caml Llvm_bitwriter interface.
+# 
+##===----------------------------------------------------------------------===##
+
+LEVEL := ../../..
+LIBRARYNAME := llvm_bitwriter
+DONT_BUILD_RELINKED := 1
+UsedComponents := bitwriter
+UsedOcamlInterfaces := llvm
+
+include ../Makefile.ocaml

llvm/bindings/ocaml/bitwriter/bitwriter_ocaml.c

@@ -0,0 +1,30 @@
+/*===-- bitwriter_ocaml.c - LLVM Ocaml Glue ---------------------*- C++ -*-===*\
+|*                                                                            *|
+|*                     The LLVM Compiler Infrastructure                       *|
+|*                                                                            *|
+|* This file is distributed under the University of Illinois Open Source      *|
+|* License. See LICENSE.TXT for details.                                      *|
+|*                                                                            *|
+|*===----------------------------------------------------------------------===*|
+|*                                                                            *|
+|* This file glues LLVM's ocaml interface to its C interface. These functions *|
+|* are by and large transparent wrappers to the corresponding C functions.    *|
+|*                                                                            *|
+|* Note that these functions intentionally take liberties with the CAMLparamX *|
+|* macros, since most of the parameters are not GC heap objects.              *|
+|*                                                                            *|
+\*===----------------------------------------------------------------------===*/
+
+#include "llvm-c/BitWriter.h"
+#include "llvm-c/Core.h"
+#include "caml/alloc.h"
+#include "caml/mlvalues.h"
+#include "caml/memory.h"
+
+/*===-- Modules -----------------------------------------------------------===*/
+
+/* Llvm.llmodule -> string -> bool */
+CAMLprim value llvm_write_bitcode_file(value M, value Path) {
+  int res = LLVMWriteBitcodeToFile((LLVMModuleRef) M, String_val(Path));
+  return Val_bool(res == 0);
+}

llvm/bindings/ocaml/bitwriter/llvm_bitwriter.ml

@@ -0,0 +1,18 @@
+(*===-- llvm_bitwriter.ml - LLVM Ocaml Interface ----------------*- C++ -*-===*
+ *
+ *                     The LLVM Compiler Infrastructure
+ *
+ * This file is distributed under the University of Illinois Open Source
+ * License. See LICENSE.TXT for details.
+ *
+ *===----------------------------------------------------------------------===
+ *
+ * This interface provides an ocaml API for the LLVM intermediate
+ * representation, the classes in the VMCore library.
+ *
+ *===----------------------------------------------------------------------===*)
+
+
+(* Writes the bitcode for module the given path. Returns true if successful. *)
+external write_bitcode_file : Llvm.llmodule -> string -> bool
+                            = "llvm_write_bitcode_file"

llvm/bindings/ocaml/bitwriter/llvm_bitwriter.mli

@@ -0,0 +1,19 @@
+(*===-- llvm_bitwriter.mli - LLVM Ocaml Interface ---------------*- C++ -*-===*
+ *
+ *                     The LLVM Compiler Infrastructure
+ *
+ * This file is distributed under the University of Illinois Open Source
+ * License. See LICENSE.TXT for details.
+ *
+ *===----------------------------------------------------------------------===
+ *
+ * This interface provides an ocaml API for the LLVM bitcode writer, the
+ * classes in the Bitwriter library.
+ *
+ *===----------------------------------------------------------------------===*)
+
+
+(** [write_bitcode_file m path] writes the bitcode for module [m] to the file at
+    [path]. Returns [true] if successful, [false] otherwise. **)
+external write_bitcode_file : Llvm.llmodule -> string -> bool
+                            = "llvm_write_bitcode_file"

llvm/bindings/ocaml/executionengine/Makefile

@@ -0,0 +1,20 @@
+##===- bindings/ocaml/executionengine/Makefile --------------*- Makefile -*-===##
+# 
+#                     The LLVM Compiler Infrastructure
+#
+# This file is distributed under the University of Illinois Open Source
+# License. See LICENSE.TXT for details.
+# 
+##===----------------------------------------------------------------------===##
+# 
+# This is the makefile for the Objective Caml Llvm_executionengine interface.
+# 
+##===----------------------------------------------------------------------===##
+
+LEVEL := ../../..
+LIBRARYNAME := llvm_executionengine
+DONT_BUILD_RELINKED := 1
+UsedComponents := executionengine jit interpreter native
+UsedOcamlInterfaces := llvm
+
+include ../Makefile.ocaml

llvm/bindings/ocaml/executionengine/executionengine_ocaml.c

@@ -0,0 +1,313 @@
+/*===-- analysis_ocaml.c - LLVM Ocaml Glue ----------------------*- C++ -*-===*\
+|*                                                                            *|
+|*                     The LLVM Compiler Infrastructure                       *|
+|*                                                                            *|
+|* This file is distributed under the University of Illinois Open Source      *|
+|* License. See LICENSE.TXT for details.                                      *|
+|*                                                                            *|
+|*===----------------------------------------------------------------------===*|
+|*                                                                            *|
+|* This file glues LLVM's ocaml interface to its C interface. These functions *|
+|* are by and large transparent wrappers to the corresponding C functions.    *|
+|*                                                                            *|
+|* Note that these functions intentionally take liberties with the CAMLparamX *|
+|* macros, since most of the parameters are not GC heap objects.              *|
+|*                                                                            *|
+\*===----------------------------------------------------------------------===*/
+
+#include "llvm-c/ExecutionEngine.h"
+#include "caml/alloc.h"
+#include "caml/custom.h"
+#include "caml/fail.h"
+#include "caml/memory.h"
+#include <string.h>
+#include <assert.h>
+
+
+/* Can't use the recommended caml_named_value mechanism for backwards
+   compatibility reasons. This is largely equivalent. */
+static value llvm_ee_error_exn;
+
+CAMLprim value llvm_register_ee_exns(value Error) {
+  llvm_ee_error_exn = Field(Error, 0);
+  register_global_root(&llvm_ee_error_exn);
+  return Val_unit;
+}
+
+static void llvm_raise(value Prototype, char *Message) {
+  CAMLparam1(Prototype);
+  CAMLlocal1(CamlMessage);
+  
+  CamlMessage = copy_string(Message);
+  LLVMDisposeMessage(Message);
+  
+  raise_with_arg(Prototype, CamlMessage);
+  abort(); /* NOTREACHED */
+#ifdef CAMLnoreturn
+  CAMLnoreturn; /* Silences warnings, but is missing in some versions. */
+#endif
+}
+
+
+/*--... Operations on generic values .......................................--*/
+
+#define Genericvalue_val(v)  (*(LLVMGenericValueRef *)(Data_custom_val(v)))
+
+static void llvm_finalize_generic_value(value GenVal) {
+  LLVMDisposeGenericValue(Genericvalue_val(GenVal));
+}
+
+static struct custom_operations generic_value_ops = {
+  (char *) "LLVMGenericValue",
+  llvm_finalize_generic_value,
+  custom_compare_default,
+  custom_hash_default,
+  custom_serialize_default,
+  custom_deserialize_default
+};
+
+static value alloc_generic_value(LLVMGenericValueRef Ref) {
+  value Val = alloc_custom(&generic_value_ops, sizeof(LLVMGenericValueRef), 0, 1);
+  Genericvalue_val(Val) = Ref;
+  return Val;
+}
+
+/* Llvm.lltype -> float -> t */
+CAMLprim value llvm_genericvalue_of_float(LLVMTypeRef Ty, value N) {
+  CAMLparam1(N);
+  CAMLreturn(alloc_generic_value(
+    LLVMCreateGenericValueOfFloat(Ty, Double_val(N))));
+}
+
+/* 'a -> t */
+CAMLprim value llvm_genericvalue_of_value(value V) {
+  CAMLparam1(V);
+  CAMLreturn(alloc_generic_value(LLVMCreateGenericValueOfPointer(Op_val(V))));
+}
+
+/* Llvm.lltype -> int -> t */
+CAMLprim value llvm_genericvalue_of_int(LLVMTypeRef Ty, value Int) {
+  return alloc_generic_value(LLVMCreateGenericValueOfInt(Ty, Int_val(Int), 1));
+}
+
+/* Llvm.lltype -> int32 -> t */
+CAMLprim value llvm_genericvalue_of_int32(LLVMTypeRef Ty, value Int32) {
+  CAMLparam1(Int32);
+  CAMLreturn(alloc_generic_value(
+    LLVMCreateGenericValueOfInt(Ty, Int32_val(Int32), 1)));
+}
+
+/* Llvm.lltype -> nativeint -> t */
+CAMLprim value llvm_genericvalue_of_nativeint(LLVMTypeRef Ty, value NatInt) {
+  CAMLparam1(NatInt);
+  CAMLreturn(alloc_generic_value(
+    LLVMCreateGenericValueOfInt(Ty, Nativeint_val(NatInt), 1)));
+}
+
+/* Llvm.lltype -> int64 -> t */
+CAMLprim value llvm_genericvalue_of_int64(LLVMTypeRef Ty, value Int64) {
+  CAMLparam1(Int64);
+  CAMLreturn(alloc_generic_value(
+    LLVMCreateGenericValueOfInt(Ty, Int64_val(Int64), 1)));
+}
+
+/* Llvm.lltype -> t -> float */
+CAMLprim value llvm_genericvalue_as_float(LLVMTypeRef Ty, value GenVal) {
+  CAMLparam1(GenVal);
+  CAMLreturn(copy_double(
+    LLVMGenericValueToFloat(Ty, Genericvalue_val(GenVal))));
+}
+
+/* t -> 'a */
+CAMLprim value llvm_genericvalue_as_value(value GenVal) {
+  return Val_op(LLVMGenericValueToPointer(Genericvalue_val(GenVal)));
+}
+
+/* t -> int */
+CAMLprim value llvm_genericvalue_as_int(value GenVal) {
+  assert(LLVMGenericValueIntWidth(Genericvalue_val(GenVal)) <= 8 * sizeof(value)
+         && "Generic value too wide to treat as an int!");
+  return Val_int(LLVMGenericValueToInt(Genericvalue_val(GenVal), 1));
+}
+
+/* t -> int32 */
+CAMLprim value llvm_genericvalue_as_int32(value GenVal) {
+  CAMLparam1(GenVal);
+  assert(LLVMGenericValueIntWidth(Genericvalue_val(GenVal)) <= 32
+         && "Generic value too wide to treat as an int32!");
+  CAMLreturn(copy_int32(LLVMGenericValueToInt(Genericvalue_val(GenVal), 1)));
+}
+
+/* t -> int64 */
+CAMLprim value llvm_genericvalue_as_int64(value GenVal) {
+  CAMLparam1(GenVal);
+  assert(LLVMGenericValueIntWidth(Genericvalue_val(GenVal)) <= 64
+         && "Generic value too wide to treat as an int64!");
+  CAMLreturn(copy_int64(LLVMGenericValueToInt(Genericvalue_val(GenVal), 1)));
+}
+
+/* t -> nativeint */
+CAMLprim value llvm_genericvalue_as_nativeint(value GenVal) {
+  CAMLparam1(GenVal);
+  assert(LLVMGenericValueIntWidth(Genericvalue_val(GenVal)) <= 8 * sizeof(value)
+         && "Generic value too wide to treat as a nativeint!");
+  CAMLreturn(copy_nativeint(LLVMGenericValueToInt(Genericvalue_val(GenVal),1)));
+}
+
+
+/*--... Operations on execution engines ....................................--*/
+
+/* llmoduleprovider -> ExecutionEngine.t */
+CAMLprim LLVMExecutionEngineRef llvm_ee_create(LLVMModuleProviderRef MP) {
+  LLVMExecutionEngineRef Interp;
+  char *Error;
+  if (LLVMCreateExecutionEngine(&Interp, MP, &Error))
+    llvm_raise(llvm_ee_error_exn, Error);
+  return Interp;
+}
+
+/* llmoduleprovider -> ExecutionEngine.t */
+CAMLprim LLVMExecutionEngineRef
+llvm_ee_create_interpreter(LLVMModuleProviderRef MP) {
+  LLVMExecutionEngineRef Interp;
+  char *Error;
+  if (LLVMCreateInterpreter(&Interp, MP, &Error))
+    llvm_raise(llvm_ee_error_exn, Error);
+  return Interp;
+}
+
+/* llmoduleprovider -> ExecutionEngine.t */
+CAMLprim LLVMExecutionEngineRef
+llvm_ee_create_jit(LLVMModuleProviderRef MP) {
+  LLVMExecutionEngineRef JIT;
+  char *Error;
+  if (LLVMCreateJITCompiler(&JIT, MP, &Error))
+    llvm_raise(llvm_ee_error_exn, Error);
+  return JIT;
+}
+
+/* ExecutionEngine.t -> unit */
+CAMLprim value llvm_ee_dispose(LLVMExecutionEngineRef EE) {
+  LLVMDisposeExecutionEngine(EE);
+  return Val_unit;
+}
+
+/* llmoduleprovider -> ExecutionEngine.t -> unit */
+CAMLprim value llvm_ee_add_mp(LLVMModuleProviderRef MP,
+                              LLVMExecutionEngineRef EE) {
+  LLVMAddModuleProvider(EE, MP);
+  return Val_unit;
+}
+
+/* llmoduleprovider -> ExecutionEngine.t -> llmodule */
+CAMLprim LLVMModuleRef llvm_ee_remove_mp(LLVMModuleProviderRef MP,
+                                         LLVMExecutionEngineRef EE) {
+  LLVMModuleRef RemovedModule;
+  char *Error;
+  if (LLVMRemoveModuleProvider(EE, MP, &RemovedModule, &Error))
+    llvm_raise(llvm_ee_error_exn, Error);
+  return RemovedModule;
+}
+
+/* string -> ExecutionEngine.t -> llvalue option */
+CAMLprim value llvm_ee_find_function(value Name, LLVMExecutionEngineRef EE) {
+  CAMLparam1(Name);
+  CAMLlocal1(Option);
+  LLVMValueRef Found;
+  if (LLVMFindFunction(EE, String_val(Name), &Found))
+    CAMLreturn(Val_unit);
+  Option = alloc(1, 1);
+  Field(Option, 0) = Val_op(Found);
+  CAMLreturn(Option);
+}
+
+/* llvalue -> GenericValue.t array -> ExecutionEngine.t -> GenericValue.t */
+CAMLprim value llvm_ee_run_function(LLVMValueRef F, value Args,
+                                    LLVMExecutionEngineRef EE) {
+  unsigned NumArgs;
+  LLVMGenericValueRef Result, *GVArgs;
+  unsigned I;
+  
+  NumArgs = Wosize_val(Args);
+  GVArgs = (LLVMGenericValueRef*) malloc(NumArgs * sizeof(LLVMGenericValueRef));
+  for (I = 0; I != NumArgs; ++I)
+    GVArgs[I] = Genericvalue_val(Field(Args, I));
+  
+  Result = LLVMRunFunction(EE, F, NumArgs, GVArgs);
+  
+  free(GVArgs);
+  return alloc_generic_value(Result);
+}
+
+/* ExecutionEngine.t -> unit */
+CAMLprim value llvm_ee_run_static_ctors(LLVMExecutionEngineRef EE) {
+  LLVMRunStaticConstructors(EE);
+  return Val_unit;
+}
+
+/* ExecutionEngine.t -> unit */
+CAMLprim value llvm_ee_run_static_dtors(LLVMExecutionEngineRef EE) {
+  LLVMRunStaticDestructors(EE);
+  return Val_unit;
+}
+
+/* llvalue -> string array -> (string * string) array -> ExecutionEngine.t ->
+   int */
+CAMLprim value llvm_ee_run_function_as_main(LLVMValueRef F,
+                                            value Args, value Env,
+                                            LLVMExecutionEngineRef EE) {
+  CAMLparam2(Args, Env);
+  int I, NumArgs, NumEnv, EnvSize, Result;
+  const char **CArgs, **CEnv;
+  char *CEnvBuf, *Pos;
+  
+  NumArgs = Wosize_val(Args);
+  NumEnv = Wosize_val(Env);
+  
+  /* Build the environment. */
+  CArgs = (const char **) malloc(NumArgs * sizeof(char*));
+  for (I = 0; I != NumArgs; ++I)
+    CArgs[I] = String_val(Field(Args, I));
+  
+  /* Compute the size of the environment string buffer. */
+  for (I = 0, EnvSize = 0; I != NumEnv; ++I) {
+    EnvSize += strlen(String_val(Field(Field(Env, I), 0))) + 1;
+    EnvSize += strlen(String_val(Field(Field(Env, I), 1))) + 1;
+  }
+  
+  /* Build the environment. */
+  CEnv = (const char **) malloc((NumEnv + 1) * sizeof(char*));
+  CEnvBuf = (char*) malloc(EnvSize);
+  Pos = CEnvBuf;
+  for (I = 0; I != NumEnv; ++I) {
+    char *Name  = String_val(Field(Field(Env, I), 0)),
+         *Value = String_val(Field(Field(Env, I), 1));
+    int NameLen  = strlen(Name),
+        ValueLen = strlen(Value);
+    
+    CEnv[I] = Pos;
+    memcpy(Pos, Name, NameLen);
+    Pos += NameLen;
+    *Pos++ = '=';
+    memcpy(Pos, Value, ValueLen);
+    Pos += ValueLen;
+    *Pos++ = '\0';
+  }
+  CEnv[NumEnv] = NULL;
+  
+  Result = LLVMRunFunctionAsMain(EE, F, NumArgs, CArgs, CEnv);
+  
+  free(CArgs);
+  free(CEnv);
+  free(CEnvBuf);
+  
+  CAMLreturn(Val_int(Result));
+}
+
+/* llvalue -> ExecutionEngine.t -> unit */
+CAMLprim value llvm_ee_free_machine_code(LLVMValueRef F,
+                                         LLVMExecutionEngineRef EE) {
+  LLVMFreeMachineCodeForFunction(EE, F);
+  return Val_unit;
+}
+

llvm/bindings/ocaml/executionengine/llvm_executionengine.ml

@@ -0,0 +1,106 @@
+(*===-- llvm_executionengine.ml - LLVM Ocaml Interface ----------*- C++ -*-===*
+ *
+ *                     The LLVM Compiler Infrastructure
+ *
+ * This file is distributed under the University of Illinois Open Source
+ * License. See LICENSE.TXT for details.
+ *
+ *===----------------------------------------------------------------------===*)
+
+
+exception Error of string
+
+external register_exns: exn -> unit
+  = "llvm_register_ee_exns"
+
+
+module GenericValue = struct
+  type t
+  
+  external of_float: Llvm.lltype -> float -> t
+    = "llvm_genericvalue_of_float"
+  external of_pointer: 'a -> t
+    = "llvm_genericvalue_of_value"
+  external of_int32: Llvm.lltype -> int32 -> t
+    = "llvm_genericvalue_of_int32"
+  external of_int: Llvm.lltype -> int -> t
+    = "llvm_genericvalue_of_int"
+  external of_nativeint: Llvm.lltype -> nativeint -> t
+    = "llvm_genericvalue_of_nativeint"
+  external of_int64: Llvm.lltype -> int64 -> t
+    = "llvm_genericvalue_of_int64"
+  
+  external as_float: Llvm.lltype -> t -> float
+    = "llvm_genericvalue_as_float"
+  external as_pointer: t -> 'a
+    = "llvm_genericvalue_as_value"
+  external as_int32: t -> int32
+    = "llvm_genericvalue_as_int32"
+  external as_int: t -> int
+    = "llvm_genericvalue_as_int"
+  external as_nativeint: t -> nativeint
+    = "llvm_genericvalue_as_nativeint"
+  external as_int64: t -> int64
+    = "llvm_genericvalue_as_int64"
+end
+
+
+module ExecutionEngine = struct
+  type t
+  
+  (* FIXME: Ocaml is not running this setup code unless we use 'val' in the
+            interface, which causes the emission of a stub for each function;
+            using 'external' in the module allows direct calls into 
+            ocaml_executionengine.c. This is hardly fatal, but it is unnecessary
+            overhead on top of the two stubs that are already invoked for each 
+            call into LLVM. *)
+  let _ = register_exns (Error "")
+  
+  external create: Llvm.llmoduleprovider -> t
+    = "llvm_ee_create"
+  external create_interpreter: Llvm.llmoduleprovider -> t
+    = "llvm_ee_create_interpreter"
+  external create_jit: Llvm.llmoduleprovider -> t
+    = "llvm_ee_create_jit"
+  external dispose: t -> unit
+    = "llvm_ee_dispose"
+  external add_module_provider: Llvm.llmoduleprovider -> t -> unit
+    = "llvm_ee_add_mp"
+  external remove_module_provider: Llvm.llmoduleprovider -> t -> Llvm.llmodule
+    = "llvm_ee_remove_mp"
+  external find_function: string -> t -> Llvm.llvalue option
+    = "llvm_ee_find_function"
+  external run_function: Llvm.llvalue -> GenericValue.t array -> t ->
+                         GenericValue.t
+    = "llvm_ee_run_function"
+  external run_static_ctors: t -> unit
+    = "llvm_ee_run_static_ctors"
+  external run_static_dtors: t -> unit
+    = "llvm_ee_run_static_dtors"
+  external run_function_as_main: Llvm.llvalue -> string array ->
+                                 (string * string) array -> t -> int
+    = "llvm_ee_run_function_as_main"
+  external free_machine_code: Llvm.llvalue -> t -> unit
+    = "llvm_ee_free_machine_code"
+  
+  (* The following are not bound. Patches are welcome.
+  
+  get_target_data: t -> lltargetdata
+  add_global_mapping: llvalue -> llgenericvalue -> t -> unit
+  clear_all_global_mappings: t -> unit
+  update_global_mapping: llvalue -> llgenericvalue -> t -> unit
+  get_pointer_to_global_if_available: llvalue -> t -> llgenericvalue
+  get_pointer_to_global: llvalue -> t -> llgenericvalue
+  get_pointer_to_function: llvalue -> t -> llgenericvalue
+  get_pointer_to_function_or_stub: llvalue -> t -> llgenericvalue
+  get_global_value_at_address: llgenericvalue -> t -> llvalue option
+  store_value_to_memory: llgenericvalue -> llgenericvalue -> lltype -> unit
+  initialize_memory: llvalue -> llgenericvalue -> t -> unit
+  recompile_and_relink_function: llvalue -> t -> llgenericvalue
+  get_or_emit_global_variable: llvalue -> t -> llgenericvalue
+  disable_lazy_compilation: t -> unit
+  lazy_compilation_enabled: t -> bool
+  install_lazy_function_creator: (string -> llgenericvalue) -> t -> unit
+  
+   *)
+end

llvm/bindings/ocaml/executionengine/llvm_executionengine.mli

@@ -0,0 +1,152 @@
+(*===-- llvm_executionengine.mli - LLVM Ocaml Interface ---------*- C++ -*-===*
+ *
+ *                     The LLVM Compiler Infrastructure
+ *
+ * This file is distributed under the University of Illinois Open Source
+ * License. See LICENSE.TXT for details.
+ *
+ *===----------------------------------------------------------------------===
+ *
+ * This interface provides an ocaml API for LLVM execution engine (JIT/
+ * interpreter), the classes in the ExecutionEngine library.
+ *
+ *===----------------------------------------------------------------------===*)
+
+
+exception Error of string
+
+
+module GenericValue: sig
+  (** [GenericValue.t] is a boxed union type used to portably pass arguments to
+      and receive values from the execution engine. It supports only a limited
+      selection of types; for more complex argument types, it is necessary to
+      generate a stub function by hand or to pass parameters by reference.
+      See the struct [llvm::GenericValue]. **)
+  type t
+  
+  (** [of_float fpty n] boxes the float [n] in a float-valued generic value
+      according to the floating point type [fpty]. See the fields 
+      [llvm::GenericValue::DoubleVal] and [llvm::GenericValue::FloatVal]. **)
+  val of_float: Llvm.lltype -> float -> t
+  
+  (** [of_pointer v] boxes the pointer value [v] in a generic value. See the
+      field [llvm::GenericValue::PointerVal]. **)
+  val of_pointer: 'a -> t
+  
+  (** [of_int32 n w] boxes the int32 [i] in a generic value with the bitwidth
+      [w]. See the field [llvm::GenericValue::IntVal]. **)
+  val of_int32: Llvm.lltype -> int32 -> t
+  
+  (** [of_int n w] boxes the int [i] in a generic value with the bitwidth
+      [w]. See the field [llvm::GenericValue::IntVal]. **)
+  val of_int: Llvm.lltype -> int -> t
+  
+  (** [of_natint n w] boxes the native int [i] in a generic value with the
+      bitwidth [w]. See the field [llvm::GenericValue::IntVal]. **)
+  val of_nativeint: Llvm.lltype -> nativeint -> t
+  
+  (** [of_int64 n w] boxes the int64 [i] in a generic value with the bitwidth
+      [w]. See the field [llvm::GenericValue::IntVal]. **)
+  val of_int64: Llvm.lltype -> int64 -> t
+  
+  (** [as_float fpty gv] unboxes the floating point-valued generic value [gv] of
+      floating point type [fpty]. See the fields [llvm::GenericValue::DoubleVal]
+      and [llvm::GenericValue::FloatVal]. **)
+  val as_float: Llvm.lltype -> t -> float
+  
+  (** [as_pointer gv] unboxes the pointer-valued generic value [gv]. See the
+      field [llvm::GenericValue::PointerVal]. **)
+  val as_pointer: t -> 'a
+  
+  (** [as_int32 gv] unboxes the integer-valued generic value [gv] as an [int32].
+      Is invalid if [gv] has a bitwidth greater than 32 bits. See the field
+      [llvm::GenericValue::IntVal]. **)
+  val as_int32: t -> int32
+  
+  (** [as_int gv] unboxes the integer-valued generic value [gv] as an [int].
+      Is invalid if [gv] has a bitwidth greater than the host bit width (but the
+      most significant bit may be lost). See the field
+      [llvm::GenericValue::IntVal]. **)
+  val as_int: t -> int
+  
+  (** [as_natint gv] unboxes the integer-valued generic value [gv] as a
+      [nativeint]. Is invalid if [gv] has a bitwidth greater than
+      [nativeint]. See the field [llvm::GenericValue::IntVal]. **)
+  val as_nativeint: t -> nativeint
+  
+  (** [as_int64 gv] returns the integer-valued generic value [gv] as an [int64].
+      Is invalid if [gv] has a bitwidth greater than [int64]. See the field
+      [llvm::GenericValue::IntVal]. **)
+  val as_int64: t -> int64
+end
+
+
+module ExecutionEngine: sig
+  (** An execution engine is either a JIT compiler or an interpreter, capable of
+      directly loading an LLVM module and executing its functions without first
+      invoking a static compiler and generating a native executable. **)
+  type t
+  
+  (** [create mp] creates a new execution engine, taking ownership of the
+      module provider [mp] if successful. Creates a JIT if possible, else falls
+      back to an interpreter. Raises [Error msg] if an error occurrs. The
+      execution engine is not garbage collected and must be destroyed with
+      [dispose ee]. See the function [llvm::ExecutionEngine::create]. **)
+  val create: Llvm.llmoduleprovider -> t
+  
+  (** [create_interpreter mp] creates a new interpreter, taking ownership of the
+      module provider [mp] if successful. Raises [Error msg] if an error
+      occurrs. The execution engine is not garbage collected and must be
+      destroyed with [dispose ee].
+      See the function [llvm::ExecutionEngine::create]. **)
+  val create_interpreter: Llvm.llmoduleprovider -> t
+  
+  (** [create_jit mp] creates a new JIT (just-in-time compiler), taking
+      ownership of the module provider [mp] if successful. Raises [Error msg] if
+      an error occurrs. The execution engine is not garbage collected and must
+      be destroyed with [dispose ee].
+      See the function [llvm::ExecutionEngine::create]. **)
+  val create_jit: Llvm.llmoduleprovider -> t
+  
+  (** [dispose ee] releases the memory used by the execution engine and must be
+      invoked to avoid memory leaks. **)
+  val dispose: t -> unit
+  
+  (** [add_module_provider mp ee] adds the module provider [mp] to the execution
+      engine [ee]. **)
+  val add_module_provider: Llvm.llmoduleprovider -> t -> unit
+  
+  (** [remove_module_provider mp ee] removes the module provider [mp] from the
+      execution engine [ee], disposing of [mp] and the module referenced by
+      [mp]. Raises [Error msg] if an error occurs. **)
+  val remove_module_provider: Llvm.llmoduleprovider -> t -> Llvm.llmodule
+  
+  (** [find_function n ee] finds the function named [n] defined in any of the 
+      modules owned by the execution engine [ee]. Returns [None] if the function
+      is not found and [Some f] otherwise. **)
+  val find_function: string -> t -> Llvm.llvalue option
+  
+  (** [run_function f args ee] synchronously executes the function [f] with the
+      arguments [args], which must be compatible with the parameter types. **)
+  val run_function: Llvm.llvalue -> GenericValue.t array -> t ->
+                    GenericValue.t
+  
+  (** [run_static_ctors ee] executes the static constructors of each module in
+      the execution engine [ee]. **)
+  val run_static_ctors: t -> unit
+  
+  (** [run_static_dtors ee] executes the static destructors of each module in
+      the execution engine [ee]. **)
+  val run_static_dtors: t -> unit
+  
+  (** [run_function_as_main f args env ee] executes the function [f] as a main 
+      function, passing it [argv] and [argc] according to the string array
+      [args], and [envp] as specified by the array [env]. Returns the integer 
+      return value of the function. **)
+  val run_function_as_main: Llvm.llvalue -> string array ->
+                            (string * string) array -> t -> int
+  
+  (** [free_machine_code f ee] releases the memory in the execution engine [ee]
+      used to store the machine code for the function [f]. **)
+  val free_machine_code: Llvm.llvalue -> t -> unit
+end

llvm/bindings/ocaml/llvm/Makefile

@@ -0,0 +1,20 @@
+##===- bindings/ocaml/bitwriter/Makefile -------------------*- Makefile -*-===##
+# 
+#                     The LLVM Compiler Infrastructure
+#
+# This file is distributed under the University of Illinois Open Source
+# License. See LICENSE.TXT for details.
+# 
+##===----------------------------------------------------------------------===##
+# 
+# This is the makefile for the Objective Caml Llvm interface.
+# 
+##===----------------------------------------------------------------------===##
+
+LEVEL := ../../..
+LIBRARYNAME := llvm
+DONT_BUILD_RELINKED := 1
+UsedComponents := core
+UsedOcamLibs := llvm
+
+include ../Makefile.ocaml

llvm/bindings/ocaml/llvm/llvm.ml

@@ -0,0 +1,526 @@
+(*===-- tools/ml/llvm.ml - LLVM Ocaml Interface ---------------------------===*
+ *
+ *                     The LLVM Compiler Infrastructure
+ *
+ * This file is distributed under the University of Illinois Open Source
+ * License. See LICENSE.TXT for details.
+ *
+ *===----------------------------------------------------------------------===*)
+
+
+type llmodule
+type lltype
+type lltypehandle
+type llvalue
+type llbasicblock
+type llbuilder
+type llmoduleprovider
+type llmemorybuffer
+
+module TypeKind = struct
+  type t =
+  | Void
+  | Float
+  | Double
+  | X86fp80
+  | Fp128
+  | Ppc_fp128
+  | Label
+  | Integer
+  | Function
+  | Struct
+  | Array
+  | Pointer
+  | Opaque
+  | Vector
+end
+
+module Linkage = struct
+  type t =
+  | External
+  | Link_once
+  | Weak
+  | Appending
+  | Internal
+  | Dllimport
+  | Dllexport
+  | External_weak
+  | Ghost
+end
+
+module Visibility = struct
+  type t =
+  | Default
+  | Hidden
+  | Protected
+end
+
+module CallConv = struct
+  let c = 0
+  let fast = 8
+  let cold = 9
+  let x86_stdcall = 64
+  let x86_fastcall = 65
+end
+
+module Icmp = struct
+  type t =
+  | Eq
+  | Ne
+  | Ugt
+  | Uge
+  | Ult
+  | Ule
+  | Sgt
+  | Sge
+  | Slt
+  | Sle
+end
+
+module Fcmp = struct
+  type t =
+  | False
+  | Oeq
+  | Ogt
+  | Oge
+  | Olt
+  | Ole
+  | One
+  | Ord
+  | Uno
+  | Ueq
+  | Ugt
+  | Uge
+  | Ult
+  | Ule
+  | Une
+  | True
+end
+
+exception IoError of string
+
+external register_exns : exn -> unit = "llvm_register_core_exns"
+let _ = register_exns (IoError "")
+
+
+(*===-- Modules -----------------------------------------------------------===*)
+
+external create_module : string -> llmodule = "llvm_create_module"
+external dispose_module : llmodule -> unit = "llvm_dispose_module"
+external target_triple: llmodule -> string
+                      = "llvm_target_triple"
+external set_target_triple: string -> llmodule -> unit
+                          = "llvm_set_target_triple"
+external data_layout: llmodule -> string
+                    = "llvm_data_layout"
+external set_data_layout: string -> llmodule -> unit
+                        = "llvm_set_data_layout"
+external define_type_name : string -> lltype -> llmodule -> bool
+                          = "llvm_add_type_name"
+external delete_type_name : string -> llmodule -> unit
+                          = "llvm_delete_type_name"
+
+
+(*===-- Types -------------------------------------------------------------===*)
+
+external classify_type : lltype -> TypeKind.t = "llvm_classify_type"
+
+(*--... Operations on integer types ........................................--*)
+external _i1_type : unit -> lltype = "llvm_i1_type"
+external _i8_type : unit -> lltype = "llvm_i8_type"
+external _i16_type : unit -> lltype = "llvm_i16_type"
+external _i32_type : unit -> lltype = "llvm_i32_type"
+external _i64_type : unit -> lltype = "llvm_i64_type"
+
+let i1_type = _i1_type ()
+let i8_type = _i8_type ()
+let i16_type = _i16_type ()
+let i32_type = _i32_type ()
+let i64_type = _i64_type ()
+
+external integer_type : int -> lltype = "llvm_integer_type"
+external integer_bitwidth : lltype -> int = "llvm_integer_bitwidth"
+
+(*--... Operations on real types ...........................................--*)
+external _float_type : unit -> lltype = "llvm_float_type"
+external _double_type : unit -> lltype = "llvm_double_type"
+external _x86fp80_type : unit -> lltype = "llvm_x86fp80_type"
+external _fp128_type : unit -> lltype = "llvm_fp128_type"
+external _ppc_fp128_type : unit -> lltype = "llvm_ppc_fp128_type"
+
+let float_type = _float_type ()
+let double_type = _double_type ()
+let x86fp80_type = _x86fp80_type ()
+let fp128_type = _fp128_type ()
+let ppc_fp128_type = _ppc_fp128_type ()
+
+(*--... Operations on function types .......................................--*)
+external function_type : lltype -> lltype array -> lltype = "llvm_function_type"
+external var_arg_function_type : lltype -> lltype array -> lltype
+                               = "llvm_var_arg_function_type"
+external is_var_arg : lltype -> bool = "llvm_is_var_arg"
+external return_type : lltype -> lltype = "LLVMGetReturnType"
+external param_types : lltype -> lltype array = "llvm_param_types"
+
+(*--... Operations on struct types .........................................--*)
+external struct_type : lltype array -> lltype = "llvm_struct_type"
+external packed_struct_type : lltype array -> lltype = "llvm_packed_struct_type"
+external element_types : lltype -> lltype array = "llvm_element_types"
+external is_packed : lltype -> bool = "llvm_is_packed"
+
+(*--... Operations on pointer, vector, and array types .....................--*)
+external array_type : lltype -> int -> lltype = "llvm_array_type"
+external pointer_type : lltype -> lltype = "llvm_pointer_type"
+external qualified_pointer_type : lltype -> int -> lltype
+                                = "llvm_qualified_pointer_type"
+external vector_type : lltype -> int -> lltype = "llvm_vector_type"
+
+external element_type : lltype -> lltype = "LLVMGetElementType"
+external array_length : lltype -> int = "llvm_array_length"
+external address_space : lltype -> int = "llvm_address_space"
+external vector_size : lltype -> int = "llvm_vector_size"
+
+(*--... Operations on other types ..........................................--*)
+external opaque_type : unit -> lltype = "llvm_opaque_type"
+external _void_type : unit -> lltype = "llvm_void_type"
+external _label_type : unit -> lltype = "llvm_label_type"
+
+let void_type = _void_type ()
+let label_type = _label_type ()
+
+(*--... Operations on type handles .........................................--*)
+external handle_to_type : lltype -> lltypehandle = "llvm_handle_to_type"
+external type_of_handle : lltypehandle -> lltype = "llvm_type_of_handle"
+external refine_type : lltype -> lltype -> unit = "llvm_refine_type"
+
+
+(*===-- Values ------------------------------------------------------------===*)
+
+external type_of : llvalue -> lltype = "llvm_type_of"
+external value_name : llvalue -> string = "llvm_value_name"
+external set_value_name : string -> llvalue -> unit = "llvm_set_value_name"
+external dump_value : llvalue -> unit = "llvm_dump_value"
+
+(*--... Operations on constants of (mostly) any type .......................--*)
+external is_constant : llvalue -> bool = "llvm_is_constant"
+external const_null : lltype -> llvalue = "LLVMConstNull"
+external const_all_ones : (*int|vec*)lltype -> llvalue = "LLVMConstAllOnes"
+external undef : lltype -> llvalue = "LLVMGetUndef"
+external is_null : llvalue -> bool = "llvm_is_null"
+external is_undef : llvalue -> bool = "llvm_is_undef"
+
+(*--... Operations on scalar constants .....................................--*)
+external const_int : lltype -> int -> llvalue = "llvm_const_int"
+external const_of_int64 : lltype -> Int64.t -> bool -> llvalue
+                        = "llvm_const_of_int64"
+external const_float : lltype -> float -> llvalue = "llvm_const_float"
+
+(*--... Operations on composite constants ..................................--*)
+external const_string : string -> llvalue = "llvm_const_string"
+external const_stringz : string -> llvalue = "llvm_const_stringz"
+external const_array : lltype -> llvalue array -> llvalue = "llvm_const_array"
+external const_struct : llvalue array -> llvalue = "llvm_const_struct"
+external const_packed_struct : llvalue array -> llvalue
+                             = "llvm_const_packed_struct"
+external const_vector : llvalue array -> llvalue = "llvm_const_vector"
+
+(*--... Constant expressions ...............................................--*)
+external size_of : lltype -> llvalue = "LLVMSizeOf"
+external const_neg : llvalue -> llvalue = "LLVMConstNeg"
+external const_not : llvalue -> llvalue = "LLVMConstNot"
+external const_add : llvalue -> llvalue -> llvalue = "LLVMConstAdd"
+external const_sub : llvalue -> llvalue -> llvalue = "LLVMConstSub"
+external const_mul : llvalue -> llvalue -> llvalue = "LLVMConstMul"
+external const_udiv : llvalue -> llvalue -> llvalue = "LLVMConstUDiv"
+external const_sdiv : llvalue -> llvalue -> llvalue = "LLVMConstSDiv"
+external const_fdiv : llvalue -> llvalue -> llvalue = "LLVMConstFDiv"
+external const_urem : llvalue -> llvalue -> llvalue = "LLVMConstURem"
+external const_srem : llvalue -> llvalue -> llvalue = "LLVMConstSRem"
+external const_frem : llvalue -> llvalue -> llvalue = "LLVMConstFRem"
+external const_and : llvalue -> llvalue -> llvalue = "LLVMConstAnd"
+external const_or : llvalue -> llvalue -> llvalue = "LLVMConstOr"
+external const_xor : llvalue -> llvalue -> llvalue = "LLVMConstXor"
+external const_icmp : Icmp.t -> llvalue -> llvalue -> llvalue
+                    = "llvm_const_icmp"
+external const_fcmp : Fcmp.t -> llvalue -> llvalue -> llvalue
+                    = "llvm_const_fcmp"
+external const_shl : llvalue -> llvalue -> llvalue = "LLVMConstShl"
+external const_lshr : llvalue -> llvalue -> llvalue = "LLVMConstLShr"
+external const_ashr : llvalue -> llvalue -> llvalue = "LLVMConstAShr"
+external const_gep : llvalue -> llvalue array -> llvalue = "llvm_const_gep"
+external const_trunc : llvalue -> lltype -> llvalue = "LLVMConstTrunc"
+external const_sext : llvalue -> lltype -> llvalue = "LLVMConstSExt"
+external const_zext : llvalue -> lltype -> llvalue = "LLVMConstZExt"
+external const_fptrunc : llvalue -> lltype -> llvalue = "LLVMConstFPTrunc"
+external const_fpext : llvalue -> lltype -> llvalue = "LLVMConstFPExt"
+external const_uitofp : llvalue -> lltype -> llvalue = "LLVMConstUIToFP"
+external const_sitofp : llvalue -> lltype -> llvalue = "LLVMConstSIToFP"
+external const_fptoui : llvalue -> lltype -> llvalue = "LLVMConstFPToUI"
+external const_fptosi : llvalue -> lltype -> llvalue = "LLVMConstFPToSI"
+external const_ptrtoint : llvalue -> lltype -> llvalue = "LLVMConstPtrToInt"
+external const_inttoptr : llvalue -> lltype -> llvalue = "LLVMConstIntToPtr"
+external const_bitcast : llvalue -> lltype -> llvalue = "LLVMConstBitCast"
+external const_select : llvalue -> llvalue -> llvalue -> llvalue
+                      = "LLVMConstSelect"
+external const_extractelement : llvalue -> llvalue -> llvalue
+                              = "LLVMConstExtractElement"
+external const_insertelement : llvalue -> llvalue -> llvalue -> llvalue
+                             = "LLVMConstInsertElement"
+external const_shufflevector : llvalue -> llvalue -> llvalue -> llvalue
+                             = "LLVMConstShuffleVector"
+
+(*--... Operations on global variables, functions, and aliases (globals) ...--*)
+external is_declaration : llvalue -> bool = "llvm_is_declaration"
+external linkage : llvalue -> Linkage.t = "llvm_linkage"
+external set_linkage : Linkage.t -> llvalue -> unit = "llvm_set_linkage"
+external section : llvalue -> string = "llvm_section"
+external set_section : string -> llvalue -> unit = "llvm_set_section"
+external visibility : llvalue -> Visibility.t = "llvm_visibility"
+external set_visibility : Visibility.t -> llvalue -> unit = "llvm_set_visibility"
+external alignment : llvalue -> int = "llvm_alignment"
+external set_alignment : int -> llvalue -> unit = "llvm_set_alignment"
+external is_global_constant : llvalue -> bool = "llvm_is_global_constant"
+external set_global_constant : bool -> llvalue -> unit
+                             = "llvm_set_global_constant"
+
+(*--... Operations on global variables .....................................--*)
+external declare_global : lltype -> string -> llmodule -> llvalue
+                        = "llvm_declare_global"
+external define_global : string -> llvalue -> llmodule -> llvalue
+                       = "llvm_define_global"
+external lookup_global : string -> llmodule -> llvalue option
+                       = "llvm_lookup_global"
+external delete_global : llvalue -> unit = "llvm_delete_global"
+external has_initializer : llvalue -> bool = "llvm_has_initializer"
+external global_initializer : llvalue -> llvalue = "LLVMGetInitializer"
+external set_initializer : llvalue -> llvalue -> unit = "llvm_set_initializer"
+external remove_initializer : llvalue -> unit = "llvm_remove_initializer"
+external is_thread_local : llvalue -> bool = "llvm_is_thread_local"
+external set_thread_local : bool -> llvalue -> unit = "llvm_set_thread_local"
+
+(*--... Operations on functions ............................................--*)
+external declare_function : string -> lltype -> llmodule -> llvalue
+                          = "llvm_declare_function"
+external define_function : string -> lltype -> llmodule -> llvalue
+                         = "llvm_define_function"
+external lookup_function : string -> llmodule -> llvalue option
+                         = "llvm_lookup_function"
+external delete_function : llvalue -> unit = "llvm_delete_function"
+external params : llvalue -> llvalue array = "llvm_params"
+external param : llvalue -> int -> llvalue = "llvm_param"
+external is_intrinsic : llvalue -> bool = "llvm_is_intrinsic"
+external function_call_conv : llvalue -> int = "llvm_function_call_conv"
+external set_function_call_conv : int -> llvalue -> unit
+                                = "llvm_set_function_call_conv"
+external collector : llvalue -> string option = "llvm_collector"
+external set_collector : string option -> llvalue -> unit = "llvm_set_collector"
+
+(* TODO: param attrs *)
+
+(*--... Operations on basic blocks .........................................--*)
+external basic_blocks : llvalue -> llbasicblock array = "llvm_basic_blocks"
+external entry_block : llvalue -> llbasicblock = "LLVMGetEntryBasicBlock"
+external delete_block : llbasicblock -> unit = "llvm_delete_block"
+external append_block : string -> llvalue -> llbasicblock = "llvm_append_block"
+external insert_block : string -> llbasicblock -> llbasicblock
+                      = "llvm_insert_block"
+external value_of_block : llbasicblock -> llvalue = "LLVMBasicBlockAsValue"
+external value_is_block : llvalue -> bool = "llvm_value_is_block"
+external block_of_value : llvalue -> llbasicblock = "LLVMValueAsBasicBlock"
+
+(*--... Operations on call sites ...........................................--*)
+external instruction_call_conv: llvalue -> int
+                              = "llvm_instruction_call_conv"
+external set_instruction_call_conv: int -> llvalue -> unit
+                                  = "llvm_set_instruction_call_conv"
+
+(*--... Operations on phi nodes ............................................--*)
+external add_incoming : (llvalue * llbasicblock) -> llvalue -> unit
+                      = "llvm_add_incoming"
+external incoming : llvalue -> (llvalue * llbasicblock) list = "llvm_incoming"
+
+
+(*===-- Instruction builders ----------------------------------------------===*)
+external builder: unit-> llbuilder
+                = "llvm_builder"
+external builder_before : llvalue -> llbuilder = "llvm_builder_before"
+external builder_at_end : llbasicblock -> llbuilder = "llvm_builder_at_end"
+external position_before : llvalue -> llbuilder -> unit = "llvm_position_before"
+external position_at_end : llbasicblock -> llbuilder -> unit
+                         = "llvm_position_at_end"
+
+(*--... Terminators ........................................................--*)
+external build_ret_void : llbuilder -> llvalue = "llvm_build_ret_void"
+external build_ret : llvalue -> llbuilder -> llvalue = "llvm_build_ret"
+external build_br : llbasicblock -> llbuilder -> llvalue = "llvm_build_br"
+external build_cond_br : llvalue -> llbasicblock -> llbasicblock -> llbuilder ->
+                         llvalue = "llvm_build_cond_br"
+external build_switch : llvalue -> llbasicblock -> int -> llbuilder -> llvalue
+                      = "llvm_build_switch"
+external build_invoke : llvalue -> llvalue array -> llbasicblock ->
+                        llbasicblock -> string -> llbuilder -> llvalue
+                      = "llvm_build_invoke_bc" "llvm_build_invoke_nat"
+external build_unwind : llbuilder -> llvalue = "llvm_build_unwind"
+external build_unreachable : llbuilder -> llvalue = "llvm_build_unreachable"
+
+(*--... Arithmetic .........................................................--*)
+external build_add : llvalue -> llvalue -> string -> llbuilder -> llvalue
+                   = "llvm_build_add"
+external build_sub : llvalue -> llvalue -> string -> llbuilder -> llvalue
+                   = "llvm_build_sub"
+external build_mul : llvalue -> llvalue -> string -> llbuilder -> llvalue
+                   = "llvm_build_mul"
+external build_udiv : llvalue -> llvalue -> string -> llbuilder -> llvalue
+                    = "llvm_build_udiv"
+external build_sdiv : llvalue -> llvalue -> string -> llbuilder -> llvalue
+                    = "llvm_build_sdiv"
+external build_fdiv : llvalue -> llvalue -> string -> llbuilder -> llvalue
+                    = "llvm_build_fdiv"
+external build_urem : llvalue -> llvalue -> string -> llbuilder -> llvalue
+                    = "llvm_build_urem"
+external build_srem : llvalue -> llvalue -> string -> llbuilder -> llvalue
+                    = "llvm_build_srem"
+external build_frem : llvalue -> llvalue -> string -> llbuilder -> llvalue
+                    = "llvm_build_frem"
+external build_shl : llvalue -> llvalue -> string -> llbuilder -> llvalue
+                   = "llvm_build_shl"
+external build_lshr : llvalue -> llvalue -> string -> llbuilder -> llvalue
+                    = "llvm_build_lshr"
+external build_ashr : llvalue -> llvalue -> string -> llbuilder -> llvalue
+                    = "llvm_build_ashr"
+external build_and : llvalue -> llvalue -> string -> llbuilder -> llvalue
+                   = "llvm_build_and"
+external build_or : llvalue -> llvalue -> string -> llbuilder -> llvalue
+                  = "llvm_build_or"
+external build_xor : llvalue -> llvalue -> string -> llbuilder -> llvalue
+                   = "llvm_build_xor"
+external build_neg : llvalue -> string -> llbuilder -> llvalue
+                   = "llvm_build_neg"
+external build_not : llvalue -> string -> llbuilder -> llvalue
+                   = "llvm_build_not"
+
+(*--... Memory .............................................................--*)
+external build_malloc : lltype -> string -> llbuilder -> llvalue
+                      = "llvm_build_malloc"
+external build_array_malloc : lltype -> llvalue -> string -> llbuilder ->
+                              llvalue = "llvm_build_array_malloc"
+external build_alloca : lltype -> string -> llbuilder -> llvalue
+                      = "llvm_build_alloca"
+external build_array_alloca : lltype -> llvalue -> string -> llbuilder ->
+                              llvalue = "llvm_build_array_alloca"
+external build_free : llvalue -> llbuilder -> llvalue = "llvm_build_free"
+external build_load : llvalue -> string -> llbuilder -> llvalue
+                    = "llvm_build_load"
+external build_store : llvalue -> llvalue -> llbuilder -> llvalue
+                     = "llvm_build_store"
+external build_gep : llvalue -> llvalue array -> string -> llbuilder -> llvalue
+                   = "llvm_build_gep"
+
+(*--... Casts ..............................................................--*)
+external build_trunc : llvalue -> lltype -> string -> llbuilder -> llvalue
+                     = "llvm_build_trunc"
+external build_zext : llvalue -> lltype -> string -> llbuilder -> llvalue
+                    = "llvm_build_zext"
+external build_sext : llvalue -> lltype -> string -> llbuilder -> llvalue
+                    = "llvm_build_sext"
+external build_fptoui : llvalue -> lltype -> string -> llbuilder -> llvalue
+                      = "llvm_build_fptoui"
+external build_fptosi : llvalue -> lltype -> string -> llbuilder -> llvalue
+                      = "llvm_build_fptosi"
+external build_uitofp : llvalue -> lltype -> string -> llbuilder -> llvalue
+                      = "llvm_build_uitofp"
+external build_sitofp : llvalue -> lltype -> string -> llbuilder -> llvalue
+                      = "llvm_build_sitofp"
+external build_fptrunc : llvalue -> lltype -> string -> llbuilder -> llvalue
+                       = "llvm_build_fptrunc"
+external build_fpext : llvalue -> lltype -> string -> llbuilder -> llvalue
+                     = "llvm_build_fpext"
+external build_ptrtoint : llvalue -> lltype -> string -> llbuilder -> llvalue
+                        = "llvm_build_prttoint"
+external build_inttoptr : llvalue -> lltype -> string -> llbuilder -> llvalue
+                        = "llvm_build_inttoptr"
+external build_bitcast : llvalue -> lltype -> string -> llbuilder -> llvalue
+                       = "llvm_build_bitcast"
+
+(*--... Comparisons ........................................................--*)
+external build_icmp : Icmp.t -> llvalue -> llvalue -> string ->
+                      llbuilder -> llvalue = "llvm_build_icmp"
+external build_fcmp : Fcmp.t -> llvalue -> llvalue -> string ->
+                      llbuilder -> llvalue = "llvm_build_fcmp"
+
+(*--... Miscellaneous instructions .........................................--*)
+external build_phi : (llvalue * llbasicblock) list -> string -> llbuilder ->
+                     llvalue = "llvm_build_phi"
+external build_call : llvalue -> llvalue array -> string -> llbuilder -> llvalue
+                    = "llvm_build_call"
+external build_select : llvalue -> llvalue -> llvalue -> string -> llbuilder ->
+                        llvalue = "llvm_build_select"
+external build_va_arg : llvalue -> lltype -> string -> llbuilder -> llvalue
+                      = "llvm_build_va_arg"
+external build_extractelement : llvalue -> llvalue -> string -> llbuilder ->
+                                llvalue = "llvm_build_extractelement"
+external build_insertelement : llvalue -> llvalue -> llvalue -> string ->
+                               llbuilder -> llvalue = "llvm_build_insertelement"
+external build_shufflevector : llvalue -> llvalue -> llvalue -> string ->
+                               llbuilder -> llvalue = "llvm_build_shufflevector"
+
+
+(*===-- Module providers --------------------------------------------------===*)
+
+module ModuleProvider = struct
+  external create : llmodule -> llmoduleprovider
+                  = "LLVMCreateModuleProviderForExistingModule"
+  external dispose : llmoduleprovider -> unit = "llvm_dispose_module_provider"
+end
+  
+
+(*===-- Memory buffers ----------------------------------------------------===*)
+
+module MemoryBuffer = struct
+  external of_file : string -> llmemorybuffer = "llvm_memorybuffer_of_file"
+  external of_stdin : unit -> llmemorybuffer = "llvm_memorybuffer_of_stdin"
+  external dispose : llmemorybuffer -> unit = "llvm_memorybuffer_dispose"
+end
+
+
+(*===-- Non-Externs -------------------------------------------------------===*)
+(* These functions are built using the externals, so must be declared late.   *)
+
+let concat2 sep arr =
+  let s = ref "" in
+  if 0 < Array.length arr then begin
+    s := !s ^ arr.(0);
+    for i = 1 to (Array.length arr) - 1 do
+      s := !s ^ sep ^ arr.(i)
+    done
+  end;
+  !s
+
+let rec string_of_lltype ty =
+  (* FIXME: stop infinite recursion! :) *)
+  match classify_type ty with
+    TypeKind.Integer -> "i" ^ string_of_int (integer_bitwidth ty)
+  | TypeKind.Pointer -> (string_of_lltype (element_type ty)) ^ "*"
+  | TypeKind.Struct ->
+      let s = "{ " ^ (concat2 ", " (
+                Array.map string_of_lltype (element_types ty)
+              )) ^ " }" in
+      if is_packed ty
+        then "<" ^ s ^ ">"
+        else s
+  | TypeKind.Array -> "["   ^ (string_of_int (array_length ty)) ^
+                      " x " ^ (string_of_lltype (element_type ty)) ^ "]"
+  | TypeKind.Vector -> "<"   ^ (string_of_int (vector_size ty)) ^
+                       " x " ^ (string_of_lltype (element_type ty)) ^ ">"
+  | TypeKind.Opaque -> "opaque"
+  | TypeKind.Function -> string_of_lltype (return_type ty) ^
+                         " (" ^ (concat2 ", " (
+                           Array.map string_of_lltype (param_types ty)
+                         )) ^ ")"
+  | TypeKind.Label -> "label"
+  | TypeKind.Ppc_fp128 -> "ppc_fp128"
+  | TypeKind.Fp128 -> "fp128"
+  | TypeKind.X86fp80 -> "x86_fp80"
+  | TypeKind.Double -> "double"
+  | TypeKind.Float -> "float"
+  | TypeKind.Void -> "void"

llvm/build-for-llvm-top.sh

@@ -0,0 +1,58 @@
+#!/bin/sh
+
+# This includes the Bourne shell library from llvm-top. Since this file is
+# generally only used when building from llvm-top, it is safe to assume that
+# llvm is checked out into llvm-top in which case .. just works.
+. ../library.sh
+
+# Process the options passed in to us by the build script into standard
+# variables. 
+process_arguments "$@"
+
+# See if we have previously been configured by sensing the presence
+# of the config.status scripts
+if test ! -x "config.status" ; then
+  # We must configure so build a list of configure options
+  config_options="--prefix=$PREFIX --with-llvmgccdir=$PREFIX"
+  if test "$OPTIMIZED" -eq 1 ; then
+    config_options="$config_options --enable-optimized"
+  else
+    config_options="$config_options --disable-optimized"
+  fi
+  if test "$DEBUG" -eq 1 ; then
+    config_options="$config_options --enable-debug"
+  else
+    config_options="$config_options --disable-debug"
+  fi
+  if test "$ASSERTIONS" -eq 1 ; then
+    config_options="$config_options --enable-assertions"
+  else
+    config_options="$config_options --disable-assertions"
+  fi
+  if test "$CHECKING" -eq 1 ; then
+    config_options="$config_options --enable-expensive-checks"
+  else
+    config_options="$config_options --disable-expensive-checks"
+  fi
+  if test "$DOXYGEN" -eq 1 ; then
+    config_options="$config_options --enable-doxygen"
+  else
+    config_options="$config_options --disable-doxygen"
+  fi
+  if test "$THREADS" -eq 1 ; then
+    config_options="$config_options --enable-threads"
+  else
+    config_options="$config_options --disable-threads"
+  fi
+  config_options="$config_options $OPTIONS_DASH $OPTIONS_DASH_DASH"
+  msg 0 Configuring $module with:
+  msg 0 "  ./configure" $config_options
+  $LLVM_TOP/llvm/configure $config_options || \
+    die $? "Configuring llvm module failed"
+else
+  msg 0 Module $module already configured, ignoring configure options.
+fi
+
+msg 0 Building $module with:
+msg 0 "  make" $OPTIONS_ASSIGN tools-only
+make $OPTIONS_ASSIGN tools-only

llvm/docs/.cvsignore

@@ -1,4 +0,0 @@
-doxygen.cfg
-doxygen
-doxygen.out
-*.tar.gz

llvm/docs/AliasAnalysis.html

@@ -50,6 +50,7 @@
     implementations</a></li>
     </ul>
   </li>
+  <li><a href="#memdep">Memory Dependence Analysis</a></li>
 </ol>
 
 <div class="doc_author">
@@ -755,6 +756,9 @@ field-<b>sensitive</b>" version of Steensgaard's algorithm using the Data
 Structure Analysis framework.  This gives it substantially more precision than
 the standard algorithm while maintaining excellent analysis scalability.</p>
 
+<p>Note that <tt>-steens-aa</tt> is available in the optional "poolalloc"
+module, it is not part of the LLVM core.</p>
+
 </div>
 
 <!-- _______________________________________________________________________ -->
@@ -775,6 +779,9 @@ queries, and can provide context-sensitive mod/ref information as well.  The
 only major facility not implemented so far is support for must-alias
 information.</p>
 
+<p>Note that <tt>-ds-aa</tt> is available in the optional "poolalloc"
+module, it is not part of the LLVM core.</p>
+
 </div>
 
 
@@ -941,6 +948,24 @@ algorithm will have a lower number of may aliases).</p>
 
 </div>
 
+<!-- *********************************************************************** -->
+<div class="doc_section">
+  <a name="memdep">Memory Dependence Analysis</a>
+</div>
+<!-- *********************************************************************** -->
+
+<div class="doc_text">
+
+<p>If you're just looking to be a client of alias analysis information, consider
+using the Memory Dependence Analysis interface instead.  MemDep is a lazy, 
+caching layer on top of alias analysis that is able to answer the question of
+what preceding memory operations a given instruction depends on, either at an
+intra- or inter-block level.  Because of its laziness and caching 
+policy, using MemDep can be a significant performance win over accessing alias
+analysis directly.</p>
+
+</div>
+
 <!-- *********************************************************************** -->
 
 <hr>

llvm/docs/BOOST_LICENSE_1_0.txt

@@ -0,0 +1,23 @@
+Boost Software License - Version 1.0 - August 17th, 2003
+
+Permission is hereby granted, free of charge, to any person or organization
+obtaining a copy of the software and accompanying documentation covered by
+this license (the "Software") to use, reproduce, display, distribute,
+execute, and transmit the Software, and to prepare derivative works of the
+Software, and to permit third-parties to whom the Software is furnished to
+do so, all subject to the following:
+
+The copyright notices in the Software and this entire statement, including
+the above license grant, this restriction and the following disclaimer,
+must be included in all copies of the Software, in whole or in part, and
+all derivative works of the Software, unless such copies or derivative
+works are solely in the form of machine-executable object code generated by
+a source language processor.
+
+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, TITLE AND NON-INFRINGEMENT. IN NO EVENT
+SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE
+FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE,
+ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+DEALINGS IN THE SOFTWARE.

llvm/docs/BitCodeFormat.html

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

llvm/docs/Bugpoint.html

@@ -123,7 +123,7 @@ 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
+passes crash, give you a bitcode file, and give you instructions on how to
 reproduce the failure with <tt>opt</tt> or <tt>llc</tt>.</p>
 
 </div>
@@ -141,7 +141,7 @@ 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
+potential scope of the problem.  After it is finished, it emits two bitcode
 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

llvm/docs/CFEBuildInstrs.html

@@ -45,7 +45,7 @@ the past.</p>
 
 <div class="doc_code">
 <pre>
-svn co svn://anonsvn.opensource.apple.com/svn/llvm/trunk <i>dst-directory</i>
+svn co http://llvm.org/svn/llvm-project/llvm-gcc-4.0/trunk <i>dst-directory</i>
 </pre>
 </div>
 

llvm/docs/CodeGenerator.html

@@ -719,8 +719,7 @@ comes from.</p>
 corresponds one-to-one with the LLVM function input to the instruction selector.
 In addition to a list of basic blocks, the <tt>MachineFunction</tt> contains a
 a <tt>MachineConstantPool</tt>, a <tt>MachineFrameInfo</tt>, a
-<tt>MachineFunctionInfo</tt>, a <tt>SSARegMap</tt>, and a set of live in and
-live out registers for the function.  See
+<tt>MachineFunctionInfo</tt>, and a <tt>MachineRegisterInfo</tt>.  See
 <tt>include/llvm/CodeGen/MachineFunction.h</tt> for more information.</p>
 
 </div>
@@ -748,16 +747,14 @@ explains how they work and some of the rationale behind their design.</p>
 <p>
 Instruction Selection is the process of translating LLVM code presented to the
 code generator into target-specific machine instructions.  There are several
-well-known ways to do this in the literature.  In LLVM there are two main forms:
-the SelectionDAG based instruction selector framework and an old-style 'simple'
-instruction selector, which effectively peephole selects each LLVM instruction
-into a series of machine instructions.  We recommend that all targets use the
-SelectionDAG infrastructure.
+well-known ways to do this in the literature.  LLVM uses a SelectionDAG based
+instruction selector.
 </p>
 
 <p>Portions of the DAG instruction selector are generated from the target 
 description (<tt>*.td</tt>) files.  Our goal is for the entire instruction
-selector to be generated from these <tt>.td</tt> files.</p>
+selector to be generated from these <tt>.td</tt> files, though currently
+there are still things that require custom C++ code.</p>
 </div>
 
 <!-- _______________________________________________________________________ -->
@@ -865,7 +862,11 @@ of the code compiled (if you only get errors printed to the console while using
 this, you probably <a href="ProgrammersManual.html#ViewGraph">need to configure
 your system</a> to add support for it).  The <tt>-view-sched-dags</tt> option
 views the SelectionDAG output from the Select phase and input to the Scheduler
-phase.</p>
+phase.  The <tt>-view-sunit-dags</tt> option views the ScheduleDAG, which is
+based on the final SelectionDAG, with nodes that must be scheduled as a unit
+bundled together into a single node, and with immediate operands and other
+nodes that aren't relevent for scheduling omitted.
+</p>
 
 </div>
 
@@ -1111,7 +1112,8 @@ primarily because it is a work in progress and is not yet finished:</p>
 <li>There is no great way to support matching complex addressing modes yet.  In
     the future, we will extend pattern fragments to allow them to define
     multiple values (e.g. the four operands of the <a href="#x86_memory">X86
-    addressing mode</a>).  In addition, we'll extend fragments so that a
+    addressing mode</a>, which are currently matched with custom C++ code).
+    In addition, we'll extend fragments so that a
     fragment can match multiple different patterns.</li>
 <li>We don't automatically infer flags like isStore/isLoad yet.</li>
 <li>We don't automatically generate the set of supported registers and
@@ -1310,8 +1312,8 @@ bool RegMapping_Fer::compatible_class(MachineFunction &amp;mf,
                                       unsigned p_reg) {
   assert(MRegisterInfo::isPhysicalRegister(p_reg) &amp;&amp;
          "Target register must be physical");
-  const TargetRegisterClass *trc = mf.getSSARegMap()->getRegClass(v_reg);
-  return trc->contains(p_reg);
+  const TargetRegisterClass *trc = mf.getRegInfo().getRegClass(v_reg);
+  return trc-&gt;contains(p_reg);
 }
 </pre>
 </div>
@@ -1340,7 +1342,7 @@ register. Whereas physical registers are statically defined in a
 <tt>TargetRegisterInfo.td</tt> file and cannot be created by the
 application developer, that is not the case with virtual registers.
 In order to create new virtual registers, use the method
-<tt>SSARegMap::createVirtualRegister()</tt>. This method will return a
+<tt>MachineRegisterInfo::createVirtualRegister()</tt>. This method will return a
 virtual register with the highest code.
 </p>
 
@@ -1357,7 +1359,7 @@ if that register is being used by the instruction. The method
 <tt>MachineOperand::isDef()</tt> informs if that registers is being
 defined.</p>
 
-<p>We will call physical registers present in the LLVM bytecode before
+<p>We will call physical registers present in the LLVM bitcode before
 register allocation <i>pre-colored registers</i>. Pre-colored
 registers are used in many different situations, for instance, to pass
 parameters of functions calls, and to store results of particular
@@ -1628,11 +1630,9 @@ are specific to the code generator for a particular target.</p>
 <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 sub-target support added for specific processor families and 
-implementations.</p>
+code generator is capable of targeting a variety of x86-32 and x86-64
+processors, and includes support for ISA extensions such as MMX and SSE.
+</p>
 
 </div>
 

llvm/docs/CodingStandards.html

@@ -122,9 +122,9 @@ documentation is very useful:</p>
 
 <b>File Headers</b>
 
-<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
-should not be checked into CVS.  Most source trees will probably have a standard
+<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 should not be 
+checked into Subversion.  Most source trees will probably have a standard
 file header format.  The standard format for the LLVM source tree looks like
 this:</p>
 
@@ -134,8 +134,8 @@ this:</p>
 // 
 //                     The LLVM Compiler Infrastructure
 //
-// This file was developed by &lt;whoever started the file&gt; and is distributed under
-// the University of Illinois Open Source License. See LICENSE.TXT for details.
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
 // 
 //===----------------------------------------------------------------------===//
 //
@@ -146,9 +146,7 @@ this:</p>
 </pre>
 </div>
 
-<p>A few things to note about this particular format:  The 'developed by' line
-should be the name of the person or organization who initially contributed the 
-file.  The "<tt>-*- C++
+<p>A few things to note about this particular format:  The "<tt>-*- C++
 -*-</tt>" string on the first line is there to tell Emacs that the source file
 is a C++ file, not a C file (Emacs assumes .h files are C files by default).
 Note that this tag is not necessary in .cpp files.  The name of the file is also
@@ -156,9 +154,9 @@ 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>
+<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 and should not be modified in any way.</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
@@ -505,14 +503,15 @@ library. There are two problems with this:</p>
 
 <ol>
   <li>The time to run the static c'tors impacts startup time of
-      applications&mdash;a critical time for gui apps.</li>
+      applications&mdash;a critical time for GUI apps.</li>
   <li>The static c'tors cause the app to pull many extra pages of memory off the
-      disk: both the code for the static c'tors in each .o file and the small
-      amount of data that gets touched.  In addition, touched/dirty pages put
-      more pressure on the VM system on low-memory machines.</li>
+      disk: both the code for the static c'tors in each <tt>.o</tt> file and the
+      small amount of data that gets touched. In addition, touched/dirty pages
+      put more pressure on the VM system on low-memory machines.</li>
 </ol>
 
-<table align="center">
+<div align="center">
+<table>
   <tbody>
     <tr>
       <th>Old Way</th>
@@ -526,7 +525,7 @@ library. There are two problems with this:</p>
       <td align="left"><pre>DEBUG(std::cerr &lt;&lt; ...);
 DEBUG(dump(std::cerr));</pre></td>
       <td align="left"><pre>DOUT &lt;&lt; ...;
-dump(DOUT);</pre></td>
+DEBUG(dump(DOUT));</pre></td>
     </tr>
     <tr>
       <td align="left"><pre>std::cerr &lt;&lt; "Hello world\n";</pre></td>
@@ -553,19 +552,21 @@ dump(DOUT);</pre></td>
       <td align="left"><pre>llvm::StringStream</pre></td>
     </tr>
     <tr>
-      <td align="left"><pre>void print(std::ostream &Out);
+      <td align="left"><pre>void print(std::ostream &amp;Out);
 // ...
 print(std::cerr);</pre></td>
-      <td align="left"><pre>void print(std::ostream &Out);
-void print(std::ostream *Out) { if (Out) print(*Out) }
+      <td align="left"><pre>void print(llvm::OStream Out);<sup>1</sup>
 // ...
 print(llvm::cerr);</pre>
 
-<ul><i>N.B.</i> The second <tt>print</tt> method is called by the <tt>print</tt>
-expression. It prevents the execution of the first <tt>print</tt> method if the
-stream is <tt>cnull</tt>.</ul></td>
-   </tbody>
-</table>
+</td> </tbody> </table>
+</div>
+
+<div class="doc_text">
+<p><sup>1</sup><tt>llvm::OStream</tt> is a light-weight class so it should never
+be passed by reference. This is important because in some configurations,
+<tt>DOUT</tt> is an rvalue.</p>
+</div>
 
 </div>
 
@@ -734,15 +735,12 @@ 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
-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
+<li><a href="http://www.amazon.com/Effective-Specific-Addison-Wesley-Professional-Computing/dp/0321334876">Effective
+C++</a> by Scott Meyers.  Also 
 interesting and useful are "More Effective C++" and "Effective STL" by the same
 author.</li>
 
-<li><a href="http://cseng.aw.com/book/0,3828,0201633620,00.html">Large-Scale C++
-Software Design</a> by John Lakos</li>
+<li>Large-Scale C++ Software Design by John Lakos</li>
 
 </ol>
 

llvm/docs/CommandGuide/.cvsignore

@@ -1,4 +0,0 @@
-pod2htm?.tmp
-*.html
-*.1
-*.ps

llvm/docs/CommandGuide/Makefile

@@ -2,8 +2,8 @@
 # 
 #                     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 distributed under the University of Illinois Open Source
+# License. See LICENSE.TXT for details.
 # 
 ##===----------------------------------------------------------------------===##
 

llvm/docs/CommandGuide/bugpoint.pod

@@ -64,6 +64,12 @@ 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<--enable-valgrind>
+
+Use valgrind to find faults in the optimization phase. This will allow
+bugpoint to find otherwise asymptomatic problems caused by memory
+mis-management.
+
 =item B<-find-bugs>
 
 Continually randomize the specified passes and run them on the test program
@@ -87,6 +93,11 @@ optimizations, use the B<--help> and B<--load> options together; for example:
 
     bugpoint --load myNewPass.so --help
 
+=item B<--mlimit> F<megabytes>
+
+Specifies an upper limit on memory usage of the optimization and codegen. Set
+to zero to disable the limit.
+
 =item B<--output> F<filename>
 
 Whenever the test program produces output on its standard output stream, it
@@ -105,12 +116,6 @@ using the specified code generator.  These options allow you to choose the
 interpreter, the JIT compiler, the static native code compiler, or the C
 backend, respectively.
 
-=item B<--enable-valgrind>
-
-Use valgrind to find faults in the optimization phase. This will allow
-bugpoint to find otherwise asymptomatic problems caused by memory
-mis-management.
-
 =back
 
 =head1 EXIT STATUS

llvm/docs/CommandGuide/html/.cvsignore

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

llvm/docs/CommandGuide/index.html

@@ -3,7 +3,7 @@
 <html>
 <head>
   <title>LLVM Command Guide</title>
-  <link rel="stylesheet" href="../llvm.css" type="text/css">
+  <link rel="stylesheet" href="/docs/llvm.css" type="text/css">
 </head>
 <body>
 
@@ -32,50 +32,50 @@ options) arguments to the tool you are interested in.</p>
 
 <ul>
 
-<li><a href="html/llvm-as.html"><b>llvm-as</b></a> - 
+<li><a href="/cmds/llvm-as.html"><b>llvm-as</b></a> - 
     assemble a human-readable .ll file into bytecode</li>
 
-<li><a href="html/llvm-dis.html"><b>llvm-dis</b></a> -
+<li><a href="/cmds/llvm-dis.html"><b>llvm-dis</b></a> -
     disassemble a bytecode file into a human-readable .ll file</li>
 
-<li><a href="html/llvm-upgrade.html"><b>llvm-upgrade</b></a> -
+<li><a href="/cmds/llvm-upgrade.html"><b>llvm-upgrade</b></a> -
     upgrade LLVM assembly from previous version</li>
 
-<li><a href="html/opt.html"><b>opt</b></a> -
+<li><a href="/cmds/opt.html"><b>opt</b></a> -
     run a series of LLVM-to-LLVM optimizations on a bytecode file</li>
 
-<li><a href="html/llc.html"><b>llc</b></a> - 
+<li><a href="/cmds/llc.html"><b>llc</b></a> - 
     generate native machine code for a bytecode file</li>
 
-<li><a href="html/lli.html"><b>lli</b></a> - 
+<li><a href="/cmds/lli.html"><b>lli</b></a> - 
     directly run a program compiled to bytecode using a JIT compiler or 
     interpreter</li>
 
-<li><a href="html/llvm-link.html"><b>llvm-link</b></a> -
+<li><a href="/cmds/llvm-link.html"><b>llvm-link</b></a> -
     link several bytecode files into one</li>
 
-<li><a href="html/llvm-ar.html"><b>llvm-ar</b></a> - 
+<li><a href="/cmds/llvm-ar.html"><b>llvm-ar</b></a> - 
     archive bytecode files</li>
 
-<li><a href="html/llvm-ranlib.html"><b>llvm-ranlib</b></a> - 
+<li><a href="/cmds/llvm-ranlib.html"><b>llvm-ranlib</b></a> - 
     create an index for archives made with llvm-ar</li>
 
-<li><a href="html/llvm-nm.html"><b>llvm-nm</b></a> -
+<li><a href="/cmds/llvm-nm.html"><b>llvm-nm</b></a> -
     print out the names and types of symbols in a bytecode file</li>
 
-<li><a href="html/llvm-prof.html"><b>llvm-prof</b></a> -
+<li><a href="/cmds/llvm-prof.html"><b>llvm-prof</b></a> -
     format raw `<tt>llvmprof.out</tt>' data into a human-readable report</li>
 
-<li><a href="html/llvmc.html"><b>llvmc</b></a> -
+<li><a href="/cmds/llvmc.html"><b>llvmc</b></a> -
   generic and configurable compiler driver</li>
 
-<li><a href="html/llvm-ld.html"><b>llvm-ld</b></a> -
+<li><a href="/cmds/llvm-ld.html"><b>llvm-ld</b></a> -
   general purpose linker with loadable runtime optimization support</li>
 
-<li><a href="html/llvm-config.html"><b>llvm-config</b></a> - 
+<li><a href="/cmds/llvm-config.html"><b>llvm-config</b></a> - 
   print out LLVM compilation options, libraries, etc. as configured.</li>
 
-  <li><a href="html/llvm2cpp.html"><b>llvm2cpp</b></a> - convert LLVM assembly
+  <li><a href="/cmds/llvm2cpp.html"><b>llvm2cpp</b></a> - convert LLVM assembly
   into the corresponding LLVM C++ API calls to produce it</li>
 </ul>
 
@@ -90,13 +90,13 @@ options) arguments to the tool you are interested in.</p>
 <div class="doc_text">
 <ul>
 
-<li><a href="html/llvmgcc.html"><b>llvmgcc</b></a> -
+<li><a href="/cmds/llvmgcc.html"><b>llvmgcc</b></a> -
     GCC-based C front-end for LLVM
 
-<li><a href="html/llvmgxx.html"><b>llvmg++</b></a> -
+<li><a href="/cmds/llvmgxx.html"><b>llvmg++</b></a> -
     GCC-based C++ front-end for LLVM</li>
 
-<li><a href="html/stkrc.html"><b>stkrc</b></a> -
+<li><a href="/cmds/stkrc.html"><b>stkrc</b></a> -
     front-end compiler for the <a href="../Stacker.html">Stacker</a> 
     language</li>
 
@@ -115,13 +115,13 @@ options) arguments to the tool you are interested in.</p>
 
 <ul>
 
-<li><a href="html/bugpoint.html"><b>bugpoint</b></a> -
+<li><a href="/cmds/bugpoint.html"><b>bugpoint</b></a> -
     automatic test-case reducer</li>
 
-<li><a href="html/llvm-extract.html"><b>llvm-extract</b></a> -
+<li><a href="/cmds/llvm-extract.html"><b>llvm-extract</b></a> -
     extract a function from an LLVM bytecode file</li>
 
-<li><a href="html/llvm-bcanalyzer.html"><b>llvm-bcanalyzer</b></a> -
+<li><a href="/cmds/llvm-bcanalyzer.html"><b>llvm-bcanalyzer</b></a> -
     bytecode analyzer (analyzes the binary encoding itself, not the program it
     represents)</li>
 
@@ -137,7 +137,7 @@ options) arguments to the tool you are interested in.</p>
 <div class="doc_text">
 <ul>
 
-<li><a href="html/tblgen.html"><b>tblgen</b></a> -
+<li><a href="/cmds/tblgen.html"><b>tblgen</b></a> -
     target description reader and generator</li>
 
 </ul>

llvm/docs/CommandGuide/llc.pod

@@ -10,18 +10,18 @@ B<llc> [I<options>] [I<filename>]
 
 =head1 DESCRIPTION
 
-The B<llc> command compiles LLVM bytecode into assembly language for a
+The B<llc> command compiles LLVM bitcode into assembly language for a
 specified architecture.  The assembly language output can then be passed through
 a native assembler and linker to generate a native executable.
 
 The choice of architecture for the output assembly code is automatically
-determined from the input bytecode file, unless the B<-march> option is used to
+determined from the input bitcode file, unless the B<-march> option is used to
 override the default.
 
 =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 I<filename> is - or omitted, B<llc> reads LLVM bitcode from standard input.
+Otherwise, it will read LLVM bitcode 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 -,
@@ -48,13 +48,13 @@ an output file which already exists.
 
 =item B<-mtriple>=I<target triple>
 
-Override the target triple specified in the input bytecode file with the 
+Override the target triple specified in the input bitcode file with the 
 specified string.
 
 =item B<-march>=I<arch>
 
 Specify the architecture for which to generate assembly, overriding the target
-encoded in the bytecode file.  See the output of B<llc --help> for a list of
+encoded in the bitcode file.  See the output of B<llc --help> for a list of
 valid architectures.  By default this is inferred from the target triple or
 autodetected to the current architecture.
 

llvm/docs/CommandGuide/lli.pod

@@ -2,7 +2,7 @@
 
 =head1 NAME
 
-lli - directly execute programs from LLVM bytecode
+lli - directly execute programs from LLVM bitcode
 
 =head1 SYNOPSIS
 
@@ -10,26 +10,40 @@ 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
+B<lli> directly executes programs in LLVM bitcode format.  It takes a program
+in LLVM bitcode 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
+If I<filename> is not specified, then B<lli> reads the LLVM bitcode for the
 program from standard input.
 
 The optional I<args> specified on the command line are passed to the program as
 arguments.
 
-=head1 OPTIONS
+=head1 GENERAL OPTIONS
 
 =over
 
+=item B<-fake-argv0>=I<executable>
+
+Override the C<argv[0]> value passed into the executing program.
+
+=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<-help>
 
 Print a summary of command line options.
 
+=item B<-load>=I<puginfilename>
+
+Causes B<lli> to load the plugin (shared object) named I<pluginfilename> and use
+it for optimization.
+
 =item B<-stats>
 
 Print statistics from the code-generation passes. This is only meaningful for
@@ -40,16 +54,26 @@ the just-in-time compiler, at present.
 Record the amount of time needed for each code-generation pass and print it to
 standard error.
 
+=item B<-version>
+
+Print out the version of B<lli> and exit without doing anything else.
+
+=back 
+
+=head1 TARGET OPTIONS
+
+=over 
+
 =item B<-mtriple>=I<target triple>
 
-Override the target triple specified in the input bytecode file with the 
+Override the target triple specified in the input bitcode file with the 
 specified string.  This may result in a crash if you pick an
 architecture which is not compatible with the current system.
 
 =item B<-march>=I<arch>
 
 Specify the architecture for which to generate assembly, overriding the target
-encoded in the bytecode file.  See the output of B<llc --help> for a list of
+encoded in the bitcode file.  See the output of B<llc --help> for a list of
 valid architectures.  By default this is inferred from the target triple or
 autodetected to the current architecture.
 
@@ -67,17 +91,112 @@ operations are enabled or not.  The default set of attributes is set by the
 current CPU.  For a list of available attributes, use:
 B<llvm-as E<lt> /dev/null | llc -march=xyz -mattr=help>
 
-=item B<-force-interpreter>=I<{false,true}>
+=back
 
-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>
+=head1 FLOATING POINT OPTIONS
 
-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>.
+=over 
+
+=item B<-disable-excess-fp-precision>
+
+Disable optimizations that may increase floating point precision.
+
+=item B<-enable-finite-only-fp-math>
+
+Enable optimizations that assumes only finite floating point math. That is,
+there is no NAN or Inf values.
+
+=item B<-enable-unsafe-fp-math>
+
+Causes B<lli> to enable optimizations that may decrease floating point
+precision.
+
+=item B<-soft-float>
+
+Causes B<lli> to generate software floating point library calls instead of
+equivalent hardware instructions.
+
+=back
+
+=head1 CODE GENERATION OPTIONS
+
+=over
+
+=item B<-code-model>=I<model>
+
+Choose the code model from:
+
+    default: Target default code model
+    small: Small code model
+    kernel: Kernel code model
+    medium: Medium code model
+    large: Large code model
+
+=item B<-disable-post-RA-scheduler>
+
+Disable scheduling after register allocation.
+
+=item B<-disable-spill-fusing>
+
+Disable fusing of spill code into instructions.
+
+=item B<-enable-correct-eh-support> 
+
+Make the -lowerinvoke pass insert expensive, but correct, EH code.
+
+=item B<-enable-eh> 
+
+Exception handling should be emitted.
+
+=item B<-join-liveintervals> 
+
+Coalesce copies (default=true).
+
+=item B<-nozero-initialized-in-bss>
+Don't place zero-initialized symbols into the BSS section.
+
+=item B<-pre-RA-sched>=I<scheduler>
+
+Instruction schedulers available (before register allocation):
+
+    =default: Best scheduler for the target 
+    =none: No scheduling: breadth first sequencing 
+    =simple: Simple two pass scheduling: minimize critical path and maximize processor utilization 
+    =simple-noitin: Simple two pass scheduling: Same as simple except using generic latency 
+    =list-burr: Bottom-up register reduction list scheduling 
+    =list-tdrr: Top-down register reduction list scheduling 
+    =list-td: Top-down list scheduler -print-machineinstrs - Print generated machine code
+
+=item B<-regalloc>=I<allocator>
+
+Register allocator to use: (default = linearscan)
+
+    =bigblock: Big-block register allocator 
+    =linearscan: linear scan register allocator =local -   local register allocator 
+    =simple: simple register allocator 
+
+=item B<-relocation-model>=I<model> 
+
+Choose relocation model from:
+
+    =default: Target default relocation model 
+    =static: Non-relocatable code =pic -   Fully relocatable, position independent code 
+    =dynamic-no-pic: Relocatable external references, non-relocatable code 
+
+=item B<-spiller>
+
+Spiller to use: (default: local) 
+
+    =simple: simple spiller 
+    =local: local spiller 
+
+=item B<-x86-asm-syntax>=I<syntax>
+
+Choose style of code to emit from X86 backend: 
+
+    =att: Emit AT&T-style assembly 
+    =intel: Emit Intel-style assembly
 
 =back
 

llvm/docs/CommandGuide/llvm-ar.pod

@@ -13,7 +13,7 @@ B<llvm-ar> [-]{dmpqrtx}[Rabfikouz] [relpos] [count] <archive> [files...]
 
 The B<llvm-ar> command is similar to the common Unix utility, C<ar>. It 
 archives several files together into a single file. The intent for this is
-to produce archive libraries by LLVM bytecode that can be linked into an
+to produce archive libraries by LLVM bitcode that can be linked into an
 LLVM program. However, the archive can contain any kind of file. By default,
 B<llvm-ar> generates a symbol table that makes linking faster because
 only the symbol table needs to be consulted, not each individual file member
@@ -44,7 +44,7 @@ Here's where B<llvm-ar> departs from previous C<ar> implementations:
 
 =item I<Symbol Table>
 
-Since B<llvm-ar> is intended to archive bytecode files, the symbol table
+Since B<llvm-ar> is intended to archive bitcode files, the symbol table
 won't make much sense to anything but LLVM. Consequently, the symbol table's
 format has been simplified. It consists simply of a sequence of pairs
 of a file member index number as an LSB 4byte integer and a null-terminated 
@@ -78,7 +78,7 @@ add all the files under a directory, if requested.
 When B<llvm-ar> prints out the verbose table of contents (C<tv> option), it
 precedes the usual output with a character indicating the basic kind of 
 content in the file. A blank means the file is a regular file. A 'Z' means
-the file is compressed. A 'B' means the file is an LLVM bytecode file. An
+the file is compressed. A 'B' means the file is an LLVM bitcode file. An
 'S' means the file is the symbol table.
 
 =back
@@ -123,7 +123,7 @@ archive is not modified.
 Print files to the standard output. The F<k> modifier applies to this
 operation. This operation simply prints the F<files> indicated to the
 standard output. If no F<files> are specified, the entire archive is printed.
-Printing bytecode files is ill-advised as they might confuse your terminal
+Printing bitcode files is ill-advised as they might confuse your terminal
 settings. The F<p> operation never modifies the archive.
 
 =item q[Rfz]
@@ -146,7 +146,7 @@ F<files> are specified, the archive is not modified.
 
 Print the table of contents. Without any modifiers, this operation just prints
 the names of the members to the standard output. With the F<v> modifier,
-B<llvm-ar> also prints out the file type (B=bytecode, Z=compressed, S=symbol
+B<llvm-ar> also prints out the file type (B=bitcode, Z=compressed, S=symbol
 table, blank=regular file), the permission mode, the owner and group, the
 size, and the date. If any F<files> are specified, the listing is only for
 those files. If no F<files> are specified, the table of contents for the
@@ -196,9 +196,9 @@ A synonym for the F<b> option.
 
 =item [k] 
 
-Normally, B<llvm-ar> will not print the contents of bytecode files when the 
+Normally, B<llvm-ar> will not print the contents of bitcode files when the 
 F<p> operation is used. This modifier defeats the default and allows the 
-bytecode members to be printed.
+bitcode members to be printed.
 
 =item [N] 
 
@@ -230,8 +230,8 @@ a time stamp than the time stamp of the member in the archive.
 
 When inserting or replacing any file in the archive, compress the file first.
 This
-modifier is safe to use when (previously) compressed bytecode files are added to
-the archive; the compressed bytecode files will not be doubly compressed.
+modifier is safe to use when (previously) compressed bitcode files are added to
+the archive; the compressed bitcode files will not be doubly compressed.
 
 =back
 
@@ -252,7 +252,7 @@ archive is being created. Using this modifier turns off that warning.
 This modifier requests that an archive index (or symbol table) be added to the
 archive. This is the default mode of operation. The symbol table will contain
 all the externally visible functions and global variables defined by all the
-bytecode files in the archive. Using this modifier is more efficient that using
+bitcode files in the archive. Using this modifier is more efficient that using
 L<llvm-ranlib|llvm-ranlib> which also creates the symbol table.
 
 =item [S]
@@ -363,7 +363,7 @@ the details on each of these items:
 
 =item offset - vbr encoded 32-bit integer
 
-The offset item provides the offset into the archive file where the bytecode
+The offset item provides the offset into the archive file where the bitcode
 member is stored that is associated with the symbol. The offset value is 0
 based at the start of the first "normal" file member. To derive the actual
 file offset of the member, you must add the number of bytes occupied by the file

llvm/docs/CommandGuide/llvm-as.pod

@@ -11,7 +11,7 @@ B<llvm-as> [I<options>] [I<filename>]
 =head1 DESCRIPTION
 
 B<llvm-as> is the LLVM assembler.  It reads a file containing human-readable
-LLVM assembly language, translates it to LLVM bytecode, and writes the result
+LLVM assembly language, translates it to LLVM bitcode, 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
@@ -48,7 +48,7 @@ suffix is appended.
 
 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.
+will overwrite the output file and replace it with new bitcode.
 
 =item B<--help>
 

llvm/docs/CommandGuide/llvm-bcanalyzer.pod

@@ -2,7 +2,7 @@
 
 =head1 NAME
 
-llvm-bcanalyzer - LLVM bytecode analyzer
+llvm-bcanalyzer - LLVM bitcode analyzer
 
 =head1 SYNOPSIS
 
@@ -10,12 +10,12 @@ B<llvm-bcanalyzer> [I<options>] [F<filename>]
 
 =head1 DESCRIPTION
 
-The B<llvm-bcanalyzer> command is a small utility for analyzing bytecode files.
-The tool reads a bytecode file (such as generated with the B<llvm-as> tool) and
-produces a statistical report on the contents of the byteocde file.  The tool
-can also dump a low level but human readable version of the bytecode file. 
+The B<llvm-bcanalyzer> command is a small utility for analyzing bitcode files.
+The tool reads a bitcode file (such as generated with the B<llvm-as> tool) and
+produces a statistical report on the contents of the bitcode file.  The tool
+can also dump a low level but human readable version of the bitcode 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
+directly with the bitcode 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 
@@ -33,14 +33,14 @@ 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 
+Causes B<llvm-bcanalyzer> to dump the bitcode in a human readable format. This 
 format is significantly different from LLVM assembly and provides details about 
-the encoding of the bytecode file.
+the encoding of the bitcode file.
 
 =item B<-verify>
 
 Causes B<llvm-bcanalyzer> to verify the module produced by reading the 
-bytecode. This ensures that the statistics generated are based on a consistent
+bitcode. This ensures that the statistics generated are based on a consistent
 module.
 
 =item B<--help>
@@ -61,18 +61,18 @@ summary output.
 
 =over
 
-=item B<Bytecode Analysis Of Module>
+=item B<Bitcode Analysis Of Module>
 
-This just provides the name of the module for which bytecode analysis is being
+This just provides the name of the module for which bitcode analysis is being
 generated.
 
-=item B<Bytecode Version Number>
+=item B<Bitcode Version Number>
 
-The bytecode version (not LLVM version) of the file read by the analyzer.
+The bitcode version (not LLVM version) of the file read by the analyzer.
 
 =item B<File Size>
 
-The size, in bytes, of the entire bytecode file.
+The size, in bytes, of the entire bitcode file.
 
 =item B<Module Bytes>
 
@@ -86,7 +86,7 @@ Size.
 =item B<Global Types Bytes>
 
 The size, in bytes, of the Global Types Pool. Percentage is relative to File
-Size. This is the size of the definitions of all types in the bytecode file.
+Size. This is the size of the definitions of all types in the bitcode file.
 
 =item B<Constant Pool Bytes>
 
@@ -122,13 +122,13 @@ The size, in bytes, of the list of dependent libraries in the module. Percentage
 is relative to File Size. Note that this value is also included in the Module
 Global Bytes.
 
-=item B<Number Of Bytecode Blocks>
+=item B<Number Of Bitcode Blocks>
 
-The total number of blocks of any kind in the bytecode file.
+The total number of blocks of any kind in the bitcode file.
 
 =item B<Number Of Functions>
 
-The total number of function definitions in the bytecode file.
+The total number of function definitions in the bitcode file.
 
 =item B<Number Of Types>
 
@@ -140,42 +140,42 @@ The total number of constants (of any type) defined in the Constant Pool.
 
 =item B<Number Of Basic Blocks>
 
-The total number of basic blocks defined in all functions in the bytecode file.
+The total number of basic blocks defined in all functions in the bitcode file.
 
 =item B<Number Of Instructions>
 
-The total number of instructions defined in all functions in the bytecode file.
+The total number of instructions defined in all functions in the bitcode file.
 
 =item B<Number Of Long Instructions>
 
-The total number of long instructions defined in all functions in the bytecode
+The total number of long instructions defined in all functions in the bitcode
 file. Long instructions are those taking greater than 4 bytes. Typically long
 instructions are GetElementPtr with several indices, PHI nodes, and calls to
 functions with large numbers of arguments.
 
 =item B<Number Of Operands>
 
-The total number of operands used in all instructions in the bytecode file.
+The total number of operands used in all instructions in the bitcode file.
 
 =item B<Number Of Compaction Tables>
 
-The total number of compaction tables in all functions in the bytecode file.
+The total number of compaction tables in all functions in the bitcode file.
 
 =item B<Number Of Symbol Tables>
 
-The total number of symbol tables in all functions in the bytecode file.
+The total number of symbol tables in all functions in the bitcode file.
 
 =item B<Number Of Dependent Libs>
 
-The total number of dependent libraries found in the bytecode file.
+The total number of dependent libraries found in the bitcode file.
 
 =item B<Total Instruction Size>
 
-The total size of the instructions in all functions in the bytecode file.
+The total size of the instructions in all functions in the bitcode file.
 
 =item B<Average Instruction Size>
 
-The average number of bytes per instruction across all functions in the bytecode
+The average number of bytes per instruction across all functions in the bitcode
 file. This value is computed by dividing Total Instruction Size by Number Of
 Instructions.
 
@@ -306,7 +306,7 @@ Rate encoding scheme. The percentage is relative to # of VBR Expanded Bytes.
 
 =head1 SEE ALSO
 
-L<llvm-dis|llvm-dis>, L<http://llvm.org/docs/BytecodeFormat.html>
+L<llvm-dis|llvm-dis>, L<http://llvm.org/docs/BitcodeFormat.html>
 
 =head1 AUTHORS
 

llvm/docs/CommandGuide/llvm-config.pod

@@ -115,7 +115,7 @@ Includes either a native backend or the C backend.
 
 =item B<engine>
 
-Includes either a native JIT or the bytecode interpreter.
+Includes either a native JIT or the bitcode interpreter.
 
 =back
 

llvm/docs/CommandGuide/llvm-dis.pod

@@ -11,7 +11,7 @@ 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.
+bitcode 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.

llvm/docs/CommandGuide/llvm-extract.pod

@@ -11,10 +11,10 @@ B<llvm-extract> [I<options>] B<--func> I<function-name> [I<filename>]
 =head1 DESCRIPTION
 
 The B<llvm-extract> command takes the name of a function and extracts it from
-the specified LLVM bytecode file.  It is primarily used as a debugging tool to
+the specified LLVM bitcode 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,
+In addition to extracting the bitcode of the specified function,
 B<llvm-extract> will also remove unreachable global variables, prototypes, and
 unused types.
 
@@ -30,11 +30,11 @@ unless the B<-o> option is specified (see below).
 
 Force overwrite.  Normally, B<llvm-extract> will refuse to overwrite an
 output file that already exists.  With this option, B<llvm-extract>
-will overwrite the output file and replace it with new bytecode.
+will overwrite the output file and replace it with new bitcode.
 
 =item B<--func> I<function-name>
 
-Extract the function named I<function-name> from the LLVM bytecode.
+Extract the function named I<function-name> from the LLVM bitcode.
 
 =item B<--help>
 

llvm/docs/CommandGuide/llvm-ld.pod

@@ -10,16 +10,16 @@ B<llvm-ld> <options> <files>
 
 =head1 DESCRIPTION
 
-The B<llvm-ld> tool takes a set of LLVM bytecode files and links them
-together into a single LLVM bytecode file.  The output bytecode file can be
-another bytecode file or an executable bytecode program.  Using additional
+The B<llvm-ld> tool takes a set of LLVM bitcode files and links them
+together into a single LLVM bitcode file.  The output bitcode file can be
+another bitcode file or an executable bitcode program.  Using additional
 options, B<llvm-ld> is able to produce native code executables.
 
 The B<llvm-ld> tool is the main linker for LLVM. It is used to link together
 the output of LLVM front-end compilers and run "link time" optimizations (mostly
 the inter-procedural kind).
 
-The B<llvm-ld> tools attemps to mimic the interface provided by the default
+The B<llvm-ld> tools attempts to mimic the interface provided by the default
 system linker so that it can act as a I<drop-in> replacement.
 
 =head2 Search Order
@@ -47,13 +47,13 @@ and is applied to all libraries, preceding or succeeding, in the command line.
 
 =head2 Link order
 
-All object and bytecode files are linked first in the order they were 
+All object and bitcode 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
+Object files and static bitcode 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
@@ -64,7 +64,7 @@ undefined symbols defined.
 
 The B<llvm-ld> program has limited support for native code generation, when
 using the B<-native> or B<-native-cbe> options. Native code generation is
-perfomed by converting the linked bytecode into native assembly (.s) or C code
+performed by converting the linked bitcode into native assembly (.s) or C code
 and running the system compiler (typically gcc) on the result.
 
 =head1 OPTIONS
@@ -121,7 +121,7 @@ will not search the paths given by the B<-L> options following it.
 
 =item B<-link-as-library>
 
-Link the bytecode files together as a library, not an executable. In this mode,
+Link the bitcode files together as a library, not an executable. In this mode,
 undefined symbols will be permitted.
 
 =item B<-r>
@@ -136,14 +136,14 @@ Specifies the kind of machine for which code or assembly should be generated.
 
 Generate a native machine code executable.
 
-When generating native executables, B<llvm-ld> first checks for a bytecode
+When generating native executables, B<llvm-ld> first checks for a bitcode
 version of the library and links it in, if necessary.  If the library is
 missing, B<llvm-ld> skips it.  Then, B<llvm-ld> links in the same
 libraries as native code.
 
-In this way, B<llvm-ld> should be able to link in optimized bytecode
+In this way, B<llvm-ld> should be able to link in optimized bitcode
 subsets of common libraries and then link in any part of the library that
-hasn't been converted to bytecode.
+hasn't been converted to bitcode.
 
 =item B<-native-cbe>
 
@@ -236,7 +236,7 @@ run. This feature allows the optimization passes of B<llvm-ld> to be extended.
 
 =item B<-post-link-opt>F<Path>
 
-Run post-link optimization program. After linking is completed a bytecode file
+Run post-link optimization program. After linking is completed a bitcode file
 will be generated. It will be passed to the program specified by F<Path> as the
 first argument. The second argument to the program will be the name of a
 temporary file into which the program should place its optimized output. For
@@ -254,7 +254,7 @@ it will exit with a non-zero return code.
 
 =head1 ENVIRONMENT
 
-The C<LLVM_LIB_SEARCH_PATH> environment variable is used to find bytecode
+The C<LLVM_LIB_SEARCH_PATH> environment variable is used to find bitcode
 libraries. Any paths specified in this variable will be searched after the C<-L>
 options.
 

llvm/docs/CommandGuide/llvm-link.pod

@@ -10,8 +10,8 @@ B<llvm-link> [I<options>] I<filename ...>
 
 =head1 DESCRIPTION
 
-B<llvm-link> takes several LLVM bytecode files and links them together into a
-single LLVM bytecode file.  It writes the output file to standard output, unless
+B<llvm-link> takes several LLVM bitcode files and links them together into a
+single LLVM bitcode file.  It writes the output file to standard output, unless
 the B<-o> option is used to specify a filename.
 
 B<llvm-link> attempts to load the input files from the current directory.  If
@@ -27,14 +27,14 @@ in the order they were specified on the command line.
 =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
+libraries, B<llvm-link> will look in path name 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.
+file if it already exists.
 
 =item B<-o> F<filename>
 
@@ -44,7 +44,7 @@ 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.
+bitcode file to standard error.
 
 =item B<--help>
 
@@ -53,7 +53,7 @@ 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
+typically includes a message for each bitcode file linked in and for each
 library found.
 
 =back

llvm/docs/CommandGuide/llvm-nm.pod

@@ -2,7 +2,7 @@
 
 =head1 NAME
 
-llvm-nm - list LLVM bytecode file's symbol table
+llvm-nm - list LLVM bitcode file's symbol table
 
 =head1 SYNOPSIS
 
@@ -10,11 +10,11 @@ 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.
+The B<llvm-nm> utility lists the names of symbols from the LLVM bitcode files,
+or B<ar> archives containing LLVM bitcode 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.
+If no file name is specified, or I<-> is used as a file name, B<llvm-nm> will
+process a bitcode 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,
@@ -28,15 +28,15 @@ Type code characters currently supported, and their meanings, are as follows:
 
 =item U
 
-Named object is referenced but undefined in this bytecode file
+Named object is referenced but undefined in this bitcode file
 
 =item C
 
-Common (multiple defs link together into one def)
+Common (multiple definitions link together into one def)
 
 =item W
 
-Weak reference (multiple defs link together into zero or one defs)
+Weak reference (multiple definitions link together into zero or one definitions)
 
 =item t
 
@@ -60,10 +60,10 @@ Something unrecognizable
 
 =back
 
-Because LLVM bytecode files typically contain objects that are not considered to
+Because LLVM bitcode 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.
+even symbols which are defined in the bitcode file.
 
 =head1 OPTIONS
 
@@ -83,18 +83,18 @@ 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
+Print only symbols defined in this bitcode 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.
+from other bitcode files.
 
 =item B<--undefined-only>, B<-u>
 
-Print only symbols referenced but not defined in this bytecode file.
+Print only symbols referenced but not defined in this bitcode file.
 
 =item B<--format=>I<fmt>, B<-f>
 

llvm/docs/CommandGuide/llvm-prof.pod

@@ -6,12 +6,12 @@ llvm-prof - print execution profile of LLVM program
 
 =head1 SYNOPSIS
 
-B<llvm-prof> [I<options>] [I<bytecode file>] [I<llvmprof.out>]
+B<llvm-prof> [I<options>] [I<bitcode 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
+optionally use a specific file with the third program argument), a bitcode file
 for the program, and produces a human readable report, suitable for determining
 where the program hotspots are.
 
@@ -47,7 +47,7 @@ error.
 
 =head1 EXIT STATUS
 
-B<llvm-prof> returns 1 if it cannot load the bytecode file or the profile
+B<llvm-prof> returns 1 if it cannot load the bitcode file or the profile
 information. Otherwise, it exits with zero.
 
 =head1 AUTHOR

llvm/docs/CommandGuide/llvm-ranlib.pod

@@ -14,7 +14,7 @@ The B<llvm-ranlib> command is similar to the common Unix utility, C<ranlib>. It
 adds or updates the symbol table in an LLVM archive file. Note that using the
 B<llvm-ar> modifier F<s> is usually more efficient than running B<llvm-ranlib>
 which is only provided only for completness and compatibility. Unlike other 
-implementations of C<ranlib>, B<llvm-ranlib> indexes LLVM bytecode files, not
+implementations of C<ranlib>, B<llvm-ranlib> indexes LLVM bitcode files, not
 native object modules. You can list the contents of the symbol table with the
 C<llvm-nm -s> command.
 

llvm/docs/CommandGuide/llvm-upgrade.pod

@@ -2,7 +2,7 @@
 
 =head1 NAME
 
-llvm-upgrade - LLVM assembly upgrader
+llvm-upgrade - LLVM assembly upgrade tool
 
 =head1 SYNOPSIS
 
@@ -10,7 +10,7 @@ B<llvm-upgrade> [I<options>] [I<filename>]
 
 =head1 DESCRIPTION
 
-B<llvm-upgrade> is the LLVM assembly upgrader.  It reads a file containing 
+B<llvm-upgrade> is the LLVM assembly upgrade tool.  It reads a file containing 
 human-readable LLVM assembly language, and upgrades that assembly to the current
 version of LLVM. If the input is in the form currently accepted by LLVM, then
 no upgrades are performed. 

llvm/docs/CommandGuide/llvm2cpp.pod

@@ -2,7 +2,7 @@
 
 =head1 NAME
 
-llvm2xpp - LLVM bytecode to LLVM C++ IR translator
+llvm2xpp - LLVM bitcode to LLVM C++ IR translator
 
 =head1 SYNOPSIS
 
@@ -10,7 +10,7 @@ B<llvm2cpp> [I<options>] [I<filename>]
 
 =head1 DESCRIPTION
 
-B<llvm2cpp> translates from LLVM bytecode (.bc files) to a 
+B<llvm2cpp> translates from LLVM bitcode (.bc files) to a 
 corresponding C++ source file that will make calls against the LLVM C++ API to
 build the same module as the input. By default, the C++ output is a complete
 program that builds the module, verifies it and then emits the module as
@@ -193,6 +193,7 @@ Show the version number of this program.
 
 =back
 
+
 =head1 EXIT STATUS
 
 If B<llvm2cpp> succeeds, it will exit with 0.  Otherwise, if an error
@@ -202,6 +203,13 @@ occurs, it will exit with a non-zero value.
 
 L<llvm-as|llvm-as> L<tblgen|tblgen>
 
+=head1 NOTES
+
+This tool may be removed from a future version of LLVM. Instead, its
+functionality may be incorporated into the llc tool. It would then act similarly
+to other targets except its output would be C++ source that could be compiled to
+construct the input program.
+
 =head1 AUTHORS
 
 Written by Reid Spencer (L<http://hlvm.org>).

llvm/docs/CommandGuide/llvmc.pod

@@ -69,13 +69,13 @@ into a set of basic actions to be done:
 
 =item * Pre-processing: gathering/filtering compiler input (optional).
 
-=item * Translation: source language to bytecode conversion.
+=item * Translation: source language to bitcode conversion.
 
-=item * Assembly: bytecode to native code conversion.
+=item * Assembly: bitcode to native code conversion.
 
-=item * Optimization: conversion of bytecode to something that runs faster.
+=item * Optimization: conversion of bitcode to something that runs faster.
 
-=item * Linking: combining multiple bytecodes to produce executable program.
+=item * Linking: combining multiple bitcode files to produce executable program.
 
 =back
 
@@ -99,7 +99,7 @@ following control options are defined:
 
 This option specifies that the linking phase is not to be run. All
 previous phases, if applicable will run. This is generally how a given
-bytecode file is compiled and optimized for a source language module.
+bitcode file is compiled and optimized for a source language module.
 
 =item B<-k> or B<--link> or default
 
@@ -145,7 +145,7 @@ this is the default level of optimization.
 This level of optimization specifies a balance between generating good code 
 that will execute reasonably quickly and not spending too much time optimizing
 the code to get there. For example, this level of optimization may include 
-things like global common subexpression elimination, aggressive dead code 
+things like global common sub-expression elimination, aggressive dead code 
 elimination, and scalar replication.
 
 =item B<-O3> (aggressive optimization)
@@ -173,7 +173,7 @@ aggressive inter-procedural optimization.
 
 This is the same as B<-O5> except that it employs profile-guided
 re-optimization of the program after it has executed. Note that this implies
-a single level of re-optimization based on runtime profile analysis. Once
+a single level of re-optimization based on run time profile analysis. Once
 the re-optimization has completed, the profiling instrumentation is
 removed and final optimizations are employed.
 
@@ -220,7 +220,7 @@ of the option names the back end to use.
 
 =item B<--native>
 
-Normally, B<llvmc> produces bytecode files at most stages of compilation.
+Normally, B<llvmc> produces bitcode files at most stages of compilation.
 With this option, B<llvmc> will arrange for native object files to be
 generated with the B<-c> option, native assembly files to be generated
 with the B<-S> option, and native executables to be generated with the

llvm/docs/CommandGuide/llvmgcc.pod

@@ -12,10 +12,10 @@ B<llvm-gcc> [I<options>] I<filename>
 
 The B<llvm-gcc> command is the LLVM C front end.  It is a modified
 version of gcc that compiles C/ObjC programs into native objects, LLVM
-bytecode or LLVM assembly language, depending upon the options.
+bitcode or LLVM assembly language, depending upon the options.
 
 By default, B<llvm-gcc> compiles to native objects just like GCC does. If the
-B<-emit-llvm> option is given then it will generate LLVM bytecode files instead.
+B<-emit-llvm> option is given then it will generate LLVM bitcode files instead.
 If B<-S> (assembly) is also given, then it will generate LLVM assembly. 
 
 Being derived from the GNU Compiler Collection, B<llvm-gcc> has many
@@ -32,14 +32,14 @@ Print a summary of command line options.
 
 =item B<-S>
 
-Do not generate an LLVM bytecode file.  Rather, compile the source
+Do not generate an LLVM bitcode 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
+file into an LLVM bitcode file.  This bitcode file can then be
+linked with other bitcode files later on to generate a full LLVM
 executable.
 
 =item B<-o> I<filename>
@@ -59,11 +59,11 @@ repeated.
 =item B<-l>I<name>
 
 Link in the library libI<name>.[bc | a | so].  This library should
-be a bytecode library.
+be a bitcode library.
 
 =item B<-emit-llvm>
 
-Make the output be LLVM bytecode (or assembly) instead of native object (or
+Make the output be LLVM bitcode (or assembly) instead of native object (or
 assembly).
 
 =back

llvm/docs/CommandGuide/llvmgxx.pod

@@ -12,10 +12,10 @@ B<llvm-g++> [I<options>] I<filename>
 
 The B<llvm-g++> command is the LLVM C++ front end.  It is a modified
 version of g++ that compiles C++/ObjC++ programs into native code, 
-LLVM bytecode or assembly language, depending upon the options.
+LLVM bitcode or assembly language, depending upon the options.
 
 By default, B<llvm-g++> compiles to native objects just like GCC does. If the
-B<-emit-llvm> option is given then it will generate LLVM bytecode files instead.
+B<-emit-llvm> option is given then it will generate LLVM bitcode files instead.
 If B<-S> (assembly) is also given, then it will generate LLVM assembly. 
 
 Being derived from the GNU Compiler Collection, B<llvm-g++> has many
@@ -32,14 +32,14 @@ Print a summary of command line options.
 
 =item B<-S>
 
-Do not generate an LLVM bytecode file.  Rather, compile the source
+Do not generate an LLVM bitcode 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
+file into an LLVM bitcode file.  This bitcode file can then be
+linked with other bitcode files later on to generate a full LLVM
 executable.
 
 =item B<-o> I<filename>
@@ -59,11 +59,11 @@ repeated.
 =item B<-l>I<name>
 
 Link in the library libI<name>.[bc | a | so].  This library should
-be a bytecode library.
+be a bitcode library.
 
 =item B<-emit-llvm>
 
-Make the output be LLVM bytecode (or assembly) instead of native object (or
+Make the output be LLVM bitcode (or assembly) instead of native object (or
 assembly).
 
 =back

llvm/docs/CommandGuide/man/.cvsignore

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

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

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

llvm/docs/CommandGuide/manpage.css

@@ -13,7 +13,7 @@ h1, a { color: #336699; }
 .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;

llvm/docs/CommandGuide/opt.pod

@@ -11,24 +11,24 @@ B<opt> [I<options>] [I<filename>]
 =head1 DESCRIPTION
 
 The B<opt> command is the modular LLVM optimizer and analyzer.  It takes LLVM 
-bytecode as input, runs the specified optimizations or analyses on it, and then
-outputs the optimized LLVM bytecode or the analysis results.  The function of 
+bitcode as input, runs the specified optimizations or analyses on it, and then
+outputs the optimized LLVM bitcode or the analysis results.  The function of 
 B<opt> depends on whether the B<-analyze> option is given. 
 
 When B<-analyze> is specified, B<opt> performs various analyses of LLVM 
-bytecode.  It will usually print the results on standard output, but in a few 
+bitcode.  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.  
 
 While B<-analyze> is I<not> given, B<opt> attempts to produce an optimized 
-bytecode file.  The optimizations available via B<opt> depend upon what 
+bitcode file.  The optimizations available via B<opt> depend upon what 
 libraries were linked into it as well as any additional libraries that have 
 been loaded with the B<-load> option.  Use the B<-help> option to determine 
 what optimizations you can use.
 
 If I<filename> is omitted from the command line or is I<->, B<opt> reads its
-input from standard input. The input must be an LLVM bytecode file.
+input from standard input. The input must be an LLVM bitcode file.
 
 If an output filename is not specified with the B<-o> option, B<opt>
 writes its output to the standard output.
@@ -41,7 +41,7 @@ writes its output to the standard output.
 
 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.
+overwrite the output file and replace it with new bitcode.
 
 =item B<-help>
 

llvm/docs/CommandGuide/ps/.cvsignore

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

llvm/docs/CommandGuide/stkrc.pod

@@ -14,8 +14,8 @@ The B<stkrc> command is the compiler for the Stacker language. Stacker is a
 simple stack based, Forth-like language that was written as a demonstration
 language for LLVM. For details on the language, please see
 L<http://llvm.org/docs/Stacker.html> . The B<stkrc> compiler is fairly 
-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
+minimal. It compiles to bitcode only and doesn't perform any optimizations.
+The output of stkrc (a bitcode 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 
@@ -65,7 +65,7 @@ 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. 
+bitcode file. This option overrides that behavior. 
 
 =item B<-s> F<stacksize>
 

llvm/docs/CommandLine.html

@@ -60,7 +60,7 @@
             <tt>cl::ParseCommandLineOptions</tt> function</a></li>
         <li><a href="#cl::ParseEnvironmentOptions">The 
             <tt>cl::ParseEnvironmentOptions</tt> function</a></li>
-        <li><a href="#cl::SetVersionPrinter">The cl::SetVersionPrinter
+        <li><a href="#cl::SetVersionPrinter">The <tt>cl::SetVersionPrinter</tt>
           function</a></li>
         <li><a href="#cl::opt">The <tt>cl::opt</tt> class</a></li>
         <li><a href="#cl::list">The <tt>cl::list</tt> class</a></li>
@@ -75,6 +75,8 @@
             parser</a></li>
         <li><a href="#boolparser">The <tt>parser&lt;bool&gt;</tt>
             specialization</a></li>
+        <li><a href="#boolOrDefaultparser">The <tt>parser&lt;boolOrDefault&gt;</tt>
+            specialization</a></li>
         <li><a href="#stringparser">The <tt>parser&lt;string&gt;</tt>
             specialization</a></li>
         <li><a href="#intparser">The <tt>parser&lt;int&gt;</tt>
@@ -136,7 +138,7 @@ code.</li>
 
 <li>Globally accessible: Libraries can specify command line arguments that are
 automatically enabled in any tool that links to the library.  This is possible
-because the application doesn't have to keep a "list" of arguments to pass to
+because the application doesn't have to keep a list of arguments to pass to
 the parser.  This also makes supporting <a href="#dynamicopts">dynamically
 loaded options</a> trivial.</li>
 
@@ -214,12 +216,12 @@ int main(int argc, char **argv) {
 declarations.</p>
 
 <p>Now that you are ready to support command line arguments, we need to tell the
-system which ones we want, and what type of argument they are.  The CommandLine
+system which ones we want, and what type of arguments they are.  The CommandLine
 library uses a declarative syntax to model command line arguments with the
 global variable declarations that capture the parsed values.  This means that
 for every command line option that you would like to support, there should be a
 global variable declaration to capture the result.  For example, in a compiler,
-we would like to support the unix standard '<tt>-o &lt;filename&gt;</tt>' option
+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>
 
@@ -381,7 +383,7 @@ OPTIONS:
   -help  - display available options (--help-hidden for more)
 </pre></div>
 
-<p>and "<tt>opt --help-hidden</tt>" prints this:</p>
+<p>and "<tt>compiler --help-hidden</tt>" prints this:</p>
 
 <div class="doc_code"><pre>
 USAGE: compiler [options] &lt;input file&gt;
@@ -430,7 +432,7 @@ a value itself:</p>
 </pre></div>
 
 <p>The third line (which is the only one we modified from above) defines a
-"<tt>-q</tt> alias that updates the "<tt>Quiet</tt>" variable (as specified by
+"<tt>-q</tt>" alias that updates the "<tt>Quiet</tt>" variable (as specified by
 the <tt><a href="#cl::aliasopt">cl::aliasopt</a></tt> modifier) whenever it is
 specified.  Because aliases do not hold state, the only thing the program has to
 query is the <tt>Quiet</tt> variable now.  Another nice feature of aliases is
@@ -460,24 +462,24 @@ uses.</p>
 
 <div class="doc_text">
 
-<p>So far, we have seen how the CommandLine library handles builtin types like
+<p>So far we have seen how the CommandLine library handles builtin types like
 <tt>std::string</tt>, <tt>bool</tt> and <tt>int</tt>, but how does it handle
 things it doesn't know about, like enums or '<tt>int*</tt>'s?</p>
 
-<p>The answer is that it uses a table driven generic parser (unless you specify
+<p>The answer is that it uses a table-driven generic parser (unless you specify
 your own parser, as described in the <a href="#extensionguide">Extension
 Guide</a>).  This parser maps literal strings to whatever type is required, and
 requires you to tell it what this mapping should be.</p>
 
-<p>Lets say that we would like to add four optimization levels to our
+<p>Let's say that we would like to add four optimization levels to our
 optimizer, using the standard flags "<tt>-g</tt>", "<tt>-O0</tt>",
 "<tt>-O1</tt>", and "<tt>-O2</tt>".  We could easily implement this with boolean
 options like above, but there are several problems with this strategy:</p>
 
 <ol>
 <li>A user could specify more than one of the options at a time, for example,
-"<tt>opt -O3 -O2</tt>".  The CommandLine library would not be able to catch this
-erroneous input for us.</li>
+"<tt>compiler -O3 -O2</tt>".  The CommandLine library would not be able to
+catch this erroneous input for us.</li>
 
 <li>We would have to test 4 different variables to see which ones are set.</li>
 
@@ -632,7 +634,7 @@ that you can choose the form most appropriate for your application.</p>
 
 <div class="doc_text">
 
-<p>Now that we have the standard run of the mill argument types out of the way,
+<p>Now that we have the standard run-of-the-mill argument types out of the way,
 lets get a little wild and crazy.  Lets say that we want our optimizer to accept
 a <b>list</b> of optimizations to perform, allowing duplicates.  For example, we
 might want to run: "<tt>compiler -dce -constprop -inline -dce -strip</tt>".  In
@@ -748,7 +750,7 @@ the first are discarded.</p>
 
 <p>Finally, if external storage is used, then the location specified must be of
 <b>type</b> <tt>unsigned</tt>. In all other ways a <a
-href="#bits"><tt>cl::bits</tt></a> option is morally equivalent to a <a
+href="#bits"><tt>cl::bits</tt></a> option is equivalent to a <a
 href="#list"> <tt>cl::list</tt></a> option.</p>
 
 </div>
@@ -914,7 +916,7 @@ can use it like this:</p>
   
   <div class="doc_code"><pre>
   static cl::list&lt;std::string&gt; Files(cl::Positional, cl::OneOrMore);
-  static cl::listlt;std::string&gt; Libraries("l", cl::ZeroOrMore);
+  static cl::list&lt;std::string&gt; Libraries("l", cl::ZeroOrMore);
 
   int main(int argc, char**argv) {
     // ...
@@ -967,7 +969,7 @@ interpreted by the command line argument.</p>
 standard Unix Bourne shell (<tt>/bin/sh</tt>).  To run <tt>/bin/sh</tt>, first
 you specify options to the shell itself (like <tt>-x</tt> which turns on trace
 output), then you specify the name of the script to run, then you specify
-arguments to the script.  These arguments to the script are parsed by the bourne
+arguments to the script.  These arguments to the script are parsed by the Bourne
 shell command line option processor, but are not interpreted as options to the
 shell itself.  Using the CommandLine library, we would specify this as:</p>
 
@@ -1040,10 +1042,7 @@ extern bool DebugFlag;
 <i>// DEBUG macro - This macro should be used by code to emit debug information.
 // In the '-debug' option is specified on the command line, and if this is a
 // debug build, then the code specified as the option to the macro will be
-// executed.  Otherwise it will not be.  Example:
-//
-// DOUT &lt;&lt; "Bitset contains: " &lt;&lt; Bitset &lt;&lt; "\n";
-//</i>
+// executed.  Otherwise it will not be.</i>
 <span class="doc_hilite">#ifdef NDEBUG
 #define DEBUG(X)
 #else
@@ -1055,7 +1054,7 @@ extern bool DebugFlag;
 <p>This allows clients to blissfully use the <tt>DEBUG()</tt> macro, or the
 <tt>DebugFlag</tt> explicitly if they want to.  Now we just need to be able to
 set the <tt>DebugFlag</tt> boolean when the option is set.  To do this, we pass
-an additial argument to our command line argument processor, and we specify
+an additional argument to our command line argument processor, and we specify
 where to fill in with the <a href="#cl::location">cl::location</a>
 attribute:</p>
 
@@ -1204,15 +1203,15 @@ compiled program:</p>
 
 <li><a name="cl::NotHidden">The <b><tt>cl::NotHidden</tt></b></a> modifier
 (which is the default for <tt><a href="#cl::opt">cl::opt</a></tt> and <tt><a
-href="#cl::list">cl::list</a></tt> options), indicates the option is to appear
+href="#cl::list">cl::list</a></tt> options) indicates the option is to appear
 in both help listings.</li>
 
 <li><a name="cl::Hidden">The <b><tt>cl::Hidden</tt></b></a> modifier (which is the
-default for <tt><a href="#cl::alias">cl::alias</a></tt> options), indicates that
+default for <tt><a href="#cl::alias">cl::alias</a></tt> options) indicates that
 the option should not appear in the <tt>--help</tt> output, but should appear in
 the <tt>--help-hidden</tt> output.</li>
 
-<li><a name="cl::ReallyHidden">The <b><tt>cl::ReallyHidden</tt></b></a> modifier,
+<li><a name="cl::ReallyHidden">The <b><tt>cl::ReallyHidden</tt></b></a> modifier
 indicates that the option should not appear in any help output.</li>
 
 </ul>
@@ -1253,7 +1252,7 @@ indicates that the specified option must be specified exactly one time.</li>
 indicates that the option must be specified at least one time.</li>
 
 <li>The <b><tt>cl::ConsumeAfter</tt></b> modifier is described in the <a
-href="#positional">Positional arguments section</a></li>
+href="#positional">Positional arguments section</a>.</li>
 
 </ul>
 
@@ -1326,7 +1325,7 @@ when <a href="#extensionguide">extending the library</a>.</p>
 
 <p>The formatting option group is used to specify that the command line option
 has special abilities and is otherwise different from other command line
-arguments.  As usual, you can only specify at most one of these arguments.</p>
+arguments.  As usual, you can only specify one of these arguments at most.</p>
 
 <ul>
 
@@ -1335,7 +1334,7 @@ modifier (which is the default all options) specifies that this option is
 "normal".</li>
 
 <li><a name="cl::Positional">The <b><tt>cl::Positional</tt></b></a> modifier
-specifies that this is a positional argument, that does not have a command line
+specifies that this is a positional argument that does not have a command line
 option associated with it.  See the <a href="#positional">Positional
 Arguments</a> section for more information.</li>
 
@@ -1356,7 +1355,7 @@ modifier added to allow the CommandLine library to recognize them.  Note that
 specified.</li>
 
 <li><a name="cl::Grouping">The <b><tt>cl::Grouping</tt></b></a> modifier is used
-to implement unix style tools (like <tt>ls</tt>) that have lots of single letter
+to implement Unix-style tools (like <tt>ls</tt>) that have lots of single letter
 arguments, but only require a single dash.  For example, the '<tt>ls -labF</tt>'
 command actually enables four different options, all of which are single
 letters.  Note that <b><tt><a href="#cl::Grouping">cl::Grouping</a></tt></b>
@@ -1424,7 +1423,7 @@ more values (i.e. it is a <a href="#cl::list">cl::list</a> option).</li>
 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
+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>
@@ -1485,14 +1484,14 @@ as <a
 href="#cl::ParseCommandLineOptions"><tt>cl::ParseCommandLineOptions</tt></a>,
 except that it is designed to take values for options from an environment
 variable, for those cases in which reading the command line is not convenient or
-not desired. It fills in the values of all the command line option variables
-just like <a
+desired. It fills in the values of all the command line option variables just
+like <a
 href="#cl::ParseCommandLineOptions"><tt>cl::ParseCommandLineOptions</tt></a>
 does.</p>
 
-<p>It takes three parameters: first, the name of the program (since
-<tt>argv</tt> may not be available, it can't just look in <tt>argv[0]</tt>),
-second, the name of the environment variable to examine, and third, the optional
+<p>It takes three parameters: the name of the program (since <tt>argv</tt> may
+not be available, it can't just look in <tt>argv[0]</tt>), the name of the
+environment variable to examine, and the optional
 <a href="#description">additional extra text</a> to emit when the
 <tt>--help</tt> option is invoked.</p>
 
@@ -1516,7 +1515,7 @@ input.</p>
 <div class="doc_text">
 
 <p>The <tt>cl::SetVersionPrinter</tt> function is designed to be called
-directly from <tt>main</tt>, and <i>before</i>
+directly from <tt>main</tt> and <i>before</i>
 <tt>cl::ParseCommandLineOptions</tt>. Its use is optional. It simply arranges
 for a function to be called in response to the <tt>--version</tt> option instead
 of having the <tt>CommandLine</tt> library print out the usual version string
@@ -1702,6 +1701,12 @@ is used to convert boolean strings to a boolean value.  Currently accepted
 strings are "<tt>true</tt>", "<tt>TRUE</tt>", "<tt>True</tt>", "<tt>1</tt>",
 "<tt>false</tt>", "<tt>FALSE</tt>", "<tt>False</tt>", and "<tt>0</tt>".</li>
 
+<li><a name="boolOrDefaultparser">The <b><tt>parser&lt;boolOrDefault&gt;</tt>
+ specialization</b></a> is used for cases where the value is boolean,
+but we also need to know whether the option was specified at all.  boolOrDefault
+is an enum with 3 values, BOU_UNSET, BOU_TRUE and BOU_FALSE.  This parser accepts
+the same strings as <b><tt>parser&lt;bool&gt;</tt></b>.</li>
+
 <li><a name="stringparser">The <b><tt>parser&lt;string&gt;</tt>
 specialization</b></a> simply stores the parsed string into the string value
 specified.  No conversion or modification of the data is performed.</li>
@@ -1775,7 +1780,7 @@ it.</p>
 <p>This approach works well in situations where you would line to parse an
 option using special syntax for a not-very-special data-type.  The drawback of
 this approach is that users of your parser have to be aware that they are using
-your parser, instead of the builtin ones.</p>
+your parser instead of the builtin ones.</p>
 
 </li>
 
@@ -1799,16 +1804,16 @@ this the default for all <tt>unsigned</tt> options.</p>
 </pre></div>
 
 <p>Our new class inherits from the <tt>cl::basic_parser</tt> template class to
-fill in the default, boiler plate, code for us.  We give it the data type that
-we parse into (the last argument to the <tt>parse</tt> method so that clients of
-our custom parser know what object type to pass in to the parse method (here we
-declare that we parse into '<tt>unsigned</tt>' variables.</p>
+fill in the default, boiler plate code for us.  We give it the data type that
+we parse into, the last argument to the <tt>parse</tt> method, so that clients of
+our custom parser know what object type to pass in to the parse method.  (Here we
+declare that we parse into '<tt>unsigned</tt>' variables.)</p>
 
 <p>For most purposes, the only method that must be implemented in a custom
 parser is the <tt>parse</tt> method.  The <tt>parse</tt> method is called
 whenever the option is invoked, passing in the option itself, the option name,
 the string to parse, and a reference to a return value.  If the string to parse
-is not well formed, the parser should output an error message and return true.
+is not well-formed, the parser should output an error message and return true.
 Otherwise it should return false and set '<tt>Val</tt>' to the parsed value.  In
 our example, we implement <tt>parse</tt> as:</p>
 

llvm/docs/CompilerDriver.html

@@ -199,7 +199,7 @@
       </ul></td>
       <td class="td_left"><ul>
           <li>LLVM Assembly</li>
-          <li>LLVM Bytecode</li>
+          <li>LLVM Bitcode</li>
           <li>LLVM C++ IR</li>
       </ul></td>
       <td class="td_left"><dl>
@@ -215,10 +215,10 @@
       <td><b>Optimization</b></td>
       <td class="td_left"><ul>
           <li>LLVM Assembly</li>
-          <li>LLVM Bytecode</li>
+          <li>LLVM Bitcode</li>
       </ul></td>
       <td class="td_left"><ul>
-          <li>LLVM Bytecode</li>
+          <li>LLVM Bitcode</li>
       </ul></td>
       <td class="td_left"><dl>
           <dt><tt>-Ox</tt>
@@ -229,13 +229,13 @@
     <tr>
       <td><b>Linking</b></td>
       <td class="td_left"><ul>
-          <li>LLVM Bytecode</li>
+          <li>LLVM Bitcode</li>
           <li>Native Object Code</li>
           <li>LLVM Library</li>
           <li>Native Library</li>
       </ul></td>
       <td class="td_left"><ul>
-          <li>LLVM Bytecode Executable</li>
+          <li>LLVM Bitcode Executable</li>
           <li>Native Executable</li>
       </ul></td>
       <td class="td_left"><dl>
@@ -291,7 +291,7 @@ should be invoked. Users may but are not advised to alter the compiler's
 available command line options for those programs regardless of whether they
 were written for LLVM or not. Furthermore, not all compiler tools will
 have the same capabilities. Some compiler tools will simply generate LLVM assembly
-code, others will be able to generate fully optimized byte code. In general,
+code, others will be able to generate fully optimized bitcode. In general,
 <tt>llvmc</tt> doesn't make any assumptions about the capabilities or command 
 line options of a sub-tool. It simply uses the details found in the 
 configuration files and leaves it to the compiler writer to specify the 
@@ -299,9 +299,9 @@ configuration correctly.</p>
 
 <p>This approach means that new compiler tools can be up and working very
 quickly. As a first cut, a tool can simply compile its source to raw
-(unoptimized) bytecode or LLVM assembly and <tt>llvmc</tt> can be configured 
-to pick up the slack (translate LLVM assembly to bytecode, optimize the 
-bytecode, generate native assembly, link, etc.).   In fact, the compiler tools 
+(unoptimized) bitcode or LLVM assembly and <tt>llvmc</tt> can be configured 
+to pick up the slack (translate LLVM assembly to bitcode, optimize the 
+bitcode, generate native assembly, link, etc.).   In fact, the compiler tools 
 need not use any LLVM libraries, and it could be written in any language 
 (instead of C++).  The configuration data will allow the full range of 
 optimization, assembly, and linking capabilities that LLVM provides to be added 
@@ -309,7 +309,7 @@ to these kinds of tools.  Enabling the rapid development of front-ends is one
 of the primary goals of <tt>llvmc</tt>.</p>
 
 <p>As a compiler tool matures, it may utilize the LLVM libraries and tools 
-to more efficiently produce optimized bytecode directly in a single compilation 
+to more efficiently produce optimized bitcode directly in a single compilation 
 and optimization program. In these cases, multiple tools would not be needed 
 and the configuration data for the compiler would change.</p>
 
@@ -532,10 +532,10 @@ optimization.</p>
       </tr>
       <tr>
         <td><b>translator.output</b></td>
-        <td><tt>bytecode</tt> or <tt>assembly</tt></td>
+        <td><tt>bitcode</tt> or <tt>assembly</tt></td>
         <td class="td_left">This item specifies the kind of output the language's 
           translator generates.</td>
-        <td><tt>bytecode</tt></td>
+        <td><tt>bitcode</tt></td>
       </tr>
       <tr>
         <td><b>translator.preprocesses</b></td>
@@ -556,10 +556,10 @@ optimization.</p>
       </tr>
       <tr>
         <td><b>optimizer.output</b></td>
-        <td><tt>bytecode</tt> or <tt>assembly</tt></td>
+        <td><tt>bitcode</tt> or <tt>assembly</tt></td>
         <td class="td_left">This item specifies the kind of output the language's 
-          optimizer generates. Valid values are "assembly" and "bytecode"</td>
-        <td><tt>bytecode</tt></td>
+          optimizer generates. Valid values are "assembly" and "bitcode"</td>
+        <td><tt>bitcode</tt></td>
       </tr>
       <tr>
         <td><b>optimizer.preprocesses</b></td>
@@ -724,7 +724,7 @@ optimization.</p>
   translator.required=true
 
   # stkrc doesn't handle the -On options
-  translator.output=bytecode
+  translator.output=bitcode
 
 ##########################################################
 # Optimizer definitions
@@ -742,7 +742,7 @@ optimization.</p>
   # opt doesn't preprocess
   optimizer.preprocesses=no
 
-  # opt produces bytecode
+  # opt produces bitcode
   optimizer.output = bc
 
 ##########################################################
@@ -761,7 +761,7 @@ optimization.</p>
   defined below.</p>
   <dl>
     <dt><a name="def_assembly"><b>assembly</b></a></dt> 
-    <dd>A compilation <a href="#def_phase">phase</a> in which LLVM bytecode or 
+    <dd>A compilation <a href="#def_phase">phase</a> in which LLVM bitcode or 
     LLVM assembly code is assembled to a native code format (either target 
     specific aseembly language or the platform's native object file format).
     </dd>
@@ -774,12 +774,12 @@ optimization.</p>
     <dd>Refers to <tt>llvmc</tt> itself.</dd>
 
     <dt><a name="def_linking"><b>linking</b></a></dt>
-    <dd>A compilation <a href="#def_phase">phase</a> in which LLVM bytecode files 
+    <dd>A compilation <a href="#def_phase">phase</a> in which LLVM bitcode files 
     and (optionally) native system libraries are combined to form a complete 
     executable program.</dd>
 
     <dt><a name="def_optimization"><b>optimization</b></a></dt>
-    <dd>A compilation <a href="#def_phase">phase</a> in which LLVM bytecode is 
+    <dd>A compilation <a href="#def_phase">phase</a> in which LLVM bitcode is 
     optimized.</dd>
 
     <dt><a name="def_phase"><b>phase</b></a></dt>
@@ -804,7 +804,7 @@ optimization.</p>
     <dt><a name="def_translation"><b>translation</b></a></dt>
     <dd>A compilation <a href="#def_phase">phase</a> in which 
     <a href="#def_sourcelanguage">source language</a> code is translated into 
-    either LLVM assembly language or LLVM bytecode.</dd>
+    either LLVM assembly language or LLVM bitcode.</dd>
   </dl>
 </div>
 <!-- *********************************************************************** -->

llvm/docs/DeveloperPolicy.html

@@ -15,6 +15,7 @@
     <li><a href="#informed">Stay Informed</a></li>
     <li><a href="#patches">Making a Patch</a></li>
     <li><a href="#reviews">Code Reviews</a></li>
+    <li><a href="#owners">Code Owners</a></li>
     <li><a href="#testcases">Test Cases</a></li>
     <li><a href="#quality">Quality</a></li>
     <li><a href="#commitaccess">Obtaining Commit Access</a></li>
@@ -46,7 +47,7 @@
   <ol>
     <li>Attract both users and developers to the LLVM project.</li>
     <li>Make life as simple and easy for contributors as possible.</li>
-    <li>Keep the top of tree CVS/SVN trees as stable as possible.</li>
+    <li>Keep the top of Subversion trees as stable as possible.</li>
   </ol>
   
   <p>This policy is aimed at frequent contributors to LLVM. People interested in
@@ -93,16 +94,15 @@
 <p>When making a patch for review, the goal is to make it as easy for the
    reviewer to read it as possible.  As such, we recommend that you:</p>
   <ol>
-    <li>Make your patch against the CVS HEAD (main development trunk), 
-        not a branch, and not an old version of LLVM.  This makes it easy to
-        apply the patch.</li>
+    <li>Make your patch against the Subversion trunk, not a branch, and not an 
+    old version of LLVM.  This makes it easy to apply the patch.</li>
         
     <li>Similarly, patches should be submitted soon after they are generated.
     Old patches may not apply correctly if the underlying code changes between
     the time the patch was created and the time it is applied.</li>
         
     <li>Patches should be made with this command:
-    <pre>cvs diff -Ntdup -5</pre>
+    <pre>svn diff -x -u</pre>
      or with the utility <tt>utils/mkpatch</tt>, which makes it easy to read the
      diff.</li>
      
@@ -141,11 +141,55 @@
   <p>Developers should participate in code reviews as both reviewers and 
     reviewees. If someone is kind enough to review your code, you should
     return the favor for someone else.  Note that anyone is welcome to review
-    and give feedback on a patch, but only people with CVS write access can 
-    approve it.</p>
+    and give feedback on a patch, but only people with Subversion write access 
+    can approve it.</p>
 
 </div>
 
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"> <a name="owners">Code Owners</a></div>
+<div class="doc_text">
+
+  <p>The LLVM Project relies on two features of its process to maintain rapid
+     development in addition to the high quality of its source base: the
+     combination of code review plus post-commit review for trusted maintainers.
+     Having both is a great way for the project to take advantage of the fact
+     that most people do the right thing most of the time, and only commit
+     patches without pre-commit review when they are confident they are
+     right.</p>
+     
+  <p>The trick to this is that the project has to guarantee that all patches 
+     that are committed are reviewed after they go in: you don't want everyone
+     to assume someone else will review it, allowing the patch to go unreviewed.
+     To solve this problem, we have a notion of an 'owner' for a piece of the
+     code.  The sole responsibility of a code owner is to ensure that a commit
+     to their area of the code is appropriately reviewed, either by themself or
+     by someone else.  The current code owners are:</p>
+  
+  <ol>
+    <li><b>Anton Korobeynikov</b>: Exception handling, debug information, and
+        Windows codegen.</li>
+    <li><b>Duncan Sands</b>: llvm-gcc 4.2.</li>
+    <li><b>Evan Cheng</b>: Code generator and all targets.</li>
+    <li><b>Chris Lattner</b>: Everything else.</li>
+  </ol>
+  
+  <p>Note that code ownership is completely different than reviewers: anyone can
+     review a piece of code, and we welcome code review from anyone who is
+     interested.  Code owners are the "last line of defense" to guarantee that
+     all patches that are committed are actually reviewed.</p>
+
+  <p>Being a code owner is a somewhat unglamorous position, but it is incredibly
+     important for the ongoing success of the project.  Because people get busy,
+     interests change, and unexpected things happen, code ownership is purely
+     opt-in, and anyone can choose to resign their "title" at any time. For now,
+     we do not have an official policy on how one gets elected to be a code 
+     owner.
+  </p>
+
+</div>
+
+
 <!-- _______________________________________________________________________ -->
 <div class="doc_subsection"> <a name="testcases">Test Cases</a></div>
 <div class="doc_text">
@@ -228,10 +272,32 @@
 
 <p>
 We grant commit access to contributors with a track record of submitting high
-quality patches.  If you would like commit access, please send an email to the 
-<a href="mailto:llvm-oversight@cs.uiuc.edu">LLVM oversight group</a>.</p>
+quality patches.  If you would like commit access, please send an email to  
+<a href="mailto:sabre@nondot.org">Chris</a> with the following information:</p>
+
+<ol>
+  <li>The user name you want to commit with, e.g. "sabre".</li>
+  <li>The full name and email address you want message to llvm-commits to come
+      from, e.g. "Chris Lattner &lt;sabre@nondot.org&gt;".</li>
+  <li>A "password hash" of the password you want to use, e.g. "2ACR96qjUqsyM".  
+      Note that you don't ever tell us what your password is, you just give it
+      to us in an encrypted form.  To get this, run "htpasswd" (a utility that
+      comes with apache) in crypt mode (often enabled with "-d"), or find a web
+      page that will do it for you.</li>
+</ol>
+
+<p>Once you've been granted commit access, you should be able to check out an
+   LLVM tree with an SVN URL of "https://username@llvm.org/..." instead of the
+   normal anonymous URL of "http://llvm.org/...".  The first time you commit
+   you'll have to type in your password.  Note that you may get a warning from
+   SVN about an untrusted key, you can ignore this.  To verify that your commit
+   access works, please do a test commit (e.g. change a comment or add a blank
+   line).  Your first commit to a repository may require the autogenerated email
+   to be approved by a mailing list.  This is normal, and will be done when
+   the mailing list owner has time.</p>
 
 <p>If you have recently been granted commit access, these policies apply:</p>
+
 <ol>
   <li>You are granted <i>commit-after-approval</i> to all parts of LLVM.
   To get approval, submit a <a href="#patches">patch</a> to
@@ -351,28 +417,12 @@ Changes</a></div>
 <div class="doc_text">
   <p>We believe in correct attribution of contributions to 
   their contributors.  However, we do not want the source code to be littered
-  with random attributions (this is noisy/distracting and revision control
-  keeps a perfect history of this anyway).  As such, we follow these rules:</p>
-  <ol>
-    <li>Developers who originate new files in LLVM should place their name at
-    the top of the file per the 
-    <a href="CodingStandards.html#scf_commenting">Coding Standards</a>.</li>
-    <li>There should be only one name at the top of the file and it should be
-    the person who created the file.</li>
-    <li>Placing your name in the file does not imply <a
-        href="#clp">copyright</a>: it is only used to attribute the file to
-        its original author.</li>
-    <li>Developers should be aware that after some time has passed, the name at
-    the top of a file may become meaningless as maintenance/ownership of files
-    changes.  Despite this, once set, the attribution of a file never changes.
-    Revision control keeps an accurate history of contributions.</li>
-    <li>Developers should maintain their entry in the 
-    <a href="http://llvm.org/cvsweb/cvsweb.cgi/llvm/CREDITS.TXT?rev=HEAD&amp;content-type=text/x-cvsweb-markup">CREDITS.txt</a> 
-    file to summarize their contributions.</li>
-    <li>Commit comments should contain correct attribution of the person who
-    submitted the patch if that person is not the committer (i.e. when a 
-    developer with commit privileges commits a patch for someone else).</li>
-  </ol>
+  with random attributions "this code written by J Random Guy" (this is noisy
+  and distracting.  In practice, the revision control system keeps a perfect
+  history of who change what, and the CREDITS.txt file describes higher-level
+  contributions.</p>
+
+  <p>Overall, please do not add contributor names to the source base.</p>
 </div>
 
 

llvm/docs/ExceptionHandling.html

@@ -22,14 +22,14 @@
   <ol>
     <li><a href="#throw">Throw</a></li>
     <li><a href="#try_catch">Try/Catch</a></li>
-    <li><a href="#finallys">Finallys</a></li>
+    <li><a href="#cleanups">Cleanups</a></li>
     <li><a href="#throw_filters">Throw Filters</a></li>
+    <li><a href="#restrictions">Restrictions</a></li>
   </ol></li>
   <li><a href="#format_common_intrinsics">Exception Handling Intrinsics</a>
   <ol>
   	<li><a href="#llvm_eh_exception"><tt>llvm.eh.exception</tt></a></li>
   	<li><a href="#llvm_eh_selector"><tt>llvm.eh.selector</tt></a></li>
-  	<li><a href="#llvm_eh_filter"><tt>llvm.eh.filter</tt></a></li>
   	<li><a href="#llvm_eh_typeid_for"><tt>llvm.eh.typeid.for</tt></a></li>
   </ol></li>
   <li><a href="#asm">Asm Table Formats</a>
@@ -72,21 +72,20 @@ C/C++.</p>
 <p>Exception handling for most programming languages is designed to recover from
 conditions that rarely occur during general use of an application.  To that end,
 exception handling should not interfere with the main flow of an
-application&apos;s algorithm by performing checkpointing tasks such as saving
+application's algorithm by performing checkpointing tasks such as saving
 the current pc or register state.</p>
 
 <p>The Itanium ABI Exception Handling Specification defines a methodology for
 providing outlying data in the form of exception tables without inlining
-speculative exception handling code in the flow of an application&apos;s main
+speculative exception handling code in the flow of an application's main
 algorithm.  Thus, the specification is said to add "zero-cost" to the normal
 execution of an application.</p>
 
 <p>A more complete description of the Itanium ABI exception handling runtime
 support of can be found at <a
 href="http://www.codesourcery.com/cxx-abi/abi-eh.html">Itanium C++ ABI:
-Exception Handling.</a>  A description of the exception frame format can be
-found at <a
-href="http://refspecs.freestandards.org/LSB_3.0.0/LSB-Core-generic/LSB-
+Exception Handling.</a> A description of the exception frame format can be found
+at <a href="http://refspecs.freestandards.org/LSB_3.0.0/LSB-Core-generic/LSB-
 Core-generic/ehframechpt.html">Exception Frames</a>, with details of the Dwarf
 specification at <a href="http://www.eagercon.com/dwarf/dwarf3std.htm">Dwarf 3
 Standard.</a> A description for the C++ exception table formats can be found at
@@ -212,13 +211,20 @@ further use in the landing pad and catch code.</p>
 <p><a href="#llvm_eh_selector"><tt>llvm.eh.selector</tt></a> takes a minimum of
 three arguments.  The first argument is the reference to the exception
 structure. The second argument is a reference to the personality function to be
-used for this try catch sequence. The remaining arguments are references to the
-type infos for each of the catch statements in the order they should be tested.
-The <i>catch all</i> (...) is represented with a <tt>null i8*</tt>.  The result
-of the <a href="#llvm_eh_selector"><tt>llvm.eh.selector</tt></a> is the index of
-the type info in the corresponding exception table. The LLVM C++ front end
-generates code to save this value in an alloca location for further use in the
-landing pad and catch code.</p>
+used for this try catch sequence. Each of the remaining arguments is either a
+reference to the type info for a catch statement,
+a <a href="#throw_filters">filter</a> expression,
+or the number zero representing a <a href="#cleanups">cleanup</a>.
+The exception is tested against the arguments sequentially from first to last.
+The result of the <a href="#llvm_eh_selector"><tt>llvm.eh.selector</tt></a> is a
+positive number if the exception matched a type info, a negative number if it matched
+a filter, and zero if it matched a cleanup.  If nothing is matched, the behaviour of
+the program is <a href="#restrictions">undefined</a>.
+The LLVM C++ front end generates code to save the selector value in an alloca
+location for further use in the landing pad and catch code.
+If a type info matched then the selector value is the index of the type info in
+the exception table, which can be obtained using the
+<a href="#llvm_eh_typeid_for"><tt>llvm.eh.typeid.for</tt></a> intrinsic.</p>
 
 <p>Once the landing pad has the type info selector, the code branches to the
 code for the first catch.  The catch then checks the value of the type info
@@ -236,7 +242,7 @@ selector.</p>
 <p>Finally, the entry and exit of catch code is bracketed with calls to
 <tt>__cxa_begin_catch</tt> and <tt>__cxa_end_catch</tt>.
 <tt>__cxa_begin_catch</tt> takes a exception structure reference as an argument
-and returns the value of the exception object.</tt>  <tt>__cxa_end_catch</tt>
+and returns the value of the exception object. <tt>__cxa_end_catch</tt>
 takes a exception structure reference as an argument. This function clears the
 exception from the exception space.  Note: a rethrow from within the catch may
 replace this call with a <tt>__cxa_rethrow</tt>.</p>
@@ -245,7 +251,7 @@ replace this call with a <tt>__cxa_rethrow</tt>.</p>
 
 <!-- ======================================================================= -->
 <div class="doc_subsection">
-  <a name="finallys">Finallys</a>
+  <a name="cleanups">Cleanups</a>
 </div>
 
 <div class="doc_text">
@@ -254,7 +260,12 @@ replace this call with a <tt>__cxa_rethrow</tt>.</p>
 from a landing pad to the first catch.  Control may actually flow from the
 landing pad to clean up code and then to the first catch.  Since the required
 clean up for each invoke in a try may be different (ex., intervening
-constructor), there may be several landing pads for a given try.</p>
+constructor), there may be several landing pads for a given try.  If cleanups
+need to be run, the number zero should be passed as the last
+<a href="#llvm_eh_selector"><tt>llvm.eh.selector</tt></a> argument.
+However for C++ a <tt>null i8*</tt> <a href="#restrictions">must</a> be passed
+instead.
+</p>
 
 </div>
 
@@ -268,17 +279,45 @@ constructor), there may be several landing pads for a given try.</p>
 <p>C++ allows the specification of which exception types that can be thrown from
 a function.  To represent this a top level landing pad may exist to filter out
 invalid types.  To express this in LLVM code the landing pad will call <a
-href="#llvm_eh_filter"><tt>llvm.eh.filter</tt></a> instead of <a
 href="#llvm_eh_selector"><tt>llvm.eh.selector</tt></a>.  The arguments are the
-same, but what gets created in the exception table is different. <a
-href="#llvm_eh_filter"><tt>llvm.eh.filter</tt></a>  will return a negative value
-if it doesn't find a match. If no match is found then a call to
-<tt>__cxa_call_unexpected</tt> should be made, otherwise
+length of the filter expression (the number of type infos plus one), followed by
+the type infos themselves.
+<a href="#llvm_eh_selector"><tt>llvm.eh.selector</tt></a> will return a negative
+value if the exception does not match any of the type infos.  If no match is
+found then a call to <tt>__cxa_call_unexpected</tt> should be made, otherwise
 <tt>_Unwind_Resume</tt>.  Each of these functions require a reference to the
 exception structure.</p>
 
 </div>
 
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+  <a name="restrictions">Restrictions</a>
+</div>
+
+<div class="doc_text">
+
+<p>The semantics of the invoke instruction require that any exception that
+unwinds through an invoke call should result in a branch to the invoke's unwind
+label.  However such a branch will only happen if the
+<a href="#llvm_eh_selector"><tt>llvm.eh.selector</tt></a> matches.
+Thus in order to ensure correct operation, the front-end must only generate
+<a href="#llvm_eh_selector"><tt>llvm.eh.selector</tt></a> calls that are
+guaranteed to always match whatever exception unwinds through the invoke.
+For most languages it is enough to pass zero, indicating the presence of
+a <a href="#cleanups">cleanup</a>, as the last
+<a href="#llvm_eh_selector"><tt>llvm.eh.selector</tt></a> argument.
+However for C++ this is not sufficient, because the C++ personality function
+will terminate the program if it detects that unwinding the exception only
+results in matches with cleanups.  For C++ a <tt>null i8*</tt> should
+be passed as the last
+<a href="#llvm_eh_selector"><tt>llvm.eh.selector</tt></a> argument instead.
+This is interpreted as a catch-all by the C++ personality function, and will
+always match.
+</p>
+
+</div>
+
 <!-- ======================================================================= -->
 <div class="doc_section">
   <a name="format_common_intrinsics">Exception Handling Intrinsics</a>
@@ -315,7 +354,8 @@ exception structure reference.</p>
 
 <div class="doc_text">
 <pre>
-  i32 %<a href="#llvm_eh_selector">llvm.eh.selector</a>(i8*, i8*, i8*, ...)
+  i32 %<a href="#llvm_eh_selector">llvm.eh.selector.i32</a>(i8*, i8*, i8*, ...)
+  i64 %<a href="#llvm_eh_selector">llvm.eh.selector.i64</a>(i8*, i8*, i8*, ...)
 </pre>
 
 <p>This intrinsic indicates that the exception selector is available at this
@@ -326,32 +366,18 @@ exception selector.</p>
 <p><a href="#llvm_eh_selector"><tt>llvm.eh.selector</tt></a> takes a minimum of
 three arguments.  The first argument is the reference to the exception
 structure. The second argument is a reference to the personality function to be
-used for this try catch sequence. The remaining arguments are references to the
-type infos for each of the catch statements in the order they should be tested.
-The <i>catch all</i> (...) is represented with a <tt>null i8*</tt>.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsubsection">
-  <a name="llvm_eh_filter">llvm.eh.filter</a>
-</div>
-
-<div class="doc_text">
-<pre>
-  i32 %<a href="#llvm_eh_filter">llvm.eh.filter</a>(i8*, i8*, i8*, ...)
-</pre>
-
-<p>This intrinsic indicates that the exception selector is available at this
-point in the code.  The backend will replace this intrinsic with code to fetch
-the second argument of a call.  The effect is that the intrinsic result is the
-exception selector.</p>
-
-<p><a href="#llvm_eh_filter"><tt>llvm.eh.filter</tt></a> takes a minimum of
-three arguments.  The first argument is the reference to the exception
-structure. The second argument is a reference to the personality function to be
-used for this function. The remaining arguments are references to the type infos
-for each type that can be thrown by the current function.</p>
+used for this try catch sequence. Each of the remaining arguments is either a
+reference to the type info for a catch statement,
+a <a href="#throw_filters">filter</a> expression,
+or the number zero representing a <a href="#cleanups">cleanup</a>.
+The exception is tested against the arguments sequentially from first to last.
+The result of the <a href="#llvm_eh_selector"><tt>llvm.eh.selector</tt></a> is a
+positive number if the exception matched a type info, a negative number if it matched
+a filter, and zero if it matched a cleanup.  If nothing is matched, the behaviour of
+the program is <a href="#restrictions">undefined</a>.
+If a type info matched then the selector value is the index of the type info in
+the exception table, which can be obtained using the
+<a href="#llvm_eh_typeid_for"><tt>llvm.eh.typeid.for</tt></a> intrinsic.</p>
 
 </div>
 
@@ -362,7 +388,8 @@ for each type that can be thrown by the current function.</p>
 
 <div class="doc_text">
 <pre>
-  i32 %<a href="#llvm_eh_typeid_for">llvm.eh.typeid.for</a>(i8*)
+  i32 %<a href="#llvm_eh_typeid_for">llvm.eh.typeid.for.i32</a>(i8*)
+  i64 %<a href="#llvm_eh_typeid_for">llvm.eh.typeid.for.i64</a>(i8*)
 </pre>
 
 <p>This intrinsic returns the type info index in the exception table of the
@@ -410,7 +437,7 @@ all functions in the unit.</p>
 <div class="doc_text">
 
 <p>An exception table contains information about what actions to take when an
-exception is thrown in a particular part of a function&apos;s code.  There is
+exception is thrown in a particular part of a function's code.  There is
 one exception table per function except leaf routines and functions that have
 only calls to non-throwing functions will not need an exception table.</p>
 
@@ -427,16 +454,7 @@ only calls to non-throwing functions will not need an exception table.</p>
 
 <ol>
 
-<li><p>Need to create landing pads for code in between explicit landing pads. 
-The landing pads will have a zero action and a NULL landing pad address and are
-used to inform the runtime that the exception should be rethrown.</li></p>
-
-<li><p>Actions for a given function should be folded to save space.</p></li>
-
-<li><p>Filters for inlined functions need to be handled more extensively.
-Currently it&apos;s hardwired for one filter per function.</li></p>
-
-<li><p>Testing/Testing/Testing.</li></p>
+<li><p>Testing/Testing/Testing.</p></li>
 
 </ol>
 

llvm/docs/ExtendingLLVM.html

@@ -107,19 +107,17 @@ support for it.  Generally you must do the following steps:</p>
 <dt>Add support to the C backend in <tt>lib/Target/CBackend/</tt></dt>
 
 <dd>Depending on the intrinsic, there are a few ways to implement this.  For
-most intrinsics, it makes sense to add code to lower your intrinsic in 
-<tt>LowerIntrinsicCall</tt> in <tt>lib/CodeGen/IntrinsicLowering.cpp</tt>.
-Second, if it makes sense to lower the intrinsic to an expanded sequence of C 
-code in all cases, just emit the expansion in <tt>visitCallInst</tt> in
-<tt>Writer.cpp</tt>.  If the intrinsic has some way to express it with GCC 
-(or any other compiler) extensions, it can be conditionally supported based on 
-the compiler compiling the CBE output (see <tt>llvm.prefetch</tt> for an 
-example).  
-Third, if the intrinsic really has no way to be lowered, just have the code 
-generator emit code that prints an error message and calls abort if executed.
-</dd>
+    most intrinsics, it makes sense to add code to lower your intrinsic in
+    <tt>LowerIntrinsicCall</tt> in <tt>lib/CodeGen/IntrinsicLowering.cpp</tt>.
+    Second, if it makes sense to lower the intrinsic to an expanded sequence of
+    C code in all cases, just emit the expansion in <tt>visitCallInst</tt> in
+    <tt>Writer.cpp</tt>.  If the intrinsic has some way to express it with GCC
+    (or any other compiler) extensions, it can be conditionally supported based
+    on the compiler compiling the CBE output (see <tt>llvm.prefetch</tt> for an
+    example).  Third, if the intrinsic really has no way to be lowered, just
+    have the code generator emit code that prints an error message and calls
+    abort if executed.</dd>
 
-<dl>
 <dt>Add support to the .td file for the target(s) of your choice in 
    <tt>lib/Target/*/*.td</tt>.</dt>
 
@@ -127,6 +125,7 @@ generator emit code that prints an error message and calls abort if executed.
     the intrinsic, though it may obviously require adding the instructions you
     want to generate as well.  There are lots of examples in the PowerPC and X86
     backend to follow.</dd>
+</dl>
 
 </div>
 
@@ -228,7 +227,7 @@ complicated behavior in a single node (rotate).</p>
 
 <div class="doc_text">
 
-<p><span class="doc_warning">WARNING: adding instructions changes the bytecode
+<p><span class="doc_warning">WARNING: adding instructions changes the bitcode
 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>
@@ -251,8 +250,8 @@ necessary.</p>
     add the grammar on how your instruction can be read and what it will
     construct as a result</li>
 
-<li><tt>llvm/lib/Bytecode/Reader/Reader.cpp</tt>:
-    add a case for your instruction and how it will be parsed from bytecode</li>
+<li><tt>llvm/lib/Bitcode/Reader/Reader.cpp</tt>:
+    add a case for your instruction and how it will be parsed from bitcode</li>
 
 <li><tt>llvm/lib/VMCore/Instruction.cpp</tt>:
     add a case for how your instruction will be printed out to assembly</li>
@@ -285,7 +284,7 @@ to understand this new instruction.</p>
 
 <div class="doc_text">
 
-<p><span class="doc_warning">WARNING: adding new types changes the bytecode
+<p><span class="doc_warning">WARNING: adding new types changes the bitcode
 format, and will break compatibility with currently-existing LLVM
 installations.</span> Only add new types if it is absolutely necessary.</p>
 
@@ -348,12 +347,12 @@ bool TypesEqual(const Type *Ty, const Type *Ty2,
 <li><tt>llvm/lib/AsmReader/Lexer.l</tt>:
     add ability to parse in the type from text assembly</li>
 
-<li><tt>llvm/lib/ByteCode/Writer/Writer.cpp</tt>:
-    modify <tt>void BytecodeWriter::outputType(const Type *T)</tt> to serialize
+<li><tt>llvm/lib/BitCode/Writer/Writer.cpp</tt>:
+    modify <tt>void BitcodeWriter::outputType(const Type *T)</tt> to serialize
     your type</li>
 
-<li><tt>llvm/lib/ByteCode/Reader/Reader.cpp</tt>:
-    modify <tt>const Type *BytecodeReader::ParseType()</tt> to read your data
+<li><tt>llvm/lib/BitCode/Reader/Reader.cpp</tt>:
+    modify <tt>const Type *BitcodeReader::ParseType()</tt> to read your data
     type</li> 
 
 <li><tt>llvm/lib/VMCore/AsmWriter.cpp</tt>:

llvm/docs/FAQ.html

@@ -39,8 +39,8 @@
   <li>The <tt>configure</tt> script finds the right C compiler, but it uses the
   LLVM linker from a previous build.  What do I do?</li>
   <li>When creating a dynamic library, I get a strange GLIBC error.</li>
-  <li>I've updated my source tree from CVS, and now my build is trying to use a
-  file/directory that doesn't exist.</li>
+  <li>I've updated my source tree from Subversion, and now my build is trying 
+  to use a file/directory that doesn't exist.</li>
   <li>I've modified a Makefile in my source tree, but my build tree keeps using
   the old version.  What do I do?</li>
   <li>I've upgraded to a new version of LLVM, and I get strange build
@@ -50,8 +50,10 @@
   <li>Compiling LLVM with GCC 3.3.2 fails, what should I do?</li>
   <li>When I use the test suite, all of the C Backend tests fail.  What is
       wrong?</li>
-  <li>After CVS update, rebuilding gives the error "No rule to make
-  target".</li>
+  <li>After Subversion update, rebuilding gives the error "No rule to make
+      target".</li>
+  <li><a href="#llvmc">The <tt>llvmc</tt> program gives me errors/doesn't
+      work.</a></li>
   </ol></li>
 
   <li><a href="#felangs">Source Languages</a>
@@ -87,8 +89,6 @@
 
   <li><a href="#cfe_code">Questions about code generated by the GCC front-end</a>
   <ol>
-     <li><a href="#__main">What is this <tt>__main()</tt> call that gets inserted into
-         <tt>main()</tt>?</a></li>
      <li><a href="#iosinit">What is this <tt>llvm.global_ctors</tt> and
           <tt>_GLOBAL__I__tmp_webcompile...</tt> stuff that happens when I
           #include &lt;iostream&gt;?</a></li>
@@ -180,14 +180,12 @@ LLVM have been ported to a plethora of platforms.</p>
 <p>Some porting problems may exist in the following areas:</p>
 
 <ul>
-
   <li>The GCC front end code is not as portable as the LLVM suite, so it may not
-  compile as well on unsupported platforms.</li>
+      compile as well on unsupported platforms.</li>
 
   <li>The LLVM build system relies heavily on UNIX shell tools, like the Bourne
-  Shell and sed.  Porting to systems without these tools (MacOS 9, Plan 9) will
-  require more effort.</li>
-
+      Shell and sed.  Porting to systems without these tools (MacOS 9, Plan 9)
+      will require more effort.</li>
 </ul>
 
 </div>
@@ -225,21 +223,23 @@ if it's grabbing the wrong linker/assembler/etc, there are two ways to fix
 it:</p>
 
 <ol>
-		
   <li><p>Adjust your <tt>PATH</tt> environment variable so that the correct
-  program appears first in the <tt>PATH</tt>.  This may work, but may not be
-  convenient when you want them <i>first</i> in your path for other
-  work.</p></li>
+      program appears first in the <tt>PATH</tt>.  This may work, but may not be
+      convenient when you want them <i>first</i> in your path for other
+      work.</p></li>
 
   <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>
+      correct. In a Borne compatible shell, the syntax would be:</p>
+
+<div class="doc_code">
+<pre>
+% PATH=[the path without the bad program] ./configure ...
+</pre>
+</div>
 
       <p>This is still somewhat inconvenient, but it allows <tt>configure</tt>
-      to do its work without having to adjust your <tt>PATH</tt>
-      permanently.</p></li>
-	
+         to do its work without having to adjust your <tt>PATH</tt>
+         permanently.</p></li>
 </ol>
 
 </div>
@@ -255,8 +255,8 @@ your own version of GCC that has shared libraries enabled by default.</p>
 </div>
 
 <div class="question">
-<p>I've updated my source tree from CVS, and now my build is trying to use a
-file/directory that doesn't exist.</p>
+<p>I've updated my source tree from Subversion, and now my build is trying to 
+use a file/directory that doesn't exist.</p>
 </div>
 
 <div class="answer">
@@ -271,12 +271,13 @@ old version.  What do I do?</p>
 </div>
 
 <div class="answer">
-
 <p>If the Makefile already exists in your object tree, you
 can just run the following command in the top level directory of your object
 tree:</p>
 
-<p><tt>./config.status &lt;relative path to Makefile&gt;</tt><p>
+<div class="doc_code">
+<pre>% ./config.status &lt;relative path to Makefile&gt;</pre>
+</div>
 
 <p>If the Makefile is new, you will have to modify the configure script to copy
 it over.</p>
@@ -311,11 +312,18 @@ clean</tt> and then <tt>make</tt> in the directory that fails to build.</p>
 
 <p>For example, if you built LLVM with the command:</p>
 
-<p><tt>gmake ENABLE_PROFILING=1</tt>
+<div class="doc_code">
+<pre>% gmake ENABLE_PROFILING=1</pre>
+</div>
 
 <p>...then you must run the tests with the following commands:</p>
 
-<p><tt>cd llvm/test<br>gmake  ENABLE_PROFILING=1</tt></p>
+<div class="doc_code">
+<pre>
+% cd llvm/test
+% gmake ENABLE_PROFILING=1
+</pre>
+</div>
 
 </div>
 
@@ -343,27 +351,28 @@ build.</p>
 
 <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>
+affects projects other than LLVM.  Try upgrading or downgrading your GCC.</p>
 </div>
 
 <div class="question">
-<p>After CVS update, rebuilding gives the error "No rule to make target".</p>
+<p>After Subversion update, rebuilding gives the error "No rule to make
+target".</p>
 </div>
 
 <div class="answer">
 <p>If the error is of the form:</p>
 
 <div class="doc_code">
-<tt>
+<pre>
 gmake[2]: *** No rule to make target `/path/to/somefile', needed by
 `/path/to/another/file.d'.<br>
 Stop.
-</tt>
+</pre>
 </div>
 
-<p>This may occur anytime files are moved within the CVS repository or removed
-entirely.  In this case, the best solution is to erase all <tt>.d</tt> files,
-which list dependencies for source files, and rebuild:</p>
+<p>This may occur anytime files are moved within the Subversion repository or 
+removed entirely.  In this case, the best solution is to erase all 
+<tt>.d</tt> files, which list dependencies for source files, and rebuild:</p>
 
 <div class="doc_code">
 <pre>
@@ -377,6 +386,15 @@ which list dependencies for source files, and rebuild:</p>
 rebuilding.</p>
 </div>
 
+<div class="question"><p><a name="llvmc">
+The <tt>llvmc</tt> program gives me errors/doesn't work.</a></p>
+</div>
+
+<div class="answer">
+<p><tt>llvmc</tt> is experimental and isn't really supported. We suggest
+using <tt>llvm-gcc</tt> instead.</p>
+</div>
+
 <!-- *********************************************************************** -->
 <div class="doc_section"><a name="felangs">Source Languages</a></div>
 
@@ -388,17 +406,15 @@ rebuilding.</p>
   available through a special version of GCC that LLVM calls the 
   <a href="#cfe">C Front End</a></p>
   <p>There is an incomplete version of a Java front end available in the
-  <tt>llvm-java</tt> CVS repository. There is no documentation on this yet so
+  <tt>java</tt> module. There is no documentation on this yet so
   you'll need to download the code, compile it, and try it.</p>
-  <p>In the <tt>examples/BFtoLLVM</tt> directory is a translator for the 
-  BrainF*** language (2002 Language Specification).</p>
-  <p>In the <tt>projects/Stacker</tt> directory is a compiler and runtime
+  <p>In the <tt>stacker</tt> module is a compiler and runtime
   library for the Stacker language, a "toy" language loosely based on Forth.</p>
   <p>The PyPy developers are working on integrating LLVM into the PyPy backend
   so that PyPy language can translate to LLVM.</p>
 </div>
-<div class="question"><a name="langhlsupp">
-  <p>What support is there for a higher level source language constructs for 
+<div class="question"><p><a name="langhlsupp">
+  What support is there for a higher level source language constructs for 
   building a compiler?</a></p>
 </div>
 <div class="answer">
@@ -411,13 +427,12 @@ rebuilding.</p>
   of running optimizations, linking, and executable generation.</p>
 </div>
 
-<div class="question"><a name="langhlsupp">
-  <p>I don't understand the GetElementPtr
-      instruction. Help!</a></p>
+<div class="question"><p><a name="langhlsupp">
+  I don't understand the GetElementPtr instruction. Help!</a></p>
 </div>
 <div class="answer">
   <p>See <a href="GetElementPtr.html">The Often Misunderstood GEP
-   Instruction</a>.</li>
+   Instruction</a>.</p>
 </div>
 
 <!-- *********************************************************************** -->
@@ -471,11 +486,14 @@ find libcrtend.a.
 <p>
 The only way this can happen is if you haven't installed the runtime library. To
 correct this, do:</p>
+
+<div class="doc_code">
 <pre>
-  % cd llvm/runtime
-  % make clean ; make install-bytecode
+% cd llvm/runtime
+% make clean ; make install-bytecode
 </pre>
 </div>
+</div>
 
 <div class="question">
 <p>
@@ -510,79 +528,67 @@ C++ support for a processor that does not otherwise have a C++ compiler.
 <p>Use commands like this:</p>
 
 <ol>
-<li><p>Compile your program as normal with llvm-g++:</p></li>
-
-<div class="doc_code">$ llvm-g++ x.cpp -o program</div>
-
-<p>or:</p>
+  <li><p>Compile your program as normal with llvm-g++:</p>
 
 <div class="doc_code">
- llvm-g++ a.cpp -c<br>
- llvm-g++ b.cpp -c<br>
- llvm-g++ a.o b.o -o program
+<pre>
+% llvm-g++ x.cpp -o program
+</pre>
 </div>
 
-<p>With llvm-gcc3, this will generate program and program.bc.  The .bc file is 
-the LLVM version of the program all linked together.</p>
+  <p>or:</p>
 
-<li><p>Convert the LLVM code to C code, using the LLC tool with the C
-backend:</p></li>
+<div class="doc_code">
+<pre>
+% llvm-g++ a.cpp -c
+% llvm-g++ b.cpp -c
+% llvm-g++ a.o b.o -o program
+</pre>
+</div>
 
-<div class="doc_code">$ llc -march=c program.bc -o program.c</div>
+      <p>With llvm-gcc3, this will generate program and program.bc.  The .bc
+         file is the LLVM version of the program all linked together.</p></li>
 
-<li><p>Finally, compile the c file:</p></li>
+  <li><p>Convert the LLVM code to C code, using the LLC tool with the C
+      backend:</p>
 
-<div class="doc_code">$ cc x.c</div>
+<div class="doc_code">
+<pre>
+% llc -march=c program.bc -o program.c
+</pre>
+</div></li>
+
+<li><p>Finally, compile the C file:</p>
+
+<div class="doc_code">
+<pre>
+% cc x.c
+</pre>
+</div></li>
 
 </ol>
 
-<p>Note that, by default, the C backend does not support exception handling.
-If you want/need it for a certain program, you can enable it by passing
-"-enable-correct-eh-support" to the llc program.  The resultant code will
-use setjmp/longjmp to implement exception support that is correct but
-relatively slow.
-</p>
+<p>Note that, by default, the C backend does not support exception handling.  If
+you want/need it for a certain program, you can enable it by passing
+"-enable-correct-eh-support" to the llc program.  The resultant code will use
+setjmp/longjmp to implement exception support that is correct but relatively
+slow.</p>
 
-<p>Also note: this specific sequence of commands won't work if you use a 
-function defined in the C++ runtime library (or any other C++ library).  To 
-access an external C++ library, you must manually 
-compile libstdc++ to LLVM bytecode, statically link it into your program, then
-use the commands above to convert the whole result into C code.  Alternatively,
-you can compile the libraries and your application into two different chunks
-of C code and link them.</p>
+<p>Also note: this specific sequence of commands won't work if you use a
+function defined in the C++ runtime library (or any other C++ library).  To
+access an external C++ library, you must manually compile libstdc++ to LLVM
+bitcode, statically link it into your program, then use the commands above to
+convert the whole result into C code.  Alternatively, you can compile the
+libraries and your application into two different chunks of C code and link
+them.</p>
 
 </div>
 
-
-
 <!-- *********************************************************************** -->
 <div class="doc_section">
   <a name="cfe_code">Questions about code generated by the GCC front-end</a>
 </div>
 
-<div class="question"><p>
-<a name="__main"></a>
-What is this <tt>__main()</tt> call that gets inserted into <tt>main()</tt>?
-</p></div>
-
-<div class="answer">
-<p>
-The <tt>__main</tt> call is inserted by the C/C++ compiler in order to guarantee
-that static constructors and destructors are called when the program starts up
-and shuts down.  In C, you can create static constructors and destructors by
-using GCC extensions, and in C++ you can do so by creating a global variable
-whose class has a ctor or dtor.
-</p>
-
-<p>
-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">
 <a name="iosinit"></a>
 <p> What is this <tt>llvm.global_ctors</tt> and
@@ -650,12 +656,13 @@ a value that is not defined.  You can get these if you do not initialize a
 variable before you use it.  For example, the C function:</p>
 
 <div class="doc_code">
-  <tt>int X() { int i; return i; }</tt>
+<pre>
+int X() { int i; return i; }
+</pre>
 </div>
 
-<p>Is compiled to "<tt>ret int undef</tt>" because "i" never has a value 
-specified for it.
-</p>
+<p>Is compiled to "<tt>ret i32 undef</tt>" because "<tt>i</tt>" never has
+a value specified for it.</p>
 </div>
 
 <!-- *********************************************************************** -->

llvm/docs/GetElementPtr.html

@@ -53,7 +53,7 @@
   <p>When people are first confronted with the GEP instruction, they tend to
   relate it to known concepts from other programming paradigms, most notably C
   array indexing and field selection. However, GEP is a little different and
-  this leads to the following questions, all of which are answered in the
+  this leads to the following questions; all of which are answered in the
   following sections.</p>
   <ol>
     <li><a href="#firstptr">What is the first index of the GEP instruction?</a>
@@ -74,10 +74,15 @@
   <p>The confusion with the first index usually arises from thinking about 
   the GetElementPtr instruction as if it was a C index operator. They aren't the
   same. For example, when we write, in "C":</p>
-  <pre>
-  AType* Foo;
-  ...
-  X = &amp;Foo-&gt;F;</pre>
+
+<div class="doc_code">
+<pre>
+AType *Foo;
+...
+X = &amp;Foo-&gt;F;
+</pre>
+</div>
+
   <p>it is natural to think that there is only one index, the selection of the
   field <tt>F</tt>.  However, in this example, <tt>Foo</tt> is a pointer. That 
   pointer must be indexed explicitly in LLVM. C, on the other hand, indexs
@@ -85,8 +90,13 @@
   code, you would provide the GEP instruction with two index operands. The 
   first operand indexes through the pointer; the second operand indexes the 
   field <tt>F</tt> of the structure, just as if you wrote:</p>
-  <pre>
-  X = &amp;Foo[0].F;</pre>
+
+<div class="doc_code">
+<pre>
+X = &amp;Foo[0].F;
+</pre>
+</div>
+
   <p>Sometimes this question gets rephrased as:</p>
   <blockquote><p><i>Why is it okay to index through the first pointer, but 
       subsequent pointers won't be dereferenced?</i></p></blockquote> 
@@ -96,19 +106,23 @@
   the GEP instruction as an operand without any need for accessing memory. It 
   must, therefore be indexed and requires an index operand. Consider this 
   example:</p>
-  <pre>
-  struct munger_struct {
-    int f1;
-    int f2;
-  };
-  void munge(struct munger_struct *P)
-  {
-    P[0].f1 = P[1].f1 + P[2].f2;
-  }
-  ...
-  munger_struct Array[3];
-  ...
-  munge(Array);</pre>
+
+<div class="doc_code">
+<pre>
+struct munger_struct {
+  int f1;
+  int f2;
+};
+void munge(struct munger_struct *P) {
+  P[0].f1 = P[1].f1 + P[2].f2;
+}
+...
+munger_struct Array[3];
+...
+munge(Array);
+</pre>
+</div>
+
   <p>In this "C" example, the front end compiler (llvm-gcc) will generate three
   GEP instructions for the three indices through "P" in the assignment
   statement.  The function argument <tt>P</tt> will be the first operand of each
@@ -117,36 +131,50 @@
   <tt>struct munger_struct</tt> type,  for either the <tt>f1</tt> or 
   <tt>f2</tt> field. So, in LLVM assembly the <tt>munge</tt> function looks 
   like:</p>
-  <pre>
-  void %munge(%struct.munger_struct* %P) {
-  entry:
-    %tmp = getelementptr %struct.munger_struct* %P, i32 1, i32 0
-    %tmp = load i32* %tmp
-    %tmp6 = getelementptr %struct.munger_struct* %P, i32 2, i32 1
-    %tmp7 = load i32* %tmp6
-    %tmp8 = add i32 %tmp7, %tmp
-    %tmp9 = getelementptr %struct.munger_struct* %P, i32 0, i32 0
-    store i32 %tmp8, i32* %tmp9
-    ret void
-  }</pre>
+
+<div class="doc_code">
+<pre>
+void %munge(%struct.munger_struct* %P) {
+entry:
+  %tmp = getelementptr %struct.munger_struct* %P, i32 1, i32 0
+  %tmp = load i32* %tmp
+  %tmp6 = getelementptr %struct.munger_struct* %P, i32 2, i32 1
+  %tmp7 = load i32* %tmp6
+  %tmp8 = add i32 %tmp7, %tmp
+  %tmp9 = getelementptr %struct.munger_struct* %P, i32 0, i32 0
+  store i32 %tmp8, i32* %tmp9
+  ret void
+}
+</pre>
+</div>
+
   <p>In each case the first operand is the pointer through which the GEP
   instruction starts. The same is true whether the first operand is an
   argument, allocated memory, or a global variable. </p>
   <p>To make this clear, let's consider a more obtuse example:</p>
-  <pre>
-  %MyVar = unintialized global i32
-  ...
-  %idx1 = getelementptr i32* %MyVar, i64 0
-  %idx2 = getelementptr i32* %MyVar, i64 1
-  %idx3 = getelementptr i32* %MyVar, i64 2</pre>
+
+<div class="doc_code">
+<pre>
+%MyVar = unintialized global i32
+...
+%idx1 = getelementptr i32* %MyVar, i64 0
+%idx2 = getelementptr i32* %MyVar, i64 1
+%idx3 = getelementptr i32* %MyVar, i64 2
+</pre>
+</div>
+
   <p>These GEP instructions are simply making address computations from the 
   base address of <tt>MyVar</tt>.  They compute, as follows (using C syntax):
   </p>
-  <ul>
-    <li> idx1 = (char*) &amp;MyVar + 0</li>
-    <li> idx2 = (char*) &amp;MyVar + 4</li>
-    <li> idx3 = (char*) &amp;MyVar + 8</li>
-  </ul>
+
+<div class="doc_code">
+<pre>
+idx1 = (char*) &amp;MyVar + 0
+idx2 = (char*) &amp;MyVar + 4
+idx3 = (char*) &amp;MyVar + 8
+</pre>
+</div>
+
   <p>Since the type <tt>i32</tt> is known to be four bytes long, the indices 
   0, 1 and 2 translate into memory offsets of 0, 4, and 8, respectively. No 
   memory is accessed to make these computations because the address of 
@@ -168,10 +196,16 @@
   <p>Quick answer: there are no superfluous indices.</p>
   <p>This question arises most often when the GEP instruction is applied to a
   global variable which is always a pointer type. For example, consider
-  this:</p><pre>
-  %MyStruct = uninitialized global { float*, i32 }
-  ...
-  %idx = getelementptr { float*, i32 }* %MyStruct, i64 0, i32 1</pre>
+  this:</p>
+
+<div class="doc_code">
+<pre>
+%MyStruct = uninitialized global { float*, i32 }
+...
+%idx = getelementptr { float*, i32 }* %MyStruct, i64 0, i32 1
+</pre>
+</div>
+
   <p>The GEP above yields an <tt>i32*</tt> by indexing the <tt>i32</tt> typed 
   field of the structure <tt>%MyStruct</tt>. When people first look at it, they 
   wonder why the <tt>i64 0</tt> index is needed. However, a closer inspection 
@@ -205,10 +239,15 @@
   access memory in any way. That's what the Load and Store instructions are for.
   GEP is only involved in the computation of addresses. For example, consider 
   this:</p>
-  <pre>
-  %MyVar = uninitialized global { [40 x i32 ]* }
-  ...
-  %idx = getelementptr { [40 x i32]* }* %MyVar, i64 0, i32 0, i64 0, i64 17</pre>
+
+<div class="doc_code">
+<pre>
+%MyVar = uninitialized global { [40 x i32 ]* }
+...
+%idx = getelementptr { [40 x i32]* }* %MyVar, i64 0, i32 0, i64 0, i64 17
+</pre>
+</div>
+
   <p>In this example, we have a global variable, <tt>%MyVar</tt> that is a
   pointer to a structure containing a pointer to an array of 40 ints. The 
   GEP instruction seems to be accessing the 18th integer of the structure's
@@ -218,17 +257,27 @@
   GEP instruction never accesses memory, it is illegal.</p>
   <p>In order to access the 18th integer in the array, you would need to do the
   following:</p>
-  <pre>
-  %idx = getelementptr { [40 x i32]* }* %, i64 0, i32 0
-  %arr = load [40 x i32]** %idx
-  %idx = getelementptr [40 x i32]* %arr, i64 0, i64 17</pre>
+
+<div class="doc_code">
+<pre>
+%idx = getelementptr { [40 x i32]* }* %, i64 0, i32 0
+%arr = load [40 x i32]** %idx
+%idx = getelementptr [40 x i32]* %arr, i64 0, i64 17
+</pre>
+</div>
+
   <p>In this case, we have to load the pointer in the structure with a load
   instruction before we can index into the array. If the example was changed 
   to:</p>
-  <pre>
-  %MyVar = uninitialized global { [40 x i32 ] }
-  ...
-  %idx = getelementptr { [40 x i32] }*, i64 0, i32 0, i64 17</pre>
+
+<div class="doc_code">
+<pre>
+%MyVar = uninitialized global { [40 x i32 ] }
+...
+%idx = getelementptr { [40 x i32] }*, i64 0, i32 0, i64 17
+</pre>
+</div>
+
   <p>then everything works fine. In this case, the structure does not contain a
   pointer and the GEP instruction can index through the global variable,
   into the first field of the structure and access the 18th <tt>i32</tt> in the 
@@ -244,10 +293,15 @@
   <p>If you look at the first indices in these GEP
   instructions you find that they are different (0 and 1), therefore the address
   computation diverges with that index. Consider this example:</p>
-  <pre>
-  %MyVar = global { [10 x i32 ] }
-  %idx1 = getlementptr { [10 x i32 ] }* %MyVar, i64 0, i32 0, i64 1
-  %idx2 = getlementptr { [10 x i32 ] }* %MyVar, i64 1</pre>
+
+<div class="doc_code">
+<pre>
+%MyVar = global { [10 x i32 ] }
+%idx1 = getlementptr { [10 x i32 ] }* %MyVar, i64 0, i32 0, i64 1
+%idx2 = getlementptr { [10 x i32 ] }* %MyVar, i64 1
+</pre>
+</div>
+
   <p>In this example, <tt>idx1</tt> computes the address of the second integer
   in the array that is in the structure in %MyVar, that is <tt>MyVar+4</tt>. The 
   type of <tt>idx1</tt> is <tt>i32*</tt>. However, <tt>idx2</tt> computes the 
@@ -267,10 +321,15 @@
   <p>These two GEP instructions will compute the same address because indexing
   through the 0th element does not change the address. However, it does change
   the type. Consider this example:</p>
-  <pre>
-  %MyVar = global { [10 x i32 ] }
-  %idx1 = getlementptr { [10 x i32 ] }* %MyVar, i64 1, i32 0, i64 0
-  %idx2 = getlementptr { [10 x i32 ] }* %MyVar, i64 1</pre>
+
+<div class="doc_code">
+<pre>
+%MyVar = global { [10 x i32 ] }
+%idx1 = getlementptr { [10 x i32 ] }* %MyVar, i64 1, i32 0, i64 0
+%idx2 = getlementptr { [10 x i32 ] }* %MyVar, i64 1
+</pre>
+</div>
+
   <p>In this example, the value of <tt>%idx1</tt> is <tt>%MyVar+40</tt> and
   its type is <tt>i32*</tt>. The value of <tt>%idx2</tt> is also 
   <tt>MyVar+40</tt> but its type is <tt>{ [10 x i32] }*</tt>.</p>

llvm/docs/GettingStarted.html

@@ -17,38 +17,37 @@
   <li><a href="#quickstart">Getting Started Quickly (A Summary)</a>
   <li><a href="#requirements">Requirements</a>
     <ol>
-      <li><a href="#hardware">Hardware</a>
-      <li><a href="#software">Software</a>
-      <li><a href="#brokengcc">Broken versions of GCC</a>
+      <li><a href="#hardware">Hardware</a></li>
+      <li><a href="#software">Software</a></li>
+      <li><a href="#brokengcc">Broken versions of GCC and other tools</a></li>
     </ol></li>
 
   <li><a href="#starting">Getting Started with LLVM</a>
     <ol>
-      <li><a href="#terminology">Terminology and Notation</a>
-      <li><a href="#environment">Setting Up Your Environment</a>
-      <li><a href="#unpack">Unpacking the LLVM Archives</a>
-      <li><a href="#checkout">Checkout LLVM from CVS</a>
-      <li><a href="#installcf">Install the GCC Front End</a>
-      <li><a href="#config">Local LLVM Configuration</a>
-      <li><a href="#compile">Compiling the LLVM Suite Source Code</a>
-      <li><a href="#cross-compile">Cross-Compiling LLVM</a>
-      <li><a href="#objfiles">The Location of LLVM Object Files</a>
-      <li><a href="#optionalconfig">Optional Configuration Items</a>
+      <li><a href="#terminology">Terminology and Notation</a></li>
+      <li><a href="#environment">Setting Up Your Environment</a></li>
+      <li><a href="#unpack">Unpacking the LLVM Archives</a></li>
+      <li><a href="#checkout">Checkout LLVM from Subversion</a></li>
+      <li><a href="#installcf">Install the GCC Front End</a></li>
+      <li><a href="#config">Local LLVM Configuration</a></li>
+      <li><a href="#compile">Compiling the LLVM Suite Source Code</a></li>
+      <li><a href="#cross-compile">Cross-Compiling LLVM</a></li>
+      <li><a href="#objfiles">The Location of LLVM Object Files</a></li>
+      <li><a href="#optionalconfig">Optional Configuration Items</a></li>
     </ol></li>
 
   <li><a href="#layout">Program layout</a>
     <ol>
-      <li><a href="#cvsdir"><tt>CVS</tt> directories</a>
-      <li><a href="#examples"><tt>llvm/examples</tt></a>
-      <li><a href="#include"><tt>llvm/include</tt></a>
-      <li><a href="#lib"><tt>llvm/lib</tt></a>
-      <li><a href="#projects"><tt>llvm/projects</tt></a>
-      <li><a href="#runtime"><tt>llvm/runtime</tt></a>  
-      <li><a href="#test"><tt>llvm/test</tt></a>
-      <li><a href="#llvmtest"><tt>llvm-test</tt></a>
-      <li><a href="#tools"><tt>llvm/tools</tt></a>  
-      <li><a href="#utils"><tt>llvm/utils</tt></a>
-      <li><a href="#win32"><tt>llvm/win32</tt></a>
+      <li><a href="#examples"><tt>llvm/examples</tt></a></li>
+      <li><a href="#include"><tt>llvm/include</tt></a></li>
+      <li><a href="#lib"><tt>llvm/lib</tt></a></li>
+      <li><a href="#projects"><tt>llvm/projects</tt></a></li>
+      <li><a href="#runtime"><tt>llvm/runtime</tt></a></li>
+      <li><a href="#test"><tt>llvm/test</tt></a></li>
+      <li><a href="#llvmtest"><tt>llvm-test</tt></a></li>
+      <li><a href="#tools"><tt>llvm/tools</tt></a></li>
+      <li><a href="#utils"><tt>llvm/utils</tt></a></li>
+      <li><a href="#win32"><tt>llvm/win32</tt></a></li>
     </ol></li>
 
   <li><a href="#tutorial">An Example Using the LLVM Tool Chain</a>
@@ -83,14 +82,14 @@ basic information.</p>
 
 <p>First, LLVM comes in two pieces. The first piece is the LLVM suite. This
 contains all of the tools, libraries, and header files needed to use the low
-level virtual machine.  It contains an assembler, disassembler, bytecode
-analyzer and bytecode optimizer.  It also contains a test suite that can be
+level virtual machine.  It contains an assembler, disassembler, bitcode
+analyzer and bitcode optimizer.  It also contains a test suite that can be
 used to test the LLVM tools and the GCC front end.</p>
 
 <p>The second piece is the GCC front end.  This component provides a version of
-GCC that compiles C and C++ code into LLVM bytecode.  Currently, the GCC front
+GCC that compiles C and C++ code into LLVM bitcode.  Currently, the GCC front
 end uses the GCC parser to convert code to LLVM.  Once
-compiled into LLVM bytecode, a program can be manipulated with the LLVM tools
+compiled into LLVM bitcode, a program can be manipulated with the LLVM tools
 from the LLVM suite.</p>
 
 <p>
@@ -115,19 +114,19 @@ and performance.
   <li>Read the documentation.</li>
   <li>Read the documentation.</li>
   <li>Remember that you were warned twice about reading the documentation.</li>
-  <li>Install the GCC front end if you intend to compile C or C++:
+  <li>Install the llvm-gcc4.0 (or llvm-gcc4.2) front end if you intend to compile C or C++:
     <ol>
       <li><tt>cd <i>where-you-want-the-C-front-end-to-live</i></tt></li>
       <li><tt>gunzip --stdout llvm-gcc.<i>platform</i>.tar.gz | tar -xvf -</tt>
       </li>
-      <li><tt>cd llvm-gcc3.4/<i>platform</i> (llvm-gcc3.4 only)<br>
-        ./fixheaders</tt></li>
+      <ul><li>If the binary extension is ".bz" use bunzip2 instead of gunzip.</li>
+      </ul>
       <li>Add llvm-gcc's "bin" directory to your PATH variable.</li>
     </ol></li>
 
   <li>Get the LLVM Source Code
   <ul>
-    <li>With the distributed files (or use <a href="#checkout">CVS</a>):
+    <li>With the distributed files (or use <a href="#checkout">SVN</a>):
     <ol>
       <li><tt>cd <i>where-you-want-llvm-to-live</i></tt>
       <li><tt>gunzip --stdout llvm-<i>version</i>.tar.gz | tar -xvf -</tt>
@@ -137,7 +136,7 @@ and performance.
 
   <li><b>[Optional]</b> Get the Test Suite Source Code 
   <ul>
-    <li>With the distributed files (or use <a href="#checkout">CVS</a>):
+    <li>With the distributed files (or use <a href="#checkout">SVN</a>):
     <ol>
       <li><tt>cd <i>where-you-want-llvm-to-live</i></tt>
       <li><tt>cd llvm/projects</tt>
@@ -333,7 +332,7 @@ build requires considerably less space.</p>
 
 <p>The LLVM suite <i>may</i> compile on other platforms, but it is not
 guaranteed to do so.  If compilation is successful, the LLVM utilities should be
-able to assemble, disassemble, analyze, and optimize LLVM bytecode.  Code
+able to assemble, disassemble, analyze, and optimize LLVM bitcode.  Code
 generation should work as well, although the generated native code may not work
 on your platform.</p>
 
@@ -385,9 +384,9 @@ href="CFEBuildInstrs.html">try to compile it</a> on your platform.</p>
     </tr>
 
     <tr>
-      <td><a href="https://www.cvshome.org/downloads.html">CVS</a></td>
-      <td>&ge;1.11</td>
-      <td>CVS access to LLVM<sup><a href="#sf2">2</a></sup></td>
+      <td><a href="http://subversion.tigris.org/project_packages.html">SVN</a></td>
+      <td>&ge;1.3</td>
+      <td>Subversion access to LLVM<sup><a href="#sf2">2</a></sup></td>
     </tr>
 
     <tr>
@@ -446,9 +445,9 @@ href="CFEBuildInstrs.html">try to compile it</a> on your platform.</p>
     <li><a name="sf1">Only the C and C++ languages are needed so there's no
       need to build the other languages for LLVM's purposes.</a> See 
       <a href="#brokengcc">below</a> for specific version info.</li>
-    <li><a name="sf2">You only need CVS if you intend to build from the 
+    <li><a name="sf2">You only need Subversion if you intend to build from the 
       latest LLVM sources. If you're working from a release distribution, you
-      don't need CVS.</a></li>
+      don't need Subversion.</a></li>
     <li><a name="sf3">Only needed if you want to run the automated test 
       suite in the <tt>llvm/test</tt> directory.</a></li>
     <li><a name="sf4">If you want to make changes to the configure scripts, 
@@ -470,7 +469,6 @@ href="CFEBuildInstrs.html">try to compile it</a> on your platform.</p>
     <li><b>date</b> - print the current date/time </li>
     <li><b>echo</b> - print to standard output</li>
     <li><b>egrep</b> - extended regular expression search utility</li>
-    <li><b>etags</b> - C/C++ tag file creator for vim/emacs</li>
     <li><b>find</b> - find files/dirs in a file system</li>
     <li><b>grep</b> - regular expression search utility</li>
     <li><b>gzip*</b> - gzip command for distribution generation</li>
@@ -491,7 +489,7 @@ href="CFEBuildInstrs.html">try to compile it</a> on your platform.</p>
 
 <!-- ======================================================================= -->
 <div class="doc_subsection">
-  <a name="brokengcc">Broken versions of GCC</a>
+  <a name="brokengcc">Broken versions of GCC and other tools</a>
 </div>
 
 <div class="doc_text">
@@ -499,8 +497,8 @@ href="CFEBuildInstrs.html">try to compile it</a> on your platform.</p>
 <p>LLVM is very demanding of the host C++ compiler, and as such tends to expose
 bugs in the compiler.  In particular, several versions of GCC crash when trying
 to compile LLVM.  We routinely use GCC 3.3.3, 3.4.0, and Apple 4.0.1 
-successfully with them (however, see below).  Other versions of GCC will 
-probably work as well.  GCC versions listed
+successfully with them (however, see important notes below).  Other versions 
+of GCC will probably work as well.  GCC versions listed
 here are known to not work.  If you are using one of these versions, please try
 to upgrade your GCC to something more recent.  If you run into a problem with a
 version of GCC not listed here, please <a href="mailto:llvmdev@cs.uiuc.edu">let
@@ -525,8 +523,19 @@ the "<tt>convert_from_eh_region_ranges_1</tt>" GCC function.</p>
    possibly others) does not compile LLVM correctly (it appears that exception 
    handling is broken in some cases).  Please download the FSF 3.3.3 or upgrade
    to a newer version of GCC.</p>
-<p><b>GCC 3.4.x</b> on X86-64/amd64</b>: GCC <a href="http://llvm.org/PR1056">
+<p><b>GCC 3.4.0 on linux/x86 (32-bit)</b>: GCC miscompiles portions of the 
+   code generator, causing an infinite loop in the llvm-gcc build when built
+   with optimizations enabled (i.e. a release build).</p>
+<p><b>GCC 3.4.2 on linux/x86 (32-bit)</b>: GCC miscompiles portions of the 
+   code generator at -O3, as with 3.4.0.  However gcc 3.4.2 (unlike 3.4.0)
+   correctly compiles LLVM at -O2.  A work around is to build release LLVM
+   builds with "make ENABLE_OPTIMIZED=1 OPTIMIZE_OPTION=-O2 ..."</p>
+<p><b>GCC 3.4.x on X86-64/amd64</b>: GCC <a href="http://llvm.org/PR1056">
    miscompiles portions of LLVM</a>.</p>
+<p><b>GCC 3.4.4 (CodeSourcery ARM 2005q3-2)</b>: this compiler miscompiles LLVM
+   when building with optimizations enabled.  It appears to work with 
+   "<tt>make ENABLE_OPTIMIZED=1 OPTIMIZE_OPTION=-O1</tt>" or build a debug
+   build.</p>
 <p><b>IA-64 GCC 4.0.0</b>: The IA-64 version of GCC 4.0.0 is known to
    miscompile LLVM.</p>
 <p><b>Apple Xcode 2.3</b>: GCC crashes when compiling LLVM at -O3 (which is the
@@ -546,6 +555,12 @@ long warning messages complaining that some ".gnu.linkonce.t.*" symbol was
 defined in a discarded section. You can safely ignore these messages as they are
 erroneous and the linkage is correct.  These messages disappear using ld
 2.17.</p>
+
+<p><b>GNU binutils 2.17</b>: Binutils 2.17 contains <a 
+href="http://sourceware.org/bugzilla/show_bug.cgi?id=3111">a bug</a> which
+causes huge link times (minutes instead of seconds) when building LLVM.  We
+recommend upgrading to a newer version (2.17.50.0.4 or later).</p>
+
 </div>
 
 
@@ -617,11 +632,11 @@ In order to compile and use LLVM, you may need to set some environment
 variables.
 
 <dl>
-  <dt><tt>LLVM_LIB_SEARCH_PATH</tt>=<tt>/path/to/your/bytecode/libs</tt></dt>
+  <dt><tt>LLVM_LIB_SEARCH_PATH</tt>=<tt>/path/to/your/bitcode/libs</tt></dt>
   <dd>[Optional] This environment variable helps LLVM linking tools find the
-  locations of your bytecode libraries. It is provided only as a
+  locations of your bitcode libraries. It is provided only as a
   convenience since you can specify the paths using the -L options of the
-  tools and the C/C++ front-end will automatically use the bytecode files
+  tools and the C/C++ front-end will automatically use the bitcode files
   installed in its
   <tt>lib</tt> directory.</dd>
 </dl>
@@ -668,32 +683,36 @@ svn://anonsvn.opensource.apple.com/svn/llvm/trunk. </p>
 
 <!-- ======================================================================= -->
 <div class="doc_subsection">
-  <a name="checkout">Checkout LLVM from CVS</a>
+  <a name="checkout">Checkout LLVM from Subversion</a>
 </div>
 
 <div class="doc_text">
 
-<p>If you have access to our CVS repository, you can get a fresh copy of
-the entire source code.  All you need to do is check it out from CVS as
+<p>If you have access to our Subversion repository, you can get a fresh copy of
+the entire source code.  All you need to do is check it out from Subvresion as
 follows:</p>
 
 <ul>
-<li><tt>cd <i>where-you-want-llvm-to-live</i></tt>
-  <li><tt>cvs -d :pserver:anon@llvm.org:/var/cvs/llvm login</tt>
-  <li>Hit the return key when prompted for the password.
-  <li><tt>cvs -z3 -d :pserver:anon@llvm.org:/var/cvs/llvm co
-      llvm</tt>
+  <li><tt>cd <i>where-you-want-llvm-to-live</i></tt></li>
+  <li>Read-Only: <tt>svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm</tt></li>
+  <li>Read-Write:<tt>svn co https://user@llvm.org/svn/llvm-project/llvm/trunk
+    llvm</tt></li>
 </ul>
 
+
 <p>This will create an '<tt>llvm</tt>' directory in the current
 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
-labels:</p>
+revision), you can checkout it from the '<tt>tags</tt>' directory (instead of
+'<tt>trunk</tt>'). The following releases are located in the following
+  subdirectories of the '<tt>tags</tt>' directory:</p>
 
 <ul>
+<li>Release 2.2: <b>RELEASE_22</b></li>
+<li>Release 2.1: <b>RELEASE_21</b></li>
+<li>Release 2.0: <b>RELEASE_20</b></li>
 <li>Release 1.9: <b>RELEASE_19</b></li>
 <li>Release 1.8: <b>RELEASE_18</b></li>
 <li>Release 1.7: <b>RELEASE_17</b></li>
@@ -707,14 +726,18 @@ labels:</p>
 </ul>
 
 <p>If you would like to get the LLVM test suite (a separate package as of 1.4),
-you get it from the CVS repository:</p>
+you get it from the Subversion repository:</p>
+
+<div class="doc_code">
 <pre>
-  cd llvm/projects
-  cvs -z3 -d :pserver:anon@llvm.org:/var/cvs/llvm co llvm-test
+% cd llvm/projects
+% svn co http://llvm.org/svn/llvm-project/test-suite/trunk llvm-test
 </pre>
+</div>
+
 <p>By placing it in the <tt>llvm/projects</tt>, it will be automatically
 configured by the LLVM configure script as well as automatically updated when
-you run <tt>cvs update</tt>.</p>
+you run <tt>svn update</tt>.</p>
 
 <p>If you would like to get the GCC front end source code, you can also get it 
 and build it yourself.  Please follow <a href="CFEBuildInstrs.html">these 
@@ -769,7 +792,8 @@ much easier now than it was in the past.</p>
 
 <div class="doc_text">
 
-<p>Once checked out from the CVS repository, the LLVM suite source code must be
+  <p>Once checked out from the Subversion repository, the LLVM suite source 
+  code must be
 configured via the <tt>configure</tt> script.  This script sets variables in the
 various <tt>*.in</tt> files, most notably <tt>llvm/Makefile.config</tt> and 
 <tt>llvm/include/Config/config.h</tt>.  It also populates <i>OBJ_ROOT</i> with 
@@ -867,15 +891,16 @@ script to configure the build system:</p>
 <p>To configure LLVM, follow these steps:</p>
 
 <ol>
-    <li>Change directory into the object root directory:
-    <br>
-    <tt>cd <i>OBJ_ROOT</i></tt>
-    <br><br>
+    <li><p>Change directory into the object root directory:</p>
 
-    <li>Run the <tt>configure</tt> script located in the LLVM source tree:
-    <br>
-    <tt><i>SRC_ROOT</i>/configure --prefix=/install/path [other options]</tt>
-    <br><br>
+    <div class="doc_code"><pre>% cd <i>OBJ_ROOT</i></pre></div></li>
+
+    <li><p>Run the <tt>configure</tt> script located in the LLVM source
+    tree:</p>
+
+    <div class="doc_code">
+    <pre>% <i>SRC_ROOT</i>/configure --prefix=/install/path [other options]</pre>
+    </div></li>
 </ol>
 
 </div>
@@ -919,7 +944,7 @@ builds:</p>
 <p>Once you have LLVM configured, you can build it by entering the
 <i>OBJ_ROOT</i> directory and issuing the following command:</p>
 
-<p><tt>gmake</tt></p>
+<div class="doc_code"><pre>% gmake</pre></div>
 
 <p>If the build fails, please <a href="#brokengcc">check here</a> to see if you
 are using a version of GCC that is known not to compile LLVM.</p>
@@ -929,7 +954,7 @@ 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>
 
-<p><tt>gmake -j2</tt></p>
+<div class="doc_code"><pre>% gmake -j2</pre></div>
 
 <p>There are several special targets which are useful when working with the LLVM
 source code:</p>
@@ -959,8 +984,8 @@ source code:</p>
   <dt><tt>gmake -C runtime install-bytecode</tt>
   <dd>
   Assuming you built LLVM into $OBJDIR, when this command is run, it will 
-  install bytecode libraries into the GCC front end's bytecode library 
-  directory.  If you need to update your bytecode libraries,
+  install bitcode libraries into the GCC front end's bitcode library 
+  directory.  If you need to update your bitcode libraries,
   this is the target to use once you've built them.
   <br><br>
 </dl>
@@ -1067,12 +1092,12 @@ platforms or configurations using the same source tree.</p>
 <ul>
   <li><p>Change directory to where the LLVM object files should live:</p>
 
-      <p><tt>cd <i>OBJ_ROOT</i></tt></p></li>
+      <div class="doc_code"><pre>% cd <i>OBJ_ROOT</i></pre></div></li>
 
   <li><p>Run the <tt>configure</tt> script found in the LLVM source
       directory:</p>
 
-      <p><tt><i>SRC_ROOT</i>/configure</tt></p></li>
+      <div class="doc_code"><pre>% <i>SRC_ROOT</i>/configure</pre></div></li>
 </ul>
 
 <p>The LLVM build will place files underneath <i>OBJ_ROOT</i> in directories
@@ -1120,23 +1145,22 @@ named after the build type:</p>
 
 <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>"
+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
+execute LLVM bitcode files directly. To do this, use commands like this (the
 first command may not be required if you are already using the module):</p>
 
 <div class="doc_code">
 <pre>
-   $ mount -t binfmt_misc none /proc/sys/fs/binfmt_misc
-   $ echo ':llvm:M::llvm::/path/to/lli:' &gt; /proc/sys/fs/binfmt_misc/register
-   $ chmod u+x hello.bc                (if needed)
-   $ ./hello.bc
+$ mount -t binfmt_misc none /proc/sys/fs/binfmt_misc
+$ echo ':llvm:M::llvm::/path/to/lli:' &gt; /proc/sys/fs/binfmt_misc/register
+$ chmod u+x hello.bc   (if needed)
+$ ./hello.bc
 </pre>
 </div>
 
 <p>
-This allows you to execute LLVM bytecode files directly.  Thanks to Jack
+This allows you to execute LLVM bitcode files directly.  Thanks to Jack
 Cummings for pointing this out!
 </p>
 
@@ -1158,13 +1182,6 @@ The following is a brief introduction to code layout:</p>
 
 </div>
 
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="cvsdir"><tt>CVS</tt> directories</a></div>
-<div class="doc_text">
-<p>Every directory checked out of CVS will contain a <tt>CVS</tt> directory; for
-the most part these can just be ignored.</p>
-</div>
-
 <!-- ======================================================================= -->
 <div class="doc_subsection"><a name="examples"><tt>llvm/examples</tt></a></div>
 <div class="doc_text">
@@ -1217,8 +1234,8 @@ different <a href="#tools">tools</a>.</p>
   <dd>This directory holds the source code for the LLVM assembly language parser 
   library.</dd>
 
-  <dt><tt><b>llvm/lib/ByteCode/</b></tt></dt>
-  <dd>This directory holds code for reading and write LLVM bytecode.</dd>
+  <dt><tt><b>llvm/lib/BitCode/</b></tt></dt>
+  <dd>This directory holds code for reading and write LLVM bitcode.</dd>
 
   <dt><tt><b>llvm/lib/Analysis/</b></tt><dd>This directory contains a variety of
   different program analyses, such as Dominator Information, Call Graphs,
@@ -1247,7 +1264,7 @@ different <a href="#tools">tools</a>.</p>
   source code locations at which the program is executing.</dd>
 
   <dt><tt><b>llvm/lib/ExecutionEngine/</b></tt></dt>
-  <dd> This directory contains libraries for executing LLVM bytecode directly 
+  <dd> This directory contains libraries for executing LLVM bitcode directly 
   at runtime in both interpreted and JIT compiled fashions.</dd>
 
   <dt><tt><b>llvm/lib/Support/</b></tt></dt>
@@ -1275,7 +1292,7 @@ different <a href="#tools">tools</a>.</p>
 <div class="doc_subsection"><a name="runtime"><tt>llvm/runtime</tt></a></div>
 <div class="doc_text">
 
-<p>This directory contains libraries which are compiled into LLVM bytecode and
+<p>This directory contains libraries which are compiled into LLVM bitcode and
 used when linking programs with the GCC front end.  Most of these libraries are
 skeleton versions of real libraries; for example, libc is a stripped down
 version of glibc.</p>
@@ -1294,13 +1311,16 @@ end to compile.</p>
 </div>
 
 <!-- ======================================================================= -->
-<div class="doc_subsection"><a name="llvmtest"><tt>llvm-test</tt></a></div>
+<div class="doc_subsection"><a name="llvmtest"><tt>test-suite</tt></a></div>
 <div class="doc_text">
-  <p>This is not a directory in the normal llvm module; it is a separate CVS
-  module that must be checked out (usually to <tt>projects/llvm-test</tt>). This
+  <p>This is not a directory in the normal llvm module; it is a separate
+  Subversion
+  module that must be checked out (usually to <tt>projects/test-suite</tt>). 
+  This
   module contains a comprehensive correctness, performance, and benchmarking
   test
-  suite for LLVM. It is a separate CVS module because not every LLVM user is
+  suite for LLVM. It is a separate Subversion module because not every LLVM 
+  user is
   interested in downloading or building such a comprehensive test suite. For
   further details on this test suite, please see the 
   <a href="TestingGuide.html">Testing Guide</a> document.</p>
@@ -1331,22 +1351,22 @@ information is in the <a href="CommandGuide/index.html">Command Guide</a>.</p>
   be configured to utilize both LLVM and non-LLVM compilation tools to enable
   pre-processing, translation, optimization, assembly, and linking of programs
   all from one command line. <tt>llvmc</tt> also takes care of processing the
-  dependent libraries found in bytecode. This reduces the need to get the
+  dependent libraries found in bitcode. This reduces the need to get the
   traditional <tt>-l&lt;name&gt;</tt> options right on the command line. Please
   note that this tool, while functional, is still experimental and not feature
   complete.</dd>
 
   <dt><tt><b>llvm-ar</b></tt></dt>
   <dd>The archiver produces an archive containing
-  the given LLVM bytecode files, optionally with an index for faster
+  the given LLVM bitcode files, optionally with an index for faster
   lookup.</dd>
   
   <dt><tt><b>llvm-as</b></tt></dt>
   <dd>The assembler transforms the human readable LLVM assembly to LLVM 
-  bytecode.</dd>
+  bitcode.</dd>
 
   <dt><tt><b>llvm-dis</b></tt></dt>
-  <dd>The disassembler transforms the LLVM bytecode to human readable 
+  <dd>The disassembler transforms the LLVM bitcode to human readable 
   LLVM assembly.</dd>
 
   <dt><tt><b>llvm-ld</b></tt></dt>
@@ -1361,35 +1381,32 @@ information is in the <a href="CommandGuide/index.html">Command Guide</a>.</p>
   
   <dt><tt><b>lli</b></tt></dt>
   <dd><tt>lli</tt> is the LLVM interpreter, which
-  can directly execute LLVM bytecode (although very slowly...). In addition
-  to a simple interpreter, <tt>lli</tt> also has a tracing mode (entered by
-  specifying <tt>-trace</tt> on the command line). Finally, for
-  architectures that support it (currently x86, Sparc, and PowerPC), by default,
-  <tt>lli</tt> will function as a Just-In-Time compiler (if the
-  functionality was compiled in), and will execute the code <i>much</i>
-  faster than the interpreter.</dd>
+  can directly execute LLVM bitcode (although very slowly...). For architectures
+  that support it (currently x86, Sparc, and PowerPC), by default, <tt>lli</tt>
+  will function as a Just-In-Time compiler (if the functionality was compiled
+  in), and will execute the code <i>much</i> faster than the interpreter.</dd>
 
   <dt><tt><b>llc</b></tt></dt>
   <dd> <tt>llc</tt> is the LLVM backend compiler, which
-  translates LLVM bytecode to a native code assembly file or to C code (with
+  translates LLVM bitcode to a native code assembly file or to C code (with
   the -march=c option).</dd>
 
   <dt><tt><b>llvm-gcc</b></tt></dt>
   <dd><tt>llvm-gcc</tt> is a GCC-based C frontend that has been retargeted to 
   use LLVM as its backend instead of GCC's RTL backend. It can also emit LLVM 
-  byte code or assembly (with the <tt>-emit-llvm</tt> option) instead of the
+  bitcode or assembly (with the <tt>-emit-llvm</tt> option) instead of the
   usual machine code output.  It works just like any other GCC compiler, 
   taking the typical <tt>-c, -S, -E, -o</tt> options that are typically used.  
   Additionally, the the source code for <tt>llvm-gcc</tt> is available as a 
-  separate CVS module.</dd>
+  separate Subversion module.</dd>
 
   <dt><tt><b>opt</b></tt></dt>
-  <dd><tt>opt</tt> reads LLVM bytecode, applies a series of LLVM to LLVM 
+  <dd><tt>opt</tt> reads LLVM bitcode, 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 
+  the resultant bitcode.  The '<tt>opt --help</tt>' command is a good way to 
   get a list of the program transformations available in LLVM.<br/>
   <dd><tt>opt</tt> can also be used to run a specific analysis on an input 
-  LLVM bytecode file and print out the results.  It is primarily useful for 
+  LLVM bitcode file and print out the results.  It is primarily useful for 
   debugging analyses, or familiarizing yourself with what an analysis does.</dd>
 </dl>
 </div>
@@ -1409,14 +1426,6 @@ are code generators for parts of LLVM infrastructure.</p>
   assuming that the other generates correct output. For the full user
   manual, run <tt>`perldoc codegen-diff'</tt>.<br><br>
 
-  <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
-  sections, so you can see at a glance what has changed. If you are at the
-  top of your LLVM CVS tree, running <tt>utils/cvsupdate</tt> is the
-  preferred way of updating the tree.<br><br>
-
   <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
@@ -1444,7 +1453,7 @@ are code generators for parts of LLVM infrastructure.</p>
   directory, switch to directory <tt>llvm/tools/llc</tt> and build it,
   causing a re-linking of LLC.<br><br>
 
-  <dt><tt><b>NightlyTest.pl</b></tt> and
+  <dt><tt><b>NewNightlyTest.pl</b></tt> and
   <tt><b>NightlyTestTemplate.html</b></tt> <dd>These files are used in a
   cron script to generate nightly status reports of the functionality of
   tools, and the results can be seen by following the appropriate link on
@@ -1487,9 +1496,9 @@ so we only include instructiosn for llvm-gcc4.
 
 <p><b>Note:</b> The <i>gcc4</i> frontend's invocation is <b><i>considerably different</i></b>
 from the previous <i>gcc3</i> frontend. In particular, the <i>gcc4</i> frontend <b><i>does not</i></b>
-create bytecode by default: <i>gcc4</i> produces native code. As the example below illustrates,
-the '--emit-llvm' flag is needed to produce LLVM bytecode output. For <i>makefiles</i> and
-<i>configure</i> scripts, the CFLAGS variable needs '--emit-llvm' to produce bytecode
+create bitcode by default: <i>gcc4</i> produces native code. As the example below illustrates,
+the '--emit-llvm' flag is needed to produce LLVM bitcode output. For <i>makefiles</i> and
+<i>configure</i> scripts, the CFLAGS variable needs '--emit-llvm' to produce bitcode
 output.</p>
 </div>
 
@@ -1499,41 +1508,46 @@ output.</p>
 <div class="doc_text">
 
 <ol>
-  <li>First, create a simple C file, name it 'hello.c':
-       <pre>
-   #include &lt;stdio.h&gt;
-   int main() {
-     printf("hello world\n");
-     return 0;
-   }
-       </pre></li>
+  <li><p>First, create a simple C file, name it 'hello.c':</p>
+
+<div class="doc_code">
+<pre>
+#include &lt;stdio.h&gt;
+
+int main() {
+  printf("hello world\n");
+  return 0;
+}
+</pre></div></li>
 
   <li><p>Next, compile the C file into a native executable:</p>
 
-      <p><tt>% llvm-gcc hello.c -o hello</tt></p>
+      <div class="doc_code"><pre>% llvm-gcc hello.c -o hello</pre></div>
 
       <p>Note that llvm-gcc works just like GCC by default.  The standard -S and
         -c arguments work as usual (producing a native .s or .o file,
-        respectively). </p>
+        respectively).</p></li>
 
-  <li><p>Next, compile the C file into a LLVM bytecode file:</p>
-      <p><tt>% llvm-gcc -O3 -emit-llvm hello.c -c -o hello.bc</tt></p>
+  <li><p>Next, compile the C file into a LLVM bitcode file:</p>
+
+      <div class="doc_code">
+      <pre>% llvm-gcc -O3 -emit-llvm hello.c -c -o hello.bc</pre></div>
 
       <p>The -emit-llvm option can be used with the -S or -c options to emit an
          LLVM ".ll" or ".bc" file (respectively) for the code.  This allows you
          to use the <a href="CommandGuide/index.html">standard LLVM tools</a> on
-         the bytecode file.</p>
+         the bitcode file.</p>
 
       <p>Unlike llvm-gcc3, llvm-gcc4 correctly responds to -O[0123] arguments.
          </p></li>
 
   <li><p>Run the program in both forms. To run the program, use:</p>
       
-      <p><tt>% ./hello</tt></p>
+      <div class="doc_code"><pre>% ./hello</pre></div>
  
       <p>and</p>
 
-      <p><tt>% lli hello.bc</tt></p>
+      <div class="doc_code"><pre>% lli hello.bc</pre></div>
 
       <p>The second examples shows how to invoke the LLVM JIT, <a
        href="CommandGuide/html/lli.html">lli</a>.</p></li>
@@ -1541,21 +1555,28 @@ output.</p>
   <li><p>Use the <tt>llvm-dis</tt> utility to take a look at the LLVM assembly
       code:</p>
 
-      <p><tt>% llvm-dis &lt; hello.bc | less</tt><br><br></li>
+<div class="doc_code">
+<pre>llvm-dis &lt; hello.bc | less</pre>
+</div></li>
 
   <li><p>Compile the program to native assembly using the LLC code
       generator:</p>
 
-      <p><tt>% llc hello.bc -o hello.s</tt></p>
+      <div class="doc_code"><pre>% llc hello.bc -o hello.s</pre></div></li>
 
   <li><p>Assemble the native assembly language 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>
+<div class="doc_code">
+<pre>
+<b>Solaris:</b> % /opt/SUNWspro/bin/cc -xarch=v9 hello.s -o hello.native
+
+<b>Others:</b>  % gcc hello.s -o hello.native
+</pre>
+</div></li>
 
   <li><p>Execute the native code program:</p>
 
-      <p><tt>% ./hello.native</tt></p>
+      <div class="doc_code"><pre>% ./hello.native</pre></div>
 
       <p>Note that using llvm-gcc to compile directly to native code (i.e. when
          the -emit-llvm option is not present) does steps 6/7/8 for you.</p>

llvm/docs/GettingStartedVS.html

@@ -57,7 +57,7 @@
   <p>To emphasize, there is no C/C++ front end currently available.
   <tt>llvm-gcc</tt> is based on GCC, which cannot be bootstrapped using VC++.
   Eventually there should be a <tt>llvm-gcc</tt> based on Cygwin or MinGW that
-  is usable.  There is also the option of generating bytecode files on Unix and
+  is usable.  There is also the option of generating bitcode files on Unix and
   copying them over to Windows.  But be aware the odds of linking C++ code
   compiled with <tt>llvm-gcc</tt> with code compiled with VC++ is essentially
   zero.</p>
@@ -86,7 +86,7 @@
 
 <ol>
   <li>Read the documentation.</li>
-  <li>Read the documentation.</li>
+  <li>Seriously, read the documentation.</li>
   <li>Remember that you were warned twice about reading the documentation.</li>
 
   <li>Get the Source Code
@@ -99,16 +99,13 @@
       <li><tt>cd llvm</tt></li>
     </ol></li>
 
-    <li>With anonymous CVS access:
+    <li>With anonymous Subversion access:
     <ol>
       <li><tt>cd <i>where-you-want-llvm-to-live</i></tt></li>
-      <li><tt>cvs -d
-          :pserver:anon@llvm-cvs.cs.uiuc.edu:/var/cvs/llvm login</tt></li>
-      <li>Hit the return key when prompted for the password.
-      <li><tt>cvs -z3 -d :pserver:anon@llvm-cvs.cs.uiuc.edu:/var/cvs/llvm 
-          co llvm</tt></li>
+      <li><tt>svn co http://llvm.org/svn/llvm-project/llvm-top/trunk llvm-top
+      </tt></li>
+      <li><tt>make checkout MODULE=llvm</tt>
       <li><tt>cd llvm</tt></li>
-      <li><tt>cvs up -P -d</tt></li>
     </ol></li>
   </ul></li>
 
@@ -128,8 +125,8 @@
 
 </ol>
 
-<p>It is strongly encouraged that you get the latest version from CVS.  Much
-progress has been made since the 1.4 release.</p>
+<p>It is strongly encouraged that you get the latest version from Subversion as
+changes are continually making the VS support better.</p>
 
 </div>
 
@@ -175,6 +172,10 @@ progress has been made since the 1.4 release.</p>
   not need them and the pre-generated files that come with the source tree
   will be used.</p>
 
+  <p>
+  Do not install the LLVM directory tree into a path containing spaces (e.g.
+  C:\Documents and Settings\...) as the configure step will fail.</p>
+
 </div>
 
 <!-- *********************************************************************** -->
@@ -206,17 +207,13 @@ each of these names with the appropriate pathname on your local system.
 All these paths are absolute:</p>
 
 <dl>
-    <dt>SRC_ROOT
-    <dd>
-    This is the top level directory of the LLVM source tree.
-    <p>
+    <dt>SRC_ROOT</dt>
+    <dd><p>This is the top level directory of the LLVM source tree.</p></dd>
 
-    <dt>OBJ_ROOT
-    <dd>
-    This is the top level directory of the LLVM object tree (i.e. the
-    tree where object files and compiled programs will be placed.  It
-    is fixed at SRC_ROOT/win32).
-    <p>
+    <dt>OBJ_ROOT</dt>
+    <dd><p>This is the top level directory of the LLVM object tree (i.e. the
+        tree where object files and compiled programs will be placed.  It is
+        fixed at SRC_ROOT/win32).</p></dd>
 </dl>
 
 </div>
@@ -230,12 +227,12 @@ All these paths are absolute:</p>
 
   <p>The object files are placed under <tt>OBJ_ROOT/Debug</tt> for debug builds
   and <tt>OBJ_ROOT/Release</tt> for release (optimized) builds.  These include
-  both executables and libararies that your application can link against.
+  both executables and libararies that your application can link against.</p>
 
   <p>The files that <tt>configure</tt> would create when building on Unix are
   created by the <tt>Configure</tt> project and placed in
   <tt>OBJ_ROOT/llvm</tt>.  You application must have OBJ_ROOT in its include
-  search path just before <tt>SRC_ROOT/include</tt>.
+  search path just before <tt>SRC_ROOT/include</tt>.</p>
 
 </div>
 
@@ -248,57 +245,83 @@ All these paths are absolute:</p>
 <div class="doc_text">
 
 <ol>
-  <li>First, create a simple C file, name it 'hello.c':
-       <pre>
-   #include &lt;stdio.h&gt;
-   int main() {
-     printf("hello world\n");
-     return 0;
-   }
-       </pre></li>
+  <li><p>First, create a simple C file, name it 'hello.c':</p>
 
-  <li><p>Next, compile the C file into a LLVM bytecode file:</p>
-      <p><tt>% llvm-gcc -c hello.c -emit-llvm -o hello.bc</tt></p>
+<div class="doc_code">
+<pre>
+#include &lt;stdio.h&gt;
+int main() {
+  printf("hello world\n");
+  return 0;
+}
+</pre></div></li>
 
-      <p>This will create the result file <tt>hello.bc</tt> which is the LLVM 
-      bytecode that corresponds the the compiled program and the library 
-      facilities that it required.  You can execute this file directly using
-      <tt>lli</tt> tool, compile it to native assembly with the <tt>llc</tt>, 
-      optimize or analyze it further with the <tt>opt</tt> tool, etc.</p> 
+  <li><p>Next, compile the C file into a LLVM bitcode file:</p>
+
+<div class="doc_code">
+<pre>
+% llvm-gcc -c hello.c -emit-llvm -o hello.bc
+</pre>
+</div>
+
+      <p>This will create the result file <tt>hello.bc</tt> which is the LLVM
+         bitcode that corresponds the the compiled program and the library
+         facilities that it required.  You can execute this file directly using
+         <tt>lli</tt> tool, compile it to native assembly with the <tt>llc</tt>,
+         optimize or analyze it further with the <tt>opt</tt> tool, etc.</p>
       
       <p><b>Note: while you cannot do this step on Windows, you can do it on a
-        Unix system and transfer <tt>hello.bc</tt> to Windows.  Important:
-        transfer as a binary file!</b></p></li>
+         Unix system and transfer <tt>hello.bc</tt> to Windows.  Important:
+         transfer as a binary file!</b></p></li>
 
   <li><p>Run the program using the just-in-time compiler:</p>
       
-      <p><tt>% lli hello.bc</tt></p></li>
+<div class="doc_code">
+<pre>
+% lli hello.bc
+</pre>
+</div>
 
       <p>Note: this will only work for trivial C programs.  Non-trivial programs
-        (and any C++ program) will have dependencies on the GCC runtime that
-        won't be satisfied by the Microsoft runtime libraries.</p>
+         (and any C++ program) will have dependencies on the GCC runtime that
+         won't be satisfied by the Microsoft runtime libraries.</p></li>
 
   <li><p>Use the <tt>llvm-dis</tt> utility to take a look at the LLVM assembly
       code:</p>
 
-      <p><tt>% llvm-dis &lt; hello.bc | more</tt><p></li>
+<div class="doc_code">
+<pre>
+% llvm-dis &lt; hello.bc | more
+</pre>
+</div></li>
 
   <li><p>Compile the program to C using the LLC code generator:</p>
 
-      <p><tt>% llc -march=c hello.bc</tt></p></li>
+<div class="doc_code">
+<pre>
+% llc -march=c hello.bc
+</pre>
+</div></li>
 
   <li><p>Compile to binary using Microsoft C:</p>
 
-      <p><tt>% cl hello.cbe.c</tt></p></li>
+<div class="doc_code">
+<pre>
+% cl hello.cbe.c
+</pre>
+</div>
 
       <p>Note: this will only work for trivial C programs.  Non-trivial programs
         (and any C++ program) will have dependencies on the GCC runtime that
-        won't be satisfied by the Microsoft runtime libraries.</p>
+        won't be satisfied by the Microsoft runtime libraries.</p></li>
 
   <li><p>Execute the native code program:</p>
 
-      <p><tt>% hello.cbe.exe</tt></p></li>
-
+<div class="doc_code">
+<pre>
+% hello.cbe.exe
+</pre>
+</div></li>
 </ol>
 
 </div>
@@ -335,7 +358,7 @@ out:</p>
   <li><a href="http://llvm.org/">LLVM homepage</a></li>
   <li><a href="http://llvm.org/doxygen/">LLVM doxygen tree</a></li>
   <li><a href="http://llvm.org/docs/Projects.html">Starting a Project
-  that Uses LLVM</a></li>
+      that Uses LLVM</a></li>
 </ul>
 
 </div>

llvm/docs/HowToSubmitABug.html

@@ -67,7 +67,7 @@ information:</p>
 <ul>
   <li>All information necessary to reproduce the problem.</li>
   <li>The reduced test-case that triggers the bug.</li>
-  <li>The location where you obtained LLVM (if not from our CVS
+  <li>The location where you obtained LLVM (if not from our Subversion
   repository).</li>
 </ul>
 
@@ -242,7 +242,7 @@ JIT, or LLC) and optionally a series of LLVM passes to run.  For example:</p>
 </div>
 
 <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
+that causes an error, and simplify the bitcode file as much as it can to assist
 you. It will print a message letting you know how to reproduce the resulting
 error.</p>
 
@@ -268,7 +268,7 @@ Backend, and then link in the shared object it generates.</p>
 
 <div class="doc_code">
 <pre>
-bugpoint -run-jit -output=[correct output file] [bytecode file]  \
+bugpoint -run-jit -output=[correct output file] [bitcode file]  \
          --tool-args -- [arguments to pass to lli]               \
          --args -- [program arguments]
 </pre>
@@ -278,7 +278,7 @@ bugpoint -run-jit -output=[correct output file] [bytecode file]  \
 
 <div class="doc_code">
 <pre>
-bugpoint -run-llc -output=[correct output file] [bytecode file]  \
+bugpoint -run-llc -output=[correct output file] [bitcode file]  \
          --tool-args -- [arguments to pass to llc]               \
          --args -- [program arguments]
 </pre>
@@ -297,7 +297,7 @@ make bugpoint-jit
 </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
+with two bitcode files: a <em>safe</em> file which can be compiled with the C
 backend and the <em>test</em> file which either LLC or the JIT
 mis-codegenerates, and thus causes the error.</p>
 
@@ -306,7 +306,7 @@ the following:</p>
 
 <ol>
 
-<li><p>Regenerate the shared object from the safe bytecode file:</p>
+<li><p>Regenerate the shared object from the safe bitcode file:</p>
 
 <div class="doc_code">
 <p><tt>
@@ -315,7 +315,7 @@ the following:</p>
 </tt></p>
 </div></li>
 
-<li><p>If debugging LLC, compile test bytecode native and link with the shared
+<li><p>If debugging LLC, compile test bitcode native and link with the shared
     object:</p>
 
 <div class="doc_code">
@@ -327,7 +327,7 @@ the following:</p>
 </div></li>
     
 <li><p>If debugging the JIT, load the shared object and supply the test
-    bytecode:</p>
+    bitcode:</p>
 
 <div class="doc_code">
 <p><tt><b>lli</b> -load=safe.so test.bc [program options]</tt></p>

llvm/docs/Lexicon.html

@@ -30,13 +30,19 @@
     </tr>
     <tr><th colspan="8"><b>- <a href="#D">D</a> -</b></th></tr>
     <tr>
+      <td><a href="#DAG">DAG</a></td>
+      <td><a href="#Derived_Pointer">Derived Pointer</a></td>
       <td><a href="#DSA">DSA</a></td>
       <td><a href="#DSE">DSE</a></td>
     </tr>
+    <tr><th colspan="8"><b>- <a href="#G">G</a> -</b></th></tr>
+      <td><a href="#GC">GC</a></td>
+    </tr>
     <tr><th colspan="8"><b>- <a href="#I">I</a> -</b></th></tr>
     <tr>
       <td><a href="#IPA">IPA</a></td>
       <td><a href="#IPO">IPO</a></td>
+      <td><a href="#ISel">ISel</a></td>
     </tr>
     <tr><th colspan="8"><b>- <a href="#L">L</a> -</b></th></tr>
     <tr>
@@ -44,6 +50,10 @@
       <td><a href="#LICM">LICM</a></td>
       <td><a href="#Load-VN">Load-VN</a></td>
     </tr>
+    <tr><th colspan="8"><b>- <a href="#O">O</a> -</b></th></tr>
+    <tr>
+      <td><a href="#Object_Pointer">Object Pointer</a></td>
+    </tr>
     <tr><th colspan="8"><b>- <a href="#P">P</a> -</b></th></tr>
     <tr>
       <td><a href="#PRE">PRE</a></td>
@@ -51,13 +61,16 @@
     <tr><th colspan="8"><b>- <a href="#R">R</a> -</b></th></tr>
     <tr>
       <td><a href="#Reassociation">Reassociation</a></td>
+      <td><a href="#Root">Root</a></td>
     </tr>
     <tr><th colspan="8"><b>- <a href="#S">S</a> -</b></th></tr>
     <tr>
+      <td><a href="#Safe_Point">Safe Point</a></td>
       <td><a href="#SCC">SCC</a></td>
       <td><a href="#SCCP">SCCP</a></td>
+      <td><a href="#SDISel">SDISel</a></td>
       <td><a href="#SRoA">SRoA</a></td>
-      <td><a href="#SSA">SSA</a></td>
+      <td><a href="#Stack_Map">Stack Map</a></td>
     </tr>
   </table>
 </div>
@@ -92,13 +105,23 @@ href="http://www.program-transformation.org/Transform/BURG">BURG</a> tool.</dd>
     subexpression compuation. For example <tt>(a+b)*(a+b)</tt> has two
     subexpressions that are the same: <tt>(a+b)</tt>. This optimization would
     perform the addition only once and then perform the multiply (but only if
-    its compulationally correct/safe).
+    it's compulationally correct/safe).
   </dl>
 </div>
 <!-- _______________________________________________________________________ -->
 <div class="doc_subsection"><a name="D">- D -</a></div>
 <div class="doc_text">
   <dl>
+    <dt><a name="DAG"><b>DAG</b></a></dt>
+    <dd>Directed Acyclic Graph</dd>
+    <dt><a name="Derived_Pointer"><b>Derived Pointer</b></a></dt>
+    <dd>A pointer to the interior of an object, such that a garbage collector
+    is unable to use the pointer for reachability analysis. While a derived
+    pointer is live, the corresponding object pointer must be kept in a root,
+    otherwise the collector might free the referenced object. With copying
+    collectors, derived pointers pose an additional hazard that they may be
+    invalidated at any <a href="Safe_Point">safe point</a>. This term is used in
+    opposition to <a href="#Object_Pointer">object pointer</a>.</dd>
     <dt><a name="DSA"><b>DSA</b></a></dt>
     <dd>Data Structure Analysis</dd>
     <dt><a name="DSE"><b>DSE</b></a></dt>
@@ -106,6 +129,24 @@ href="http://www.program-transformation.org/Transform/BURG">BURG</a> tool.</dd>
   </dl>
 </div>
 <!-- _______________________________________________________________________ -->
+<div class="doc_subsection"><a name="G">- G -</a></div>
+<div class="doc_text">
+  <dl>
+    <dt><a name="GC"><b>GC</b></a></dt>
+    <dd>Garbage Collection. The practice of using reachability analysis instead
+    of explicit memory management to reclaim unused memory.</dd>
+  </dl>
+</div>
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"><a name="H">- H -</a></div>
+<div class="doc_text">
+  <dl>
+    <dt><a name="Heap"><b>Heap</b></a></dt>
+    <dd>In garbage collection, the region of memory which is managed using
+    reachability analysis.</dd>
+  </dl>
+</div>
+<!-- _______________________________________________________________________ -->
 <div class="doc_subsection"><a name="I">- I -</a></div>
 <div class="doc_text">
   <dl>
@@ -116,6 +157,8 @@ href="http://www.program-transformation.org/Transform/BURG">BURG</a> tool.</dd>
     <dd>Inter-Procedural Optimization. Refers to any variety of code
     optimization that occurs between procedures, functions or compilation units
     (modules).</dd>
+    <dt><a name="IPO"><b>ISel</b></a></dt>
+    <dd>Instruction Selection.</dd>
   </dl>
 </div>
 <!-- _______________________________________________________________________ -->
@@ -131,6 +174,17 @@ href="http://www.program-transformation.org/Transform/BURG">BURG</a> tool.</dd>
   </dl>
 </div>
 
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"><a name="P">- O -</a></div>
+<div class="doc_text">
+  <dl>
+    <dt><a name="Object_Pointer"><b>Object Pointer</b></a></dt>
+    <dd>A pointer to an object such that the garbage collector is able to trace
+    references contained within the object. This term is used in opposition to
+    <a href="#Derived_Pointer">derived pointer</a>.</dd>
+  </dl>
+</div>
+
 <!-- _______________________________________________________________________ -->
 <div class="doc_subsection"><a name="P">- P -</a></div>
 <div class="doc_text">
@@ -147,7 +201,12 @@ href="http://www.program-transformation.org/Transform/BURG">BURG</a> tool.</dd>
     <dt><a name="Reassociation"><b>Reassociation</b></a></dt> <dd>Rearranging
     associative expressions to promote better redundancy elimination and other
     optimization.  For example, changing (A+B-A) into (B+A-A), permitting it to
-    be optimized into (B+0) then (B).
+    be optimized into (B+0) then (B).</dd>
+    <dt><a name="Root"><b>Root</b></a></dt> <dd>In garbage collection, a
+    pointer variable lying outside of the <a href="#Heap">heap</a> from which
+    the collector begins its reachability analysis. In the context of code
+    generation, "root" almost always refers to a "stack root"&#151;a local or
+    temporary variable within an executing function.</dd>
   </dl>
 </div>
 
@@ -155,6 +214,16 @@ href="http://www.program-transformation.org/Transform/BURG">BURG</a> tool.</dd>
 <div class="doc_subsection"><a name="S">- S -</a></div>
 <div class="doc_text">
   <dl>
+    <dt><a name="SCC"><b>Safe Point</b></a></dt>
+    <dd>In garbage collection, it is necessary to identify <a href="#Root">stack
+    roots</a> so that reachability analysis may proceed. It may be infeasible to
+    provide this information for every instruction, so instead the information
+    may is calculated only at designated safe points. With a copying collector,
+    <a href="#Derived_Pointers">derived pointers</a> must not be retained across
+    safe points and <a href="#Object_Pointers">object pointers</a> must be
+    reloaded from stack roots.</dd>
+    <dt><a name="SDISel"><b>SDISel</b></a></dt>
+    <dd>Selection DAG Instruction Selection.</dd>
     <dt><a name="SCC"><b>SCC</b></a></dt>
     <dd>Strongly Connected Component</dd>
     <dt><a name="SCCP"><b>SCCP</b></a></dt>
@@ -163,6 +232,10 @@ href="http://www.program-transformation.org/Transform/BURG">BURG</a> tool.</dd>
     <dd>Scalar Replacement of Aggregates</dd>
     <dt><a name="SSA"><b>SSA</b></a></dt>
     <dd>Static Single Assignment</dd>
+    <dt><a name="Stack_Map"><b>Stack Map</b></a></dt>
+    <dd>In garbage collection, metadata emitted by the code generator which
+    identifies <a href="#Root">roots</a> within the stack frame of an executing
+    function.</dd>
   </dl>
 </div>
 <!-- *********************************************************************** -->

llvm/docs/LinkTimeOptimization.html

@@ -67,9 +67,9 @@ intermodular optimization, in the compiler tool chain. Its main goal is to let
 the developer take advantage of intermodular optimizations without making any 
 significant changes to the developer's makefiles or build system. This is 
 achieved through tight integration with the linker. In this model, the linker 
-treates LLVM bytecode files like native object files and allows mixing and 
+treates LLVM bitcode files like native object files and allows mixing and 
 matching among them. The linker uses <a href="#lto">LLVMlto</a>, a dynamically 
-loaded library, to handle LLVM bytecode files. This tight integration between 
+loaded library, to handle LLVM bitcode files. This tight integration between 
 the linker and LLVM optimizer helps to do optimizations that are not possible 
 in other models. The linker input allows the optimizer to avoid relying on 
 conservative escape analysis.
@@ -85,9 +85,9 @@ conservative escape analysis.
   <p>The following example illustrates the advantages of LTO's integrated
   approach and clean interface. This example requires a system linker which
   supports LTO through the interface described in this document.  Here,
-  llvm-gcc4 transparently invokes system linker. </p>
+  llvm-gcc transparently invokes system linker. </p>
   <ul>
-    <li> Input source file <tt>a.c</tt> is compiled into LLVM byte code form.
+    <li> Input source file <tt>a.c</tt> is compiled into LLVM bitcode form.
     <li> Input source file <tt>main.c</tt> is compiled into native object code.
   </ul>
 <div class="doc_code"><pre>
@@ -131,12 +131,12 @@ int main() {
 }
 
 --- command lines ---
-$ llvm-gcc4 --emit-llvm -c a.c -o a.o  # &lt;-- a.o is LLVM bytecode file
-$ llvm-gcc4 -c main.c -o main.o # &lt;-- main.o is native object file
-$ llvm-gcc4 a.o main.o -o main # &lt;-- standard link command without any modifications
+$ llvm-gcc --emit-llvm -c a.c -o a.o  # &lt;-- a.o is LLVM bitcode file
+$ llvm-gcc -c main.c -o main.o # &lt;-- main.o is native object file
+$ llvm-gcc a.o main.o -o main # &lt;-- standard link command without any modifications
 </pre></div>
   <p>In this example, the linker recognizes that <tt>foo2()</tt> is an 
-  externally visible symbol defined in LLVM byte code file. This information 
+  externally visible symbol defined in LLVM bitcode file. This information 
   is collected using <a href="#readllvmobjectfile"> readLLVMObjectFile()</a>. 
   Based on this information, the linker completes its usual symbol resolution 
   pass and finds that <tt>foo2()</tt> is not used anywhere. This information 
@@ -202,15 +202,15 @@ $ llvm-gcc4 a.o main.o -o main # &lt;-- standard link command without any modifi
 
 <!-- ======================================================================= -->
 <div class="doc_subsection">
-  <a name="phase1">Phase 1 : Read LLVM Bytecode Files</a>
+  <a name="phase1">Phase 1 : Read LLVM Bitcode Files</a>
 </div>
 
 <div class="doc_text">
   <p>The linker first reads all object files in natural order and collects 
-  symbol information. This includes native object files as well as LLVM byte 
-  code files.  In this phase, the linker uses 
+  symbol information. This includes native object files as well as LLVM bitcode 
+  files.  In this phase, the linker uses 
   <a href="#readllvmobjectfile"> readLLVMObjectFile() </a>  to collect symbol
-  information from each LLVM bytecode files and updates its internal global 
+  information from each LLVM bitcode files and updates its internal global 
   symbol table accordingly. The intent of this interface is to avoid overhead 
   in the non LLVM case, where all input object files are native object files, 
   by putting this code in the error path of the linker. When the linker sees 
@@ -228,7 +228,7 @@ $ llvm-gcc4 a.o main.o -o main # &lt;-- standard link command without any modifi
   <p>In this stage, the linker resolves symbols using global symbol table 
   information to report undefined symbol errors, read archive members, resolve 
   weak symbols, etc. The linker is able to do this seamlessly even though it 
-  does not know the exact content of input LLVM bytecode files because it uses 
+  does not know the exact content of input LLVM bitcode files because it uses 
   symbol information provided by 
   <a href="#readllvmobjectfile">readLLVMObjectFile()</a>.  If dead code 
   stripping is enabled then the linker collects the list of live symbols.
@@ -237,12 +237,12 @@ $ llvm-gcc4 a.o main.o -o main # &lt;-- standard link command without any modifi
 
 <!-- ======================================================================= -->
 <div class="doc_subsection">
-  <a name="phase3">Phase 3 : Optimize Bytecode Files</a>
+  <a name="phase3">Phase 3 : Optimize Bitcode Files</a>
 </div>
 <div class="doc_text">
   <p>After symbol resolution, the linker updates symbol information supplied 
-  by LLVM bytecode files appropriately. For example, whether certain LLVM 
-  bytecode supplied symbols are used or not. In the example above, the linker 
+  by LLVM bitcode files appropriately. For example, whether certain LLVM 
+  bitcode supplied symbols are used or not. In the example above, the linker 
   reports that <tt>foo2()</tt> is not used anywhere in the program, including 
   native <tt>.o</tt> files. This information is used by the LLVM interprocedural
   optimizer. The linker uses <a href="#optimizemodules">optimizeModules()</a> 
@@ -260,12 +260,12 @@ $ llvm-gcc4 a.o main.o -o main # &lt;-- standard link command without any modifi
   <p>In this phase, the linker reads optimized a native object file and 
   updates the internal global symbol table to reflect any changes. The linker 
   also collects information about any changes in use of external symbols by 
-  LLVM bytecode files. In the examle above, the linker notes that 
+  LLVM bitcode files. In the examle above, the linker notes that 
   <tt>foo4()</tt> is not used any more. If dead code stripping is enabled then 
   the linker refreshes the live symbol information appropriately and performs 
   dead code stripping.</p>
   <p>After this phase, the linker continues linking as if it never saw LLVM 
-  bytecode files.</p>
+  bitcode files.</p>
 </div>
 
 <!-- *********************************************************************** -->
@@ -288,10 +288,10 @@ $ llvm-gcc4 a.o main.o -o main # &lt;-- standard link command without any modifi
 
 <div class="doc_text">
   <p>The <tt>LLVMSymbol</tt> class is used to describe the externally visible 
-  functions and global variables, defined in LLVM bytecode files, to the linker.
+  functions and global variables, defined in LLVM bitcode files, to the linker.
   This includes symbol visibility information. This information is used by 
   the linker to do symbol resolution. For example: function <tt>foo2()</tt> is 
-  defined inside an LLVM bytecode module and it is an externally visible symbol.
+  defined inside an LLVM bitcode module and it is an externally visible symbol.
   This helps the linker connect the use of <tt>foo2()</tt> in native object 
   files with a future definition of the symbol <tt>foo2()</tt>. The linker 
   will see the actual definition of <tt>foo2()</tt> when it receives the 
@@ -310,12 +310,12 @@ $ llvm-gcc4 a.o main.o -o main # &lt;-- standard link command without any modifi
 
 <div class="doc_text">
   <p>The <tt>readLLVMObjectFile()</tt> function is used by the linker to read 
-  LLVM bytecode files and collect LLVMSymbol information. This routine also
-  supplies a list of externally defined symbols that are used by LLVM bytecode
+  LLVM bitcode files and collect LLVMSymbol information. This routine also
+  supplies a list of externally defined symbols that are used by LLVM bitcode
   files. The linker uses this symbol information to do symbol resolution. 
-  Internally, <a href="#lto">LLVMlto</a> maintains LLVM bytecode modules in 
+  Internally, <a href="#lto">LLVMlto</a> maintains LLVM bitcode modules in 
   memory. This function also provides a list of external references used by 
-  bytecode files.</p>
+  bitcode files.</p>
 </div>
 
 <!-- ======================================================================= -->
@@ -325,7 +325,7 @@ $ llvm-gcc4 a.o main.o -o main # &lt;-- standard link command without any modifi
 
 <div class="doc_text">
   <p>The linker invokes <tt>optimizeModules</tt> to optimize already read 
-  LLVM bytecode files by applying LLVM intermodular optimization techniques. 
+  LLVM bitcode files by applying LLVM intermodular optimization techniques. 
   This function runs the LLVM intermodular optimizer and generates native 
   object code as <tt>.o</tt> files at the name and location provided by the 
   linker.</p>
@@ -338,7 +338,7 @@ $ llvm-gcc4 a.o main.o -o main # &lt;-- standard link command without any modifi
 
 <div class="doc_text">
   <p>The linker may use <tt>getTargetTriple()</tt> to query target architecture
-  while validating LLVM bytecode file.</p>
+  while validating LLVM bitcode file.</p>
 </div>
 
 <!-- ======================================================================= -->
@@ -347,7 +347,7 @@ $ llvm-gcc4 a.o main.o -o main # &lt;-- standard link command without any modifi
 </div>
 
 <div class="doc_text">
-  <p>Internally, <a href="#lto">LLVMlto</a> maintains LLVM bytecode modules in 
+  <p>Internally, <a href="#lto">LLVMlto</a> maintains LLVM bitcode modules in 
   memory. The linker may use <tt>removeModule()</tt> method to remove desired
   modules from memory. </p>
 </div>

llvm/docs/Makefile

@@ -2,8 +2,8 @@
 # 
 #                     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 distributed under the University of Illinois Open Source
+# License. See LICENSE.TXT for details.
 # 
 ##===----------------------------------------------------------------------===##
 
@@ -14,15 +14,14 @@ ifdef BUILD_FOR_WEBSITE
 PROJ_OBJ_DIR = .
 DOXYGEN = doxygen
 # Extract version number from the AC_INT line in configure.ac
-# AC_INIT([[llvm]],[[2.0cvs]],[llvmbugs@cs.uiuc.edu])
-PACKAGE_VERSION = $(shell grep AC_INIT ../autoconf/configure.ac | sed -e 's/[^,]*,[[][[]//' -e 's/]],.*//')
-$(warning VERSION=$(VERSION))
+# AC_INIT([[llvm]],[[2.1svn]],[llvmbugs@cs.uiuc.edu])
+PACKAGE_VERSION = $(shell grep AC_INIT ../autoconf/configure.ac | sed -e 's/^[^0-9]*\([0-9_.a-zA-Z-]*\).*/\1/' )
 
 $(PROJ_OBJ_DIR)/doxygen.cfg: doxygen.cfg.in
 	cat $< | sed \
 	  -e 's/@abs_top_srcdir@/../g' \
 	  -e 's/@DOT@/dot/g' \
-	  -e 's/@PACKAGE_VERSION@/$(PACKAGE_VERSION)/g' \
+	  -e 's/@PACKAGE_VERSION@/$(PACKAGE_VERSION)/' \
 	  -e 's/@abs_top_builddir@/../g' > $@
 endif
 

llvm/docs/MakefileGuide.html

@@ -30,7 +30,7 @@
     <ol>
       <li><a href="#libraries">Libraries</a>
         <ol>
-	  <li><a href="#BCModules">Bytecode Modules</a></li>
+	  <li><a href="#BCModules">Bitcode Modules</a></li>
 	  <li><a href="#LoadableModules">Loadable Modules</a></li>
 	</ol>
       </li>
@@ -260,11 +260,11 @@
 </div>
 
 <!-- ======================================================================= -->
-<div class="doc_subsubsection"><a name="BCModules">Bytecode Modules</a></div>
+<div class="doc_subsubsection"><a name="BCModules">Bitcode Modules</a></div>
 <div class="doc_text">
-  <p>In some situations, it is desireable to build a single bytecode module from
-  a variety of sources, instead of an archive, shared library, or bytecode 
-  library. Bytecode modules can be specified in addition to any of the other
+  <p>In some situations, it is desireable to build a single bitcode module from
+  a variety of sources, instead of an archive, shared library, or bitcode 
+  library. Bitcode modules can be specified in addition to any of the other
   types of libraries by defining the <a href="#MODULE_NAME">MODULE_NAME</a>
   variable. For example:</p>
   <pre><tt>
@@ -273,9 +273,9 @@
       MODULE_NAME = mymod
   </tt></pre>
   <p>will build a module named <tt>mymod.bc</tt> from the sources in the
-  directory. This module will be an aggregation of all the bytecode modules 
-  derived from the sources. The example will also build a bytecode archive 
-  containing a bytecode module for each compiled source file. The difference is
+  directory. This module will be an aggregation of all the bitcode modules 
+  derived from the sources. The example will also build a bitcode archive 
+  containing a bitcode module for each compiled source file. The difference is
   subtle, but important depending on how the module or library is to be linked.
   </p>
 </div>
@@ -626,7 +626,7 @@
     files. These sources will be built before any other target processing to 
     ensure they are present.</dd>
     <dt><a name="BYTECODE_LIBRARY"><tt>BYTECODE_LIBRARY</tt></a></dt>
-    <dd>If set to any value, causes a bytecode library (.bc) to be built.</dd>
+    <dd>If set to any value, causes a bitcode library (.bc) to be built.</dd>
     <dt><a name="CONFIG_FILES"><tt>CONFIG_FILES</tt></a></dt>
     <dd>Specifies a set of configuration files to be installed.</dd>
     <dt><a name="DIRS"><tt>DIRS</tt></a></dt>
@@ -709,9 +709,9 @@
     setting this variable without also setting <tt>SHARED_LIBRARY</tt> will have
     no effect.</dd>
     <dt><a name="MODULE_NAME"><tt>MODULE_NAME</tt></a></dt>
-    <dd>Specifies the name of a bytecode module to be created. A bytecode 
+    <dd>Specifies the name of a bitcode module to be created. A bitcode 
     module can be specified in conjunction with other kinds of library builds 
-    or by itself. It constructs from the sources a single linked bytecode 
+    or by itself. It constructs from the sources a single linked bitcode 
     file.</dd>
     <dt><a name="NO_INSTALL"><tt>NO_INSTALL</tt></a></dt>
     <dd>Specifies that the build products of the directory should not be
@@ -808,11 +808,6 @@
     isn't one.</dd>
     <dt><a name="ECHO"><tt>ECHO</tt></a><small>(configured)</small></dt>
     <dd>Specifies the path to the <tt>echo</tt> tool for printing output.</dd>
-    <dt><a name="ETAGS"><tt>ETAGS</tt></a><small>(configured)</small></dt>
-    <dd>Specifies the path to the <tt>etags</tt> tool.</dd>
-    <dt><a name="ETAGSFLAGS"><tt>ETAGSFLAGS</tt></a><small>(configured)</small>
-    </dt>
-    <dd>Provides flags to be passed to the <tt>etags</tt> tool.</dd>
     <dt><a name="EXEEXT"><tt>EXEEXT</tt></a><small>(configured)</small></dt>
     <dd>Provides the extension to be used on executables built by the makefiles.
     The value may be empty on platforms that do not use file extensions for
@@ -835,7 +830,7 @@
     <dt><a name="LLVMGXX"><tt>LLVMGXX</tt></a><small>(defaulted)</small></dt>
     <dd>Specifies the path to the LLVM version of the GCC C++ Compiler</dd>
     <dt><a name="LLVMLD"><tt>LLVMLD</tt></a><small>(defaulted)</small></dt>
-    <dd>Specifies the path to the LLVM bytecode linker tool</dd>
+    <dd>Specifies the path to the LLVM bitcode linker tool</dd>
     <dt><a name="LLVM_OBJ_ROOT"><tt>LLVM_OBJ_ROOT</tt></a><small>(configured)
     </small></dt>
     <dd>Specifies the top directory into which the output of the build is
@@ -884,8 +879,8 @@
     <dt><a name="BuildMode"><tt>BuildMode</tt></a></dt>
     <dd>The name of the type of build being performed: Debug, Release, or 
     Profile</dd>
-    <dt><a name="bytecode_libdir"><tt>bytecode_libdir</tt></a></dt>
-    <dd>The directory into which bytecode libraries will ultimately be 
+    <dt><a name="bitcode_libdir"><tt>bytecode_libdir</tt></a></dt>
+    <dd>The directory into which bitcode libraries will ultimately be 
     installed.  This value is derived from the <tt>--prefix</tt> option given to
     <tt>configure</tt>.</dd>
     <dt><a name="ConfigureScriptFLAGS"><tt>ConfigureScriptFLAGS</tt></a></dt>
@@ -965,7 +960,7 @@
     CXX.Flags
     DependFiles
     DestArchiveLib
-    DestBytecodeLib
+    DestBitcodeLib
     DestModule
     DestRelinkedLib
     DestSharedLib

llvm/docs/ProgrammersManual.html

@@ -62,6 +62,7 @@ option</a></li>
       <li><a href="#dss_sortedvectorset">A sorted 'vector'</a></li>
       <li><a href="#dss_smallset">"llvm/ADT/SmallSet.h"</a></li>
       <li><a href="#dss_smallptrset">"llvm/ADT/SmallPtrSet.h"</a></li>
+      <li><a href="#dss_denseset">"llvm/ADT/DenseSet.h"</a></li>
       <li><a href="#dss_FoldingSet">"llvm/ADT/FoldingSet.h"</a></li>
       <li><a href="#dss_set">&lt;set&gt;</a></li>
       <li><a href="#dss_setvector">"llvm/ADT/SetVector.h"</a></li>
@@ -77,6 +78,11 @@ option</a></li>
       <li><a href="#dss_map">&lt;map&gt;</a></li>
       <li><a href="#dss_othermap">Other Map-Like Container Options</a></li>
     </ul></li>
+    <li><a href="#ds_bit">BitVector-like containers</a>
+    <ul>
+      <li><a href="#dss_bitvector">A dense bitvector</a></li>
+      <li><a href="#dss_sparsebitvector">A sparse bitvector</a></li>
+    </ul></li>
   </ul>
   </li>
   <li><a href="#common">Helpful Hints for Common Operations</a>
@@ -97,6 +103,8 @@ complex example</a> </li>
 the same way</a> </li>
           <li><a href="#iterate_chains">Iterating over def-use &amp;
 use-def chains</a> </li>
+          <li><a href="#iterate_preds">Iterating over predecessors &amp;
+successors of blocks</a></li>
         </ul>
       </li>
       <li><a href="#simplechanges">Making simple changes</a>
@@ -106,6 +114,7 @@ use-def chains</a> </li>
           <li><a href="#schanges_deleting">Deleting 		 <tt>Instruction</tt>s</a> </li>
           <li><a href="#schanges_replacing">Replacing an 		 <tt>Instruction</tt>
 with another <tt>Value</tt></a> </li>
+          <li><a href="#schanges_deletingGV">Deleting <tt>GlobalVariable</tt>s</a> </li>  
         </ul>
       </li>
 <!--
@@ -580,9 +589,9 @@ suite, it gives a report that looks like this:</p>
 
 <div class="doc_code">
 <pre>
-   7646 bytecodewriter  - Number of normal instructions
-    725 bytecodewriter  - Number of oversized instructions
- 129996 bytecodewriter  - Number of bytecode bytes written
+   7646 bitcodewriter   - Number of normal instructions
+    725 bitcodewriter   - Number of oversized instructions
+ 129996 bitcodewriter   - Number of bitcode bytes written
    2817 raise           - Number of insts DCEd or constprop'd
    3213 raise           - Number of cast-of-self removed
    5046 raise           - Number of expression trees converted
@@ -704,6 +713,11 @@ access the container.  Based on that, you should use:</p>
     iteration, but do not support efficient look-up based on a key.
 </li>
 
+<li>a <a href="#ds_bit">bit</a> container provides an efficient way to store and
+    perform set operations on sets of numeric id's, while automatically
+    eliminating duplicates.  Bit containers require a maximum of 1 bit for each
+    identifier you want to store.
+</li>
 </ul>
 
 <p>
@@ -975,6 +989,25 @@ visited in sorted order.</p>
 
 </div>
 
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+  <a name="dss_denseset">"llvm/ADT/DenseSet.h"</a>
+</div>
+
+<div class="doc_text">
+
+<p>
+DenseSet is a simple quadratically probed hash table.  It excels at supporting
+small values: it uses a single allocation to hold all of the pairs that
+are currently inserted in the set.  DenseSet is a great way to unique small
+values that are not simple pointers (use <a 
+href="#dss_smallptrset">SmallPtrSet</a> for pointers).  Note that DenseSet has
+the same requirements for the value type that <a 
+href="#dss_densemap">DenseMap</a> has.
+</p>
+
+</div>
+
 <!-- _______________________________________________________________________ -->
 <div class="doc_subsubsection">
   <a name="dss_FoldingSet">"llvm/ADT/FoldingSet.h"</a>
@@ -1224,7 +1257,7 @@ iterators in a densemap are invalidated whenever an insertion occurs, unlike
 map.  Also, because DenseMap allocates space for a large number of key/value
 pairs (it starts with 64 by default), it will waste a lot of space if your keys
 or values are large.  Finally, you must implement a partial specialization of
-DenseMapKeyInfo for the key that you want, if it isn't already supported.  This
+DenseMapInfo for the key that you want, if it isn't already supported.  This
 is required to tell DenseMap about two special marker values (which can never be
 inserted into the map) that it needs internally.</p>
 
@@ -1275,6 +1308,52 @@ expensive.  Element iteration does not visit elements in a useful order.</p>
 
 </div>
 
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+  <a name="ds_bit">Bit storage containers (BitVector, SparseBitVector)</a>
+</div>
+
+<div class="doc_text">
+<p>Unlike the other containers, there are only two bit storage containers, and 
+choosing when to use each is relatively straightforward.</p>
+
+<p>One additional option is 
+<tt>std::vector&lt;bool&gt;</tt>: we discourage its use for two reasons 1) the
+implementation in many common compilers (e.g. commonly available versions of 
+GCC) is extremely inefficient and 2) the C++ standards committee is likely to
+deprecate this container and/or change it significantly somehow.  In any case,
+please don't use it.</p>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+  <a name="dss_bitvector">BitVector</a>
+</div>
+
+<div class="doc_text">
+<p> The BitVector container provides a fixed size set of bits for manipulation.
+It supports individual bit setting/testing, as well as set operations.  The set
+operations take time O(size of bitvector), but operations are performed one word
+at a time, instead of one bit at a time.  This makes the BitVector very fast for
+set operations compared to other containers.  Use the BitVector when you expect
+the number of set bits to be high (IE a dense set).
+</p>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+  <a name="dss_sparsebitvector">SparseBitVector</a>
+</div>
+
+<div class="doc_text">
+<p> The SparseBitVector container is much like BitVector, with one major
+difference: Only the bits that are set, are stored.  This makes the
+SparseBitVector much more space efficient than BitVector when the set is sparse,
+as well as making set operations O(number of set bits) instead of O(size of
+universe).  The downside to the SparseBitVector is that setting and testing of random bits is O(N), and on large SparseBitVectors, this can be slower than BitVector. In our implementation, setting or testing bits in sorted order
+(either forwards or reverse) is O(1) worst case.  Testing and setting bits within 128 bits (depends on size) of the current bit is also O(1).  As a general statement, testing/setting bits in a SparseBitVector is O(distance away from last set bit).
+</p>
+</div>
 
 <!-- *********************************************************************** -->
 <div class="doc_section">
@@ -1459,7 +1538,7 @@ the last line of the last example,</p>
 
 <div class="doc_code">
 <pre>
-Instruction* pinst = &amp;*i;
+Instruction *pinst = &amp;*i;
 </pre>
 </div>
 
@@ -1467,7 +1546,7 @@ Instruction* pinst = &amp;*i;
 
 <div class="doc_code">
 <pre>
-Instruction* pinst = i;
+Instruction *pinst = i;
 </pre>
 </div>
 
@@ -1535,8 +1614,7 @@ class OurFunctionPass : public FunctionPass {
  href="#CallInst">CallInst</a>&gt;(&amp;*i)) {
             // <i>We know we've encountered a call instruction, so we</i>
             // <i>need to determine if it's a call to the</i>
-            // <i>function pointed to by m_func or not</i>
-
+            // <i>function pointed to by m_func or not.</i>
             if (callInst-&gt;getCalledFunction() == targetFunc)
               ++callCounter;
           }
@@ -1545,7 +1623,7 @@ class OurFunctionPass : public FunctionPass {
     }
 
   private:
-    unsigned  callCounter;
+    unsigned callCounter;
 };
 </pre>
 </div>
@@ -1597,7 +1675,7 @@ of <tt>F</tt>:</p>
 
 <div class="doc_code">
 <pre>
-Function* F = ...;
+Function *F = ...;
 
 for (Value::use_iterator i = F-&gt;use_begin(), e = F-&gt;use_end(); i != e; ++i)
   if (Instruction *Inst = dyn_cast&lt;Instruction&gt;(*i)) {
@@ -1617,10 +1695,10 @@ the particular <tt>Instruction</tt>):</p>
 
 <div class="doc_code">
 <pre>
-Instruction* pi = ...;
+Instruction *pi = ...;
 
 for (User::op_iterator i = pi-&gt;op_begin(), e = pi-&gt;op_end(); i != e; ++i) {
-  Value* v = *i;
+  Value *v = *i;
   // <i>...</i>
 }
 </pre>
@@ -1633,6 +1711,36 @@ for (User::op_iterator i = pi-&gt;op_begin(), e = pi-&gt;op_end(); i != e; ++i)
 
 </div>
 
+<!--_______________________________________________________________________-->
+<div class="doc_subsubsection">
+  <a name="iterate_preds">Iterating over predecessors &amp;
+successors of blocks</a>
+</div>
+
+<div class="doc_text">
+
+<p>Iterating over the predecessors and successors of a block is quite easy
+with the routines defined in <tt>"llvm/Support/CFG.h"</tt>.  Just use code like
+this to iterate over all predecessors of BB:</p>
+
+<div class="doc_code">
+<pre>
+#include "llvm/Support/CFG.h"
+BasicBlock *BB = ...;
+
+for (pred_iterator PI = pred_begin(BB), E = pred_end(BB); PI != E; ++PI) {
+  BasicBlock *Pred = *PI;
+  // <i>...</i>
+}
+</pre>
+</div>
+
+<p>Similarly, to iterate over successors use
+succ_iterator/succ_begin/succ_end.</p>
+
+</div>
+
+
 <!-- ======================================================================= -->
 <div class="doc_subsection">
   <a name="simplechanges">Making simple changes</a>
@@ -1665,7 +1773,7 @@ parameters. For example, an <tt>AllocaInst</tt> only <i>requires</i> a
 
 <div class="doc_code">
 <pre>
-AllocaInst* ai = new AllocaInst(Type::IntTy);
+AllocaInst* ai = new AllocaInst(Type::Int32Ty);
 </pre>
 </div>
 
@@ -1693,7 +1801,7 @@ used as some kind of index by some other code.  To accomplish this, I place an
 
 <div class="doc_code">
 <pre>
-AllocaInst* pa = new AllocaInst(Type::IntTy, 0, "indexLoc");
+AllocaInst* pa = new AllocaInst(Type::Int32Ty, 0, "indexLoc");
 </pre>
 </div>
 
@@ -1845,7 +1953,7 @@ AllocaInst* instToReplace = ...;
 BasicBlock::iterator ii(instToReplace);
 
 ReplaceInstWithValue(instToReplace-&gt;getParent()-&gt;getInstList(), ii,
-                     Constant::getNullValue(PointerType::get(Type::IntTy)));
+                     Constant::getNullValue(PointerType::get(Type::Int32Ty)));
 </pre></div></li>
 
   <li><tt>ReplaceInstWithInst</tt> 
@@ -1860,7 +1968,7 @@ AllocaInst* instToReplace = ...;
 BasicBlock::iterator ii(instToReplace);
 
 ReplaceInstWithInst(instToReplace-&gt;getParent()-&gt;getInstList(), ii,
-                    new AllocaInst(Type::IntTy, 0, "ptrToReplacedInt"));
+                    new AllocaInst(Type::Int32Ty, 0, "ptrToReplacedInt"));
 </pre></div></li>
 </ul>
 
@@ -1878,6 +1986,28 @@ ReplaceInstWithValue, ReplaceInstWithInst -->
 
 </div>
 
+<!--_______________________________________________________________________-->
+<div class="doc_subsubsection">
+  <a name="schanges_deletingGV">Deleting <tt>GlobalVariable</tt>s</a>
+</div>
+
+<div class="doc_text">
+
+<p>Deleting a global variable from a module is just as easy as deleting an 
+Instruction. First, you must have a pointer to the global variable that you wish
+ to delete.  You use this pointer to erase it from its parent, the module.
+ For example:</p>
+
+<div class="doc_code">
+<pre>
+<a href="#GlobalVariable">GlobalVariable</a> *GV = .. ;
+
+GV-&gt;eraseFromParent();
+</pre>
+</div>
+
+</div>
+
 <!-- *********************************************************************** -->
 <div class="doc_section">
   <a name="advanced">Advanced Topics</a>
@@ -1912,7 +2042,7 @@ recursive types and late resolution of opaque types makes the situation very
 difficult to handle.  Fortunately, for the most part, our implementation makes
 most clients able to be completely unaware of the nasty internal details.  The
 primary case where clients are exposed to the inner workings of it are when
-building a recursive type.  In addition to this case, the LLVM bytecode reader,
+building a recursive type.  In addition to this case, the LLVM bitcode reader,
 assembly parser, and linker also have to be aware of the inner workings of this
 system.
 </p>
@@ -1957,7 +2087,7 @@ To build this, use the following LLVM APIs:
 <a href="#PATypeHolder">PATypeHolder</a> StructTy = OpaqueType::get();
 std::vector&lt;const Type*&gt; Elts;
 Elts.push_back(PointerType::get(StructTy));
-Elts.push_back(Type::IntTy);
+Elts.push_back(Type::Int32Ty);
 StructType *NewSTy = StructType::get(Elts);
 
 // <i>At this point, NewSTy = "{ opaque*, i32 }". Tell VMCore that</i>

llvm/docs/Projects.html

@@ -88,10 +88,10 @@ choosing.  You can place it anywhere you like.  Rename the directory to match
 the name of your project.</li>
 
 <li>
-If you downloaded LLVM using CVS, remove all the directories named CVS (and all
-the files therein) from your project's new source tree.  This will keep CVS
-from thinking that your project is inside <tt>llvm/projects/sample</tt>.
-</li>
+If you downloaded LLVM using Subversion, remove all the directories named .svn 
+(and all the files therein) from your project's new source tree.  This will 
+keep Subversion from thinking that your project is inside 
+<tt>llvm/trunk/projects/sample</tt>.</li>
 
 <li>Add your source code and Makefiles to your source tree.</li>
 

llvm/docs/ReleaseNotes.html

@@ -4,11 +4,11 @@
 <head>
   <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
   <link rel="stylesheet" href="llvm.css" type="text/css">
-  <title>LLVM 1.9 Release Notes</title>
+  <title>LLVM 2.2 Release Notes</title>
 </head>
 <body>
 
-<div class="doc_title">LLVM 1.9 Release Notes</div>
+<div class="doc_title">LLVM 2.2 Release Notes</div>
  
 <ol>
   <li><a href="#intro">Introduction</a></li>
@@ -23,6 +23,7 @@
   <p>Written by the <a href="http://llvm.org">LLVM Team</a><p>
 </div>
 
+
 <!-- *********************************************************************** -->
 <div class="doc_section">
   <a name="intro">Introduction</a>
@@ -32,13 +33,10 @@
 <div class="doc_text">
 
 <p>This document contains the release notes for the LLVM compiler
-infrastructure, release 1.9.  Here we describe the status of LLVM, including any
-known problems and major improvements from the previous release.  The most
-up-to-date version of this document (corresponding to LLVM CVS) can be found
-on the <a
-href="http://llvm.org/releases/">LLVM releases 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>
+infrastructure, release 2.2.  Here we describe the status of LLVM, including
+major improvements from the previous release and any known problems.  All LLVM
+releases may be downloaded from the <a href="http://llvm.org/releases/">LLVM
+releases web site</a>.</p>
 
 <p>For more information about LLVM, including information about the latest
 release, please check out the <a href="http://llvm.org/">main LLVM
@@ -46,10 +44,10 @@ web site</a>.  If you have questions or comments, the <a
 href="http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVM developer's mailing
 list</a> is a good place to send them.</p>
 
-<p>Note that if you are reading this file from CVS or the main LLVM web page,
-this document applies to the <i>next</i> release, not the current one.  To see
-the release notes for the current or previous releases, see the <a
-href="http://llvm.org/releases/">releases page</a>.</p>
+<p>Note that if you are reading this file from a Subversion checkout or the 
+main LLVM web page, this document applies to the <i>next</i> release, not the
+current one.  To see the release notes for a specific releases, please see the
+<a href="http://llvm.org/releases/">releases page</a>.</p>
 
 </div>
 
@@ -61,171 +59,283 @@ href="http://llvm.org/releases/">releases page</a>.</p>
 
 <div class="doc_text">
 
-<p>This is the tenth public release of the LLVM Compiler Infrastructure. This
-release incorporates a large number of enhancements, new features, and bug
-fixes.  We recommend that all users of previous LLVM versions upgrade.
-</p>
+<p>This is the thirteenth public release of the LLVM Compiler Infrastructure. 
+It includes many features and refinements from LLVM 2.1.</p>
+
+</div>
+
+<!-- Unfinished features in 2.2:
+  Index Set Splitting not enabled by default
+  Machine LICM
+  Machine Sinking
+  LegalizeDAGTypes
+ -->
+
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="deprecation">Deprecated features in LLVM 2.2</a>
+</div>
+
+<div class="doc_text">
+
+<p>This is the last LLVM release to support llvm-gcc 4.0, llvm-upgrade, and
+llvmc in its current form.  llvm-gcc 4.0 has been replaced with llvm-gcc 4.2.
+llvm-upgrade is useful for upgrading llvm 1.9 files to llvm 2.x syntax, but you
+can always use an old release to do this.  llvmc is currently mostly useless in
+llvm 2.2, and will be redesigned or removed in llvm 2.3.</p>
 
 </div>
 
 <!--=========================================================================-->
 <div class="doc_subsection">
-<a name="newfeatures">New Features in LLVM 1.9</a>
+<a name="frontends">llvm-gcc 4.0, llvm-gcc 4.2, and clang</a>
 </div>
 
-<!--_________________________________________________________________________-->
-<div class="doc_subsubsection"><a name="x86-64">New X86-64 Backend</a></div>
 <div class="doc_text">
-<p>LLVM 1.9 now fully supports the x86-64 instruction set on Mac OS/X, and
-supports it on Linux (and other operating systems) when compiling in -static
-mode. LLVM includes JIT support for X86-64, and supports both Intel EMT-64T
-and AMD-64 architectures.  The X86-64 instruction set permits addressing a
-64-bit addressing space and provides the compiler with twice the
-number of integer registers to use.</p>
+
+<p>LLVM 2.2 fully supports both the llvm-gcc 4.0 and llvm-gcc 4.2 front-ends (in
+LLVM 2.1, llvm-gcc 4.2 was beta).  Since LLVM 2.1, the llvm-gcc 4.2 front-end
+has made leaps and bounds and is now at least as good as 4.0 in virtually every
+area, and is better in several areas (for example, exception handling
+correctness, support for Ada and Fortran, better ABI compatibility, etc).  We 
+strongly recommend that you
+migrate from llvm-gcc 4.0 to llvm-gcc 4.2 in this release cycle because
+<b>LLVM 2.2 is the last release that will support llvm-gcc 4.0</b>:  LLVM 2.3
+will only support the llvm-gcc 4.2 front-end.</p>
+
+<p>The <a href="http://clang.llvm.org/">clang project</a> is an effort to build
+a set of new 'llvm native' front-end technologies for the LLVM optimizer
+and code generator.  Currently, its C and Objective-C support is maturing 
+nicely, and it has advanced source-to-source analysis and transformation
+capabilities.  If you are interested in building source-level tools for C and
+Objective-C (and eventually C++), you should take a look.  However, note that
+clang is not an official part of the LLVM 2.2 release.  If you are interested in
+this project, please see its <a href="http://clang.llvm.org/">web site</a>.</p>
+
 </div>
 
-<!--_________________________________________________________________________-->
-<div class="doc_subsubsection"><a name="lto">Link-Time Optimization integration
-with native linkers</a></div>
-<div class="doc_text">
-<p>LLVM now includes <a href="LinkTimeOptimization.html">liblto</a> which can
-be used to integrate LLVM Link-Time Optimization support into a native linker.
-This allows LLVM .bc to transparently participate with linking an application,
-even when some .o files are in LLVM form and some are not.</p>
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="majorfeatures">Major New Features</a>
 </div>
 
-<!--_________________________________________________________________________-->
-<div class="doc_subsubsection"><a name="dwarf">DWARF debugging 
-support for Linux, Cygwin and MinGW on X86</a></div>
 <div class="doc_text">
-<p>llvm-gcc4 now supports generating debugging info for Linux, Cygwin and MinGW.
-This extends the PPC/Darwin and X86/Darwin debugging support available in the
-1.8 release. DWARF is a standard debugging format used on many platforms.</p>
-</div>
 
-<!--_________________________________________________________________________-->
-<div class="doc_subsubsection"><a name="optimizer">Optimizer
-Improvements</a></div>
-<div class="doc_text">
-<p>The mid-level optimizer is now faster and produces better code in many cases.
-  Significant changes include:</p>
+<p>LLVM 2.2 includes several major new capabilities:</p>
 
 <ul>
-<li>LLVM includes a new 'predicate simplifier' pass, which
-    currently performs dominator tree-based optimizations.</li>
-<li>The complete loop unroll pass now supports unrolling of
-     multiple basic block loops.</li>
-<li>The 'globalopt' pass can now perform the scalar replacement of
-    aggregates transformation on some heap allocations.</li>
-<li>The globalsmodref-aa alias analysis can now track 'indirect pointer
-     globals' more accurately.</li>
-<li>The instruction combiner can now perform element propagation  
-analysis of vector expressions, eliminating computation of vector elements
-that are not used.</li>
+<li>A research team led by Scott Michel in the Computer Systems Research
+Department at The Aerospace Corporation contributed the CellSPU backend, which
+generates code for the vector coprocessors on the Sony/Toshiba/IBM Cell BE
+processor. llvm-gcc 4.2 supports CellSPU as a 'configure' target and progress
+is being made so that libgcc.a compiles cleanly. Notable pieces still in
+development include full 64-bit integer and full double precision floating
+point support.</li>
+
+<li>Anton and Duncan significantly improved llvm-gcc 4.2 support for the GCC Ada
+(GNAT) and Fortran (gfortran) front-ends.  These front-ends should still be considered
+experimental however: see the <a href="#knownproblems">list of known problems</a>.
+The release binaries do not contain either front-end: they need to be built from
+source (the Ada front-end only builds on x86-32 linux).</li>
+
+<li>Dale contributed full support for long double on x86/x86-64 (where it is 80
+bits) and on Darwin PPC/PPC64 (where it is 128 bits).  In previous LLVM
+releases, llvm-gcc silently mapped long double to double.</li>
+
+<li>Gordon Henriksen rewrote most of the <a href="GarbageCollection.html"
+>Accurate Garbage Collection</a> code in the code generator, making the
+generated code more efficient and adding support for the OCaml garbage collector
+metadata format.</li>
+
+<li>Christopher Lamb contributed support for multiple address spaces in LLVM
+IR.  This is useful for supporting targets that have 'near' vs 'far' pointers,
+'RAM' vs 'ROM' pointers, or that have non-local memory that can be accessed with
+special instructions.</li>
+
+<li>LLVM now includes a new set of detailed <a 
+href="tutorial/index.html">tutorials</a>, which explain how to implement a
+language with LLVM and shows how to use several important APIs.</li>
+
+</ul>
+
+</div>
+
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="coreimprovements">LLVM Core Improvements</a>
+</div>
+
+<div class="doc_text">
+<p>New features include:
+</p>
+
+<ul>
+<li>Gordon contributed support for C and OCaml Bindings for the basic LLVM IR
+construction routines as well as several other auxiliary APIs.</li>
+
+<li>Anton added readnone/readonly attributes for modeling function side effects.
+Duncan hooked up GCC's pure/const attributes to them and enhanced mod/ref
+analysis to use them.</li>
+
+<li>Devang added LLVMFoldingBuilder, a version of LLVMBuilder that implicitly
+simplifies the code as it is constructed.</li>
+
+<li>Ted Kremenek added a framework for generic object serialization to bitcode
+files. This support is only used by clang right now for ASTs but is extensible
+and could be used for serializing arbitrary other data into bitcode files.</li>
+    
+<li>Duncan improved TargetData to distinguish between the size/alignment of a
+type in a register, in memory according to the platform ABI, and in memory when
+we have a choice.</li>
+
+<li>Reid moved parameter attributes off of FunctionType and onto functions
+and calls.  This makes it much easier to add attributes to a function in a
+transformation pass.</li>
+
+<li>Dan Gohman added support for vector sin, cos, and pow intrinsics.</li>
+
 </ul>
   
 </div>
 
-<!--_________________________________________________________________________-->
-<div class="doc_subsubsection"><a name="codegen">Code
-Generator Enhancements</a></div>
-
-<div class="doc_text">
-<p>
-The LLVM Target-Independent code generator now supports more target features and
-optimizes many cases more aggressively.  New features include:
-</p>
-
-<ul>
-<li>LLVM now includes a late branch folding pass which optimizes code
-    layout, performs several branch optzns, and deletes unreachable code.</li>
-<li>The code generator now support targets that have pre/post-increment
-    addressing modes.</li>
-<li>LLVM now supports dynamically-loadable register allocators and
-     schedulers.</li>
-<li>LLVM 1.9 includes several improvements to inline asm support,
-    including support for new constraints and modifiers.</li>
-<li>The register coalescer is now more aggressive than before,  
-     allowing it to eliminate more copies.</li>
-</ul>
-
-<p>In addition, the LLVM target description format has itself been extended in
- several ways:</p>
- 
-<ul>
-<li>tblgen now allows definition of '<a 
-     href="TableGenFundamentals.html#multiclass">multiclasses</a>' which can be
-     used to factor instruction patterns more aggressively in .td files.</li>
-<li>LLVM has a new TargetAsmInfo class which captures a variety of
-     information about the target assembly language format.</li>
-<li>.td files now support "<tt>${:foo}</tt>" syntax for encoding 
-     subtarget-specific assembler syntax into instruction descriptions.</li>
-</ul>
-
-<p>Further, several significant target-specific enhancements are included in
-LLVM 1.9:</p>
-
-<ul>
-<li>The LLVM ARM backend now supports more instructions
-    and the use of a frame pointer.  It is now possible to build  
-   libgcc and a simple cross compiler, but it is not considered "complete" yet.
-   </li>
-<li>LLVM supports the Win32 dllimport/dllexport linkage and
-     stdcall/fastcall calling conventions.</li>
-</ul>
-
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="codegen">Code Generator Improvements</a>
 </div>
 
-<!--_________________________________________________________________________-->
-<div class="doc_subsubsection"><a name="other">Other Improvements</a></div>
 <div class="doc_text">
-<p>This release includes many other improvements, including improvements to
-   the optimizers and code generators (improving the generated code) changes to
-   speed up the compiler in many ways (improving algorithms and fine tuning 
-   code), and changes to reduce the code size of the compiler itself.</p>
 
-<p>More specific changes include:</p>
+<p>We put a significant amount of work into the code generator infrastructure,
+which allows us to implement more aggressive algorithms and make it run
+faster:</p>
 
 <ul>
-<li>The llvm-test framework now supports SPEC2006.</li>
-<li>LLVM now includes a <a href="GetElementPtr.html">FAQ about the
-<tt>getelementptr</tt> instruction</a>.</li>
-<li>Bugpoint now supports a new "<tt>-find-bugs</tt>" mode.  This mode makes
-    bugpoint permute pass sequences to try to expose bugs due to pass
-    sequencing.</li>
-<li>The JIT now supports lazily streaming code from multiple modules at a
-     time, implicitly linking the code as it goes.</li>
+
+<li>Owen refactored the existing LLVM dominator and loop information code to
+allow it work on the machine code representation.  He contributed support for
+dominator and loop information on machine code and merged the code for forward
+and backward dominator computation.</li>
+
+<li>Dan added support for emitting debug information with .file and .loc
+directives on platforms that support it, instead of emitting large tables in the .s
+file.</li>
+
+<li>Evan extended the DAG scheduler to model physical register dependencies
+explicitly and have the BURR scheduler pick a correct schedule based on the
+dependencies.  This reduces our use of the 'flag' operand hack.</li>
+
+<li>Evan added initial support for register coalescing of subregister
+references.</li>
+
+<li>Rafael Espindola implemented initial support for a new 'byval' attribute,
+which allows more efficient by-value argument passing in the LLVM IR.  Evan 
+finished support for it and enabled it in the X86 (32- and 64-bit) and C
+backends.</li>
+
+<li>The LLVM TargetInstrInfo class can now answer queries about the mod/ref and
+side-effect behavior of MachineInstr's.  This information is inferred
+automatically by TableGen from .td files for all instructions with
+patterns.</li>
+
+<li>Evan implemented simple live interval splitting on basic block boundaries.
+This allows the register allocator to be more successful at keeping values in
+registers in some parts of a value's live range, even if they need to be spilled
+in some other block.</li>
+
+<li>The new MachineRegisterInfo.h class provides support for efficiently
+iterating over all defs/uses of a register, and this information is
+automatically kept up-to-date.  This support is similar to the  use_iterator in
+the LLVM IR level.</li>
+
+<li>The MachineInstr, MachineOperand and TargetInstrDesc classes are simpler,
+more consistent, and better documented.</li>
 </ul>
+
 </div>
 
 <!--=========================================================================-->
 <div class="doc_subsection">
-<a name="apichanges">Significant API Changes in LLVM 1.9</a>
+<a name="optimizer">Optimizer Improvements</a>
 </div>
 
 <div class="doc_text">
 
-<p>Several significant API changes have been made.  If you are maintaining
-out-of-tree code, please be aware that:</p>
+<p>In addition to a huge array of bug fixes and minor performance tweaks, the 
+LLVM 2.2 optimizers support a few major enhancements:</p>
 
 <ul>
-<li>The ConstantSInt and ConstantUInt classes have been merged into the
- ConstantInt class.</li>
-<li><p>As a step towards making LLVM's integer types signless, several new
-instructions have been added to LLVM. The <tt>Div</tt> instruction is now 
-<tt>UDiv</tt>, <tt>SDiv</tt>, and <tt>FDiv</tt>.  The <tt>Rem</tt> instruction
-is now <tt>URem</tt>, <tt>SRem</tt> and <tt>FRem</tt>. See the
-<a href="LangRef.html">Language Reference</a> for details on these new
-instructions.</p>
-<li><p><tt>ConstantBool::True</tt> and <tt>ConstantBool::False</tt> have been
-      renamed to <tt>ConstantBool::getTrue()</tt> and
-      <tt>ConstantBool::getFalse()</tt>.</p></li>
-<li>The 'analyze' tool has been merged into the 'opt' tool.</li>
+
+<li>Daniel Berlin and Curtis Dunham rewrote Andersen's alias analysis to be
+several orders of magnitude faster, and implemented Offline Variable
+Substitution and Lazy Cycle Detection.  Note that Andersen's is not enabled in
+llvm-gcc by default, but can be accessed through 'opt'.</li>
+
+<li>Dan Gohman contributed several enhancements to Loop Strength Reduction (LSR)
+to make it more aggressive with SSE intrinsics and when induction variables are
+used by non-memory instructions.</li> 
+
+<li>Evan added support for simple exit value substitution to LSR.</li>
+
+<li>Evan enhanced LSR to support induction variable reuse when the induction
+variables have different widths.</li>
 
 </ul>
+
 </div>
 
 
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="targetspecific">Target Specific Improvements</a>
+</div>
+
+<div class="doc_text">
+<p>New target-specific features include:
+</p>
+
+<ul>
+<li>Evan contributed support to the X86 backend to model the mod/ref behavior
+of the EFLAGS register explicitly in all instructions.  This gives more freedom
+to the scheduler, and is a more explicit way to model the instructions.</li>
+<li>Dale contributed support for exception handling on Darwin/PPC and he and
+Anton got x86-64 working.</li> 
+<li>Evan turned on if-conversion by default for ARM, allowing LLVM to take
+advantage of its predication features.</li>
+<li>Bruno added PIC support to the MIPS backend, fixed many bugs and improved
+support for architecture variants.</li>
+<li>Arnold Schwaighofer added initial support for X86 tail calls.</li>
+<li>Evan contributed several enhancements to Darwin/x86 debug information.</li>
+<li>Duncan added x86-64 support for trampolines (pointers to nested functions).</li>
+</ul>
+  
+</div>
+
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="otherimprovements">Other Improvements</a>
+</div>
+
+<div class="doc_text">
+<p>New features include:
+</p>
+
+<ul>
+<li>Gordon expanded and updated the <a href="Passes.html">LLVM Analysis and
+Transformation Passes</a> reference to include descriptions for each pass.</li>
+
+<li>We rewrote the lexer and parser used by TableGen to make them simpler
+and cleaner.  This gives tblgen support for 'caret diagnostics'.  The .ll file
+lexer was also rewritten to support caret diagnostics but doesn't use this
+support yet.</li>
+ 
+<li>Dale has been grinding through the GCC testsuite, and marked many 
+LLVM-incompatible tests as not-to-be-run (for example, if they are grepping
+through some GCC dump file that LLVM doesn't produce), he also found and fixed
+many LLVM bugs exposed by the testsuite.</li>
+</ul>
+  
+</div>
+
 <!-- *********************************************************************** -->
 <div class="doc_section">
   <a name="portability">Portability and Supported Platforms</a>
@@ -237,14 +347,14 @@ instructions.</p>
 <p>LLVM is known to work on the following platforms:</p>
 
 <ul>
-  <li>Intel and AMD machines running Red Hat Linux, Fedora Core and FreeBSD 
+<li>Intel and AMD machines running Red Hat Linux, Fedora Core and FreeBSD 
       (and probably other unix-like systems).</li>
-<li>Intel and AMD machines running on Win32 using MinGW libraries (native)</li>
-<li>Sun UltraSPARC workstations running Solaris 8.</li>
+<li>PowerPC and X86-based Mac OS X systems, running 10.3 and above in 32-bit and
+    64-bit modes.</li>
+<li>Intel and AMD machines running on Win32 using MinGW libraries (native).</li>
 <li>Intel and AMD machines running on Win32 with the Cygwin libraries (limited
     support is available for native builds with Visual C++).</li>
-<li>PowerPC and X86-based Mac OS X systems, running 10.2 and above in 32-bit and
-    64-bit modes.</li>
+<li>Sun UltraSPARC workstations running Solaris 8.</li>
 <li>Alpha-based machines running Debian GNU/Linux.</li>
 <li>Itanium-based machines running Linux and HP-UX.</li>
 </ul>
@@ -287,13 +397,12 @@ useful to some people.  In particular, if you would like to work on one of these
 components, please contact us on the <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVMdev list</a>.</p>
 
 <ul>
-<li>The <tt>-cee</tt> pass is known to be buggy, and may be removed in in a 
-    future release.</li>
-<li>The IA64 code generator is experimental.</li>
-<li>The ARM code generator is experimental.</li>
-<li>The Alpha JIT is experimental.</li>
-<li>"<tt>-filetype=asm</tt>" (the default) is the only supported value for the 
-    <tt>-filetype</tt> llc option.</li>
+<li>The <tt>-cee</tt> pass is known to be buggy and will be removed in
+    LLVM 2.3.</li>
+<li>The MSIL, IA64, Alpha, and MIPS backends are experimental.</li>
+<li>The LLC "<tt>-filetype=asm</tt>" (the default) is the only supported
+    value for this option.</li>
+<li>The llvmc tool is not supported.</li>
 </ul>
 
 </div>
@@ -307,9 +416,12 @@ components, please contact us on the <a href="http://lists.cs.uiuc.edu/mailman/l
 
 <ul>
 <li>The X86 backend does not yet support <a href="http://llvm.org/PR879">inline
-    assembly that uses the X86 floating point stack</a>.  See the <a 
-    href="http://llvm.org/PR879">bug</a> for details on workarounds on
-    Linux.</li>
+    assembly that uses the X86 floating point stack</a>.</li>
+<li>The X86 backend occasionally has <a href="http://llvm.org/PR1649">alignment
+    problems</a> on operating systems that don't require 16-byte stack alignment
+    (including most non-darwin OS's like linux).</li>
+<li>The X86 backend generates inefficient floating point code when configured to
+    generate code for systems that don't have SSE2.</li>
 </ul>
 
 </div>
@@ -322,10 +434,27 @@ components, please contact us on the <a href="http://lists.cs.uiuc.edu/mailman/l
 <div class="doc_text">
 
 <ul>
-<li><a href="http://llvm.org/PR642">PowerPC backend does not correctly
-implement ordered FP comparisons</a>.</li>
-<li>The 64-bit PowerPC backend is not fully stable. If you desire PPC64 support,
-    please use mainline CVS LLVM, which has several important bug fixes.</li>
+<li>The Linux PPC32/ABI support needs testing for the interpreter and static
+compilation, and lacks support for debug information.</li>
+</ul>
+
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+  <a name="arm-be">Known problems with the ARM back-end</a>
+</div>
+
+<div class="doc_text">
+
+<ul>
+<li>Thumb mode works only on ARMv6 or higher processors. On sub-ARMv6
+processors, thumb programs can crash or produce wrong
+results (<a href="http://llvm.org/PR1388">PR1388</a>).</li>
+<li>Compilation for ARM Linux OABI (old ABI) is supported, but not fully tested.
+</li>
+<li>There is a bug in QEMU-ARM (&lt;= 0.9.0) which causes it to incorrectly execute
+programs compiled with LLVM.  Please use more recent versions of QEMU.</li>
 </ul>
 
 </div>
@@ -344,36 +473,6 @@ implement ordered FP comparisons</a>.</li>
 
 </div>
 
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="c-be">Known problems with the C back-end</a>
-</div>
-
-<div class="doc_text">
-
-<ul>
-
-<li>The C back-end produces code that violates the ANSI C Type-Based Alias
-Analysis rules.  As such, special options may be necessary to compile the code
-(for example, GCC requires the <tt>-fno-strict-aliasing</tt> option).  This
-problem probably cannot be fixed.</li>
-
-<li><a href="http://llvm.org/PR56">Zero arg vararg functions are not 
-supported</a>.  This should not affect LLVM produced by the C or C++ 
-frontends.</li>
-
-<li>The C backend does not correctly implement the <a 
-href="LangRef.html#int_stacksave"><tt>llvm.stacksave</tt></a> or
-<a href="LangRef.html#int_stackrestore"><tt>llvm.stackrestore</tt></a> 
-intrinsics.  This means that some code compiled by it can run out of stack
-space if they depend on these (e.g. C99 varargs).</li>
-
-<li><a href="http://llvm.org/PR802">The C backend does not support inline
-    assembly code</a>.</li>
-</ul>
-
-</div>
-
 <!-- ======================================================================= -->
 <div class="doc_subsection">
   <a name="alpha-be">Known problems with the Alpha back-end</a>
@@ -415,36 +514,31 @@ programs.</li>
 
 <li>Defining vararg functions is not supported (but calling them is ok).</li>
 
+<li>The Itanium backend has bitrotted somewhat.</li>
 </ul>
 
 </div>
 
 <!-- ======================================================================= -->
 <div class="doc_subsection">
-  <a name="arm-be">Known problems with the ARM back-end</a>
+  <a name="c-be">Known problems with the C back-end</a>
 </div>
 
 <div class="doc_text">
 
 <ul>
-<li>The ARM backend is currently in early development stages, it is not 
-ready for production use.</li>
+<li><a href="http://llvm.org/PR802">The C backend does not support inline
+    assembly code</a>.</li>
+<li><a href="http://llvm.org/PR1126">The C backend does not support vectors
+    yet</a>.</li>
+<li><a href="http://llvm.org/PR1658">The C backend violates the ABI of common
+    C++ programs</a>, preventing intermixing between C++ compiled by the CBE and
+    C++ code compiled with LLC or native compilers.</li>
+<li>The C backend does not support all exception handling constructs.</li>
 </ul>
 
 </div>
 
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-  <a name="core">Known problems with the LLVM Core</a>
-</div>
-
-<div class="doc_text">
-
-<ul>
-  <li>In the JIT, <tt>dlsym()</tt> on a symbol compiled by the JIT will not
-  work.</li>
-</ul>
-</div>
 
 <!-- ======================================================================= -->
 <div class="doc_subsection">
@@ -456,15 +550,9 @@ ready for production use.</li>
 
 <div class="doc_text">
 
-<p>
-
-<p>llvm-gcc4 is far more stable and produces better code than llvm-gcc3, but
-does not currently support <a href="http://llvm.org/PR869">Link-Time 
-Optimization</a> or <a href="http://llvm.org/PR870">C++ Exception Handling</a>,
-which llvm-gcc3 does.</p>
-
-<p>llvm-gcc4 does not support the <a href="http://llvm.org/PR947">GCC indirect
-goto extension</a>, but llvm-gcc3 does.</p>
+<p>llvm-gcc does not currently support <a href="http://llvm.org/PR869">Link-Time
+Optimization</a> on most platforms "out-of-the-box".  Please inquire on the
+llvmdev mailing list if you are interested.</p>
 
 </div>
 
@@ -474,86 +562,52 @@ goto extension</a>, but llvm-gcc3 does.</p>
 </div>
 
 <div class="doc_text">
-
 <ul>
 
-<li>"long double" is transformed by the front-end into "double".  There is no
-support for floating point data types of any size other than 32 and 64
-bits.</li>
-    
-<li>Although many GCC extensions are supported, some are not.  In particular,
-    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/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/Thread_002dLocal.html">Thread-Local</a>: Per-thread variables.</li>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Pragmas.html#Pragmas">Pragmas</a>: Pragmas accepted by GCC.</li>
-  </ol>
-
-  <p>The following GCC extensions are <b>partially</b> supported.  An ignored
-  attribute means that the LLVM compiler ignores the presence of the attribute,
-  but the code should still work.  An unsupported attribute is one which is
-  ignored by the LLVM compiler and will cause a different interpretation of
-  the program.</p>
+<li><p>llvm-gcc does <b>not</b> support <tt>__builtin_apply</tt> yet.
+  See <a href="http://gcc.gnu.org/onlinedocs/gcc/Constructing-Calls.html#Constructing%20Calls">Constructing Calls</a>: Dispatching a call to another function.</p>
+</li>
 
+<li><p>llvm-gcc <b>partially</b> supports these GCC extensions:</p>
   <ol>
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html#Variable%20Length">Variable Length</a>:
-      Arrays whose length is computed at run time.<br>
-      Supported, but allocated stack space is not freed until the function returns (noted above).</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.
+      Nested functions are supported, but llvm-gcc does not support
+      taking the address of a nested function (except on X86 targets)
+      or non-local gotos.</li>
 
   <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function%20Attributes">Function Attributes</a>:
 
       Declaring that functions have no side effects or that they can never
       return.<br>
 
-      <b>Supported:</b> <tt>constructor</tt>, <tt>destructor</tt>,
+      <b>Supported:</b> <tt>alias</tt>, <tt>always_inline</tt>, <tt>cdecl</tt>, 
+      <tt>const</tt>, <tt>constructor</tt>, <tt>destructor</tt>, 
       <tt>deprecated</tt>, <tt>fastcall</tt>, <tt>format</tt>, 
-      <tt>format_arg</tt>, <tt>non_null</tt>, <tt>noreturn</tt>, 
+      <tt>format_arg</tt>, <tt>non_null</tt>, <tt>noinline</tt>, 
+      <tt>noreturn</tt>, <tt>nothrow</tt>, <tt>pure</tt>, <tt>regparm</tt>
       <tt>section</tt>, <tt>stdcall</tt>, <tt>unused</tt>, <tt>used</tt>, 
       <tt>visibility</tt>, <tt>warn_unused_result</tt>, <tt>weak</tt><br>
 
-      <b>Ignored:</b> <tt>noinline</tt>,
-      <tt>always_inline</tt>, <tt>pure</tt>, <tt>const</tt>, <tt>nothrow</tt>,
-      <tt>malloc</tt>, <tt>no_instrument_function</tt>, <tt>cdecl</tt><br>
-
-      <b>Unsupported:</b> <tt>alias</tt>, <tt>regparm</tt>, all other target specific 
-      attributes</li>
-   
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html#Variable%20Attributes">Variable Attributes</a>:
-      Specifying attributes of variables.<br>
-      <b>Supported:</b> <tt>cleanup</tt>, <tt>common</tt>, <tt>nocommon</tt>,
-      <tt>deprecated</tt>, <tt>dllimport</tt>, <tt>dllexport</tt>, 
-      <tt>section</tt>, <tt>transparent_union</tt>, <tt>unused</tt>, 
-      <tt>used</tt>, <tt>weak</tt><br>
-
-      <b>Unsupported:</b> <tt>aligned</tt>, <tt>mode</tt>, <tt>packed</tt>,
-                          <tt>shared</tt>, <tt>tls_model</tt>,
-                          <tt>vector_size</tt>, all target specific attributes.
-  </li>
-
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html#Type%20Attributes">Type Attributes</a>:	Specifying attributes of types.<br>
-      <b>Supported:</b> <tt>transparent_union</tt>, <tt>unused</tt>,
-                        <tt>deprecated</tt>, <tt>may_alias</tt><br>
-
-      <b>Unsupported:</b> <tt>aligned</tt>, <tt>packed</tt>, 
-                        all target specific attributes.</li>
-
-  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#Other%20Builtins">Other Builtins</a>:
-      Other built-in functions.<br>
-      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>), 
-         <tt>__builtin_prefetch</tt>, <tt>__builtin_popcount[ll]</tt>,
-         <tt>__builtin_clz[ll]</tt>, and <tt>__builtin_ctz[ll]</tt>.</li>
+      <b>Ignored:</b> <tt>malloc</tt>,
+      <tt>no_instrument_function</tt></li>
   </ol>
+</li>
 
-  <p>The following extensions <b>are</b> known to be supported:</p>
+<li><p>llvm-gcc supports the vast majority of GCC extensions, including:</p>
 
   <ol>
+  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Pragmas.html#Pragmas">Pragmas</a>: Pragmas accepted by GCC.</li>
+  <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/Other-Builtins.html#Other%20Builtins">Other Builtins</a>:
+      Other built-in functions.</li>
+  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html#Variable%20Attributes">Variable Attributes</a>:
+      Specifying attributes of variables.</li>
+  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html#Type%20Attributes">Type Attributes</a>:	Specifying attributes of types.</li>
+  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Thread_002dLocal.html">Thread-Local</a>: Per-thread variables.</li>
+  <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html#Variable%20Length">Variable Length</a>:
+      Arrays whose length is computed at run time.</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/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>
@@ -609,44 +663,66 @@ lists, please let us know (also including whether or not they work).</p>
 
 <div class="doc_text">
 
-<p>For this release, the C++ front-end is considered to be fully
+<p>The C++ front-end is considered to be fully
 tested and works for a number of non-trivial programs, including LLVM
-itself.</p>
+itself, Qt, Mozilla, etc.</p>
 
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
-  Notes
-</div>
-
-<div class="doc_text">
 <ul>
-<li>llvm-gcc4 does not support C++ exception handling at all yet.</li>
-
-<li>Destructors for local objects are not always run when a <tt>longjmp</tt> is
-    performed. In particular, destructors for objects in the <tt>longjmp</tt>ing
-    function and in the <tt>setjmp</tt> receiver function may not be run.
-    Objects in intervening stack frames will be destroyed, however (which is
-    better than most compilers).</li>
-
-<li>The LLVM C++ front-end follows the <a
-    href="http://www.codesourcery.com/cxx-abi">Itanium C++ ABI</a>.
-    This document, which is not Itanium specific, specifies a standard for name
-    mangling, class layout, v-table layout, RTTI formats, and other C++
-    representation issues.  Because we use this API, code generated by the LLVM
-    compilers should be binary compatible with machine code generated by other
-    Itanium ABI C++ compilers (such as G++, the Intel and HP compilers, etc).
-    <i>However</i>, the exception handling mechanism used by llvm-gcc3 is very
-    different from the model used in the Itanium ABI, so <b>exceptions will not
-    interact correctly</b>. </li>
-
+<li>Exception handling only works well on the X86 and PowerPC targets.
+It works well for x86-64 darwin but not x86-64 linux.</li>
 </ul>
 
 </div>
 
 
 
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+  <a name="ada-fe">Known problems with the Ada front-end</a>
+</div>
+
+<div class="doc_text">
+The llvm-gcc 4.2 Ada compiler works fairly well, however this is not a mature
+technology and problems should be expected.
+<ul>
+<li>The Ada front-end currently only builds on x86-32.  This is mainly due
+to lack of trampoline support (pointers to nested functions) on other platforms,
+however it <a href="http://llvm.org/PR2006">also fails to build on x86-64</a>
+which does support trampolines.</li>
+<li>The Ada front-end <a href="http://llvm.org/PR2007">fails to bootstrap</a>.
+Workaround: configure with --disable-bootstrap.</li>
+<li>The c380004 and <a href="http://llvm.org/PR2010">c393010</a> ACATS tests
+fail (c380004 also fails with gcc-4.2 mainline).</li>
+<li>Many gcc specific Ada tests continue to crash the compiler.</li>
+<li>The -E binder option (exception backtraces)
+<a href="http://llvm.org/PR1982">does not work</a> and will result in programs
+crashing if an exception is raised.  Workaround: do not use -E.</li>
+<li>Only discrete types <a href="http://llvm.org/PR1981">are allowed to start
+or finish at a non-byte offset</a> in a record.  Workaround: do not pack records
+or use representation clauses that result in a field of a non-discrete type
+starting or finishing in the middle of a byte.</li>
+<li>The lli interpreter <a href="http://llvm.org/PR2009">considers 'main'
+as generated by the Ada binder to be invalid</a>.
+Workaround: hand edit the file to use pointers for argv and envp rather than
+integers.</li>
+<li>The -fstack-check option <a href="http://llvm.org/PR2008">is ignored</a>.</li>
+</ul>
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+  <a name="fortran-fe">Known problems with the Fortran front-end</a>
+</div>
+
+<div class="doc_text">
+
+<ul>
+<li>The llvm-gcc 4.2 gfortran front-end supports a broad range of Fortran code, but does
+<a href="http://llvm.org/PR1971">not support EQUIVALENCE yet</a>.</li>
+</ul>
+</div>
+
+
 <!-- *********************************************************************** -->
 <div class="doc_section">
   <a name="additionalinfo">Additional Information</a>
@@ -656,11 +732,10 @@ itself.</p>
 <div class="doc_text">
 
 <p>A wide variety of additional information is available on the <a
-href="http://llvm.org">LLVM web page</a>, including <a
-href="http://llvm.org/docs/">documentation</a> and <a
-href="http://llvm.org/pubs/">publications describing algorithms and
-components implemented in LLVM</a>.  The web page also contains versions of the
-API documentation which is up-to-date with the CVS version of the source code.
+href="http://llvm.org">LLVM web page</a>, in particular in the <a
+href="http://llvm.org/docs/">documentation</a> section.  The web page also
+contains versions of the API documentation which is up-to-date with the
+Subversion version of the source code.
 You can access versions of these documents specific to this release by going
 into the "<tt>llvm/doc/</tt>" directory in the LLVM tree.</p>
 
@@ -677,9 +752,9 @@ lists</a>.</p>
   <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>
+  src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"></a>
 
-  <a href="http://llvm.org/">The LLVM Compiler Infrastructure</a><br>
+  <a href="http://llvm.org/">LLVM Compiler Infrastructure</a><br>
   Last modified: $Date$
 </address>
 

llvm/docs/SourceLevelDebugging.html

@@ -747,7 +747,7 @@ provide debug information at various points in generated code.</p>
 
 <p>This intrinsic is used to provide correspondence between the source file and
 the generated code.  The first argument is the line number (base 1), second
-argument si the column number (0 if unknown) and the third argument the source
+argument is the column number (0 if unknown) and the third argument the source
 <tt>%<a href="#format_compile_units">llvm.dbg.compile_unit</a>*</tt> cast to a
 <tt>{ }*</tt>.  Code following a call to this intrinsic will have been defined
 in close proximity of the line, column and file.  This information holds until
@@ -991,7 +991,7 @@ another scope).</p>
 
 <p>It is worth noting that this scoping mechanism is used to control scoping of
 all declarations, not just variable declarations.  For example, the scope of a
-C++ using declaration is controlled with this couldchange how name lookup is
+C++ using declaration is controlled with this and could change how name lookup is
 performed.</p>
 
 </div>

llvm/docs/Stacker.html

@@ -1296,18 +1296,26 @@ remainder of the story.
 </div>
 <!-- ======================================================================= -->
 <div class="doc_subsection"> <a name="directory">Directory Structure</a></div>
+
 <div class="doc_text">
 <p>The source code, test programs, and sample programs can all be found
 in the LLVM repository named <tt>llvm-stacker</tt> This should be checked out to
 the <tt>projects</tt> directory so that it will auto-configure. To do that, make
 sure you have the llvm sources in <tt><i>llvm</i></tt> 
 (see <a href="GettingStarted.html">Getting Started</a>) and then use these 
-commands:<pre>
-    cd <i>llvm</i>/projects
-    cvs co llvm-stacker</pre>
-</p>
+commands:</p>
+
+<div class="doc_code">
+<pre>
+% svn co http://llvm.org/svn/llvm-project/llvm-top/trunk llvm-top
+% cd llvm-top
+% make build MODULE=stacker
+</pre>
+</div>
+
 <p>Under the <tt>projects/llvm-stacker</tt> directory you will find the
 implementation of the Stacker compiler, as follows:</p>
+
 <ul>
     <li><em>lib</em> - contains most of the source code
     <ul>
@@ -1322,11 +1330,14 @@ implementation of the Stacker compiler, as follows:</p>
     <li><em>sample</em> - contains the sample programs</li>
 </ul>
 </div>
+
 <!-- ======================================================================= -->
 <div class="doc_subsection"><a name="lexer"></a>The Lexer</div>
+
 <div class="doc_text">
 <p>See projects/llvm-stacker/lib/compiler/Lexer.l</p>
 </div>
+
 <!-- ======================================================================= -->
 <div class="doc_subsection"><a name="parser"></a>The Parser</div>
 <div class="doc_text">

llvm/docs/TestingGuide.html

@@ -106,30 +106,40 @@ and tcl.</p>
 
 <div class="doc_text">
 
-<p>The tests are located in two separate CVS modules. The basic feature and 
-regression tests are in the main "llvm" module under the directory 
-<tt>llvm/test</tt>. A more comprehensive test suite that includes whole 
-programs in C and C++ is in the <tt>llvm-test</tt> module. This module should 
-be checked out to the <tt>llvm/projects</tt> directory. When you
-<tt>configure</tt> the <tt>llvm</tt> module, the <tt>llvm-test</tt> module
-will be automatically configured. Alternatively, you can configure the
- <tt>llvm-test</tt> module manually.</p>
+  <p>The tests are located in two separate Subversion modules. The basic feature
+  and regression tests are in the main "llvm" module under the directory 
+  <tt>llvm/test</tt>. A more comprehensive test suite that includes whole 
+programs in C and C++ is in the <tt>test-suite</tt> module. This module should 
+be checked out to the <tt>llvm/projects</tt> directory as llvm-test (for
+historical purpose).  When you <tt>configure</tt> the <tt>llvm</tt> module, 
+the <tt>llvm-test</tt> directory will be automatically configured. 
+Alternatively, you can configure the <tt>test-suite</tt> module manually.</p>
 <p>To run all of the simple tests in LLVM using DejaGNU, use the master Makefile
  in the <tt>llvm/test</tt> directory:</p>
+
+<div class="doc_code">
 <pre>
 % gmake -C llvm/test
 </pre>
-or<br>
+</div>
+
+<p>or</p>
+
+<div class="doc_code">
 <pre>
 % gmake check
 </pre>
+</div>
 
 <p>To run only a subdirectory of tests in llvm/test using DejaGNU (ie.
 Regression/Transforms), just set the TESTSUITE variable to the path of the
 subdirectory (relative to <tt>llvm/test</tt>):</p>
+
+<div class="doc_code">
 <pre>
 % gmake -C llvm/test TESTSUITE=Regression/Transforms
 </pre>
+</div>
 
 <p><b>Note: If you are running the tests with <tt>objdir != subdir</tt>, you
 must have run the complete testsuite before you can specify a
@@ -138,13 +148,16 @@ subdirectory.</b></p>
 <p>To run the comprehensive test suite (tests that compile and execute whole 
 programs), run the <tt>llvm-test</tt> tests:</p>
 
+<div class="doc_code">
 <pre>
 % cd llvm/projects
-% cvs co llvm-test
-% cd llvm-test
-% ./configure --with-llvmsrc=$LLVM_SRC_ROOT --with-llvmobj=$LLVM_OBJ_ROOT
+% svn co http://llvm.org/svn/llvm-project/test-suite/trunk llvm-test
+% cd ..
+% ./configure --with-llvmgccdir=$LLVM_GCC_DIR
+% cd projects/llvm-test
 % gmake
 </pre>
+</div>
 
 </div>
 
@@ -201,7 +214,7 @@ 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>All "whole program" tests are located in the <tt>llvm-test</tt> CVS
+<p>All "whole program" tests are located in the <tt>test-suite</tt> Subversion
 module.</p> 
 
 </div>
@@ -220,26 +233,27 @@ subtrees of the test suite directory tree are as follows:</p>
   <p>This directory contains a large array of small tests
   that exercise various features of LLVM and to ensure that regressions do not
   occur. The directory is broken into several sub-directories, each focused on
-  a particular area of LLVM. A few of the important ones are:<ul>
+  a particular area of LLVM. A few of the important ones are:</p>
+  <ul>
     <li><tt>Analysis</tt>: checks Analysis passes.</li>
     <li><tt>Archive</tt>: checks the Archive library.</li>
     <li><tt>Assembler</tt>: checks Assembly reader/writer functionality.</li>
-    <li><tt>Bytecode</tt>: checks Bytecode reader/writer functionality.</li>
+    <li><tt>Bitcode</tt>: checks Bitcode reader/writer functionality.</li>
     <li><tt>CodeGen</tt>: checks code generation and each target.</li>
     <li><tt>Features</tt>: checks various features of the LLVM language.</li>
-    <li><tt>Linker</tt>: tests bytecode linking.</li>
+    <li><tt>Linker</tt>: tests bitcode linking.</li>
     <li><tt>Transforms</tt>: tests each of the scalar, IPO, and utility
     transforms to ensure they make the right transformations.</li>
     <li><tt>Verifier</tt>: tests the IR verifier.</li>
-  </ul></p>
+  </ul>
   <p>Typically when a bug is found in LLVM, a regression test containing 
   just enough code to reproduce the problem should be written and placed 
   somewhere underneath this directory.  In most cases, this will be a small 
   piece of LLVM assembly language code, often distilled from an actual 
   application or benchmark.</p></li>
 
-<li><tt>llvm-test</tt>
-<p>The <tt>llvm-test</tt> CVS module contains programs that can be compiled 
+<li><tt>test-suite</tt>
+<p>The <tt>test-suite</tt> module contains programs that can be compiled 
 with LLVM and executed.  These programs are compiled using the native compiler
 and various LLVM backends.  The output from the program compiled with the 
 native compiler is assumed correct; the results from the other programs are
@@ -324,11 +338,14 @@ location of these external programs is configured by the llvm-test
   </p>
 
   <p> Below is an example of legal RUN lines in a <tt>.ll</tt> file:</p>
-  <pre>
-  ; RUN: llvm-as &lt; %s | llvm-dis &gt; %t1
-  ; RUN: llvm-dis &lt; %s.bc-13 &gt; %t2
-  ; RUN: diff %t1 %t2
-  </pre>
+
+<div class="doc_code">
+<pre>
+; RUN: llvm-as &lt; %s | llvm-dis &gt; %t1
+; RUN: llvm-dis &lt; %s.bc-13 &gt; %t2
+; RUN: diff %t1 %t2
+</pre>
+</div>
 
   <p>As with a Unix shell, the RUN: lines permit pipelines and I/O redirection
   to be used. However, the usage is slightly different than for Bash. To check
@@ -351,43 +368,66 @@ location of these external programs is configured by the llvm-test
   <p>There are some quoting rules that you must pay attention to when writing
   your RUN lines. In general nothing needs to be quoted. Tcl won't strip off any
   ' or " so they will get passed to the invoked program. For example:</p>
-  <pre>
-     ... | grep 'find this string'
-  </pre>
+
+<div class="doc_code">
+<pre>
+... | grep 'find this string'
+</pre>
+</div>
+
   <p>This will fail because the ' characters are passed to grep. This would
   instruction grep to look for <tt>'find</tt> in the files <tt>this</tt> and
   <tt>string'</tt>. To avoid this use curly braces to tell Tcl that it should
   treat everything enclosed as one value. So our example would become:</p>
-  <pre>
-     ... | grep {find this string}
-  </pre>
+
+<div class="doc_code">
+<pre>
+... | grep {find this string}
+</pre>
+</div>
+
   <p>Additionally, the characters <tt>[</tt> and <tt>]</tt> are treated 
   specially by Tcl. They tell Tcl to interpret the content as a command to
   execute. Since these characters are often used in regular expressions this can
   have disastrous results and cause the entire test run in a directory to fail.
   For example, a common idiom is to look for some basicblock number:</p>
-  <pre>
-     ... | grep bb[2-8]
-  </pre>
+
+<div class="doc_code">
+<pre>
+... | grep bb[2-8]
+</pre>
+</div>
+
   <p>This, however, will cause Tcl to fail because its going to try to execute
   a program named "2-8". Instead, what you want is this:</p>
-  <pre>
-     ... | grep {bb\[2-8\]}
-  </pre>
+
+<div class="doc_code">
+<pre>
+... | grep {bb\[2-8\]}
+</pre>
+</div>
+
   <p>Finally, if you need to pass the <tt>\</tt> character down to a program,
   then it must be doubled. This is another Tcl special character. So, suppose
   you had:
-  <pre>
-     ... | grep 'i32\*'
-  </pre>
+
+<div class="doc_code">
+<pre>
+... | grep 'i32\*'
+</pre>
+</div>
+
   <p>This will fail to match what you want (a pointer to i32). First, the
   <tt>'</tt> do not get stripped off. Second, the <tt>\</tt> gets stripped off
   by Tcl so what grep sees is: <tt>'i32*'</tt>. That's not likely to match
   anything. To resolve this you must use <tt>\\</tt> and the <tt>{}</tt>, like
   this:</p>
-  <pre>
-     ... | grep {i32\\*}
-  </pre>
+
+<div class="doc_code">
+<pre>
+... | grep {i32\\*}
+</pre>
+</div>
 
 </div>
 
@@ -402,38 +442,49 @@ location of these external programs is configured by the llvm-test
   library, certain names can be accessed with an alternate syntax: a % prefix.
   These alternates are deprecated and may go away in a future version.
   </p>
-  Here are the available variable names. The alternate syntax is listed in
+  <p>Here are the available variable names. The alternate syntax is listed in
   parentheses.</p>
+
   <dl style="margin-left: 25px">
     <dt><b>$test</b> (%s)</dt>
     <dd>The full path to the test case's source. This is suitable for passing
     on the command line as the input to an llvm tool.</dd>
+
     <dt><b>$srcdir</b></dt>
     <dd>The source directory from where the "<tt>make check</tt>" was run.</dd>
+
     <dt><b>objdir</b></dt>
-    <dd>The object directory that corresponds to the </tt>$srcdir</tt>.</dd>
+    <dd>The object directory that corresponds to the <tt>$srcdir</tt>.</dd>
+
     <dt><b>subdir</b></dt>
     <dd>A partial path from the <tt>test</tt> directory that contains the 
     sub-directory that contains the test source being executed.</dd>
+
     <dt><b>srcroot</b></dt>
     <dd>The root directory of the LLVM src tree.</dd>
+
     <dt><b>objroot</b></dt>
     <dd>The root directory of the LLVM object tree. This could be the same
     as the srcroot.</dd>
+
     <dt><b>path</b><dt>
     <dd>The path to the directory that contains the test case source.  This is 
     for locating any supporting files that are not generated by the test, but 
     used by the test.</dd>
+
     <dt><b>tmp</b></dt>
     <dd>The path to a temporary file name that could be used for this test case.
     The file name won't conflict with other test cases. You can append to it if
     you need multiple temporaries. This is useful as the destination of some
     redirected output.</dd>
+
     <dt><b>llvmlibsdir</b> (%llvmlibsdir)</dt>
     <dd>The directory where the LLVM libraries are located.</dd>
+
     <dt><b>target_triplet</b> (%target_triplet)</dt>
     <dd>The target triplet that corresponds to the current host machine (the one
     running the test cases). This should probably be called "host".<dd>
+
     <dt><b>prcontext</b> (%prcontext)</dt>
     <dd>Path to the prcontext tcl script that prints some context around a 
     line that matches a pattern. This isn't strictly necessary as the test suite
@@ -441,31 +492,41 @@ location of these external programs is configured by the llvm-test
     the prcontext script is located. Note that this script is similar to 
     <tt>grep -C</tt> but you should use the <tt>prcontext</tt> script because
     not all platforms support <tt>grep -C</tt>.</dd>
+
     <dt><b>llvmgcc</b> (%llvmgcc)</dt>
     <dd>The full path to the <tt>llvm-gcc</tt> executable as specified in the
     configured LLVM environment</dd>
+
     <dt><b>llvmgxx</b> (%llvmgxx)</dt>
     <dd>The full path to the <tt>llvm-gxx</tt> executable as specified in the
     configured LLVM environment</dd>
+
     <dt><b>llvmgcc_version</b> (%llvmgcc_version)</dt>
     <dd>The full version number of the <tt>llvm-gcc</tt> executable.</dd>
+
     <dt><b>llvmgccmajvers</b> (%llvmgccmajvers)</dt>
     <dd>The major version number of the <tt>llvm-gcc</tt> executable.</dd>
+
     <dt><b>gccpath</b></dt>
     <dd>The full path to the C compiler used to <i>build </i> LLVM. Note that 
     this might not be gcc.</dd>
+
     <dt><b>gxxpath</b></dt>
     <dd>The full path to the C++ compiler used to <i>build </i> LLVM. Note that 
     this might not be g++.</dd>
+
     <dt><b>compile_c</b> (%compile_c)</dt>
     <dd>The full command line used to compile LLVM C source  code. This has all 
     the configured -I, -D and optimization options.</dd>
+
     <dt><b>compile_cxx</b> (%compile_cxx)</dt>
     <dd>The full command used to compile LLVM C++ source  code. This has 
     all the configured -I, -D and optimization options.</dd>
+
     <dt><b>link</b> (%link)</dt> 
     <dd>This full link command used to link LLVM executables. This has all the
     configured -I, -L and -l options.</dd>
+
     <dt><b>shlibext</b> (%shlibext)</dt>
     <dd>The suffix for the host platforms share library (dll) files. This
     includes the period as the first character.</dd>
@@ -491,6 +552,7 @@ location of these external programs is configured by the llvm-test
     non-zero result will cause the test to fail. This script overcomes that 
     issue and nicely documents that the test case is purposefully ignoring the
     result code of the tool</dd>
+
     <dt><b>not</b></dt>
     <dd>This script runs its arguments and then inverts the result code from 
     it. Zero result codes become 1. Non-zero result codes become 0. This is
@@ -511,9 +573,12 @@ location of these external programs is configured by the llvm-test
   succeed. To XFAIL everywhere just specify <tt>XFAIL: *</tt>. When matching
   the llvm-gcc version, you can specify the major (e.g. 3) or full version 
   (i.e. 3.4) number. Here is an example of an <tt>XFAIL</tt> line:</p>
-  <pre>
-   ; XFAIL: darwin,sun,llvmgcc4
-  </pre>
+
+<div class="doc_code">
+<pre>
+; XFAIL: darwin,sun,llvmgcc4
+</pre>
+</div>
 
   <p>To make the output more useful, the <tt>llvm_runtest</tt> function wil
   scan the lines of the test case for ones that contain a pattern that matches
@@ -573,12 +638,14 @@ specify the following configuration options:</p>
     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>
@@ -598,12 +665,12 @@ specify the following configuration options:</p>
 <i>are not</i> executed inside of the LLVM source tree. This is because the
 test suite creates temporary files during execution.</p>
 
-<p>The master Makefile in llvm/test is capable of running only the DejaGNU
-driven tests. By default, it will run all of these tests.</p>
+<p>The master Makefile in <tt>llvm/test</tt> is capable of running only the
+DejaGNU driven tests. By default, it will run all of these tests.</p>
 
 <p>To run only the DejaGNU driven tests, run <tt>gmake</tt> at the
 command line in <tt>llvm/test</tt>.  To run a specific directory of tests, use
-the TESTSUITE variable.
+the <tt>TESTSUITE</tt> variable.
 </p>
 
 <p>For example, to run the Regression tests, type 
@@ -613,40 +680,54 @@ the TESTSUITE variable.
 <tt>llvm/test/Regression</tt>. You must use DejaGNU from the <tt>llvm/test</tt>
 directory to run them.</p>
 
-<p>To run the <tt>llvm-test</tt> suite, you need to use the following steps:
-</p>
+<p>To run the <tt>llvm-test</tt> suite, you need to use the following steps:</p>
+
 <ol>
-  <li>cd into the llvm/projects directory</li>
-  <li>check out the <tt>llvm-test</tt> module with:<br/>
-  <tt>cvs -d :pserver:anon@llvm.org:/var/cvs/llvm co -PR llvm-test</tt><br> 
-  This will get the test suite into <tt>llvm/projects/llvm-test</tt></li>
-  <li>configure the test suite. You can do this one of two ways:
-  <ol>
-    <li>Use the regular llvm configure:<br/>
-    <tt>cd $LLVM_OBJ_ROOT ; $LLVM_SRC_ROOT/configure</tt><br/>
-    This will ensure that the <tt>projects/llvm-test</tt> directory is also
-    properly configured.</li>
-    <li>Use the <tt>configure</tt> script found in the <tt>llvm-test</tt> source
-    directory:<br/>
-    <tt>$LLVM_SRC_ROOT/projects/llvm-test/configure
-     --with-llvmsrc=$LLVM_SRC_ROOT --with-llvmobj=$LLVM_OBJ_ROOT</tt>
-    </li>
-  </ol>
-  <li>gmake</li>
+  <li><tt>cd</tt> into the <tt>llvm/projects</tt> directory</li>
+
+  <li><p>Check out the <tt>test-suite</tt> module with:</p>
+
+<div class="doc_code">
+<pre>
+% svn co http://llvm.org/svn/llvm-project/test-suite/trunk llvm-test
+</pre>
+</div>
+
+      <p>This will get the test suite into <tt>llvm/projects/llvm-test</tt></p>
+
+  <li><p>Configure the test suite using llvm configure. This will automatically configure llvm-test. 
+         You must do it from the top level otherwise llvm-gcc will not be set which is required to 
+        run llvm-test:</p>
+<div class="doc_code">
+<pre>
+% cd $LLVM_OBJ_ROOT ; $LLVM_SRC_ROOT/configure --with-llvmgccdir=$LLVM_GCC_DIR
+</pre>
+</div>
+  <li><tt>gmake</tt></li>
 </ol>
 <p>Note that the second and third steps only need to be done once. After you
 have the suite checked out and configured, you don't need to do it again (unless
-the test code or configure script changes).</p>
+the test code or configure script changes). $LLVM_GCC_DIR is the path to the LLVM 
+C/C++ FrontEnd</p>
 
 <p>To make a specialized test (use one of the
-<tt>llvm-test/TEST.&lt;type&gt;.Makefile</tt>s), just run:<br/>
-<tt>gmake TEST=&lt;type&gt; test</tt><br/>For example, you could run the
-nightly tester tests using the following commands:</p>
+<tt>llvm-test/TEST.&lt;type&gt;.Makefile</tt>s), just run:</p>
 
+<div class="doc_code">
 <pre>
- % cd llvm/projects/llvm-test
- % gmake TEST=nightly test
+% gmake TEST=&lt;type&gt; test
 </pre>
+</div>
+
+<p>For example, you could run the nightly tester tests using the following
+commands:</p>
+
+<div class="doc_code">
+<pre>
+% cd llvm/projects/llvm-test
+% gmake TEST=nightly test
+</pre>
+</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
@@ -760,24 +841,15 @@ as keep track of LLVM's progress over time.</p>
 machine, take a look at the comments at the top of the 
 <tt>utils/NewNightlyTest.pl</tt> file. If you decide to set up a nightly tester 
 please choose a unique nickname and invoke <tt>utils/NewNightlyTest.pl</tt> 
-with the "-nickname [yournickname]" command line option. We usually run it 
-from a crontab entry that looks like this:</p>
+with the "-nickname [yournickname]" command line option. 
 
-<div class="doc_code">
-<pre>
-5 3 * * *  $HOME/llvm/utils/NewNightlyTest.pl -parallel -nickname Nickname \
-           $CVSROOT $HOME/buildtest $HOME/cvs/testresults
-</pre>
-</div>
-
-<p>Or, you can create a shell script to encapsulate the running of the script.
+<p>You can create a shell script to encapsulate the running of the script.
 The optimized x86 Linux nightly test is run from just such a script:</p>
 
 <div class="doc_code">
 <pre>
 #!/bin/bash
 BASE=/proj/work/llvm/nightlytest
-export CVSROOT=:pserver:anon@llvm.org:/var/cvs/llvm
 export BUILDDIR=$BASE/build 
 export WEBDIR=$BASE/testresults 
 export LLVMGCCDIR=/proj/work/llvm/cfrontend/install
@@ -786,7 +858,7 @@ export LD_LIBRARY_PATH=/proj/install/lib
 cd $BASE
 cp /proj/work/llvm/llvm/utils/NewNightlyTest.pl .
 nice ./NewNightlyTest.pl -nice -release -verbose -parallel -enable-linscan \
-   -nickname NightlyTester -noexternals 2&gt;&amp;1 &gt; output.log
+   -nickname NightlyTester -noexternals &gt; output.log 2&gt;&amp;1 
 </pre>
 </div>