summaryrefslogtreecommitdiffstats
path: root/llvm/include/llvm-c
Commit message (Collapse)AuthorAgeFilesLines
* Finish removing DestroySource.Rafael Espindola2014-12-231-8/+1
| | | | | | Fixes pr21901. llvm-svn: 224782
* [C API] Expose LLVMGetGlobalValueAddress and LLVMGetFunctionAddress.Peter Zotov2014-12-221-0/+4
| | | | | | Patch by Ramkumar Ramachandra <artagnon@gmail.com> llvm-svn: 224720
* 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
* libLTO: Allow linker to choose context of modules and codegenDuncan P. N. Exon Smith2014-11-111-1/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add API for specifying which `LLVMContext` each `lto_module_t` and `lto_code_gen_t` is in. In particular, this enables the following flow: for (auto &File : Files) { lto_module_t M = lto_module_create_in_local_context(File...); querySymbols(M); lto_module_dispose(M); } lto_code_gen_t CG = lto_codegen_create_in_local_context(); for (auto &File : FilesToLink) { lto_module_t M = lto_module_create_in_codegen_context(File..., CG); lto_codegen_add_module(CG, M); lto_module_dispose(M); } lto_codegen_compile(CG); lto_codegen_write_merged_modules(CG, ...); lto_codegen_dispose(CG); This flow has a few benefits. - Only one module (two if you count the combined module in the code generator) is in memory at a time. - Metadata (and constants) from files that are parsed to query symbols but not linked into the code generator don't pollute the global context. - The first for loop can be parallelized, since each module is in its own context. - When the code generator is disposed, the memory from LTO gets freed. rdar://problem/18767512 llvm-svn: 221733
* [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
* Introduce LLVMParseCommandLineOptions C API function.Peter Collingbourne2014-10-161-0/+11
| | | | llvm-svn: 219975
* Introduce LLVMWriteBitcodeToMemoryBuffer C API function.Peter Collingbourne2014-10-141-0/+3
| | | | llvm-svn: 219643
* C API: Add LLVMCloneModule()Tom Stellard2014-10-011-0/+4
| | | | llvm-svn: 218775
* Extend C disassembler API to allow specifying target featuresBradley Smith2014-09-301-3/+17
| | | | llvm-svn: 218682
* [C API] Make the 'lower switch' pass available via the C API.Juergen Ributzka2014-09-111-0/+3
| | | | llvm-svn: 217630
* Add an AlignmentFromAssumptions PassHal Finkel2014-09-071-0/+3
| | | | | | | | | | | | | | | | | | | | | This adds a ScalarEvolution-powered transformation that updates load, store and memory intrinsic pointer alignments based on invariant((a+q) & b == 0) expressions. Many of the simple cases we can get with ValueTracking, but we still need something like this for the more complicated cases (such as those with an offset) that require some algebra. Note that gcc's __builtin_assume_aligned's optional third argument provides exactly for this kind of 'misalignment' offset for which this kind of logic is necessary. The primary motivation is to fixup alignments for vector loads/stores after vectorization (and unrolling). This pass is added to the optimization pipeline just after the SLP vectorizer runs (which, admittedly, does not preserve SE, although I imagine it could). Regardless, I actually don't think that the preservation matters too much in this case: SE computes lazily, and this pass won't issue any SE queries unless there are any assume intrinsics, so there should be no real additional cost in the common case (SLP does preserve DT and LoopInfo). llvm-svn: 217344
* Reinstate "Nuke the old JIT."Eric Christopher2014-09-021-1/+0
| | | | | | | | Approved by Jim Grosbach, Lang Hames, Rafael Espindola. This reinstates commits r215111, 215115, 215116, 215117, 215136. llvm-svn: 216982
* Canonicalize header guards into a common format.Benjamin Kramer2014-08-133-6/+6
| | | | | | | | | | Add header guards to files that were missing guards. Remove #endif comments as they don't seem common in LLVM (we can easily add them back if we decide they're useful) Changes made by clang-tidy with minor tweaks. llvm-svn: 215558
* [LLVM-C] Expose User::getOperandUse as LLVMGetOperandUse.Peter Zotov2014-08-121-0/+7
| | | | | | Patch by Gabriel Radanne <drupyog@zoho.com> llvm-svn: 215419
* Temporarily Revert "Nuke the old JIT." as it's not quite ready toEric Christopher2014-08-071-0/+1
| | | | | | | | | | | be deleted. This will be reapplied as soon as possible and before the 3.6 branch date at any rate. Approved by Jim Grosbach, Lang Hames, Rafael Espindola. This reverts commits r215111, 215115, 215116, 215117, 215136. llvm-svn: 215154
* Fix the ocaml bindings.Rafael Espindola2014-08-071-1/+0
| | | | llvm-svn: 215117
* [LLVM-C] Add LLVM{IsConstantString,GetAsString,GetElementAsConstant}.Peter Zotov2014-08-031-0/+21
| | | | llvm-svn: 214676
* Remove lto_codegen_set_attr.Rafael Espindola2014-08-011-9/+1
| | | | | | It was never exported, so no functionality change. llvm-svn: 214519
* Add scoped-noalias metadataHal Finkel2014-07-241-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit adds scoped noalias metadata. The primary motivations for this feature are: 1. To preserve noalias function attribute information when inlining 2. To provide the ability to model block-scope C99 restrict pointers Neither of these two abilities are added here, only the necessary infrastructure. In fact, there should be no change to existing functionality, only the addition of new features. The logic that converts noalias function parameters into this metadata during inlining will come in a follow-up commit. What is added here is the ability to generally specify noalias memory-access sets. Regarding the metadata, alias-analysis scopes are defined similar to TBAA nodes: !scope0 = metadata !{ metadata !"scope of foo()" } !scope1 = metadata !{ metadata !"scope 1", metadata !scope0 } !scope2 = metadata !{ metadata !"scope 2", metadata !scope0 } !scope3 = metadata !{ metadata !"scope 2.1", metadata !scope2 } !scope4 = metadata !{ metadata !"scope 2.2", metadata !scope2 } Loads and stores can be tagged with an alias-analysis scope, and also, with a noalias tag for a specific scope: ... = load %ptr1, !alias.scope !{ !scope1 } ... = load %ptr2, !alias.scope !{ !scope1, !scope2 }, !noalias !{ !scope1 } When evaluating an aliasing query, if one of the instructions is associated with an alias.scope id that is identical to the noalias scope associated with the other instruction, or is a descendant (in the scope hierarchy) of the noalias scope associated with the other instruction, then the two memory accesses are assumed not to alias. Note that is the first element of the scope metadata is a string, then it can be combined accross functions and translation units. The string can be replaced by a self-reference to create globally unqiue scope identifiers. [Note: This overview is slightly stylized, since the metadata nodes really need to just be numbers (!0 instead of !scope0), and the scope lists are also global unnamed metadata.] Existing noalias metadata in a callee is "cloned" for use by the inlined code. This is necessary because the aliasing scopes are unique to each call site (because of possible control dependencies on the aliasing properties). For example, consider a function: foo(noalias a, noalias b) { *a = *b; } that gets inlined into bar() { ... if (...) foo(a1, b1); ... if (...) foo(a2, b2); } -- now just because we know that a1 does not alias with b1 at the first call site, and a2 does not alias with b2 at the second call site, we cannot let inlining these functons have the metadata imply that a1 does not alias with b2. llvm-svn: 213864
* MergedLoadStoreMotion passGerolf Hoflehner2014-07-181-0/+3
| | | | | | | | | | | Merges equivalent loads on both sides of a hammock/diamond and hoists into into the header. Merges equivalent stores on both sides of a hammock/diamond and sinks it to the footer. Can enable if conversion and tolerate better load misses and store operand latencies. llvm-svn: 213396
* 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
* [modules] The LLVM C API does not require C++!Richard Smith2014-06-121-1/+0
| | | | llvm-svn: 210842
* 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
* [modules] Add module maps for LLVM. These are not quite ready for prime-timeRichard Smith2014-05-211-0/+5
| | | | | | | yet, but only a few more Clang patches need to land. (I have 'ninja check' passing locally.) llvm-svn: 209269
* 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
* Move LTOModule and LTOCodeGenerator to the llvm namespace.Rafael Espindola2014-05-031-2/+2
| | | | llvm-svn: 207911
* Style update: don't duplicate comments, they were getting out of sync.Rafael Espindola2014-05-031-2/+3
| | | | llvm-svn: 207909
* [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
* Add an -mattr option to the gold plugin to support subtarget features in LTOTom Roeder2014-04-251-1/+9
| | | | | | | | | | This adds support for an -mattr option to the gold plugin and to llvm-lto. This allows the caller to specify details of the subtarget architecture, like +aes, or +ssse3 on x86. Note that this requires a change to the include/llvm-c/lto.h interface: it adds a function lto_codegen_set_attr and it increments the version of the interface. llvm-svn: 207279
* Convert getFileOffset to getOffset and move it to its only user.Rafael Espindola2014-04-211-1/+0
| | | | | | | | | | | | | We normally don't drop functions from the C API's, but in this case I think we can: * The old implementation of getFileOffset was fairly broken * The introduction of LLVMGetSymbolFileOffset was itself a C api breaking change as it removed LLVMGetSymbolOffset. * It is an incredibly specialized use case. The only reason MCJIT needs it is because of its odd position of being a dynamic linker of .o files. llvm-svn: 206750
* 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
* Teach llvm-lto to respect the given RelocModel.James Molloy2014-04-141-1/+2
| | | | | | Patch by Nick Tomlinson! llvm-svn: 206177
* The LLVM C API shouldn't be including a file from the C++ API. Especially not aRichard Smith2014-04-081-1/+0
| | | | | | file that it doesn't use. llvm-svn: 205755
* Revert "Reapply "LTO: add API to set strategy for -internalize""Duncan P. N. Exon Smith2014-04-021-19/+0
| | | | | | | | | | | This reverts commit r199244. Conflicts: include/llvm-c/lto.h include/llvm/LTO/LTOCodeGenerator.h lib/LTO/LTOCodeGenerator.cpp llvm-svn: 205471
* ARM64: initial backend importTim Northover2014-03-291-0/+21
| | | | | | | | | | | | This adds a second implementation of the AArch64 architecture to LLVM, accessible in parallel via the "arm64" triple. The plan over the coming weeks & months is to merge the two into a single backend, during which time thorough code review should naturally occur. Everything will be easier with the target in-tree though, hence this commit. llvm-svn: 205090
* 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-062-11/+21
| | | | | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud