Pass a && to getLazyBitcodeModule.

This forces callers to use std::move when calling it. It is somewhat odd to have
code with std::move that doesn't always move, but it is also odd to have code
with

Pass a && to getLazyBitcodeModule.

This forces callers to use std::move when calling it. It is somewhat odd to have
code with std::move that doesn't always move, but it is also odd to have code
without std::move that sometimes moves.

llvm-svn: 217049

show more ...

Pass a std::unique_ptr<MemoryBuffer>& to getLazyBitcodeModule.

By taking a reference we can do the ownership transfer in one place instead of
expecting every caller to do it.

llvm-svn: 216492

Pass a MemoryBufferRef when we can avoid taking ownership.

The attached patch simplifies a few interfaces that don't need to take
ownership of a buffer.

For example, both parseAssembly and parseBit

Pass a MemoryBufferRef when we can avoid taking ownership.

The attached patch simplifies a few interfaces that don't need to take
ownership of a buffer.

For example, both parseAssembly and parseBitcodeFile will parse the
entire buffer before returning. There is no need to take ownership.

Using a MemoryBufferRef makes it obvious in the type signature that
there is no ownership transfer.

llvm-svn: 216488

show more ...

Explicitly pass ownership of the MemoryBuffer to AddNewSourceBuffer using std::unique_ptr

llvm-svn: 216223

Don't own the buffer in object::Binary.

Owning the buffer is somewhat inflexible. Some Binaries have sub Binaries
(like Archive) and we had to create dummy buffers just to handle that. It is
also a

Don't own the buffer in object::Binary.

Owning the buffer is somewhat inflexible. Some Binaries have sub Binaries
(like Archive) and we had to create dummy buffers just to handle that. It is
also a bad fit for IRObjectFile where the Module wants to own the buffer too.

Keeping this ownership would make supporting IR inside native objects
particularly painful.

This patch focuses in lib/Object. If something elsewhere used to own an Binary,
now it also owns a MemoryBuffer.

This patch introduces a few new types.

* MemoryBufferRef. This is just a pair of StringRefs for the data and name.
This is to MemoryBuffer as StringRef is to std::string.
* OwningBinary. A combination of Binary and a MemoryBuffer. This is needed
for convenience functions that take a filename and return both the
buffer and the Binary using that buffer.

The C api now uses OwningBinary to avoid any change in semantics. I will start
a new thread to see if we want to change it and how.

llvm-svn: 216002

show more ...

Make RecordStreamer.h private.

llvm-svn: 212361

Ignore llvm.* globals.

It is not clear if llvm.global_ctors should or should not be in llvm.metadata,
but in practice it is not and we need to ignore it for LTO.

llvm-svn: 212351

Implement LTOModule on top of IRObjectFile.

IRObjectFile provides all the logic for producing mangled names and getting
symbols from inline assembly.

LTOModule then adds logic for linking specific

Implement LTOModule on top of IRObjectFile.

IRObjectFile provides all the logic for producing mangled names and getting
symbols from inline assembly.

LTOModule then adds logic for linking specific tasks, like constructing
llvm.compiler_user or extracting linker options from the bitcode.

The rule of the thumb is that IRObjectFile has the functionality that is
needed by both LTO and llvm-ar.

llvm-svn: 212349

show more ...

Mark intrinsic functions as llvm-specific.

llvm-svn: 212347

Don't include llvm.metadata variables in archive symbol tables.

llvm-svn: 212344

Move createIRObjectFile to the IRObjectFile class and return the concrete type.

llvm-svn: 212301

Add support for inline asm symbols to IRObjectFile.

This also enables it in llvm-nm so that it can be tested.

llvm-svn: 212282

Pass a unique_ptr<MemoryBuffer> to the constructors in the Binary hierarchy.

Once the objects are constructed, they own the buffer. Passing a unique_ptr
makes that clear.

llvm-svn: 211595

Make ObjectFile and BitcodeReader always own the MemoryBuffer.

This allows us to just use a std::unique_ptr to store the pointer to the buffer.
The flip side is that they have to support releasing t

Make ObjectFile and BitcodeReader always own the MemoryBuffer.

