summaryrefslogtreecommitdiffstats
path: root/llvm/include/llvm-c/Core.h
Commit message (Collapse)AuthorAgeFilesLines
* [IR] Add support for empty tokensDavid Majnemer2015-11-111-0/+1
| | | | | | | | | | | | | | When working with tokens, it is often the case that one has instructions which consume a token and produce a new token. Currently, we have no mechanism to represent an initial token state. Instead, we can create a notional "empty token" by inventing a new constant which captures the semantics we would like. This new constant is called ConstantTokenNone and is written textually as "token none". Differential Revision: http://reviews.llvm.org/D14581 llvm-svn: 252811
* Fix some Clang-tidy modernize warnings, other minor fixes.Eugene Zelenko2015-11-041-9/+8
| | | | | | | | Fixed warnings are: modernize-use-override, modernize-use-nullptr and modernize-redundant-void-arg. Differential revision: http://reviews.llvm.org/D14312 llvm-svn: 252087
* [WinEH] Add cleanupendpad instructionJoseph Tremoulet2015-09-031-4/+6
| | | | | | | | | | | | | | | | | | | | | | | Summary: Add a `cleanupendpad` instruction, used to mark exceptional exits out of cleanups (for languages/targets that can abort a cleanup with another exception). The `cleanupendpad` instruction is similar to the `catchendpad` instruction in that it is an EH pad which is the target of unwind edges in the handler and which itself has an unwind edge to the next EH action. The `cleanupendpad` instruction, similar to `cleanupret` has a `cleanuppad` argument indicating which cleanup it exits. The unwind successors of a `cleanuppad`'s `cleanupendpad`s must agree with each other and with its `cleanupret`s. Update WinEHPrepare (and docs/tests) to accomodate `cleanupendpad`. Reviewers: rnk, andrew.w.kaylor, majnemer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12433 llvm-svn: 246751
* [IR] Add token typesDavid Majnemer2015-08-141-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-0/+2
| | | | | | | | | | | | Summary: As per title Reviewers: chandlerc, bogner, majnemer, axw Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11141 llvm-svn: 243847
* New EH representation for MSVC compatibilityDavid Majnemer2015-07-311-1/+13
| | | | | | | | | | This introduces new instructions neccessary to implement MSVC-compatible exception handling support. Most of the middle-end and none of the back-end haven't been audited or updated to take them into account. Differential Revision: http://reviews.llvm.org/D11097 llvm-svn: 243766
* Fix typo "fuction" noticed in comments in AssumptionCache.h, and also all ↵Nick Lewycky2015-07-291-1/+1
| | | | | | | | the other files that have the same typo. All comments, no functionality change! (Merely a "fuctionality" change.) Bonus change to remove emacs major mode marker from SystemZMachineFunctionInfo.cpp because emacs already knows it's C++ from the extension. Also fix typo "appeary" in AMDGPUMCAsmInfo.h. llvm-svn: 243585
* Revert "Update LLVM bindings after r239940. ..."Reid Kleckner2015-07-161-1/+2
| | | | | | | | | | | 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/+14
| | | | | | | | | | | | | | | 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
* Revert the new EH instructionsDavid Majnemer2015-07-101-13/+1
| | | | | | This reverts commits r241888-r241891, I didn't mean to commit them. llvm-svn: 241893
* New EH representation for MSVC compatibilityDavid Majnemer2015-07-101-1/+13
| | | | | | | | | | | | | | | Summary: This introduces new instructions neccessary to implement MSVC-compatible exception handling support. Most of the middle-end and none of the back-end haven't been audited or updated to take them into account. Reviewers: rnk, JosephTremoulet, reames, nlewycky, rjmccall Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11041 llvm-svn: 241888
* Update LLVM bindings after r239940. Apparently these aren't included inDaniel Jasper2015-06-181-2/+1
| | | | | | | | | any tests and I even don't know how to run the tests. This seems like a minimal change to make them work again, although I can't really verify at this point. Additionally, it probably makes sense to propagate the personality parameter removal further. llvm-svn: 240010
* Add safestack attribute to LLVMAttribute enum and Go bindings. CorrectPeter Collingbourne2015-06-151-9/+9
| | | | | | | constants in commented-out part of LLVMAttribute enum. Add tests that verify that the safestack attribute is only allowed as a function attribute. llvm-svn: 239772
* [C API] Add LLVMStructGetTypeAtIndex.Peter Zotov2015-06-041-0/+7
| | | | | | Patch by deadalnix (Amaury SECHET). llvm-svn: 239029
* [IR] Introduce a dereferenceable_or_null(N) attribute.Sanjoy Das2015-04-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: If a pointer is marked as dereferenceable_or_null(N), LLVM assumes it is either `null` or `dereferenceable(N)` or both. This change only introduces the attribute and adds a token test case for the `llvm-as` / `llvm-dis`. It does not hook up other parts of the optimizer to actually exploit the attribute -- those changes will come later. For pointers in address space 0, `dereferenceable(N)` is now exactly equivalent to `dereferenceable_or_null(N)` && `nonnull`. For other address spaces, `dereferenceable(N)` is potentially weaker than `dereferenceable_or_null(N)` && `nonnull` (since we could have a null `dereferenceable(N)` pointer). The motivating case for this change is Java (and other managed languages), where pointers are either `null` or dereferenceable up to some usually known-at-compile-time constant offset. Reviewers: rafael, hfinkel Reviewed By: hfinkel Subscribers: nicholas, llvm-commits Differential Revision: http://reviews.llvm.org/D8650 llvm-svn: 235132
* IR: Split Metadata from ValueDuncan P. N. Exon Smith2014-12-091-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [C API] PR19859: Add functions to query and modify branches.Peter Zotov2014-10-281-0/+61
| | | | | | Patch by Gabriel Radanne <drupyog@zoho.com>. llvm-svn: 220817
* [C API] PR19859: Add LLVMGetFCmpPredicate and LLVMConstRealGetDouble.Peter Zotov2014-10-281-0/+18
| | | | | | Patch by Gabriel Radanne <drupyog@zoho.com>. llvm-svn: 220814
* [LLVM-C] Add LLVMInstructionClone.Peter Zotov2014-10-171-0/+10
| | | | llvm-svn: 220007
* C API: Add LLVMCloneModule()Tom Stellard2014-10-011-0/+4
| | | | llvm-svn: 218775
* [LLVM-C] Expose User::getOperandUse as LLVMGetOperandUse.Peter Zotov2014-08-121-0/+7
| | | | | | Patch by Gabriel Radanne <drupyog@zoho.com> llvm-svn: 215419
* [LLVM-C] Add LLVM{IsConstantString,GetAsString,GetElementAsConstant}.Peter Zotov2014-08-031-0/+21
| | | | llvm-svn: 214676
* Add a dereferenceable attributeHal Finkel2014-07-181-0/+1
| | | | | | | | | This attribute indicates that the parameter or return pointer is dereferenceable. Practically speaking, loads from such a pointer within the associated byte range are safe to speculatively execute. Such pointer parameters are common in source languages (C++ references, for example). llvm-svn: 213385
* Re-apply r211287: Remove support for LLVM runtime multi-threading.Chandler Carruth2014-06-271-8/+5
| | | | | | | I'll fix the problems in libclang and other projects in ways that don't require <mutex> until we sort out the cygwin situation. llvm-svn: 211900
* Revert r211287, "Remove support for LLVM runtime multi-threading."NAKAMURA Takumi2014-06-241-5/+8
| | | | | | libclang still requires it on cygming, lack of incomplete <mutex>. llvm-svn: 211592
* Remove support for LLVM runtime multi-threading.Zachary Turner2014-06-191-8/+5
| | | | | | | | | | | | | After a number of previous small iterations, the functions llvm_start_multithreaded() and llvm_stop_multithreaded() have been reduced essentially to no-ops. This change removes them entirely. Reviewed by: rnk, dblaikie Differential Revision: http://reviews.llvm.org/D4216 llvm-svn: 211287
* Revert r211066, 211067, 211068, 211069, 211070.Zachary Turner2014-06-161-5/+8
| | | | | | | These were committed accidentally from the wrong branch before having a review sign-off. llvm-svn: 211072
* Remove some more code out into a separate CL.Zachary Turner2014-06-161-8/+5
| | | | llvm-svn: 211067
* Revert "Remove support for runtime multi-threading."Zachary Turner2014-06-101-5/+8
| | | | | | This reverts revision r210600. llvm-svn: 210603
* Remove support for runtime multi-threading.Zachary Turner2014-06-101-8/+5
| | | | | | | | | | | | | | | | | | | | | This patch removes the functions llvm_start_multithreaded() and llvm_stop_multithreaded(), and changes llvm_is_multithreaded() to return a constant value based on the value of the compile-time definition LLVM_ENABLE_THREADS. Previously, it was possible to have compile-time support for threads on, and runtime support for threads off, in which case certain mutexes were not allocated or ever acquired. Now, if the build is created with threads enabled, mutexes are always acquired. A test before/after patch of compiling a very large TU showed no noticeable performance impact of this change. Reviewers: rnk Differential Revision: http://reviews.llvm.org/D4076 llvm-svn: 210600
* Add a new attribute called 'jumptable' that creates jump-instruction tables ↵Tom Roeder2014-06-051-1/+2
| | | | | | | | | | | | for functions marked with this attribute. It includes a pass that rewrites all indirect calls to jumptable functions to pass through these tables. This also adds backend support for generating the jump-instruction tables on ARM and X86. Note that since the jumptable attribute creates a second function pointer for a function, any function marked with jumptable must also be marked with unnamed_addr. llvm-svn: 210280
* Add 'nonnull', a new parameter and return attribute which indicates that the ↵Nick Lewycky2014-05-201-1/+2
| | | | | | pointer is not null. Instcombine will elide comparisons between these and null. Patch by Luqman Aden! llvm-svn: 209185
* Add C API for thread yielding callback.Juergen Ributzka2014-05-161-0/+9
| | | | | | | | | | | | | | | | | | | | | Sometimes a LLVM compilation may take more time then a client would like to wait for. The problem is that it is not possible to safely suspend the LLVM thread from the outside. When the timing is bad it might be possible that the LLVM thread holds a global mutex and this would block any progress in any other thread. This commit adds a new yield callback function that can be registered with a context. LLVM will try to yield by calling this callback function, but there is no guaranteed frequency. LLVM will only do so if it can guarantee that suspending the thread won't block any forward progress in other LLVM contexts in the same process. Once the client receives the call back it can suspend the thread safely and resume it at another time. Related to <rdar://problem/16728690> llvm-svn: 208945
* Revert "[PM] Add pass run listeners to the pass manager."Juergen Ributzka2014-05-151-27/+0
| | | | | | | Revert the current implementation and C API. New implementation and C APIs are in the works. llvm-svn: 208904
* Split GlobalValue into GlobalValue and GlobalObject.Rafael Espindola2014-05-131-2/+3
| | | | | | | | | 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
* [PM] Add pass run listeners to the pass manager.Juergen Ributzka2014-04-281-0/+27
| | | | | | | | | | | | | | | | | | This commit provides the necessary C/C++ APIs and infastructure to enable fine- grain progress report and safe suspension points after each pass in the pass manager. Clients can provide a callback function to the pass manager to call after each pass. This can be used in a variety of ways (progress report, dumping of IR between passes, safe suspension of threads, etc). The run listener list is maintained in the LLVMContext, which allows a multi- threaded client to be only informed for it's own thread. This of course assumes that the client created a LLVMContext for each thread. This fixes <rdar://problem/16728690> llvm-svn: 207430
* Added new functionality to LLVM C API to use DiagnosticInfo to handle errorsTom Stellard2014-04-161-0/+37
| | | | | | Patch by: Darren Powell llvm-svn: 206407
* llvm-c: expose unnamedaddr field of globalsTim Northover2014-03-101-0/+2
| | | | | | Patch by Manuel Jacob. llvm-svn: 203482
* [Modules] Fix a layering issue that is actually impacting the modulesChandler Carruth2014-03-061-10/+1
| | | | | | | | | | | | | | | | | | | | | | selfhost. The 'Core.h' C-API header is part of the IR LLVM library. (One might even argue it should be called IR.h, but that's a separate point.) We can't include it into a Support header without violating the layering, and in a way that breaks modules. MemoryBuffer's opaque C type was being defined in the Core.h C-API header despite being in the Support library, and thus we ended up with this weird issue. It turns out that there were other constructs from the Support library in the Core.h header. This patch lifts all of them into Support.h and then includes that into Core.h. The only possible fallout is if someone was including Support.h and relying on Core.h to be visible for their own uses. Considering the narrow interface actually provided by the C-API for the Support library, this seems a very, very unlikely mistake. llvm-svn: 203071
* [C API] Implement LLVM{Get,Set}Alignment for AllocaInst.Peter Zotov2014-03-051-0/+2
| | | | | | Patch by Manuel Jacob. llvm-svn: 202936
* C API: Add functions to get or set a GlobalValue's DLLStorageClassReid Kleckner2014-03-051-0/+8
| | | | | | Patch by Manuel Jacob! llvm-svn: 202928
* Decouple dllexport/dllimport from linkageNico Rieck2014-01-141-2/+2
| | | | | | | | | | | | | | | | | | | Representing dllexport/dllimport as distinct linkage types prevents using these attributes on templates and inline functions. Instead of introducing further mixed linkage types to include linkonce and weak ODR, the old import/export linkage types are replaced with a new separate visibility-like specifier: define available_externally dllimport void @f() {} @Var = dllexport global i32 1, align 4 Linkage for dllexported globals and functions is now equal to their linkage without dllexport. Imported globals and functions must be either declarations with external linkage, or definitions with AvailableExternallyLinkage. llvm-svn: 199218
* Revert "Decouple dllexport/dllimport from linkage"Nico Rieck2014-01-141-2/+2
| | | | | | | | Revert this for now until I fix an issue in Clang with it. This reverts commit r199204. llvm-svn: 199207
* Decouple dllexport/dllimport from linkageNico Rieck2014-01-141-2/+2
| | | | | | | | | | | | | | | | | | | Representing dllexport/dllimport as distinct linkage types prevents using these attributes on templates and inline functions. Instead of introducing further mixed linkage types to include linkonce and weak ODR, the old import/export linkage types are replaced with a new separate visibility-like specifier: define available_externally dllimport void @f() {} @Var = dllexport global i32 1, align 4 Linkage for dllexported globals and functions is now equal to their linkage without dllexport. Imported globals and functions must be either declarations with external linkage, or definitions with AvailableExternallyLinkage. llvm-svn: 199204
* Begin adding docs and IR-level support for the inalloca attributeReid Kleckner2013-12-191-1/+2
| | | | | | | | | | | | | | | | | | | The inalloca attribute is designed to support passing C++ objects by value in the Microsoft C++ ABI. It behaves the same as byval, except that it always implies that the argument is in memory and that the bytes are never copied. This attribute allows the caller to take the address of an outgoing argument's memory and execute arbitrary code to store into it. This patch adds basic IR support, docs, and verification. It does not attempt to implement any lowering or fix any possibly broken transforms. When this patch lands, a complete description of this feature should appear at http://llvm.org/docs/InAlloca.html . Differential Revision: http://llvm-reviews.chandlerc.com/D2173 llvm-svn: 197645
* Expose the fence instruction via the C API.Filip Pizlo2013-11-201-1/+3
| | | | llvm-svn: 195173
* Add addrspacecast instruction.Matt Arsenault2013-11-151-0/+5
| | | | | | Patch by Michele Scandale! llvm-svn: 194760
* This exposes the new calling conventions (WebKit_JS and AnyReg) via the C ↵Filip Pizlo2013-11-091-0/+2
| | | | | | API by adding them to the enumeration in Core.h. llvm-svn: 194323
* [llvm-c] Implement LLVMPrintValueToStringPeter Zotov2013-11-061-0/+8
| | | | | | Original patch by Chris Wailes llvm-svn: 194135
* [llvm-c] (PR16190) Add LLVMIsA* functions for ConstantDataSequential and ↵Peter Zotov2013-11-051-0/+3
| | | | | | | | subclasses Original patch by David Monniaux llvm-svn: 194074
OpenPOWER on IntegriCloud