On Tue, Mar 03, 2015 at 10:50:03AM -0600, Hal Finkel wrote: > > Actually, it is a bit more complicated. A good setjmp/longjmp > > implementation in libc saves exactly the same set of registers. The > > only > > reason the GCC implementation can be better is that it forces > > register > > spilling to fixed locations and makes longjmp depend on that. > > No, this is not quite right. __builtin_setjmp can save many fewer > registers than setjmp, because it does not need to save registers that > don't need to be restored at that particular call site (the function > might not be using all available registers). Furthermore, those saves, > and the restores, can be scheduled to hide their latency (not all > clumped together in the longjmp implementation).
I think that's overly optimistic. I believe neither GCC nor Clang do CFG analysis between __builtin_setjmp and __builtin_longjmp. As such, __builtin_setjmp has to assume that all callee-saved registers will be clobbered and __builtin_longjmp has to assume they all have been clobbered. The optimisation potential for __builtin_setjmp is therefore to avoid saving a register that has been spilled already. Functions involving setjmp rarely are complex, so that potential is small. Now for __builtin_longjmp, the question is more interesting. If it does use EH logic with a landing pad, it can leave most of the reloading to the __builtin_setjmp recovery side. This makes for a much more complex logic in the backend as I mentioned earlier. The other option is to essentially implement the same logic as longjmp with some scheduling potential. That __builting_longjmp part is where the real potential is. Joerg _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
