aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Linker/LinkModules.cpp
AgeCommit message (Collapse)AuthorFilesLines
2012-11-27Remove the dependent libraries feature.Bill Wendling1-13/+0
The dependent libraries feature was never used and has bit-rotted. Remove it. llvm-svn: 168694
2012-08-03Move the "findUsedStructTypes" functionality outside of the Module class.Bill Wendling1-4/+5
The "findUsedStructTypes" method is very expensive to run. It needs to be optimized so that LTO can run faster. Splitting this method out of the Module class will help this occur. For instance, it can keep a list of seen objects so that it doesn't process them over and over again. llvm-svn: 161228
2012-06-23Extend the IL for selecting TLS models (PR9788)Hans Wennborg1-2/+2
This allows the user/front-end to specify a model that is better than what LLVM would choose by default. For example, a variable might be declared as @x = thread_local(initialexec) global i32 42 if it will not be used in a shared library that is dlopen'ed. If the specified model isn't supported by the target, or if LLVM can make a better choice, a different model may be used. llvm-svn: 159077
2012-05-09Supply a C interface to the "LinkModules" method.Bill Wendling1-0/+15
Patch by Andrew Wilkins! llvm-svn: 156469
2012-04-21Add a flag to the struct type finder to collect only those types which haveBill Wendling1-2/+2
names. This saves collecting types we normally don't care about. llvm-svn: 155300
2012-03-23It's possible for two types, which are isomorphic, to be added to theBill Wendling1-6/+25
destination module, but one of them isn't used in the destination module. If another module comes along and the uses the unused type, there could be type conflicts when the modules are finally linked together. (This happened when building LLVM.) The test that was reduced is: Module A: %Z = type { %A } %A = type { %B.1, [7 x x86_fp80] } %B.1 = type { %C } %C = type { i8* } declare void @func_x(%C*, i64, i64) declare void @func_z(%Z* nocapture) Module B: %B = type { %C.1 } %C.1 = type { i8* } %A.2 = type { %B.3, [5 x x86_fp80] } %B.3 = type { %C.1 } define void @func_z() { %x = alloca %A.2, align 16 %y = getelementptr inbounds %A.2* %x, i64 0, i32 0, i32 0 call void @func_x(%C.1* %y, i64 37, i64 927) nounwind ret void } declare void @func_x(%C.1*, i64, i64) declare void @func_y(%B* nocapture) (Unfortunately, this test doesn't fail under llvm-link, only during an LTO linking.) The '%C' and '%C.1' clash. The destination module gets the '%C' declaration. When merging Module B, it looks at the '%C.1' subtype of the '%B' structure. It adds that in, because that's cool. And when '%B.3' is processed, it uses the '%C.1'. But the '%B' has used '%C' and we prefer to use '%C'. So the '@func_x' type is changed to 'void (%C*, i64, i64)', but the type of '%x' in '@func_z' remains '%A.2'. The GEP resolves to a '%C.1', which conflicts with the '@func_x' signature. We can resolve this situation by making sure that the type is used in the destination before saying that it should be used in the module being merged in. With this fix, LLVM and Clang both compile under LTO. <rdar://problem/10913281> llvm-svn: 153351
2012-03-23Ignore the last message.Bill Wendling1-1/+3
llvm-svn: 153315
2012-03-23Revert patch. It broke the build.Bill Wendling1-3/+1
llvm-svn: 153314
2012-03-23Dematerialize the source functions after we're done with them. This saves a bitBill Wendling1-1/+3
of memory during LTO. llvm-svn: 153313
2012-03-22Some whitespace and comment cleanup.Bill Wendling1-5/+0
llvm-svn: 153278
2012-03-22Remove unneeded #ifdefs.Bill Wendling1-3/+1
llvm-svn: 153277
2012-03-22Add a 'dump' method to the type map. Doxygenify some of the comments and add aBill Wendling1-23/+36
few comments where none existed before. Also change a function's name to match the current coding standard. No functionality change. llvm-svn: 153276
2012-03-03Include cctype for isdigit. Patch by Stephen Hines.Duncan Sands1-0/+1
llvm-svn: 151973
2012-02-28Oops...Don't commit the other stuff..Bill Wendling1-44/+29
llvm-svn: 151618
2012-02-28Modify comment to reflect the importance of this code.Bill Wendling1-29/+44
llvm-svn: 151617
2012-02-27Add back removed code. It still causes LLVM to miscompile. But not having it ↵Bill Wendling1-0/+30
breaks other things. llvm-svn: 151594
2012-02-27Don't use #if 0. Just remove until I can address this.Bill Wendling1-35/+0
llvm-svn: 151580
2012-02-27The code that cleans up multiple, isomorphic types has a subtle error thatBill Wendling1-3/+7
manifests itself when building LLVM with LTO. <rdar://problem/10913281> llvm-svn: 151576
2012-02-14Capitalize messages so that they appear nicely with the linker's error messages.Bill Wendling1-9/+9
llvm-svn: 150466
2012-02-11[WIP] Initial code for module flags.Bill Wendling1-5/+186
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
2012-02-07Convert assert(0) to llvm_unreachableCraig Topper1-1/+1
llvm-svn: 149967
2012-01-25use Constant::getAggregateElement to simplify a bunch of code.Chris Lattner1-15/+4
llvm-svn: 148934
2012-01-24add more support for ConstantDataSequentialChris Lattner1-18/+21
llvm-svn: 148802
2012-01-05Link symbols with different visibilities according to the rules in theRafael Espindola1-24/+54
System V Application Binary Interface. This lets us use -fvisibility-inlines-hidden with LTO. Fixes PR11697. llvm-svn: 147624
2011-12-23When not destroying the source, the linker is not remapping the types. Added ↵Mon P Wang1-1/+1
support to CloneFunctionInto to allow remapping for this case. llvm-svn: 147217
2011-12-20Fix a nasty bug in the type remapping stuff that I added that is breaking ↵Chris Lattner1-1/+8
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
2011-12-20Now that PR11464 is fixed, reapply the patch to fix PR11464, Chris Lattner1-0/+25
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
2011-12-20fix PR11464 by preventing the linker from mapping two different struct types ↵Chris Lattner1-12/+27
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
2011-12-17Revert 146728 as it's causing failures on some of the external bots as well as Chad Rosier1-25/+0
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
2011-12-16By popular demand, link up types by name if they are isomorphic and one is anChris Lattner1-0/+25
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
2011-11-02Add support to the linker to lazily link in functions. This change only ↵Tanya Lattner1-0/+58
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
2011-10-30Teach ModuleLinker::getLinkageResult about materialisable functionsPeter Collingbourne1-1/+1
llvm-svn: 143316
2011-10-14Allow the source module to be materialized during the linking process.Tanya Lattner1-2/+11
llvm-svn: 142010
2011-10-11Make it possible to use the linker without destroying the source module. ↵Tanya Lattner1-30/+55
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
2011-08-12switch to the new struct api.Chris Lattner1-3/+3
llvm-svn: 137482
2011-08-04Linke NamedMDNodes after linking global values as comment suggests.Devang Patel1-5/+5
llvm-svn: 136909
2011-07-18Migrate LLVM and Clang to use the new makeArrayRef(...) functions where ↵Frits van Bommel1-1/+1
previously explicit non-default constructors were used. Mostly mechanical with some manual reformatting. llvm-svn: 135390
2011-07-14Link NamedMDNode before linking function bodies.Devang Patel1-5/+5
llvm-svn: 135204
2011-07-14simplify this logic now that GlobalAlias::isDeclaration is fixed.Chris Lattner1-4/+2
llvm-svn: 135183
2011-07-09Land the long talked about "type system rewrite" patch. ThisChris Lattner1-1074/+742
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
2011-03-29Set the unnamed_addr only when we're creating a new GV in the dest module.Bill Wendling1-0/+1
llvm-svn: 128507
2011-03-29Revert r128501. It caused test failures.Bill Wendling1-1/+0
llvm-svn: 128506
2011-03-29We need to copy over the unnamed_addr attribute.Bill Wendling1-0/+1
llvm-svn: 128501
2011-02-01Correctly merge available_externally and regular definitions when they haveRafael Espindola1-2/+4
different visibilities. llvm-svn: 124650
2011-01-15Allow unnamed_addr on declarations.Rafael Espindola1-3/+7
llvm-svn: 123529
2011-01-13Keep unnamed_addr when linking.Rafael Espindola1-0/+2
llvm-svn: 123364
2011-01-08Revamp the ValueMapper interfaces in a couple ways:Chris Lattner1-29/+6
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
2010-12-30include the module identifier when emitting this warning, PR8865.Chris Lattner1-4/+7
llvm-svn: 122637
2010-12-30print the right string, thanks for Frits for noticing.Chris Lattner1-1/+1
llvm-svn: 122636
2010-12-29improve warning message to at least say what the triples are.Chris Lattner1-1/+3
llvm-svn: 122632
generated by cgit v1.1 at 2025-10-19 05:25:55 +0000