This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: avoid unnecessary register saves for setjmp
- From: Chris Lattner <sabre at nondot dot org>
- To: Jan Vroonhof <jvlists at ntlworld dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 27 Nov 2003 13:59:11 -0600 (CST)
- Subject: Re: avoid unnecessary register saves for setjmp
> >> To be fair, an argument against this change is that it would break
> >> code that uses setjmp and longjmp to implement coroutine linkage.
> >> (The set/get/make/swapcontext calls are better for this, but that
> >> doesn't mean everyone uses them.)
>
> Doesn't it also convert longjmp from an O(1) in to an O(nr off stack frames)
> operation?
Yes, if you use unwinding to implement it. You can obviously use SJLJ
to implement the exception runtime, retaining the same complexity. The
normal design decision is to favor non-exceptional control flow, even if
that means changing exception throws to take O(n). In practice, stack
unwinding is still very fast.
> > I don't believe that this is actually legal ANSI C. You can only return
> > to a place that has been setjmp'd to, there is no way to 'construct' a
> > jmpbuf. Likewise, you cannot setjmp, return from the setjmp'ing function,
> > then longjmp back to the 'dead' jmpbuf.
>
> It might not be ANSI C, but it does work on most systems for user
> level threading (essentially implementing swapcontext by direct
> manipulation of the jmbuf). There is lots of useful things people do
> with C that are not strictly ANSI/ISO C. In fact that kind of low
> level control is often exactly the reason to use C in the first place.
As Zach said, they should be using getcontext/swapcontext/makecontext.
jmpbuf's do not hold the entire register state for the processor.
-Chris
--
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/