summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/Globals.cpp
Commit message (Collapse)AuthorAgeFilesLines
* GlobalValue: use getValueType() instead of getType()->getPointerElementType().Manuel Jacob2016-01-161-1/+1
| | | | | | | | | | | | Reviewers: mjacob Subscribers: jholewinski, arsenm, dsanders, dblaikie Patch by Eduard Burtescu. Differential Revision: http://reviews.llvm.org/D16260 llvm-svn: 257999
* Stop increasing alignment of externally-visible globals on ELFJames Y Knight2016-01-151-1/+43
| | | | | | | | | | | | | | | | | | | | | platforms. With ELF, the alignment of a global variable in a shared library will get copied into an executables linked against it, if the executable even accesss the variable. So, it's not possible to implicitly increase alignment based on access patterns, or you'll break existing binaries. This happened to affect libc++'s std::cout symbol, for example. See thread: http://thread.gmane.org/gmane.comp.compilers.clang.devel/45311 (This is a re-commit of r257719, without the bug reported in PR26144. I've tweaked the code to not assert-fail in enforceKnownAlignment when computeKnownBits doesn't recurse far enough to find the underlying Alloca/GlobalObject value.) Differential Revision: http://reviews.llvm.org/D16145 llvm-svn: 257902
* Revert "Stop increasing alignment of externally-visible globals on ELF ↵James Y Knight2016-01-141-43/+1
| | | | | | | | platforms." This reverts commit r257719, due to PR26144. llvm-svn: 257775
* Stop increasing alignment of externally-visible globals on ELFJames Y Knight2016-01-131-1/+43
| | | | | | | | | | | | | | platforms. With ELF, the alignment of a global variable in a shared library will get copied into an executables linked against it, if the executable even accesss the variable. So, it's not possible to implicitly increase alignment based on access patterns, or you'll break existing binaries. This happened to affect libc++'s std::cout symbol, for example. See thread: http://thread.gmane.org/gmane.comp.compilers.clang.devel/45311 llvm-svn: 257719
* Drop support for dematerializing.Rafael Espindola2015-12-181-6/+0
| | | | | | | It was only used on lib/Linker and the use was "dead" since it was used on a function the IRMover had just moved. llvm-svn: 256019
* Don't copy information from aliasee to alias.Rafael Espindola2015-12-021-10/+11
| | | | | | They are independent. llvm-svn: 254541
* IR: Remove implicit iterator conversions from lib/IR, NFCDuncan P. N. Exon Smith2015-10-081-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | Stop converting implicitly between iterators and pointers/references in lib/IR. For convenience, I've added a `getIterator()` accessor to `ilist_node` so that callers don't need to know how to spell the iterator class (i.e., they can use `X.getIterator()` instead of `Function::iterator(X)`). I'll eventually disallow these implicit conversions entirely, but there's a lot of code, so it doesn't make sense to do it all in one patch. One library or so at a time. Why? To root out cases of `getNextNode()` and `getPrevNode()` being used in iterator logic. The design of `ilist` makes that invalid when the current node could be at the back of the list, but it happens to "work" right now because of a bug where those functions never return `nullptr` if you're using a half-node sentinel. Before I can fix the function, I have to remove uses of it that rely on it misbehaving. (Maybe the function should just be deleted anyway? But I don't want deleting it -- potentially a huge project -- to block fixing ilist/iplist.) llvm-svn: 249782
* [opaque pointer types] Add an explicit value type to GlobalObjectDavid Blaikie2015-09-141-2/+2
| | | | | | | | | This is needed by all GlobalObjects (GlobalAlias, Function, GlobalVariable), see the GlobalObject::getValueType which is used in many places. If at some point that can be removed, then we can remove this member. llvm-svn: 247621
* Revert "[opaque pointer type] Pass GlobalAlias the actual pointer type ↵David Blaikie2015-09-141-14/+19
| | | | | | | | | | | | | | | | | rather than decomposing it into pointee type + address space" This was a flawed change - it just caused the getElementType call to be deferred until later, when we really need to remove it. Now that the IR for GlobalAliases has been updated, the root cause is addressed that way instead and this change is no longer needed (and in fact gets in the way - because we want to pass the pointee type directly down further). Follow up patches to push this through GlobalValue, bitcode format, etc, will come along soon. This reverts commit 236160. llvm-svn: 247585
* [opaque pointer types] Push the passing of value types up from ↵David Blaikie2015-08-211-4/+4
| | | | | | | | | Function/GlobalVariable to GlobalObject (coming next, pushing this up into GlobalValue, so it can store the value type directly) llvm-svn: 245742
* Devirtualize Constant::replaceUsesOfWithOnConstant.Pete Cooper2015-06-241-2/+2
| | | | | | | | | | | | | | | | | | | | This is part of the work to devirtualize Value. The old pattern was to call replaceUsesOfWithOnConstant which was overridden by subclasses. Those could then call replaceUsesOfWithOnConstantImpl on Constant to handle deleting the current value. To be consistent with other parts of the code, this has been changed so that we call the method on Constant, and that dispatches to an Impl on subclasses. As part of this, it made sense to rename the methods to be more descriptive. The new name is Constant::handleOperandChange, and it requires that all subclasses of Constant implement handleOperandChangeImpl, even if they just throw an error if they shouldn't be called. Reviewed by Duncan Exon Smith. llvm-svn: 240567
* Remove unused GlobalVariable::replaceUsesOfWithOnConstant. NFC.Pete Cooper2015-06-241-20/+4
| | | | | | | | | | | | | | | The only caller of this method is Value::replaceAllUsesWith which explicitly checks that we are not a GlobalValue. So replace the body with an unreachable to ensure that we never call it. The unreachable itself is moved to GlobalValue not GlobalVariable as that is the base class of all the globals we don't want to call this method on. Note, this patch is short lived as i'll soon refactor all callers of this method. llvm-svn: 240486
* Devirtualize Constant::destroyConstant.Pete Cooper2015-06-231-3/+3
| | | | | | | | | | | | | | | This reorganizes destroyConstant and destroyConstantImpl. Now there is only destroyConstant in Constant itself, while subclasses are required to implement destroyConstantImpl. destroyConstantImpl no longer calls delete but is instead only responsible for removing the constant from any maps in which it is contained. Reviewed by Duncan Exon Smith. llvm-svn: 240471
* 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
OpenPOWER on IntegriCloud