summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/Core.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Expose AttributeSetNode, use it to provide aggregate getter for attribute in ↵Amaury Sechet2016-07-211-0/+28
| | | | | | | | | | | | | | the C API. Summary: See D19181 for context. Reviewers: whitequark, Wallbraker, jyknight, echristo, bkramer, void Subscribers: mehdi_amini Differential Revision: http://reviews.llvm.org/D21265 llvm-svn: 276236
* Apply clang-tidy's modernize-loop-convert to most of lib/IR.Benjamin Kramer2016-06-261-2/+2
| | | | | | Only minor manual fixes. No functionality change intended. llvm-svn: 273813
* Add support for string attributes in the C API.Amaury Sechet2016-06-151-1/+23
| | | | | | | | | | | | Summary: As per title. This completes the C API Attribute support. Reviewers: Wallbraker, whitequark, echristo, rafael, jyknight Subscribers: mehdi_amini Differential Revision: http://reviews.llvm.org/D21365 llvm-svn: 272811
* Add support for callsite in the new C API for attributesAmaury Sechet2016-06-151-0/+18
| | | | | | | | | | | | Summary: The second consumer of attributes. Reviewers: Wallbraker, whitequark, echristo, rafael, jyknight Subscribers: mehdi_amini Differential Revision: http://reviews.llvm.org/D21266 llvm-svn: 272754
* Remove unused import. NFCAmaury Sechet2016-06-141-1/+0
| | | | llvm-svn: 272731
* IR: Introduce local_unnamed_addr attribute.Peter Collingbourne2016-06-141-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Change () to (void) in the C API.Amaury Sechet2016-06-121-1/+1
| | | | llvm-svn: 272506
* Make sure we have a Add/Remove/Has function for various thing that can have ↵Amaury Sechet2016-06-121-2/+68
| | | | | | | | | | | | | | attribute. Summary: This also deprecated the get attribute function familly. Reviewers: Wallbraker, whitequark, joker.eph, echristo, rafael, jyknight Subscribers: axw, joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D19181 llvm-svn: 272504
* Extract renaming from D19181Amaury Sechet2016-05-231-7/+2
| | | | | | | | | | | | Summary: This needs to get in before anything is released concerning attribute. If the old name gets in the wild, then we are stuck with it forever. Putting it in its own diff should getting that part at least in fast. Reviewers: Wallbraker, whitequark, joker.eph, echristo, rafael, jyknight Subscribers: llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D20417 llvm-svn: 270452
* Return a StringRef from getSection.Rafael Espindola2016-05-111-1/+3
| | | | | | This is similar to how getName is handled. llvm-svn: 269218
* Properly name LLVMSetIsInBounds's argument. NFCAmaury Sechet2016-05-011-2/+2
| | | | llvm-svn: 268176
* Reformat LLVMConstPointerNull. NFCAmaury Sechet2016-04-251-2/+1
| | | | llvm-svn: 267484
* Style fix in Core.h / Core.cpp. NFCAmaury Sechet2016-04-231-14/+10
| | | | llvm-svn: 267257
* Add LLVMGetAttrKindID in the C API in order to facilitate migration away ↵Amaury Sechet2016-04-201-0/+14
| | | | | | | | | | | | | | | | | from LLVMAttribute Summary: LLVMAttribute has outlived its utility and is becoming a problem for C API users that what to use all the LLVM attributes. In order to help moving away from LLVMAttribute in a smooth manner, this diff introduce LLVMGetAttrKindIDInContext, which can be used instead of the enum values. See D18749 for reference. Reviewers: Wallbraker, whitequark, joker.eph, echristo, rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D19081 llvm-svn: 266842
* Nuke getGlobalContext() from LLVM (but the C API)Mehdi Amini2016-04-141-4/+4
| | | | | | | | | | The only use for getGlobalContext() is in the C API. Let's just move the static global here and nuke the C++ API. Differential Revision: http://reviews.llvm.org/D19094 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266380
* Revert "Add LLVMGetAttrKindIDInContext in the C API in order to facilitate ↵Amaury Sechet2016-04-131-12/+0
| | | | | | | | migration away from LLVMAttribute" This reverts commit 0bcfd95c268bcb180a525e1837e84475df8acdc7. llvm-svn: 266259
* Add LLVMGetAttrKindIDInContext in the C API in order to facilitate migration ↵Amaury Sechet2016-04-131-0/+12
| | | | | | | | | | | | | | away from LLVMAttribute Summary: LLVMAttribute has outlived its utility and is becoming a problem for C API users that what to use all the LLVM attributes. In order to help moving away from LLVMAttribute in a smooth manner, this diff introduce LLVMGetAttrKindIDInContext, which can be used instead of the enum values. Reviewers: Wallbraker, whitequark, joker.eph, echristo Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D18749 llvm-svn: 266257
* [llvm-c] Expose LLVMContextGetDiagnostic{Handler,Context}Jeroen Ketema2016-04-081-1/+11
| | | | | | Differential Revision: http://reviews.llvm.org/D18820 llvm-svn: 265773
* [llvm-c] Add LLVMGetValueKind.Peter Zotov2016-04-061-0/+11
| | | | | | | | Patch by Nicole Mazzuca <npmazzuca@gmail.com>. Differential Revision: http://reviews.llvm.org/D18729 llvm-svn: 265608
* NFC: make AtomicOrdering an enum classJF Bastien2016-04-061-14/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In the context of http://wg21.link/lwg2445 C++ uses the concept of 'stronger' ordering but doesn't define it properly. This should be fixed in C++17 barring a small question that's still open. The code currently plays fast and loose with the AtomicOrdering enum. Using an enum class is one step towards tightening things. I later also want to tighten related enums, such as clang's AtomicOrderingKind (which should be shared with LLVM as a 'C++ ABI' enum). This change touches a few lines of code which can be improved later, I'd like to keep it as NFC for now as it's already quite complex. I have related changes for clang. As a follow-up I'll add: bool operator<(AtomicOrdering, AtomicOrdering) = delete; bool operator>(AtomicOrdering, AtomicOrdering) = delete; bool operator<=(AtomicOrdering, AtomicOrdering) = delete; bool operator>=(AtomicOrdering, AtomicOrdering) = delete; This is separate so that clang and LLVM changes don't need to be in sync. Reviewers: jyknight, reames Subscribers: jyknight, llvm-commits Differential Revision: http://reviews.llvm.org/D18775 llvm-svn: 265602
* [llvm-c] Expose LLVM{Get,Set}ModuleIdentifierPeter Zotov2016-04-051-0/+11
| | | | | | | | Patch by Nicole Mazzuca <npmazzuca@gmail.com>. Differential Revision: http://reviews.llvm.org/D18736 llvm-svn: 265394
* Style update in Core.h/Core.cpp . NFCAmaury Sechet2016-04-041-2/+2
| | | | llvm-svn: 265353
* Various style fix in Core.h/Core.cpp . NFCAmaury Sechet2016-04-031-7/+7
| | | | llvm-svn: 265277
* Expose IRBuilder::CreateAtomicCmpXchg as LLVMBuildAtomicCmpXchg in the C API.Mehdi Amini2016-03-191-0/+55
| | | | | | | | | | | | | Summary: Also expose getters and setters in the C API, so that the change can be tested. Reviewers: nhaehnle, axw, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D18260 From: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> llvm-svn: 263886
* Use templated version of unwrap instead of cats in the Core.cpp. NFCAmaury Sechet2016-03-131-6/+7
| | | | llvm-svn: 263349
* Move LLVMConstStructInContext so that declarationa nd definition order ↵Amaury Sechet2016-03-131-8/+8
| | | | | | match. NFC llvm-svn: 263348
* Small formating change in Core.cpp . NFCAmaury Sechet2016-03-071-3/+1
| | | | llvm-svn: 262860
* Add support for invoke/landingpad/resume in C API testAmaury Sechet2016-02-181-0/+34
| | | | | | | | | | | | Summary: As per title. There was a lot of part missing in the C API, so I had to extend the invoke and landingpad API. Reviewers: echristo, joker.eph, Wallbraker Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D17359 llvm-svn: 261254
* Add support for memory operations (load/store/gep) in C API echo testAmaury Sechet2016-02-171-0/+12
| | | | | | | | | | | | Summary: As per title. Reviewers: bogner, chandlerc, echristo, dblaikie, joker.eph, Wallbraker Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D17245 llvm-svn: 261174
* Deprecate LLVMGetDataLayout and replace it by LLVMGetDataLayoutStrAmaury Sechet2016-02-161-1/+5
| | | | | | | | | | | | Summary: The name is confusing as it matche another method on the module. Reviewers: joker.eph, Wallbraker, echristo Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D17283 llvm-svn: 260920
* Rename LLVMSetDataLayout's argument to match what they stand forAmaury Sechet2016-02-151-2/+2
| | | | llvm-svn: 260916
* Add support for phi nodes in the LLVM C API testAmaury Sechet2016-02-111-0/+4
| | | | | | | | | | | | Summary: This required to add binding to Instruction::removeFromParent so that instruction can be forward declared and then moved at the right place. Reviewers: bogner, chandlerc, echristo, dblaikie, joker.eph, Wallbraker Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D17057 llvm-svn: 260597
* Add support for struct in C API testAmaury Sechet2016-02-101-0/+22
| | | | | | | | | | | | Summary: As per title. This also include extra support for insertvalue and extracvalue. Reviewers: bogner, chandlerc, echristo, dblaikie, joker.eph, Wallbraker Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D17055 llvm-svn: 260335
* Add binding for counting argument and find called value of call and invoke ↵Amaury Sechet2016-02-101-12/+11
| | | | | | | | | | | | instruction from the C API. Summary: As per title. This remove the need to rely on internal knowledge of call and invoke instruction to find called value and argument count. Reviewers: bogner, chandlerc, echristo, dblaikie, joker.eph, Wallbraker Differential Revision: http://reviews.llvm.org/D17054 llvm-svn: 260332
* Add C binding for AllocaInst::getAllocatedTypeAmaury Sechet2016-02-091-0/+6
| | | | | | | | | | | | | | | Summary: Comes with an awesome test. Depends on D16912 Reviewers: bogner, chandlerc, echristo, dblaikie, joker.eph, Wallbraker Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16942 llvm-svn: 260313
* Improve the C API echo test tool to emit basic block is the right order.Amaury Sechet2016-02-091-0/+4
| | | | | | | | | | | | Summary: As per title. Also add a facility method to get the name of a basic block from the C API. Reviewers: bogner, chandlerc, echristo, dblaikie, joker.eph, Wallbraker Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16912 llvm-svn: 260309
* Remove static global GCNames from Function.cpp and move it to the ContextMehdi Amini2016-01-081-1/+1
| | | | | | | | | This remove the need for locking when deleting a function. Differential Revision: http://reviews.llvm.org/D15988 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 257139
* IR: Remove implicit iterator conversions from lib/IR, NFCDuncan P. N. Exon Smith2015-10-081-35/+35
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "[opaque pointer type] Pass GlobalAlias the actual pointer type ↵David Blaikie2015-09-141-1/+2
| | | | | | | | | | | | | | | | | 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
* [IR] Add token typesDavid Majnemer2015-08-141-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This introduces the basic functionality to support "token types". The motivation stems from the need to perform operations on a Value whose provenance cannot be obscured. There are several applications for such a type but my immediate motivation stems from WinEH. Our personality routine enforces a single-entry - single-exit regime for cleanups. After several rounds of optimizations, we may be left with a terminator whose "cleanup-entry block" is not entirely clear because control flow has merged two cleanups together. We have experimented with using labels as operands inside of instructions which are not terminators to indicate where we came from but found that LLVM does not expect such exotic uses of BasicBlocks. Instead, we can use this new type to clearly associate the "entry point" and "exit point" of our cleanup. This is done by having the cleanuppad yield a Token and consuming it at the cleanupret. The token type makes it impossible to obscure or otherwise hide the Value, making it trivial to track the relationship between the two points. What is the burden to the optimizer? Well, it turns out we have already paid down this cost by accepting that there are certain calls that we are not permitted to duplicate, optimizations have to watch out for such instructions anyway. There are additional places in the optimizer that we will probably have to update but early examination has given me the impression that this will not be heroic. Differential Revision: http://reviews.llvm.org/D11861 llvm-svn: 245029
* Add support to set/get ordering for load/store from the C APIAndrew Wilkins2015-08-021-1/+34
| | | | | | | | | | | | Summary: As per title Reviewers: chandlerc, bogner, majnemer, axw Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11141 llvm-svn: 243847
* Revert "Update LLVM bindings after r239940. ..."Reid Kleckner2015-07-161-1/+8
| | | | | | | | | | | Revert the changes to the C API LLVMBuildLandingPad that were part of the personality function move. We now set the personality on the parent function when the C API attempts to construct a landingpad with a personality. This reverts commit r240010. llvm-svn: 242372
* Add capability to get and set the personalitty function from the C APIAndrew Wilkins2015-07-141-0/+8
| | | | | | | | | | | | | | | Summary: The capability was lost with D10429 where the personality function was set at function level rather than landing pad level. Now there is no way to get/set the personality function from the C API. That is a problem. Note that the whole thing could be avoided by improving the C API testing, as started by D10725 Reviewers: chandlerc, bogner, majnemer, andrew.w.kaylor, rafael, rnk, axw Subscribers: rafael, llvm-commits Differential Revision: http://reviews.llvm.org/D10946 llvm-svn: 242104
* Move the personality function from LandingPadInst to FunctionDavid Majnemer2015-06-171-5/+2
| | | | | | | | | | | | | | | | | | | The personality routine currently lives in the LandingPadInst. This isn't desirable because: - All LandingPadInsts in the same function must have the same personality routine. This means that each LandingPadInst beyond the first has an operand which produces no additional information. - There is ongoing work to introduce EH IR constructs other than LandingPadInst. Moving the personality routine off of any one particular Instruction and onto the parent function seems a lot better than have N different places a personality function can sneak onto an exceptional function. Differential Revision: http://reviews.llvm.org/D10429 llvm-svn: 239940
* [C API] Add LLVMStructGetTypeAtIndex.Peter Zotov2015-06-041-0/+5
| | | | | | Patch by deadalnix (Amaury SECHET). llvm-svn: 239029
* [opaque pointer type] Pass GlobalAlias the actual pointer type rather than ↵David Blaikie2015-04-291-2/+1
| | | | | | | | | | | | | 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
* Add the i128 builtin type to LLVM.Kit Barton2015-04-171-0/+6
| | | | | | | | | | | The i128 type is needed as a builtin type in order to support the v1i128 vector type. The PowerPC ABI requires that the i128 and v1i128 types are handled differently when passed as parameters to functions (i128 is passed in pairs of GPRs, v1i128 is passed in a single vector register). http://reviews.llvm.org/D8564 llvm-svn: 235196
* [opaque pointer type] The last of the GEP IRBuilder API migrationsDavid Blaikie2015-04-051-1/+1
| | | | | | | | | There's still lots of callers passing nullptr, of course - some because they'll never be migrated (InstCombines for bitcasts - well they don't make any sense when the pointer type is opaque anyway, for example) and others that will need more engineering to pass Types around. llvm-svn: 234126
* [opaque pointer type] More GEP IRBuilder API migrations...David Blaikie2015-04-031-1/+2
| | | | llvm-svn: 234058
* [opaque pointer type] API migration for GEP constant factoriesDavid Blaikie2015-04-021-3/+3
| | | | | | | | | | | | | Require the pointee type to be passed explicitly and assert that it is correct. For now it's possible to pass nullptr here (and I've done so in a few places in this patch) but eventually that will be disallowed once all clients have been updated or removed. It'll be a long road to get all the way there... but if you have the cahnce to update your callers to pass the type explicitly without depending on a pointer's element type, that would be a good thing to do soon and a necessary thing to do eventually. llvm-svn: 233938
OpenPOWER on IntegriCloud