> probably there should be a switch to choose whether codegen should turn > unwind/invoke into dwarf or setjmp/longjmp style code.There is, but it happens before codegen and is slow. -enable-correct-eh-support will translate invoke/unwind into setjmp/longjmp pairs for the correct behavior. See: http://llvm.org/docs/Passes.html#lowerinvoke Nick> > Ciao, > > Duncan. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- Nick Johnson
Nick Johnson wrote:>> probably there should be a switch to choose whether codegen should turn >> unwind/invoke into dwarf or setjmp/longjmp style code.It seems to me that there is an implicit, and undocumented, assumption that unwinding needs to handle stack-allocated objects. 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).> > There is, but it happens before codegen and is slow. > -enable-correct-eh-support will translate invoke/unwind into > setjmp/longjmp pairs for the correct behavior. See: > http://llvm.org/docs/Passes.html#lowerinvoke*Begin rant* 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. After all, isn't it the job of the front-end to insert all the clean-up code for stack-allocated objects? Java, C#, Python, and Ruby have destructors(finalizers), but they are managed by the garbage collector. C++ is the odd one out, so why do the semantics of an llvm instruction depend on C++ semantics? *End rant* ;) Mark.> > Nick > > > >> Ciao, >> >> Duncan. >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > >
Mark Shannon wrote:> Nick Johnson wrote: >>> probably there should be a switch to choose whether codegen should turn >>> unwind/invoke into dwarf or setjmp/longjmp style code. > > It seems to me that there is an implicit, and undocumented, assumption > that unwinding needs to handle stack-allocated objects. > > 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).Not quite. It's also necessary to execute all the pending POSIX pthread_cleanup_pop() actions.> 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.I don't think so. Not for pthreads, anyway. Andrew.
> 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. 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." Nick
On Mon, Jul 20, 2009 at 5:01 AM, Nick Johnson<nicholas.paul.johnson at gmail.com> wrote:>> probably there should be a switch to choose whether codegen should turn >> unwind/invoke into dwarf or setjmp/longjmp style code. > > There is, but it happens before codegen and is slow. > -enable-correct-eh-support will translate invoke/unwind into > setjmp/longjmp pairs for the correct behavior. See: > http://llvm.org/docs/Passes.html#lowerinvoke > > NickThat lowerinvoke pass does seem to have room for improvement, then.