g++/i386: 4-byte inline struct return

g++/i386: 4-byte inline struct return

[Hasdi R Hashim]

Hello guys,

	I would really, really appreaciate it if somebody would look into
this. This is the general case, I am sure you can come with multiple
permutations of the code snippet (I did), before you can isolate the
problem.

SOURCE CODE:
	struct foo { long x; } ;
	inline foo bar(long x) return z ; { z.x = x; }

	foo a;
	void foobar() { a = bar(1); }

OUTPUT ASM CODE (notice redundant code):
	foobar__Fv:
		pushl %ebp
		movl %esp,%ebp
		subl $4,%esp
		movl $1,-4(%ebp)
		movl $1,a
		leave
		ret
WHAT I EXPECT (mo efficient):
	foobar__Fv:
		pushl %ebp
		movl %esp,%ebp
		movl $1,a
		leave
		ret

I tried every single trick I could think off to make "foo a = bar(1)" as
efficient as "long a = 1". I think the problem has to with struct returns
because when I substitute "struct foo.." with "typedef long foo" I get the
expected code. Can somebody please work on this? This has enormous
potential; it would help me and millions other sorry hackers out there. 

TQ :) :) ;)

Hasdi

PS - yes, I did -O, -O2 and -O3

Re: g++/i386: 4-byte inline struct return

[Hasdi R Hashim]

On Thu, 17 Sep 1998, Joern Rennecke wrote:
> This problem is ABI related.  For instance, you will get better code for
> i386-linuxaout that for i386-pc-linux-gnu.
> Unless you use -freg-struct-return , but then, you can get problems with
> library functions like inet_makeaddr.

I'll try this when I get back home. I think gcc should return struct
values in registers anyway (ignoring -fpcc-struct-return) if the caller
and callee can follow the same struct-return convention (i.e. inline and
static functions). Is there a fallacy in my thinking? I hope somebody more
experience can tell me if this is easy to 'fix' in egcs. 

Thanks a bunch. -Hasdi

Re: g++/i386: 4-byte inline struct return

[Hasdi R Hashim]

On Thu, 17 Sep 1998, Joern Rennecke wrote:
> We can't do this for non-inline static functions - nor the non-inline
> expansion of an inline static function - if the choice in general is
> -fpcc-struct-return .  We don't know if the address of the function is
> taken before we have compilde the entire file.

