Useless %esp manipulation; omitting "l" suffix in assembly output; getting the address of a label from another function.

Useless %esp manipulation; omitting "l" suffix in assembly output; getting the address of a label from another function.

[Mark J Roberts]

First, a trivial bug. Compile this with gcc cvs:

	struct x { int a, b, c, d; };

	struct x zook(void)
	{
		struct x x = {0, 1, 2, 3};
		return x;
	}

gcc -S -O2 -fomit-frame-pointer -march=athlon-xp test.c

	.file	"test.c"
	.text
	.p2align 4,,15
globl zook
	.type	zook, @function
zook:
	subl	$28, %esp
	movl	32(%esp), %eax
	movl	$0, (%eax)
	movl	$1, 4(%eax)
	movl	$2, 8(%eax)
	movl	$3, 12(%eax)
	addl	$28, %esp
	ret	$4
	.size	zook, .-zook
	.ident	"GCC: (GNU) 3.4 20030410 (experimental)"

and you get code that uselessly moves %esp.

I've got a couple feature requests too, take them or leave them.

1) Output "mov" instead of "movl", etc, since gas doesn't require
the suffix and it's easier to read the code when they are omitted.

2) Given code like

	void process(void *addr)
	{
		goto *addr;
	l1:
	l2:	something goes here
	l3:
	l4:
	}

where you're trying to optimize some code by saving the address of a
label and using it next time the function is called, provide some
way to get the address of the label from another function (useful
for initializing addr the first time). Ie,

	void setup(struct state *s)
	{
		s->addr = process.l1;
	}

or whatever.

Re: Useless %esp manipulation; omitting "l" suffix in assembly output; getting the address of a label from another function.

[Richard Henderson]

On Thu, Apr 10, 2003 at 05:50:00PM -0500, Mark J Roberts wrote:
> 	struct x { int a, b, c, d; };
> 
> 	struct x zook(void)
> 	{
> 		struct x x = {0, 1, 2, 3};
> 		return x;
> 	}
> 
> gcc -S -O2 -fomit-frame-pointer -march=athlon-xp test.c
> 
> 	.file	"test.c"
> 	.text
> 	.p2align 4,,15
> globl zook
> 	.type	zook, @function
> zook:
> 	subl	$28, %esp
> 	movl	32(%esp), %eax
> 	movl	$0, (%eax)
> 	movl	$1, 4(%eax)
> 	movl	$2, 8(%eax)
> 	movl	$3, 12(%eax)
> 	addl	$28, %esp
> 	ret	$4
> 	.size	zook, .-zook
> 	.ident	"GCC: (GNU) 3.4 20030410 (experimental)"
> 
> and you get code that uselessly moves %esp.

This should be fixed by tree-ssa stuff, but can't be done
otherwise.  We committed too early to putting "x" on the
stack.

> 1) Output "mov" instead of "movl", etc, since gas doesn't require
> the suffix and it's easier to read the code when they are omitted.

I disagree about legibility.  And, you've no idea how this
affects various legacy assemblers.

> 2) Given code like
> 
> 	void process(void *addr)
> 	{
> 		goto *addr;
> 	l1:
> 	l2:	something goes here
> 	l3:
> 	l4:
> 	}
> 
> where you're trying to optimize some code by saving the address of a
> label and using it next time the function is called, provide some
> way to get the address of the label from another function (useful
> for initializing addr the first time). Ie,
> 
> 	void setup(struct state *s)
> 	{
> 		s->addr = process.l1;
> 	}
> 
> or whatever.

No thanks.  There are several other solutions you can use here.


r~

Re: Useless %esp manipulation; omitting "l" suffix in assembly output; getting the address of a label from another function.

[Mark J Roberts]

Richard Henderson:
> I disagree about legibility.  And, you've no idea how this
> affects various legacy assemblers.

Maybe this could be an option? I imagine many people don't use the
suffixes and would naturally prefer to see more familiar output.

If it's too ugly to implement this in gcc, I guess I'll throw a perl
script together and stick that in my compile scripts.

> No thanks.  There are several other solutions you can use here.

Nothing quite as simple though. There's

	goto *(void *[]){&&i0, &&i1, &&i2, &&i3}[n];

which is generic and also the more limited

	goto *(addr ?: &&l0); /* special case */

that I can think of, and I suppose I'll end up doing the latter as
it seems a little quicker.

Re: Useless %esp manipulation; omitting "l" suffix in assembly output; getting the address of a label from another function.

[Richard Henderson]

On Thu, Apr 10, 2003 at 08:30:58PM -0500, Mark J Roberts wrote:
> Maybe this could be an option? I imagine many people don't use the
> suffixes and would naturally prefer to see more familiar output.

No chance.  The maintainence burden isn't worth it.


r~