This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Support non-standard extension (call via casted function pointer)

On 01/27/2016 03:07 PM, Michael Karcher wrote:
Why can't ghc produce code like:
int bar ()
   int (*foo1)() = foo;
   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
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.
Just a few clarifications. It's not specific to GCC; GCC's extended ASM syntax has been supported by various other compilers for some time.

"r" essentially says put the value into a general purpose register; I'm not aware of any target where that would not work.

Anyway, right now our focus is the upcoming gcc-6 release. Attacking this problem in GCC is queued for gcc-7 development.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]