[cfe-dev] Indirect call generation for other than native targets

[John McCall]

On Jan 29, 2013, at 2:04 AM, ihusar at fit.vutbr.cz wrote:
> Hi David, thank you for your reply.
> 
> Here are some more details.
> I need to process the code produced by clang later in my opt-like passes and
> there, when I process the CallInst and ask for the called function
> from this code:
> 
> call void bitcast (void (...)* @fun to void ()*)()
> 
> like this:
> 
> CallInst* ci = dyn_cast<CallInst>(i);
> Function* f = ci->getCalledFunction();
> 
> the pointer f is set to NULL and according to the comments for
> CallInst::getCalledFunction, the call is indirect:
> 
>  /// getCalledFunction - Return the function called, or null if this is an
>  /// indirect function invocation.

It's not really an indirect invocation.  The problem is that getCalledFunction()
does not look through bitcasts.  That's generally for the good, because
otherwise code that uses it would have to be extremely defensive about
type mismatches, but it does complicate things like the definition of a direct call.

clang started inserting the bitcast relatively recently in order to fix some
longstanding problems with variadic calls on some platforms.  Specifically,
on MIPS it is invalid to call a non-variadic function as if it were a variadic one
because variadic arguments are always passed on the stack.  This makes it
quite important that unprototyped calls not generate an apparently variadic
call (which, in turn, means you cannot call e.g. printf without a prototype, but
that's acceptable platform behavior under the C standard), except on a handful
of platforms (like x86-64) that explicitly specify that unprototyped calls should
follow the variadic conventions.  On i386 (and many others) it's a wash, but
I wanted the default behavior to follow the MIPS logic (and maybe generate
slightly less pretty IR) instead of requiring every MIPS-like platform to opt in
to correctness.

John.