The main observation is that we never need both the filesize and the map size.
When mapping a slice of a file, it doesn't make sense to request a null
terminator and that would be the only case where the filesize would be used.

There are other cleanups that should be done in this area:

* A client should not have to pass the size (even an explicit -1) to say if
  it wants a null terminator or not, so we should probably swap the argument
  order.
* The default should be to not require a null terminator. Very few clients
  require this, but many end up asking for it just because it is the default.

llvm-svn: 186984

The linker will call `lto_codegen_add_must_preserve_symbol' on all globals that
should be kept around. The linker will pretend that a dylib is being created.
<rdar://problem/12528059>

llvm-svn: 169770

This function sets the `_exportDynamic' ivar. When that's set, we export all
symbols (e.g. we don't run the internalize pass). This is equivalent to the
`--export-dynamic' linker flag in GNU land:

--export-dynamic
  When creating a dynamically linked executable, add all symbols to the dynamic
  symbol table. The dynamic symbol table is the set of symbols which are visible
  from dynamic objects at run time. If you do not use this option, the dynamic
  symbol table will normally contain only those symbols which are referenced by
  some dynamic object mentioned in the link. If you use dlopen to load a dynamic
  object which needs to refer back to the symbols defined by the program, rather
  than some other dynamic object, then you will probably need to use this option
  when linking the program itself.

The Darwin linker will support this via the `-export_dynamic' flag. We should
modify clang to support this via the `-rdynamic' flag.

llvm-svn: 169656

Again, tools are trickier to pick the main module header for than
library source files. I've started to follow the pattern of using
LLVMContext.h when it is included as a stub for program source files.

llvm-svn: 169252

so we don't want it to show up in the stable 3.1 interface.

While at it, add a comment about why LTOCodeGenerator manually creates the
internalize pass.

llvm-svn: 154807

llvm-svn: 154312

llvm-svn: 154306

llvm-svn: 153802

llvm-svn: 153740

Luis Felipe Strano Moraes!

llvm-svn: 129558

memory and writing it back to disk.

llvm-svn: 128108

of an file.

llvm-svn: 127781

6m30.

llvm-svn: 126426

MemoryBuffer::getOpenFile to not close the file descriptor.

llvm-svn: 125128

This means avoid using uint32_t. This patch reverts r112200 and fixes original  problem by fixing argument type in lto.cpp.

llvm-svn: 123038

llvm-svn: 112200

llvm-svn: 110759

Nick, please review.

llvm-svn: 110705

gold plugin.

llvm-svn: 110604

llvm-svn: 77960

llvm-svn: 74774

llvm-svn: 74678

llvm-svn: 74640

Add a pointer to the owning LLVMContext to Module.  This requires threading LLVMContext through a lot
of the bitcode reader and ASM parser APIs, as well as supporting it in all of the tools.

Patches for Clang and LLVM-GCC to follow.

llvm-svn: 74614

llvm-svn: 74281

Add lto_codegen_set_assembler_path() API which allows the linker to specify the
path to the assembler tool to run.  When assembler is used (instead of compiler)
different command line options are used.
Add LTO_API_VERSION #define so clients (linkers) can conditionalize use of new APIs.

llvm-svn: 72823

run when assembling.

Wire this up to the gold plugin. You can now pass --plugin-opt gcc=/foo/bar/gcc
and it will run that gcc instead of looking for it on the path.

llvm-svn: 70490

llvm-svn: 53249

llvm-svn: 53119

Rename new lto2 tool as lto.
lto2->lto

llvm-svn: 52912

llvm-svn: 47695

first commit of new LTO system.  It is not hooked up in the llvm/tools/Makefile, so no one will build it be default yet

llvm-svn: 47621