Re: RFC: Support non-standard extension (call via casted function pointer)
On 27.01.2016 16:10, Thorsten Otto wrote:
> > This frobbing of a pointer return value in %d0 only happens in the
> > outgoing case already now, because in the non-outgoing case,
> > m68k_function_value is (unverified claim) only called from expand_call,
> > which replaces the PARALLEL rtx by the first list element, i.e. %a0. (or
> > %d0 if !POINTER_TYPE_P(valtype) after my patch).
>
> Wether pointer values are returned in d0 or a0 only depend on the ABI,
> not the machine type.
Well, this is kind-of correct. Of course the ABI defines whether
pointers are returned in d0, a0 or rax. But the ABI depends on the
machine type and is implemented by the machine-specific backend.
>
> BTW what does ghc expect on x86-64? The ABIs on linux and e.g Win64
> are also quite different with respect to which registers are used to
> pass/ parameters.
The translation from Cmm to C only happens in "unregisterized" builds of
ghc. In this kind of build, ghc has no specific expectations about what
registers will be used for passing or returning value. The only thing
ghc expects is that the code generated *by gcc* to retrieve the returned
value (from a temporary memory location, an integer register, a
floating-point register, an address register) for a function of type X
called through a pointer-to-function-of-type-X matches the code
generated *by gcc* to put that value into some registers.
I trust gcc on Win64 and gcc on linux to know the specific ABIs and
generate correct code.
> And in the m68k-case, you will have similar problems with double
> values. Depending on the ABI, they are returned in either fp0 or d0/d1.
I already checked that, first experimentally, after that by reading the
source code. There are no problems with returning double values, because
the register picked for reading the return value from is determined by
m68k_function_value using only the valtype parameter. This parameter
indicates the actual return type when m68k_function_value is used while
compiling the function and this parameter indicates the return type of
the function-expression that acutally got called when compiling the
caller. In the case of ghc, these types match, so a consistent register
is returned (which depends on the ABI, though).
> Conclusion: IMHO, If ghc fetches the return value from the wrong
> register, then ghc is broken, not gcc.
ghc does not fetch anything from any register. ghc generates C code that
is known to be non-conforming, and gcc decides what register to fetch from.
Regards,
Michael Karcher
Reply to: