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
17 lines
430 B
MLIR
17 lines
430 B
MLIR
// RUN: mlir-cpu-runner %s -e entry -entry-point-result=void \
|
|
// RUN: -shared-libs=%mlir_integration_test_dir/libmlir_c_runner_utils%shlibext | \
|
|
// RUN: FileCheck %s
|
|
|
|
module {
|
|
llvm.func @printI64(i64)
|
|
llvm.func @entry() {
|
|
%c2 = llvm.mlir.constant(-42: i64) :i64
|
|
%val = llvm.inline_asm "xor $0, $0", "=r,r" %c2 :
|
|
(i64) -> i64
|
|
|
|
// CHECK: 0
|
|
llvm.call @printI64(%val) : (i64) -> ()
|
|
llvm.return
|
|
}
|
|
}
|