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

diff --git a/docs/HistoricalNotes/2001-09-18-OptimizeExceptions.txt b/docs/HistoricalNotes/2001-09-18-OptimizeExceptions.txt
deleted file mode 100644
index 9379081018..0000000000
--- a/docs/HistoricalNotes/2001-09-18-OptimizeExceptions.txt
+++ /dev/null
@@ -1,56 +0,0 @@
-Date: Tue, 18 Sep 2001 00:38:37 -0500 (CDT)
-From: Chris Lattner <sabre@nondot.org>
-To: Vikram S. Adve <vadve@cs.uiuc.edu>
-Subject: Idea for a simple, useful link time optimization
-
-
-In C++ programs, exceptions suck, and here's why:
-
-1. In virtually all function calls, you must assume that the function
-   throws an exception, unless it is defined as 'nothrow'.  This means
-   that every function call has to have code to invoke dtors on objects
-   locally if one is thrown by the function.  Most functions don't throw
-   exceptions, so this code is dead [with all the bad effects of dead
-   code, including icache pollution].
-2. Declaring a function nothrow causes catch blocks to be added to every
-   call that isnot  provably nothrow.  This makes them very slow.
-3. Extra extraneous exception edges reduce the opportunity for code
-   motion.
-4. EH is typically implemented with large lookup tables.  Ours is going to
-   be much smaller (than the "standard" way of doing it) to start with,
-   but eliminating it entirely would be nice. :)
-5. It is physically impossible to correctly put (accurate, correct)
-   exception specifications on generic, templated code.  But it is trivial
-   to analyze instantiations of said code.
-6. Most large C++ programs throw few exceptions.  Most well designed
-   programs only throw exceptions in specific planned portions of the
-   code.
-
-Given our _planned_ model of handling exceptions, all of this would be
-pretty trivial to eliminate through some pretty simplistic interprocedural
-analysis.  The DCE factor alone could probably be pretty significant.  The
-extra code motion opportunities could also be exploited though...
-
-Additionally, this optimization can be implemented in a straight forward
-conservative manner, allowing libraries to be optimized or individual
-files even (if there are leaf functions visible in the translation unit
-that are called).
-
-I think it's a reasonable optimization that hasn't really been addressed
-(because assembly is way too low level for this), and could have decent
-payoffs... without being a overly complex optimization.
-
-After I wrote all of that, I found this page that is talking about
-basically the same thing I just wrote, except that it is translation unit
-at a time, tree based approach:
-http://www.ocston.org/~jls/ehopt.html
-
-but is very useful from "expected gain" and references perspective.  Note
-that their compiler is apparently unable to inline functions that use
-exceptions, so there numbers are pretty worthless... also our results
-would (hopefully) be better because it's interprocedural...
-
-What do you think?
-
--Chris
-