summaryrefslogtreecommitdiffstats
path: root/llvm/test/Linker
Commit message (Collapse)AuthorAgeFilesLines
...
* [ThinLTO] Find all needed metadata when linking metadata as postpassTeresa Johnson2016-01-251-3/+13
| | | | | | | | | For metadata postpass linking, after importing all functions, we need to recursively walk through any nodes reached via imported functions to locate needed subprogram metadata. Some might only be reached indirectly via the variable list for an inlined function. llvm-svn: 258728
* [ThinLTO] Handle DISubprogram reached indirectly from DIImportedEntityTeresa Johnson2016-01-251-2/+24
| | | | | | | Extend fix for PR26037 to identify DISubprogram reached from a DIImportedEntity via a DILexicalBlock. llvm-svn: 258722
* Revert obsolete llvm-link -preserve-modules option/testTeresa Johnson2016-01-211-5/+0
| | | | | | | This testing mode is now obsolete with the change to linkInModule to take a std::unique_ptr to Module. llvm-svn: 258399
* Fix PR26152.Evgeniy Stepanov2016-01-202-0/+31
| | | | | | | | Fix the condition for when the new global takes over the name of the existing one to be the negation of the condition for the new global to get internal linkage. llvm-svn: 258355
* Reapply r257105 "[Verifier] Check that debug values have proper size"Keno Fischer2016-01-154-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I originally reapplied this in 257550, but had to revert again due to bot breakage. The only change in this version is to allow either the TypeSize or the TypeAllocSize of the variable to be the one represented in debug info (hopefully in the future we can figure out how to encode the difference). Additionally, several bot failures following r257550, were due to optimizer bugs now fixed in r257787 and r257795. r257550 commit message was: ``` The follow extra changes were made to test cases: Manually making the variable be the actual type instead of a pointer to avoid pointer-size differences in generic code: LLVM :: DebugInfo/Generic/2010-03-24-MemberFn.ll LLVM :: DebugInfo/Generic/2010-04-06-NestedFnDbgInfo.ll LLVM :: DebugInfo/Generic/2010-05-03-DisableFramePtr.ll LLVM :: DebugInfo/Generic/varargs.ll Delete sizing information from debug info for the same reason (but the presence of the pointer was important to the test case): LLVM :: DebugInfo/Generic/restrict.ll LLVM :: DebugInfo/Generic/tu-composite.ll LLVM :: Linker/type-unique-type-array-a.ll LLVM :: Linker/type-unique-simple2.ll Fixing an incorrect DW_OP_deref LLVM :: DebugInfo/Generic/2010-05-03-OriginDIE.ll Fixing a missing DW_OP_deref LLVM :: DebugInfo/Generic/incorrect-variable-debugloc.ll Additionally, clang should no longer complain during bootstrap should no longer happen after r257534. The original commit message was: `` Summary: Teach the Verifier to make sure that the storage size given to llvm.dbg.declare or the value size given to llvm.dbg.value agree with what is declared in DebugInfo. This is implicitly assumed in a number of passes (e.g. in SROA). Additionally this catches a number of common mistakes, such as passing a pointer when a value was intended or vice versa. One complication comes from stack coloring which modifies the original IR when it merges allocas in order to make sure that if AA falls back to the IR it gets the correct result. However, given this new invariant, indiscriminately replacing one alloca by a different (differently sized one) is no longer valid. Fix this by just undefing out any use of the alloca in a dbg.declare in this case. Additionally, I had to fix a number of test cases. Of particular note: - I regenerated dbg-changes-codegen-branch-folding.ll from the given source as it was affected by the bug fixed in r256077 - two-cus-from-same-file.ll was changed to avoid having a variable-typed debug variable as that would depend on the target, even though this test is supposed to be generic - I had to manually declared size/align for reference type. See also the discussion for D14275/r253186. - fpstack-debuginstr-kill.ll required changing `double` to `long double` - most others were just a question of adding OP_deref `` ``` llvm-svn: 257850
* Re-Revert r257105 (Verifier debug info changes)Keno Fischer2016-01-134-10/+10
| | | | | | | While I investigate some new buildbot failures. This was originally reapplied as r257550 and r257558. llvm-svn: 257563
* Reapply r257105 "[Verifier] Check that debug values have proper size"Keno Fischer2016-01-134-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The follow extra changes were made to test cases: Manually making the variable be the actual type instead of a pointer to avoid pointer-size differences in generic code: LLVM :: DebugInfo/Generic/2010-03-24-MemberFn.ll LLVM :: DebugInfo/Generic/2010-04-06-NestedFnDbgInfo.ll LLVM :: DebugInfo/Generic/2010-05-03-DisableFramePtr.ll LLVM :: DebugInfo/Generic/varargs.ll Delete sizing information from debug info for the same reason (but the presence of the pointer was important to the test case): LLVM :: DebugInfo/Generic/restrict.ll LLVM :: DebugInfo/Generic/tu-composite.ll LLVM :: Linker/type-unique-type-array-a.ll LLVM :: Linker/type-unique-simple2.ll Fixing an incorrect DW_OP_deref LLVM :: DebugInfo/Generic/2010-05-03-OriginDIE.ll Fixing a missing DW_OP_deref LLVM :: DebugInfo/Generic/incorrect-variable-debugloc.ll Additionally, clang should no longer complain during bootstrap should no longer happen after r257534. The original commit message was: ``` Summary: Teach the Verifier to make sure that the storage size given to llvm.dbg.declare or the value size given to llvm.dbg.value agree with what is declared in DebugInfo. This is implicitly assumed in a number of passes (e.g. in SROA). Additionally this catches a number of common mistakes, such as passing a pointer when a value was intended or vice versa. One complication comes from stack coloring which modifies the original IR when it merges allocas in order to make sure that if AA falls back to the IR it gets the correct result. However, given this new invariant, indiscriminately replacing one alloca by a different (differently sized one) is no longer valid. Fix this by just undefing out any use of the alloca in a dbg.declare in this case. Additionally, I had to fix a number of test cases. Of particular note: - I regenerated dbg-changes-codegen-branch-folding.ll from the given source as it was affected by the bug fixed in r256077 - two-cus-from-same-file.ll was changed to avoid having a variable-typed debug variable as that would depend on the target, even though this test is supposed to be generic - I had to manually declared size/align for reference type. See also the discussion for D14275/r253186. - fpstack-debuginstr-kill.ll required changing `double` to `long double` - most others were just a question of adding OP_deref ``` llvm-svn: 257550
* [Linker] Also treat a DIImportedEntity scope DISubprogram as needed.Ahmed Bougacha2016-01-071-14/+22
| | | | | | | | | Follow-up to r257000: DIImportedEntity can reach a DISubprogram via its entity, but also via its scope. Handle the latter case as well. PR26037. llvm-svn: 257019
* Always treat DISubprogram reached by DIImportedEntity as needed.Teresa Johnson2016-01-072-0/+53
| | | | | | | | | | It is illegal to have a null entity in a DIImportedEntity, so we must link in a DISubprogram metadata node referenced by one, even if the associated function is not linked in or inlined anywhere. Fixes PR26037. llvm-svn: 257000
* [ThinLTO/LTO] Don't link in unneeded metadataTeresa Johnson2015-12-183-2/+87
| | | | | | | | | | | | | | | | | | | | Summary: Third patch split out from http://reviews.llvm.org/D14752. Only map in needed DISubroutine metadata (imported or otherwise linked in functions and other DISubroutine referenced by inlined instructions). This is supported for ThinLTO, LTO and llvm-link --only-needed, with associated tests for each one. Depends on D14838. Reviewers: dexonsmith, joker.eph Subscribers: davidxl, llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D14843 llvm-svn: 256003
* [ThinLTO] Metadata linking for imported functionsTeresa Johnson2015-12-172-0/+109
| | | | | | | | | | | | | | | | | | | | | | | Summary: Second patch split out from http://reviews.llvm.org/D14752. Maps metadata as a post-pass from each module when importing complete, suturing up final metadata to the temporary metadata left on the imported instructions. This entails saving the mapping from bitcode value id to temporary metadata in the importing pass, and from bitcode value id to final metadata during the metadata linking postpass. Depends on D14825. Reviewers: dexonsmith, joker.eph Subscribers: davidxl, llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D14838 llvm-svn: 255909
* Use diagnostic handler in the LLVMContextRafael Espindola2015-12-141-1/+1
| | | | | | | | | | | | | | | | This patch converts code that has access to a LLVMContext to not take a diagnostic handler. This has a few advantages * It is easier to use a consistent diagnostic handler in a single program. * Less clutter since we are not passing a handler around. It does make it a bit awkward to implement some C APIs that return a diagnostic string. I will propose new versions of these APIs and deprecate the current ones. llvm-svn: 255571
* Fix another case where the linkage was not set.Rafael Espindola2015-12-102-1/+12
| | | | llvm-svn: 255272
* Slit lib/Linker in two.Rafael Espindola2015-12-101-7/+28
| | | | | | | | | | | | | | | | A linker normally has two stages: symbol resolution and "moving stuff". In lib/Linker there is the complication of lazy linking some globals, but it was still far more mixed than it needed to. This splits the linker into a lower level IRMover and the linker proper. The IRMover just takes a list of globals to move and a callback that lets the user control what is lazy linked. The main motivation is that now tools/gold (and soon lld) can use their own symbol resolution to instruct IRMover what to do. llvm-svn: 255254
* Synchronize the logic for deciding to link a gv.Rafael Espindola2015-12-092-0/+14
| | | | | | | We were deciding to not link an available_externally gv over a declaration, but then copying over the body anyway. llvm-svn: 255169
* Add a test showing that we internalize lazily linked GVs.Rafael Espindola2015-12-082-0/+12
| | | | llvm-svn: 254989
* Simplify test. NFC.Rafael Espindola2015-12-081-6/+4
| | | | llvm-svn: 254987
* Link declaration lazily.Rafael Espindola2015-12-0713-6/+61
| | | | | | | We already linked available_externally and linkonce lazily, this just adds declarations to the list. llvm-svn: 254917
* Simplify test.Rafael Espindola2015-12-071-3/+1
| | | | llvm-svn: 254916
* Change how the linker handles the old llvm.global_ctors.Rafael Espindola2015-12-071-0/+8
| | | | | | | | | | | | | | | | | Now instead of changing it to the new format and then linking, it just handles the old format while copying it over. The main differences are: * There is no rauw in the source module. * An old format input is always upgraded. The first item helps with having a sane API that passes in a GV list to the linker. The second one is a small step in deprecating the old format. llvm-svn: 254907
* Simplify test. NFC.Rafael Espindola2015-12-031-8/+4
| | | | llvm-svn: 254631
* [ThinLTO] Appending linkage fixesTeresa Johnson2015-12-032-0/+26
| | | | | | | | | | | | | | | | | | | | Summary: Fix import from module with appending var, which cannot be imported. The first fix is to remove an overly-aggressive error check. The second fix is to deal with restructuring introduced to the module linker yesterday in r254418 (actually, this fix was included already in r254559, just added some additional cleanup). Test by Mehdi Amini. Reviewers: joker.eph, rafael Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D15156 llvm-svn: 254624
* Switch the linker to having a whitelist of GVs.Rafael Espindola2015-12-021-4/+4
| | | | | | | | | | | | This replaces DoNotLinkFromSource with ValuesToLink. It also moves the computation of ValuesToLink earlier. It is a bit simpler and an important step in slitting the linker into an ir mover and a linker proper. The test change is because we now avoid creating dead declarations. llvm-svn: 254559
* Delete what is now duplicated code.Rafael Espindola2015-12-021-8/+8
| | | | | | | | | Having to import an alias as declaration is not thinlto specific. The test difference are because when we already have a decl and we are not importing it, we just leave the decl alone. llvm-svn: 254556
* Also copy private linkage globals when needed.Rafael Espindola2015-12-022-0/+15
| | | | | | | This was an omission when handling COFF style comdats with local keys. Should fix the sanitizer-windows bot. llvm-svn: 254543
* Don't copy information from aliasee to alias.Rafael Espindola2015-12-022-2/+2
| | | | | | They are independent. llvm-svn: 254541
* Fix linking when we copy over only a decl.Rafael Espindola2015-12-022-0/+21
| | | | | | | We were failing to copy the fact that the GV is weak and in the case of an alias, producing invalid IR. llvm-svn: 254538
* Add an interesting case we already get right.Rafael Espindola2015-12-021-0/+14
| | | | llvm-svn: 254514
* Simplify test. NFC.Rafael Espindola2015-12-011-3/+2
| | | | llvm-svn: 254419
* Bring r254336 back:Rafael Espindola2015-12-016-0/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The difference is that now we don't error on out-of-comdat access to internal global values. We copy them instead. This seems to match the expectation of COFF linkers (see pr25686). Original message: Start deciding earlier what to link. A traditional linker is roughly split in symbol resolution and "copying stuff". The two tasks are badly mixed in lib/Linker. This starts splitting them apart. With this patch there are no direct call to linkGlobalValueBody or linkGlobalValueProto. Everything is linked via WapValue. This also includes a few fixes: * A GV goes undefined if the comdat is dropped (comdat11.ll). * We error if an internal GV goes undefined (comdat13.ll). * We don't link an unused comdat. The first two match the behavior of an ELF linker. The second one is equivalent to running globaldce on the input. llvm-svn: 254418
* This reverts commit r254336 and r254344.Rafael Espindola2015-11-304-33/+0
| | | | | | They broke a bot and I am debugging why. llvm-svn: 254347
* Disable a consistency check.Rafael Espindola2015-11-302-22/+0
| | | | | | Trying to figure out why it fails on a bot but passes locally. llvm-svn: 254344
* Start deciding earlier what to link.Rafael Espindola2015-11-306-0/+55
| | | | | | | | | | | | | | | | | | | | | | A traditional linker is roughly split in symbol resolution and "copying stuff". The two tasks are badly mixed in lib/Linker. This starts splitting them apart. With this patch there are no direct call to linkGlobalValueBody or linkGlobalValueProto. Everything is linked via WapValue. This also includes a few fixes: * A GV goes undefined if the comdat is dropped (comdat11.ll). * We error if an internal GV goes undefined (comdat13.ll). * We don't link an unused comdat. The first two match the behavior of an ELF linker. The second one is equivalent to running globaldce on the input. llvm-svn: 254336
* Avoid writing to source directory of testsReid Kleckner2015-11-301-1/+1
| | | | llvm-svn: 254324
* Fix another llvm.ctors merging bug.Rafael Espindola2015-11-302-0/+15
| | | | | | | We were not looking past casts to see if an element should be included or not. llvm-svn: 254313
* Make this test less strict.Rafael Espindola2015-11-291-5/+5
| | | | | | We just want to test what is copied, no the order. llvm-svn: 254255
* Correctly handle llvm.global_ctors merging.Rafael Espindola2015-11-292-0/+13
| | | | | | | We were not handling the case where an entry must be dropped and the destination module has no llvm.global_ctors. llvm-svn: 254241
* Fix a crash when writing merged bitcode.Rafael Espindola2015-11-291-0/+3
| | | | | | | Playing with mutateType in here was making getValueType and getType incompatible. llvm-svn: 254240
* Pass .ll directly to llvm-link.Rafael Espindola2015-11-271-7/+4
| | | | llvm-svn: 254214
* Pass .ll directly to llvm-linkRafael Espindola2015-11-271-3/+1
| | | | llvm-svn: 254213
* Modernize the test a bitRafael Espindola2015-11-271-7/+2
| | | | | | | Remove out of date comment. Pass .ll files to llvm-link. llvm-svn: 254210
* Disallow aliases to available_externally.Rafael Espindola2015-11-261-3/+9
| | | | | | | | | | | | They are as much trouble as aliases to declarations. They are requiring the code generator to define a symbol with the same value as another symbol, but the second symbol is undefined. If representing this is important for some optimization, we could add support for available_externally aliases. They would be *required* to point to a declaration (or available_externally definition). llvm-svn: 254170
* Have a single way for creating unique value names.Rafael Espindola2015-11-224-7/+7
| | | | | | | | | | | We had two code paths. One would create names like "foo.1" and the other names like "foo1". For globals it is important to use "foo.1" to help C++ name demangling. For locals there is no strong reason to go one way or the other so I kept the most common mangling (foo1). llvm-svn: 253804
* [ThinLTO] Handle bitcode without function summary sections gracefullyTeresa Johnson2015-11-211-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Several fixes to the handling of bitcode files without function summary sections so that they are skipped during ThinLTO processing in llvm-lto and the gold plugin when appropriate instead of aborting. 1 Don't assert when trying to add a FunctionInfo that doesn't have a summary attached. 2 Skip FunctionInfo structures that don't have attached function summary sections when trying to create the combined function summary. 3 In both llvm-lto and gold-plugin, check whether a bitcode file has a function summary section before trying to parse the index, and skip the bitcode file if it does not. 4 Fix hasFunctionSummaryInMemBuffer in BitcodeReader, which had a bug where we returned to early while looking for the summary section. Also added llvm-lto and gold-plugin based tests for cases where we don't have function summaries in the bitcode file. I verified that either the first couple fixes described above are enough to avoid the crashes, or fixes 1,3,4. But have combined them all here for added robustness. Reviewers: joker.eph Subscribers: llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D14903 llvm-svn: 253796
* llvm-link option and test for recent metadata mapping bugTeresa Johnson2015-11-211-0/+5
| | | | | | | | | | | | | | | | | | | | | | | Summary: Add a -preserve-modules option to llvm-link that simulates LTO clients that don't destroy modules as they are linked. This enables reproduction of a recent bug introduced by a metadata linking change that was only caught when the modules weren't destroyed before writing bitcode (LTO on Windows). See http://llvm.org/viewvc/llvm-project?view=revision&revision=253170 for more details on the original bug and the fix. Confirmed the new test added here reproduces the failure using the new option when I suppress the fix. Reviewers: pcc Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D14818 llvm-svn: 253740
* Revert "Change memcpy/memset/memmove to have dest and source alignments."Pete Cooper2015-11-193-6/+6
| | | | | | | | | | This reverts commit r253511. This likely broke the bots in http://lab.llvm.org:8011/builders/clang-ppc64-elf-linux2/builds/20202 http://bb.pgr.jp/builders/clang-3stage-i686-linux/builds/3787 llvm-svn: 253543
* Change memcpy/memset/memmove to have dest and source alignments.Pete Cooper2015-11-183-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note, this was reviewed (and more details are in) http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html These intrinsics currently have an explicit alignment argument which is required to be a constant integer. It represents the alignment of the source and dest, and so must be the minimum of those. This change allows source and dest to each have their own alignments by using the alignment attribute on their arguments. The alignment argument itself is removed. There are a few places in the code for which the code needs to be checked by an expert as to whether using only src/dest alignment is safe. For those places, they currently take the minimum of src/dest alignments which matches the current behaviour. For example, code which used to read: call void @llvm.memcpy.p0i8.p0i8.i32(i8* %dest, i8* %src, i32 500, i32 8, i1 false) will now read: call void @llvm.memcpy.p0i8.p0i8.i32(i8* align 8 %dest, i8* align 8 %src, i32 500, i1 false) For out of tree owners, I was able to strip alignment from calls using sed by replacing: (call.*llvm\.memset.*)i32\ [0-9]*\,\ i1 false\) with: $1i1 false) and similarly for memmove and memcpy. I then added back in alignment to test cases which needed it. A similar commit will be made to clang which actually has many differences in alignment as now IRBuilder can generate different source/dest alignments on calls. In IRBuilder itself, a new argument was added. Instead of calling: CreateMemCpy(Dst, Src, getInt64(Size), DstAlign, /* isVolatile */ false) you now call CreateMemCpy(Dst, Src, getInt64(Size), DstAlign, SrcAlign, /* isVolatile */ false) There is a temporary class (IntegerAlignment) which takes the source alignment and rejects implicit conversion from bool. This is to prevent isVolatile here from passing its default parameter to the source alignment. Note, changes in future can now be made to codegen. I didn't change anything here, but this change should enable better memcpy code sequences. Reviewed by Hal Finkel. llvm-svn: 253511
* [ThinLTO] Update test to be more tolerant of ordering changesTeresa Johnson2015-11-121-40/+40
| | | | | | | | | Update the ThinLTO function importing test to use DAG forms of checks so that it is more tolerant of changes to relative ordering between imported decls/defs. This reduces the number of changes required by the comdat importing patch I am sending for review shortly. llvm-svn: 252932
* Ensure ModuleLinker materializes complete comdat groupsTeresa Johnson2015-11-103-16/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The module linker lazy links some "discardable if unused" global values (e.g. linkonce), materializing and linking them only if they are referenced in the module. If a comdat group contains a linkonce member that is not referenced, however, it would not be materialized and linked, leading to an incomplete comdat group. If there are other object files not part of the same LTO link that also define and use that comdat group, the linker may select the incomplete group leading to link time unsats. To solve this, whenever a global value body is linked, make sure we materialize any other members of the same comdat group that are not yet materialized. This ensures they are in the lazy link list and get linked as well. Added new test and adjusted old test to remove parts that didn't make sense with fix. Reviewers: rafael Subscribers: dexonsmith, davidxl, llvm-commits Differential Revision: http://reviews.llvm.org/D14516 llvm-svn: 252647
* [ThinLTO] WeakAny fixes/cleanupTeresa Johnson2015-11-101-0/+2
| | | | | | | | | | | | | | | | | | | | | | | Ensure WeakAny variables are imported as ExternalWeak declarations. To handle WeakAny more consistently and fix this issue: 1) Update helper doImportAsDefinition to properly flag WeakAny variables and aliases as not importing defintions. Update callers of doImportAsDefinition to remove now redundant checks for WeakAny aliases, or ignore aliases, as appropriate. 2) Add any !doImportAsDefinition GVs to DoNotLinkFromSource set during linking of the GV prototype, where we usually add GVs to the DoNotLinkFromSource set for other reasons. Remove now unnecessary adding of WeakAny aliases to DoNotLinkFromSource set from copyGlobalAliasProto. Remove now unnecessary guard against linking non-imported function bodies from ModuleLinker::run. llvm-svn: 252626
OpenPOWER on IntegriCloud