<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 10/27/2017 01:36 PM, Friedman, Eli
wrote:<br>
</div>
<blockquote
cite="mid:0fd66d82-9a60-cba9-b69a-d530f096f56b@codeaurora.org"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div class="moz-cite-prefix">On 10/26/2017 9:01 PM, Hal Finkel via
llvm-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:d9837f66-5c20-7bfe-9f91-c15d9fb2ab81@anl.gov">
<p><br>
</p>
<div class="moz-cite-prefix">On 10/26/2017 10:56 PM, Chris
Lattner via llvm-dev wrote:<br>
</div>
<blockquote
cite="mid:AA022A6C-756B-40AB-BB89-50199CBD5502@nondot.org"
type="cite"> <br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Oct 26, 2017, at 8:14 PM, Chandler
Carruth via llvm-dev <<a moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<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;
-webkit-text-stroke-width: 0px;" class=""><br
class="Apple-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 class="">
</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 class="">
</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>
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>
<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>
</blockquote>
<br>
Good point. If we optimize a function on the basis of being able to
see all users, it can no longer be "special" in this regard (and we
also can't introduce new calls to it). In the general case (which, I
imagine is the libc-LTO case), you might need to clone such a
function when we specialize so that we can continue to introduce new
calls to the original function (and then DCE afterward).<br>
<br>
-Hal<br>
<br>
<blockquote
cite="mid:0fd66d82-9a60-cba9-b69a-d530f096f56b@codeaurora.org"
type="cite"> <br>
-Eli<br>
<pre class="moz-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>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>