This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: Support non-standard extension (call via casted function pointer)
- From: Michael Karcher <debian at mkarcher dot dialup dot fu-berlin dot de>
- To: Andrew Pinski <pinskia at gmail dot com>, Richard Biener <richard dot guenther at gmail dot com>
- Cc: Thorsten Otto <halgara at yahoo dot de>, John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin dot de>, GCC Development <gcc at gcc dot gnu dot org>, Debian m68k <debian-68k at lists dot debian dot org>, Andreas Schwab <schwab at linux-m68k dot org>, Matthias Klose <doko at debian dot org>
- Date: Wed, 27 Jan 2016 23:07:23 +0100
- Subject: Re: RFC: Support non-standard extension (call via casted function pointer)
- Authentication-results: sourceware.org; auth=none
- References: <56A7C307 dot 3010701 at mkarcher dot dialup dot fu-berlin dot de> <1824417918 dot 1565020 dot 1453907423941 dot JavaMail dot yahoo at mail dot yahoo dot com> <CAFiYyc0fAj3Dq6SEySEf93_Fx0heK5nh9VRrY-u8VNDePyqYdw at mail dot gmail dot com> <CA+=Sn1m026Ub4TPgSFsriUwPiigVZFos6PzN_hKhO0=6MQskPA at mail dot gmail dot com>
On 27.01.2016 22:49, Andrew Pinski wrote:
> On Wed, Jan 27, 2016 at 7:17 AM, Richard Biener
> <richard.guenther@gmail.com> wrote:
>>
>> We are trying to support
>>
>> t.c
>> ---
>> void *foo();
>>
>> int bar()
>> {
>> return ((int (*)())foo) ();
>> }
> Why can't ghc produce code like:
> int bar ()
> {
> int (*foo1)() = foo;
> asm("":"+r"(foo1));
> return foo1();
> }
Thank you for the first suggestion about what ghc can do to avoid the
problem without the need to change the internally used Cmm language (as
would be needed to avoid lying about the type of foo).
> Yes it no longer produces an direct function call but it might be
> better in the long run anyways.
I don't really care about the direct function call. Using ghc on a
target where it can't generate native machine code is doomed to be slow
anyway.
But I don't see how it "might be better in the long rung anyway". The
first thing I note is that this workaround is specific to gcc. I didn't
check the gcc internals manual, but I am unsure whether the constraint
"r" is portable to be used on function pointers on all architectures gcc
supports. Furthermore, this hides the fact that the use case is not
supported by playing games with the optimizer, whereas Jeff and Richard
try to get this use case supported.
If gcc decides that the m68k backend should not be adjusted to use the
parameter "valtype" to determine the register used by the currently
selected ABI for the return value on caller side, but keep using the
function declaration for that, I will nevertheless propose this change
to ghc.
> Thanks,
> Andrew
Regards,
Michael Karcher