llvm-svn: 122142

llvm-svn: 122141

llvm-svn: 121958

llvm-svn: 121379

llvm-svn: 120298

This allows using GetDLLSuffix() with appendSuffix().

llvm-svn: 118051

llvm-svn: 118050

llvm-svn: 116788

llvm-svn: 115827

fix is trying to accomplish.

This code could still use some polishing.

llvm-svn: 115759

source module *and* it must be merged (instead of simply replaced or appended
to), then merge instead of replacing or adding another global.

The ObjC __image_info section was being appended to because of this
failure. This caused a crash because the linker expects the image info section
to be a specific size.

<rdar://problem/8198537>

llvm-svn: 115753

This reverts commit r113632

Conflicts:

	cmake/modules/AddLLVM.cmake

llvm-svn: 113819

llvm-svn: 113632

llvm-svn: 112713

fix: add a flag to MapValue and friends which indicates whether
any module-level mappings are being made. In the common case of
inlining, no module-level mappings are needed, so MapValue doesn't
need to examine non-function-local metadata, which can be very
expensive in the case of a large module with really deep metadata
(e.g. a large C++ program compiled with -g).

This flag is a little awkward; perhaps eventually it can be moved
into the ClonedCodeInfo class.

llvm-svn: 112190

individual ...", which depends on r111922, which I am reverting.

llvm-svn: 112157

instructions, not when remapping modules.

llvm-svn: 112091

- Support the LinkerWeak*Linkage types in llvm-nm and in LinkModules.cpp.

llvm-svn: 111952

which reference GlobalValues are properly remapped.

llvm-svn: 111949

llvm-svn: 111948

which does the same thing. This eliminates redundant code and
handles MDNodes better. MDNode linking still doesn't fully
work yet though.

llvm-svn: 111941

llvm-svn: 111933

llvm-svn: 111102

llvm-svn: 111082

for creating and populating NamedMDNodes.

llvm-svn: 109061

llvm-svn: 107215

metadata types which should be marked as "weak", but which the linker will
remove upon final linkage. For example, the "objc_msgSend_fixup_alloc" symbol is
defined like this:

       .globl l_objc_msgSend_fixup_alloc
       .weak_definition l_objc_msgSend_fixup_alloc
       .section __DATA, __objc_msgrefs, coalesced
       .align 3
l_objc_msgSend_fixup_alloc:
        .quad   _objc_msgSend_fixup
        .quad   L_OBJC_METH_VAR_NAME_1

This is different from the "linker_private" linkage type, because it can't have
the metadata defined with ".weak_definition".

llvm-svn: 107205

llvm-svn: 104855

separate canRead() call.

llvm-svn: 104853

methods to try to have the type predicates be more logically positioned.

llvm-svn: 96349

llvm-svn: 95468

Need to recurse for all operands of function-local metadata; and handle Instructions (which map to themselves)

llvm-svn: 94691

Modules and ModuleProviders. Because the "ModuleProvider" simply materializes
GlobalValues now, and doesn't provide modules, it's renamed to
"GVMaterializer". Code that used to need a ModuleProvider to materialize
Functions can now materialize the Functions directly. Functions no longer use a
magic linkage to record that they're materializable; they simply ask the
GVMaterializer.

Because the C ABI must never change, we can't remove LLVMModuleProviderRef or
the functions that refer to it. Instead, because Module now exposes the same
functionality ModuleProvider used to, we store a Module* in any
LLVMModuleProviderRef and translate in the wrapper methods.  The bindings to
other languages still use the ModuleProvider concept.  It would probably be
worth some time to update them to follow the C++ more closely, but I don't
intend to do it.

Fixes http://llvm.org/PR5737 and http://llvm.org/PR5735.

llvm-svn: 94686

llvm-svn: 94650

llvm-svn: 94632

llvm-svn: 94378

llvm-svn: 94243

missing ones are libsupport, libsystem and libvmcore.  libvmcore is
currently blocked on bugpoint, which uses EH.  Once it stops using
EH, we can switch it off.

This #if 0's out 3 unit tests, because gtest requires RTTI information.
Suggestions welcome on how to fix this.

llvm-svn: 94164

Fixed linking of modules containing aliases to constant bitcasts.  Existing behaviour first tried to replace the aliases with the global that they aliased (rather than the bitcast), causing a crash on an assert because the types didn't match.  When this was fixed, it then did the same thing creating the new alias (creating an alias with a different type to its aliasee).  

Linking modules containing aliases to GEPs is still not quite right.  GEPs that are equivalent to bitcasts will be replaced by bitcasts, GEPs that are not will just break.  Aliases to GEPs that are not equivalent to bitcasts are horribly broken anyway (it might be worth adding an assert when creating the alias to prevent these being created; they just cause problems later).

llvm-svn: 93052

llvm-svn: 92674