summaryrefslogtreecommitdiff
path: root/mlir/lib/Conversion/LLVMCommon/StructBuilder.cpp
AgeCommit message (Collapse)Author
2025-07-22[mlir][NFC] update `Conversion` create APIs (6/n) (#149888)Maksim Levental
See https://github.com/llvm/llvm-project/pull/147168 for more info.
2023-02-09[mlir] Handle different pointer sizes in unranked memref descriptorsKrzysztof Drewniak
The code for unranked memref descriptors assumed that sizeof(!llvm.ptr) == lizeof(!llvm.ptr<N>) for all address spaces N. This is not always true (ex. the AMDGPU compiler backend has sizeof(!llvm.ptr) = 64 bits but sizeof(!llvm.ptr<5>) = 32 bits, where address space 5 is used for stack allocations). While this is merely an overallocation in the case where a non-0 address space has pointers smaller than the default, the existing code could cause OOB memory accesses when sizeof(!llvm.ptr<N>) > sizeof(!llvm.ptr). So, add an address spaces parameter to computeSizes in order to partially resolve this class of bugs. Note that the LLVM data layout in the conversion passes is currently set to "" and not constructed from the MLIR data layout or some other source, but this could change in the future. Depends on D142159 Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D141293
2022-08-10[mlir][LLVMIR] "Modernize" Insert/ExtractValueOpJeff Niu
This patch "modernizes" the LLVM `insertvalue` and `extractvalue` operations to use DenseI64ArrayAttr, since they only require an array of indices and previously there was confusion about whether to use i32 or i64 arrays, and to use assembly format. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D131537
2021-07-07[mlir] factor out common parts of the converstion to the LLVM dialectAlex Zinenko
"Standard-to-LLVM" conversion is one of the oldest passes in existence. It has become quite large due to the size of the Standard dialect itself, which is being split into multiple smaller dialects. Furthermore, several conversion features are useful for any dialect that is being converted to the LLVM dialect, which, without this refactoring, creates a dependency from those conversions to the "standard-to-llvm" one. Put several of the reusable utilities from this conversion to a separate library, namely: - type converter from builtin to LLVM dialect types; - utility for building and accessing values of LLVM structure type; - utility for building and accessing values that represent memref in the LLVM dialect; - lowering options applicable everywhere. Additionally, remove the type wrapping/unwrapping notion from the type converter that is no longer relevant since LLVM types has been reimplemented as first-class MLIR types. Reviewed By: pifon2a Differential Revision: https://reviews.llvm.org/D105534