Overhauled llvm/clang docs builds. Closes PR6613.

[oota-llvm.git] / docs / HistoricalNotes / 2001-05-19-ExceptionResponse.txt

diff --git a/docs/HistoricalNotes/2001-05-19-ExceptionResponse.txt b/docs/HistoricalNotes/2001-05-19-ExceptionResponse.txt
deleted file mode 100644 (file)
index 3375365..0000000
--- a/docs/HistoricalNotes/2001-05-19-ExceptionResponse.txt
+++ /dev/null
@@ -1,45 +0,0 @@
-Date: Sat, 19 May 2001 19:09:13 -0500 (CDT)
-From: Chris Lattner <sabre@nondot.org>
-To: Vikram S. Adve <vadve@cs.uiuc.edu>
-Subject: RE: Meeting writeup
-
-> I read it through and it looks great!
-
-Thanks!
-
-> The finally clause in Java may need more thought.  The code for this clause
-> is like a subroutine because it needs to be entered from many points (end of
-> try block and beginning of each catch block), and then needs to *return to
-> the place from where the code was entered*.  That's why JVM has the
-> jsr/jsr_w instruction.
-
-Hrm... I guess that is an implementation decision.  It can either be
-modelled as a subroutine (as java bytecodes do), which is really
-gross... or it can be modelled as code duplication (emitted once inline,
-then once in the exception path).  Because this could, at worst,
-slightly less than double the amount of code in a function (it is
-bounded) I don't think this is a big deal.  One of the really nice things
-about the LLVM representation is that it still allows for runtime code
-generation for exception paths (exceptions paths are not compiled until
-needed).  Obviously a static compiler couldn't do this though.  :)
-
-In this case, only one copy of the code would be compiled... until the
-other one is needed on demand.  Also this strategy fits with the "zero
-cost" exception model... the standard case is not burdened with extra
-branches or "call"s.
-
-> I suppose you could save the return address in a particular register
-> (specific to this finally block), jump to the finally block, and then at the
-> end of the finally block, jump back indirectly through this register.  It
-> will complicate building the CFG but I suppose that can be handled.  It is
-> also unsafe in terms of checking where control returns (which is I suppose
-> why the JVM doesn't use this).
-
-I think that a code duplication method would be cleaner, and would avoid
-the caveats that you mention.  Also, it does not slow down the normal case
-with an indirect branch...
-
-Like everything, we can probably defer a final decision until later.  :)
-
--Chris
-