summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/Globals.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [Alignment][NFC] Remove dependency on GlobalObject::setAlignment(unsigned)Guillaume Chatelet2019-10-151-1/+1
| | | | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: arsenm, mehdi_amini, jvesely, nhaehnle, hiraditya, steven_wu, dexonsmith, dang, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68944 llvm-svn: 374880
* Use parenthses to silence warning.Bill Wendling2019-08-061-2/+2
| | | | llvm-svn: 368105
* [LLVM][Alignment] Introduce Alignment In GlobalObjectGuillaume Chatelet2019-08-061-5/+9
| | | | | | | | | | | | | | | | | | | Summary: This is patch is part of a serie to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: jfb Subscribers: hiraditya, dexonsmith, llvm-commits, courbet Tags: #llvm Differential Revision: https://reviews.llvm.org/D65748 Address comments llvm-svn: 368000
* IR: Teach GlobalIndirectSymbol::getBaseObject() to handle more kinds of ↵Peter Collingbourne2019-07-241-0/+37
| | | | | | | | | | | | | | | | | | | | | expressions. For aliases, any expression that lowers at the MC level to global_object or global_object+constant is valid at the object file level. getBaseObject() should return a result if the aliasee ends up being of that form even if the IR used to produce it is somewhat unconventional. Note that this is different from what stripInBoundsOffsets() and that family of functions is doing. Those functions are concerned about semantic properties of IR, whereas here we only care about the lowering result. Therefore reimplement getBaseObject() in a way that matches the lowering result. This fixes a crash when producing a summary for aliases such as that in the included test case. Differential Revision: https://reviews.llvm.org/D65115 llvm-svn: 366952
* Add IR support, ELF section and user documentation for partitioning feature.Peter Collingbourne2019-05-291-0/+23
| | | | | | | | | | | | The partitioning feature was proposed here: http://lists.llvm.org/pipermail/llvm-dev/2019-February/130583.html This is mostly just documentation. The feature itself will be contributed in subsequent patches. Differential Revision: https://reviews.llvm.org/D60242 llvm-svn: 361923
* IR: Give the TypeAllocator a more generic name and start using it for ↵Peter Collingbourne2019-05-291-3/+2
| | | | | | | | section names as well. NFCI. This prepares us to start using it for partition names. llvm-svn: 361922
* 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
* [IR] Allow increasing the alignment of dso-local globals.Eli Friedman2018-10-311-1/+1
| | | | | | | | | I think this is the actual important property; the previous visibility check was an approximation. Differential Revision: https://reviews.llvm.org/D53852 llvm-svn: 345790
* Allow creating llvm::Function in non-zero address spacesAlexander Richardson2018-08-231-0/+5
| | | | | | | | | | | | | | | | | | | | Most users won't have to worry about this as all of the 'getOrInsertFunction' functions on Module will default to the program address space. An overload has been added to Function::Create to abstract away the details for most callers. This is based on https://reviews.llvm.org/D37054 but without the changes to make passing a Module to Function::Create() mandatory. I have also added some more tests and fixed the LLParser to accept call instructions for types in the program address space. Reviewed By: bjope Differential Revision: https://reviews.llvm.org/D47541 llvm-svn: 340519
* Sink Analysis/ObjectUtil(canBeOmittedFromSymbolTable) into IR so it can be ↵David Blaikie2018-03-211-0/+18
| | | | | | legitimately be used by Object/IRSymtab llvm-svn: 328135
* Represent runtime preemption in the IR.Sean Fertile2017-10-261-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently we do not represent runtime preemption in the IR, which has several drawbacks: 1) The semantics of GlobalValues differ depending on the object file format you are targeting (as well as the relocation-model and -fPIE value). 2) We have no way of disabling inlining of run time interposable functions, since in the IR we only know if a function is link-time interposable. Because of this llvm cannot support elf-interposition semantics. 3) In LTO builds of executables we will have extra knowledge that a symbol resolved to a local definition and can't be preemptable, but have no way to propagate that knowledge through the compiler. This patch adds preemptability specifiers to the IR with the following meaning: dso_local --> means the compiler may assume the symbol will resolve to a definition within the current linkage unit and the symbol may be accessed directly even if the definition is not within this compilation unit. dso_preemptable --> means that the compiler must assume the GlobalValue may be replaced with a definition from outside the current linkage unit at runtime. To ease transitioning dso_preemptable is treated as a 'default' in that low-level codegen will still do the same checks it did previously to see if a symbol should be accessed indirectly. Eventually when IR producers emit the specifiers on all Globalvalues we can change dso_preemptable to mean 'always access indirectly', and remove the current logic. Differential Revision: https://reviews.llvm.org/D20217 llvm-svn: 316668
* Sort the remaining #include lines in include/... and lib/....Chandler Carruth2017-06-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
* IR: When creating a global variable, assert that its type is valid.Peter Collingbourne2017-06-041-0/+4
| | | | llvm-svn: 304690
* Add support for handling ifuncs to GlobalValue::getBaseObjectTeresa Johnson2017-05-151-1/+1
| | | | | | | | | | | | | | | | | Summary: All GlobalIndirectSymbol types (not just GlobalAlias) should return their base object. Without this patch LTO would warn "Unable to determine comdat of alias!" for an ifunc. Reviewers: pcc Subscribers: mehdi_amini, inglorion, llvm-commits Differential Revision: https://reviews.llvm.org/D33202 llvm-svn: 303096
* De-virtualize GlobalValueReid Kleckner2017-05-111-11/+31
| | | | | | | | | | | | | | | The erase/remove from parent methods now use a switch table to remove themselves from their appropriate parent ilist. The copyAttributesFrom method is now completely non-virtual, since we only ever copy attributes from a global of the appropriate type. Pre-requisite to de-virtualizing Value to save a vptr (https://reviews.llvm.org/D31261). NFC llvm-svn: 302823
* [IR] Allow attributes with global variablesJaved Absar2017-05-111-0/+1
| | | | | | | | | | | | | This patch extends llvm-ir to allow attributes to be set on global variables. An RFC was sent out earlier by my colleague James Molloy: http://lists.llvm.org/pipermail/cfe-dev/2017-March/053100.html A key part of that proposal was to extend LLVM-IR to carry attributes on global variables. This generic feature could be useful for multiple purposes. In our present context, it would be useful to carry user specified sections for bss/rodata/data. Reviewed by: Jonathan Roelofs, Reid Kleckner Differential Revision: https://reviews.llvm.org/D32009 llvm-svn: 302794
* [IR] Implement pairs of non-const and const methods using the const version ↵Craig Topper2017-03-271-2/+2
| | | | | | | | instead of the non-const version. NFCI This removes a const_cast of the this pointer. llvm-svn: 298831
* [IR] Inline some Function accessorsReid Kleckner2017-03-161-12/+0
| | | | | | | | | I checked that all of these out-of-line methods previously compiled to simple loads and bittests, so they are pretty good candidates for inlining. In particular, arg_size() and arg_empty() are popular and are just two loads, so they seem worth inlining. llvm-svn: 297963
* [GlobalObject] Fix setSection("")Keno Fischer2017-02-151-1/+3
| | | | | | | | | | | | | Summary: In rL291613, the section name was interned in LLVMContext. However, this broke the ability to remove the section from a GlobalObject, because it tried to intern empty strings, which is not allowed. Fix that and add an appropriate regression test. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D29795 llvm-svn: 295238
* Move the section name from GlobalObject to the LLVMContextReid Kleckner2017-01-101-4/+22
| | | | | | | | | | | | | | | | | | | | | | | Summary: Convention wisdom says that bytes in Function are precious, and the vast, vast majority of globals do not live in special sections. Even when they do, they tend to live in the same section. Store the section name on the LLVMContext in a StringSet, and maintain a map from GlobalObject* to section name like we do for metadata, prefix data, etc. The fact that we've survived this long wasting at least three pointers of space in Function suggests that Function bytes are perhaps not as precious as we once thought. Given that most functions have metadata attachments when debug info is enabled, we might consider adding a pointer here to make that access more efficient. Reviewers: jlebar, dexonsmith, mehdi_amini Subscribers: mehdi_amini, aprantl, llvm-commits Differential Revision: https://reviews.llvm.org/D28150 llvm-svn: 291613
* Add a static_assert about the sizeof(GlobalValue)Reid Kleckner2016-12-291-0/+7
| | | | | | | | I added one for Value back in r262045, and I'm starting to think we should have these for any class with bitfields whose memory efficiency really matters. llvm-svn: 290698
* IR, X86: Understand !absolute_symbol metadata on global variables.Peter Collingbourne2016-12-081-0/+21
| | | | | | | | | | | | | | | | | Summary: Attaching !absolute_symbol to a global variable does two things: 1) Marks it as an absolute symbol reference. 2) Specifies the value range of that symbol's address. Teach the X86 backend to allow absolute symbols to appear in place of immediates by extending the relocImm and mov64imm32 matchers. Start using relocImm in more places where it is legal. As previously proposed on llvm-dev: http://lists.llvm.org/pipermail/llvm-dev/2016-October/105800.html Differential Revision: https://reviews.llvm.org/D25878 llvm-svn: 289087
* Bitcode: Change the materializer interface to return llvm::Error.Peter Collingbourne2016-11-091-1/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D26439 llvm-svn: 286382
* IR: Deduplicate getParent() functions on derived classes of GlobalValue into ↵Peter Collingbourne2016-10-251-12/+0
| | | | | | the base class. NFCI. llvm-svn: 285050
* Target: Change various section classifiers in TargetLoweringObjectFile to ↵Peter Collingbourne2016-10-241-0/+8
| | | | | | | | | | | | | | | | take a GlobalObject. These functions are about classifying a global which will actually be emitted, so it does not make sense for them to take a GlobalValue which may for example be an alias. Change the Mach-O object writer and the Hexagon, Lanai and MIPS backends to look through aliases before using TargetLoweringObjectFile interfaces. These are functional changes but all appear to be bug fixes. Differential Revision: https://reviews.llvm.org/D25917 llvm-svn: 285006
* [IR] [DAE] Copy comdats during DAE, and don't copy comdats in ↵Justin Lebar2016-06-151-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | GlobalObject::copyAttributesFrom. Summary: This reverts the changes to Globals.cpp and IRMover.cpp in "[IR] Copy comdats in GlobalObject::copyAttributesFrom" (D20631, rL270743). The DeadArgElim test is left unchanged, and we change DAE to explicitly copy comdats. The reverted change breaks copyAttributesFrom when the destination lives in a different module from the source. The decision in D21255 was to revert this patch and handle comdat copying separately from copyAttributesFrom. Reviewers: majnemer, rnk Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D21403 llvm-svn: 272855
* IR: Introduce local_unnamed_addr attribute.Peter Collingbourne2016-06-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a local_unnamed_addr attribute is attached to a global, the address is known to be insignificant within the module. It is distinct from the existing unnamed_addr attribute in that it only describes a local property of the module rather than a global property of the symbol. This attribute is intended to be used by the code generator and LTO to allow the linker to decide whether the global needs to be in the symbol table. It is possible to exclude a global from the symbol table if three things are true: - This attribute is present on every instance of the global (which means that the normal rule that the global must have a unique address can be broken without being observable by the program by performing comparisons against the global's address) - The global has linkonce_odr linkage (which means that each linkage unit must have its own copy of the global if it requires one, and the copy in each linkage unit must be the same) - It is a constant or a function (which means that the program cannot observe that the unique-address rule has been broken by writing to the global) Although this attribute could in principle be computed from the module contents, LTO clients (i.e. linkers) will normally need to be able to compute this property as part of symbol resolution, and it would be inefficient to materialize every module just to compute it. See: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html for earlier discussion. Part of the fix for PR27553. Differential Revision: http://reviews.llvm.org/D20348 llvm-svn: 272709
* Add support for metadata attachments for global variables.Peter Collingbourne2016-05-311-3/+7
| | | | | | | | | | This patch adds an IR, assembly and bitcode representation for metadata attachments for globals. Future patches will port existing features to use these new attachments. Differential Revision: http://reviews.llvm.org/D20074 llvm-svn: 271348
* [IR] Copy comdats in GlobalObject::copyAttributesFromReid Kleckner2016-05-251-0/+1
| | | | | | | | | | | | | | This is probably correct for all uses except cross-module IR linking, where we need to move the comdat from the source module to the destination module. Fixes PR27870. Reviewers: majnemer Differential Revision: http://reviews.llvm.org/D20631 llvm-svn: 270743
* Return a StringRef from getSection.Rafael Espindola2016-05-111-2/+7
| | | | | | This is similar to how getName is handled. llvm-svn: 269218
* [GCC] Attribute ifunc support in llvmDmitry Polukhin2016-04-071-0/+34
| | | | | | | | | | | This patch add support for GCC attribute((ifunc("resolver"))) for targets that use ELF as object file format. In general ifunc is a special kind of function alias with type @gnu_indirect_function. Patch for Clang http://reviews.llvm.org/D15524 Differential Revision: http://reviews.llvm.org/D15525 llvm-svn: 265667
* [IFUNC] Use GlobalIndirectSymbol when aliases and ifuncs have something similarDmitry Polukhin2016-04-051-2/+2
| | | | | | | | | | | Second part extracted from http://reviews.llvm.org/D15525 Use GlobalIndirectSymbol in all cases when aliases and ifuncs have something in common. Differential Revision: http://reviews.llvm.org/D18754 llvm-svn: 265382
* constify GlobalValue::getGUID() and GlobalValue::getGlobalIdentifier() (NFC)Mehdi Amini2016-04-021-1/+1
| | | | | From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265217
* [IFUNC] Introduce GlobalIndirectSymbol as a base class for alias and ifuncDmitry Polukhin2016-03-311-5/+15
| | | | | | | | | | | | This patch is a part of http://reviews.llvm.org/D15525 GlobalIndirectSymbol class contains common implementation for both aliases and ifuncs. This patch should be NFC change that just prepare common code for ifunc support. Differential Revision: http://reviews.llvm.org/D18433 llvm-svn: 265016
* Add GUID/getGlobalIdentifier() non-static API to global valueMehdi Amini2016-03-251-0/+5
| | | | | | | | | | | | | | | Summary: These are just helpers calling their static counter part to simplify client code. Reviewers: tejohnson Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D18339 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 264382
* Move global ID computation from Function to GlobalValue (NFC)Teresa Johnson2016-03-151-0/+24
| | | | | | | | Since the static getGlobalIdentifier and getGUID methods are now called for global values other than functions, reflect that by moving these methods to the GlobalValue class. llvm-svn: 263524
* Simplify handleOperandChangeImpl() removing last argument (NFC)Mehdi Amini2016-02-101-1/+1
| | | | | | | | | | The Use argument was used to compute the operand number for a fast path when replacing only one operand. However we always have to go through all the operands. So the argument number can be recomputed locally anyway. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 260454
* 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
OpenPOWER on IntegriCloud