[llvm-commits] [llvm] r129235 - in /llvm/trunk: include/llvm/BasicBlock.h include/llvm/Bitcode/LLVMBitCodes.h lib/AsmParser/LLLexer.cpp lib/AsmParser/LLParser.cpp lib/AsmParser/LLToken.h lib/Bitcode/Reader/BitcodeReader.cpp lib/Bitcode/Writer/BitcodeWriter.cpp lib/VMCore/AsmWriter.cpp lib/VMCore/BasicBlock.cpp test/Feature/bb_attrs.ll

Bill Wendling wendling at apple.com
Mon Apr 11 13:50:36 PDT 2011

On Apr 11, 2011, at 8:48 AM, Duncan Sands wrote:

> I disagree with the way you describe the issue in (2), though maybe I'm just
> nit picking.  There is an issue, but I would say that the issue is in getting
> the right exception value / selector value at the point where decisions about
> branching to catch clauses is made, and not one of knowing "all of the
> information about the call".  As you explain, at the moment when an exception
> results in control branching to a landing pad there is a value for the
> exception and selector (passed in registers), but the point where you make
> decisions about which catch to execute etc can be far away, with all kinds of
> other exceptions being thrown and caught before you get there.  This means that
> you are obliged to stash the exception/selector values away somewhere so that
> you can get hold of them again later.  I didn't discuss this point much in my
> proposal since it can be solved using intrinsics (ie with no IR changes).  I
> agree that the intrinsics approach is rather ugly and something of a hack, but
> since it would solve the problem I find it hard to get excited about it: point
> (1) seems much more serious to me.
> In short, I would say that my proposal has all the minor problems of the current
> implementation, but not the major problem :)
> I think the best way to proceed is not to discuss solutions/proposals etc for
> the moment, but instead to clearly define what is wrong with the current eh
> scheme.  In the next day or so I plan to post an email describing and
> analysing all the problems with the current scheme (this may take me a while
> since there are a lot of them!).
Hi Duncan,

Fair enough, I'll write up what I think are the problems with the current implementation. To be honest, This topic has been debated a lot in the past few years. There may not be a whole lot of information left to squeeze from the proverbial turnip. :-) I'm highly motivated to fix/rewrite exception handling because of the number of problems (reported both internally and externally) that crop up due to our current implementation.


More information about the llvm-commits mailing list