[docs] Remove POD based man page docs (and build system support).

 - Currently this leaves us with less build system support (e.g., installing man pages) for the docs than is desired. I'm working on fixing this, but it may take a while. If someone finds this particularly egregious let me know and I will prioritize it.

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

25 files changed, 0 insertions, 3901 deletions

diff --git a/docs/CommandGuide/FileCheck.pod b/docs/CommandGuide/FileCheck.pod
deleted file mode 100644
index 2662cc0128..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,
-let's look at the rest of the .ll file (after the RUN line):
-
-  define void @sub1(i32* %p, i32 %v) {
-  entry:
-  ; CHECK: sub1:
-  ; CHECK: subl
-          %0 = tail call i32 @llvm.atomic.load.sub.i32.p0i32(i32* %p, i32 %v)
-          ret void
-  }
-  
-  define void @inc4(i64* %p) {
-  entry:
-  ; CHECK: inc4:
-  ; CHECK: incq
-          %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:              | FileCheck %s -check-prefix=X32>
-  ; RUN: llvm-as < %s | llc -mtriple=x86_64-apple-darwin9 -mattr=sse41 \
-  ; RUN:              | FileCheck %s -check-prefix=X64>
-
-  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
-  ; X32: pinsrd_1:
-  ; X32:    pinsrd $1, 4(%esp), %xmm0
-  
-  ; X64: pinsrd_1:
-  ; X64:    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 consecutive 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
-        
-  ; CHECK:          t2:
-  ; CHECK: 	        movl	8(%esp), %eax
-  ; CHECK-NEXT: 	movapd	(%eax), %xmm0
-  ; CHECK-NEXT: 	movhpd	12(%esp), %xmm0
-  ; CHECK-NEXT: 	movl	4(%esp), %eax
-  ; CHECK-NEXT: 	movapd	%xmm0, (%eax)
-  ; CHECK-NEXT: 	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 before the first match, or after the last match).  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
-  ; CHECK: @coerce_offset0
-  ; CHECK-NOT: load
-  ; CHECK: 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	{{[0-9]+}}(%esp), {{%xmm[0-7]}}
-
-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	[[REGISTER:%[a-z]+]]
-  ; CHECK:    andw	{{.*}}[REGISTER]]
-
-The first check line matches a regex (B<%[a-z]+>) and captures it into
-the variable "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 B<[[ ]]> pairs, are named, and their names can be
-formed with the regex "B<[a-zA-Z_][a-zA-Z0-9_]*>".  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
-"B<CHECK: [[XYZ:.*]]x[[XYZ]]>", 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 3f9f60b8e7..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 $(DST_MAN_DIR)llvm-build.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 f7a3ec7624..0000000000
--- a/docs/CommandGuide/bugpoint.pod
+++ /dev/null
@@ -1,186 +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<--opt-args> I<opt args>
-
-Pass all arguments specified after B<--opt-args> to the invocation of B<opt>.
-
-=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,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, or a
-custom command (see B<--exec-command>) respectively.
-
-=item B<--safe-{llc,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, 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<--compile-command> I<command>
-
-This option defines the command to use with the B<--compile-custom>
-option to compile the bitcode testcase. This can be useful for
-testing compiler output without running any link or execute stages. To
-generate a reduced unit test, you may add CHECK directives to the
-testcase and pass the name of an executable compile-command script in this form:
-
-    #!/bin/sh
-    llc "$@"
-    not FileCheck [bugpoint input file].ll < bugpoint-test-program.s
-
-This script will "fail" as long as FileCheck passes. So the result
-will be the minimum bitcode that passes FileCheck.
-
-=item B<--safe-path> I<path>
-
-This option defines the path to the command to execute with the
-B<--safe-{int,jit,llc,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 772a59f40e..0000000000
--- a/docs/CommandGuide/index.html
+++ /dev/null
@@ -1,139 +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="../llvm.css" type="text/css">
-</head>
-<body>
-
-<h1>
-  LLVM Command Guide
-</h1>
-
-<div>
-
-<p>These documents are HTML versions of the <a href="man/man1/">man pages</a>
-for all of the LLVM tools.  These pages describe how to use the LLVM commands
-and what their options are.  Note that these pages do not describe all of the
-options available for all tools.  To get a complete listing, pass the
-<tt>-help</tt> (general options) or <tt>-help-hidden</tt> (general+debugging
-options) arguments to the tool you are interested in.</p>
-
-</div>
-
-<!-- *********************************************************************** -->
-<h2>
-  <a name="basic">Basic Commands</a>
-</h2>
-<!-- *********************************************************************** -->
-
-<div>
-
-<ul>
-
-<li><a href="/cmds/llvm-as.html"><b>llvm-as</b></a> -
-    assemble a human-readable .ll file into bytecode</li>
-
-<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="/cmds/opt.html"><b>opt</b></a> -
-    run a series of LLVM-to-LLVM optimizations on a bytecode file</li>
-