llvm-svn: 143316

llvm-svn: 142010

Make it possible to use the linker without destroying the source module. This is so the source module can be linked to multiple other destination modules. For all that used LinkModules() before, they will continue to destroy the source module as before.

This line, and those below, will be ignored--

M    include/llvm/Linker.h
M    tools/bugpoint/Miscompilation.cpp
M    tools/bugpoint/BugDriver.cpp
M    tools/llvm-link/llvm-link.cpp
M    lib/Linker/LinkModules.cpp

llvm-svn: 141606

It happens (for example) when you want to have a dependency on the .so
with the specific version, like liblzma.so.1.0.0 or
libcrypto.so.0.9.8.

llvm-svn: 140201

llvm-svn: 137482

llvm-svn: 136909

specified in the same file that the library itself is created. This is
more idiomatic for CMake builds, and also allows us to correctly specify
dependencies that are missed due to bugs in the GenLibDeps perl script,
or change from compiler to compiler. On Linux, this returns CMake to
a place where it can relably rebuild several targets of LLVM.

I have tried not to change the dependencies from the ones in the current
auto-generated file. The only places I've really diverged are in places
where I was seeing link failures, and added a dependency. The goal of
this patch is not to start changing the dependencies, merely to move
them into the correct location, and an explicit form that we can control
and change when necessary.

This also removes a serialization point in the build because we don't
have to scan all the libraries before we begin building various tools.
We no longer have a step of the build that regenerates a file inside the
source tree. A few other associated cleanups fall out of this.

This isn't really finished yet though. After talking to dgregor he urged
switching to a single CMake macro to construct libraries with both
sources and dependencies in the arguments. Migrating from the two macros
to that style will be a follow-up patch.

Also, llvm-config is still generated with GenLibDeps.pl, which means it
still has slightly buggy dependencies. The internal CMake
'llvm-config-like' macro uses the correct explicitly specified
dependencies however. A future patch will switch llvm-config generation
(when using CMake) to be based on these deps as well.

This may well break Windows. I'm getting a machine set up now to dig
into any failures there. If anyone can chime in with problems they see
or ideas of how to solve them for Windows, much appreciated.

llvm-svn: 136433

Migrate LLVM and Clang to use the new makeArrayRef(...) functions where previously explicit non-default constructors were used.
Mostly mechanical with some manual reformatting.

llvm-svn: 135390

llvm-svn: 135204

llvm-svn: 135183

patch brings numerous advantages to LLVM.  One way to look at it
is through diffstat:
 109 files changed, 3005 insertions(+), 5906 deletions(-)

Removing almost 3K lines of code is a good thing.  Other advantages
include:

1. Value::getType() is a simple load that can be CSE'd, not a mutating
   union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
   uniques them.  This means that the compiler doesn't merge them structurally
   which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
   struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
   in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead 
   "const Type *" everywhere.

Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.  
"LLVM 3.0" is the right time to do this.

There are still some cleanups pending after this, this patch is large enough
as-is.

llvm-svn: 134829

llvm-svn: 128507

llvm-svn: 128506

llvm-svn: 128501

different visibilities.

llvm-svn: 124650

llvm-svn: 123529

llvm-svn: 123364

1. Take a flags argument instead of a bool.  This makes
   it more clear to the reader what it is used for.
2. Add a flag that says that "remapping a value not in the
   map is ok".
3. Reimplement MapValue to share a bunch of code and be a lot
   more efficient.  For lookup failures, don't drop null values
   into the map.
4. Using the new flag a bunch of code can vaporize in LinkModules
   and LoopUnswitch, kill it.

No functionality change.

llvm-svn: 123058

llvm-svn: 122637

llvm-svn: 122636

llvm-svn: 122632

llvm-svn: 122158

llvm-svn: 122157

the buildbots.

llvm-svn: 122149

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