<div dir="ltr"><div>Dear John,<br>Thank you for your reply. <br>The LLVM IRs are definitely the same since the cloning pass is the final IR pass in LTO. The calls to the clones always stay in the program as well. </div><div><br>The problem is that this happens only in large functions (with a couple of hundreds of basic blocks) and it happens very rarely (on average in 1 function out of every 1 thousand). So I wasn't sure whether by dumping the MachineFunction, I will be able to figure out the problem. I can however, figure out which codegen pass causes this. <br><br></div>I also believe that the code generators don't do any inter-procedural analysis, unless some meta data from IR level instructs them to do so.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 2, 2014 at 10:28 AM, John Criswell <span dir="ltr"><<a href="mailto:jtcriswel@gmail.com" target="_blank">jtcriswel@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><div><div class="h5">
    <div>On 12/1/14, 11:15 PM, Rahman Lavaee
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">
        <div>
          <div>I am trying to use CloneFunction to clone every IR
            function in a program, give the cloned versions a prefix and
            call the clones from the original functions (redirect the
            calls).<br>
          </div>
          <br>
          Surprisingly, I see that after the LTO optimizations, the
          number of machine basic blocks in the two functions differ in
          some cases. <br>
          <br>
          Is this reasonable at all, given that the two functions must
          be exactly the same in the IR level.<br>
          <br>
        </div>
        Or it might happen because of the interprocedural optimizations?
        <br>
      </div>
    </blockquote>
    <br></div></div>
    Have you verified that the old and new functions are identical at
    the LLVM IR level right before code generation in libLTO (you can
    easily modify libLTO to dump out the LLVM IR right before code
    generation).  It might happen because of inter-procedural
    optimizations.  If the old functions are no longer called, then
    inter-procedural constant propagation and other inter-procedural
    optimizations may change the new functions but not the old
    functions.<br>
    <br>
    I don't know if the code generators do any inter-procedural
    analysis; my impression was that they did not.  However, someone
    else needs to answer that question.<br>
    <br>
    Regards,<br>
    <br>
    John Criswell<span class="HOEnZb"><font color="#888888"><br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div><br>
          <div>
            <div>
              <div>
                <div>
                  <div>-- <br>
                    <div><font face="tahoma,
                        sans-serif">Rahman</font></div>
                  </div>
                </div>
              </div>
            </div>
          </div>
        </div>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      <pre>_______________________________________________
LLVM Developers mailing list
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a>
</pre>
    </blockquote>
    <br>
    <br>
    <pre cols="72">-- 
John Criswell
Assistant Professor
Department of Computer Science, University of Rochester
<a href="http://www.cs.rochester.edu/u/criswell" target="_blank">http://www.cs.rochester.edu/u/criswell</a></pre>
  </font></span></div>

</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><font face="tahoma, sans-serif">Rahman</font></div>
</div>