Re: Register allocation in special circumstancies

torbenm@diku.dk (Torben AEgidius Mogensen) writes:


>"Andrey S. Bokhanko" <ruff@mcst.ru> writes:
>
>>As we all know, C language has nasty (for compiler developers)
>>feature: setjmp/longjmp.
...
>The simplest thing would be to wrap every setjmp inside a function,
>which isn't inlined. This way, it won't affect the register allocation
>of the function that uses setjmp. And inside the new function you have
>a well-defined register state defined by the calling convention, which
>makes saving the state fairly simple.


I used a similar technique in the Mercury compiler, which *generates*
C code that uses setjmp(). Putting each statement using setjmp() in
its own C function means that the Mercury compiler doesn't need to
declare any of the local variables in the generated C code as
`volatile', which makes things much easier.


Note however that when generating C code, you can't wrap just the
setjmp() in a function, because that function will have exited by the
time longjmp() is called; the technique you described requires
setjmp() to save the caller's stack frame (in particular the return
address), and longjmp() to restore it, but when generating C code you
don't have control over the setjmp() and longjmp() implementations, so
you can't rely on that.


For the Mercury compiler, we only generate calls to setjmp()
in certain stylized ways, in particular only in the form
`if (setjmp(buf)) { ... code which may call longjmp(buf, 1) ... }',
where there are no calls to `longjmp(buf, ...)' from outside of
the `if' statement. So we wrap the whole if-then-else in a
function. If the body of the if-then-else contains references
to local variables or parameters of the containing function,
then we arrange for those to be passed by reference to the
wrapper function.


--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
                                                                        | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.

Return to the comp.compilers page.
Search the comp.compilers archives again.