<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 9/8/15 11:52 AM, Christian Convey
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAPfS4ZzTpnTMMNd-VV68V=whY_DnE+eFFXqM_EUGXDpnPDQOYw@mail.gmail.com"
      type="cite">
      <meta http-equiv="Context-Type" content="text/html; charset=UTF-8">
      <div dir="ltr">Hi John, 
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Tue, Sep 8, 2015 at 11:26 AM, John
            Criswell <span dir="ltr"><<a moz-do-not-send="true"
                href="mailto:jtcriswel@gmail.com" target="_blank">jtcriswel@gmail.com</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote">
              <div><span class="">
                  <div>The getCalledFunc() method is not very
                    sophisticated.  It turns NULL if the called value is
                    not trivially a function constant.<br>
                  </div>
                </span> <br>
                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.<br>
                <br>
                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.<br>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>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.)</div>
            <div><br>
            </div>
            <div>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.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    I would think so, yes.<br>
    <br>
    <blockquote
cite="mid:CAPfS4ZzTpnTMMNd-VV68V=whY_DnE+eFFXqM_EUGXDpnPDQOYw@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div><br>
            </div>
            <div>Do you know if it tends to be the case that:</div>
            <div>
              <ul>
                <li>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.<br>
                  <br>
                </li>
                <li>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 <i>not</i> an llvm::Constant.</li>
              </ul>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    No.  A direct call at the C/C++ source level can end up being a call
    in which the argument to the CallInst or InvokeInst is not a
    function constant.  Examples include:<br>
    <br>
    1) Cases in which a function is used with a different number of
    arguments than the declared type.  This is common when a C function
    prototype has no arguments but the function definition has
    arguments.<br>
    <br>
    2) An optimization changes an if/then/else to a predicated
    instruction.  For example, it is possible that:<br>
    <br>
    if (flag)<br>
        foo(5);<br>
    else<br>
        bar(5);<br>
    <br>
    ... could become something like (in a combined LLVM/C notation):<br>
    <br>
    call ((flag) ? foo : bar) (5)<br>
    <br>
    Note that I don't know if this optimization will happen, but in
    theory, it can happen.<br>
    <br>
    In short, if you want to handle C/C++ code, you need to handle
    whatever the frontend spits out in LLVM IR.  That includes function
    constants, casted function constants, function arguments that are a
    select instruction between several constants, etc.<br>
    <br>
    You may want to grep the DSA code in the poolalloc project for
    getCalledValue() to see what kind of CallInsts it handles.  That
    way, you can piggy-back off the experiences we've had updating DSA
    to handle what the newer LLVM front-ends do.<br>
    <br>
    Regards,<br>
    <br>
    John Criswell<br>
    <br>
    <blockquote
cite="mid:CAPfS4ZzTpnTMMNd-VV68V=whY_DnE+eFFXqM_EUGXDpnPDQOYw@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>
              <div><br>
              </div>
            </div>
            <div>Thanks again,</div>
            <div>Christian</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
John Criswell
Assistant Professor
Department of Computer Science, University of Rochester
<a class="moz-txt-link-freetext" href="http://www.cs.rochester.edu/u/criswell">http://www.cs.rochester.edu/u/criswell</a></pre>
  </body>
</html>