aboutsummaryrefslogtreecommitdiff
path: root/llvm/bindings
AgeCommit message (Collapse)AuthorFilesLines
2023-06-16[OCaml] Rename link_modules' to link_modulesAlan Hu2-4/+4
Commit 434e956 renamed link_modules to link_modules' for unclear reasons. Based on the commit's diff, the author possibly intended to have two functions, link_modules to bind to LLVMLinkModules and link_modules' to bind to LLVMLinkModules2. However, there is only one function. link_modules' appears in LLVM 3.8 onwards. Differential Revision: https://reviews.llvm.org/D153090
2023-06-05Remove vestiges of removed OCaml modulesAlan Hu2-33/+0
Several OCaml modules using the old PassManager API were removed in https://reviews.llvm.org/D144751, but the META file still needed to be updated to remove them. This diff also removes an unused macro definition related to the module removals. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D152114
2023-05-18[bindings] Remove LLVM python bindingsAnders Waldenborg16-2075/+0
The LLVM python bindings are defunct. They have not seen any substantial active development since 2014. The version number, which is used to find the libLLVM-NN.so library, has not been updated since LLVM 10.0 (2019) (and even then they were probably mostly broken) After fixing the version number to be able to run them at all, a large number of tests in the test suite fails. Already in 2017 the removal was discussed: https://discourse.llvm.org/t/is-anyone-using-still-using-the-python-bindings/46063 https://lists.llvm.org/pipermail/llvm-dev/2017-August/116857.html There exist external projects providing python bindings for LLVM, e.g: https://github.com/numba/llvmlite Differential Revision: https://reviews.llvm.org/D150642
2023-05-17[NFC][Py Reformat] Reformat python files in llvmTobias Hieta11-306/+375
This is the first commit in a series that will reformat all the python files in the LLVM repository. Reformatting is done with `black`. See more information here: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style Reviewed By: jhenderson, JDevlieghere, MatzeB Differential Revision: https://reviews.llvm.org/D150545
2023-04-14[llvm-c] Remove PassRegistry and initialization APIsNikita Popov1-49/+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-16[ConstExpr] Remove select constant expressionNikita Popov3-14/+0
This removes the select constant expression, as part of https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179. Uses of this expressions have already been removed in advance, so this just removes related infrastructure and updates tests. Differential Revision: https://reviews.llvm.org/D145382
2023-02-28[OCaml] Migrate from naked pointers to prepare for OCaml 5Alan Hu19-1670/+2243
The OCaml bindings currently return pointers to LLVM objects as-is to OCaml. These "naked pointers" end up appearing as values of local variables in OCaml code, stored as part of other OCaml values, etc. The safety of this design relies on the OCaml runtime system's ability to distinguish these pointers from pointers to memory on the OCaml garbage collected heap. In particular, when the OCaml GC encounters a pointer to memory known to not be part of the OCaml heap, it does not follow it. In OCaml 4.02 an optimized "no naked pointers" mode was introduced where the runtime system does not perform such checks and requires that no such naked pointers be passed to OCaml code, instead one of several encodings needs to be used. In OCaml 5, the no naked pointers mode is now the only mode. This diff uses one of the potential encodings to eliminate naked pointers, making the LLVM OCaml bindings compatible with the "no naked pointers" mode of OCaml >= 4.02 and 5. The encoding implemented in this diff relies on LLVM objects to be at least 2-byte aligned, meaning that the lsb of pointers will necessarily be clear. The encoding sets the lsb when passing LLVM pointers to OCaml, and clears it on the return path. Setting the lsb causes the OCaml runtime system to interpret the resulting value as a tagged integer, which does not participate in garbage collection. In some cases, particularly functions that receive an OCaml array of LLVM pointers, this encoding requires allocation of a temporary array, but otherwise this diff aims to preserve the existing performance characteristics of the OCaml bindings. Reviewed By: jberdine Differential Revision: https://reviews.llvm.org/D136400
2023-02-24[OCaml] Remove all PassManager-related functionsAlan Hu23-1020/+1
Reviewed By: aeubanks, nikic Differential Revision: https://reviews.llvm.org/D144751
2023-02-24Recommit "[SCCP] Remove legacy SCCP pass."Florian Hahn2-11/+0
This reverts commit a9a1950115d7db95c7439128b14af2cefe8f796d. The legacy PM uses in Polly have been removed, so recommit the patch. Original message: This is part of the optimization pipeline, of which the legacy pass manager version is deprecated. Reviewed By: aeubanks Differential Revision: https://reviews.llvm.org/D144201
2023-02-19[LoopIdiomRecognize] Remove legacy passFangrui Song3-14/+0
Following recent changes to remove non-core legacy passes.
2023-02-15[LoopDeletion] Remove legacy passFangrui Song3-14/+0
Following recent changes to remove non-core legacy passes.
2023-02-15[LoopReroll] Remove legacy pass (unused in the pipeline)Fangrui Song3-14/+0
Following recent changes to remove non-core legacy passes.
2023-02-15[llvm-c] Add C API methods to match 64bit ArrayType C++ API signaturesMeghan Denny1-1/+1
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-14[IPSCCP] Remove legacy passArthur Eubanks3-15/+1
This is part of the optimization pipeline, of which the legacy pass manager version is deprecated.
2023-02-14[GlobalOpt] Remove legacy passArthur Eubanks3-14/+0
This is part of the optimization pipeline, of which the legacy pass manager version is deprecated.
2023-02-09[Inliner] Remove legacy simple inlinerArthur Eubanks3-14/+0
It's part of the optimization pipeline, of which the legacy pass manager version is deprecated.
2023-02-07Reland [LegacyPM] Remove some legacy passesArthur Eubanks3-41/+0
These are part of the optimization pipeline, of which the legacy pass manager version is deprecated. Namely * Internalize * StripSymbols * StripNonDebugSymbols * StripDeadDebugInfo * StripDeadPrototypes * VectorCombine * WarnMissedTransformations Fixed previously failing ocaml tests (one of them seems to already be failing?)
2023-02-07Revert "[LegacyPM] Remove some legacy passes"Arthur Eubanks2-0/+27
This reverts commit a4b4f62beb0bf40123181e5f5bdf32ef54f87166. Ocaml bindings tests failing.
2023-02-07[LegacyPM] Remove some legacy passesArthur Eubanks2-27/+0
These are part of the optimization pipeline, of which the legacy pass manager version is deprecated. Namely * Internalize * StripSymbols * StripNonDebugSymbols * StripDeadDebugInfo * StripDeadPrototypes * VectorCombine * WarnMissedTransformations
2023-02-06[MergeFunctions] Remove legacy passArthur Eubanks3-14/+0
It's part of the optimization pipeline, which the legacy pass manager version is deprecated.
2022-11-15[AggressiveInstCombine] Remove legacy PM passArthur Eubanks1-3/+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-10-31[llvm][ocaml] Replace deprecated C functions in OCaml bindingsAlan Hu3-15/+19
Follow-up to D135524, to replace two more deprecated C functions in the OCaml bindings. const_in_bounds_gep now accepts the source element type as argument, and const_element has been changed into aggregate_element, which works on a wider range of constants and returns an option. Differential Revision: https://reviews.llvm.org/D136914
2022-10-25[Instrumentation] Remove legacy passesArthur Eubanks1-4/+0
Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D136615
2022-10-21[ObjCARC] Remove legacy PM versions of optimization passesArthur Eubanks1-4/+0
This doesn't touch objc-arc-contract because that's in the codegen pipeline. However, this does move its corresponding initialize function into initializeCodegen(). Reviewed By: asbirlea Differential Revision: https://reviews.llvm.org/D135041
2022-10-13[llvm-ocaml] Fix arity mismatch in pointer bindingsAlan Hu1-1/+1
Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D135842
2022-10-11[llvm-ocaml] Replace all typed pointer functions with opaque pointer functionsAlan Hu3-228/+72
Reviewed By: aeubanks Differential Revision: https://reviews.llvm.org/D135524
2022-10-10[Bindings] Remove go bindingsNikita Popov29-4373/+0
Remove the unmaintained Go bindings per https://discourse.llvm.org/t/rfc-remove-the-go-bindings/65725. The tinygo project provides maintained Go bindings at https://github.com/tinygo-org/go-llvm. Differential Revision: https://reviews.llvm.org/D135436
2022-10-03[llvm-ocaml] Add binding for constructing opaque pointersAlan Hu3-0/+12
Reviewed By: aeubanks Differential Revision: https://reviews.llvm.org/D134916
2022-09-26[NFC][2/n] Remove PrunePH passSebastian Peryt4-15/+0
Second patch in the series to remove legacy PM and associated -enable-new-pm=0 flag targets pass that has not been ported to new PM - PruneEH. Discussion about this can be found in D44415. Reviewed By: aeubanks Differential Revision: https://reviews.llvm.org/D134686
2022-09-08[ConstantExpr] Remove fneg expressionNikita Popov3-6/+0
As part of https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179, this removes the fneg constant expression (which is, incidentally, the only unary operator expression). Differential Revision: https://reviews.llvm.org/D133418
2022-07-12[IR] Remove support for float binop constant expressionsNikita Popov3-32/+0
As part of https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179, this removes support for the floating-point binop constant expressions fadd, fsub, fmul, fdiv and frem. As part of this change, the C APIs LLVMConstFAdd, LLVMConstFSub, LLVMConstFMul, LLVMConstFDiv and LLVMConstFRem are removed. The LLVMBuild APIs should be used instead. Differential Revision: https://reviews.llvm.org/D129478
2022-07-06[ConstExpr] Remove div/rem constant expressionsNikita Popov3-35/+0
D128820 stopped creating div/rem constant expressions by default; this patch removes support for them entirely. The getUDiv(), getExactUDiv(), getSDiv(), getExactSDiv(), getURem() and getSRem() on ConstantExpr are removed, and ConstantExpr::get() now only accepts binary operators for which ConstantExpr::isSupportedBinOp() returns true. Uses of these methods may be replaced either by corresponding IRBuilder methods, or ConstantFoldBinaryOpOperands (if a constant result is required). On the C API side, LLVMConstUDiv, LLVMConstExactUDiv, LLVMConstSDiv, LLVMConstExactSDiv, LLVMConstURem and LLVMConstSRem are removed and corresponding LLVMBuild methods should be used. Importantly, this also means that constant expressions can no longer trap! This patch still keeps the canTrap() method to minimize diff -- I plan to drop it in a separate NFC patch. Differential Revision: https://reviews.llvm.org/D129148
2022-07-04[IR] Remove support for insertvalue constant expressionNikita Popov4-34/+0
This removes the insertvalue constant expression, as part of https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179. This is very similar to the extractvalue removal from D125795. insertvalue is also not supported in bitcode, so no auto-ugprade is necessary. ConstantExpr::getInsertValue() can be replaced with IRBuilder::CreateInsertValue() or ConstantFoldInsertValueInstruction(), depending on whether a constant result is required (with the latter being fallible). The ConstantExpr::hasIndices() and ConstantExpr::getIndices() methods also go away here, because there are no longer any constant expressions with indices. Differential Revision: https://reviews.llvm.org/D128719
2022-06-28[IR] Remove support for extractvalue constant expressionNikita Popov4-37/+0
This removes the extractvalue constant expression, as part of https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179. extractvalue is already not supported in bitcode, so we do not need to worry about bitcode auto-upgrade. Uses of ConstantExpr::getExtractValue() should be replaced with IRBuilder::CreateExtractValue() (if the fact that the result is constant is not important) or ConstantFoldExtractValueInstruction() (if it is). Though for this particular case, it is also possible and usually preferable to use getAggregateElement() instead. The C API function LLVMConstExtractValue() is removed, as the underlying constant expression no longer exists. Instead, LLVMBuildExtractValue() should be used (which will constant fold or create an instruction). Depending on the use-case, LLVMGetAggregateElement() may also be used instead. Differential Revision: https://reviews.llvm.org/D125795
2022-06-27[ArgPromotion] Remove legacy PM supportNikita Popov4-15/+0
Support for the legacy pass manager in ArgPromotion causes complications in D125485. As the legacy pass manager for middle-end optimizations is unsupported, drop ArgPromotion from the legacy pipeline, rather than introducing additional complexity to deal with it. Differential Revision: https://reviews.llvm.org/D128536
2022-06-02[llvm-ocaml] Add and use opaque pointer compatible bindingsNikita Popov3-3/+139
Add bindings for LLVMConstGEP2, LLVMAddAlias2, LLVMBuildLoad2, LLVMBuildInvoke2, LLVMBuildGEP2, LLVMBuildInBoundsGEP2, LLVMBuildStructGEP2, LLVMBuildPtrDiff2 and use these in tests.
2022-06-02[llvm-ocaml] Add LLVMBuildCall2 bindingNikita Popov3-0/+17
Add binding for the opaque pointer compatible LLVMBuildCall2 API and use it in tests.
2022-04-29Remove loop-unswitch from various bindings.Florian Hahn4-15/+0
LoopUnswitch has been removed in fb4113ef0c8b. Also remove it from various bindings.
2022-04-27[LegacyPM] Remove ThreadSanitizerLegacyPassFangrui Song3-11/+0
Using the legacy PM for the optimization pipeline was deprecated in 13.0.0. Following recent changes to remove non-core features of the legacy PM/optimization pipeline, remove ThreadSanitizerLegacyPass. Reviewed By: #sanitizers, vitalybuka Differential Revision: https://reviews.llvm.org/D124209
2022-04-24[OCaml][DebugInfo] Add bindings for parameter and auto variable creationVaivaswatha Nagaraj3-0/+204
This patch extends https://reviews.llvm.org/D90831 with a few more functions added to the OCaml debuginfo bindings. Differential Revision: https://reviews.llvm.org/D123914
2022-04-21[LegacyPM] Remove AddressSanitizerLegacyPassFangrui Song3-19/+0
Using the legacy PM for the optimization pipeline was deprecated in 13.0.0. Following recent changes to remove non-core features of the legacy PM/optimization pipeline, remove AddressSanitizerLegacyPass, ModuleAddressSanitizerLegacyPass, and ASanGlobalsMetadataWrapperPass. MemorySanitizerLegacyPass was removed in D123894. Reviewed By: #sanitizers, vitalybuka Differential Revision: https://reviews.llvm.org/D124216
2022-04-21Revert "[LegacyPM] Remove AddressSanitizerLegacyPass"Nico Weber3-0/+19
This reverts commit e68c589e53da4a53bf1cea79a9cb38308edbb8c6. Breaks check-llvm, see comments on https://reviews.llvm.org/D124216
2022-04-21[LegacyPM] Remove AddressSanitizerLegacyPassFangrui Song3-19/+0
Using the legacy PM for the optimization pipeline was deprecated in 13.0.0. Following recent changes to remove non-core features of the legacy PM/optimization pipeline, remove AddressSanitizerLegacyPass, ModuleAddressSanitizerLegacyPass, and ASanGlobalsMetadataWrapperPass. MemorySanitizerLegacyPass was removed in D123894. Reviewed By: #sanitizers, vitalybuka Differential Revision: https://reviews.llvm.org/D124216
2022-04-21[LegacyPM] Remove MemorySanitizerLegacyPassFangrui Song3-9/+0
Using the legacy PM for the optimization pipeline was deprecated in 13.0.0. Following recent changes to remove non-core features of the legacy PM/optimization pipeline, remove MemorySanitizerLegacyPass. Differential Revision: https://reviews.llvm.org/D123894
2022-04-21[Pipelines] Remove Legacy Passes in CoroutinesChuanqi Xu2-28/+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-04-19[Go] Remove PopulateLTOPassManager binding after D123882Fangrui Song1-4/+0
2022-04-18[ocaml bindings] Remove LTO bindingsArthur Eubanks3-19/+1
Followup to D123882.
2022-03-14[NFC] Fix go binding buildKito Cheng1-0/+1
Fix test failure cause by D121332.
2022-03-01[SanitizerBounds] Add support for NoSanitizeBounds functionTong Zhang1-0/+1
Currently adding attribute no_sanitize("bounds") isn't disabling -fsanitize=local-bounds (also enabled in -fsanitize=bounds). The Clang frontend handles fsanitize=array-bounds which can already be disabled by no_sanitize("bounds"). However, instrumentation added by the BoundsChecking pass in the middle-end cannot be disabled by the attribute. The fix is very similar to D102772 that added the ability to selectively disable sanitizer pass on certain functions. In this patch, if no_sanitize("bounds") is provided, an additional function attribute (NoSanitizeBounds) is attached to IR to let the BoundsChecking pass know we want to disable local-bounds checking. In order to support this feature, the IR is extended (similar to D102772) to make Clang able to preserve the information and let BoundsChecking pass know bounds checking is disabled for certain function. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D119816
2022-02-16[llvm] [bindings/OCaml] Remove unused dep on ounit2Michał Górny1-1/+0
Remove the dependency on ounit2 and the relevant lit code. It seems that ounit2 is not used at all and all OCaml binding tests pass without it installed. Thanks for Shiwei Weng and Josh Berdine for bringing this to my attention. Differential Revision: https://reviews.llvm.org/D119884
generated by cgit v1.1 at 2024-09-07 11:49:52 +0000