This allows us to just use a std::unique_ptr to store the pointer to the buffer.
The flip side is that they have to support releasing the buffer back to the
caller.

Overall this looks like a more efficient and less brittle api.

llvm-svn: 211542

show more ...

Change IRObjectFile to parse the bitcode lazily.

The main point of this class is to provide a cheap object interface to a bitcode
file, so it has to be as lazy as possible.

llvm-svn: 211207

Remove 'using std::errro_code' from lib.

llvm-svn: 210871

Don't use 'using std::error_code' in include/llvm.

This should make sure that most new uses use the std prefix.

llvm-svn: 210835

Remove the linker_private and linker_private_weak linkages.

These linkages were introduced some time ago, but it was never very
clear what exactly their semantics were or what they should be used
fo

Remove the linker_private and linker_private_weak linkages.

These linkages were introduced some time ago, but it was never very
clear what exactly their semantics were or what they should be used
for. Some investigation found these uses:

* utf-16 strings in clang.
* non-unnamed_addr strings produced by the sanitizers.

It turns out they were just working around a more fundamental problem.
For some sections a MachO linker needs a symbol in order to split the
section into atoms, and llvm had no idea that was the case. I fixed
that in r201700 and it is now safe to use the private linkage. When
the object ends up in a section that requires symbols, llvm will use a
'l' prefix instead of a 'L' prefix and things just work.

With that, these linkages were already dead, but there was a potential
future user in the objc metadata information. I am still looking at
CGObjcMac.cpp, but at this point I am convinced that linker_private
and linker_private_weak are not what they need.

The objc uses are currently split in

* Regular symbols (no '\01' prefix). LLVM already directly provides
whatever semantics they need.
* Uses of a private name (start with "\01L" or "\01l") and private
linkage. We can drop the "\01L" and "\01l" prefixes as soon as llvm
agrees with clang on L being ok or not for a given section. I have two
patches in code review for this.
* Uses of private name and weak linkage.

The last case is the one that one could think would fit one of these
linkages. That is not the case. The semantics are

* the linker will merge these symbol by *name*.
* the linker will hide them in the final DSO.

Given that the merging is done by name, any of the private (or
internal) linkages would be a bad match. They allow llvm to rename the
symbols, and that is really not what we want. From the llvm point of
view, these objects should really be (linkonce|weak)(_odr)?.

For now, just keeping the "\01l" prefix is probably the best for these
symbols. If we one day want to have a more direct support in llvm,
IMHO what we should add is not a linkage, it is just a hidden_symbol
attribute. It would be applicable to multiple linkages. For example,
on weak it would produce the current behavior we have for objc
metadata. On internal, it would be equivalent to private (and we
should then remove private).

llvm-svn: 203866

show more ...

Replace OwningPtr<T> with std::unique_ptr<T>.

This compiles with no changes to clang/lld/lldb with MSVC and includes
overloads to various functions which are used by those projects and llvm
which ha

Replace OwningPtr<T> with std::unique_ptr<T>.

This compiles with no changes to clang/lld/lldb with MSVC and includes
overloads to various functions which are used by those projects and llvm
which have OwningPtr's as parameters. This should allow out of tree
projects some time to move. There are also no changes to libs/Target,
which should help out of tree targets have time to move, if necessary.

llvm-svn: 203083

show more ...

[C++11] Replace OwningPtr::take() with OwningPtr::release().

llvm-svn: 202957

Now that it is possible, use the mangler in IRObjectFile.

A really simple patch marks the end of a lot of yak shaving :-)

llvm-svn: 202463

Add missing include.

Should fix the bots.

llvm-svn: 201882

Add a SymbolicFile interface between Binary and ObjectFile.

This interface allows IRObjectFile to be implemented without having dummy
methods for all section and segment related methods.

Both llvm-

Add a SymbolicFile interface between Binary and ObjectFile.

This interface allows IRObjectFile to be implemented without having dummy
methods for all section and segment related methods.

Both llvm-ar and llvm-nm are changed to use it. Unfortunately the mangler is
still not plugged in since it requires some refactoring to make a Module hold
a DataLayout.

llvm-svn: 201881

show more ...