<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 8/13/13 9:37 PM, Nick Lewycky wrote:<br>
</div>
<blockquote
cite="mid:CADbEz-gmZMUY2pFS=S_MuGfwWaSsgSL9XVFiHXdG+fTWe8inDQ@mail.gmail.com"
type="cite">
<div dir="ltr">I don't think such comparison is precise. For app
with networking lib, the "braid" reside at app side because the
app define the behavior. <br>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> For
linker+libLTO, I believe the "brain"
should reside at libLTO side, as it is far
more complicate (although our current
implement is bit simple). <br>
</div>
</blockquote>
<div><br>
</div>
<div>I'm afraid I don't agree. We can agree to
disagree on this point, it isn't necessary
for us to agree here to make forwards
progress.</div>
</div>
</div>
</div>
</blockquote>
</div>
Such discussion will be open-ended. I don't like to
waste bandwidth over here. It is not my focus<br>
at all. Maybe you can understand that point after you
try to make some infrastructure level <br>
change to the lto. If you OSX, you will see that. If you
don't, grab a Linux machine, try to implement <br>
that feature on Linux+gold but *WITHOUT* touching any
bit the tool/gold/*. <br>
</div>
</blockquote>
<div><br>
</div>
<div>Does <a moz-do-not-send="true"
href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090202/073164.html"
target="_blank">http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090202/073164.html</a>
count? tools/gold/* didn't exist when I started.</div>
</div>
</div>
</div>
</blockquote>
Unfortunately, not. <br>
<br>
You are working on a simple and clean APIs provided by gold linker.
<br>
How about try to achieve what I'm try to achieve without touching
these bits? <br>
<br>
The difficulty is how dance under the existing interface, not how to
bridge two interfaces.<br>
<br>
<blockquote
cite="mid:CADbEz-gmZMUY2pFS=S_MuGfwWaSsgSL9XVFiHXdG+fTWe8inDQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>Look, I didn't make up this rule. I'm trying to tell
you, as a new contributor, that the rule already existed
and you should be aware of it.</div>
<div><br>
</div>
<div>Here's an old example of Chris mentioning the rule that
changes to the C ABI are not allowed (and yes, libLTO's
API is part of the C API):</div>
<div><a moz-do-not-send="true"
href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090720/081858.html"
target="_blank">http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090720/081858.html</a> .
I don't think this is the first time it was mentioned
either, but I wasn't able to find a better example with a
minute of searching.</div>
</div>
</div>
</div>
</blockquote>
<br>
I did not *change* "C ABI", I *add* API. <br>
<br>
<blockquote
cite="mid:CADbEz-gmZMUY2pFS=S_MuGfwWaSsgSL9XVFiHXdG+fTWe8inDQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> Currently, we
ignore the I/O issue about LTO, can you imagine what
kind of APIs we need in future <br>
to improve the I/Os. And how can magically maintain such
backward compatability? libLTO is <br>
potentially very complex state-machine. <br>
<br>
Why not let linker to expose its interface, and let
plugin (LTO) to work with them. Isn't that easier. <br>
I don't understand you think exposing interface from LTO
to linker is better. Such linker is tightly<br>
bound to a compiler, dedicated to compiler. In order to
maintain that linker, engineer needs in-depth<br>
knowhows about compiler and linker. I don't see why it
is better. <br>
</div>
</blockquote>
<div><br>
</div>
<div>Let me try to restate what you said in my own words, so
we can make sure I understood it. You want llvm-lto to be
its own program, and the system linker should be a plugin
that llvm-lto loads?</div>
</div>
</div>
</div>
</blockquote>
Why the hack there are so many confusion. <br>
<br>
I want a stand-alone, decoupled liner, just like gold which talk
with llvm-lto on gold's interface, not lto_xxx(). <br>
i.e. the llvm-lto in my mind would be current libgold + libLTO. <br>
<br>
<br>
<blockquote
cite="mid:CADbEz-gmZMUY2pFS=S_MuGfwWaSsgSL9XVFiHXdG+fTWe8inDQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>Sure. It's a way to let the compiler and the
compiler-provided LTO plugin collaborate, via "flags"
(really any string with limited punctuation).</div>
<div><br>
</div>
<div>But that assumes the linker will be run by the
compiler, which isn't always true. We want llvm lto to
work as a drop-in replacement for the existing tools, and
sometimes existing build systems will run ld directly.
(Yes, gold will search known paths on the system to find
the plugin, it doesn't require a flag.)</div>
</div>
</div>
</div>
</blockquote>
<br>
Then the existing weird build system have to understand the these
flags. No other way around. <br>
I don't see why a linker have to work with one compiler. <br>
<br>
<br>
</body>
</html>