Re: Register allocation in special circumstancies

Torben AEgidius Mogensen wrote (first quoting Bokhanko):


> ..., and hence we must take into account this
> >nasty feature of "setjmp" points. But how to do it?
>
> 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....


No. It doesn't help at all in a callee-saves situation. The problem is
that in


int f()
int var = 1;
...
if (setjmp(...)) { // or a wrapper for it!
...
// what's var now? Any of g, h, i
// might be the caller of longjmp
}
...
var = 2;
g();
var = 3;
h();
var = 4;
i();


any of g, h, or i (or their own descendants) may call longjmp. There
is absolutely nothing setjmp or its wrapper can know about the dynamic
value of var at the time that longjmp is called later, and deeper
down. When control finally returns to f(), unless f() itself has
stashed the dynamically current value of var before each call out, to
g, h, i, the value of a will be lost unless the wrapper is prepared to
do a highly compiler-dependent search through the stack for the place
where f's registers actually reside.


Saying (in C89 and C99)


volatile int var = 1;


is entended to encourage f to save var within itself before each call
out to make this work, and correspondingly to restore it at each
callee return. Putting the setjmp in a wrapper could frustrate this
attempt, if the compiler somehow keys on the presence of a call to
setjmp, and in any event doesn't help it.


The point is that the register state at the time of the call to setjmp
is not necessarily relevant, so the most assiduous saving of it
doesn't help.


[The situation is much more pleasant in a general caller-saves scheme,
where the setjmp/longjmp situation can often fit in with little
effort.]


Dennis

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