summaryrefslogtreecommitdiffstats
path: root/llvm/unittests/Linker/LinkModulesTest.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [llvm] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-151-2/+2
| | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. llvm-svn: 369013
* [opaque pointer types] Pass value type to LoadInst creation.James Y Knight2019-02-011-1/+1
| | | | | | | | | This cleans up all LoadInst creation in LLVM to explicitly pass the value type rather than deriving it from the pointer's element-type. Differential Revision: https://reviews.llvm.org/D57172 llvm-svn: 352911
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Fix build for LLVM unittestsReid Kleckner2017-09-151-6/+6
| | | | llvm-svn: 313397
* Re-sort #include lines for unittests. This uses a slightly modifiedChandler Carruth2017-06-061-2/+2
| | | | | | | | | | | | | | | clang-format (https://reviews.llvm.org/D33932) to keep primary headers at the top and handle new utility headers like 'gmock' consistently with other utility headers. No other change was made. I did no manual edits, all of this is clang-format. This should allow other changes to have more clear and focused diffs, and is especially motivated by moving some headers into more focused libraries. llvm-svn: 304786
* Implement intrinsic mangling for literal struct types.Daniel Berlin2017-02-151-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes PR 31921 Summary: Predicateinfo requires an ugly workaround to try to avoid literal struct types due to the intrinsic mangling not being implemented. This workaround actually does not work in all cases (you can hit the assert by bootstrapping with -print-predicateinfo), and can't be made to work without DFS'ing the type (IE copying getMangledStr and using a version that detects if it would crash). Rather than do that, i just implemented the mangling. It seems simple, since they are unified structurally. Looking at the overloaded-mangling testcase we have, it actually turns out the gc intrinsics will *also* crash if you try to use a literal struct. Thus, the testcase added fails before this patch, and works after, without needing to resort to predicateinfo. Reviewers: chandlerc, davide Subscribers: llvm-commits, sanjoy Differential Revision: https://reviews.llvm.org/D29925 llvm-svn: 295253
* Remangle intrinsics names when types are renamedArtur Pilipenko2016-06-241-0/+54
| | | | | | | | | | | | | This is a resubmittion of previously reverted rL273568. This is a fix for the problem mentioned in "LTO and intrinsics mangling" llvm-dev mail thread: http://lists.llvm.org/pipermail/llvm-dev/2016-April/098387.html Reviewers: mehdi_amini, reames Differential Revision: http://reviews.llvm.org/D19373 llvm-svn: 273686
* Revert r273568 "Remangle intrinsics names when types are renamed"Hans Wennborg2016-06-231-54/+0
| | | | | | It broke 2008-07-15-Bswap.ll and 2009-09-01-PostRAProlog.ll llvm-svn: 273574
* Remangle intrinsics names when types are renamedArtur Pilipenko2016-06-231-0/+54
| | | | | | | | | | | This is a fix for the problem mentioned in "LTO and intrinsics mangling" llvm-dev mail thread: http://lists.llvm.org/pipermail/llvm-dev/2016-April/098387.html Reviewers: mehdi_amini, reames Differential Revision: http://reviews.llvm.org/D19373 llvm-svn: 273568
* Delete the deprecated LLVMLinkModules.Rafael Espindola2016-02-121-24/+0
| | | | llvm-svn: 260683
* Reorganize the C API headers to improve build times.Eric Christopher2015-12-181-0/+1
| | | | | | | | | Type specific declarations have been moved to Type.h and error handling routines have been moved to ErrorHandling.h. Both are included in Core.h so nothing should change for projects directly including the headers, but transitive dependencies may be affected. llvm-svn: 255965
* Change linkInModule to take a std::unique_ptr.Rafael Espindola2015-12-161-8/+36
| | | | | | | Passing in a std::unique_ptr should help find errors when the module is used after being linked into another module. llvm-svn: 255842
* Use diagnostic handler in the LLVMContextRafael Espindola2015-12-141-6/+13
| | | | | | | | | | | | | | | | 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
* Always pass a diagnostic handler to the linker.Rafael Espindola2015-12-041-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | Before this patch the diagnostic handler was optional. If it was not passed, the one in the LLVMContext was used. That is probably not a pattern we want to follow. If each area has an optional callback, there is a sea of callbacks and it is hard to follow which one is called. Doing this also found cases where the callback is a nice addition, like testing that no errors or warnings are reported. The other option is to always use the diagnostic handler in the LLVMContext. That has a few problems * To implement the C API we would have to set the diag handler and then set it back to the original value. * Code that creates the context might be far away from code that wants the diagnostics. I do have a patch that implements the second option and will send that as an RFC. llvm-svn: 254777
* Use references now that it is natural to do so.Rafael Espindola2015-12-011-6/+5
| | | | | | | The linker never takes ownership of a module or changes which module it is refering to, making it natural to use references. llvm-svn: 254449
* unittests: Remove implicit ilist iterator conversions, NFCDuncan P. N. Exon Smith2015-10-201-1/+1
| | | | llvm-svn: 250843
* Linker: Move distinct MDNodes instead of cloningDuncan P. N. Exon Smith2015-08-031-0/+74
| | | | | | | | | | | | | | | | | | | | | Instead of cloning distinct `MDNode`s when linking in a module, just move them over. The module linker destroys the source module, so the old node would otherwise just be leaked on the context. Create the new node in place. This also reduces the number of cloned uniqued nodes (since it's less likely their operands have changed). This mapping strategy is only correct when we're discarding the source, so the linker turns it on via a ValueMapper flag, `RF_MoveDistinctMDs`. There's nothing observable in terms of `llvm-link` output here: the linked module should be semantically identical. I'll be adding more 'distinct' nodes to the debug info metadata graph in order to break uniquing cycles, so the benefits of this will partly come in future commits. However, we should get some gains immediately, since we have a fair number of 'distinct' `DILocation`s being linked in. llvm-svn: 243883
* [LinkerTest] Use LLVMDisposeMessage to free error string.Benjamin Kramer2015-06-151-1/+1
| | | | | | | LLVMDisposeMessage is just a thing wrapper around free at the moment, but it's the proper API to use here. llvm-svn: 239731
* [LinkerTest] Don't leak error string.Benjamin Kramer2015-06-131-0/+1
| | | | llvm-svn: 239673
* Fix returning error message in LLVMLinkModulesEli Bendersky2015-06-121-0/+40
| | | | | | | | | | | On error, the temporary output stream wouldn't be flushed and therefore the caller would see an empty error message. Patch by Antoine Pitrou Differential Revision: http://reviews.llvm.org/D10241 llvm-svn: 239646
* Use 'override/final' instead of 'virtual' for overridden methodsAlexander Kornienko2015-04-111-2/+2
| | | | | | | | | | | | | | The patch is generated using clang-tidy misc-use-override check. This command was used: tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py \ -checks='-*,misc-use-override' -header-filter='llvm|clang' \ -j=32 -fix -format http://reviews.llvm.org/D8925 llvm-svn: 234679
* Opaque Pointer Types: GEP API migrations to specify the gep type explicitlyDavid Blaikie2015-03-241-2/+3
| | | | | | | | | | | | | | | | | | | | | The changes to InstCombine (& SCEV) do seem a bit silly - it doesn't make anything obviously better to have the caller access the pointers element type (the thing I'm trying to remove) than the GEP itself, but it's a helpful migration step. This will allow me to more obviously lock down GEP (& Load, etc) API usage, then fix all the code that accesses pointer element types except the places that need to be removed (most of the InstCombines) anyway - at which point I'll need to just remove all that code because it won't be meaningful anymore (there will be no pointer types, so no bitcasts to combine) SCEV looks like it'll need some restructuring - we'll have to do a bit more work for GEP canonicalization, since it'll depend on how it's used if we can even manage to canonicalize it to a non-ugly GEP. I guess we can do some fun stuff like voting (do 2 out of 3 load from the GEP with a certain type that gives a pretty GEP? Does every typed use of the GEP use either a specific type or a generic type (i8*, etc)?) llvm-svn: 233131
* [cleanup] Re-sort all the #include lines in LLVM usingChandler Carruth2015-01-141-1/+1
| | | | | | | | | | | utils/sort_includes.py. I clearly haven't done this in a while, so more changed than usual. This even uncovered a missing include from the InstrProf library that I've added. No functionality changed here, just mechanical cleanup of the include order. llvm-svn: 225974
* Factor common code it Linker::init.Rafael Espindola2014-11-171-0/+20
| | | | | | The TypeFinder was not being used in one of the constructors. llvm-svn: 222172
* Remove the PreserveSource linker mode.Rafael Espindola2014-10-281-11/+15
| | | | | | | | | | | | | | | | | | | | I noticed that it was untested, and forcing it on caused some tests to fail: LLVM :: Linker/metadata-a.ll LLVM :: Linker/prefixdata.ll LLVM :: Linker/type-unique-odr-a.ll LLVM :: Linker/type-unique-simple-a.ll LLVM :: Linker/type-unique-simple2-a.ll LLVM :: Linker/type-unique-simple2.ll LLVM :: Linker/type-unique-type-array-a.ll LLVM :: Linker/unnamed-addr1-a.ll LLVM :: Linker/visibility1.ll If it is to be resurrected, it has to be fixed and we should probably have a -preserve-source command line option in llvm-mc and run tests with and without it. llvm-svn: 220741
* Update the error handling of lib/Linker.Rafael Espindola2014-10-251-3/+3
| | | | | | Instead of passing a std::string&, use the new diagnostic infrastructure. llvm-svn: 220608
* [C++11] Use 'nullptr'.Craig Topper2014-06-081-5/+5
| | | | llvm-svn: 210442
* LinkModulesTest.cpp: Reformat.NAKAMURA Takumi2014-04-291-20/+13
| | | | llvm-svn: 207537
* LinkModulesTest.cpp: Use test-specific Ctx instead of getGlobalContext(). ↵NAKAMURA Takumi2014-04-291-4/+2
| | | | | | The global context might not be free'd. [vg_leak] llvm-svn: 207535
* Replace OwningPtr<T> with std::unique_ptr<T>.Ahmed Charles2014-03-061-1/+1
| | | | | | | | | | This compiles with no changes to clang/lld/lldb with MSVC and includes overloads to various functions which are used by those projects and llvm which have OwningPtr's as parameters. This should allow out of tree projects some time to move. There are also no changes to libs/Target, which should help out of tree targets have time to move, if necessary. llvm-svn: 203083
* [Layering] Sink Linker.h into a Linker subdirectory to make itChandler Carruth2014-03-061-1/+1
| | | | | | consistent with every other sub-library header in LLVM. llvm-svn: 203065
* [cleanup] Re-sort all the includes with utils/sort_includes.py.Chandler Carruth2014-03-041-1/+1
| | | | llvm-svn: 202811
* Reapply r194218 with fix:Bill Wendling2014-01-161-0/+165
| | | | | | | | | | | | Move copying of global initializers below the cloning of functions. The BlockAddress doesn't have access to the correct basic blocks until the functions have been cloned. This causes the BlockAddress to point to the old values. Just wait until the functions have been cloned before copying the initializers. PR13163 llvm-svn: 199354
* Revert "Move copying of global initializers below the cloning of functions."Adrian Prantl2013-11-091-131/+0
| | | | | | | | This would cause internal symbols that are only referenced by global initializers to be removed. This reverts commit 194219. llvm-svn: 194304
* Revert "Run clang-format on file."Adrian Prantl2013-11-091-9/+14
| | | | | | This reverts commit 194219. llvm-svn: 194303
* Run clang-format on file.Bill Wendling2013-11-071-14/+9
| | | | llvm-svn: 194219
* Move copying of global initializers below the cloning of functions.Bill Wendling2013-11-071-0/+131
The BlockAddress doesn't have access to the correct basic blocks until the functions have been cloned. This causes the BlockAddress to point to the old values. Just wait until the functions have been cloned before copying the initializers. PR13163 llvm-svn: 194218
OpenPOWER on IntegriCloud