<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<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">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<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">
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8">
<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>
<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>
</body>
</html>