[PATCH] LTO: introduce object file-based on-disk module format.

[Rafael Ávila de Espíndola]

+  /// Returns 'true' if the bitcode bc is for the specified target triple.
+  static bool isTargetMatch(StringRef bc, const char *triplePrefix);

Using a StringRef is a nice independent improvement in here
(isTargetMatch), please commit it first. Nit: take the opportunity to
rename the argument names to match the llvm style.


 LTOModule *LTOModule::createFromBuffer(const void *mem, size_t length,
                                        TargetOptions options,
                                        std::string &errMsg, StringRef path) {
   std::unique_ptr<MemoryBuffer> buffer(makeBuffer(mem, length, path));
   if (!buffer)
     return nullptr;
-  return makeLTOModule(buffer.release(), options, errMsg);
+  return makeLTOModule(StringRef((const char *)mem, length), options, errMsg);

The buffer is not need in here anymore, is it?


-  return makeLTOModule(buffer.release(), options, errMsg);
+  return makeLTOModule(buffer->getBuffer(), options, errMsg);

The MemoryBuffer is now destroyed immediately instead of being
transferred into the produced LTOModule. This would work with the
current setup, except you also do

-  m->materializeAllPermanently();

Which means the IRReader will be pointed to unmapped memory, no?

BTW, the materializeAllPermanently is a very unfortunate but necessary
thing for the C api. The reason it is there is the way ld64 implements
an optimization:

* We want to avoid putting linkonce_odr symbols in the symbol table
unless their address is significant.
* The way ld64 implements this is being told for every symbol if it
can be dropped from the symbol table.
* To tell ld64 about that we need to look at every use of a symbol.
* To look at every use of a symbol we have to materialize all function
bodies since they may contain an use.


Two higher level questions about this approach:

* It is effectively a way of doing fat object files. GCC does
something similar. One small but recurring annoyance I had when
working with GCC LTO is that it can end up falling back silently to
non-LTO since tho outer container is ELF, with IR in a section. With
LLVM right now we get an error, since without our help the linker is
clueless as to what LLVM IR is. Can't you invert this? Put the ELF in
the IR (or even represent .go_export directly in some metadata) and
extent the gold plugin API to handle this? Another advantage is that
it should be easier to support fat COFF and MachO objects too.

* If we do need to go with IR in ELF instead of ELF in IR, we also
need to update lib/Object to handle it. We still want to get an
IRObjectFile (by default at least) when given one of those files so
that llvm-nm/llvm-ar do the right thing.

http://reviews.llvm.org/D4371