[LLVMdev] LLVMdev Digest, Vol 85, Issue 50

Wed Jul 27 10:27:37 PDT 2011

>
> 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.
>
> -bw
>

Bill,

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

2) 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
compatible.

3) 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...?...

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

5) 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
result...

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

6) 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
do matter.

7) there are still lots of other intrinsics/routines involved:
	__cxa_allocate_exception
	__cxa_throw,   cxa_rethrow
	__cxa_begin_catch(),    __cxa_end_catch
although these particular ones seem to be the easiest to document as  
they do seem to be
translated verbatim (no CodeGen miracles).

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

sincerely,
Peter Lawrence.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110727/e7a0f051/attachment.html>