summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/Globals.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Rename NumOperands to make it clear its managed by the User. NFC.Pete Cooper2015-06-121-2/+8
| | | | | | | | | | | | | | | | | | | | | This is to try make it very clear that subclasses shouldn't be changing the value directly. Now that OperandList for normal instructions is computed using the NumOperands, its critical that the NumOperands is accurate or we could compute the wrong offset to the first operand. I looked over all places which update NumOperands and they are all safe. Hung off use User's don't use NumOperands to compute the OperandList so they are safe to continue to manipulate it. The only other User which changed it was GlobalVariable which has an optional init list but always allocated space for a single Use. It was correctly setting NumOperands to 1 before setting an initializer, and setting it to 0 after clearing the init list, so the order was safe. Added some comments to that code to make sure that this isn't changed in future without being aware of this constraint. Reviewed by Duncan Exon Smith. llvm-svn: 239621
* While in GlobalValue fix the function(s) that don't follow theEric Christopher2015-05-151-2/+2
| | | | | | naming convention and update users. llvm-svn: 237461
* [opaque pointer type] Pass GlobalAlias the actual pointer type rather than ↵David Blaikie2015-04-291-19/+14
| | | | | | | | | | | | | decomposing it into pointee type + address space Many of the callers already have the pointer type anyway, and for the couple of callers that don't it's pretty easy to call PointerType::get on the pointee type and address space. This avoids LLParser from using PointerType::getElementType when parsing GlobalAliases from IR. llvm-svn: 236160
* Remove getDataLayout() from Instruction/GlobalValue/BasicBlock/FunctionMehdi Amini2015-03-031-4/+0
| | | | | | | | | | | | | | | | | Summary: This does not conceptually belongs here. Instead provide a shortcut getModule() that provides access to the DataLayout. Reviewers: chandlerc, echristo Reviewed By: echristo Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8027 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 231147
* The leak detector is dead, long live asan and valgrind.Rafael Espindola2014-12-221-14/+0
| | | | | | | In resent times asan and valgrind have found way more memory management bugs in llvm than the special purpose leak detector. llvm-svn: 224703
* Copy externally_initialized in GlobalVariable::copyAttributesFrom.Rafael Espindola2014-11-101-0/+1
| | | | | | Patch by Kevin Frei! llvm-svn: 221620
* Modernize the error handling of the Materialize function.Rafael Espindola2014-10-241-2/+2
| | | | llvm-svn: 220600
* Don't ever call materializeAllPermanently during LTO.Rafael Espindola2014-10-241-3/+19
| | | | | | | | | | To do this, change the representation of lazy loaded functions. The previous representation cannot differentiate between a function whose body has been removed and one whose body hasn't been read from the .bc file. That means that in order to drop a function, the entire body had to be read. llvm-svn: 220580
* IR: Add COMDATs to the IRDavid Majnemer2014-06-271-7/+12
| | | | | | | | | | | | | | | | This new IR facility allows us to represent the object-file semantic of a COMDAT group. COMDATs allow us to tie together sections and make the inclusion of one dependent on another. This is required to implement features like MS ABI VFTables and optimizing away certain kinds of initialization in C++. This functionality is only representable in COFF and ELF, Mach-O has no similar mechanism. Differential Revision: http://reviews.llvm.org/D4178 llvm-svn: 211920
* Make getBaseObject static.Rafael Espindola2014-06-181-1/+1
| | | | | | Thanks to David Majnemer for noticing. llvm-svn: 211208
* Fix gcc -Wparentheses warning.Patrik Hagglund2014-06-041-1/+1
| | | | llvm-svn: 210178
* Allow alias to point to an arbitrary ConstantExpr.Rafael Espindola2014-06-031-12/+33
| | | | | | | | | | | | | | | | | | | | | This patch changes GlobalAlias to point to an arbitrary ConstantExpr and it is up to MC (or the system assembler) to decide if that expression is valid or not. This reduces our ability to diagnose invalid uses and how early we can spot them, but it also lets us do things like @test5 = alias inttoptr(i32 sub (i32 ptrtoint (i32* @test2 to i32), i32 ptrtoint (i32* @bar to i32)) to i32*) An important implication of this patch is that the notion of aliased global doesn't exist any more. The alias has to encode the information needed to access it in its metadata (linkage, visibility, type, etc). Another consequence to notice is that getSection has to return a "const char *". It could return a NullTerminatedStringRef if there was such a thing, but when that was proposed the decision was to just uses "const char*" for that. llvm-svn: 210062
* [pr19844] Add thread local mode to aliases.Rafael Espindola2014-05-281-2/+4
| | | | | | | | | | This matches gcc's behavior. It also seems natural given that aliases contain other properties that govern how it is accessed (linkage, visibility, dll storage). Clang still has to be updated to expose this feature to C. llvm-svn: 209759
* Use create methods since msvc doesn't handle delegating constructors.Rafael Espindola2014-05-171-16/+28
| | | | llvm-svn: 209076
* Reduce abuse of default values in the GlobalAlias constructor.Rafael Espindola2014-05-171-3/+20
| | | | | | This is in preparation for adding an optional offset. llvm-svn: 209073
* Delete getAliasedGlobal.Rafael Espindola2014-05-161-2/+2
| | | | llvm-svn: 209040
* Fix most of PR10367.Rafael Espindola2014-05-161-44/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch changes the design of GlobalAlias so that it doesn't take a ConstantExpr anymore. It now points directly to a GlobalObject, but its type is independent of the aliasee type. To avoid changing all alias related tests in this patches, I kept the common syntax @foo = alias i32* @bar to mean the same as now. The cases that used to use cast now use the more general syntax @foo = alias i16, i32* @bar. Note that GlobalAlias now behaves a bit more like GlobalVariable. We know that its type is always a pointer, so we omit the '*'. For the bitcode, a nice surprise is that we were writing both identical types already, so the format change is minimal. Auto upgrade is handled by looking through the casts and no new fields are needed for now. New bitcode will simply have different types for Alias and Aliasee. One last interesting point in the patch is that replaceAllUsesWith becomes smart enough to avoid putting a ConstantExpr in the aliasee. This seems better than checking and updating every caller. A followup patch will delete getAliasedGlobal now that it is redundant. Another patch will add support for an explicit offset. llvm-svn: 209007
* Change the GlobalAlias constructor to look a bit more like GlobalVariable.Rafael Espindola2014-05-161-7/+9
| | | | | | | This is part of the fix for pr10367. A GlobalAlias always has a pointer type, so just have the constructor build the type. llvm-svn: 208983
* Revert "Implement global merge optimization for global variables."Rafael Espindola2014-05-161-25/+0
| | | | | | | | | | | | This reverts commit r208934. The patch depends on aliases to GEPs with non zero offsets. That is not supported and fairly broken. The good news is that GlobalAlias is being redesigned and will have support for offsets, so this patch should be a nice match for it. llvm-svn: 208978
* Implement global merge optimization for global variables.Jiangning Liu2014-05-151-0/+25
| | | | | | | | | | | This commit implements two command line switches -global-merge-on-external and -global-merge-aligned, and both of them are false by default, so this optimization is disabled by default for all targets. For ARM64, some back-end behaviors need to be tuned to get this optimization further enabled. llvm-svn: 208934
* Split GlobalValue into GlobalValue and GlobalObject.Rafael Espindola2014-05-131-24/+21
| | | | | | | | | This allows code to statically accept a Function or a GlobalVariable, but not an alias. This is already a cleanup by itself IMHO, but the main reason for it is that it gives a lot more confidence that the refactoring to fix the design of GlobalAlias is correct. That will be a followup patch. llvm-svn: 208716
* Run clang-format in small sections of code to make a patch easier to read.Rafael Espindola2014-05-091-18/+14
| | | | llvm-svn: 208419
* Delete trailing white space.Rafael Espindola2014-05-091-4/+4
| | | | llvm-svn: 208415
* Special case aliases in GlobalValue::getSection.Rafael Espindola2014-05-061-0/+6
| | | | | | | | This is similar to the getAlignment patch, but is done just for completeness. It looks like we never call getSection on an alias. All the tests still pass if the if is replaced with an assert. llvm-svn: 208139
* Special case aliases in GlobalValue::getAlignment.Rafael Espindola2014-05-061-0/+7
| | | | | | | | | An alias has the address of what it points to, so it also has the same alignment. This allows a few optimizations to see past aliases for free. llvm-svn: 208103
* Be more strict about not allowing setSection on aliases.Rafael Espindola2014-05-061-0/+5
| | | | llvm-svn: 208095
* Be more strict about not calling setAlignment on global aliases.Rafael Espindola2014-05-061-3/+6
| | | | | | | The fact that GlobalAlias::setAlignment exists at all is a side effect of how the classes are organized, it should never be used. llvm-svn: 208094
* [C++11] More 'nullptr' conversion or in some cases just using a boolean ↵Craig Topper2014-04-091-5/+5
| | | | | | check instead of comparing to nullptr. llvm-svn: 205831
* Prevent alias from pointing to weak aliases.Rafael Espindola2014-03-271-21/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds back r204781. Original message: Aliases are just another name for a position in a file. As such, the regular symbol resolutions are not applied. For example, given define void @my_func() { ret void } @my_alias = alias weak void ()* @my_func @my_alias2 = alias void ()* @my_alias We produce without this patch: .weak my_alias my_alias = my_func .globl my_alias2 my_alias2 = my_alias That is, in the resulting ELF file my_alias, my_func and my_alias are just 3 names pointing to offset 0 of .text. That is *not* the semantics of IR linking. For example, linking in a @my_alias = alias void ()* @other_func would require the strong my_alias to override the weak one and my_alias2 would end up pointing to other_func. There is no way to represent that with aliases being just another name, so the best solution seems to be to just disallow it, converting a miscompile into an error. llvm-svn: 204934
* Revert "Prevent alias from pointing to weak aliases."Rafael Espindola2014-03-261-14/+21
| | | | | | | | | This reverts commit r204781. I will follow up to with msan folks to see what is what they were trying to do with aliases to weak aliases. llvm-svn: 204784
* Prevent alias from pointing to weak aliases.Rafael Espindola2014-03-261-21/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Aliases are just another name for a position in a file. As such, the regular symbol resolutions are not applied. For example, given define void @my_func() { ret void } @my_alias = alias weak void ()* @my_func @my_alias2 = alias void ()* @my_alias We produce without this patch: .weak my_alias my_alias = my_func .globl my_alias2 my_alias2 = my_alias That is, in the resulting ELF file my_alias, my_func and my_alias are just 3 names pointing to offset 0 of .text. That is *not* the semantics of IR linking. For example, linking in a @my_alias = alias void ()* @other_func would require the strong my_alias to override the weak one and my_alias2 would end up pointing to other_func. There is no way to represent that with aliases being just another name, so the best solution seems to be to just disallow it, converting a miscompile into an error. llvm-svn: 204781
* [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
* Use DataLayout from the module when easily available.Rafael Espindola2014-02-251-0/+4
| | | | | | | | | | | | | | | | | Eventually DataLayoutPass should go away, but for now that is the only easy way to get a DataLayout in some APIs. This patch only changes the ones that have easy access to a Module. One interesting issue with sometimes using DataLayoutPass and sometimes fetching it from the Module is that we have to make sure they are equivalent. We can get most of the way there by always constructing the pass with a Module. In fact, the pass could be changed to point to an external DataLayout instead of owning one to make this stricter. Unfortunately, the C api passes a DataLayout, so it has to be up to the caller to make sure the pass and the module are in sync. llvm-svn: 202204
* Check that GlobalAliases don't have section or alignment.Rafael Espindola2014-02-131-0/+2
| | | | | | | An alias is always in the section of its aliasee and has the same alignment (since it has the same address). llvm-svn: 201354
* Copy dll storage in copyAttributes.Rafael Espindola2014-02-131-0/+1
| | | | llvm-svn: 201295
* Copy the ThreadLocalMode in GlobalVariable::copyAttributesFromHans Wennborg2014-02-101-1/+1
| | | | | | This fixes the oversight from r159077. llvm-svn: 201098
* Allow addrspacecast in global aliasesMatt Arsenault2014-01-021-1/+2
| | | | llvm-svn: 198349
* Revert r193251 : Use address-taken to disambiguate global variable and ↵Shuxin Yang2013-10-271-3/+0
| | | | | | indirect memops. llvm-svn: 193489
* Use address-taken to disambiguate global variable and indirect memops.Shuxin Yang2013-10-231-0/+3
| | | | | | | | | | Major steps include: 1). introduces a not-addr-taken bit-field in GlobalVariable 2). GlobalOpt pass sets "not-address-taken" if it proves a global varirable dosen't have its address taken. 3). AA use this info for disambiguation. llvm-svn: 193251
* Introduce non-const overloads for GlobalAlias::{get,resolve}AliasedGlobal.Peter Collingbourne2013-08-191-8/+8
| | | | llvm-svn: 188725
* Added instance variable/initializers/getter/setters for new keyword ↵Michael Gottesman2013-02-031-5/+10
| | | | | | | | | | | | | | externally initialized to GlobalVariable. No *TRUE* functionality change. I am going to add in the actual test cases with the actual functionality changes in a later patch because I want to include some test cases. To be clear when I say no *TRUE* functionality change I mean that this patch (like it says in the title) only contains getters/setters and sets up a default initial value of the instance variable to false so that this patch does not affect any other uses of Global Variable.h. llvm-svn: 174295
* Move all of the header files which are involved in modelling the LLVM IRChandler Carruth2013-01-021-6/+6
| | | | | | | | | | | | | | | | | | | | | 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/+264
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