[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

[Duncan Sands]

Hi Bill,

>>>> This sounds very interesting.  Do you have a description of what you're angling for?  I'd really like to understand and digest the model before you write too much code.
>>
>> since Bill's proposal seemed way too complicated to me, I sent in an
>> alternative proposal shortly afterwards, here:
>>
>> http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-December/036731.html
>>
>> In particular it has a fairly detailed analysis of some of the existing
>> problems with LLVM exception handling.
>>
> I didn't comment too much on your idea because I think of the problem differently. To me the problem is systemic and not cosmetic. Your solution is cosmetic in nature, and still has the major problems of the current implementation.
>
> For instance in order to generate good EH tables (this is not to say that the EH code has to be DWARF-specific, but it does need to be rich enough to handling DWARF EH stuff), we need to know at two points in the code all of the information about the call that may throw: (1) at the point where the call is made, and (2) at the point where the decision to execute a catch or cleanup is made.

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!).

Ciao, Duncan.