| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[mlir][LLVMIR] Apply CallOp/CallableInterface on suitable operations - Applying CallOpInterface on CallOp and InvokeOp. - Applying CallableInterface on LLVMFuncOp. We're testing the changes using CallGraph, which uses both interfaces. Differential Revision: https://reviews.llvm.org/D129026 | 3 年前 | |
[mlir][NFC] Update textual references of func to func.func in LLVM/Math/MemRef/NVGPU/OpenACC/OpenMP/Quant/SCF/Shape tests The special case parsing of func operations is being removed. | 4 年前 | |
[mlir][LLVMIR] Use a new way to verify GEPOp indices Previously, GEPOp relies on findKnownStructIndices to check if a GEP index should be static. The truth is, findKnownStructIndices can only tell you a GEP index _might_ be indexing into a struct (which should use a static GEP index). But GEPOp::build and GEPOp::verify are falsely taking this information as a certain answer, which creates many false alarms like the one depicted in test/Target/LLVMIR/Import/dynamic-gep-index.ll. The solution presented here adopts a new verification scheme: When we're recursively checking the child element types of a struct type, instead of checking every child types, we only check the one dictated by the (static) GEP index value. We also combine "refinement" logics -- refine/promote struct index mlir::Value into constants -- into the very verification process since they have lots of logics in common. The resulting code is more concise and less brittle. We also hide GEPOp::findKnownStructIndices since most of the aforementioned logics are already encapsulated within GEPOp::build and GEPOp::verify, we found little reason for findKnownStructIndices (or the new findStructIndices) to be public. Differential Revision: https://reviews.llvm.org/D124935 | 4 年前 | |
[mlir][LLVMIR] Add support for va_start/copy/end intrinsics This patch adds three new LLVM intrinsic operations: llvm.intr.vastart/copy/end. And its translation from LLVM IR. This effectively removes a restriction, imposed by 0126dcf1f0a1, where non-external functions in LLVM dialect cannot be variadic. At that time it was not clear how LLVM intrinsics are going to be modeled, which indirectly affects va_start/copy/end, the core intrinsics used in variadic functions. But since we have LLVM intrinsics as normal MLIR operations, it's not a problem anymore. Differential Revision: https://reviews.llvm.org/D127540 | 3 年前 | |
[MLIR Parser] Improve QoI for "expected token" errors A typical problem with missing a token is that the missing token is at the end of a line. The problem with this is that the error message gets reported on the start of the following line (which is where the next / invalid token is) which can be confusing. Handle this by noticing this case and backing up to the end of the previous line. Differential Revision: https://reviews.llvm.org/D125295 | 4 年前 | |
[mlir][llvm] Add vector insert/extract intrinsics These intrinsics will be needed to convert between fixed-length vectors and scalable vectors. This operation will be needed for VLS (vector-length specific) vectorization, when interfacing with vector functions or intrinsics that take scalable vectors as operands in a context where the length of our vectors is known or assumed at compile time, but we still want to generate scalable vector instructions. Differential Revision: https://reviews.llvm.org/D127100 | 3 年前 | |
[mlir][LLVM] Support opaque pointers in data layout entries This is likely preferable to having it crash if one were to specify an opaque pointer type, and the actual element type is unused either way. Differential Revision: https://reviews.llvm.org/D124334 | 4 年前 | |
[mlir][OpenMP] Added assembly format for omp.wsloop and remove parseClauses This patch - adds assembly format for omp.wsloop operation - removes the parseClauses clauses as it is not required anymore This is expected to be the final patch in a series of patches for replacing parsers for clauses with oilist. Reviewed By: Mogball Differential Revision: https://reviews.llvm.org/D121367 | 4 年前 | |
[mlir][nvvm] Change MMAShapeAttr to AttrDef MMAShapeAttr was a StructAttr Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D127348 | 4 年前 | |
[mlir] initial support for opaque pointers in the LLVM dialect LLVM IR has introduced and is moving forward with the concept of opaque pointers, i.e. pointer types that are not carrying around the pointee type. Instead, memory-related operations indicate the type of the data being accessed through the opaque pointer. Introduce the initial support for opaque pointers in the LLVM dialect: - LLVMPointerType to support omitting the element type; - alloca/load/store/gep to support opaque pointers in their operands and results; this requires alloca and gep to store the element type as an attribute; - memory-related intrinsics to support opaque pointers in their operands; - translation to LLVM IR for the ops above is no longer using methods deprecated in LLVM API due to the introduction of opaque pointers. Unlike LLVM IR, MLIR can afford to support both opaque and non-opaque pointers at the same time and simplify the transition. Translation to LLVM IR of MLIR that involves opaque pointers requires the LLVMContext to be configured to always use opaque pointers. Reviewed By: wsmoses Differential Revision: https://reviews.llvm.org/D123310 | 4 年前 | |
Recommit: "[MLIR][NVVM] Replace fdiv on fp16 with promoted (fp32) multiplication with reciprocal plus one (conditional) Newton iteration." This change rolls bcfc0a9051014437b55ab932d9aca5ecdca6776b forward (i.e., reverting 369ce54bb302f209239b8ebc77ad824add9df089) with fixed CMakeLists.txt. | 4 年前 | |
[mlir] replace 'emit_c_wrappers' func->llvm conversion option with a pass The 'emit_c_wrappers' option in the FuncToLLVM conversion requests C interface wrappers to be emitted for every builtin function in the module. While this has been useful to bootstrap the interface, it is problematic in the longer term as it may unintentionally affect the functions that should retain their existing interface, e.g., libm functions obtained by lowering math operations (see D126964 for an example). Since D77314, we have a finer-grain control over interface generation via an attribute that avoids the problem entirely. Remove the 'emit_c_wrappers' option. Introduce the '-llvm-request-c-wrappers' pass that can be run in any pipeline that needs blanket emission of functions to annotate all builtin functions with the attribute before performing the usual lowering that accounts for the attribute. Reviewed By: chelini Differential Revision: https://reviews.llvm.org/D127952 | 4 年前 | |
[mlir][ROCDL] Define MLIR wrappers around new MFMA intrinsics In order to support newer hardware, define wrappers around MFMA intrinsics that have not previously been exposed in the ROCDL dialect. A amdgpu.mfma wrapper around these instructions is in development and will provide a more user-friendly interface to them. Reviewed By: ThomasRaoux Differential Revision: https://reviews.llvm.org/D128079 | 3 年前 | |
[mlir][LLVMIR] Add support for va_start/copy/end intrinsics This patch adds three new LLVM intrinsic operations: llvm.intr.vastart/copy/end. And its translation from LLVM IR. This effectively removes a restriction, imposed by 0126dcf1f0a1, where non-external functions in LLVM dialect cannot be variadic. At that time it was not clear how LLVM intrinsics are going to be modeled, which indirectly affects va_start/copy/end, the core intrinsics used in variadic functions. But since we have LLVM intrinsics as normal MLIR operations, it's not a problem anymore. Differential Revision: https://reviews.llvm.org/D127540 | 3 年前 | |
[mlir][NFC] Update textual references of func to func.func in LLVM/Math/MemRef/NVGPU/OpenACC/OpenMP/Quant/SCF/Shape tests The special case parsing of func operations is being removed. | 4 年前 | |
[mlir][NFC] Update textual references of func to func.func in LLVM/Math/MemRef/NVGPU/OpenACC/OpenMP/Quant/SCF/Shape tests The special case parsing of func operations is being removed. | 4 年前 | |
[mlir] Remove the type keyword from type alias definitions This was carry over from LLVM IR where the alias definition can be ambiguous, but MLIR type aliases have no such problems. Having the type keyword is superfluous and doesn't add anything. This commit drops it, which also nicely aligns with the syntax for attribute aliases (which doesn't have a keyword). Differential Revision: https://reviews.llvm.org/D125501 | 4 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 |