summaryrefslogtreecommitdiffstats
path: root/llvm/include/llvm-c
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* C API: Add functions to get or set a GlobalValue's DLLStorageClassReid Kleckner2014-03-051-0/+8
| | | | | | Patch by Manuel Jacob! llvm-svn: 202928
* Add 'remark' diagnostic type in LLVMTobias Grosser2014-02-281-4/+5
| | | | | | | | | | | | A 'remark' is information that is not an error or a warning, but rather some additional information provided to the user. In contrast to a 'note' a 'remark' is an independent diagnostic, whereas a 'note' always depends on another diagnostic. A typical use case for remark nodes is information provided to the user, e.g. information provided by the vectorizer about loops that have been vectorized. llvm-svn: 202474
* LTO API: add lto_module_create_from_memory_with_path.Manman Ren2014-02-101-1/+11
| | | | | | | | | | | | | This function adds an extra path argument to lto_module_create_from_memory. The path argument will be passed to makeBuffer to make sure the MemoryBuffer has a name and the created module has a module identifier. This is mainly for emitting warning messages from the linker. When we emit warning message on a module, we can use the module identifier. rdar://15985737 llvm-svn: 201114
* Fix known typosAlp Toker2014-01-241-1/+1
| | | | | | | Sweep the codebase for common typos. Includes some changes to visible function names that were misspelt. llvm-svn: 200018
* Add target analysis passes to the codegen pipeline for MCJIT.Juergen Ributzka2014-01-232-0/+5
| | | | | | | | | | | This patch adds the target analysis passes (usually TargetTransformInfo) to the codgen pipeline. We also expose now the AddAnalysisPasses method through the C API, because the optimizer passes would also benefit from better target-specific cost models. Reviewed by Andrew Kaylor llvm-svn: 199926
* Adding new LTO APIs to parse metadata nodes and extract linker options andYunzhong Gao2014-01-211-1/+38
| | | | | | | | dependent libraries from a bitcode module. Differential Revision: http://llvm-reviews.chandlerc.com/D2343 llvm-svn: 199759
* LTO: document LTO_API_VERSION for each APIDuncan P. N. Exon Smith2014-01-161-7/+80
| | | | | | | | | | | | | | Adding a doxygen comment for each bit of API to indicate at which LTO_API_VERSION each was available, manually gleaned from successive git-blames. A few notes: - LTO_API_VERSION was set to 3 at its introduction. - I've indicated all the API introduced before LTO_API_VERSION was around as available "prior to LTO_API_VERSION=3". - A number of API changes neglected to bump LTO_API_VERSION. These I've indicated as available at the *next* bump of LTO_API_VERSION. llvm-svn: 199429
* [LTO] Add a hook to map LLVM diagnostics into the clients of LTO.Quentin Colombet2014-01-151-1/+28
| | | | | | | | | | | | | | | | | | | Add a hook in the C API of LTO so that clients of the code generator can set their own handler for the LLVM diagnostics. The handler is defined like this: typedef void (*lto_diagnostic_handler_t)(lto_codegen_diagnostic_severity_t severity, const char *diag, void *ctxt) - severity says how bad this is. - diag is a string that contains the diagnostic message. - ctxt is the registered context for this handler. This hook is more general than the lto_get_error_message, since this function keeps only the latest message and can only be queried when something went wrong (no warning for instance). <rdar://problem/15517596> llvm-svn: 199338
* Reapply "LTO: add API to set strategy for -internalize"Duncan P. N. Exon Smith2014-01-141-1/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reapply r199191, reverted in r199197 because it carelessly broke Other/link-opts.ll. The problem was that calling createInternalizePass("main") would select createInternalizePass(bool("main")) instead of createInternalizePass(ArrayRef<const char *>("main")). This commit fixes the bug. The original commit message follows. Add API to LTOCodeGenerator to specify a strategy for the -internalize pass. This is a new attempt at Bill's change in r185882, which he reverted in r188029 due to problems with the gold linker. This puts the onus on the linker to decide whether (and what) to internalize. In particular, running internalize before outputting an object file may change a 'weak' symbol into an internal one, even though that symbol could be needed by an external object file --- e.g., with arclite. This patch enables three strategies: - LTO_INTERNALIZE_FULL: the default (and the old behaviour). - LTO_INTERNALIZE_NONE: skip -internalize. - LTO_INTERNALIZE_HIDDEN: only -internalize symbols with hidden visibility. LTO_INTERNALIZE_FULL should be used when linking an executable. Outputting an object file (e.g., via ld -r) is more complicated, and depends on whether hidden symbols should be internalized. E.g., for ld -r, LTO_INTERNALIZE_NONE can be used when -keep_private_externs, and LTO_INTERNALIZE_HIDDEN can be used otherwise. However, LTO_INTERNALIZE_FULL is inappropriate, since the output object file will eventually need to link with others. lto_codegen_set_internalize_strategy() sets the strategy for subsequent calls to lto_codegen_write_merged_modules() and lto_codegen_compile*(). <rdar://problem/14334895> llvm-svn: 199244
OpenPOWER on IntegriCloud