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
22 lines
409 B
MLIR
22 lines
409 B
MLIR
// RUN: mlir-opt -pass-pipeline='func(canonicalize)' %s | FileCheck %s
|
|
// verify that terminators survive the canonicalizer
|
|
|
|
// CHECK-LABEL: @return
|
|
// CHECK: llvm.return
|
|
func @return() {
|
|
llvm.return
|
|
}
|
|
|
|
// CHECK-LABEL: @control_flow
|
|
// CHECK: llvm.br
|
|
// CHECK: llvm.cond_br
|
|
// CHECK: llvm.return
|
|
func @control_flow(%cond : i1) {
|
|
llvm.br ^bb1
|
|
^bb1:
|
|
llvm.cond_br %cond, ^bb2, ^bb1
|
|
^bb2:
|
|
llvm.return
|
|
}
|
|
|