Hi,
I was thinking about the potential for link-time optimizations. And the fact that you already now output LLVM bitcode to object files, archives, and perhaps even executables (that would give a .NET flavor to LLVM, I wonder if this can be made to work seamlessly on Windows [1]). Then I thought about the fact that you seem intent on supporting all native formats that you run into.
I was then thinking something along this path: “What if we were to create a new set of binary formats just for LLVM, that people can use if they prefer clang(++)?”
It is probably me that is something wrong with, but I have a strong dislike for the existing object, archive, and executable formats. For one, most of them are designed in such a way that you’d think there was something mentally wrong with the guys who designed them. Look at COFF strings, for instance, and notice how complicated it is to decode a COFF string when all you ought to do was to look up an offset into a string table. And so on with the various formats.
What do you nowadays with LLVM extensions? Do you encode them in the bitcode that you output to object files or what. I’m thinking of all the information that usually gets lots when you output an ordinary object file: pretty much all but the binary image and a set public symbols and relocations.
My angle to LLVM is this: LLVM is the future, GCC is the past. Not all may agree with me, but I think we’ll see GCC fade away as clang/clang++ become more widely used. So why accept the limitations of GCC object file formats?
I am not trying to start a flame war or anything. I can be told to shut up if I produce too many stupid questions in too short a time 
[1] It can. Simply reserve a specific extension, such as “lbc” (LLVM BitCode), to the file type and then define a system-wide association to the bitcode interpreter, and you’re all set.
Cheers,
Mikael
– The Day You Stop Wondering Is the Day You Died.