| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 150466
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Module flags are key-value pairs associated with the module. They include a
'behavior' value, indicating how module flags react when mergine two
files. Normally, it's just the union of the two module flags. But if two module
flags have the same key, then the resulting flags are dictated by the behaviors.
Allowable behaviors are:
Error
Emits an error if two values disagree.
Warning
Emits a warning if two values disagree.
Require
Emits an error when the specified value is not present
or doesn't have the specified value. It is an error for
two (or more) llvm.module.flags with the same ID to have
the Require behavior but different values. There may be
multiple Require flags per ID.
Override
Uses the specified value if the two values disagree. It
is an error for two (or more) llvm.module.flags with the
same ID to have the Override behavior but different
values.
llvm-svn: 150300
|
|
|
|
| |
llvm-svn: 149967
|
|
|
|
| |
llvm-svn: 148934
|
|
|
|
| |
llvm-svn: 148802
|
|
|
|
|
|
|
|
| |
System V Application Binary Interface. This lets us use
-fvisibility-inlines-hidden with LTO.
Fixes PR11697.
llvm-svn: 147624
|
|
|
|
|
|
|
|
| |
support
to CloneFunctionInto to allow remapping for this case.
llvm-svn: 147217
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
kc++ on
the build bot in some cases. The basic issue happens when a source module contains
both a "%foo" type and a "%foo.42" type. It will see the later one, check to see if
the destination module contains a "%foo" type, and it will return true... because
both the source and destination modules are in the same LLVMContext. We don't want
to map source types to other source types, so don't do the remapping if the mapped
type came from the source module.
Unfortunately, I've been unable to reduce a decent testcase for this, kc++ is
pretty great that way.
llvm-svn: 147010
|
|
|
|
|
|
|
|
| |
merging types by name when we can. We still don't guarantee type name linkage
but we do it when obviously the right thing to do. This makes LTO type names
easier to read, for example.
llvm-svn: 146932
|
|
|
|
|
|
| |
from the source module onto the same opaque destination type. An opaque type can only be resolved to one thing or another after all.
llvm-svn: 146929
|
|
|
|
|
|
|
|
|
|
|
| |
internal nightly testers. Original commit message:
By popular demand, link up types by name if they are isomorphic and one is an
autorenamed version of the other. This makes the IR easier to read, because
we don't end up with random renamed versions of the types after LTO'ing a large
app.
llvm-svn: 146838
|
|
|
|
|
|
|
| |
autorenamed version of the other. This makes the IR easier to read, because
we don't end up with random renamed versions of the types after LTO'ing a large app.
llvm-svn: 146728
|
|
|
|
|
|
| |
links functions marked with specific linkage (internal, private, linker_private, linker_private_weak, linker_private_weak_def_auto, linkonce, linkonce_odr, and available_externally) if they have uses in the destination module. Instead of automatically linking, these functions are placed onto a worklist to be processed in the final stage of linking. We iterate over the list and if any functions on the list have uses in the destination module, we link them in and repeat the process until no changes in the state (uses) has changed. This means that any functions in the LazilyLink worklist that have a use in the destination module will be linked in and none that don't.
llvm-svn: 143524
|
|
|
|
| |
llvm-svn: 143316
|
|
|
|
| |
llvm-svn: 142010
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 137482
|
|
|
|
| |
llvm-svn: 136909
|
|
|
|
|
|
|
|
| |
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: 120298
|
|
|
|
| |
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
|
|
|
|
| |
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
|