| f088b99e | 21-Apr-2022 |
Min-Yih Hsu <[email protected]> |
[mlir][LLVMIR] Use the correct way to determine if it's a scalable vector
One of the ShuffleVectorOp::build functions checks if the incoming vector operands is scalable vector by casting its type to
[mlir][LLVMIR] Use the correct way to determine if it's a scalable vector
One of the ShuffleVectorOp::build functions checks if the incoming vector operands is scalable vector by casting its type to mlir::VectorType first. However, in some cases the operand is not necessarily mlir::VectorType (e.g. it might be a LLVMVectorType).
This patch fixes this issue by using the dedicated `LLVM::isScalableVectorType` function to determine if the incoming vector is scalable vector or not.
Differential Revision: https://reviews.llvm.org/D125818
show more ...
|
| a75657d6 | 20-Apr-2022 |
Min-Yih Hsu <[email protected]> |
[mlir][LLVMIR] Do not cache llvm::Constant into instMap
Constants in MLIR are not globally unique, unlike that in LLVM IR. Therefore, reusing previous-translated constants might cause the user opera
[mlir][LLVMIR] Do not cache llvm::Constant into instMap
Constants in MLIR are not globally unique, unlike that in LLVM IR. Therefore, reusing previous-translated constants might cause the user operations not being dominated by the constant (because the previous-translated ones can be placed in arbitrary place)
This indeed misses some opportunities where we actually can reuse a previous-translated constants, but verbosity is not our first priority here.
Differential Revision: https://reviews.llvm.org/D124404
show more ...
|
| ea9bcb8b | 20-Apr-2022 |
Min-Yih Hsu <[email protected]> |
[mlir][LLVMIR] Do not cache Instruction generated on-the-fly
More specifically, the llvm::Instruction generated by llvm::ConstantExpr::getAsInstruction. Such Instruction will be deleted right away,
[mlir][LLVMIR] Do not cache Instruction generated on-the-fly
More specifically, the llvm::Instruction generated by llvm::ConstantExpr::getAsInstruction. Such Instruction will be deleted right away, but it's possible that when getAsInstruction is called again, it will create a new Instruction that has the same address with the one we just deleted. Thus, we shouldn't keep it in the `instMap` to avoid a conflicting index that triggers an assertion in processInstruction.
Differential Revision: https://reviews.llvm.org/D124402
show more ...
|