Overhauled llvm/clang docs builds. Closes PR6613.

NOTE: 2nd part changeset for cfe trunk to follow.

*** PRE-PATCH ISSUES ADDRESSED

- clang api docs fail build from objdir
- clang/llvm api docs collide in install PREFIX/
- clang/llvm main docs collide in install
- clang/llvm main docs have full of hard coded destination
  assumptions and make use of absolute root in static html files;
  namely CommandGuide tools hard codes a website destination
  for cross references and some html cross references assume
  website root paths

*** IMPROVEMENTS

- bumped Doxygen from 1.4.x -> 1.6.3
- splits llvm/clang docs into 'main' and 'api' (doxygen) build trees
- provide consistent, reliable doc builds for both main+api docs
- support buid vs. install vs. website intentions
- support objdir builds
- document targets with 'make help'
- correct clean and uninstall operations
- use recursive dir delete only where absolutely necessary
- added call function fn.RMRF which safeguards against botched 'rm -rf';
  if any target (or any variable is evaluated) which attempts
  to remove any dirs which match a hard-coded 'safelist', a verbose
  error will be printed and make will error-stop.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103213 91177308-0d34-0410-b5e6-96231b3b80d8

25 files changed, 0 insertions, 4160 deletions

diff --git a/docs/CommandGuide/FileCheck.pod b/docs/CommandGuide/FileCheck.pod
deleted file mode 100644
index 433979a871..0000000000
--- a/docs/CommandGuide/FileCheck.pod
+++ /dev/null
@@ -1,245 +0,0 @@
-
-=pod
-
-=head1 NAME
-
-FileCheck - Flexible pattern matching file verifier
-
-=head1 SYNOPSIS
-
-B<FileCheck> I<match-filename> [I<--check-prefix=XXX>] [I<--strict-whitespace>]
-
-=head1 DESCRIPTION
-
-B<FileCheck> reads two files (one from standard input, and one specified on the
-command line) and uses one to verify the other.  This behavior is particularly
-useful for the testsuite, which wants to verify that the output of some tool
-(e.g. llc) contains the expected information (for example, a movsd from esp or
-whatever is interesting).  This is similar to using grep, but it is optimized
-for matching multiple different inputs in one file in a specific order.
-
-The I<match-filename> file specifies the file that contains the patterns to
-match.  The file to verify is always read from standard input.
-
-=head1 OPTIONS
-
-=over
-
-=item B<-help>
-
-Print a summary of command line options.
-
-=item B<--check-prefix> I<prefix>
-
-FileCheck searches the contents of I<match-filename> for patterns to match.  By
-default, these patterns are prefixed with "CHECK:".  If you'd like to use a
-different prefix (e.g. because the same input file is checking multiple
-different tool or options), the B<--check-prefix> argument allows you to specify
-a specific prefix to match.
-
-=item B<--strict-whitespace>
-
-By default, FileCheck canonicalizes input horizontal whitespace (spaces and
-tabs) which causes it to ignore these differences (a space will match a tab).
-The --strict-whitespace argument disables this behavior.
-
-=item B<-version>
-
-Show the version number of this program.
-
-=back
-
-=head1 EXIT STATUS
-
-If B<FileCheck> verifies that the file matches the expected contents, it exits
-with 0.  Otherwise, if not, or if an error occurs, it will exit with a non-zero
-value.
-
-=head1 TUTORIAL
-
-FileCheck is typically used from LLVM regression tests, being invoked on the RUN
-line of the test.  A simple example of using FileCheck from a RUN line looks
-like this:
-
-  ; RUN: llvm-as < %s | llc -march=x86-64 | FileCheck %s
-
-This syntax says to pipe the current file ("%s") into llvm-as, pipe that into
-llc, then pipe the output of llc into FileCheck.  This means that FileCheck will
-be verifying its standard input (the llc output) against the filename argument
-specified (the original .ll file specified by "%s").  To see how this works,
-lets look at the rest of the .ll file (after the RUN line):
-
-  define void @sub1(i32* %p, i32 %v) {
-  entry:
-  ; <b>CHECK: sub1:</b>
-  ; <b>CHECK: subl</b>
-          %0 = tail call i32 @llvm.atomic.load.sub.i32.p0i32(i32* %p, i32 %v)
-          ret void
-  }
-  
-  define void @inc4(i64* %p) {
-  entry:
-  ; <b>CHECK: inc4:</b>
-  ; <b>CHECK: incq</b>
-          %0 = tail call i64 @llvm.atomic.load.add.i64.p0i64(i64* %p, i64 1)
-          ret void
-  }
-
-Here you can see some "CHECK:" lines specified in comments.  Now you can see
-how the file is piped into llvm-as, then llc, and the machine code output is
-what we are verifying.  FileCheck checks the machine code output to verify that
-it matches what the "CHECK:" lines specify.
-
-The syntax of the CHECK: lines is very simple: they are fixed strings that
-must occur in order.  FileCheck defaults to ignoring horizontal whitespace
-differences (e.g. a space is allowed to match a tab) but otherwise, the contents
-of the CHECK: line is required to match some thing in the test file exactly.
-
-One nice thing about FileCheck (compared to grep) is that it allows merging
-test cases together into logical groups.  For example, because the test above
-is checking for the "sub1:" and "inc4:" labels, it will not match unless there
-is a "subl" in between those labels.  If it existed somewhere else in the file,
-that would not count: "grep subl" matches if subl exists anywhere in the
-file.
-
-
-
-=head2 The FileCheck -check-prefix option
-
-The FileCheck -check-prefix option allows multiple test configurations to be
-driven from one .ll file.  This is useful in many circumstances, for example,
-testing different architectural variants with llc.  Here's a simple example:
-
-  ; RUN: llvm-as < %s | llc -mtriple=i686-apple-darwin9 -mattr=sse41 \
-  ; RUN:              | <b>FileCheck %s -check-prefix=X32</b>
-  ; RUN: llvm-as < %s | llc -mtriple=x86_64-apple-darwin9 -mattr=sse41 \
-  ; RUN:              | <b>FileCheck %s -check-prefix=X64</b>
-
-  define <4 x i32> @pinsrd_1(i32 %s, <4 x i32> %tmp) nounwind {
-          %tmp1 = insertelement <4 x i32>; %tmp, i32 %s, i32 1
-          ret <4 x i32> %tmp1
-  ; <b>X32:</b> pinsrd_1:
-  ; <b>X32:</b>    pinsrd $1, 4(%esp), %xmm0
-  
-  ; <b>X64:</b> pinsrd_1:
-  ; <b>X64:</b>    pinsrd $1, %edi, %xmm0
-  }
-
-In this case, we're testing that we get the expected code generation with
-both 32-bit and 64-bit code generation.
-
-
-
-=head2 The "CHECK-NEXT:" directive
-
-Sometimes you want to match lines and would like to verify that matches
-happen on exactly consequtive lines with no other lines in between them.  In
-this case, you can use CHECK: and CHECK-NEXT: directives to specify this.  If
-you specified a custom check prefix, just use "<PREFIX>-NEXT:".  For
-example, something like this works as you'd expect:
-
-  define void @t2(<2 x double>* %r, <2 x double&gt;* %A, double %B) {
-	%tmp3 = load <2 x double&gt;* %A, align 16
-	%tmp7 = insertelement <2 x double&gt; undef, double %B, i32 0
-	%tmp9 = shufflevector <2 x double&gt; %tmp3,
-                              <2 x double&gt; %tmp7,
-                              <2 x i32&gt; < i32 0, i32 2 &gt;
-	store <2 x double&gt; %tmp9, <2 x double&gt;* %r, align 16
-	ret void
-        
-  ; <b>CHECK:</b> t2:
-  ; <b>CHECK:</b> 	movl	8(%esp), %eax
-  ; <b>CHECK-NEXT:</b> 	movapd	(%eax), %xmm0
-  ; <b>CHECK-NEXT:</b> 	movhpd	12(%esp), %xmm0
-  ; <b>CHECK-NEXT:</b> 	movl	4(%esp), %eax
-  ; <b>CHECK-NEXT:</b> 	movapd	%xmm0, (%eax)
-  ; <b>CHECK-NEXT:</b> 	ret
-  }
-
-CHECK-NEXT: directives reject the input unless there is exactly one newline
-between it an the previous directive.  A CHECK-NEXT cannot be the first
-directive in a file.
-
-
-
-=head2 The "CHECK-NOT:" directive
-
-The CHECK-NOT: directive is used to verify that a string doesn't occur
-between two matches (or the first match and the beginning of the file).  For
-example, to verify that a load is removed by a transformation, a test like this
-can be used:
-
-  define i8 @coerce_offset0(i32 %V, i32* %P) {
-    store i32 %V, i32* %P
-   
-    %P2 = bitcast i32* %P to i8*
-    %P3 = getelementptr i8* %P2, i32 2
-
-    %A = load i8* %P3
-    ret i8 %A
-  ; <b>CHECK:</b> @coerce_offset0
-  ; <b>CHECK-NOT:</b> load
-  ; <b>CHECK:</b> ret i8
-  }
-
-
-
-=head2 FileCheck Pattern Matching Syntax
-
-The CHECK: and CHECK-NOT: directives both take a pattern to match.  For most
-uses of FileCheck, fixed string matching is perfectly sufficient.  For some
-things, a more flexible form of matching is desired.  To support this, FileCheck
-allows you to specify regular expressions in matching strings, surrounded by
-double braces: B<{{yourregex}}>.  Because we want to use fixed string
-matching for a majority of what we do, FileCheck has been designed to support
-mixing and matching fixed string matching with regular expressions.  This allows
-you to write things like this:
-
-  ; CHECK: movhpd	<b>{{[0-9]+}}</b>(%esp), <b>{{%xmm[0-7]}}</b>
-
-In this case, any offset from the ESP register will be allowed, and any xmm
-register will be allowed.
-
-Because regular expressions are enclosed with double braces, they are
-visually distinct, and you don't need to use escape characters within the double
-braces like you would in C.  In the rare case that you want to match double
-braces explicitly from the input, you can use something ugly like
-B<{{[{][{]}}> as your pattern.
-
-
-
-=head2 FileCheck Variables
-
-It is often useful to match a pattern and then verify that it occurs again
-later in the file.  For codegen tests, this can be useful to allow any register,
-but verify that that register is used consistently later.  To do this, FileCheck
-allows named variables to be defined and substituted into patterns.  Here is a
-simple example:
-
-  ; CHECK: test5:
-  ; CHECK:    notw	<b>[[REGISTER:%[a-z]+]]</b>
-  ; CHECK:    andw	{{.*}}<b>[[REGISTER]]</b>
-
-The first check line matches a regex (<tt>%[a-z]+</tt>) and captures it into
-the variables "REGISTER".  The second line verifies that whatever is in REGISTER
-occurs later in the file after an "andw".  FileCheck variable references are
-always contained in <tt>[[ ]]</tt> pairs, are named, and their names can be
-formed with the regex "<tt>[a-zA-Z_][a-zA-Z0-9_]*</tt>".  If a colon follows the
-name, then it is a definition of the variable, if not, it is a use.
-
-FileCheck variables can be defined multiple times, and uses always get the
-latest value.  Note that variables are all read at the start of a "CHECK" line
-and are all defined at the end.  This means that if you have something like
-"<tt>CHECK: [[XYZ:.*]]x[[XYZ]]<tt>" that the check line will read the previous
-value of the XYZ variable and define a new one after the match is performed.  If
-you need to do something like this you can probably take advantage of the fact
-that FileCheck is not actually line-oriented when it matches, this allows you to
-define two separate CHECK lines that match on the same line.
-
-
-
-=head1 AUTHORS
-
-Maintained by The LLVM Team (L<http://llvm.org>).
-
-=cut
diff --git a/docs/CommandGuide/Makefile b/docs/CommandGuide/Makefile
deleted file mode 100644
index 2c2d0760e7..0000000000
--- a/docs/CommandGuide/Makefile
+++ /dev/null
@@ -1,103 +0,0 @@
-##===- docs/CommandGuide/Makefile --------------------------*- Makefile -*-===##
-# 
-#                     The LLVM Compiler Infrastructure
-#
-# This file is distributed under the University of Illinois Open Source
-# License. See LICENSE.TXT for details.
-# 
-##===----------------------------------------------------------------------===##
-
-ifdef BUILD_FOR_WEBSITE
-# This special case is for keeping the CommandGuide on the LLVM web site
-# up to date automatically as the documents are checked in. It must build
-# the POD files to HTML only and keep them in the src directories. It must also
-# build in an unconfigured tree, hence the ifdef. To use this, run
-# make -s BUILD_FOR_WEBSITE=1 inside the cvs commit script.
-SRC_DOC_DIR=
-DST_HTML_DIR=html/
-DST_MAN_DIR=man/man1/
-DST_PS_DIR=ps/
-
-# If we are in BUILD_FOR_WEBSITE mode, default to the all target.
-all:: html man ps
-
-clean:
-	rm -f pod2htm*.*~~ $(HTML) $(MAN) $(PS)
-
-# To create other directories, as needed, and timestamp their creation
-%/.dir:
-	-mkdir $* > /dev/null
-	date > $@
-
-else
-
-# Otherwise, if not in BUILD_FOR_WEBSITE mode, use the project info.
-LEVEL := ../..
-include $(LEVEL)/Makefile.common
-
-SRC_DOC_DIR=$(PROJ_SRC_DIR)/
-DST_HTML_DIR=$(PROJ_OBJ_DIR)/
-DST_MAN_DIR=$(PROJ_OBJ_DIR)/
-DST_PS_DIR=$(PROJ_OBJ_DIR)/
-
-endif
-
-
-POD  := $(wildcard $(SRC_DOC_DIR)*.pod)
-HTML := $(patsubst $(SRC_DOC_DIR)%.pod, $(DST_HTML_DIR)%.html, $(POD))
-MAN  := $(patsubst $(SRC_DOC_DIR)%.pod, $(DST_MAN_DIR)%.1, $(POD))
-PS   := $(patsubst $(SRC_DOC_DIR)%.pod, $(DST_PS_DIR)%.ps, $(POD))
-
-# The set of man pages we will not install
-NO_INSTALL_MANS = $(DST_MAN_DIR)FileCheck.1
-
-# The set of man pages that we will install
-INSTALL_MANS = $(filter-out $(NO_INSTALL_MANS), $(MAN))
-
-.SUFFIXES:
-.SUFFIXES: .html .pod .1 .ps
-
-$(DST_HTML_DIR)%.html: %.pod $(DST_HTML_DIR)/.dir
-	pod2html --css=manpage.css --htmlroot=. \
-	  --podpath=. --noindex --infile=$< --outfile=$@ --title=$*
-
-$(DST_MAN_DIR)%.1: %.pod $(DST_MAN_DIR)/.dir
-	pod2man --release=CVS --center="LLVM Command Guide" $< $@
-
-$(DST_PS_DIR)%.ps: $(DST_MAN_DIR)%.1 $(DST_PS_DIR)/.dir
-	groff -Tps -man $< > $@
-
-
-html: $(HTML)
-man: $(MAN)
-ps: $(PS)
-
-EXTRA_DIST := $(POD) index.html
-
-clean-local::
-	$(Verb) $(RM) -f pod2htm*.*~~ $(HTML) $(MAN) $(PS)
-
-HTML_DIR := $(DESTDIR)$(PROJ_docsdir)/html/CommandGuide
-MAN_DIR  := $(DESTDIR)$(PROJ_mandir)/man1
-PS_DIR   := $(DESTDIR)$(PROJ_docsdir)/ps
-
-install-local:: $(HTML) $(INSTALL_MANS) $(PS)
-	$(Echo) Installing HTML CommandGuide Documentation
-	$(Verb) $(MKDIR) $(HTML_DIR)
-	$(Verb) $(DataInstall) $(HTML) $(HTML_DIR)
-	$(Verb) $(DataInstall) $(PROJ_SRC_DIR)/index.html $(HTML_DIR)
-	$(Verb) $(DataInstall) $(PROJ_SRC_DIR)/manpage.css $(HTML_DIR)
-	$(Echo) Installing MAN CommandGuide Documentation
-	$(Verb) $(MKDIR) $(MAN_DIR)
-	$(Verb) $(DataInstall) $(INSTALL_MANS) $(MAN_DIR)
-	$(Echo) Installing PS CommandGuide Documentation
-	$(Verb) $(MKDIR) $(PS_DIR)
-	$(Verb) $(DataInstall) $(PS) $(PS_DIR)
-
-uninstall-local::
-	$(Echo) Uninstalling CommandGuide Documentation
-	$(Verb) $(RM) -rf $(HTML_DIR) $(MAN_DIR) $(PS_DIR)
-
-printvars::
-	$(Echo) "POD            : " '$(POD)'
-	$(Echo) "HTML           : " '$(HTML)'
diff --git a/docs/CommandGuide/bugpoint.pod b/docs/CommandGuide/bugpoint.pod
deleted file mode 100644
index 7afeea1aba..0000000000
--- a/docs/CommandGuide/bugpoint.pod
+++ /dev/null
@@ -1,167 +0,0 @@
-=pod
-
-=head1 NAME
-
-bugpoint - automatic test case reduction tool
-
-=head1 SYNOPSIS
-
-B<bugpoint> [I<options>] [I<input LLVM ll/bc files>] [I<LLVM passes>] B<--args>
-I<program arguments>
-
-=head1 DESCRIPTION
-
-B<bugpoint> narrows down the source of problems in LLVM tools and passes.  It
-can be used to debug three types of failures: optimizer crashes, miscompilations
-by optimizers, or bad native code generation (including problems in the static
-and JIT compilers).  It aims to reduce large test cases to small, useful ones.
-For more information on the design and inner workings of B<bugpoint>, as well as
-advice for using bugpoint, see F<llvm/docs/Bugpoint.html> in the LLVM
-distribution.
-
-=head1 OPTIONS
-
-=over 
-
-=item B<--additional-so> F<library>
-
-Load the dynamic shared object F<library> into the test program whenever it is
-run.  This is useful if you are debugging programs which depend on non-LLVM
-libraries (such as the X or curses libraries) to run.
-
-=item B<--append-exit-code>=I<{true,false}>
-
-Append the test programs exit code to the output file so that a change in exit
-code is considered a test failure. Defaults to false.
-
-=item B<--args> I<program args>
-
-Pass all arguments specified after -args to the test program whenever it runs.
-Note that if any of the I<program args> start with a '-', you should use:
-
-    bugpoint [bugpoint args] --args -- [program args]
-
-The "--" right after the B<--args> option tells B<bugpoint> to consider any
-options starting with C<-> to be part of the B<--args> option, not as options to
-B<bugpoint> itself.
-
-=item B<--tool-args> I<tool args>
-
-Pass all arguments specified after --tool-args to the LLVM tool under test
-(B<llc>, B<lli>, etc.) whenever it runs.  You should use this option in the
-following way:
-
-    bugpoint [bugpoint args] --tool-args -- [tool args]
-
-The "--" right after the B<--tool-args> option tells B<bugpoint> to consider any
-options starting with C<-> to be part of the B<--tool-args> option, not as
-options to B<bugpoint> itself. (See B<--args>, above.)
-
-=item B<--safe-tool-args> I<tool args>
-
-Pass all arguments specified after B<--safe-tool-args> to the "safe" execution
-tool.
-
-=item B<--gcc-tool-args> I<gcc tool args>
-
-Pass all arguments specified after B<--gcc-tool-args> to the invocation of
-B<gcc>.
-
-=item B<--disable-{dce,simplifycfg}>
-
-Do not run the specified passes to clean up and reduce the size of the test
-program. By default, B<bugpoint> uses these passes internally when attempting to
-reduce test programs.  If you're trying to find a bug in one of these passes,
-B<bugpoint> may crash.
-
-=item B<--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
-until a bug is found or the user kills B<bugpoint>. 
-
-=item B<-help>
-
-Print a summary of command line options.
-
-=item B<--input> F<filename>
-
-Open F<filename> and redirect the standard input of the test program, whenever
-it runs, to come from that file.
-
-=item B<--load> F<plugin>
-
-Load the dynamic object F<plugin> into B<bugpoint> itself.  This object should
-register new optimization passes.  Once loaded, the object will add new command
-line options to enable various optimizations.  To see the new complete list of
-optimizations, use the B<-help> and B<--load> options together; for example:
-
-    bugpoint --load myNewPass.so -help
-
-=item B<--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
-should match the contents of F<filename> (the "reference output"). If you
-do not use this option, B<bugpoint> will attempt to generate a reference output
-by compiling the program with the "safe" backend and running it.
-
-=item B<--profile-info-file> F<filename>
-
-Profile file loaded by B<--profile-loader>.
-
-=item B<--run-{int,jit,llc,cbe,custom}>
-
-Whenever the test program is compiled, B<bugpoint> should generate code for it
-using the specified code generator.  These options allow you to choose the
-interpreter, the JIT compiler, the static native code compiler, the C
-backend, or a custom command (see B<--exec-command>) respectively.
-
-=item B<--safe-{llc,cbe,custom}>
-
-When debugging a code generator, B<bugpoint> should use the specified code
-generator as the "safe" code generator. This is a known-good code generator
-used to generate the "reference output" if it has not been provided, and to
-compile portions of the program that as they are excluded from the testcase.
-These options allow you to choose the
-static native code compiler, the C backend, or a custom command,
-(see B<--exec-command>) respectively. The interpreter and the JIT backends
-cannot currently be used as the "safe" backends.
-
-=item B<--exec-command> I<command>
-
-This option defines the command to use with the B<--run-custom> and
-B<--safe-custom> options to execute the bitcode testcase. This can
-be useful for cross-compilation.
-
-=item B<--safe-path> I<path>
-
-This option defines the path to the command to execute with the
-B<--safe-{int,jit,llc,cbe,custom}>
-option.
-
-=back
-
-=head1 EXIT STATUS
-
-If B<bugpoint> succeeds in finding a problem, it will exit with 0.  Otherwise,
-if an error occurs, it will exit with a non-zero value.
-
-=head1 SEE ALSO
-
-L<opt|opt>
-
-=head1 AUTHOR
-
-Maintained by the LLVM Team (L<http://llvm.org>).
-
-=cut
diff --git a/docs/CommandGuide/html/manpage.css b/docs/CommandGuide/html/manpage.css
deleted file mode 100644
index b200343490..0000000000
--- a/docs/CommandGuide/html/manpage.css
+++ /dev/null
@@ -1,256 +0,0 @@
-/* Based on http://www.perldoc.com/css/perldoc.css */
-
-@import url("../llvm.css");
-
-body { font-family: Arial,Helvetica; }
-
-blockquote { margin: 10pt;  }
-
-h1, a { color: #336699; }
-
-
-/*** Top menu style ****/
-.mmenuon { 
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #ff6600; font-size: 10pt;
- }
-.mmenuoff { 
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #ffffff; font-size: 10pt;
-}	  
-.cpyright {
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #ffffff; font-size: xx-small;
-}
-.cpyrightText {
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #ffffff; font-size: xx-small;
-}
-.sections { 
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #336699; font-size: 11pt;
-}	 
-.dsections { 
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #336699; font-size: 12pt;
-}	
-.slink { 
- font-family: Arial,Helvetica; font-weight: normal; text-decoration: none;
- color: #000000; font-size: 9pt;
-}	 
-
-.slink2 { font-family: Arial,Helvetica; text-decoration: none; color: #336699; }	 
-
-.maintitle { 
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #336699; font-size: 18pt;
-}	 
-.dblArrow {
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #336699; font-size: small;
-}
-.menuSec {
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #336699; font-size: small;
-}
-
-.newstext {
- font-family: Arial,Helvetica; font-size: small;
-}
-
-.linkmenu {
- font-family: Arial,Helvetica; color: #000000; font-weight: bold;
- text-decoration: none;
-}
-
-P {
- font-family: Arial,Helvetica;
-}
-
-PRE {
-    font-size: 10pt;
-}
-.quote { 
- font-family: Times; text-decoration: none;
- color: #000000; font-size: 9pt; font-style: italic;
-}	
-.smstd { font-family: Arial,Helvetica; color: #000000; font-size: x-small; } 
-.std { font-family: Arial,Helvetica; color: #000000; } 
-.meerkatTitle { 
- font-family: sans-serif; font-size: x-small;  color: black;    }
-
-.meerkatDescription { font-family: sans-serif; font-size: 10pt; color: black }
-.meerkatCategory { 
- font-family: sans-serif; font-size: 9pt; font-weight: bold; font-style: italic; 
- color: brown; }
-.meerkatChannel { 
- font-family: sans-serif; font-size: 9pt; font-style: italic; color: brown; }
-.meerkatDate { font-family: sans-serif; font-size: xx-small; color: #336699; }
-
-.tocTitle {
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #333333; font-size: 10pt;
-}
-
-.toc-item {
- font-family: Arial,Helvetica; font-weight: bold; 
- color: #336699; font-size: 10pt; text-decoration: underline;
-}
-
-.perlVersion {
- font-family: Arial,Helvetica; font-weight: bold; 
- color: #336699; font-size: 10pt; text-decoration: none;
-}
-
-.podTitle {
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #000000;
-}
-
-.docTitle {
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #000000; font-size: 10pt;
-}
-.dotDot {
- font-family: Arial,Helvetica; font-weight: bold; 
- color: #000000; font-size: 9pt;
-}
-
-.docSec {
- font-family: Arial,Helvetica; font-weight: normal; 
- color: #333333; font-size: 9pt;
-}
-.docVersion {
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #336699; font-size: 10pt;
-}
-
-.docSecs-on {
- font-family: Arial,Helvetica; font-weight: normal; text-decoration: none;
- color: #ff0000; font-size: 10pt;
-}
-.docSecs-off {
- font-family: Arial,Helvetica; font-weight: normal; text-decoration: none;
- color: #333333; font-size: 10pt;
-}
-
-h2 {
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #336699; font-size: medium;
-}
-h1 {
- font-family: Verdana,Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #336699; font-size: large;
-}
-
-DL {
- font-family: Arial,Helvetica; font-weight: normal; text-decoration: none;
- color: #333333; font-size: 10pt;
-}
-
-UL > LI > A {
- font-family: Arial,Helvetica; font-weight: bold;
- color: #336699; font-size: 10pt;
-}
-
-.moduleInfo {
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #333333; font-size: 11pt;
-}
-
-.moduleInfoSec {
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
- color: #336699; font-size: 10pt;
-}
-
-.moduleInfoVal {
- font-family: Arial,Helvetica; font-weight: normal; text-decoration: underline;
- color: #000000; font-size: 10pt;
-}
-
-.cpanNavTitle {
- font-family: Arial,Helvetica; font-weight: bold; 
- color: #ffffff; font-size: 10pt;
-}
-.cpanNavLetter {
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; 
- color: #333333; font-size: 9pt;
-}
-.cpanCat {
- font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; 
- color: #336699; font-size: 9pt;
-}
-
-.bttndrkblue-bkgd-top {
-	background-color: #225688;
-	background-image: url(/global/mvc_objects/images/bttndrkblue_bgtop.gif);
-}
-.bttndrkblue-bkgd-left {
-	background-color: #225688;
-	background-image: url(/global/mvc_objects/images/bttndrkblue_bgleft.gif);
-}
-.bttndrkblue-bkgd {
-	padding-top: 0px;
-	padding-bottom: 0px;
-	margin-bottom: 0px;
-	margin-top: 0px;
-	background-repeat: no-repeat;
-	background-color: #225688;
-	background-image: url(/global/mvc_objects/images/bttndrkblue_bgmiddle.gif);
-	vertical-align: top;
-}
-.bttndrkblue-bkgd-right {
-	background-color: #225688;
-	background-image: url(/global/mvc_objects/images/bttndrkblue_bgright.gif);
-}
-.bttndrkblue-bkgd-bottom {
-	background-color: #225688;
-	background-image: url(/global/mvc_objects/images/bttndrkblue_bgbottom.gif);
-}
-.bttndrkblue-text a {
-	color: #ffffff;
-	text-decoration: none;
-}
-a.bttndrkblue-text:hover {
-	color: #ffDD3C;
-	text-decoration: none;
-}
-.bg-ltblue {
-	background-color: #f0f5fa;
-} 
-
-.border-left-b {
-	background: #f0f5fa url(/i/corner-leftline.gif) repeat-y;
-} 
-
-.border-right-b {
-	background: #f0f5fa url(/i/corner-rightline.gif) repeat-y;
-} 
-
-.border-top-b {
-	background: #f0f5fa url(/i/corner-topline.gif) repeat-x;
-} 
-
-.border-bottom-b {
-	background: #f0f5fa url(/i/corner-botline.gif) repeat-x;
-} 
-
-.border-right-w {
-	background: #ffffff url(/i/corner-rightline.gif) repeat-y;
-} 
-
-.border-top-w {
-	background: #ffffff url(/i/corner-topline.gif) repeat-x;
-} 
-
-.border-bottom-w {
-	background: #ffffff url(/i/corner-botline.gif) repeat-x;
-} 
-
-.bg-white {
-	background-color: #ffffff;
-} 
-
-.border-left-w {
-	background: #ffffff url(/i/corner-leftline.gif) repeat-y;
-} 
diff --git a/docs/CommandGuide/index.html b/docs/CommandGuide/index.html
deleted file mode 100644
index 72cd2cf5f9..0000000000
--- a/docs/CommandGuide/index.html
+++ /dev/null
@@ -1,155 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
-                      "http://www.w3.org/TR/html4/strict.dtd">
-<html>
-<head>
-  <title>LLVM Command Guide</title>
-  <link rel="stylesheet" href="/docs/llvm.css" type="text/css">
-</head>
-<body>
-
-<div class="doc_title">
-  LLVM Command Guide
-</div>
-
-<div class="doc_text">
-
-<p>These documents are HTML versions of the <a href="man/man1/">man pages</