Commit Graph

3 Commits

Author SHA1 Message Date
Alex Zinenko 2230bf99c7 [mlir] replace LLVMIntegerType with built-in integer type
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
2021-01-07 19:48:31 +01:00
Rahul Joshi b7382ed3fe [MLIR] Extend Symbol verification to reject public symbol declarations.
- Extend the Symbol interface with `isDeclaration` to identify operations that declare
  a symbol as opposed to define it.
- Extend verification to disallow public declarations as per the discussion in
   https://llvm.discourse.group/t/rfc-symbol-definition-declaration-x-visibility-checks/2140
- Adopt the new interface for `FuncOp` and fix test and code to not have/create public
  function declarations.

Differential Revision: https://reviews.llvm.org/D91456
2020-11-16 16:05:32 -08:00
Alexander Belyaev fed9ff5117 [mlir] Test CallOp STD->LLVM conversion.
This exercises the corner case that was fixed in
https://reviews.llvm.org/rG8979a9cdf226066196f1710903d13492e6929563.

The bug can be reproduced when there is a @callee with a custom type argument and @caller has a producer of this argument passed to the @callee.

Example:
func @callee(!test.test_type) -> i32
func @caller() -> i32 {
  %arg = "test.type_producer"() : () -> !test.test_type
  %out = call @callee(%arg) : (!test.test_type) -> i32
  return %out : i32
}

Even though there is a type conversion for !test.test_type, the output IR (before the fix) contained a DialectCastOp:

module {
  llvm.func @callee(!llvm.ptr<i8>) -> !llvm.i32
  llvm.func @caller() -> !llvm.i32 {
    %0 = llvm.mlir.null : !llvm.ptr<i8>
    %1 = llvm.mlir.cast %0 : !llvm.ptr<i8> to !test.test_type
    %2 = llvm.call @callee(%1) : (!test.test_type) -> !llvm.i32
    llvm.return %2 : !llvm.i32
  }
}

instead of

module {
  llvm.func @callee(!llvm.ptr<i8>) -> !llvm.i32
  llvm.func @caller() -> !llvm.i32 {
    %0 = llvm.mlir.null : !llvm.ptr<i8>
    %1 = llvm.call @callee(%0) : (!llvm.ptr<i8>) -> !llvm.i32
    llvm.return %1 : !llvm.i32
  }
}

Differential Revision: https://reviews.llvm.org/D85914
2020-08-13 19:10:21 +02:00