summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/Module.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Fix bug 19437 - Only add discriminators for DWARF 4 and above.Diego Novillo2014-04-171-0/+8
| | | | | | | | | | | | | | Summary: This prevents the discriminator generation pass from triggering if the DWARF version being used in the module is prior to 4. Reviewers: echristo, dblaikie CC: llvm-commits Differential Revision: http://reviews.llvm.org/D3413 llvm-svn: 206507
* [C++11] More 'nullptr' conversion or in some cases just using a boolean ↵Craig Topper2014-04-091-6/+6
| | | | | | check instead of comparing to nullptr. llvm-svn: 205831
* Module: Don't rename in getOrInsertFunction()Duncan P. N. Exon Smith2014-03-101-10/+0
| | | | | | | | | | | | | | | | | | | | | | | During LTO, user-supplied definitions of C library functions often exist. -instcombine uses Module::getOrInsertFunction() to get a handle on library functions (e.g., @puts, when optimizing @printf). Previously, Module::getOrInsertFunction() would rename any matching functions with local linkage, and create a new declaration. In LTO, this is the opposite of desired behaviour, as it skips by the user-supplied version of the library function and creates a new undefined reference which the linker often cannot resolve. After some discussing with Rafael on the list, it looks like it's undesired behaviour. If a consumer actually *needs* this behaviour, we should add new API with a more explicit name. I added two testcases: one specifically for the -instcombine behaviour and one for the LTO flow. <rdar://problem/16165191> llvm-svn: 203513
* [C++11] Modernize the IR library a bit.Benjamin Kramer2014-03-101-4/+2
| | | | | | No functionality change. llvm-svn: 203465
* 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] Move GVMaterializer.h into the IR library where itsChandler Carruth2014-03-061-1/+1
| | | | | | | | | | | | | implementation already lived. After this commit, the only IR-library headers in include/llvm/* are ones related to the legacy pass infrastructure that I'm planning to leave there until the new one is farther along. The only other headers at the top level are linking and initialization aids that aren't really libraries but just headers. llvm-svn: 203069
* [Modules] Move the LeakDetector header into the IR library where theChandler Carruth2014-03-041-1/+1
| | | | | | | | | | | source file had already been moved. Also move the unittest into the IR unittest library. This may seem an odd thing to put in the IR library but we only really use this with instructions and it needs the LLVM context to work, so it is intrinsically tied to the IR library. llvm-svn: 202842
* Fix resetting the DataLayout in a Module.Rafael Espindola2014-02-251-1/+5
| | | | | | | | | | | | | | | No tool does this currently, but as everything else in a module we should be able to change its DataLayout. Most of the fix is in DataLayout to make sure it can be reset properly. The test uses Module::setDataLayout since the fact that we mutate a DataLayout is an implementation detail. The module could hold a OwningPtr<DataLayout> and the DataLayout itself could be immutable. Thanks to Philip Reames for pushing me in the right direction. llvm-svn: 202198
* Store a DataLayout in Module.Rafael Espindola2014-02-251-2/+26
| | | | | | | | | | | | | | Now that DataLayout is not a pass, store one in Module. Since the C API expects to be able to get a char* to the datalayout description, we have to keep a std::string somewhere. This patch keeps it in Module and also uses it to represent modules without a DataLayout. Once DataLayout is mandatory, we should probably move the string to DataLayout itself since it won't be necessary anymore to represent the special case of a module without a DataLayout. llvm-svn: 202190
* Return an error_code from materializeAllPermanently.Rafael Espindola2014-01-141-7/+5
| | | | llvm-svn: 199275
* Use error_code in Module::materializeAll.Rafael Espindola2014-01-141-9/+7
| | | | llvm-svn: 199269
* Re-remove dead code.Nadav Rotem2014-01-091-45/+0
| | | | | | This reverts r198854. llvm-svn: 198879
* Revert r198819 - "Remove dead code."Nadav Rotem2014-01-091-0/+45
| | | | llvm-svn: 198854
* Remove dead code.Rafael Espindola2014-01-091-45/+0
| | | | llvm-svn: 198819
* When parsing data layout string looking for endianness, use the correct defaultDmitri Gribenko2013-12-201-1/+1
| | | | llvm-svn: 197771
* Correctly apply the default pointer sizeDmitri Gribenko2013-12-201-1/+1
| | | | llvm-svn: 197770
* Debug Info: drop debug info via upgrading path if version number does not match.Manman Ren2013-12-021-5/+10
| | | | | | | | | | | | | | Add a helper function getDebugInfoVersionFromModule to return the debug info version number for a module. "Verifier/module-flags-1.ll" checks for verification errors. It will seg fault when calling getDebugInfoVersionFromModule because of the incorrect format for module flags in the testing case. We make getModuleFlagsMetadata more robust by checking for error conditions. PR17982 llvm-svn: 196158
* Use error_code in GVMaterializer.Rafael Espindola2013-11-051-4/+15
| | | | | | They just propagate out the bitcode reader error, so we don't need a new enum. llvm-svn: 194091
* Reuse variableMatt Arsenault2013-09-301-1/+1
| | | | llvm-svn: 191712
* Fix getOrInsertGlobal dropping the address space.Matt Arsenault2013-09-301-2/+4
| | | | | | | | Currently it will insert an illegal bitcast. Arguably, the address space argument should be added for the creation case. llvm-svn: 191702
* Fix typoMatt Arsenault2013-09-281-1/+1
| | | | llvm-svn: 191595
* Make these methods const correct.Rafael Espindola2013-07-251-2/+1
| | | | | | Thanks to Nick Lewycky for noticing it. llvm-svn: 187098
* Add getModuleFlag(StringRef Key) to query a module flag given Key.Manman Ren2013-07-161-0/+13
| | | | | | No functionality change. llvm-svn: 186470
* Remove dead code.Eli Bendersky2013-05-151-17/+0
| | | | | | This method is not being used/tested anywhere. llvm-svn: 181943
* Removed extraneous #include "LLVMContextImpl.h" from lib/IR/Module.cppJean-Luc Duprat2013-03-011-1/+0
| | | | llvm-svn: 176382
* Cache the result of Function::getIntrinsicID() in a DenseMap attached to the ↵Michael Ilseman2013-03-011-0/+1
| | | | | | | | | | LLVMContext. This reduces the time actually spent doing string to ID conversion and shows a 10% improvement in compile time for a particularly bad case that involves ARM Neon intrinsics (these have many overloads). Patch by Jean-Luc Duprat! llvm-svn: 176365
* Move all of the header files which are involved in modelling the LLVM IRChandler Carruth2013-01-021-5/+5
| | | | | | | | | | | | | | | | | | | | | into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. llvm-svn: 171366
* Rename VMCore directory to IR.Chandler Carruth2013-01-021-0/+451
Aside from moving the actual files, this patch only updates the build system and the source file comments under lib/... that are relevant. I'll be updating other docs and other files in smaller subsequnet commits. While I've tried to test this, but it is entirely possible that there will still be some build system fallout. Also, note that I've not changed the library name itself: libLLVMCore.a is still the library name. I'd be interested in others' opinions about whether we should rename this as well (I think we should, just not sure what it might break) llvm-svn: 171359
OpenPOWER on IntegriCloud