aboutsummaryrefslogtreecommitdiff
path: root/llvm/tools/llvm-c-test/echo.cpp
AgeCommit message (Collapse)AuthorFilesLines
2025-06-22[C API] Add getter/setter for samesign flag on icmp (#145247)Benji Smith1-0/+2
This was added to the C++ API in https://github.com/llvm/llvm-project/pull/111419 so this change adds accessors in the C API, along with a couple tests.
2025-04-25[llvm-c] Add `LLVMConstDataArray` and `LLVMGetRawDataValues` (#129440)Quinton Miller1-5/+12
Resolves #129439. The addition to `echo.ll` is for testing `ConstantArray`, because every other array in that file is in fact a `ConstantDataArray` and now takes the new code path in `echo.cpp`.
2024-08-20[LLVM] Add a C API for creating instructions with custom syncscopes. (#104775)Tim Besard1-13/+13
Another upstreaming of C API extensions we have in Julia/LLVM.jl. Although [we went](https://github.com/maleadt/LLVM.jl/pull/431) with a string-based API there, here I'm proposing something that's similar to existing metadata/attribute APIs: - explicit functions to map syncscope names to IDs, and back - `LLVM*SyncScope` versions of builder APIs that already take a `SingleThread` argument: atomic rmw, atomic xchg, fence - `LLVMGetAtomicSyncScopeID` and `LLVMSetAtomicSyncScopeID` for other atomic instructions - testing through `llvm-c-test`'s `--echo` functionality
2024-07-25Remove the `x86_mmx` IR type. (#98505)James Y Knight1-2/+0
It is now translated to `<1 x i64>`, which allows the removal of a bunch of special casing. This _incompatibly_ changes the ABI of any LLVM IR function with `x86_mmx` arguments or returns: instead of passing in mmx registers, they will now be passed via integer registers. However, the real-world incompatibility caused by this is expected to be minimal, because Clang never uses the x86_mmx type -- it lowers `__m64` to either `<1 x i64>` or `double`, depending on ABI. This change does _not_ eliminate the SelectionDAG `MVT::x86mmx` type. That type simply no longer corresponds to an IR type, and is used only by MMX intrinsics and inline-asm operands. Because SelectionDAGBuilder only knows how to generate the operands/results of intrinsics based on the IR type, it thus now generates the intrinsics with the type MVT::v1i64, instead of MVT::x86mmx. We need to fix this before the DAG LegalizeTypes, and thus have the X86 backend fix them up in DAGCombine. (This may be a short-lived hack, if all the MMX intrinsics can be removed in upcoming changes.) Works towards issue #98272.
2024-07-17[C API] Support new ptrauth constant type (#93909)Benji Smith1-0/+10
This is a new constant type that was added to the C++ API in 0edc97f119f3ac3ff96b11183fe5c001a48a9a8d. This adds the ability to create instances of this constant and get its values to the C API.
2024-07-16[C API] Add accessors for new no-wrap flags on GEP instructions (#97970)Benji Smith1-9/+7
Previously, only the inbounds flag was accessible via the C API. This adds support for any no-wrap related flags (currently nuw and nusw).
2024-06-26[C API] Add getters for Target Extension Types to C API (#96447)Benji Smith1-2/+20
Accessors for the name, type parameters, and integer parameters are added. A test is added to echo.ll This was originally done in https://github.com/llvm/llvm-project/pull/71291 but that has been stale for several months. This re-applies the changes, but with some tweaks. e.g. removing the bulk getters in favour of a simple get-by-index approach for the type/integer parameters. The latter is more in line with the rest of the API
2024-05-08[C API] Add getters and build function for CallBr (#91154)Benji Smith1-0/+40
This adds LLVMBuildCallBr to create CallBr instructions, and getters for the CallBr-specific data. The remainder of its data, e.g. arguments/function, can be accessed using existing getters.
2024-03-18[C API] Add accessors for function prefix and prologue data (#82193)Benji Smith1-0/+8
A test is added to echo.ll, and the echo.cpp part of llvm-c-test is updated to clone a function's prefix and prologue.
2023-12-12[C API] Add getters and setters for fast-math flags on relevant instructions ↵Benji Smith1-0/+56
(#75123) These flags are usable on floating point arithmetic, as well as call, select, and phi instructions whose resulting type is floating point, or a vector of, or an array of, a valid type. Whether or not the flags are valid for a given instruction can be checked with the new LLVMCanValueUseFastMathFlags function. These are exposed using a new LLVMFastMathFlags type, which is an alias for unsigned. An anonymous enum defines the bit values for it. Tests are added in echo.ll for select/phil/call, and the floating point types in the new float_ops.ll bindings test. Select and the floating point arithmetic instructions were not implemented in llvm-c-test/echo.cpp, so they were added as well.
2023-12-11[LLVM-C] Support operand bundles (#73914)Quinton Miller1-7/+39
Added the following functions for manipulating operand bundles, as well as building ``call`` and ``invoke`` instructions that use operand bundles: * LLVMBuildCallWithOperandBundles * LLVMBuildInvokeWithOperandBundles * LLVMCreateOperandBundle * LLVMDisposeOperandBundle * LLVMGetNumOperandBundles * LLVMGetOperandBundleAtIndex * LLVMGetNumOperandBundleArgs * LLVMGetOperandBundleArgAtIndex * LLVMGetOperandBundleTag Fixes #71873.
2023-12-06[llvm-c] Add support for setting/getting new disjoint flag on or ↵Alex Bradbury1-0/+2
instructions (#74517) Follows #73952 doing the same thing for the nneg flag on zext (i.e., exposing support in the C API).
2023-11-29[C API] Add support for setting/getting new nneg flag on zext instructions ↵Benji Smith1-0/+8
(#73592) This flag was added in #67982, but was not yet accessible via the C API. This commit adds a getter/setter for this flag, and a test for it.
2023-09-30[C API] Fix LLVMGetOrdering/LLVMIsAtomicSingleThread for fence/memory instrs ↵Benji Smith1-0/+8
(#65228) Fixes https://github.com/llvm/llvm-project/issues/65227 LLVMGetOrdering previously did not support Fence instructions, and calling it on a fence would lead to a bad cast as it assumed a load/store, or an AtomicRMWInst. This would either read a garbage memory order, or assertion LLVMIsAtomicSingleThread did not support either Fence instructions, loads, or stores, and would similarly lead to a bad cast. It happened to work out since the relevant types all have their synch scope ID at the same offset, but it still should be fixed These cases are now fixed for the C API, and tests for these instructions are added. The echo test utility now also supports cloning Fence instructions, which it did not previously ----- From what I can tell, there's no unified API to pull `getOrdering`/`getSyncScopeID` from, and instead requires casting to individual types: if there is a better way of handling this I can switch to that
2023-08-15[C API]: Add getters for inline assembly template string, constraints, and flagsJustin Bogner1-0/+30
This change adds support for accessing information about inline assembly calls through the C API, enough to be able to round-trip the information. This partially addresses https://llvm.org/pr42692 which points out gaps in the C API Getters for each of the parameters to LLVMGetInlineAsm/InlineAsm::get have been added, such that the C API now has enough surface to clone inline assembly calls This API currently only returns the raw constraint string via LLVMGetInlineAsmConstraintString: it may be prudent to also expose the parsed constraints via InlineAsm::ParseConstraints, but I wasn't sure how that should look like. This at least exposes the information for clients Patch by Benji Smith. Thanks! Differential Revision: https://reviews.llvm.org/D153185
2023-07-31[llvm-c] Add LLVMSetTailCallKind and LLVMGetTailCallKindYAMAMOTO Takashi1-1/+1
Reviewed By: aeubanks Differential Revision: https://reviews.llvm.org/D153107
2023-06-08[C API] Add getters and setters for NUW, NSW, and ExactJustin Bogner1-0/+24
This partially addresses Bug 42692; see discussion there. Adds C API getters and setters for the NUW, NSW, and Exact flags on various instructions. Patch by Craig Disselkoen. Thanks! Differential Revision: https://reviews.llvm.org/D89252
2023-02-15[llvm-c] Add C API methods to match 64bit ArrayType C++ API signaturesMeghan Denny1-6/+4
Fixes https://github.com/llvm/llvm-project/issues/56496. As mentioned in the issue, new functions LLVMArrayType2 and LLVMGetArrayLength2 are created so as to not break the old API. The old methods are then marked as deprecated and callers are updated. Differential Revision: https://reviews.llvm.org/D143700
2022-12-20[IR] Add a target extension type to LLVM.Joshua Cranmer1-0/+2
Target-extension types represent types that need to be preserved through optimization, but otherwise are not introspectable by target-independent optimizations. This patch doesn't add any uses of these types by an existing backend, it only provides basic infrastructure such that these types would work correctly. Reviewed By: nikic, barannikov88 Differential Revision: https://reviews.llvm.org/D135202
2022-12-06[llvm-c][test] Remove typed pointer support from llvm-c-test echoArthur Eubanks1-3/+1
Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D139364
2022-06-23[llvm-c] Add LLVMGetAggregateElement() functionNikita Popov1-30/+12
This adds LLVMGetAggregateElement() as a wrapper for Constant::getAggregateElement(), which allows fetching a struct/array/vector element without handling different possible underlying representations. As the changed echo test shows, previously you for example had to treat ConstantArray (use LLVMGetOperand) and ConstantDataArray (use LLVMGetElementAsConstant) separately, not to mention all the other possible representations (like PoisonValue). I've deprecated LLVMGetElementAsConstant() in favor of the new function, which is strictly more powerful (but I could be convinced to drop the deprecation). This is partly motivated by https://reviews.llvm.org/D125795, which drops LLVMConstExtractValue() because the underlying constant expression no longer exists. This function could previously be used as a poor man's getAggregateElement(). Differential Revision: https://reviews.llvm.org/D128417
2022-06-02[llvm-c-test] Default to opaque pointersFangrui Song1-1/+2
2022-06-01[llvm-c-test] Always set opaque pointers modeNikita Popov1-2/+1
Avoid a behavior change when opaque pointers are enabled by default.
2022-05-16[llvm-c] Add functions for enabling and creating opaque pointersNicolas Abram Lujan1-7/+11
This is based on https://reviews.llvm.org/D125168 which adds a wrapper to allow use of opaque pointers from the C API. I added an opaque pointer mode test to echo.ll, and to fix assertions that forbid the use of mixed typed and opaque pointers that were triggering in it I had to also add wrappers for setOpaquePointers() and isOpaquePointer(). I also changed echo.ll to remove a bitcast i32* %x to i8*, because passing it through llvm-as and llvm-dis was generating a %0 = bitcast ptr %x to ptr, but when building that same bitcast in echo.cpp it was getting elided by IRBuilderBase::CreateCast (https://github.com/llvm/llvm-project/blob/08ac66124874d70dab63c731da0244f9e29ef168/llvm/include/llvm/IR/IRBuilder.h#L1998-L1999). Differential Revision: https://reviews.llvm.org/D125183
2022-02-02Cleanup header dependencies in LLVMCoreserge-sans-paille1-0/+1
Based on the output of include-what-you-use. This is a big chunk of changes. It is very likely to break downstream code unless they took a lot of care in avoiding hidden ehader dependencies, something the LLVM codebase doesn't do that well :-/ I've tried to summarize the biggest change below: - llvm/include/llvm-c/Core.h: no longer includes llvm-c/ErrorHandling.h - llvm/IR/DIBuilder.h no longer includes llvm/IR/DebugInfo.h - llvm/IR/IRBuilder.h no longer includes llvm/IR/IntrinsicInst.h - llvm/IR/LLVMRemarkStreamer.h no longer includes llvm/Support/ToolOutputFile.h - llvm/IR/LegacyPassManager.h no longer include llvm/Pass.h - llvm/IR/Type.h no longer includes llvm/ADT/SmallPtrSet.h - llvm/IR/PassManager.h no longer includes llvm/Pass.h nor llvm/Support/Debug.h And the usual count of preprocessed lines: $ clang++ -E -Iinclude -I../llvm/include ../llvm/lib/IR/*.cpp -std=c++14 -fno-rtti -fno-exceptions | wc -l before: 6400831 after: 6189948 200k lines less to process is no that bad ;-) Discourse thread on the topic: https://llvm.discourse.group/t/include-what-you-use-include-cleanup Differential Revision: https://reviews.llvm.org/D118652
2021-12-17[llvm-c] Accept GEP operators in some APIsNikita Popov1-0/+13
As requested in D115787, I've added a test for LLVMConstGEP2 and LLVMConstInBoundsGEP2. However, to make this work in the echo test, I also had to change a couple of APIs to work on GEP operators, rather than only GEP instructions. Differential Revision: https://reviews.llvm.org/D115858
2021-12-04[llvm-c] Avoid deprecated APIs in testsNikita Popov1-6/+10
Avoid the use of deprecated (opaque pointer incompatible) APIs in C API tests, in preparation for header deprecation. Add a LLVMGetGEPSourceElementType() to cover a bit of functionality that is necessary for the echo test. This change is split out from https://reviews.llvm.org/D114936.
2021-12-02[llvm-c] Make LLVMAddAlias opaque pointer compatibleNikita Popov1-2/+4
Deprecate LLVMAddAlias in favor of LLVMAddAlias2, which accepts a value type and an address space. Previously these were extracted from the pointer type. Differential Revision: https://reviews.llvm.org/D114860
2021-10-22[LLVM-C]Add LLVMAddMetadataToInst, deprecated LLVMSetInstDebugLocation.Florian Hahn1-1/+1
IRBuilder has been updated to support preserving metdata in a more general manner. This patch adds `LLVMAddMetadataToInst` and deprecates `LLVMSetInstDebugLocation` in favor of the more general function. Reviewed By: aprantl Differential Revision: https://reviews.llvm.org/D93454
2021-10-08[NFC] Make some includes explicitNikita Popov1-0/+1
Avoid relying on a number of indirect includes that currently happen through the Hashing.h header in DenseMapInfo.h.
2021-06-03[ADT] Move DenseMapInfo for ArrayRef/StringRef into respective headers (NFC)Nikita Popov1-0/+1
This is a followup to D103422. The DenseMapInfo implementations for ArrayRef and StringRef are moved into the ArrayRef.h and StringRef.h headers, which means that these two headers no longer need to be included by DenseMapInfo.h. This required adding a few additional includes, as many files were relying on various things pulled in by ArrayRef.h. Differential Revision: https://reviews.llvm.org/D103491
2021-02-12LLVM-C: Allow LLVM{Get/Set}Alignment on an atomicrmw/cmpxchg instruction.James Y Knight1-0/+2
(Now that these can have alignment specified.)
2020-12-30Fixes warning 'enumeration value not handled in switch'.Bogdan Graur1-0/+2
This was introduced in commit: 981a0bd85811fe49379fdbef35528e2c2f3511a3. Differential Revision: https://reviews.llvm.org/D93944
2020-11-30Creating a named struct requires only a Context and a name, but looking up a ↵Nick Lewycky1-1/+1
struct by name requires a Module. The method on Module merely accesses the LLVMContextImpl and no data from the module itself, so this patch moves getTypeByName to a static method on StructType that takes a Context and a name. There's a small number of users of this function, they are all updated. This updates the C API adding a new method LLVMGetTypeByName2 that takes a context and a name. Differential Revision: https://reviews.llvm.org/D78793
2020-11-25Adding PoisonValue for representing poison value explicitly in IRZhengyang Liu1-0/+6
Define ConstantData::PoisonValue. Add support for poison value to LLLexer/LLParser/BitcodeReader/BitcodeWriter. Add support for poison value to llvm-c interface. Add support for poison value to OCaml binding. Add m_Poison in PatternMatch. Differential Revision: https://reviews.llvm.org/D71126
2020-10-28C API: support scalable vectorsCraig Disselkoen1-3/+3
This adds support for scalable vector types in the C API and in llvm-c-test, and also adds a test to ensure that llvm-c-test can properly roundtrip operations involving scalable vectors. While creating this diff, I discovered that the C API cannot properly roundtrip _constant expressions_ involving shufflevector / scalable vectors, but that seems to be a separate enough issue that I plan to address it in a future diff (unless reviewers feel it should be addressed here). Differential Revision: https://reviews.llvm.org/D89816
2020-09-26[LLVM-C] Turn a ShuffleVector Constant Into a Getter.Robert Widmann1-1/+1
It is not a good idea to expose raw constants in the LLVM C API. Replace this with an explicit getter. Differential Revision: https://reviews.llvm.org/D88367
2020-09-25C API: functions to get mask of a ShuffleVectorCraig Disselkoen1-11/+69
This commit fixes a regression (from LLVM 10 to LLVM 11 RC3) in the LLVM C API. Previously, commit 1ee6ec2bf removed the mask operand from the ShuffleVector instruction, storing the mask data separately in the instruction instead; this reduced the number of operands of ShuffleVector from 3 to 2. AFAICT, this change unintentionally caused a regression in the LLVM C API. Specifically, it is no longer possible to get the mask of a ShuffleVector instruction through the C API. This patch introduces new functions which together allow a C API user to get the mask of a ShuffleVector instruction, restoring the functionality which was previously available through LLVMGetOperand(). This patch also adds tests for this change to the llvm-c-test executable, which involved adding support for InsertElement, ExtractElement, and ShuffleVector itself (as well as constant vectors) to echo.cpp. Previously, vector operations weren't tested at all in echo.ll. I also fixed some typos in comments and help-text nearby these changes, which I happened to spot while developing this patch. Since the typo fixes are technically unrelated other than being in the same files, I'm happy to take them out if you'd rather they not be included in the patch. Differential Revision: https://reviews.llvm.org/D88190
2020-05-15[SVE] Restore broken LLVM-C ABI compatabilityChristopher Tetreault1-1/+1
Reviewers: deadalnix, efriedma, rengolin, jyknight, joerg Reviewed By: joerg Subscribers: tschuett, hiraditya, rkruppe, psnobl, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D79915
2020-05-15[IR][BFloat] Add BFloat IR typeTies Stuij1-0/+2
Summary: The BFloat IR type is introduced to provide support for, initially, the BFloat16 datatype introduced with the Armv8.6 architecture (optional from Armv8.2 onwards). It has an 8-bit exponent and a 7-bit mantissa and behaves like an IEEE 754 floating point IR type. This is part of a patch series upstreaming Armv8.6 features. Subsequent patches will upstream intrinsics support and C-lang support for BFloat. Reviewers: SjoerdMeijer, rjmccall, rsmith, liutianle, RKSimon, craig.topper, jfb, LukeGeeson, sdesmalen, deadalnix, ctetreau Subscribers: hiraditya, llvm-commits, danielkiss, arphaman, kristof.beyls, dexonsmith Tags: #llvm Differential Revision: https://reviews.llvm.org/D78190
2020-04-22[SVE] Add new VectorType subclassesChristopher Tetreault1-1/+4
Summary: Introduce new types for fixed width and scalable vectors. Does not remove getNumElements yet so as to not break code during transition period. Reviewers: deadalnix, efriedma, sdesmalen, craig.topper, huntergr Reviewed By: sdesmalen Subscribers: jholewinski, arsenm, jvesely, nhaehnle, mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, nicolasvasilache, csigg, arpith-jacob, mgester, lucyrfox, liufengdb, kerbowa, Joonsoo, grosul1, frgossen, lldb-commits, tschuett, hiraditya, rkruppe, psnobl, llvm-commits Tags: #llvm, #lldb Differential Revision: https://reviews.llvm.org/D77587
2020-04-13Make IRBuilder automatically set alignment on load/store/alloca.Eli Friedman1-0/+1
This is equivalent in terms of LLVM IR semantics, but we want to transition away from using MaybeAlign to represent the alignment of these instructions. Differential Revision: https://reviews.llvm.org/D77984
2020-01-06[NFC] Fix trivial typos in commentsJames Henderson1-2/+2
Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D72143 Patch by Kazuaki Ishizaki.
2019-11-05[IR] Add Freeze instructionaqjune1-0/+5
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
2019-11-05Fix clone_constant_impl to correctly deal with null pointersaqjune1-0/+7
Summary: This patch resolves llvm-c-test's following error ``` LLVM ERROR: LLVMGetValueKind returned incorrect type ``` which arises when the input bitcode contains a null pointer. Reviewers: jdoerfert, CodaFi, deadalnix Reviewed By: jdoerfert Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68928
2019-09-26Improve C API support for atomicrmw and cmpxchg.Nick Lewycky1-1/+20
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
2019-08-15Revert "Expose TailCallKind via the LLVM C API"Jonas Devlieghere1-1/+1
This is failing on several build bots. Reverting as discussed in https://reviews.llvm.org/D66061. llvm-svn: 368953
2019-08-14Expose TailCallKind via the LLVM C APIRobert Widmann1-1/+1
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
2019-02-05[LLVM-C] Add Bindings to GlobalIFuncRobert Widmann1-2/+76
Summary: Adds the standard gauntlet of accessors for global indirect functions and updates the echo test. Now it would be nice to have a target abstraction so one could know if they have access to a suitable ELF linker and runtime. Reviewers: whitequark, deadalnix Reviewed By: whitequark Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D56177 llvm-svn: 353193
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth1-4/+3
to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
generated by cgit v1.1 at 2025-09-29 09:01:13 +0000