| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[mlir] (NFC) Clean up bazel and CMake target names All dialect targets in bazel have been named *Dialect and all dialect targets in CMake have been named MLIR*Dialect. | 4 年前 | |
[mlir][ArmSME] Split the Op definition (nfc) (#67985) Move the definitions of LLVM intrinsic Ops for ArmSME into a dedicated file. To facilitate this, the dialect definition together with various shared definitions are moved to ArmSME.td. This change will allow us to refactor the ArmSME dialect documentation. In particular, we will be able to categorise the Ops into "regular" and "intrinsic" ops. Also, it will be easier to add some custom documentation as opposed to relying on auto-generated docs that simply list the available Ops. The documentation will be updated in a forthcoming patch. Only non-functional changes. | 2 年前 | |
[mlir][ArmSVE] Restructure sources to match ArmSME dialect (NFC) (#68399) This rearranges the Arm SVE dialect to have the same structure of the Arm SME dialect. So this just moves around some source files and adds a ArmSVE_IntrOp base class for SVE intrinsics. This makes later changes a little easier and more consistent other dialects. | 2 年前 | |
[mlir] Support lowering of dialect attributes attached to top-level modules This patch supports the processing of dialect attributes attached to top-level module-type operations during MLIR-to-LLVMIR lowering. This approach modifies the mlir::translateModuleToLLVMIR() function to call ModuleTranslation::convertOperation() on the top-level operation, after its body has been lowered. This, in turn, will get the LLVMTranslationDialectInterface object associated to that operation's dialect before trying to use it for lowering prior to processing dialect attributes attached to the operation. Since there are no LLVMTranslationDialectInterfaces for the builtin and GPU dialects, which define their own module-type operations, this patch also adds and registers them. The requirement for always calling mlir::registerBuiltinDialectTranslation() before any translation of MLIR to LLVM IR where builtin module operations are present is introduced. The purpose of these new translation interfaces is to succeed when processing module-type operations, allowing the lowering process to continue and to prevent the introduction of failures related to not finding such interfaces. Differential Revision: https://reviews.llvm.org/D145932 | 3 年前 | |
[mlir][gpu] Change GPU modules to globals (#135478) Load/unload GPU modules in global ctors/dtors instead of each time when launching a kernel. Loading GPU modules is a heavy-weight operation and synchronizes the GPU context. Now that the modules are loaded ahead of time, asynchronously launched kernels can run concurrently, see https://discourse.llvm.org/t/how-to-lower-the-combination-of-async-gpu-ops-in-gpu-dialect. The implementations of embedBinary() and launchKernel() use slightly different mechanics at the moment but I prefer to not change the latter more than necessary as part of this PR. I will prepare a follow-up NFC for launchKernel() to align them again. | 1 年前 | |
[MLIR] Apply clang-tidy fixes for readability-identifier-naming in LLVMToLLVMIRTranslation.cpp (NFC) | 8 个月前 | |
[mlir][NVVM] Add nvvm.membar operation (#166698) Add nvvm.membar operation with level as defined in https://docs.nvidia.com/cuda/parallel-thread-execution/#parallel-synchronization-and-communication-instructions-membar This will be used to replace direct intrinsic call in CUDA Fortran for threadfence(), threadfence_block and thread fence_system() currently lowered here: https://github.com/llvm/llvm-project/blob/e700f157026bf8b4d58f936c5db8f152e269d77f/flang/lib/Optimizer/Builder/CUDAIntrinsicCall.cpp#L1310 The nvvm membar intrsinsic are also used in CUDA C/C++ (https://github.com/llvm/llvm-project/blob/49f55f4991227f3c7a2b8161bbf45c74b7023944/clang/lib/Headers/__clang_cuda_device_functions.h#L528) | 9 个月前 | |
[mlir][NFC] Use getDefiningOp<OpTy>() instead of dyn_cast<OpTy>(getDefiningOp()) (#150428) This PR uses val.getDefiningOp<OpTy>() to replace dyn_cast<OpTy>(val.getDefiningOp()) , dyn_cast_or_null<OpTy>(val.getDefiningOp()) and dyn_cast_if_present<OpTy>(val.getDefiningOp()). | 1 年前 | |
[OpenMP][flang] Lowering of OpenMP custom reductions to MLIR (#168417) This patch add support for lowering of custom reductions to MLIR. It also enhances the capability of the pass to automatically mark functions as "declare target" by traversing custom reduction initializers and combiners. | 8 个月前 | |
[mlir][ptr] Add ptr.ptr_diff operation (#157354) Thi patch introduces the ptr.ptr_diff operation for computing pointer differences. The semantics of the operation are given by: `` The ptr_diff operation computes the difference between two pointers, returning an integer or index value representing the number of bytes between them. The operation supports both scalar and shaped types with value semantics: - When both operands are scalar: produces a single difference value - When both are shaped: performs element-wise subtraction, shapes must be the same The operation also supports the following flags: - none: No flags are set. - nuw: No Unsigned Wrap, if the subtraction causes an unsigned overflow, the result is a poison value. - nsw: No Signed Wrap, if the subtraction causes a signed overflow, the result is a poison value. NOTE: The pointer difference is calculated using an integer type specified by the data layout. The final result will be sign-extended or truncated to fit the result type as necessary. ` This patch also adds translation to LLVM IR hooks for the ptr_diff op. This translation uses the ptrtoaddr builder to compute only index bits difference. Example: mlir llvm.func @ptr_diff_vector_i32(%ptrs1: vector<8x!ptr.ptr<#llvm.address_space<0>>>, %ptrs2: vector<8x!ptr.ptr<#llvm.address_space<0>>>) -> vector<8xi32> { %diffs = ptr.ptr_diff %ptrs1, %ptrs2 : vector<8x!ptr.ptr<#llvm.address_space<0>>> -> vector<8xi32> llvm.return %diffs : vector<8xi32> } Translation to LLVM IR: llvm define <8 x i32> @ptr_diff_vector_i32(<8 x ptr> %0, <8 x ptr> %1) { %3 = ptrtoint <8 x ptr> %0 to <8 x i64> %4 = ptrtoint <8 x ptr> %1 to <8 x i64> %5 = sub <8 x i64> %3, %4 %6 = trunc <8 x i64> %5 to <8 x i32> ret <8 x i32> %6 } ` --------- Co-authored-by: Mehdi Amini <joker.eph@gmail.com> | 10 个月前 | |
[mlir][ROCDL] Plumb through AMDGPU memory access metadata (#110916) The LLVM backend has moved from function-wide attributes for making assurances about potentially unsafe atomic operations (like "unsafe-fp-atomics") to metadata on individual atomic operations. This commit adds support for generating this metadata from MLIR. --------- Co-authored-by: Quinn Dawkins <quinn.dawkins@gmail.com> | 1 年前 | |
[mlir] Remove unused includes (NFC) (#147158) These are identified by misc-include-cleaner. I've filtered out those that break builds. Also, I'm staying away from llvm-config.h, config.h, and Compiler.h, which likely cause platform- or compiler-specific build failures. | 1 年前 | |
[mlir] Remove unused includes (NFC) (#147158) These are identified by misc-include-cleaner. I've filtered out those that break builds. Also, I'm staying away from llvm-config.h, config.h, and Compiler.h, which likely cause platform- or compiler-specific build failures. | 1 年前 | |
[MLIR][XeVM] Add lowering for llvm load store ops with XeVM cache control (#156768) Add lowering support for LLVM load / store ops with XeVM cache control attributes. | 11 个月前 | |
[mlir][LLVM|ptr] Add the #llvm.address_space attribute, and allow ptr translation (#156333) This commit introduces the #llvm.address_space attribute. This attribute implements the ptr::MemorySpaceAttrInterface, establishing the semantics of the LLVM address space. This allows making !ptr.ptr translatable to LLVM IR as long it uses the #llvm.address_space attribute. Concretely, !ptr.ptr<#llvm.address_space<N>> now translates to ptr addrspace(N). Additionally, this patch makes PtrLikeTypes with no metadata, no element type, and with #llvm.address_space memory space, compatible with the LLVM dialect. **Infrastructure Updates:** - Refactor ptr::MemorySpaceAttrInterface to include DataLayout parameter for better validation - Add new utility functions LLVM::isLoadableType() and LLVM::isTypeCompatibleWithAtomicOp() - Update type compatibility checks to support ptr-like types with LLVM address spaces - Splice the MemorySpaceAttrInterface to its own library, so the LLVMDialect won't depend on the PtrDialect yet **Translation Support:** - New PtrToLLVMIRTranslation module for converting ptr dialect to LLVM IR - Type translation support for ptr types with LLVM address spaces - Proper address space preservation during IR lowering Example: mlir llvm.func @llvm_ops_with_ptr_values(%arg0: !llvm.ptr) { %1 = llvm.load %arg0 : !llvm.ptr -> !ptr.ptr<#llvm.address_space<1>> llvm.store %1, %arg0 : !ptr.ptr<#llvm.address_space<1>>, !llvm.ptr llvm.return } Translates to: llvmir ; ModuleID = 'LLVMDialectModule' source_filename = "LLVMDialectModule" define void @llvm_ops_with_ptr_values(ptr %0) { %2 = load ptr addrspace(1), ptr %0, align 8 store ptr addrspace(1) %2, ptr %0, align 8 ret void } !llvm.module.flags = !{!0} !0 = !{i32 2, !"Debug Info Version", i32 3} | 11 个月前 | |
[mlir] Reland 5a6e52d6ef96d2bcab6dc50bdb369662ff17d2a0 with update (NFC) Excluded updates to mlir/lib/AsmParser/Parser.cpp , which caused LIT failure "FAIL: MLIR::completion.test" on multiple buildbots. | 1 年前 |