<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 27, 2017 at 11:36 AM, Friedman, Eli via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF"><span class="">
    <div class="m_7400205316069985375moz-cite-prefix">On 10/26/2017 9:01 PM, Hal Finkel via
      llvm-dev wrote:<br>
    </div>
    <blockquote type="cite">
      
      <p><br>
      </p>
      <div class="m_7400205316069985375moz-cite-prefix">On 10/26/2017 10:56 PM, Chris Lattner
        via llvm-dev wrote:<br>
      </div>
      <blockquote type="cite">
        
        <br>
        <div>
          <blockquote type="cite">
            <div>On Oct 26, 2017, at 8:14 PM, Chandler Carruth
              via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>
              wrote:</div>
            <br class="m_7400205316069985375Apple-interchange-newline">
            <div>
              <div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br class="m_7400205316069985375Apple-interchange-newline">
                One alternative that seems appealing but doesn't
                actually help would be to make `TargetLibraryInfo`
                ignore internal functions. That is how the C++ spec
                seems to handle this for example (C library function
                names are reserved only when they have linkage). But
                this doesn't work well for LLVM because we want to be
                able to LTO an internalized C library. So I think we
                need the rule for LLVM function names to not rely on
                linkage here.</div>
            </div>
          </blockquote>
          <br>
        </div>
        <div>Oh sorry, (almost) TLDR I didn’t get to this part.  I don’t
          see how this is applicable.  If you’re statically linking in a
          libc, I think it is fine to forgo the optimizations
          that TargetLibraryInfo is all about.</div>
        <div><br>
        </div>
        <div>If these transformations are important to use in this case,
          we should invent a new attribute, and the thing that turns
          libc symbols into internal ones should add the attribute to
          the (now internal) libc symbols.</div>
      </blockquote>
      <br>
      I'm not sure; some of the transformations are somewhat special
      (e.g., based on mathematical properties, or things like printf
      -> puts translation). LTO alone certainly won't give you those
      kinds of things via normal IPA, and I doubt we want attributes for
      all of them. Also, having LTO essentially disable optimizations
      isn't good either.</blockquote>
    <br></span>
    Given the way the optimization pipeline works; we can't treat an
    "internal" function as equivalent to a C library function.  When the
    linkage of a function becomes "internal", optimizations start
    kicking in based on the fact that we can see all the users of the
    function.<br>
    <br>
    For example, suppose my program has one call to puts with the
    constant string "foo", and one call to printf which can be
    transformed into a call to puts, and we LTO the C library into it. 
    First we run IPSCCP, which will constant-propagate the address of
    the string into the implementation of puts.  Then instcombine runs
    and transforms the call to printf into a call to puts.  Now we have
    a miscompile, because our "puts" can only output "foo".<br></div></blockquote><div><br></div><div><br></div><div>Slightly off topic. This particular example probably just shows the issue in implementation. A more robust way to implement this is to 'clone' the original function and privatize it instead of the original function.  The removal of the original function can be delayed till the real link time when linker sees no references to it.   This is also a more flexible scheme as LTO does not need to operate in strict whole program mode, nor does it need to query linker to see if the function is referenced by other library functions not visible to the compiler (in IR form), or there is reference to the symbol through dlopen/dlsym ..</div><div><br></div><div>David</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
    <br>
    Given we have mutually exclusive optimizations, we have to pick:
    either we allow the IPSCCP transform, or we allow the instcombine
    transform.  The most straightforward way to indicate the difference
    is to check the linkage: it intuitively has the right meaning, and
    our existing inter-procedural optimizations already check it.<br>
    <br>
    -Eli<span class="HOEnZb"><font color="#888888"><br>
    <pre class="m_7400205316069985375moz-signature" cols="72">-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project</pre>
  </font></span></div>

<br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></div>