avoid unnecessary register saves for setjmp

[Zack Weinberg]

Chris Lattner <sabre@nondot.org> writes:

> On Thu, 27 Nov 2003, Zack Weinberg wrote:
>
>> >From a language-design perspective it's desirable for x to have the
>> value 23 in both fragments.  (Leaving out the volatile on x is
>> intentional.)  Its being undefined in C is a source of hard-to-find
>> bugs.  It happens because longjmp() can't know which registers need
>> restoring, whereas the EH unwinder does know and can get it
>> (abstractly) right.  So by using the EH unwinder for longjmp we clean
>> up a nasty dark corner of the language.
>
> Also, ideally, longjmp should run cleanups in intervening stackframes,
> which the LLVM implementation does, just like for pthreads cancellation.

Right.  (The IA64 psABI seems to anticipate that some people expect it
*not* to, by providing longjmp_unwind.)

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

No, no it isn't.

zw