Re: Dynamic FUNCTION_OUTGOING_VALUE?

[Alexandre Courbot <Alexandre dot Courbot at lifl dot fr>]

> I'm still not sure I get it.  If the return value is in a fixed place,
> then we still need to copy it from that fixed place to the pseudo, so
> why do you want a pseudo in the call insn itself?

This is because my target actually has no registers. Everything is abstract. 
Consider the following code:

int foofunc()
{
	return 5;
}

void barfunc()
{
	int i = foofunc;
}

The ideal generated code on my target would be:

.Cst CardCode foofunc {
	.Return CardInt

	Return #5
}

.Cst CardCode barfunc {
	.Local CardInt i_0

	i_0 <- foofunc
}

While currently barfunc is compiled into:

.Cst CardCode barfunc {
	.Local CardInt i_0
	.Temp temp_ret

	temp_ret <- foofunc
	i_0 <- temp_ret asIs
}

The mapping is quite straightforward: Stack slots are mapped into local 
variables, and data registers into temporaries. When compiling the callee, 
returning to a fixed place is good. This allows me to save the return value 
when it is moved into the return register, and to output its value when the 
return insn is matched.

For the caller however, getting the return value from a fixed place is not 
optimal. The call_value insn is of the form

(set (reg 0) (call ....))

(register 0 being the return value register). Then the result is moved into 
the destination:

(set (mem (... [i])) (reg 0))

Register 0 must then be mapped into a temporary. The ideal for me would be to 
be able to generate an insn of the form

(set (mem (... [i])) (call)) directly.

Although it looks like when you read the rtl that the return value is never 
grabbed, it generates better code. But it seems impossible to generate such a 
form, since I can't know at call time where the result should be put.

The reason why I've been looking at replacing the fixed value with a pseudo is 
the first step is to fix another issue. I am allowed to use a limited number 
of temporaries per function, and this thing obliges me to reserve a temporary 
to receive return values. If I could replace it with a pseudo, it would then 
make better code (either use a data register which will end in a temporary 
without reserving it for that only purpose, or a stack slot which will be 
compiled into a locale).

I hope the issue is more clear now. I don't think that getting the return 
value from a different place than the one it has been returned into would 
cause the compiler to have a bad behavior (I'm not sure about optimization 
passes though - especially function inlining).

> > What prevents me from creating a pseudo in FUNCTION_RETURN_VALUE is that
> > is it called several times for every function call, and even when
> > outputting the code of the callee. So it is impossible to assign a unique
> > pseudo for every function call.
>
> You could try to write a patch to fix this.

Right. If someone can confirm that this wouldn't hurt at the compiler level, 
I'll put this on my todo-list.

Alex.