regparm & other gcc bug

[Martynas Kunigelis]

Jim Wilson wrote:
> 
>         Basically any machine that defines SMALL_REGISTER_CLASSES and passes args in
>         registers is playing with fire -- reload can and will silently generate incorrect
>         code for such targets.  For that reason I _highly_ recommend against using
>         registers for parameter passing on the x86 targets.
> 
> I'll second it.  The x86 regparm attribute is unsafe, and should not be used.
> It might be possible to fix the problem by hacking reload and the x86 port,
> but it doesn't seem very worthwhile.  The problem is hard to fix, and exposes
> people to unnecessary risks of compiler bugs.  There are probably easier
> ways to get faster x86 code.
> 

I don't know how hard is it to fix it, still I feel sorry. Register
parameters
can boost performance a lot in some cases I think... :( :( Anyway,
there's a bug
in gcc I have reported maybe a year and a half ago, still nobody at FSF
cared to
fix it. The bug is that if you specify multiple attributes for a
function (didn't try
the variables and structs though), only the last one in the list is
taken into account.
Here's a small example:

int add(int, int, int, int) __attribute__((regparm(3), stdcall));

int add(int a, int b, int c, int d)
{
    return a + b + c + d;
}

If you compile the function, only stdcall is taken into account, regparm
is not active.
If you swap regparm and stdcall in the __attribute__ and compile it
again, only regparm
will be used. There you go...

Damn, I can't resist it: think about the efficiency of the code
generated for this
function if both attributes are counted and -fomit-frame-pointer is
specified:

	addl %edx, %eax
	addl %ecx, %eax
	addl 4(%esp), %eax
	ret  $4

That's why I'd love to have the regparm stuff. I know, I know, this is
far too trivial
example, but....

-Martynas