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

diff --git a/docs/ExtendedIntegerResults.txt b/docs/ExtendedIntegerResults.txt
deleted file mode 100644
index 44e9fbf0e7..0000000000
--- a/docs/ExtendedIntegerResults.txt
+++ /dev/null
@@ -1,133 +0,0 @@
-//===----------------------------------------------------------------------===//
-// Representing sign/zero extension of function results
-//===----------------------------------------------------------------------===//
-
-Mar 25, 2009  - Initial Revision
-
-Most ABIs specify that functions which return small integers do so in a
-specific integer GPR.  This is an efficient way to go, but raises the question:
-if the returned value is smaller than the register, what do the high bits hold?
-
-There are three (interesting) possible answers: undefined, zero extended, or
-sign extended.  The number of bits in question depends on the data-type that
-the front-end is referencing (typically i1/i8/i16/i32).
-
-Knowing the answer to this is important for two reasons: 1) we want to be able
-to implement the ABI correctly.  If we need to sign extend the result according
-to the ABI, we really really do need to do this to preserve correctness.  2)
-this information is often useful for optimization purposes, and we want the
-mid-level optimizers to be able to process this (e.g. eliminate redundant
-extensions).
-
-For example, lets pretend that X86 requires the caller to properly extend the
-result of a return (I'm not sure this is the case, but the argument doesn't
-depend on this).  Given this, we should compile this:
-
-int a();
-short b() { return a(); }
-
-into:
-
-_b:
-	subl	$12, %esp
-	call	L_a$stub
-	addl	$12, %esp
-	cwtl
-	ret
-
-An optimization example is that we should be able to eliminate the explicit
-sign extension in this example:
-
-short y();
-int z() {
-  return ((int)y() << 16) >> 16;
-}
-
-_z:
-	subl	$12, %esp
-	call	_y
-	;;  movswl %ax, %eax   -> not needed because eax is already sext'd
-	addl	$12, %esp
-	ret
-
-//===----------------------------------------------------------------------===//
-// What we have right now.
-//===----------------------------------------------------------------------===//
-
-Currently, these sorts of things are modelled by compiling a function to return
-the small type and a signext/zeroext marker is used.  For example, we compile
-Z into:
-
-define i32 @z() nounwind {
-entry:
-	%0 = tail call signext i16 (...)* @y() nounwind
-	%1 = sext i16 %0 to i32
-	ret i32 %1
-}
-
-and b into:
-
-define signext i16 @b() nounwind {
-entry:
-	%0 = tail call i32 (...)* @a() nounwind		; <i32> [#uses=1]
-	%retval12 = trunc i32 %0 to i16		; <i16> [#uses=1]
-	ret i16 %retval12
-}
-
-This has some problems: 1) the actual precise semantics are really poorly
-defined (see PR3779).  2) some targets might want the caller to extend, some
-might want the callee to extend 3) the mid-level optimizer doesn't know the
-size of the GPR, so it doesn't know that %0 is sign extended up to 32-bits 
-here, and even if it did, it could not eliminate the sext. 4) the code
-generator has historically assumed that the result is extended to i32, which is
-a problem on PIC16 (and is also probably wrong on alpha and other 64-bit
-targets).
-
-//===----------------------------------------------------------------------===//
-// The proposal
-//===----------------------------------------------------------------------===//
-
-I suggest that we have the front-end fully lower out the ABI issues here to
-LLVM IR.  This makes it 100% explicit what is going on and means that there is
-no cause for confusion.  For example, the cases above should compile into:
-
-define i32 @z() nounwind {
-entry:
-        %0 = tail call i32 (...)* @y() nounwind
-	%1 = trunc i32 %0 to i16
-        %2 = sext i16 %1 to i32
-        ret i32 %2
-}
-define i32 @b() nounwind {
-entry:
-	%0 = tail call i32 (...)* @a() nounwind
-	%retval12 = trunc i32 %0 to i16
-	%tmp = sext i16 %retval12 to i32
-	ret i32 %tmp
-}
-
-In this model, no functions will return an i1/i8/i16 (and on a x86-64 target
-that extends results to i64, no i32).  This solves the ambiguity issue, allows us 
-to fully describe all possible ABIs, and now allows the optimizers to reason
-about and eliminate these extensions.
-
-The one thing that is missing is the ability for the front-end and optimizer to
-specify/infer the guarantees provided by the ABI to allow other optimizations.
-For example, in the y/z case, since y is known to return a sign extended value,
-the trunc/sext in z should be eliminable.
-
-This can be done by introducing new sext/zext attributes which mean "I know
-that the result of the function is sign extended at least N bits.  Given this,
-and given that it is stuck on the y function, the mid-level optimizer could
-easily eliminate the extensions etc with existing functionality.
-
-The major disadvantage of doing this sort of thing is that it makes the ABI
-lowering stuff even more explicit in the front-end, and that we would like to
-eventually move to having the code generator do more of this work.  However,
-the sad truth of the matter is that this is a) unlikely to happen anytime in
-the near future, and b) this is no worse than we have now with the existing
-attributes.
-
-C compilers fundamentally have to reason about the target in many ways.  
-This is ugly and horrible, but a fact of life.
-