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

1 files changed, 0 insertions, 63 deletions

diff --git a/docs/HistoricalNotes/2001-06-01-GCCOptimizations.txt b/docs/HistoricalNotes/2001-06-01-GCCOptimizations.txt
deleted file mode 100644
index 97af16a2da..0000000000
--- a/docs/HistoricalNotes/2001-06-01-GCCOptimizations.txt
+++ /dev/null
@@ -1,63 +0,0 @@
-Date: Fri, 1 Jun 2001 16:38:17 -0500 (CDT)
-From: Chris Lattner <sabre@nondot.org>
-To: Vikram S. Adve <vadve@cs.uiuc.edu>
-Subject: Interesting: GCC passes
-
-
-Take a look at this document (which describes the order of optimizations
-that GCC performs):
-
-http://gcc.gnu.org/onlinedocs/gcc_17.html
-
-The rundown is that after RTL generation, the following happens:
-
-1 . [t] jump optimization (jumps to jumps, etc)
-2 . [t] Delete unreachable code
-3 .     Compute live ranges for CSE
-4 . [t] Jump threading (jumps to jumps with identical or inverse conditions)
-5 . [t] CSE
-6 . *** Conversion to SSA 
-7 . [t] SSA Based DCE
-8 . *** Conversion to LLVM
-9 .     UnSSA
-10.     GCSE
-11.     LICM
-12.     Strength Reduction
-13.     Loop unrolling
-14. [t] CSE
-15. [t] DCE
-16.     Instruction combination, register movement, scheduling... etc.
-
-I've marked optimizations with a [t] to indicate things that I believe to
-be relatively trivial to implement in LLVM itself.  The time consuming
-things to reimplement would be SSA based PRE, Strength reduction & loop
-unrolling... these would be the major things we would miss out on if we
-did LLVM creation from tree code [inlining and other high level
-optimizations are done on the tree representation].
-
-Given the lack of "strong" optimizations that would take a long time to
-reimplement, I am leaning a bit more towards creating LLVM from the tree
-code.  Especially given that SGI has GPL'd their compiler, including many
-SSA based optimizations that could be adapted (besides the fact that their
-code looks MUCH nicer than GCC :)
-
-Even if we choose to do LLVM code emission from RTL, we will almost
-certainly want to move LLVM emission from step 8 down until at least CSE
-has been rerun... which causes me to wonder if the SSA generation code
-will still work (due to global variable dependencies and stuff).  I assume
-that it can be made to work, but might be a little more involved than we
-would like.
-
-I'm continuing to look at the Tree -> RTL code.  It is pretty gross
-because they do some of the translation a statement at a time, and some
-of it a function at a time...  I'm not quite clear why and how the
-distinction is drawn, but it does not appear that there is a wonderful
-place to attach extra info.
-
-Anyways, I'm proceeding with the RTL -> LLVM conversion phase for now.  We
-can talk about this more on Monday.
-
-Wouldn't it be nice if there were a obvious decision to be made?  :)
-
--Chris
-