[LLVMdev] RFC: Exception Handling Proposal Revised

[Duncan Sands]

Hi Bill,

>> Why not combine this into:
>>
>> invoke void @_Z3foov()
>> to label %invcont unwind resume to label %...
>> catches [
>> %struct.__fundamental_type_info_pseudo* @_ZTIi, label %ch.int
>> %struct.__pointer_type_info_pseudo* @_ZTIPKc, label %ch.str
>> ]
>> catchall [i8* null, label % ch.ca <http://ch.ca>]
>>
>> ? That would get rid of the "landingpad" basic block attribute, and rules about
>> what can branch to landing pads, that these cannot be split etc. Your rules
>> mean that you can uniquely associate a dispatch instruction with each invoke
>> unwind edge, so why not directly attach the dispatch information to the edge,
>> i.e. to the invoke?
>>
> That was my first proposal (way back when). I ran into the problem of cleanups.
> Basically, they get in the way of the decision making process. Consider this:
>
> invoke void @_Z3foov()
> to label %invcont unwind resume to label %...
> catches [
> %struct.__fundamental_type_info_pseudo* @_ZTIi, label %ch.int
> %struct.__pointer_type_info_pseudo* @_ZTIPKc, label %ch.str
> ]
> catchall [i8* null, label % ch.ca <http://ch.ca>]
>
> Now consider that a cleanup must occur here. How do we represent this here and
> still keep the information that "int" goes to ch.int and "const char *" goes to
> ch.str? The cleanups must happen before we get to ch.int, ch.str, and ch.ca
> <http://ch.ca>. And cleanup code can be arbitrarily complex – including the fact
> that it may not return, or it may have multiple exit points. You end up needing
> a dispatch-like instruction at the end of the cleanup region so that you can
> associated the invoke to the decision point – the point where we determine which
> handler we need to execute. After we realized this, this proposal became the
> natural way.

thanks for the explanation.  I am writing up an alternative exception handling
proposal which does not suffer from this problem (at least I think it doesn't!).

>> As a general remark, I don't see how this is superior to gcc's region scheme,
>> which could be adapted to LLVM by (in essence) attaching to an invoke the list
>> of all regions (and their info like list of catches) that contain the invoke.
>> If you do that then you get something rather close to your proposal, only the
>> dispatch instructions have become part of the invokes, you don't need the funny
>> landing pad special semantics etc.
>>
> Could you describe GCC's region scheme?

My alternative proposal will describe the scheme you get if you do what the
above paragraph suggests.  I don't plan to explicitly describe gcc's nested
region scheme, but rest assured that in llvm-gcc it would be easy to
implement - in some ways easier than what we do now.

Ciao,

Duncan.