2230bf99c7
The LLVM dialect type system has been closed until now, i.e. did not support types from other dialects inside containers. While this has had obvious benefits of deriving from a common base class, it has led to some simple types being almost identical with the built-in types, namely integer and floating point types. This in turn has led to a lot of larger-scale complexity: simple types must still be converted, numerous operations that correspond to LLVM IR intrinsics are replicated to produce versions operating on either LLVM dialect or built-in types leading to quasi-duplicate dialects, lowering to the LLVM dialect is essentially required to be one-shot because of type conversion, etc. In this light, it is reasonable to trade off some local complexity in the internal implementation of LLVM dialect types for removing larger-scale system complexity. Previous commits to the LLVM dialect type system have adapted the API to support types from other dialects. Replace LLVMIntegerType with the built-in IntegerType plus additional checks that such types are signless (these are isolated in a utility function that replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice. Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94178
15 lines
519 B
MLIR
15 lines
519 B
MLIR
// RUN: mlir-opt %s -test-convert-call-op | FileCheck %s
|
|
|
|
// CHECK-LABEL: llvm.func @callee(!llvm.ptr<i8>) -> i32
|
|
func private @callee(!test.test_type) -> i32
|
|
|
|
// CHECK-NEXT: llvm.func @caller() -> i32
|
|
func @caller() -> i32 {
|
|
%arg = "test.type_producer"() : () -> !test.test_type
|
|
%out = call @callee(%arg) : (!test.test_type) -> i32
|
|
return %out : i32
|
|
}
|
|
// CHECK-NEXT: [[ARG:%.*]] = llvm.mlir.null : !llvm.ptr<i8>
|
|
// CHECK-NEXT: [[OUT:%.*]] = llvm.call @callee([[ARG]])
|
|
// CHECK-SAME: : (!llvm.ptr<i8>) -> i32
|