[LLVMdev] x86 unwind support[MESSAGE NOT SCANNED]

Mark Shannon marks at dcs.gla.ac.uk
Mon Jul 20 06:10:39 PDT 2009


Nick Johnson wrote:
>> In languages without stack-allocated objects (ie. most languages that
>> support exceptions) there is no need to unwind frame-by-frame, the
>> unwind simply needs to make a single jump to the invoke instruction and
>> restore the context (which in x86 is just 6 registers).
>>
> 
> No.  Java, C#, Ruby and Python all support the finally/ensure block;
> C# supports the using( IDisposable x =...) {} construct.  Both
> constructs require support for a frame-by-frame unwind; as these
> construct can be nested, a single throw may visit many landing pads
> (which may come from different compilation units).
> 
> It doesn't have anything to do with stack-allocated vs heap-allocated,
> but rather with the language's guarantees about exceptions.
> 
> 
>> It is possible to implement invoke/unwind in such a way that both invoke
>>  *and* unwind are fast, when  unwind just unwinds and doesn't perform
>> any magic behind-the-scenes operations.
>>
> 
> Why?  Exceptions are supposed to occur in exceptional situations.  In
> general, one should try to optimize for the common case, which does
> not include invoke/unwind.

I take it you have never used Python ;)
(Python uses exceptions to terminate loops, so it helps if they aren't 
too slow)

> 
> One should certainly not slow down a function call which never throws
> just because other functions may throw.  Paraphrasing Bjarne
> Stroustrup, "If you don't use it, you shouldn't pay for it."
>
And to quote Tim Peters (about Python)
"If the implementation is hard to explain, it's a bad idea."

Please try and get out of the C++ mindset, llvm may be implemented *in* 
C++, but its not implemented just *for* C++ (at least I hope it isn't).

Mark.
> 
> Nick
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 




More information about the llvm-dev mailing list