[LLVMdev] LLVM Archive Format Extension Proposal

[Relph, Richard]

On Nov 24, 2012, at 2:48 PM, Nick Kledzik <kledzik at apple.com<mailto:kledzik at apple.com>> wrote:

On Nov 21, 2012, at 4:00 PM, Relph, Richard wrote:
On Nov 21, 2012, at 11:07 AM, Nick Kledzik <kledzik at apple.com<mailto:kledzik at apple.com>> wrote:
On Nov 21, 2012, at 8:55 AM, Relph, Richard wrote:
AMD would like to add new functionality to ranlib (and later ar and nm) and to the bits of LLVM Core that read (and later write) archives.
Herewith a terse summary of the change, which we want to improve support of OpenCL for multiple GPUs in a single run-time.

Conceptually, a serialized archive is really 2 pieces: a few header members and a set of normal file members. There are no constraints on the normal members in the 'pure' archive format. They could be text files, pictures, or, as we're all familiar with, object modules. Most object file archives are "libraries" and the have a special header member that is a global symbol table, associating global scope names with defining object module members in the archive body.

We have N very large archives, defining essentially the same set of symbols. Many of the normal file members of each are duplicated in other archives, but not all. The goal is the produce a single "super-archive" that contains 1 copy of each unique object file member no matter how many archives it is part of, and N symbol table members representing each of the original N archives.
Let me see if I understand your need here.  You are dynamically generating code and need to link it.  The linking step requires some support routines which makes sense to have in a static library.  Since this must work on machines not set up with developer tools, you are packaging the static library inside a DLL/DSO.  In addition, with all the minor variations of GPUs, having a separate archive for every GPU type would be too large, so you need some way to remove duplicates of support functions.

Close. But it isn't "support routines". It's the entire OpenCL "built-in" library… thousands and thousands of functions, some tiny, some large, some merely aliases.

If the above summary is close, then here are two other ideas that avoid the need for archive/TOC changes:
1) Have lots of little archives which removes duplicates.  Give each archive a unique name, then have a lookup table which lists which sequence of archives to use for which specific GPU.  When linking for a particular GPU, you pass the linker that particular sequence of little archives to search.

This is close to what we have now, but find unworkable because the Linker doesn't take a "set" of libraries. So if library A calls something in B calls something in A, you end up having to make multiple passes over the libraries, which isn't efficient and creates other headaches. This is what we are trying to 'solve' by going to a single library, but we want to preserve the space advantage of the current approach.

The gnu linker has the option:
  --start-group archives --end-group
which tells the linker to keep searching the list of archives (not just make one pass).   The darwin linker does this by default.

BTW, I had assumed you were using the "system linker".   But that won't work if you are adding some new kind of archive table of contents.  I guess that means you have some in-process code that provides linking functionality?  If so, I'd like to understand this better to see if this is something lld <http://lld.llvm.org/> might want to support some day.

We are using the Linker class, which uses the Bitcode/Archive class, which is why I was focusing on that class to support the new functionality.
Once I have Bitcode/Archive enhanced, and llvm-ar generates the new "multi-archives", I was going to add a method to the Linker class to support linking "in-memory archives"… not strictly part of the Archive enhancements, but something we else we need.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121206/26fce778/attachment.html>