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, 71 deletions

diff --git a/docs/HistoricalNotes/2001-06-01-GCCOptimizations2.txt b/docs/HistoricalNotes/2001-06-01-GCCOptimizations2.txt
deleted file mode 100644
index 6c9e0971a0..0000000000
--- a/docs/HistoricalNotes/2001-06-01-GCCOptimizations2.txt
+++ /dev/null
@@ -1,71 +0,0 @@
-Date: Fri, 1 Jun 2001 17:08:44 -0500 (CDT)
-From: Chris Lattner <sabre@nondot.org>
-To: Vikram S. Adve <vadve@cs.uiuc.edu>
-Subject: RE: Interesting: GCC passes
-
-> That is very interesting.  I agree that some of these could be done on LLVM
-> at link-time, but it is the extra time required that concerns me.  Link-time
-> optimization is severely time-constrained.
-
-If we were to reimplement any of these optimizations, I assume that we
-could do them a translation unit at a time, just as GCC does now.  This
-would lead to a pipeline like this:
-
-Static optimizations, xlation unit at a time:
-.c --GCC--> .llvm --llvmopt--> .llvm 
-
-Link time optimizations:
-.llvm --llvm-ld--> .llvm --llvm-link-opt--> .llvm 
-
-Of course, many optimizations could be shared between llvmopt and
-llvm-link-opt, but the wouldn't need to be shared...  Thus compile time
-could be faster, because we are using a "smarter" IR (SSA based).
-
-> BTW, about SGI, "borrowing" SSA-based optimizations from one compiler and
-> putting it into another is not necessarily easier than re-doing it.
-> Optimization code is usually heavily tied in to the specific IR they use.
-
-Understood.  The only reason that I brought this up is because SGI's IR is
-more similar to LLVM than it is different in many respects (SSA based,
-relatively low level, etc), and could be easily adapted.  Also their
-optimizations are written in C++ and are actually somewhat
-structured... of course it would be no walk in the park, but it would be
-much less time consuming to adapt, say, SSA-PRE than to rewrite it.
-
-> But your larger point is valid that adding SSA based optimizations is
-> feasible and should be fun.  (Again, link time cost is the issue.)
-
-Assuming linktime cost wasn't an issue, the question is: 
-Does using GCC's backend buy us anything?
-
-> It also occurs to me that GCC is probably doing quite a bit of back-end
-> optimization (step 16 in your list).  Do you have a breakdown of that?
-
-Not really.  The irritating part of GCC is that it mixes it all up and
-doesn't have a clean seperation of concerns.  A lot of the "back end
-optimization" happens right along with other data optimizations (ie, CSE
-of machine specific things).
-
-As far as REAL back end optimizations go, it looks something like this:
-
-1. Instruction combination: try to make CISCy instructions, if available
-2. Register movement: try to get registers in the right places for the
-architecture to avoid register to register moves.  For example, try to get
-the first argument of a function to naturally land in %o0 for sparc.
-3. Instruction scheduling: 'nuff said :)
-4. Register class preferencing: ??
-5. Local register allocation
-6. global register allocation
-7. Spilling
-8. Local regalloc
-9. Jump optimization
-10. Delay slot scheduling
-11. Branch shorting for CISC machines
-12. Instruction selection & peephole optimization
-13. Debug info output
-
-But none of this would be usable for LLVM anyways, unless we were using
-GCC as a static compiler.
-
--Chris
-