"Joseph S. Myers" wrote on 14.09.2007 00:09:49:
> On Thu, 13 Sep 2007, Michael Meissner wrote:
>
> > In the first patch, I am somewhat uncomfortable with changing
> RETURN_IN_MEMORY
> > and OUTGOING_REG_PARM_STACK_SPACE, by adding an additional
> parameter, and then
> > changing all of the targets. It might be better to have new macros
> > (RETURN_IN_MEMORY_ABI, OUTGOING_REG_PARM_STACK_SPACE_ABI), and if
> the old macro
> > is defined, code the new macro calling the earlier macro. This way
you can
> > avoid changing the other backends. Otherwise, you probably need
> to work with
> > each maintainer to make sure you haven't broken their code.
>
> If you change the interface like that, the replacement should be a
target
> hook in the target structure, not a target macro.
>
On 14 August 2007 16:04, Kai Tietz wrote:
AFAICS is RETURN_IN_MEMORY deprecated, isn't it. It seems to be there just
by an incomplete move to TARGET_RETURN_IN_MEMORY (which allready has the
additional parameter). Here's the 3.3.3 internals manual:
10.10.9 How Large Values Are Returned
-------------------------------------
When a function value's mode is `BLKmode' (and in some other cases),
the value is not returned according to `FUNCTION_VALUE' (*note Scalar
Return::). Instead, the caller passes the address of a block of memory
in which the value should be stored. This address is called the
"structure value address".
This section describes how to control returning structure values in
memory.
`RETURN_IN_MEMORY (TYPE)'
A C expression which can inhibit the returning of certain function
values in registers, based on the type of value. A nonzero value
says to return the function value in memory, just as large
structures are always returned. Here TYPE will be a C expression
of type `tree', representing the data type of the value.
Note that values of mode `BLKmode' must be explicitly handled by
this macro. Also, the option `-fpcc-struct-return' takes effect
regardless of this macro. On most systems, it is possible to
leave the macro undefined; this causes a default definition to be
used, whose value is the constant 1 for `BLKmode' values, and 0
otherwise.
Do not use this macro to indicate that structures and unions
should always be returned in memory. You should instead use
`DEFAULT_PCC_STRUCT_RETURN' to indicate this.
And now the current top-of-tree internals manual:
15.10.9 How Large Values Are Returned
-------------------------------------
When a function value's mode is `BLKmode' (and in some other cases),
the value is not returned according to `TARGET_FUNCTION_VALUE' (*note
Scalar Return::). Instead, the caller passes the address of a block of
memory in which the value should be stored. This address is called the
"structure value address".
This section describes how to control returning structure values in
memory.
-- Target Hook: bool TARGET_RETURN_IN_MEMORY (tree TYPE, tree FNTYPE)
This target hook should return a nonzero value to say to return the
function value in memory, just as large structures are always
returned. Here TYPE will be the data type of the value, and FNTYPE
will be the type of the function doing the returning, or `NULL' for
libcalls.
Note that values of mode `BLKmode' must be explicitly handled by
this function. Also, the option `-fpcc-struct-return' takes
effect regardless of this macro. On most systems, it is possible
to leave the hook undefined; this causes a default definition to
be used, whose value is the constant 1 for `BLKmode' values, and 0
otherwise.
Do not use this hook to indicate that structures and unions should
always be returned in memory. You should instead use
`DEFAULT_PCC_STRUCT_RETURN' to indicate this.
So it looks like the documentation is already there; this is an incomplete
transition, and I am just bringing the old back-compat macros up-to-date
with the changed abi for the new target-hook version!
Cheers,
i.A. Kai Tietz
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.
------------------------------------------------------------------------------------------
OneVision Software Entwicklungs GmbH & Co. KG
Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com
Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050
Handelsregister: HRA 6744, Amtsgericht Regensburg
Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH
Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg
Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer:
Ulrike Döhler, Manuela Kluger
