What? Yet another EH proposal?! This one is different from the others in that
I’m planning to start implementing this shortly. But I want your feedback! I’ve
all ready gotten a lot of feedback from Chris, John, Jim, Eric, and many others.
Now is your turn!
Please read this proposal and send me your comments, suggestions, and concerns.
it is good to see that the “exception regions” idea has been abandoned, it is mathematically
inconsistent with modern optimization theory, and at best would require extra passes to translate
into/outof that representation form.
it is good to see the prohibition of mixing by inlining of exception handing from different languages,
it has always been my thought that this cannot be well defined in general, different languages not
only have different control-flow semantics for exception handling, but the different type systems
(what is a derived type and what constitutes “type match” for exceptions) are not always going to be
the other non-cosmetic portion of this proposal boils down to:
a) every invoke must point to a landingpad-block
b) every landingpad-block must start with a catch specification (LandingpadInst)
c) catch specifications (LandingpadInst) must not occur anywhere else
don’t take “cosmetic” as a criticism, I think gcc suffers from bad cosmetics, and llvm benefits
from good cosmetics. The logic I see is that we already have PHINode and TerminateInst
that have explicit restrictions, so it makes sense that if catch-specifications have restrictions
they too should be Instructions rather than Intrinsics.
3.b) I have been thinking about other possible control-flow-graph invariants of the
landingpad blocks and the catch blocks that they lead to, but so far have not come up
with very muchl, I wonder if anyone else is thinking about this…?..
for example cleanups come before __cxa_begin_catch, but it isn’t clear what is a cleanup
and what isn’t other than what comes before a __cxa_begin_catch and what comes after ?
however, using that as the definition of cleanup, for C++ any InvokeInst that is so
identified as cleanup then its only operand has to be terminate (I think, someone
please correct me if I’ve made an incorrect conclusion here).
3.c) I have been thinking about whether the original source code structure of try-catch
statements can be reconstructed from the IR, are two try-catches nested, either in the
try or the catch part, or are they disjoint, and can the cleanups be identified as such at
the IR level or have things potentially been mixmastered up too much after optimization.
I wonder if anyone else is thinking about this also…?..
- IIUC, llvm has inherited a bug from gcc where the debugger cannot let the user know an exception is
going to be uncaught until after the stack has been unwound – contrary to the design intentions of the
unwind library that most exception implementations are based on (with a two phase unwind algorithm) –
which creates a problem for the debugger user.
so, the question is will there be a specific recognizable “catch all types” type that can occur in the
landingpad’s catch list ?
and will there be a __llvm_personality_v0 that is designed to do the right thing for this case.
yes, I know this is a can-of-worms, it will break gcc compatibility, but then perhaps we can be the
motivation for gnu folks to fix their implementation, be the leader rather than the follower.!.
4.b) it is not at all clear from your write up what the “cleanup” option for a landingpad is, and
how this is used when both cleanups AND catches are necessary in a given try-catch source
code statement, including if one of the user specified catches is a catch-all.
- its not clear from your email what is done with the result value of the landingpad instruction,
but I presume that your intent is that this does not change from the current scheme where
the “llvm.eh.typeid.for()” is called and its result is compared with the landingpad instruction’s
…and then a miracle happens in CodeGen, and most of the intrinsics are thrown away and the
hard register contents at the resumption at a landingpad from an Unwind include the value that
llvm.eh.typeid.for() would have returned…
this is the sort of thing I’m talking about when I imply that the current scheme is poorly documented!
Also, what is going to happen for the case of cleanup AND catches, currently the result of not
only the llvm.eh.select() result is cached, but in fact the complete decoding of it relative to
all the llvm.eh.typeid.for() calls is cached, then the cleanup code executed, THEN finally the
already decoded value is used to “switch” from the landing pad to the correct catch-block.
who is going to generate all that code, is it still going to be explicit in the IR, or is CodeGen going
to now be responsible creating it.
it would be nice if the existing UnwindInst could be retained. I wince at naming an instruction
“Resume” since in the English language it is so ambiguous (resume normal execution following
the conclusion of handing an exception, verses resume throwing an exception). IE cosmetics
there are still lots of other intrinsics/routines involved:
although these particular ones seem to be the easiest to document as they do seem to be
translated verbatim (no CodeGen miracles).
I really like the idea of “terminate” being one of the options to the landingpad
instruction, it makes identification of abnormal code more direct (otherwise control-
flow analysis has to be done to see if __terminate() is reachable to conclude that
something is abnormal code, and I really don’t like that analysis, it seems too error-
prone as __terminate() might be reachable for other reasons (not that I have come
up with such a scenario yet, but I think I might be able to), and this conclusion would
then be ambiguous).
Even if support for the terminate option required a new __llvm_personality_v0 and
a new Unwind library function, I am still in favor of having and using it. But I suspect
that CodeGen can lower this into the same old MC branch to a block that only contains
__terminate() that we currently see in IR, and a new personality and Unwind
aren’t necessary, but would still be a nice optimization.