aboutsummaryrefslogtreecommitdiff
path: root/llvm/tools/llvm-c-test
AgeCommit message (Collapse)AuthorFilesLines
2023-07-07[LLVM-C] Use unwrapDI in LLVMDITypeGetNameTamir Duberstein3-0/+30
This function otherwise crashes. This behavior has been incorrect since its introduction in 260b581498bed0b847e7e086852e0082d266711d (D46627). Reviewed By: scott.linder Differential Revision: https://reviews.llvm.org/D154630
2023-07-07Appease clang-tidyTamir Duberstein3-60/+79
Address clang-tidy warnings, correct usage text. Differential Revision: https://reviews.llvm.org/D154661
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-04-14[llvm-c] Remove PassRegistry and initialization APIsNikita Popov2-5/+0
Remove C APIs for interacting with PassRegistry and pass initialization. These are legacy PM concepts, and are no longer relevant for the new pass manager. Calls to these initialization functions can simply be dropped. Differential Revision: https://reviews.llvm.org/D145043
2023-03-09[llvm-c] Remove PassManagerBuilder APIsNikita Popov1-1/+0
The legacy PM is only supported for codegen, and PassManagerBuilder is exclusively about the middle-end optimization pipeline. Drop it. Differential Revision: https://reviews.llvm.org/D145387
2023-03-02[llvm-c] Remove bindings for creating legacy passesNikita Popov1-5/+1
Legacy passes are only supported for codegen, and I don't believe it's possible to write backends using the C API, so we should drop all of those. Reduces the number of places that need to be modified when removing legacy passes. Differential Revision: https://reviews.llvm.org/D144970
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
2023-02-09[llvm-c-test] Fix leak after D138415Fangrui Song1-0/+1
2023-02-08[llvm-c-test] Fix unused variable warningsKazu Hirata1-0/+2
This patch fixes: llvm/tools/llvm-c-test/debuginfo.c:211:12: error: unused variable 'tag0' [-Werror,-Wunused-variable] llvm/tools/llvm-c-test/debuginfo.c:222:12: error: unused variable 'tag1' [-Werror,-Wunused-variable]
2023-02-08add LLVMGetDINodeTag to C bindingsDavide Bertola3-1/+32
Differential Revision: https://reviews.llvm.org/D138415
2023-01-31[llvm-c-test] Fix warningsKazu Hirata1-0/+3
This patch fixes: llvm/tools/llvm-c-test/metadata.c:49:16: error: unused variable 'tmp' [-Werror,-Wunused-variable] llvm-project/llvm/tools/llvm-c-test/metadata.c:70:16: error: unused variable 'md' [-Werror,-Wunused-variable] llvm/tools/llvm-c-test/metadata.c:74:16: error: unused variable 'md2' [-Werror,-Wunused-variable]
2023-01-31[llvm-c] add LLVMReplaceMDNodeOperandWithDavide Bertola3-0/+49
I'm working on a tool that visits debug info and massages it using the llvm-c API. I noticed that LLVMGetOperand special cases MDNodes so I can get their operands, but I can't replace them. This patch adds LLVMReplaceMDNodeOperandWith which boils down to MDNode::replaceOperandWith. The name was chosen for consistency with LLVMGetMDNodeOperands and LLVMGetMDNodeNumOperands. Differential Revision: https://reviews.llvm.org/D136637
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 Eubanks3-7/+4
Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D139364
2022-11-15[AggressiveInstCombine] Remove legacy PM passArthur Eubanks1-1/+0
As part of legacy PM optimization pipeline removal. This shouldn't be used in codegen pipelines so it should be ok to remove. Reviewed By: asbirlea Differential Revision: https://reviews.llvm.org/D137116
2022-07-08Fix test: LLVMGetBitcodeModule takes ownership of memory bufferNicolai Hähnle1-7/+2
Clarify this behavior in the C interface header file and fix a related bug in a test. Differential Revision: https://reviews.llvm.org/D129113
2022-07-07llvm-c: Add LLVMDeleteInstruction to fix a test issueNicolai Hähnle1-4/+3
Not deleting the loose instruction with metadata associated to it causes an assertion when the LLVMContext is destroyed. This was previously hidden by the fact that llvm-c-test does not call LLVMShutdown. The planned removal of ManagedStatic exposed this issue. Differential Revision: https://reviews.llvm.org/D129114
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 Song2-2/+4
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 Lujan3-10/+17
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-04-21[Pipelines] Remove Legacy Passes in CoroutinesChuanqi Xu1-1/+0
The legacy passes are deprecated now and would be removed in near future. This patch tries to remove legacy passes in coroutines. Reviewed By: aeubanks Differential Revision: https://reviews.llvm.org/D123918
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 Popov2-8/+13
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-09-16[DebugInfo] Enhance DIImportedEntity to accept children entitiesAlok Kumar Sharma1-5/+4
New field `elements` is added to '!DIImportedEntity', representing list of aliased entities. This is needed to dump optimized debugging information where all names in a module are imported, but a few names are imported with overriding aliases. Reviewed By: dblaikie Differential Revision: https://reviews.llvm.org/D109343
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-12-06[llvm-c] Delete unimplemented llvm-c/LinkTimeOptimizer.hFangrui Song1-1/+0
The file was added in 2007 but the functions have never been implemented. Having the file can only cause confusion to existing C API (llvm-c/lto.h) users.
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-10-18[ORC] Remove OrcV1 APIs.Lang Hames1-1/+1
This removes all legacy layers, legacy utilities, the old Orc C bindings, OrcMCJITReplacement, and OrcMCJITReplacement regression tests. ExecutionEngine and MCJIT are not affected by this change.
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 Disselkoen2-16/+73
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-03-11Add debug info support for Swift/Clang APINotes.Adrian Prantl1-2/+4
In order for dsymutil to collect .apinotes files (which capture attributes such as nullability, Swift import names, and availability), I want to propose adding an apinotes: field to DIModule that gets translated into a DW_AT_LLVM_apinotes (path) nested inside DW_TAG_module. This will be primarily used by LLDB to indirectly extract the Swift names of Clang declarations that were deserialized from DWARF. <rdar://problem/59514626> Differential Revision: https://reviews.llvm.org/D75585
2020-03-11Add an SDK attribute to DICompileUnitAdrian Prantl1-1/+1
This is part of PR44213 https://bugs.llvm.org/show_bug.cgi?id=44213 When importing (system) Clang modules, LLDB needs to know which SDK (e.g., MacOSX, iPhoneSimulator, ...) they came from. While the sysroot attribute contains the absolute path to the SDK, this doesn't work well when the debugger is run on a different machine than the compiler, and the SDKs are installed in different directories. It thus makes sense to just store the name of the SDK instead of the absolute path, so it can be found relative to LLDB. rdar://problem/51645582 Differential Revision: https://reviews.llvm.org/D75646
2020-01-17Move the sysroot attribute from DIModule to DICompileUnitAdrian Prantl1-7/+5
[this re-applies c0176916a4824812d25a5a22c4ff7c95857b0cd6 with the correct commit message and phabricator link] This addresses point 1 of PR44213. https://bugs.llvm.org/show_bug.cgi?id=44213 The DW_AT_LLVM_sysroot attribute is used for Clang module debug info, to allow LLDB to import a Clang module from source. Currently it is part of each DW_TAG_module, however, it is the same for all modules in a compile unit. It is more efficient and less ambiguous to store it once in the DW_TAG_compile_unit. This should have no effect on DWARF consumers other than LLDB. Differential Revision: https://reviews.llvm.org/D71732
2020-01-17Revert "Rename DW_AT_LLVM_isysroot to DW_AT_LLVM_sysroot"Adrian Prantl1-5/+7
This reverts commit 12e479475a896f664fb721f98c2d6805185ac352. I accidentally landed this patch with the wrong commit message ...
2020-01-17Rename DW_AT_LLVM_isysroot to DW_AT_LLVM_sysrootAdrian Prantl1-7/+5
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
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-12-03Recommit "[DWARF5]Addition of alignment atrribute in typedef DIE."Sourabh Singh Tomar1-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
generated by cgit v1.1 at 2024-09-07 13:41:07 +0000