| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[mlir] (NFC) run clang-format on all files | 3 年前 | |
[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. | 3 年前 | |
[mlir] Use value instead of getValue (NFC) | 3 年前 | |
[mlir] Move the Builtin FuncOp to the Func dialect This commit moves FuncOp out of the builtin dialect, and into the Func dialect. This move has been planned in some capacity from the moment we made FuncOp an operation (years ago). This commit handles the functional aspects of the move, but various aspects are left untouched to ease migration: func::FuncOp is re-exported into mlir to reduce the actual API churn, the assembly format still accepts the unqualified func. These temporary measures will remain for a little while to simplify migration before being removed. Differential Revision: https://reviews.llvm.org/D121266 | 4 年前 | |
[MLIR] UnknownLoc on Inlinable Calls in LLVMIR Translation During MLIR translation to LLVMIR if an inlineable call has an UnkownLoc we get this error message: inlinable function call in a function with debug info must have a !dbg location call void @callee() There is code that checks for this case and strips debug information to avoid this situation. I'm expanding this code to handle the case where an debug location points at a UnknownLoc. For example, a NamedLoc whose child location is an UnknownLoc. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D121633 | 4 年前 | |
Adjust "end namespace" comment in MLIR to match new agree'd coding style See D115115 and this mailing list discussion: https://lists.llvm.org/pipermail/llvm-dev/2021-December/154199.html Differential Revision: https://reviews.llvm.org/D115309 | 4 年前 | |
Revert "[MLIR] Generic 'malloc', 'aligned_alloc' and 'free' functions" This reverts commit 3e21fb616d9a1b29bf9d1a1ba484add633d6d5b3. A lot of integration tests are failing on the bot. | 3 年前 | |
[mlir] Support convert token type from LLVM IR. This patch supports the token type for converting from LLVM IR. Differential Revision: https://reviews.llvm.org/D126756 | 3 年前 | |
[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 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 4 年前 |