sibcall.c

[Robert Stone <talby at trap dot mtview dot ca dot us>]

Hi,
	I'm not sure how to find out who to ask about recent developments
in sibcall.c.  There is one improvement I would like to see happen, or
figure out how to add related to tail call elimination.
	I am working with gcc-3.2 (GCC) 3.2.1 20020924 (Debian prerelease)
compiling for an i386 target arch.  I suspect the problem I'm having is not
an arch specific one.
	I'm pretty sure that tail call elimination could be more aggressive
with function pointers.  The sample code below eliminates the tail call in
tail1(), but not the tail call in tail2().  It does do constant propagation
on tail2() so that the fn variable is never allocated and the compiler
generates the asm "call addfifteen", but the extra step of moving that to a
"jmp addfifteen" after the frame is released never occurs.

#include <stdio.h>

int addfifteen(int arg) {
    return 15 + arg;
}

int tail1(int arg) {
    return addfifteen(arg);
}

int tail2(int arg) {
    int (*fn)(int) = addfifteen;
    return fn(arg);
}

int main(int ac, char *av[]) {
    printf("%d\n%d\n", tail1(5), tail2(12));
    return 0;
}

	Now this example is pretty contrived to simplify exposing the
problem, but what really got me started in this is that I frequently add
function pointers to my structures when I need some cheap OO abstraction
without moving the entire thing into c++ or Java.  So idioms such as:

char *toString(OBJ obj) {
    return obj->toString(obj);
}

are pretty common in my code and I suspect are common with other users as
well.  It would be nice if the general toString() could be implemented as a
small sibcall along the lines of:

toString:
	mov	4(%ebp), %eax	# eax = arg0
	mov	4(%eax), %eax	# eax = arg0->toString
	jmp	*%eax		# sibcall arg0->toString()

	Now I've applied more optimizations to this asm than I really would
want to see out of gcc today (though someday this would be nice).  My main
concern today is just that it seems like sibcall.c should be considering
function pointers as eligible for sibcalls as well as functions.  Is there
there a known problem that makes this generalization very difficult?

						Thanks,
						Robert

P.S.	I'm not subscribed to the gcc mailing list, so CC to me or I won't
	catch your reply until it hits the list archives.