Ok. non-inline statics can wait, unless somebody insists on being
adventurous in -O3. For regular inlines, I don't see any reason why you
want to return in memory (at least in most cases I've seen). It really
pains me to see redundant stores all over the code when using my
fixed-point arithmetic class (maybe I didn't implement it well enough :(. 

Hasdi

Re: g++/i386: 4-byte inline struct return

[Joern Rennecke]

> I'll try this when I get back home. I think gcc should return struct
> values in registers anyway (ignoring -fpcc-struct-return) if the caller
> and callee can follow the same struct-return convention (i.e. inline and
> static functions). Is there a fallacy in my thinking? I hope somebody more
> experience can tell me if this is easy to 'fix' in egcs. 

We can't do this for non-inline static functions - nor the non-inline
expansion of an inline static function - if the choice in general is
-fpcc-struct-return .  We don't know if the address of the function is
taken before we have compilde the entire file.

Re: g++/i386: 4-byte inline struct return

[Joern Rennecke]

> I tried every single trick I could think off to make "foo a = bar(1)" as
> efficient as "long a = 1". I think the problem has to with struct returns
> because when I substitute "struct foo.." with "typedef long foo" I get the
> expected code. Can somebody please work on this? This has enormous
> potential; it would help me and millions other sorry hackers out there. 

This problem is ABI related.  For instance, you will get better code for
i386-linuxaout that for i386-pc-linux-gnu.
Unless you use -freg-struct-return , but then, you can get problems with
library functions like inet_makeaddr.

Re: g++/i386: 4-byte inline struct return

[Joe Buck]

> On Thu, 17 Sep 1998, Joern Rennecke wrote:
> > This problem is ABI related.  For instance, you will get better code for
> > i386-linuxaout that for i386-pc-linux-gnu.
> > Unless you use -freg-struct-return , but then, you can get problems with
> > library functions like inet_makeaddr.
> 
> I'll try this when I get back home. I think gcc should return struct
> values in registers anyway (ignoring -fpcc-struct-return) if the caller
> and callee can follow the same struct-return convention (i.e. inline and
> static functions). Is there a fallacy in my thinking? I hope somebody more
> experience can tell me if this is easy to 'fix' in egcs. 

Yes, it seems that if we know the caller and callee agree, then a more
efficient scheme can be used (e.g. for static functions).  But there's the
matter of debugging; either this would break debugging or we'd have to
tell the debugger somehow that the normal rule isn't being followed.

Re: g++/i386: 4-byte inline struct return

[Martin von Loewis]

> I tried every single trick I could think off to make "foo a = bar(1)" as
> efficient as "long a = 1". I think the problem has to with struct returns
> because when I substitute "struct foo.." with "typedef long foo" I get the
> expected code. Can somebody please work on this?

Hasdi,

It might be that somebody steps forward and says 'I've been waiting
all the time to fix this, now it is the time'. In this case, ignore
my comments.

More likely, nothing will happen. There are some serious bugs in gcc
(especially in the non-C front-ends), a lot of missing features, and a
huge amount of missed optimization opportunities.

So if you *really* need this to generate efficient code, why don't you
just look into this and find out how to optimize it better.

Apparently, the problem is that ebp-4 is not used in the function
after it is written, so the write operation could be ignored. Finding
a good generalization of the situation, and implementing it reliably
would surely be appreciated by many. OTOH, if you don't do it, maybe
nobody else will.

Regards,
Martin

Re: g++/i386: 4-byte inline struct return

[Martin von Loewis]

> I'll try this when I get back home. I think gcc should return struct
> values in registers anyway (ignoring -fpcc-struct-return) if the caller
> and callee can follow the same struct-return convention (i.e. inline and
> static functions). Is there a fallacy in my thinking?

The problem is that the ABI is already defined, caller and callee will
not follow the same convention if one of them is changed now, and the
other is in a library that we have no control over.

Regards,
Martin

Re: g++/i386: 4-byte inline struct return

[Hasdi R Hashim]

On Thu, 17 Sep 1998, Hasdi R Hashim wrote:
> On Thu, 17 Sep 1998, Joern Rennecke wrote:
> > This problem is ABI related.  For instance, you will get better code for
> > i386-linuxaout that for i386-pc-linux-gnu.
> > Unless you use -freg-struct-return , but then, you can get problems with
> > library functions like inet_makeaddr.
> 
> I'll try this when I get back home. I think gcc should return struct
> values in registers anyway (ignoring -fpcc-struct-return) if the caller
> and callee can follow the same struct-return convention (i.e. inline and
> static functions). Is there a fallacy in my thinking? I hope somebody more
> experience can tell me if this is easy to 'fix' in egcs. 

Ok, I tried it out and it turns out using -freg-struct-return turned out
worse: (this is using egcs release - forgot the version - wished my box is
on the network :(

	EXPECTED:	movl	$1,dest

	ACTUAL:		movl	$1,[bp-4]	; redundant
			movl	$1,dest

	AFTER -freg..:	movl	$1,%eax		; even more
			movl	%eax,[bp-4]	; redundant
			movl	$1,dest

Curiously, when I tried out the same code on gcc 2.8.1/UltraSparc, 4-byte
struct return is identical to 4-byte int return. Either 2.8.1 is smarter
or i386.md needs a little fixing. I'd be willing to look into that if I
know which insn to look out for. It's probably common to both gcc and g++.
I'd have to investigate when I get back home.

Hasdi