<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<br>
<div>
<div>On Dec 5, 2012, at 9:10 PM, Michael Spencer <<a href="mailto:bigcheesegs@gmail.com">bigcheesegs@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">On Mon, Dec 3, 2012 at 2:08 PM, Relph, Richard <<a href="mailto:Richard.Relph@amd.com">Richard.Relph@amd.com</a>> wrote:<br>
<blockquote type="cite">On Nov 21, 2012, at 4:28 PM, "Relph, Richard" <<a href="mailto:Richard.Relph@amd.com">Richard.Relph@amd.com</a>> wrote:<br>
<br>
<blockquote type="cite">On Nov 21, 2012, at 12:09 PM, Michael Spencer <<a href="mailto:bigcheesegs@gmail.com">bigcheesegs@gmail.com</a>> wrote:<br>
<br>
<blockquote type="cite">Note that I plan to remove llvm/Bitcode/Archive once Object/Archive is<br>
capable of replacing it. The llvm tools that don't write archives<br>
files have already been switched over to it. Object/Archive already<br>
supports MemoryBuffer as a source for the data.<br>
</blockquote>
<br>
I had meant to ask in my email about the apparent duplication of Archive in Bitcode and Object libs… Good to know. Since ranlib currently uses Bitcode, that's what I've been focusing on, but I had noticed the Object/Archive.h.<br>
</blockquote>
<br>
Michael,<br>
I understand and agree that having 2 Archive implementations is something that should be fixed. Do you have a rough idea about when you might do the unification?<br>
Also, why unify around the Object/Archive implementation instead of the Bitcode/Archive implementation? What can the Object/Archive implementation "do" that can't be done with the Bitcode implementation?<br>
I ask because after looking at Archive in Object and Archive in Bitcode, the Archive in Bitcode seems much better documented than the Archive in Object, and feels (at least to me at first glance) like a somewhat better model of what Archives are. And as
you've already noted, Object/Archive can't do writes...<br>
<br>
Richard<br>
</blockquote>
<br>
I wrote Object/Archive for a couple reasons. The main reason was<br>
performance. Bitcode/Archive parses the entire archive file up front<br>
including the symbol table. Object/Archive does it lazily and uses<br>
much less memory.</blockquote>
<div><br>
</div>
I guess performance measurement depends on use… For what ar and the Linker do, using some memory to structure the archive's symbol table up front is worth the performance gain. As I read the Object/Archive implementation, each search for a symbol does a straight
linear scan of the archive symbol table in it's serialized form in memory… That's probably not very performant for the archives I have in mind - hundreds of modules with many thousands of symbols.</div>
<div><br>
</div>
<div>There are two static methods in Bitcode/Archive… one does read the entire archive (<span style="font-family: Menlo; font-size: 11px; ">OpenAndLoad)</span>, but the other reads only through the usual early members, including the symbol table (<span style="font-family: Menlo; font-size: 11px; ">OpenAndLoadSymbols</span>).
The Linker class uses this API, while ar and ranlib uses <span style="font-family: Menlo; font-size: 11px; ">OpenAndLoad.</span></div>
<div><br>
<blockquote type="cite">The other reason is that Bitcode/Archive is heavily<br>
focused on bitcode files. It even requires an LLVMContext to<br>
construct. This is was not optimal for my object file needs.<br>
</blockquote>
<div><br>
</div>
I think we could refactor Bitcode/Archive relatively simply to avoid requiring the Context at construction time, and require it only for methods that want a Module returned from Archive. We could change the constructor to accept a pointer to a Context instead
of a reference and use a default of 0. We could then add an optional parameter to the few operations that require a Context. And if at the point we actually need a Context, we still don't have one, use getGlobalContext() to acquire one.</div>
<div><br>
</div>
<div>It feels like what's desired is splitting Bitcode/Archive in two… a low-level, LLVM-neutral piece, and a higher-level, LLVM-dependent piece. Eliminating Context from the constructor goes part way to making Bitcode/Archive usable for low-level uses. Eliminating
the "automatic" production of the symbol table requires a bit more thought, but should be doable without too much effort. There are really only a handful of public methods that depend on it, and they have a lot of overlap with those that need a Context. Maybe
to support the slow, low-memory search of the symbol table member, we could add an additional method to do that. But I haven't found any users of Object/Archive's findSym() method yet, so maybe we don't need that at all.</div>
<div><br>
</div>
<div>And, of course, the static method to produce an Archive from memory instead of a file, which is pretty straight forward.</div>
<div><br>
</div>
<div>What do you think?</div>
<div><br>
</div>
<div>Richard</div>
</body>
</html>