<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/28/2017 11:42 AM, Xinliang David
Li wrote:<br>
</div>
<blockquote
cite="mid:CALRgJCMR1Ao35Tq3JLk436SKyaPes_rWU20n-fqgZ7iojcd+jQ@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<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
moz-do-not-send="true"
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
moz-do-not-send="true"
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>
</div>
</div>
</blockquote>
<br>
I agree, cloning would be good. I'll mention, however, that there
are benefits to dropping the unused original functions early that we
should likely endeavor not to lose (e.g., dropping the unused
original function may lead to optimization opportunities for global
variables and the like).<br>
<br>
More-aggressive cloning will also help with our problems optimizing,
and using IPA on, functions with inline linkage. <br>
<br>
-Hal<br>
<br>
<blockquote
cite="mid:CALRgJCMR1Ao35Tq3JLk436SKyaPes_rWU20n-fqgZ7iojcd+jQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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 moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a moz-do-not-send="true"
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>
</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>