llvm dev - Sep 2015 - CallInst::getCalledFunction returns null?

I was wondering if someone could explain why CallInst::getCalledFunc behaves
the way it does.

For simple, direct call instructions in my IR, that method behaves just as
one would expect.

However, for instructions like this:

%25 = call i32 (%struct._IO_FILE*, ...)* bitcast (i32 (...)* @close to
i32
> (%struct._IO_FILE*, ...)*)(%struct._IO_FILE* %24), !dbg !695

getCalledFunc returns null.

I know getCalledFunc is expected to return null
<http://llvm.org/docs/doxygen/html/classllvm_1_1CallInst.html#a0bcd4131e1a1d92215f5385b4e16cd2e>
on
indirect calls, but I would have thought naming the callee via a constant
expression like the one here would be considered a direct call.

Thanks,
Christian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150908/a432fd98/attachment.html>

On 9/8/15 11:16 AM, Christian Convey via llvm-dev wrote:
> I was wondering if someone could explain why 
> CallInst::getCalledFunc behaves the way it does.
>
> For simple, direct call instructions in my IR, that method behaves 
> just as one would expect.
>
> However, for instructions like this:
>
>     %25 = call i32 (%struct._IO_FILE*, ...)* bitcast (i32 (...)*
>     @close to i32 (%struct._IO_FILE*, ...)*)(%struct._IO_FILE* %24),
>     !dbg !695
>
>
> getCalledFunc returns null.
>
> I know getCalledFunc is expected to return null 
>
<http://llvm.org/docs/doxygen/html/classllvm_1_1CallInst.html#a0bcd4131e1a1d92215f5385b4e16cd2e>
on
> indirect calls, but I would have thought naming the callee via a 
> constant expression like the one here would be considered a direct call.
The getCalledFunc() method is not very sophisticated.  It turns NULL if 
the called value is not trivially a function constant.

I'm not sure for the reasoning behind this.  My best guess is that a 
constant expression could do all sorts of interesting things.  For 
example, a constant expression can select one of several values or pull 
a value out of an array using a constant expression GEP.

You'll need to do what SAFECode does; use 
getCalledValue()->stripPointerCasts() to get the called value and remove 
any casts that stand between you and the function value. It's 
inconvenient, but it works.

Alternatively, you could see if the CallSite() class provides a smarter 
method of getting the called function, but I'm not sure if it has such a 
method.

Regards,

John Criswell
>
> Thanks,
> Christian
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 
John Criswell
Assistant Professor
Department of Computer Science, University of Rochester
http://www.cs.rochester.edu/u/criswell

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150908/3edf1fda/attachment.html>

Hi John,

On Tue, Sep 8, 2015 at 11:26 AM, John Criswell <jtcriswel at gmail.com>
wrote:
> The getCalledFunc() method is not very sophisticated.  It turns NULL if
> the called value is not trivially a function constant.
>
> I'm not sure for the reasoning behind this.  My best guess is that a
> constant expression could do all sorts of interesting things.  For example,
> a constant expression can select one of several values or pull a value out
> of an array using a constant expression GEP.
>
> You'll need to do what SAFECode does; use
> getCalledValue()->stripPointerCasts() to get the called value and remove
> any casts that stand between you and the function value.  It's
> inconvenient, but it works.
>
My apologies if this should be a clang question, but I'm trying to
reconcile what people mean by "direct" calls in the clang vs. LLVM
communities.  (The documentation for getCalledFunction makes me wonder if
I'm using term the same way as everyone else.)

I'm coming to this question with my AA-implementer's hat on.  I want to
handle C/C++ indirect calls well, and I'm trying to figure out if that
basically means handling non-`llvm::Constant` callee-specifications well.

Do you know if it tends to be the case that:

   - A direct function call at the C/C++ level becomes an llvm::CallInst or
   llvm::InvokeInst where the callee is name by an llvm::Constant.

   - An indirect function call at the C/C++ level ends up being translated
   to a llvm::CallInst or llvm::InvokeInst where the callee is named by an
   llvm::Value which is *not* an llvm::Constant.


Thanks again,
Christian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150908/b92b84c4/attachment.html>