summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/Core.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* IR: Use the new DebugLoc API, NFCDuncan P. N. Exon Smith2015-03-301-3/+2
| | | | | | | | Update lib/IR and lib/Bitcode to use the new `DebugLoc` API. Added an explicit conversion to `bool` (avoiding a conversion to `MDLocation`), since a couple of these use cases need to handle broken code. llvm-svn: 233585
* [opaque pointer type] IRBuilder gep migration progressDavid Blaikie2015-03-151-1/+1
| | | | llvm-svn: 232294
* Fix invalid cast.Rafael Espindola2015-02-231-1/+1
| | | | | | | | Fixes PR22525. Patch by Ben Longbons with testcase by me. llvm-svn: 230271
* [PM] Remove the old 'PassManager.h' header file at the top level ofChandler Carruth2015-02-131-7/+7
| | | | | | | | | | | | | | | | | | | | LLVM's include tree and the use of using declarations to hide the 'legacy' namespace for the old pass manager. This undoes the primary modules-hostile change I made to keep out-of-tree targets building. I sent an email inquiring about whether this would be reasonable to do at this phase and people seemed fine with it, so making it a reality. This should allow us to start bootstrapping with modules to a certain extent along with making it easier to mix and match headers in general. The updates to any code for users of LLVM are very mechanical. Switch from including "llvm/PassManager.h" to "llvm/IR/LegacyPassManager.h". Qualify the types which now produce compile errors with "legacy::". The most common ones are "PassManager", "PassManagerBase", and "FunctionPassManager". llvm-svn: 229094
* Fix LLVMSetMetadata and LLVMAddNamedMetadataOperand for single value MDNodesBjorn Steinbrink2015-01-281-4/+18
| | | | | | | | | | | | | Summary: MetadataAsValue uses a canonical format that strips the MDNode if it contains only a single constant value. This triggers an assertion when trying to cast the value to a MDNode. Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D7165 llvm-svn: 227319
* IR: Split Metadata from ValueDuncan P. N. Exon Smith2014-12-091-24/+100
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Split `Metadata` away from the `Value` class hierarchy, as part of PR21532. Assembly and bitcode changes are in the wings, but this is the bulk of the change for the IR C++ API. I have a follow-up patch prepared for `clang`. If this breaks other sub-projects, I apologize in advance :(. Help me compile it on Darwin I'll try to fix it. FWIW, the errors should be easy to fix, so it may be simpler to just fix it yourself. This breaks the build for all metadata-related code that's out-of-tree. Rest assured the transition is mechanical and the compiler should catch almost all of the problems. Here's a quick guide for updating your code: - `Metadata` is the root of a class hierarchy with three main classes: `MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from the `Value` class hierarchy. It is typeless -- i.e., instances do *not* have a `Type`. - `MDNode`'s operands are all `Metadata *` (instead of `Value *`). - `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively. If you're referring solely to resolved `MDNode`s -- post graph construction -- just use `MDNode*`. - `MDNode` (and the rest of `Metadata`) have only limited support for `replaceAllUsesWith()`. As long as an `MDNode` is pointing at a forward declaration -- the result of `MDNode::getTemporary()` -- it maintains a side map of its uses and can RAUW itself. Once the forward declarations are fully resolved RAUW support is dropped on the ground. This means that uniquing collisions on changing operands cause nodes to become "distinct". (This already happened fairly commonly, whenever an operand went to null.) If you're constructing complex (non self-reference) `MDNode` cycles, you need to call `MDNode::resolveCycles()` on each node (or on a top-level node that somehow references all of the nodes). Also, don't do that. Metadata cycles (and the RAUW machinery needed to construct them) are expensive. - An `MDNode` can only refer to a `Constant` through a bridge called `ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`). As a side effect, accessing an operand of an `MDNode` that is known to be, e.g., `ConstantInt`, takes three steps: first, cast from `Metadata` to `ConstantAsMetadata`; second, extract the `Constant`; third, cast down to `ConstantInt`. The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have metadata schema owners transition away from using `Constant`s when the type isn't important (and they don't care about referring to `GlobalValue`s). In the meantime, I've added transitional API to the `mdconst` namespace that matches semantics with the old code, in order to avoid adding the error-prone three-step equivalent to every call site. If your old code was: MDNode *N = foo(); bar(isa <ConstantInt>(N->getOperand(0))); baz(cast <ConstantInt>(N->getOperand(1))); bak(cast_or_null <ConstantInt>(N->getOperand(2))); bat(dyn_cast <ConstantInt>(N->getOperand(3))); bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4))); you can trivially match its semantics with: MDNode *N = foo(); bar(mdconst::hasa <ConstantInt>(N->getOperand(0))); baz(mdconst::extract <ConstantInt>(N->getOperand(1))); bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2))); bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3))); bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4))); and when you transition your metadata schema to `MDInt`: MDNode *N = foo(); bar(isa <MDInt>(N->getOperand(0))); baz(cast <MDInt>(N->getOperand(1))); bak(cast_or_null <MDInt>(N->getOperand(2))); bat(dyn_cast <MDInt>(N->getOperand(3))); bay(dyn_cast_or_null<MDInt>(N->getOperand(4))); - A `CallInst` -- specifically, intrinsic instructions -- can refer to metadata through a bridge called `MetadataAsValue`. This is a subclass of `Value` where `getType()->isMetadataTy()`. `MetadataAsValue` is the *only* class that can legally refer to a `LocalAsMetadata`, which is a bridged form of non-`Constant` values like `Argument` and `Instruction`. It can also refer to any other `Metadata` subclass. (I'll break all your testcases in a follow-up commit, when I propagate this change to assembly.) llvm-svn: 223802
OpenPOWER on IntegriCloud