summaryrefslogtreecommitdiffstats
path: root/llvm/include/llvm-c
Commit message (Collapse)AuthorAgeFilesLines
* [Coroutines] Rename "legacy" passes (NFC)Brian Gesiak2020-01-011-4/+4
| | | | | | | | | | | | | | | | | | A series of patches beginning with https://reviews.llvm.org/D71898 propose to add an implementation of the coroutine passes to the new pass manager. As part of these changes, the coroutine passes that implement the legacy pass manager interface are renamed, to `<PassName>Legacy`. This mirrors similar changes that have been made to many other passes in LLVM as they've been transitioned to support both old and new pass managers. This commit splits out the renaming portion of that patch and commits it in advance as an NFC (no functional change intended) commit. It renames: * `CoroEarly` => `CoroEarlyLegacy` * `CoroSplit` => `CoroSplitLegacy` * `CoroElide` => `CoroElideLegacy` * `CoroCleanup` => `CoroCleanupLegacy`
* Rename DW_AT_LLVM_isysroot to DW_AT_LLVM_sysrootAdrian Prantl2019-12-201-3/+3
| | | | | | | | | | | | This is a purely cosmetic change that is NFC in terms of the binary output. I bugs me that I called the attribute DW_AT_LLVM_isysroot since the "i" is an artifact of GCC command line option syntax (-isysroot is in the category of -i options) and doesn't carry any useful information otherwise. This attribute only appears in Clang module debug info. Differential Revision: https://reviews.llvm.org/D71722
* Recommit "[DWARF5]Addition of alignment atrribute in typedef DIE."Sourabh Singh Tomar2019-12-031-1/+1
| | | | | | | | | | | | | | | | This revision is revised to update Go-bindings and Release Notes. The original commit message follows. This patch, adds support for DW_AT_alignment[DWARF5] attribute, to be emitted with typdef DIE. When explicit alignment is specified. Patch by Awanish Pandey <Awanish.Pandey@amd.com> Reviewers: aprantl, dblaikie, jini.susan.george, SouraVX, alok, deadalinx Differential Revision: https://reviews.llvm.org/D70111
* [LTO][Legacy] Add API for passing LLVM options separatelyFrancis Visoiu Mistrih2019-11-191-1/+14
| | | | | | | | | | | | In order to correctly pass options to LLVM, including options containing spaces which are used as delimiters for multiple options in lto_codegen_debug_options, add a new API: lto_codegen_debug_options_array. Unfortunately, tools/lto has no testing infrastructure yet, so there are no tests associated with this patch. Differential Revision: https://reviews.llvm.org/D70463
* Wrap C APIs with pragmas enforcing -Werror=strict-prototypesDuncan P. N. Exon Smith2019-11-1931-178/+135
| | | | | | | | | Force `-Werror=strict-prototypes` so that C API tests fail to compile if we add a non-prototype declaration. This should help avoid regressions like bddecba4b333f7772029b4937d2c34f9f2fda6ca was fixing. https://reviews.llvm.org/D70285 rdar://problem/57203137
* Revert "[DWARF5]Addition of alignment atrribute in typedef DIE."Sam McCall2019-11-181-1/+1
| | | | | This reverts commit 423f541c1a322963cf482683fe9777ef0692082d, which breaks llvm-c ABI.
* [DWARF5]Addition of alignment atrribute in typedef DIE.Sourabh Singh Tomar2019-11-161-1/+1
| | | | | | | | | | | | This patch, adds support for DW_AT_alignment[DWARF5] attribute, to be emitted with typdef DIE. When explicit alignment is specified. Patch by Awanish Pandey <Awanish.Pandey@amd.com> Reviewers: aprantl, dblaikie, jini.susan.george, SouraVX, alok, deadalinx Differential Revision: https://reviews.llvm.org/D70111
* [IR] Redefine Freeze instructionaqjune2019-11-121-2/+4
| | | | | | | | | | | | | | | | | | | | Summary: This patch redefines freeze instruction from being UnaryOperator to a subclass of UnaryInstruction. ConstantExpr freeze is removed, as discussed in the previous review. FreezeOperator is not added because there's no ConstantExpr freeze. `freeze i8* null` test is added to `test/Bindings/llvm-c/freeze.ll` as well, because the null pointer-related bug in `tools/llvm-c/echo.cpp` is now fixed. InstVisitor has visitFreeze now because freeze is not unaryop anymore. Reviewers: whitequark, deadalnix, craig.topper, jdoerfert, lebedev.ri Reviewed By: craig.topper, lebedev.ri Subscribers: regehr, nlopes, mehdi_amini, hiraditya, steven_wu, dexonsmith, jfb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69932
* [IR] Add Freeze instructionaqjune2019-11-051-0/+2
| | | | | | | | | | | | | | | | | | Summary: - Define Instruction::Freeze, let it be UnaryOperator - Add support for freeze to LLLexer/LLParser/BitcodeReader/BitcodeWriter The format is `%x = freeze <ty> %v` - Add support for freeze instruction to llvm-c interface. - Add m_Freeze in PatternMatch. - Erase freeze when lowering IR to SelDag. Reviewers: deadalnix, hfinkel, efriedma, lebedev.ri, nlopes, jdoerfert, regehr, filcab, delcypher, whitequark Reviewed By: lebedev.ri, jdoerfert Subscribers: jfb, kristof.beyls, hiraditya, lebedev.ri, steven_wu, dexonsmith, xbolva00, delcypher, spatel, regehr, trentxintong, vsk, filcab, nlopes, mehdi_amini, deadalnix, llvm-commits Differential Revision: https://reviews.llvm.org/D29011
* Reapply r374743 with a fix for the ocaml bindingJoerg Sonnenberger2019-10-141-0/+3
| | | | | | | | | | | | | | | | | | | Add a pass to lower is.constant and objectsize intrinsics This pass lowers is.constant and objectsize intrinsics not simplified by earlier constant folding, i.e. if the object given is not constant or if not using the optimized pass chain. The result is recursively simplified and constant conditionals are pruned, so that dead blocks are removed even for -O0. This allows inline asm blocks with operand constraints to work all the time. The new pass replaces the existing lowering in the codegen-prepare pass and fallbacks in SDAG/GlobalISEL and FastISel. The latter now assert on the intrinsics. Differential Revision: https://reviews.llvm.org/D65280 llvm-svn: 374784
* Revert "Add a pass to lower is.constant and objectsize intrinsics"Dmitri Gribenko2019-10-141-3/+0
| | | | | | | This reverts commit r374743. It broke the build with Ocaml enabled: http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/19218 llvm-svn: 374768
* Add a pass to lower is.constant and objectsize intrinsicsJoerg Sonnenberger2019-10-131-0/+3
| | | | | | | | | | | | | | | | | This pass lowers is.constant and objectsize intrinsics not simplified by earlier constant folding, i.e. if the object given is not constant or if not using the optimized pass chain. The result is recursively simplified and constant conditionals are pruned, so that dead blocks are removed even for -O0. This allows inline asm blocks with operand constraints to work all the time. The new pass replaces the existing lowering in the codegen-prepare pass and fallbacks in SDAG/GlobalISEL and FastISel. The latter now assert on the intrinsics. Differential Revision: https://reviews.llvm.org/D65280 llvm-svn: 374743
* Fix Wdocumentation unknown parameter warning. NFCI.Simon Pilgrim2019-10-091-1/+1
| | | | llvm-svn: 374171
* [llvm-c] Add UnaryOperator to LLVM_FOR_EACH_VALUE_SUBCLASS macroCameron McInally2019-10-071-0/+1
| | | | | | | | Note that we are not sure where the tests for these functions lives. This was discussed in the Phab Diff. Differential Revision: https://reviews.llvm.org/D68588 llvm-svn: 373969
* [LLVM-C] Add bindings to create macro debug infowhitequark2019-10-071-0/+45
| | | | | | | | | | | | | | | | Summary: The C API doesn't have the bindings to create macro debug information. Reviewers: whitequark, CodaFi, deadalnix Reviewed By: whitequark Subscribers: aprantl, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D58334 llvm-svn: 373903
* [LLVM-C][Ocaml] Add MergeFunctions and DCE passAditya Kumar2019-09-292-0/+6
| | | | | | | | | | | | | | | | | | | MergeFunctions and DCE pass are missing from OCaml/C-api. This patch adds them. Differential Revision: https://reviews.llvm.org/D65071 Reviewers: whitequark, hiraditya, deadalnix Reviewed By: whitequark Subscribers: llvm-commits Tags: #llvm Authored by: kren1 llvm-svn: 373170
* Improve C API support for atomicrmw and cmpxchg.Nick Lewycky2019-09-261-4/+17
| | | | | | | | | | | | | | atomicrmw and cmpxchg have a volatile flag, so allow them to be get and set with LLVM{Get,Set}Volatile. atomicrmw and fence have orderings, so allow them to be get and set with LLVM{Get,Set}Ordering. Add missing LLVMAtomicRMWBinOpFAdd and LLVMAtomicRMWBinOpFSub enum constants. AtomicCmpXchg also has a weak flag, add a getter/setter for that too. Add a getter/setter for the binary-op of an atomicrmw. atomicrmw and cmpxchg have a volatile flag, so allow it to be set/get with LLVMGetVolatile and LLVMSetVolatile. Add missing LLVMAtomicRMWBinOpFAdd and LLVMAtomicRMWBinOpFSub enum constants. AtomicCmpXchg also has a weak flag, add a getter/setter for that too. Add a getter/setter for the binary-op of an atomicrmw. Add LLVMIsA## for CatchSwitchInst, CallBrInst and FenceInst, as well as AtomicCmpXchgInst and AtomicRMWInst. Update llvm-c-test to include atomicrmw and fence, and to copy volatile for the four applicable instructions. Differential Revision: https://reviews.llvm.org/D67132 llvm-svn: 372938
* Remove the obsolete BlockByRefStruct flag from LLVM IRAdrian Prantl2019-09-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | DIFlagBlockByRefStruct is an unused DIFlag that originally was used by clang to express (Objective-)C block captures in debug info. For the last year Clang has been emitting complex DIExpressions to describe block captures instead, which makes all the code supporting this flag redundant. This patch removes the flag and all supporting "dead" code, so we can reuse the bit for something else in the future. Since this only affects debug info generated by Clang with the block extension this mostly affects Apple platforms and I don't have any bitcode compatibility concerns for removing this. The Verifier will reject debug info that uses the bit and thus degrade gracefully when LTO'ing older bitcode with a newer compiler. rdar://problem/44304813 Differential Revision: https://reviews.llvm.org/D67453 llvm-svn: 372272
* [LTO][Legacy] Add new C inferface to query libcall functionsSteven Wu2019-09-161-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is needed to implemented the same approach as lld (implemented in r338434) for how to handling symbols that can be generated by LTO code generator but not present in the symbol table for linker that uses legacy C APIs. libLTO is in charge of providing the list of symbols. Linker is in charge of implementing the eager loading from static libraries using the list of symbols. rdar://problem/52853974 Reviewers: tejohnson, bd1976llvm, deadalnix, espindola Reviewed By: tejohnson Subscribers: emaste, arichardson, hiraditya, MaskRay, dang, kledzik, mehdi_amini, inglorion, jkorous, dexonsmith, ributzka, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67568 llvm-svn: 372021
* [NFC][libLTO] Rearrange declaration in lto.hSteven Wu2019-09-131-42/+42
| | | | | | | | | | | | | | | | | | Summary: Rearrange the function declaration in lto.h so they falls in the correct doxygen group. Reviewers: tejohnson, bd1976llvm, deadalnix Reviewed By: tejohnson Subscribers: mehdi_amini, inglorion, jkorous, dexonsmith, ributzka, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67565 llvm-svn: 371900
* [Remarks] Add parser for bitstream remarksFrancis Visoiu Mistrih2019-09-091-1/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | The bitstream remark serializer landed in r367372. This adds a bitstream remark parser that parser bitstream remark files to llvm::remarks::Remark objects through the RemarkParser interface. A few interesting things to point out: * There are parsing helpers to parse the different types of blocks * The main parsing helper allows us to parse remark metadata and open an external file containing the encoded remarks * This adds a dependency from the Remarks library to the BitstreamReader library * The testing strategy is to create a remark entry through YAML, parse it, serialize it to bitstream, parse that back and compare the objects. * There are close to no tests for malformed bitstream remarks, due to the lack of textual format for the bitstream format. * This adds a new C API for parsing bitstream remarks: LLVMRemarkParserCreateBitstream. * This bumps the REMARKS_API_VERSION to 1. Differential Revision: https://reviews.llvm.org/D67134 llvm-svn: 371429
* Revert "Expose TailCallKind via the LLVM C API"Jonas Devlieghere2019-08-151-25/+0
| | | | | | | This is failing on several build bots. Reverting as discussed in https://reviews.llvm.org/D66061. llvm-svn: 368953
* Expose TailCallKind via the LLVM C APIRobert Widmann2019-08-141-0/+25
| | | | | | | | | | | | | | | | Summary: This exposes `CallInst`'s tail call kind via new `LLVMGetTailCallKind` and `LLVMSetTailCallKind` functions. The motivation for this is to be able to see `musttail` for languages that require mandatory tail calls for correctness. Today only the weaker `LLVMSetTail` is exposed and there is no way to set `GuaranteedTailCallOpt` via the C API. Reviewers: CodaFi, jyknight, deadalnix, rnk Reviewed By: CodaFi Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66061 llvm-svn: 368945
* [LLVM-C] Improve Bindings to The Internalize PassRobert Widmann2019-07-231-0/+15
| | | | | | | | | | | | | | | | Summary: Adds a binding to the internalize pass that allows the caller to pass a function pointer that acts as the visibility-preservation predicate. Previously, one could only pass an unsigned value (not LLVMBool?) that directed the pass to consider "main" or not. Reviewers: whitequark, deadalnix, harlanhaskins Reviewed By: whitequark, harlanhaskins Subscribers: kren1, hiraditya, llvm-commits, harlanhaskins Tags: #llvm Differential Revision: https://reviews.llvm.org/D62456 llvm-svn: 366777
* [Remarks] Simplify and refactor the RemarkParser interfaceFrancis Visoiu Mistrih2019-07-161-4/+19
| | | | | | | | | | | | | | | | | | | | Before, everything was based on some kind of type erased parser implementation which container a lot of boilerplate code when multiple formats were to be supported. This simplifies it by: * the remark now owns its arguments * *always* returning an error from the implementation side * working around the way the YAML parser reports errors: catch them through callbacks and re-insert them in a proper llvm::Error * add a CParser wrapper that is used when implementing the C API to avoid cluttering the C++ API with useless state * LLVMRemarkParserGetNext now returns an object that needs to be released to avoid leaking resources * add a new API to dispose of a remark entry: LLVMRemarkEntryDispose llvm-svn: 366217
* [ThinLTO]LTO]Legacy] Fix dependent libraries support by adding querying of ↵Ben Dunbobbin2019-06-121-9/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | the IRSymtab Dependent libraries support for the legacy api was committed in a broken state (see: https://reviews.llvm.org/D60274). This was missed due to the painful nature of having to integrate the changes into a linker in order to test. This change implements support for dependent libraries in the legacy LTO api: - I have removed the current api function, which returns a single string, and added functions to access each dependent library specifier individually. - To reduce the testing pain, I have made the api functions as thin as possible to maximize coverage from llvm-lto. - When doing ThinLTO the system linker will load the modules lazily when scanning the input files. Unfortunately, when modules are lazily loaded there is no access to module level named metadata. To fix this I have added api functions that allow querying the IRSymtab for the dependent libraries. I hope to expand the api in the future so that, eventually, all the information needed by a client linker during scan can be retrieved from the IRSymtab. Differential Revision: https://reviews.llvm.org/D62935 llvm-svn: 363140
* [LLVM-C] Add Accessor for Mach-O Universal Binary SlicesRobert Widmann2019-05-251-0/+16
| | | | | | | | | | | | | | | | Summary: Allow for retrieving an object file corresponding to an architecture-specific slice in a Mach-O universal binary file. Reviewers: whitequark, deadalnix Reviewed By: whitequark Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60378 llvm-svn: 361705
* [ELF] Implement Dependent Libraries FeatureBen Dunbobbin2019-05-171-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements a limited form of autolinking primarily designed to allow either the --dependent-library compiler option, or "comment lib" pragmas ( https://docs.microsoft.com/en-us/cpp/preprocessor/comment-c-cpp?view=vs-2017) in C/C++ e.g. #pragma comment(lib, "foo"), to cause an ELF linker to automatically add the specified library to the link when processing the input file generated by the compiler. Currently this extension is unique to LLVM and LLD. However, care has been taken to design this feature so that it could be supported by other ELF linkers. The design goals were to provide: - A simple linking model for developers to reason about. - The ability to to override autolinking from the linker command line. - Source code compatibility, where possible, with "comment lib" pragmas in other environments (MSVC in particular). Dependent library support is implemented differently for ELF platforms than on the other platforms. Primarily this difference is that on ELF we pass the dependent library specifiers directly to the linker without manipulating them. This is in contrast to other platforms where they are mapped to a specific linker option by the compiler. This difference is a result of the greater variety of ELF linkers and the fact that ELF linkers tend to handle libraries in a more complicated fashion than on other platforms. This forces us to defer handling the specifiers to the linker. In order to achieve a level of source code compatibility with other platforms we have restricted this feature to work with libraries that meet the following "reasonable" requirements: 1. There are no competing defined symbols in a given set of libraries, or if they exist, the program owner doesn't care which is linked to their program. 2. There may be circular dependencies between libraries. The binary representation is a mergeable string section (SHF_MERGE, SHF_STRINGS), called .deplibs, with custom type SHT_LLVM_DEPENDENT_LIBRARIES (0x6fff4c04). The compiler forms this section by concatenating the arguments of the "comment lib" pragmas and --dependent-library options in the order they are encountered. Partial (-r, -Ur) links are handled by concatenating .deplibs sections with the normal mergeable string section rules. As an example, #pragma comment(lib, "foo") would result in: .section ".deplibs","MS",@llvm_dependent_libraries,1 .asciz "foo" For LTO, equivalent information to the contents of a the .deplibs section can be retrieved by the LLD for bitcode input files. LLD processes the dependent library specifiers in the following way: 1. Dependent libraries which are found from the specifiers in .deplibs sections of relocatable object files are added when the linker decides to include that file (which could itself be in a library) in the link. Dependent libraries behave as if they were appended to the command line after all other options. As a consequence the set of dependent libraries are searched last to resolve symbols. 2. It is an error if a file cannot be found for a given specifier. 3. Any command line options in effect at the end of the command line parsing apply to the dependent libraries, e.g. --whole-archive. 4. The linker tries to add a library or relocatable object file from each of the strings in a .deplibs section by; first, handling the string as if it was specified on the command line; second, by looking for the string in each of the library search paths in turn; third, by looking for a lib<string>.a or lib<string>.so (depending on the current mode of the linker) in each of the library search paths. 5. A new command line option --no-dependent-libraries tells LLD to ignore the dependent libraries. Rationale for the above points: 1. Adding the dependent libraries last makes the process simple to understand from a developers perspective. All linkers are able to implement this scheme. 2. Error-ing for libraries that are not found seems like better behavior than failing the link during symbol resolution. 3. It seems useful for the user to be able to apply command line options which will affect all of the dependent libraries. There is a potential problem of surprise for developers, who might not realize that these options would apply to these "invisible" input files; however, despite the potential for surprise, this is easy for developers to reason about and gives developers the control that they may require. 4. This algorithm takes into account all of the different ways that ELF linkers find input files. The different search methods are tried by the linker in most obvious to least obvious order. 5. I considered adding finer grained control over which dependent libraries were ignored (e.g. MSVC has /nodefaultlib:<library>); however, I concluded that this is not necessary: if finer control is required developers can fall back to using the command line directly. RFC thread: http://lists.llvm.org/pipermail/llvm-dev/2019-March/131004.html. Differential Revision: https://reviews.llvm.org/D60274 llvm-svn: 360984
* [llvm-c] Make LLVMGetStringErrorTypeId a proper prototypeAnders Waldenborg2019-05-061-1/+1
| | | | | | | | | | | | In C a function declaration with an empty argument list isn't a real prototype, it will allow calling the function with any number of arguments. It will also cause warnings when used in C code compiled with '-Wstrict-prototypes' Reviewed By: whitequark Differential Revision: https://reviews.llvm.org/D61568 llvm-svn: 360012
* [LLVM-C] Deprecate the LLVMValueRef-returning metadata creation functionsRobert Widmann2019-04-241-21/+21
| | | | | | | | | | | | | | | | Summary: There is still some value in using these functions while the remaining LLVMValueRef-based accessors are still around, but LLVMMDNodeInContext in particular has some wonky semantics that make it worth replacing outright. Reviewers: whitequark, deadalnix Reviewed By: whitequark Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60524 llvm-svn: 359114
* [LLVM-C] Add accessors to the default floating-point metadata nodeRobert Widmann2019-04-221-1/+18
| | | | | | | | | | | | | | | | Summary: Add a getter and setter pair for floating-point accuracy metadata. Reviewers: whitequark, deadalnix Reviewed By: whitequark Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60527 llvm-svn: 358883
* [LLVM-C] Add DIFile Field AccesssorsRobert Widmann2019-04-171-0/+34
| | | | | | | | | | | | | | | | | | | Summary: Add accessors for the file, directory, source file name (curiously, an `Optional` value?), of a DIFile. This is intended to replace the LLVMValueRef-based accessors used in D52239 Reviewers: whitequark, jberdine, deadalnix Reviewed By: whitequark, jberdine Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60489 llvm-svn: 358577
* [LLVM-C] Add Accessors For Global Variable Metadata PropertiesRobert Widmann2019-04-161-0/+50
| | | | | | | | | | | | | | | | Summary: Metadata for a global variable is really a (GlobalVariable, Expression) tuple. Allow access to these, then allow retrieving the file, scope, and line for a DIVariable, whether global or local. This should be the last of the accessors required for uniform access to location and file information metadata. Reviewers: jberdine, whitequark, deadalnix Reviewed By: jberdine, whitequark Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60725 llvm-svn: 358532
* [DebugInfo] Combine Trivial and NonTrivial flagsAaron Smith2019-04-111-1/+1
| | | | | | | | | | | | | | | | Summary: Companion to https://reviews.llvm.org/D59347 Reviewers: rnk, zturner, probinson, dblaikie, deadalnix Subscribers: aprantl, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59348 llvm-svn: 358220
* Fix a typoAlexander Kornienko2019-04-101-2/+2
| | | | llvm-svn: 358092
* [LLVM-C] Correct The Current Debug Location Accessors (Again)Robert Widmann2019-04-102-1/+43
| | | | | | | | | | | | | | Summary: Resubmitting D60484 with the conflicting Go bindings renamed to avoid collisions. Reviewers: whitequark, deadalnix Subscribers: hiraditya, llvm-commits, sammccall Tags: #llvm Differential Revision: https://reviews.llvm.org/D60511 llvm-svn: 358086
* Revert "[LLVM-C] Correct The Current Debug Location Accessors"Sam McCall2019-04-101-34/+1
| | | | | | | This reverts commit r358039, which added symbols that conflict with the Go bindings. llvm-svn: 358082
* [LLVM-C] Correct The Current Debug Location AccessorsRobert Widmann2019-04-091-1/+34
| | | | | | | | | | | | | | | | Summary: Deprecate the existing accessors for the "current debug location" of an IRBuilder. The setter could not handle being reset to NULL, and the getter would create bogus metadata if the NULL location was returned. Provide direct metadata-based accessors instead. Reviewers: whitequark, deadalnix Reviewed By: whitequark Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60484 llvm-svn: 358039
* [LLVM-C] Add Bindings to Access an Instruction's DebugLocRobert Widmann2019-04-091-0/+16
| | | | | | | | | | | | | | | | Summary: Provide direct accessors to supplement LLVMSetInstDebugLocation. In addition, properly accept and return the NULL location. The old accessors provided no way to do this, so the current debug location cannot currently be cleared. Reviewers: whitequark, deadalnix Reviewed By: whitequark Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60481 llvm-svn: 358038
* [LLVM-C] Add Section and Symbol Iterator Accessors for Object File BinariesRobert Widmann2019-04-091-11/+63
| | | | | | | | | | | | | | | | Summary: This brings us to full feature parity with the old API, so I've deprecated it and updated the tests. I'll do a follow-up patch to do some more cleanup and documentation work in this header. Reviewers: whitequark, deadalnix Reviewed By: whitequark Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60407 llvm-svn: 358037
* Add LLVM IR debug info support for Fortran COMMON blocksAdrian Prantl2019-04-081-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | COMMON blocks are a feature of Fortran that has no direct analog in C languages, but they are similar to data sections in assembly language programming. A COMMON block is a named area of memory that holds a collection of variables. Fortran subprograms may map the COMMON block memory area to their own, possibly distinct, non-empty list of variables. A Fortran COMMON block might look like the following example. COMMON /ALPHA/ I, J For this construct, the compiler generates a new scope-like DI construct (!DICommonBlock) into which variables (see I, J above) can be placed. As the common block implies a range of storage with global lifetime, the !DICommonBlock refers to a !DIGlobalVariable. The Fortran variable that comprise the COMMON block are also linked via metadata to offsets within the global variable that stands for the entire common block. @alpha_ = common global %alphabytes_ zeroinitializer, align 64, !dbg !27, !dbg !30, !dbg !33 !14 = distinct !DISubprogram(…) !20 = distinct !DICommonBlock(scope: !14, declaration: !25, name: "alpha") !25 = distinct !DIGlobalVariable(scope: !20, name: "common alpha", type: !24) !27 = !DIGlobalVariableExpression(var: !25, expr: !DIExpression()) !29 = distinct !DIGlobalVariable(scope: !20, name: "i", file: !3, type: !28) !30 = !DIGlobalVariableExpression(var: !29, expr: !DIExpression()) !31 = distinct !DIGlobalVariable(scope: !20, name: "j", file: !3, type: !28) !32 = !DIExpression(DW_OP_plus_uconst, 4) !33 = !DIGlobalVariableExpression(var: !31, expr: !32) The DWARF generated for this is as follows. DW_TAG_common_block: DW_AT_name: alpha DW_AT_location: @alpha_+0 DW_TAG_variable: DW_AT_name: common alpha DW_AT_type: array of 8 bytes DW_AT_location: @alpha_+0 DW_TAG_variable: DW_AT_name: i DW_AT_type: integer*4 DW_AT_location: @Alpha+0 DW_TAG_variable: DW_AT_name: j DW_AT_type: integer*4 DW_AT_location: @Alpha+4 Patch by Eric Schweitz! Differential Revision: https://reviews.llvm.org/D54327 llvm-svn: 357934
* [LLVM-C] Allow Access to the Type of a BinaryRobert Widmann2019-04-071-0/+26
| | | | | | | | | | | | | | | | Summary: Add an accessor for the type of a binary file. Reviewers: whitequark, deadalnix Reviewed By: whitequark Subscribers: hiraditya, aheejin, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60366 llvm-svn: 357872
* [LLVM-C] Begin to Expose A More General Binary InterfaceRobert Widmann2019-04-052-0/+44
| | | | | | | | | | | | | | | | | | | | | Summary: Provides a new type, `LLVMBinaryRef`, and a binding to `llvm::object::createBinary` for more general interoperation with binary files than `LLVMObjectFileRef`. It also provides the proper non-consuming API for input buffers and populates an out parameter for error handling if necessary - two things the previous API did not do. In a follow-up, I'll define section and symbol iterators and begin to build upon the existing test infrastructure. This patch is a first step towards deprecating that API and replacing it with something more robust. Reviewers: deadalnix, whitequark Reviewed By: whitequark Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60322 llvm-svn: 357822
* [LLVM-C] Add bindings to insert basic blocksRobert Widmann2019-04-051-0/+18
| | | | | | | | | | | | | | | | | | | | Summary: Now that we can create standalone basic blocks, it's useful to be able to append them. Add bindings to - Insert a basic block after the current insertion block - Append a basic block to the end of a function's list of basic blocks Reviewers: whitequark, deadalnix, harlanhaskins Reviewed By: whitequark, harlanhaskins Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59658 llvm-svn: 357812
* [Remarks][NFCI] Remove useless includeFrancis Visoiu Mistrih2019-04-021-1/+0
| | | | | | | Remarks.h only uses LLVMBool, which comes from llvm-c/Types.h. Nothing from llvm-c/Core.h is used. llvm-svn: 357503
* [LLVM-C] Add binding to look up intrinsic by nameRobert Widmann2019-03-251-0/+7
| | | | | | | | | | | | | | | | Summary: Add a binding to Function::lookupIntrinsicID so clients don't have to go searching the ID table themselves. Reviewers: whitequark, deadalnix Reviewed By: whitequark Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59697 llvm-svn: 356948
* Remove MSVC compat hack since the inline keyword was added in 2015Reid Kleckner2019-03-191-4/+0
| | | | | | | | | | | Our minimum MSVC toolchain requirement is greater than 2015, so we don't need this conditional macro anymore. New versions of MSVC apparently have a header, xkeycheck.h, to check that keywords haven't been redefined. Fixes PR41144 llvm-svn: 356524
* Reland "[Remarks] Add a new Remark / RemarkParser abstraction"Francis Visoiu Mistrih2019-03-191-55/+168
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a Remark class that allows us to share code when working with remarks. The C API has been updated to reflect this. Instead of the parser generating C structs, it's now using a C++ object that is used through opaque pointers in C. This gives us much more flexibility on what changes we can make to the internal state of the object and interacts much better with scenarios where the library is used through dlopen. * C API updates: * move from C structs to opaque pointers and functions * the remark type is now an enum instead of a string * unit tests updates: * use mostly the C++ API * keep one test for the C API * rename to YAMLRemarksParsingTest * a typo was fixed: AnalysisFPCompute -> AnalysisFPCommute. * a new error message was added: "expected a remark tag." * llvm-opt-report has been updated to use the C++ parser instead of the C API Differential Revision: https://reviews.llvm.org/D59049 Original llvm-svn: 356491 llvm-svn: 356519
* Revert "[Remarks] Add a new Remark / RemarkParser abstraction"Francis Visoiu Mistrih2019-03-191-168/+55
| | | | | | | | | This reverts commit 51dc6a8c84cd6a58562e320e1828a0158dbbf750. Breaks http://lab.llvm.org:8011/builders/clang-cmake-x86_64-sde-avx512-linux/builds/20034/steps/build%20stage%201/logs/stdio. llvm-svn: 356492
* [Remarks] Add a new Remark / RemarkParser abstractionFrancis Visoiu Mistrih2019-03-191-55/+168
| | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a Remark class that allows us to share code when working with remarks. The C API has been updated to reflect this. Instead of the parser generating C structs, it's now using a C++ object that is used through opaque pointers in C. This gives us much more flexibility on what changes we can make to the internal state of the object and interacts much better with scenarios where the library is used through dlopen. * C API updates: * move from C structs to opaque pointers and functions * the remark type is now an enum instead of a string * unit tests updates: * use mostly the C++ API * keep one test for the C API * rename to YAMLRemarksParsingTest * a typo was fixed: AnalysisFPCompute -> AnalysisFPCommute. * a new error message was added: "expected a remark tag." * llvm-opt-report has been updated to use the C++ parser instead of the C API Differential Revision: https://reviews.llvm.org/D59049 llvm-svn: 356491
OpenPOWER on IntegriCloud