maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/mlir/test/Dialect/LLVMIR/roundtrip.mlir

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

443 lines
19 KiB
MLIR
Raw Normal View History

Add support for vector ops in the LLVM dialect This CL is step 1/n towards building a simple, programmable and portable vector abstraction in MLIR that can go all the way down to generating assembly vector code via LLVM's opt and llc tools. This CL adds the 3 instructions `llvm.extractelement`, `llvm.insertelement` and `llvm.shufflevector` as documented in the LLVM LangRef "Vector Instructions" section. The "Experimental Vector Reduction Intrinsics" are left out for now and can be added in the future on a per-need basis. Appropriate roundtrip and LLVM Target tests are added. PiperOrigin-RevId: 262542095
2019-08-09 20:24:47 +08:00
// RUN: mlir-opt %s | mlir-opt | FileCheck %s
Initial version of the LLVM IR dialect LLVM IR types are defined using MLIR's extendable type system. The dialect provides the only type kind, LLVMType, that wraps an llvm::Type*. Since LLVM IR types are pointer-unique, MLIR type systems relies on those pointers to perform its own type unique'ing. Type parsing and printing is delegated to LLVM libraries. Define MLIR operations for the LLVM IR instructions currently used by the translation to the LLVM IR Target to simplify eventual transition. Operations classes are defined using TableGen. LLVM IR instruction operands that are only allowed to take constant values are accepted as attributes instead. All operations are using verbose form for printing and parsing. PiperOrigin-RevId: 229400375
2019-01-16 02:53:22 +08:00
[mlir] support returning unranked memrefs Initially, unranked memref descriptors in the LLVM dialect were designed only to be passed into functions. An assertion was guarding against returning unranked memrefs from functions in the standard-to-LLVM conversion. This is insufficient for functions that wish to return an unranked memref such that the caller does not know the rank in advance, and hence cannot allocate the descriptor and pass it in as an argument. Introduce a calling convention for returning unranked memref descriptors as follows. An unranked memref descriptor always points to a ranked memref descriptor stored on stack of the current function. When an unranked memref descriptor is returned from a function, the ranked memref descriptor it points to is copied to dynamically allocated memory, the ownership of which is transferred to the caller. The caller is responsible for deallocating the dynamically allocated memory and for copying the pointed-to ranked memref descriptor onto its stack. Provide default lowerings for std.return, std.call and std.indirect_call that maintain the conversion defined above. This convention is additionally exercised by a runtime test to guard against memory errors. Differential Revision: https://reviews.llvm.org/D82647
2020-06-26 20:34:00 +08:00
// CHECK-LABEL: func @ops
[MLIR] Handle llvm.icmp of pointers Differential Revision: https://reviews.llvm.org/D101712
2021-05-02 12:58:06 +08:00
// CHECK-SAME: (%[[I32:.*]]: i32, %[[FLOAT:.*]]: f32, %[[I8PTR1:.*]]: !llvm.ptr<i8>, %[[I8PTR2:.*]]: !llvm.ptr<i8>, %[[BOOL:.*]]: i1, %[[VI8PTR1:.*]]: !llvm.vec<2 x ptr<i8>>)
[mlir] replace LLVM dialect float types with built-ins Continue the convergence between LLVM dialect and built-in types by replacing the bfloat, half, float and double LLVM dialect types with their built-in counterparts. At the API level, this is a direct replacement. At the syntax level, we change the keywords to `bf16`, `f16`, `f32` and `f64`, respectively, to be compatible with the built-in type syntax. The old keywords can still be parsed but produce a deprecation warning and will be eventually removed. Depends On D94178 Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94179
2021-01-06 23:21:08 +08:00
func @ops(%arg0: i32, %arg1: f32,
[mlir] switch the modeling of LLVM types to use the new mechanism A new first-party modeling for LLVM IR types in the LLVM dialect has been developed in parallel to the existing modeling based on wrapping LLVM `Type *` instances. It resolves the long-standing problem of modeling identified structure types, including recursive structures, and enables future removal of LLVMContext and related locking mechanisms from LLVMDialect. This commit only switches the modeling by (a) renaming LLVMTypeNew to LLVMType, (b) removing the old implementaiton of LLVMType, and (c) updating the tests. It is intentionally minimal. Separate commits will remove the infrastructure built for the transition and update API uses where appropriate. Depends On D85020 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D85021
2020-08-04 17:37:50 +08:00
%arg2: !llvm.ptr<i8>, %arg3: !llvm.ptr<i8>,
[MLIR] Handle llvm.icmp of pointers Differential Revision: https://reviews.llvm.org/D101712
2021-05-02 12:58:06 +08:00
%arg4: i1, %arg5 : !llvm.vec<2x!llvm.ptr<i8>>) {
Fix minor spelling tweaks (NFC) Closes tensorflow/mlir#175 PiperOrigin-RevId: 275726876
2019-10-21 00:44:06 +08:00
// Integer arithmetic binary operations.
Initial version of the LLVM IR dialect LLVM IR types are defined using MLIR's extendable type system. The dialect provides the only type kind, LLVMType, that wraps an llvm::Type*. Since LLVM IR types are pointer-unique, MLIR type systems relies on those pointers to perform its own type unique'ing. Type parsing and printing is delegated to LLVM libraries. Define MLIR operations for the LLVM IR instructions currently used by the translation to the LLVM IR Target to simplify eventual transition. Operations classes are defined using TableGen. LLVM IR instruction operands that are only allowed to take constant values are accepted as attributes instead. All operations are using verbose form for printing and parsing. PiperOrigin-RevId: 229400375
2019-01-16 02:53:22 +08:00
//
[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-06 23:19:04 +08:00
// CHECK: {{.*}} = llvm.add %[[I32]], %[[I32]] : i32
// CHECK: {{.*}} = llvm.sub %[[I32]], %[[I32]] : i32
// CHECK: {{.*}} = llvm.mul %[[I32]], %[[I32]] : i32
// CHECK: {{.*}} = llvm.udiv %[[I32]], %[[I32]] : i32
// CHECK: {{.*}} = llvm.sdiv %[[I32]], %[[I32]] : i32
// CHECK: {{.*}} = llvm.urem %[[I32]], %[[I32]] : i32
// CHECK: {{.*}} = llvm.srem %[[I32]], %[[I32]] : i32
// CHECK: {{.*}} = llvm.icmp "ne" %[[I32]], %[[I32]] : i32
[MLIR] Handle llvm.icmp of pointers Differential Revision: https://reviews.llvm.org/D101712
2021-05-02 12:58:06 +08:00
// CHECK: {{.*}} = llvm.icmp "ne" %[[I8PTR1]], %[[I8PTR1]] : !llvm.ptr<i8>
// CHECK: {{.*}} = llvm.icmp "ne" %[[VI8PTR1]], %[[VI8PTR1]] : !llvm.vec<2 x ptr<i8>>
[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-06 23:19:04 +08:00
%0 = llvm.add %arg0, %arg0 : i32
%1 = llvm.sub %arg0, %arg0 : i32
%2 = llvm.mul %arg0, %arg0 : i32
%3 = llvm.udiv %arg0, %arg0 : i32
%4 = llvm.sdiv %arg0, %arg0 : i32
%5 = llvm.urem %arg0, %arg0 : i32
%6 = llvm.srem %arg0, %arg0 : i32
%7 = llvm.icmp "ne" %arg0, %arg0 : i32
[MLIR] Handle llvm.icmp of pointers Differential Revision: https://reviews.llvm.org/D101712
2021-05-02 12:58:06 +08:00
%ptrcmp = llvm.icmp "ne" %arg2, %arg2 : !llvm.ptr<i8>
%vptrcmp = llvm.icmp "ne" %arg5, %arg5 : !llvm.vec<2 x ptr<i8>>
Initial version of the LLVM IR dialect LLVM IR types are defined using MLIR's extendable type system. The dialect provides the only type kind, LLVMType, that wraps an llvm::Type*. Since LLVM IR types are pointer-unique, MLIR type systems relies on those pointers to perform its own type unique'ing. Type parsing and printing is delegated to LLVM libraries. Define MLIR operations for the LLVM IR instructions currently used by the translation to the LLVM IR Target to simplify eventual transition. Operations classes are defined using TableGen. LLVM IR instruction operands that are only allowed to take constant values are accepted as attributes instead. All operations are using verbose form for printing and parsing. PiperOrigin-RevId: 229400375
2019-01-16 02:53:22 +08:00
Replace remaining usages of the Instruction class with Operation. PiperOrigin-RevId: 240777521
2019-03-28 23:24:38 +08:00
// Floating point binary operations.
Initial version of the LLVM IR dialect LLVM IR types are defined using MLIR's extendable type system. The dialect provides the only type kind, LLVMType, that wraps an llvm::Type*. Since LLVM IR types are pointer-unique, MLIR type systems relies on those pointers to perform its own type unique'ing. Type parsing and printing is delegated to LLVM libraries. Define MLIR operations for the LLVM IR instructions currently used by the translation to the LLVM IR Target to simplify eventual transition. Operations classes are defined using TableGen. LLVM IR instruction operands that are only allowed to take constant values are accepted as attributes instead. All operations are using verbose form for printing and parsing. PiperOrigin-RevId: 229400375
2019-01-16 02:53:22 +08:00
//
[mlir] replace LLVM dialect float types with built-ins Continue the convergence between LLVM dialect and built-in types by replacing the bfloat, half, float and double LLVM dialect types with their built-in counterparts. At the API level, this is a direct replacement. At the syntax level, we change the keywords to `bf16`, `f16`, `f32` and `f64`, respectively, to be compatible with the built-in type syntax. The old keywords can still be parsed but produce a deprecation warning and will be eventually removed. Depends On D94178 Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94179
2021-01-06 23:21:08 +08:00
// CHECK: {{.*}} = llvm.fadd %[[FLOAT]], %[[FLOAT]] : f32
// CHECK: {{.*}} = llvm.fsub %[[FLOAT]], %[[FLOAT]] : f32
// CHECK: {{.*}} = llvm.fmul %[[FLOAT]], %[[FLOAT]] : f32
// CHECK: {{.*}} = llvm.fdiv %[[FLOAT]], %[[FLOAT]] : f32
// CHECK: {{.*}} = llvm.frem %[[FLOAT]], %[[FLOAT]] : f32
%8 = llvm.fadd %arg1, %arg1 : f32
%9 = llvm.fsub %arg1, %arg1 : f32
%10 = llvm.fmul %arg1, %arg1 : f32
%11 = llvm.fdiv %arg1, %arg1 : f32
%12 = llvm.frem %arg1, %arg1 : f32
Initial version of the LLVM IR dialect LLVM IR types are defined using MLIR's extendable type system. The dialect provides the only type kind, LLVMType, that wraps an llvm::Type*. Since LLVM IR types are pointer-unique, MLIR type systems relies on those pointers to perform its own type unique'ing. Type parsing and printing is delegated to LLVM libraries. Define MLIR operations for the LLVM IR instructions currently used by the translation to the LLVM IR Target to simplify eventual transition. Operations classes are defined using TableGen. LLVM IR instruction operands that are only allowed to take constant values are accepted as attributes instead. All operations are using verbose form for printing and parsing. PiperOrigin-RevId: 229400375
2019-01-16 02:53:22 +08:00
Replace remaining usages of the Instruction class with Operation. PiperOrigin-RevId: 240777521
2019-03-28 23:24:38 +08:00
// Memory-related operations.
Initial version of the LLVM IR dialect LLVM IR types are defined using MLIR's extendable type system. The dialect provides the only type kind, LLVMType, that wraps an llvm::Type*. Since LLVM IR types are pointer-unique, MLIR type systems relies on those pointers to perform its own type unique'ing. Type parsing and printing is delegated to LLVM libraries. Define MLIR operations for the LLVM IR instructions currently used by the translation to the LLVM IR Target to simplify eventual transition. Operations classes are defined using TableGen. LLVM IR instruction operands that are only allowed to take constant values are accepted as attributes instead. All operations are using verbose form for printing and parsing. PiperOrigin-RevId: 229400375
2019-01-16 02:53:22 +08:00
//
[mlir] replace LLVM dialect float types with built-ins Continue the convergence between LLVM dialect and built-in types by replacing the bfloat, half, float and double LLVM dialect types with their built-in counterparts. At the API level, this is a direct replacement. At the syntax level, we change the keywords to `bf16`, `f16`, `f32` and `f64`, respectively, to be compatible with the built-in type syntax. The old keywords can still be parsed but produce a deprecation warning and will be eventually removed. Depends On D94178 Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94179
2021-01-06 23:21:08 +08:00
// CHECK-NEXT: %[[ALLOCA:.*]] = llvm.alloca %[[I32]] x f64 : (i32) -> !llvm.ptr<f64>
// CHECK-NEXT: %[[GEP:.*]] = llvm.getelementptr %[[ALLOCA]][%[[I32]], %[[I32]]] : (!llvm.ptr<f64>, i32, i32) -> !llvm.ptr<f64>
// CHECK-NEXT: %[[VALUE:.*]] = llvm.load %[[GEP]] : !llvm.ptr<f64>
// CHECK-NEXT: llvm.store %[[VALUE]], %[[ALLOCA]] : !llvm.ptr<f64>
// CHECK-NEXT: %{{.*}} = llvm.bitcast %[[ALLOCA]] : !llvm.ptr<f64> to !llvm.ptr<i64>
%13 = llvm.alloca %arg0 x f64 : (i32) -> !llvm.ptr<f64>
%14 = llvm.getelementptr %13[%arg0, %arg0] : (!llvm.ptr<f64>, i32, i32) -> !llvm.ptr<f64>
%15 = llvm.load %14 : !llvm.ptr<f64>
llvm.store %15, %13 : !llvm.ptr<f64>
%16 = llvm.bitcast %13 : !llvm.ptr<f64> to !llvm.ptr<i64>
Initial version of the LLVM IR dialect LLVM IR types are defined using MLIR's extendable type system. The dialect provides the only type kind, LLVMType, that wraps an llvm::Type*. Since LLVM IR types are pointer-unique, MLIR type systems relies on those pointers to perform its own type unique'ing. Type parsing and printing is delegated to LLVM libraries. Define MLIR operations for the LLVM IR instructions currently used by the translation to the LLVM IR Target to simplify eventual transition. Operations classes are defined using TableGen. LLVM IR instruction operands that are only allowed to take constant values are accepted as attributes instead. All operations are using verbose form for printing and parsing. PiperOrigin-RevId: 229400375
2019-01-16 02:53:22 +08:00
Replace remaining usages of the Instruction class with Operation. PiperOrigin-RevId: 240777521
2019-03-28 23:24:38 +08:00
// Function call-related operations.
Initial version of the LLVM IR dialect LLVM IR types are defined using MLIR's extendable type system. The dialect provides the only type kind, LLVMType, that wraps an llvm::Type*. Since LLVM IR types are pointer-unique, MLIR type systems relies on those pointers to perform its own type unique'ing. Type parsing and printing is delegated to LLVM libraries. Define MLIR operations for the LLVM IR instructions currently used by the translation to the LLVM IR Target to simplify eventual transition. Operations classes are defined using TableGen. LLVM IR instruction operands that are only allowed to take constant values are accepted as attributes instead. All operations are using verbose form for printing and parsing. PiperOrigin-RevId: 229400375
2019-01-16 02:53:22 +08:00
//
[mlir] replace LLVM dialect float types with built-ins Continue the convergence between LLVM dialect and built-in types by replacing the bfloat, half, float and double LLVM dialect types with their built-in counterparts. At the API level, this is a direct replacement. At the syntax level, we change the keywords to `bf16`, `f16`, `f32` and `f64`, respectively, to be compatible with the built-in type syntax. The old keywords can still be parsed but produce a deprecation warning and will be eventually removed. Depends On D94178 Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94179
2021-01-06 23:21:08 +08:00
// CHECK: %[[STRUCT:.*]] = llvm.call @foo(%[[I32]]) : (i32) -> !llvm.struct<(i32, f64, i32)>
// CHECK: %[[VALUE:.*]] = llvm.extractvalue %[[STRUCT]][0] : !llvm.struct<(i32, f64, i32)>
// CHECK: %[[NEW_STRUCT:.*]] = llvm.insertvalue %[[VALUE]], %[[STRUCT]][2] : !llvm.struct<(i32, f64, i32)>
// CHECK: %[[FUNC:.*]] = llvm.mlir.addressof @foo : !llvm.ptr<func<struct<(i32, f64, i32)> (i32)>>
// CHECK: %{{.*}} = llvm.call %[[FUNC]](%[[I32]]) : (i32) -> !llvm.struct<(i32, f64, i32)>
%17 = llvm.call @foo(%arg0) : (i32) -> !llvm.struct<(i32, f64, i32)>
%18 = llvm.extractvalue %17[0] : !llvm.struct<(i32, f64, i32)>
%19 = llvm.insertvalue %18, %17[2] : !llvm.struct<(i32, f64, i32)>
%20 = llvm.mlir.addressof @foo : !llvm.ptr<func<struct<(i32, f64, i32)> (i32)>>
%21 = llvm.call %20(%arg0) : (i32) -> !llvm.struct<(i32, f64, i32)>
Introduce custom format for the LLVM IR Dialect Historically, the LLVM IR dialect has been using the generic form of MLIR operation syntax. It is verbose and often redundant. Introduce the custom printing and parsing for all existing operations in the LLVM IR dialect. Update the relevant documentation and tests. -- PiperOrigin-RevId: 241617393
2019-04-03 06:33:54 +08:00
Initial version of the LLVM IR dialect LLVM IR types are defined using MLIR's extendable type system. The dialect provides the only type kind, LLVMType, that wraps an llvm::Type*. Since LLVM IR types are pointer-unique, MLIR type systems relies on those pointers to perform its own type unique'ing. Type parsing and printing is delegated to LLVM libraries. Define MLIR operations for the LLVM IR instructions currently used by the translation to the LLVM IR Target to simplify eventual transition. Operations classes are defined using TableGen. LLVM IR instruction operands that are only allowed to take constant values are accepted as attributes instead. All operations are using verbose form for printing and parsing. PiperOrigin-RevId: 229400375
2019-01-16 02:53:22 +08:00
Replace remaining usages of the Instruction class with Operation. PiperOrigin-RevId: 240777521
2019-03-28 23:24:38 +08:00
// Terminator operations and their successors.
Initial version of the LLVM IR dialect LLVM IR types are defined using MLIR's extendable type system. The dialect provides the only type kind, LLVMType, that wraps an llvm::Type*. Since LLVM IR types are pointer-unique, MLIR type systems relies on those pointers to perform its own type unique'ing. Type parsing and printing is delegated to LLVM libraries. Define MLIR operations for the LLVM IR instructions currently used by the translation to the LLVM IR Target to simplify eventual transition. Operations classes are defined using TableGen. LLVM IR instruction operands that are only allowed to take constant values are accepted as attributes instead. All operations are using verbose form for printing and parsing. PiperOrigin-RevId: 229400375
2019-01-16 02:53:22 +08:00
//
[mlir] Modernize LLVM dialect rountrip test This test largely predates MLIR testing guidelines. Update it to match the guidelines. In particular, avoid pattern-matching SSA value names, avoid unnecessary CHECK-NEXT, relax assumptions about the form of SSA names. Value-returning operations are still matched agaist _any_ name in order to check that the operation indeed produces values. Differential Revision: https://reviews.llvm.org/D82656
2020-06-26 21:27:46 +08:00
// CHECK: llvm.br ^[[BB1:.*]]
Introduce custom format for the LLVM IR Dialect Historically, the LLVM IR dialect has been using the generic form of MLIR operation syntax. It is verbose and often redundant. Introduce the custom printing and parsing for all existing operations in the LLVM IR dialect. Update the relevant documentation and tests. -- PiperOrigin-RevId: 241617393
2019-04-03 06:33:54 +08:00
llvm.br ^bb1
Initial version of the LLVM IR dialect LLVM IR types are defined using MLIR's extendable type system. The dialect provides the only type kind, LLVMType, that wraps an llvm::Type*. Since LLVM IR types are pointer-unique, MLIR type systems relies on those pointers to perform its own type unique'ing. Type parsing and printing is delegated to LLVM libraries. Define MLIR operations for the LLVM IR instructions currently used by the translation to the LLVM IR Target to simplify eventual transition. Operations classes are defined using TableGen. LLVM IR instruction operands that are only allowed to take constant values are accepted as attributes instead. All operations are using verbose form for printing and parsing. PiperOrigin-RevId: 229400375
2019-01-16 02:53:22 +08:00
[mlir] Modernize LLVM dialect rountrip test This test largely predates MLIR testing guidelines. Update it to match the guidelines. In particular, avoid pattern-matching SSA value names, avoid unnecessary CHECK-NEXT, relax assumptions about the form of SSA names. Value-returning operations are still matched agaist _any_ name in order to check that the operation indeed produces values. Differential Revision: https://reviews.llvm.org/D82656
2020-06-26 21:27:46 +08:00
// CHECK: ^[[BB1]]
Initial version of the LLVM IR dialect LLVM IR types are defined using MLIR's extendable type system. The dialect provides the only type kind, LLVMType, that wraps an llvm::Type*. Since LLVM IR types are pointer-unique, MLIR type systems relies on those pointers to perform its own type unique'ing. Type parsing and printing is delegated to LLVM libraries. Define MLIR operations for the LLVM IR instructions currently used by the translation to the LLVM IR Target to simplify eventual transition. Operations classes are defined using TableGen. LLVM IR instruction operands that are only allowed to take constant values are accepted as attributes instead. All operations are using verbose form for printing and parsing. PiperOrigin-RevId: 229400375
2019-01-16 02:53:22 +08:00
^bb1:
[mlir][LLVMIR] Add 'llvm.switch' op The LLVM IR 'switch' instruction allows control flow to be transferred to one of any number of branches depending on an integer control value, or a default value if the control does not match any branch values. This patch adds `llvm.switch` to the MLIR LLVMIR dialect, as well as translation routines for lowering it to LLVM IR. To store a variable number of operands for a variable number of branch destinations, the new op makes use of the `AttrSizedOperandSegments` trait. It stores its default branch operands as one segment, and all remaining case branches' operands as another. It also stores pairs of begin and end offset values to delineate the sub-range of each case branch's operands. There's probably a better way to implement this, since the offset computation complicates several parts of the op definition. This is the approach I settled on because in doing so I was able to delegate to the default op builder member functions. However, it may be preferable to instead specify `skipDefaultBuilders` in the op's ODS, or use a completely separate approach; feedback is welcome! Another contentious part of this patch may be the custom printer and parser functions for the op. Ideally I would have liked the MLIR to be printed in this way: ``` llvm.switch %0, ^bb1(%1 : !llvm.i32) [ 1: ^bb2, 2: ^bb3(%2, %3 : !llvm.i32, !llvm.i32) ] ``` The above would resemble how LLVM IR is formatted for the 'switch' instruction. But I found it difficult to print and parse something like this, whether I used the declarative assembly format or custom functions. I also was not sure a multi-line format would be welcome -- it seems like most MLIR ops do not use newlines. Again, I'd be happy to hear any feedback here as well, or on any other aspect of the patch. Differential Revision: https://reviews.llvm.org/D93005
2020-12-10 11:37:20 +08:00
// CHECK: llvm.cond_br %7, ^[[BB2:.*]], ^[[BB3:.*]]
llvm.cond_br %7, ^bb2, ^bb3
Initial version of the LLVM IR dialect LLVM IR types are defined using MLIR's extendable type system. The dialect provides the only type kind, LLVMType, that wraps an llvm::Type*. Since LLVM IR types are pointer-unique, MLIR type systems relies on those pointers to perform its own type unique'ing. Type parsing and printing is delegated to LLVM libraries. Define MLIR operations for the LLVM IR instructions currently used by the translation to the LLVM IR Target to simplify eventual transition. Operations classes are defined using TableGen. LLVM IR instruction operands that are only allowed to take constant values are accepted as attributes instead. All operations are using verbose form for printing and parsing. PiperOrigin-RevId: 229400375
2019-01-16 02:53:22 +08:00
[mlir] Modernize LLVM dialect rountrip test This test largely predates MLIR testing guidelines. Update it to match the guidelines. In particular, avoid pattern-matching SSA value names, avoid unnecessary CHECK-NEXT, relax assumptions about the form of SSA names. Value-returning operations are still matched agaist _any_ name in order to check that the operation indeed produces values. Differential Revision: https://reviews.llvm.org/D82656
2020-06-26 21:27:46 +08:00
// CHECK: ^[[BB2]]
Initial version of the LLVM IR dialect LLVM IR types are defined using MLIR's extendable type system. The dialect provides the only type kind, LLVMType, that wraps an llvm::Type*. Since LLVM IR types are pointer-unique, MLIR type systems relies on those pointers to perform its own type unique'ing. Type parsing and printing is delegated to LLVM libraries. Define MLIR operations for the LLVM IR instructions currently used by the translation to the LLVM IR Target to simplify eventual transition. Operations classes are defined using TableGen. LLVM IR instruction operands that are only allowed to take constant values are accepted as attributes instead. All operations are using verbose form for printing and parsing. PiperOrigin-RevId: 229400375
2019-01-16 02:53:22 +08:00
^bb2:
[mlir] replace LLVM dialect float types with built-ins Continue the convergence between LLVM dialect and built-in types by replacing the bfloat, half, float and double LLVM dialect types with their built-in counterparts. At the API level, this is a direct replacement. At the syntax level, we change the keywords to `bf16`, `f16`, `f32` and `f64`, respectively, to be compatible with the built-in type syntax. The old keywords can still be parsed but produce a deprecation warning and will be eventually removed. Depends On D94178 Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94179
2021-01-06 23:21:08 +08:00
// CHECK: %{{.*}} = llvm.mlir.undef : !llvm.struct<(i32, f64, i32)>
[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-06 23:19:04 +08:00
// CHECK: %{{.*}} = llvm.mlir.constant(42 : i64) : i47
[mlir] replace LLVM dialect float types with built-ins Continue the convergence between LLVM dialect and built-in types by replacing the bfloat, half, float and double LLVM dialect types with their built-in counterparts. At the API level, this is a direct replacement. At the syntax level, we change the keywords to `bf16`, `f16`, `f32` and `f64`, respectively, to be compatible with the built-in type syntax. The old keywords can still be parsed but produce a deprecation warning and will be eventually removed. Depends On D94178 Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94179
2021-01-06 23:21:08 +08:00
%22 = llvm.mlir.undef : !llvm.struct<(i32, f64, i32)>
[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-06 23:19:04 +08:00
%23 = llvm.mlir.constant(42) : i47
[mlir][LLVMIR] Add 'llvm.switch' op The LLVM IR 'switch' instruction allows control flow to be transferred to one of any number of branches depending on an integer control value, or a default value if the control does not match any branch values. This patch adds `llvm.switch` to the MLIR LLVMIR dialect, as well as translation routines for lowering it to LLVM IR. To store a variable number of operands for a variable number of branch destinations, the new op makes use of the `AttrSizedOperandSegments` trait. It stores its default branch operands as one segment, and all remaining case branches' operands as another. It also stores pairs of begin and end offset values to delineate the sub-range of each case branch's operands. There's probably a better way to implement this, since the offset computation complicates several parts of the op definition. This is the approach I settled on because in doing so I was able to delegate to the default op builder member functions. However, it may be preferable to instead specify `skipDefaultBuilders` in the op's ODS, or use a completely separate approach; feedback is welcome! Another contentious part of this patch may be the custom printer and parser functions for the op. Ideally I would have liked the MLIR to be printed in this way: ``` llvm.switch %0, ^bb1(%1 : !llvm.i32) [ 1: ^bb2, 2: ^bb3(%2, %3 : !llvm.i32, !llvm.i32) ] ``` The above would resemble how LLVM IR is formatted for the 'switch' instruction. But I found it difficult to print and parse something like this, whether I used the declarative assembly format or custom functions. I also was not sure a multi-line format would be welcome -- it seems like most MLIR ops do not use newlines. Again, I'd be happy to hear any feedback here as well, or on any other aspect of the patch. Differential Revision: https://reviews.llvm.org/D93005
2020-12-10 11:37:20 +08:00
// CHECK: llvm.switch %0, ^[[BB3]] [
// CHECK-NEXT: 1: ^[[BB4:.*]],
// CHECK-NEXT: 2: ^[[BB5:.*]],
// CHECK-NEXT: 3: ^[[BB6:.*]]
// CHECK-NEXT: ]
llvm.switch %0, ^bb3 [
1: ^bb4,
2: ^bb5,
3: ^bb6
]
LLVM IR Dialect: add select op and lower standard select to it This is a similar one-to-one mapping. PiperOrigin-RevId: 233621006
2019-02-13 01:31:20 +08:00
[mlir][LLVMIR] Add 'llvm.switch' op The LLVM IR 'switch' instruction allows control flow to be transferred to one of any number of branches depending on an integer control value, or a default value if the control does not match any branch values. This patch adds `llvm.switch` to the MLIR LLVMIR dialect, as well as translation routines for lowering it to LLVM IR. To store a variable number of operands for a variable number of branch destinations, the new op makes use of the `AttrSizedOperandSegments` trait. It stores its default branch operands as one segment, and all remaining case branches' operands as another. It also stores pairs of begin and end offset values to delineate the sub-range of each case branch's operands. There's probably a better way to implement this, since the offset computation complicates several parts of the op definition. This is the approach I settled on because in doing so I was able to delegate to the default op builder member functions. However, it may be preferable to instead specify `skipDefaultBuilders` in the op's ODS, or use a completely separate approach; feedback is welcome! Another contentious part of this patch may be the custom printer and parser functions for the op. Ideally I would have liked the MLIR to be printed in this way: ``` llvm.switch %0, ^bb1(%1 : !llvm.i32) [ 1: ^bb2, 2: ^bb3(%2, %3 : !llvm.i32, !llvm.i32) ] ``` The above would resemble how LLVM IR is formatted for the 'switch' instruction. But I found it difficult to print and parse something like this, whether I used the declarative assembly format or custom functions. I also was not sure a multi-line format would be welcome -- it seems like most MLIR ops do not use newlines. Again, I'd be happy to hear any feedback here as well, or on any other aspect of the patch. Differential Revision: https://reviews.llvm.org/D93005
2020-12-10 11:37:20 +08:00
// CHECK: ^[[BB3]]
^bb3:
// CHECK: llvm.switch %0, ^[[BB7:.*]] [
// CHECK-NEXT: ]
llvm.switch %0, ^bb7 [
]
// CHECK: ^[[BB4]]
^bb4:
llvm.switch %0, ^bb7 [
]
// CHECK: ^[[BB5]]
^bb5:
llvm.switch %0, ^bb7 [
]
// CHECK: ^[[BB6]]
^bb6:
llvm.switch %0, ^bb7 [
]
// CHECK: ^[[BB7]]
^bb7:
Replace remaining usages of the Instruction class with Operation. PiperOrigin-RevId: 240777521
2019-03-28 23:24:38 +08:00
// Misc operations.
[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-06 23:19:04 +08:00
// CHECK: %{{.*}} = llvm.select %{{.*}}, %{{.*}}, %{{.*}} : i1, i32
%24 = llvm.select %7, %0, %1 : i1, i32
Add LLVM::IntToPtrOp and LLVM::PtrToIntOp to LLVM dialect. -- PiperOrigin-RevId: 249604199
2019-05-23 17:03:14 +08:00
// Integer to pointer and pointer to integer conversions.
//
[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-06 23:19:04 +08:00
// CHECK: %[[PTR:.*]] = llvm.inttoptr %[[I32]] : i32 to !llvm.ptr<i32>
// CHECK: %{{.*}} = llvm.ptrtoint %[[PTR]] : !llvm.ptr<i32> to i32
%25 = llvm.inttoptr %arg0 : i32 to !llvm.ptr<i32>
%26 = llvm.ptrtoint %25 : !llvm.ptr<i32> to i32
Add LLVM::IntToPtrOp and LLVM::PtrToIntOp to LLVM dialect. -- PiperOrigin-RevId: 249604199
2019-05-23 17:03:14 +08:00
Add LLVM IR dialect hooks for FP128 and X86_FP80 types Closes tensorflow/mlir#184 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/184 from schweitzpgi:more-float-types ca27d00510a86ffc9c79c65fb3a0193b5ea097a0 PiperOrigin-RevId: 274288813
2019-10-12 09:35:02 +08:00
// Extended and Quad floating point
//
[mlir] Add better support for f80 and f128 Add builtin f80 and f128 following @schweitz proposition https://llvm.discourse.group/t/rfc-adding-better-support-for-higher-precision-floating-point/2526/5 Reviewed By: ftynse, rriddle Differential Revision: https://reviews.llvm.org/D94737
2021-01-15 23:29:37 +08:00
// CHECK: %{{.*}} = llvm.fpext %[[FLOAT]] : f32 to f80
// CHECK: %{{.*}} = llvm.fpext %[[FLOAT]] : f32 to f128
%27 = llvm.fpext %arg1 : f32 to f80
%28 = llvm.fpext %arg1 : f32 to f128
Add LLVM IR dialect hooks for FP128 and X86_FP80 types Closes tensorflow/mlir#184 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/184 from schweitzpgi:more-float-types ca27d00510a86ffc9c79c65fb3a0193b5ea097a0 PiperOrigin-RevId: 274288813
2019-10-12 09:35:02 +08:00
[mlir] replace LLVM dialect float types with built-ins Continue the convergence between LLVM dialect and built-in types by replacing the bfloat, half, float and double LLVM dialect types with their built-in counterparts. At the API level, this is a direct replacement. At the syntax level, we change the keywords to `bf16`, `f16`, `f32` and `f64`, respectively, to be compatible with the built-in type syntax. The old keywords can still be parsed but produce a deprecation warning and will be eventually removed. Depends On D94178 Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94179
2021-01-06 23:21:08 +08:00
// CHECK: %{{.*}} = llvm.fneg %[[FLOAT]] : f32
%29 = llvm.fneg %arg1 : f32
Add support for the LLVM FNeg instruction Closes tensorflow/mlir#216 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/216 from schweitzpgi:llvmir-fneg-op f9b5f185845d671b745ab6fc213d5d9aff044b34 PiperOrigin-RevId: 278795325
2019-11-06 15:39:25 +08:00
[mlir] replace LLVM dialect float types with built-ins Continue the convergence between LLVM dialect and built-in types by replacing the bfloat, half, float and double LLVM dialect types with their built-in counterparts. At the API level, this is a direct replacement. At the syntax level, we change the keywords to `bf16`, `f16`, `f32` and `f64`, respectively, to be compatible with the built-in type syntax. The old keywords can still be parsed but produce a deprecation warning and will be eventually removed. Depends On D94178 Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94179
2021-01-06 23:21:08 +08:00
// CHECK: "llvm.intr.sin"(%[[FLOAT]]) : (f32) -> f32
%30 = "llvm.intr.sin"(%arg1) : (f32) -> f32
[mlir][StandardToLLVM] Add SinOp to LLVM dialect and lowering of std.sin to this op. Differential Revision: https://reviews.llvm.org/D79505
2020-05-13 14:04:33 +08:00
[mlir] replace LLVM dialect float types with built-ins Continue the convergence between LLVM dialect and built-in types by replacing the bfloat, half, float and double LLVM dialect types with their built-in counterparts. At the API level, this is a direct replacement. At the syntax level, we change the keywords to `bf16`, `f16`, `f32` and `f64`, respectively, to be compatible with the built-in type syntax. The old keywords can still be parsed but produce a deprecation warning and will be eventually removed. Depends On D94178 Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94179
2021-01-06 23:21:08 +08:00
// CHECK: "llvm.intr.pow"(%[[FLOAT]], %[[FLOAT]]) : (f32, f32) -> f32
%31 = "llvm.intr.pow"(%arg1, %arg1) : (f32, f32) -> f32
Added pow intrinsic to LLVMIR dialect Added pow intrinsic to LLVMIR dialect. Added a roundrip test for it. Differential Revision: https://reviews.llvm.org/D80248
2020-05-25 19:42:17 +08:00
[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-06 23:19:04 +08:00
// CHECK: "llvm.intr.bitreverse"(%{{.*}}) : (i32) -> i32
%32 = "llvm.intr.bitreverse"(%arg0) : (i32) -> i32
[MLIR][LLVMDialect] Added bitreverse and ctpop intrinsics Introduced `llvm.intr.bitreverse` and `llvm.intr.ctpop` LLVM bit intrinsics to LLVM dialect. These intrinsics help with SPIR-V to LLVM conversion, allowing a direct mapping from `spv.BitReverse` and `spv.BitCount` respectively. Tests are added to `roundtrip.mlir` and `llvm-intrinsics.mlir`. Differential Revision: https://reviews.llvm.org/D82285
2020-06-24 02:20:42 +08:00
[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-06 23:19:04 +08:00
// CHECK: "llvm.intr.ctpop"(%{{.*}}) : (i32) -> i32
%33 = "llvm.intr.ctpop"(%arg0) : (i32) -> i32
[MLIR][LLVMDialect] Added bitreverse and ctpop intrinsics Introduced `llvm.intr.bitreverse` and `llvm.intr.ctpop` LLVM bit intrinsics to LLVM dialect. These intrinsics help with SPIR-V to LLVM conversion, allowing a direct mapping from `spv.BitReverse` and `spv.BitCount` respectively. Tests are added to `roundtrip.mlir` and `llvm-intrinsics.mlir`. Differential Revision: https://reviews.llvm.org/D82285
2020-06-24 02:20:42 +08:00
[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-06 23:19:04 +08:00
// CHECK: "llvm.intr.memcpy"(%{{.*}}, %{{.*}}, %{{.*}}, %{{.*}}) : (!llvm.ptr<i8>, !llvm.ptr<i8>, i32, i1) -> ()
"llvm.intr.memcpy"(%arg2, %arg3, %arg0, %arg4) : (!llvm.ptr<i8>, !llvm.ptr<i8>, i32, i1) -> ()
[mlir] support returning unranked memrefs Initially, unranked memref descriptors in the LLVM dialect were designed only to be passed into functions. An assertion was guarding against returning unranked memrefs from functions in the standard-to-LLVM conversion. This is insufficient for functions that wish to return an unranked memref such that the caller does not know the rank in advance, and hence cannot allocate the descriptor and pass it in as an argument. Introduce a calling convention for returning unranked memref descriptors as follows. An unranked memref descriptor always points to a ranked memref descriptor stored on stack of the current function. When an unranked memref descriptor is returned from a function, the ranked memref descriptor it points to is copied to dynamically allocated memory, the ownership of which is transferred to the caller. The caller is responsible for deallocating the dynamically allocated memory and for copying the pointed-to ranked memref descriptor onto its stack. Provide default lowerings for std.return, std.call and std.indirect_call that maintain the conversion defined above. This convention is additionally exercised by a runtime test to guard against memory errors. Differential Revision: https://reviews.llvm.org/D82647
2020-06-26 20:34:00 +08:00
[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-06 23:19:04 +08:00
// CHECK: "llvm.intr.memcpy"(%{{.*}}, %{{.*}}, %{{.*}}, %{{.*}}) : (!llvm.ptr<i8>, !llvm.ptr<i8>, i32, i1) -> ()
"llvm.intr.memcpy"(%arg2, %arg3, %arg0, %arg4) : (!llvm.ptr<i8>, !llvm.ptr<i8>, i32, i1) -> ()
[mlir] support returning unranked memrefs Initially, unranked memref descriptors in the LLVM dialect were designed only to be passed into functions. An assertion was guarding against returning unranked memrefs from functions in the standard-to-LLVM conversion. This is insufficient for functions that wish to return an unranked memref such that the caller does not know the rank in advance, and hence cannot allocate the descriptor and pass it in as an argument. Introduce a calling convention for returning unranked memref descriptors as follows. An unranked memref descriptor always points to a ranked memref descriptor stored on stack of the current function. When an unranked memref descriptor is returned from a function, the ranked memref descriptor it points to is copied to dynamically allocated memory, the ownership of which is transferred to the caller. The caller is responsible for deallocating the dynamically allocated memory and for copying the pointed-to ranked memref descriptor onto its stack. Provide default lowerings for std.return, std.call and std.indirect_call that maintain the conversion defined above. This convention is additionally exercised by a runtime test to guard against memory errors. Differential Revision: https://reviews.llvm.org/D82647
2020-06-26 20:34:00 +08:00
// CHECK: %[[SZ:.*]] = llvm.mlir.constant
[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-06 23:19:04 +08:00
%sz = llvm.mlir.constant(10: i64) : i64
// CHECK: "llvm.intr.memcpy.inline"(%{{.*}}, %{{.*}}, %{{.*}}, %{{.*}}) : (!llvm.ptr<i8>, !llvm.ptr<i8>, i64, i1) -> ()
"llvm.intr.memcpy.inline"(%arg2, %arg3, %sz, %arg4) : (!llvm.ptr<i8>, !llvm.ptr<i8>, i64, i1) -> ()
[mlir] support returning unranked memrefs Initially, unranked memref descriptors in the LLVM dialect were designed only to be passed into functions. An assertion was guarding against returning unranked memrefs from functions in the standard-to-LLVM conversion. This is insufficient for functions that wish to return an unranked memref such that the caller does not know the rank in advance, and hence cannot allocate the descriptor and pass it in as an argument. Introduce a calling convention for returning unranked memref descriptors as follows. An unranked memref descriptor always points to a ranked memref descriptor stored on stack of the current function. When an unranked memref descriptor is returned from a function, the ranked memref descriptor it points to is copied to dynamically allocated memory, the ownership of which is transferred to the caller. The caller is responsible for deallocating the dynamically allocated memory and for copying the pointed-to ranked memref descriptor onto its stack. Provide default lowerings for std.return, std.call and std.indirect_call that maintain the conversion defined above. This convention is additionally exercised by a runtime test to guard against memory errors. Differential Revision: https://reviews.llvm.org/D82647
2020-06-26 20:34:00 +08:00
Add LLVM::IntToPtrOp and LLVM::PtrToIntOp to LLVM dialect. -- PiperOrigin-RevId: 249604199
2019-05-23 17:03:14 +08:00
// CHECK: llvm.return
Introduce custom format for the LLVM IR Dialect Historically, the LLVM IR dialect has been using the generic form of MLIR operation syntax. It is verbose and often redundant. Introduce the custom printing and parsing for all existing operations in the LLVM IR dialect. Update the relevant documentation and tests. -- PiperOrigin-RevId: 241617393
2019-04-03 06:33:54 +08:00
llvm.return
Initial version of the LLVM IR dialect LLVM IR types are defined using MLIR's extendable type system. The dialect provides the only type kind, LLVMType, that wraps an llvm::Type*. Since LLVM IR types are pointer-unique, MLIR type systems relies on those pointers to perform its own type unique'ing. Type parsing and printing is delegated to LLVM libraries. Define MLIR operations for the LLVM IR instructions currently used by the translation to the LLVM IR Target to simplify eventual transition. Operations classes are defined using TableGen. LLVM IR instruction operands that are only allowed to take constant values are accepted as attributes instead. All operations are using verbose form for printing and parsing. PiperOrigin-RevId: 229400375
2019-01-16 02:53:22 +08:00
}
// An larger self-contained function.
[mlir] replace LLVM dialect float types with built-ins Continue the convergence between LLVM dialect and built-in types by replacing the bfloat, half, float and double LLVM dialect types with their built-in counterparts. At the API level, this is a direct replacement. At the syntax level, we change the keywords to `bf16`, `f16`, `f32` and `f64`, respectively, to be compatible with the built-in type syntax. The old keywords can still be parsed but produce a deprecation warning and will be eventually removed. Depends On D94178 Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94179
2021-01-06 23:21:08 +08:00
// CHECK-LABEL: llvm.func @foo(%{{.*}}: i32) -> !llvm.struct<(i32, f64, i32)> {
llvm.func @foo(%arg0: i32) -> !llvm.struct<(i32, f64, i32)> {
[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-06 23:19:04 +08:00
// CHECK: %[[V0:.*]] = llvm.mlir.constant(3 : i64) : i32
// CHECK: %[[V1:.*]] = llvm.mlir.constant(3 : i64) : i32
[mlir] replace LLVM dialect float types with built-ins Continue the convergence between LLVM dialect and built-in types by replacing the bfloat, half, float and double LLVM dialect types with their built-in counterparts. At the API level, this is a direct replacement. At the syntax level, we change the keywords to `bf16`, `f16`, `f32` and `f64`, respectively, to be compatible with the built-in type syntax. The old keywords can still be parsed but produce a deprecation warning and will be eventually removed. Depends On D94178 Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94179
2021-01-06 23:21:08 +08:00
// CHECK: %[[V2:.*]] = llvm.mlir.constant(4.200000e+01 : f64) : f64
// CHECK: %[[V3:.*]] = llvm.mlir.constant(4.200000e+01 : f64) : f64
[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-06 23:19:04 +08:00
// CHECK: %[[V4:.*]] = llvm.add %[[V0]], %[[V1]] : i32
// CHECK: %[[V5:.*]] = llvm.mul %[[V4]], %[[V1]] : i32
[mlir] replace LLVM dialect float types with built-ins Continue the convergence between LLVM dialect and built-in types by replacing the bfloat, half, float and double LLVM dialect types with their built-in counterparts. At the API level, this is a direct replacement. At the syntax level, we change the keywords to `bf16`, `f16`, `f32` and `f64`, respectively, to be compatible with the built-in type syntax. The old keywords can still be parsed but produce a deprecation warning and will be eventually removed. Depends On D94178 Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94179
2021-01-06 23:21:08 +08:00
// CHECK: %[[V6:.*]] = llvm.fadd %[[V2]], %[[V3]] : f64
// CHECK: %[[V7:.*]] = llvm.fsub %[[V3]], %[[V6]] : f64
[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-06 23:19:04 +08:00
// CHECK: %[[V8:.*]] = llvm.mlir.constant(1 : i64) : i1
// CHECK: llvm.cond_br %[[V8]], ^[[BB1:.*]](%[[V4]] : i32), ^[[BB2:.*]](%[[V4]] : i32)
%0 = llvm.mlir.constant(3) : i32
%1 = llvm.mlir.constant(3) : i32
[mlir] replace LLVM dialect float types with built-ins Continue the convergence between LLVM dialect and built-in types by replacing the bfloat, half, float and double LLVM dialect types with their built-in counterparts. At the API level, this is a direct replacement. At the syntax level, we change the keywords to `bf16`, `f16`, `f32` and `f64`, respectively, to be compatible with the built-in type syntax. The old keywords can still be parsed but produce a deprecation warning and will be eventually removed. Depends On D94178 Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94179
2021-01-06 23:21:08 +08:00
%2 = llvm.mlir.constant(4.200000e+01) : f64
%3 = llvm.mlir.constant(4.200000e+01) : f64
[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-06 23:19:04 +08:00
%4 = llvm.add %0, %1 : i32
%5 = llvm.mul %4, %1 : i32
[mlir] replace LLVM dialect float types with built-ins Continue the convergence between LLVM dialect and built-in types by replacing the bfloat, half, float and double LLVM dialect types with their built-in counterparts. At the API level, this is a direct replacement. At the syntax level, we change the keywords to `bf16`, `f16`, `f32` and `f64`, respectively, to be compatible with the built-in type syntax. The old keywords can still be parsed but produce a deprecation warning and will be eventually removed. Depends On D94178 Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94179
2021-01-06 23:21:08 +08:00
%6 = llvm.fadd %2, %3 : f64
%7 = llvm.fsub %3, %6 : f64
[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-06 23:19:04 +08:00
%8 = llvm.mlir.constant(1) : i1
llvm.cond_br %8, ^bb1(%4 : i32), ^bb2(%4 : i32)
Introduce custom format for the LLVM IR Dialect Historically, the LLVM IR dialect has been using the generic form of MLIR operation syntax. It is verbose and often redundant. Introduce the custom printing and parsing for all existing operations in the LLVM IR dialect. Update the relevant documentation and tests. -- PiperOrigin-RevId: 241617393
2019-04-03 06:33:54 +08:00
[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-06 23:19:04 +08:00
// CHECK:^[[BB1]](%[[V9:.*]]: i32):
[mlir] replace LLVM dialect float types with built-ins Continue the convergence between LLVM dialect and built-in types by replacing the bfloat, half, float and double LLVM dialect types with their built-in counterparts. At the API level, this is a direct replacement. At the syntax level, we change the keywords to `bf16`, `f16`, `f32` and `f64`, respectively, to be compatible with the built-in type syntax. The old keywords can still be parsed but produce a deprecation warning and will be eventually removed. Depends On D94178 Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94179
2021-01-06 23:21:08 +08:00
// CHECK: %[[V10:.*]] = llvm.call @foo(%[[V9]]) : (i32) -> !llvm.struct<(i32, f64, i32)>
// CHECK: %[[V11:.*]] = llvm.extractvalue %[[V10]][0] : !llvm.struct<(i32, f64, i32)>
// CHECK: %[[V12:.*]] = llvm.extractvalue %[[V10]][1] : !llvm.struct<(i32, f64, i32)>
// CHECK: %[[V13:.*]] = llvm.extractvalue %[[V10]][2] : !llvm.struct<(i32, f64, i32)>
// CHECK: %[[V14:.*]] = llvm.mlir.undef : !llvm.struct<(i32, f64, i32)>
// CHECK: %[[V15:.*]] = llvm.insertvalue %[[V5]], %[[V14]][0] : !llvm.struct<(i32, f64, i32)>
// CHECK: %[[V16:.*]] = llvm.insertvalue %[[V7]], %[[V15]][1] : !llvm.struct<(i32, f64, i32)>
// CHECK: %[[V17:.*]] = llvm.insertvalue %[[V11]], %[[V16]][2] : !llvm.struct<(i32, f64, i32)>
// CHECK: llvm.return %[[V17]] : !llvm.struct<(i32, f64, i32)>
[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-06 23:19:04 +08:00
^bb1(%9: i32):
[mlir] replace LLVM dialect float types with built-ins Continue the convergence between LLVM dialect and built-in types by replacing the bfloat, half, float and double LLVM dialect types with their built-in counterparts. At the API level, this is a direct replacement. At the syntax level, we change the keywords to `bf16`, `f16`, `f32` and `f64`, respectively, to be compatible with the built-in type syntax. The old keywords can still be parsed but produce a deprecation warning and will be eventually removed. Depends On D94178 Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94179
2021-01-06 23:21:08 +08:00
%10 = llvm.call @foo(%9) : (i32) -> !llvm.struct<(i32, f64, i32)>
%11 = llvm.extractvalue %10[0] : !llvm.struct<(i32, f64, i32)>
%12 = llvm.extractvalue %10[1] : !llvm.struct<(i32, f64, i32)>
%13 = llvm.extractvalue %10[2] : !llvm.struct<(i32, f64, i32)>
%14 = llvm.mlir.undef : !llvm.struct<(i32, f64, i32)>
%15 = llvm.insertvalue %5, %14[0] : !llvm.struct<(i32, f64, i32)>
%16 = llvm.insertvalue %7, %15[1] : !llvm.struct<(i32, f64, i32)>
%17 = llvm.insertvalue %11, %16[2] : !llvm.struct<(i32, f64, i32)>
llvm.return %17 : !llvm.struct<(i32, f64, i32)>
Introduce custom format for the LLVM IR Dialect Historically, the LLVM IR dialect has been using the generic form of MLIR operation syntax. It is verbose and often redundant. Introduce the custom printing and parsing for all existing operations in the LLVM IR dialect. Update the relevant documentation and tests. -- PiperOrigin-RevId: 241617393
2019-04-03 06:33:54 +08:00
[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-06 23:19:04 +08:00
// CHECK:^[[BB2]](%[[V18:.*]]: i32):
[mlir] replace LLVM dialect float types with built-ins Continue the convergence between LLVM dialect and built-in types by replacing the bfloat, half, float and double LLVM dialect types with their built-in counterparts. At the API level, this is a direct replacement. At the syntax level, we change the keywords to `bf16`, `f16`, `f32` and `f64`, respectively, to be compatible with the built-in type syntax. The old keywords can still be parsed but produce a deprecation warning and will be eventually removed. Depends On D94178 Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94179
2021-01-06 23:21:08 +08:00
// CHECK: %[[V19:.*]] = llvm.mlir.undef : !llvm.struct<(i32, f64, i32)>
// CHECK: %[[V20:.*]] = llvm.insertvalue %[[V18]], %[[V19]][0] : !llvm.struct<(i32, f64, i32)>
// CHECK: %[[V21:.*]] = llvm.insertvalue %[[V7]], %[[V20]][1] : !llvm.struct<(i32, f64, i32)>
// CHECK: %[[V22:.*]] = llvm.insertvalue %[[V5]], %[[V21]][2] : !llvm.struct<(i32, f64, i32)>
// CHECK: llvm.return %[[V22]] : !llvm.struct<(i32, f64, i32)>
[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-06 23:19:04 +08:00
^bb2(%18: i32):
[mlir] replace LLVM dialect float types with built-ins Continue the convergence between LLVM dialect and built-in types by replacing the bfloat, half, float and double LLVM dialect types with their built-in counterparts. At the API level, this is a direct replacement. At the syntax level, we change the keywords to `bf16`, `f16`, `f32` and `f64`, respectively, to be compatible with the built-in type syntax. The old keywords can still be parsed but produce a deprecation warning and will be eventually removed. Depends On D94178 Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94179
2021-01-06 23:21:08 +08:00
%19 = llvm.mlir.undef : !llvm.struct<(i32, f64, i32)>
%20 = llvm.insertvalue %18, %19[0] : !llvm.struct<(i32, f64, i32)>
%21 = llvm.insertvalue %7, %20[1] : !llvm.struct<(i32, f64, i32)>
%22 = llvm.insertvalue %5, %21[2] : !llvm.struct<(i32, f64, i32)>
llvm.return %22 : !llvm.struct<(i32, f64, i32)>
Initial version of the LLVM IR dialect LLVM IR types are defined using MLIR's extendable type system. The dialect provides the only type kind, LLVMType, that wraps an llvm::Type*. Since LLVM IR types are pointer-unique, MLIR type systems relies on those pointers to perform its own type unique'ing. Type parsing and printing is delegated to LLVM libraries. Define MLIR operations for the LLVM IR instructions currently used by the translation to the LLVM IR Target to simplify eventual transition. Operations classes are defined using TableGen. LLVM IR instruction operands that are only allowed to take constant values are accepted as attributes instead. All operations are using verbose form for printing and parsing. PiperOrigin-RevId: 229400375
2019-01-16 02:53:22 +08:00
}
Introduce std.index_cast and its lowering+translation to LLVM Index types integers of platform-specific bit width. They are used to index memrefs and as loop induction variables, however they could not be obtained from an integer until now, making it virtually impossible to express indirect accesses (given that memrefs of indices are not allowed) or data-dependent loops. Introduce `std.index_cast` to transform indices into integers and vice versa. The semantics of this cast is to sign-extend when casting to a wider integer, and to truncate when casting to a narrower integer. It belongs to StandardOps because both types it operates on are standard types, and because its results are likely to be used in std.load and std.store. Introduce llvm.sext, llvm.zext and llvm.trunc operations to the LLVM dialect. Provide the conversion of `std.index_cast` to llvm.sext or llvm.trunc, depending on the actual bitwidth of `index` known during the conversion. PiperOrigin-RevId: 253624100
2019-06-18 02:35:05 +08:00
// CHECK-LABEL: @casts
[mlir] use built-in vector types instead of LLVM dialect types when possible Continue the convergence between LLVM dialect and built-in types by using the built-in vector type whenever possible, that is for fixed vectors of built-in integers and built-in floats. LLVM dialect vector type is still in use for pointers, less frequent floating point types that do not have a built-in equivalent, and scalable vectors. However, the top-level `LLVMVectorType` class has been removed in favor of free functions capable of inspecting both built-in and LLVM dialect vector types: `LLVM::getVectorElementType`, `LLVM::getNumVectorElements` and `LLVM::getFixedVectorType`. Additional work is necessary to design an implemented the extensions to built-in types so as to remove the `LLVMFixedVectorType` entirely. Note that the default output format for the built-in vectors does not have whitespace around the `x` separator, e.g., `vector<4xf32>` as opposed to the LLVM dialect vector type format that does, e.g., `!llvm.vec<4 x fp128>`. This required changing the FileCheck patterns in several tests. Reviewed By: mehdi_amini, silvas Differential Revision: https://reviews.llvm.org/D94405
2021-01-11 20:58:05 +08:00
// CHECK-SAME: (%[[I32:.*]]: i32, %[[I64:.*]]: i64, %[[V4I32:.*]]: vector<4xi32>, %[[V4I64:.*]]: vector<4xi64>, %[[I32PTR:.*]]: !llvm.ptr<i32>)
func @casts(%arg0: i32, %arg1: i64, %arg2: vector<4xi32>,
%arg3: vector<4xi64>, %arg4: !llvm.ptr<i32>) {
[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-06 23:19:04 +08:00
// CHECK: = llvm.sext %[[I32]] : i32 to i56
%0 = llvm.sext %arg0 : i32 to i56
// CHECK: = llvm.zext %[[I32]] : i32 to i64
%1 = llvm.zext %arg0 : i32 to i64
// CHECK: = llvm.trunc %[[I64]] : i64 to i56
%2 = llvm.trunc %arg1 : i64 to i56
[mlir] use built-in vector types instead of LLVM dialect types when possible Continue the convergence between LLVM dialect and built-in types by using the built-in vector type whenever possible, that is for fixed vectors of built-in integers and built-in floats. LLVM dialect vector type is still in use for pointers, less frequent floating point types that do not have a built-in equivalent, and scalable vectors. However, the top-level `LLVMVectorType` class has been removed in favor of free functions capable of inspecting both built-in and LLVM dialect vector types: `LLVM::getVectorElementType`, `LLVM::getNumVectorElements` and `LLVM::getFixedVectorType`. Additional work is necessary to design an implemented the extensions to built-in types so as to remove the `LLVMFixedVectorType` entirely. Note that the default output format for the built-in vectors does not have whitespace around the `x` separator, e.g., `vector<4xf32>` as opposed to the LLVM dialect vector type format that does, e.g., `!llvm.vec<4 x fp128>`. This required changing the FileCheck patterns in several tests. Reviewed By: mehdi_amini, silvas Differential Revision: https://reviews.llvm.org/D94405
2021-01-11 20:58:05 +08:00
// CHECK: = llvm.sext %[[V4I32]] : vector<4xi32> to vector<4xi56>
%3 = llvm.sext %arg2 : vector<4xi32> to vector<4xi56>
// CHECK: = llvm.zext %[[V4I32]] : vector<4xi32> to vector<4xi64>
%4 = llvm.zext %arg2 : vector<4xi32> to vector<4xi64>
// CHECK: = llvm.trunc %[[V4I64]] : vector<4xi64> to vector<4xi56>
%5 = llvm.trunc %arg3 : vector<4xi64> to vector<4xi56>
[mlir] replace LLVM dialect float types with built-ins Continue the convergence between LLVM dialect and built-in types by replacing the bfloat, half, float and double LLVM dialect types with their built-in counterparts. At the API level, this is a direct replacement. At the syntax level, we change the keywords to `bf16`, `f16`, `f32` and `f64`, respectively, to be compatible with the built-in type syntax. The old keywords can still be parsed but produce a deprecation warning and will be eventually removed. Depends On D94178 Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94179
2021-01-06 23:21:08 +08:00
// CHECK: = llvm.sitofp %[[I32]] : i32 to f32
%6 = llvm.sitofp %arg0 : i32 to f32
// CHECK: %[[FLOAT:.*]] = llvm.uitofp %[[I32]] : i32 to f32
%7 = llvm.uitofp %arg0 : i32 to f32
// CHECK: = llvm.fptosi %[[FLOAT]] : f32 to i32
%8 = llvm.fptosi %7 : f32 to i32
// CHECK: = llvm.fptoui %[[FLOAT]] : f32 to i32
%9 = llvm.fptoui %7 : f32 to i32
[mlir] switch the modeling of LLVM types to use the new mechanism A new first-party modeling for LLVM IR types in the LLVM dialect has been developed in parallel to the existing modeling based on wrapping LLVM `Type *` instances. It resolves the long-standing problem of modeling identified structure types, including recursive structures, and enables future removal of LLVMContext and related locking mechanisms from LLVMDialect. This commit only switches the modeling by (a) renaming LLVMTypeNew to LLVMType, (b) removing the old implementaiton of LLVMType, and (c) updating the tests. It is intentionally minimal. Separate commits will remove the infrastructure built for the transition and update API uses where appropriate. Depends On D85020 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D85021
2020-08-04 17:37:50 +08:00
// CHECK: = llvm.addrspacecast %[[I32PTR]] : !llvm.ptr<i32> to !llvm.ptr<i32, 2>
%10 = llvm.addrspacecast %arg4 : !llvm.ptr<i32> to !llvm.ptr<i32, 2>
Introduce std.index_cast and its lowering+translation to LLVM Index types integers of platform-specific bit width. They are used to index memrefs and as loop induction variables, however they could not be obtained from an integer until now, making it virtually impossible to express indirect accesses (given that memrefs of indices are not allowed) or data-dependent loops. Introduce `std.index_cast` to transform indices into integers and vice versa. The semantics of this cast is to sign-extend when casting to a wider integer, and to truncate when casting to a narrower integer. It belongs to StandardOps because both types it operates on are standard types, and because its results are likely to be used in std.load and std.store. Introduce llvm.sext, llvm.zext and llvm.trunc operations to the LLVM dialect. Provide the conversion of `std.index_cast` to llvm.sext or llvm.trunc, depending on the actual bitwidth of `index` known during the conversion. PiperOrigin-RevId: 253624100
2019-06-18 02:35:05 +08:00
llvm.return
}
Add support for vector ops in the LLVM dialect This CL is step 1/n towards building a simple, programmable and portable vector abstraction in MLIR that can go all the way down to generating assembly vector code via LLVM's opt and llc tools. This CL adds the 3 instructions `llvm.extractelement`, `llvm.insertelement` and `llvm.shufflevector` as documented in the LLVM LangRef "Vector Instructions" section. The "Experimental Vector Reduction Intrinsics" are left out for now and can be added in the future on a per-need basis. Appropriate roundtrip and LLVM Target tests are added. PiperOrigin-RevId: 262542095
2019-08-09 20:24:47 +08:00
// CHECK-LABEL: @vect
[mlir] use built-in vector types instead of LLVM dialect types when possible Continue the convergence between LLVM dialect and built-in types by using the built-in vector type whenever possible, that is for fixed vectors of built-in integers and built-in floats. LLVM dialect vector type is still in use for pointers, less frequent floating point types that do not have a built-in equivalent, and scalable vectors. However, the top-level `LLVMVectorType` class has been removed in favor of free functions capable of inspecting both built-in and LLVM dialect vector types: `LLVM::getVectorElementType`, `LLVM::getNumVectorElements` and `LLVM::getFixedVectorType`. Additional work is necessary to design an implemented the extensions to built-in types so as to remove the `LLVMFixedVectorType` entirely. Note that the default output format for the built-in vectors does not have whitespace around the `x` separator, e.g., `vector<4xf32>` as opposed to the LLVM dialect vector type format that does, e.g., `!llvm.vec<4 x fp128>`. This required changing the FileCheck patterns in several tests. Reviewed By: mehdi_amini, silvas Differential Revision: https://reviews.llvm.org/D94405
2021-01-11 20:58:05 +08:00
func @vect(%arg0: vector<4xf32>, %arg1: i32, %arg2: f32) {
// CHECK: = llvm.extractelement {{.*}} : vector<4xf32>
%0 = llvm.extractelement %arg0[%arg1 : i32] : vector<4xf32>
// CHECK: = llvm.insertelement {{.*}} : vector<4xf32>
%1 = llvm.insertelement %arg2, %arg0[%arg1 : i32] : vector<4xf32>
// CHECK: = llvm.shufflevector {{.*}} [0 : i32, 0 : i32, 0 : i32, 0 : i32, 7 : i32] : vector<4xf32>, vector<4xf32>
%2 = llvm.shufflevector %arg0, %arg0 [0 : i32, 0 : i32, 0 : i32, 0 : i32, 7 : i32] : vector<4xf32>, vector<4xf32>
// CHECK: = llvm.mlir.constant(dense<1.000000e+00> : vector<4xf32>) : vector<4xf32>
%3 = llvm.mlir.constant(dense<1.0> : vector<4xf32>) : vector<4xf32>
Add support for vector ops in the LLVM dialect This CL is step 1/n towards building a simple, programmable and portable vector abstraction in MLIR that can go all the way down to generating assembly vector code via LLVM's opt and llc tools. This CL adds the 3 instructions `llvm.extractelement`, `llvm.insertelement` and `llvm.shufflevector` as documented in the LLVM LangRef "Vector Instructions" section. The "Experimental Vector Reduction Intrinsics" are left out for now and can be added in the future on a per-need basis. Appropriate roundtrip and LLVM Target tests are added. PiperOrigin-RevId: 262542095
2019-08-09 20:24:47 +08:00
return
}
Add alignment support for llvm.alloca Extend the LLVM dialect AllocaOp with an alignment attribute. PiperOrigin-RevId: 264068306
2019-08-19 09:54:50 +08:00
// CHECK-LABEL: @alloca
[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-06 23:19:04 +08:00
func @alloca(%size : i64) {
// CHECK: llvm.alloca %{{.*}} x i32 : (i64) -> !llvm.ptr<i32>
llvm.alloca %size x i32 {alignment = 0} : (i64) -> (!llvm.ptr<i32>)
// CHECK: llvm.alloca %{{.*}} x i32 {alignment = 8 : i64} : (i64) -> !llvm.ptr<i32>
llvm.alloca %size x i32 {alignment = 8} : (i64) -> (!llvm.ptr<i32>)
Add alignment support for llvm.alloca Extend the LLVM dialect AllocaOp with an alignment attribute. PiperOrigin-RevId: 264068306
2019-08-19 09:54:50 +08:00
llvm.return
}
LLVM Dialect: introduce llvm.mlir.null operation Similarly to `llvm.mlir.undef`, this auxiliary operation creates an SSA value that corresponds to `null` in LLVM IR. This operation is necessary to model sizeof(<...>) behavior when allocating memory. PiperOrigin-RevId: 274158760
2019-10-11 21:13:25 +08:00
// CHECK-LABEL: @null
func @null() {
[mlir] switch the modeling of LLVM types to use the new mechanism A new first-party modeling for LLVM IR types in the LLVM dialect has been developed in parallel to the existing modeling based on wrapping LLVM `Type *` instances. It resolves the long-standing problem of modeling identified structure types, including recursive structures, and enables future removal of LLVMContext and related locking mechanisms from LLVMDialect. This commit only switches the modeling by (a) renaming LLVMTypeNew to LLVMType, (b) removing the old implementaiton of LLVMType, and (c) updating the tests. It is intentionally minimal. Separate commits will remove the infrastructure built for the transition and update API uses where appropriate. Depends On D85020 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D85021
2020-08-04 17:37:50 +08:00
// CHECK: llvm.mlir.null : !llvm.ptr<i8>
%0 = llvm.mlir.null : !llvm.ptr<i8>
// CHECK: llvm.mlir.null : !llvm.ptr<struct<(ptr<func<void (i32, ptr<func<void ()>>)>>, i64)>>
%1 = llvm.mlir.null : !llvm.ptr<struct<(ptr<func<void (i32, ptr<func<void ()>>)>>, i64)>>
LLVM Dialect: introduce llvm.mlir.null operation Similarly to `llvm.mlir.undef`, this auxiliary operation creates an SSA value that corresponds to `null` in LLVM IR. This operation is necessary to model sizeof(<...>) behavior when allocating memory. PiperOrigin-RevId: 274158760
2019-10-11 21:13:25 +08:00
llvm.return
}
[MLIR] LLVM dialect: Add llvm.atomicrmw Summary: This op is the counterpart to LLVM's atomicrmw instruction. Note that volatile and syncscope attributes are not yet supported. This will be useful for upcoming parallel versions of `affine.for` and generally for reduction-like semantics. Differential Revision: https://reviews.llvm.org/D72741
2020-01-18 04:09:53 +08:00
[MLIR] LLVM Dialect: add llvm.cmpxchg and improve llvm.atomicrmw custom parser Summary: Add a `llvm.cmpxchg` op as a counterpart to LLVM IR's `cmpxchg` instruction. Note that the `weak`, `volatile`, and `syncscope` attributes are not yet supported. This will be useful for upcoming parallel versions of affine.for and generally for reduction-like semantics (especially for reductions that can't make use of `atomicrmw`, e.g. `fmax`). Reviewers: ftynse, nicolasvasilache Reviewed By: ftynse Subscribers: merge_guards_bot, jfb, mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, arpith-jacob, mgester, lucyrfox, liufengdb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D72995
2020-01-21 16:22:01 +08:00
// CHECK-LABEL: @atomicrmw
[mlir] replace LLVM dialect float types with built-ins Continue the convergence between LLVM dialect and built-in types by replacing the bfloat, half, float and double LLVM dialect types with their built-in counterparts. At the API level, this is a direct replacement. At the syntax level, we change the keywords to `bf16`, `f16`, `f32` and `f64`, respectively, to be compatible with the built-in type syntax. The old keywords can still be parsed but produce a deprecation warning and will be eventually removed. Depends On D94178 Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94179
2021-01-06 23:21:08 +08:00
func @atomicrmw(%ptr : !llvm.ptr<f32>, %val : f32) {
[mlir] tighten LLVM dialect verifiers to generate valid LLVM IR Verification of the LLVM IR produced when translating various MLIR dialects was only active when calling the translation programmatically. This has led to several cases of invalid LLVM IR being generated that could not be caught with textual mlir-translate tests. Add verifiers for these cases and fix the tests in preparation for enforcing the validation of LLVM IR. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D96774
2021-02-17 00:36:20 +08:00
// CHECK: llvm.atomicrmw fadd %{{.*}}, %{{.*}} monotonic : f32
%0 = llvm.atomicrmw fadd %ptr, %val monotonic : f32
[MLIR] LLVM Dialect: add llvm.cmpxchg and improve llvm.atomicrmw custom parser Summary: Add a `llvm.cmpxchg` op as a counterpart to LLVM IR's `cmpxchg` instruction. Note that the `weak`, `volatile`, and `syncscope` attributes are not yet supported. This will be useful for upcoming parallel versions of affine.for and generally for reduction-like semantics (especially for reductions that can't make use of `atomicrmw`, e.g. `fmax`). Reviewers: ftynse, nicolasvasilache Reviewed By: ftynse Subscribers: merge_guards_bot, jfb, mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, arpith-jacob, mgester, lucyrfox, liufengdb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D72995
2020-01-21 16:22:01 +08:00
llvm.return
}
// CHECK-LABEL: @cmpxchg
[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-06 23:19:04 +08:00
func @cmpxchg(%ptr : !llvm.ptr<i32>, %cmp : i32, %new : i32) {
// CHECK: llvm.cmpxchg %{{.*}}, %{{.*}}, %{{.*}} acq_rel monotonic : i32
%0 = llvm.cmpxchg %ptr, %cmp, %new acq_rel monotonic : i32
[MLIR] LLVM dialect: Add llvm.atomicrmw Summary: This op is the counterpart to LLVM's atomicrmw instruction. Note that volatile and syncscope attributes are not yet supported. This will be useful for upcoming parallel versions of `affine.for` and generally for reduction-like semantics. Differential Revision: https://reviews.llvm.org/D72741
2020-01-18 04:09:53 +08:00
llvm.return
}
[MLIR] Added llvm.invoke and llvm.landingpad Summary: I have tried to implement `llvm.invoke` and `llvm.landingpad`. # `llvm.invoke` is similar to `llvm.call` with two successors added, the first one is the normal label and the second one is unwind label. # `llvm.launchpad` takes a variable number of args with either `catch` or `filter` associated with them. Catch clauses are not array types and filter clauses are array types. This is same as the criteria used by LLVM (https://github.com/llvm/llvm-project/blob/4f82af81a04d711721300f6ca32f402f2ea6faf4/llvm/include/llvm/IR/Instructions.h#L2866) Examples: LLVM IR ``` define i32 @caller(i32 %a) personality i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*) { invoke i32 @foo(i32 2) to label %success unwind label %fail success: ret i32 2 fail: landingpad {i8*, i32} catch i8** @_ZTIi catch i8** null catch i8* bitcast (i8** @_ZTIi to i8*) filter [1 x i8] [ i8 1 ] ret i32 3 } ``` MLIR LLVM Dialect ``` llvm.func @caller(%arg0: !llvm.i32) -> !llvm.i32 { %0 = llvm.mlir.constant(3 : i32) : !llvm.i32 %1 = llvm.mlir.constant("\01") : !llvm<"[1 x i8]"> %2 = llvm.mlir.addressof @_ZTIi : !llvm<"i8**"> %3 = llvm.bitcast %2 : !llvm<"i8**"> to !llvm<"i8*"> %4 = llvm.mlir.null : !llvm<"i8**"> %5 = llvm.mlir.addressof @_ZTIi : !llvm<"i8**"> %6 = llvm.mlir.constant(2 : i32) : !llvm.i32 %7 = llvm.invoke @foo(%6) to ^bb1 unwind ^bb2 : (!llvm.i32) -> !llvm.i32 ^bb1: // pred: ^bb0 llvm.return %6 : !llvm.i32 ^bb2: // pred: ^bb0 %8 = llvm.landingpad (catch %5 : !llvm<"i8**">) (catch %4 : !llvm<"i8**">) (catch %3 : !llvm<"i8*">) (filter %1 : !llvm<"[1 x i8]">) : !llvm<"{ i8*, i32 }"> llvm.return %0 : !llvm.i32 } ``` Signed-off-by: Shraiysh Vaishay <cs17btech11050@iith.ac.in> Differential Revision: https://reviews.llvm.org/D72006
2020-01-30 19:50:12 +08:00
[mlir] switch the modeling of LLVM types to use the new mechanism A new first-party modeling for LLVM IR types in the LLVM dialect has been developed in parallel to the existing modeling based on wrapping LLVM `Type *` instances. It resolves the long-standing problem of modeling identified structure types, including recursive structures, and enables future removal of LLVMContext and related locking mechanisms from LLVMDialect. This commit only switches the modeling by (a) renaming LLVMTypeNew to LLVMType, (b) removing the old implementaiton of LLVMType, and (c) updating the tests. It is intentionally minimal. Separate commits will remove the infrastructure built for the transition and update API uses where appropriate. Depends On D85020 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D85021
2020-08-04 17:37:50 +08:00
llvm.mlir.global external constant @_ZTIi() : !llvm.ptr<i8>
llvm.func @bar(!llvm.ptr<i8>, !llvm.ptr<i8>, !llvm.ptr<i8>)
[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-06 23:19:04 +08:00
llvm.func @__gxx_personality_v0(...) -> i32
[MLIR] Added llvm.invoke and llvm.landingpad Summary: I have tried to implement `llvm.invoke` and `llvm.landingpad`. # `llvm.invoke` is similar to `llvm.call` with two successors added, the first one is the normal label and the second one is unwind label. # `llvm.launchpad` takes a variable number of args with either `catch` or `filter` associated with them. Catch clauses are not array types and filter clauses are array types. This is same as the criteria used by LLVM (https://github.com/llvm/llvm-project/blob/4f82af81a04d711721300f6ca32f402f2ea6faf4/llvm/include/llvm/IR/Instructions.h#L2866) Examples: LLVM IR ``` define i32 @caller(i32 %a) personality i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*) { invoke i32 @foo(i32 2) to label %success unwind label %fail success: ret i32 2 fail: landingpad {i8*, i32} catch i8** @_ZTIi catch i8** null catch i8* bitcast (i8** @_ZTIi to i8*) filter [1 x i8] [ i8 1 ] ret i32 3 } ``` MLIR LLVM Dialect ``` llvm.func @caller(%arg0: !llvm.i32) -> !llvm.i32 { %0 = llvm.mlir.constant(3 : i32) : !llvm.i32 %1 = llvm.mlir.constant("\01") : !llvm<"[1 x i8]"> %2 = llvm.mlir.addressof @_ZTIi : !llvm<"i8**"> %3 = llvm.bitcast %2 : !llvm<"i8**"> to !llvm<"i8*"> %4 = llvm.mlir.null : !llvm<"i8**"> %5 = llvm.mlir.addressof @_ZTIi : !llvm<"i8**"> %6 = llvm.mlir.constant(2 : i32) : !llvm.i32 %7 = llvm.invoke @foo(%6) to ^bb1 unwind ^bb2 : (!llvm.i32) -> !llvm.i32 ^bb1: // pred: ^bb0 llvm.return %6 : !llvm.i32 ^bb2: // pred: ^bb0 %8 = llvm.landingpad (catch %5 : !llvm<"i8**">) (catch %4 : !llvm<"i8**">) (catch %3 : !llvm<"i8*">) (filter %1 : !llvm<"[1 x i8]">) : !llvm<"{ i8*, i32 }"> llvm.return %0 : !llvm.i32 } ``` Signed-off-by: Shraiysh Vaishay <cs17btech11050@iith.ac.in> Differential Revision: https://reviews.llvm.org/D72006
2020-01-30 19:50:12 +08:00
// CHECK-LABEL: @invokeLandingpad
[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-06 23:19:04 +08:00
llvm.func @invokeLandingpad() -> i32 attributes { personality = @__gxx_personality_v0 } {
// CHECK: %[[a0:.*]] = llvm.mlir.constant(0 : i32) : i32
// CHECK: %{{.*}} = llvm.mlir.constant(3 : i32) : i32
[mlir] switch the modeling of LLVM types to use the new mechanism A new first-party modeling for LLVM IR types in the LLVM dialect has been developed in parallel to the existing modeling based on wrapping LLVM `Type *` instances. It resolves the long-standing problem of modeling identified structure types, including recursive structures, and enables future removal of LLVMContext and related locking mechanisms from LLVMDialect. This commit only switches the modeling by (a) renaming LLVMTypeNew to LLVMType, (b) removing the old implementaiton of LLVMType, and (c) updating the tests. It is intentionally minimal. Separate commits will remove the infrastructure built for the transition and update API uses where appropriate. Depends On D85020 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D85021
2020-08-04 17:37:50 +08:00
// CHECK: %[[a2:.*]] = llvm.mlir.constant("\01") : !llvm.array<1 x i8>
// CHECK: %[[a3:.*]] = llvm.mlir.null : !llvm.ptr<ptr<i8>>
// CHECK: %[[a4:.*]] = llvm.mlir.null : !llvm.ptr<i8>
// CHECK: %[[a5:.*]] = llvm.mlir.addressof @_ZTIi : !llvm.ptr<ptr<i8>>
// CHECK: %[[a6:.*]] = llvm.bitcast %[[a5]] : !llvm.ptr<ptr<i8>> to !llvm.ptr<i8>
[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-06 23:19:04 +08:00
// CHECK: %[[a7:.*]] = llvm.mlir.constant(1 : i32) : i32
// CHECK: %[[a8:.*]] = llvm.alloca %[[a7]] x i8 : (i32) -> !llvm.ptr<i8>
[mlir] replace LLVM dialect float types with built-ins Continue the convergence between LLVM dialect and built-in types by replacing the bfloat, half, float and double LLVM dialect types with their built-in counterparts. At the API level, this is a direct replacement. At the syntax level, we change the keywords to `bf16`, `f16`, `f32` and `f64`, respectively, to be compatible with the built-in type syntax. The old keywords can still be parsed but produce a deprecation warning and will be eventually removed. Depends On D94178 Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94179
2021-01-06 23:21:08 +08:00
// CHECK: %{{.*}} = llvm.invoke @foo(%[[a7]]) to ^[[BB2:.*]] unwind ^[[BB1:.*]] : (i32) -> !llvm.struct<(i32, f64, i32)>
[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-06 23:19:04 +08:00
%0 = llvm.mlir.constant(0 : i32) : i32
%1 = llvm.mlir.constant(3 : i32) : i32
[mlir] switch the modeling of LLVM types to use the new mechanism A new first-party modeling for LLVM IR types in the LLVM dialect has been developed in parallel to the existing modeling based on wrapping LLVM `Type *` instances. It resolves the long-standing problem of modeling identified structure types, including recursive structures, and enables future removal of LLVMContext and related locking mechanisms from LLVMDialect. This commit only switches the modeling by (a) renaming LLVMTypeNew to LLVMType, (b) removing the old implementaiton of LLVMType, and (c) updating the tests. It is intentionally minimal. Separate commits will remove the infrastructure built for the transition and update API uses where appropriate. Depends On D85020 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D85021
2020-08-04 17:37:50 +08:00
%2 = llvm.mlir.constant("\01") : !llvm.array<1 x i8>
%3 = llvm.mlir.null : !llvm.ptr<ptr<i8>>
%4 = llvm.mlir.null : !llvm.ptr<i8>
%5 = llvm.mlir.addressof @_ZTIi : !llvm.ptr<ptr<i8>>
%6 = llvm.bitcast %5 : !llvm.ptr<ptr<i8>> to !llvm.ptr<i8>
[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-06 23:19:04 +08:00
%7 = llvm.mlir.constant(1 : i32) : i32
%8 = llvm.alloca %7 x i8 : (i32) -> !llvm.ptr<i8>
[mlir] replace LLVM dialect float types with built-ins Continue the convergence between LLVM dialect and built-in types by replacing the bfloat, half, float and double LLVM dialect types with their built-in counterparts. At the API level, this is a direct replacement. At the syntax level, we change the keywords to `bf16`, `f16`, `f32` and `f64`, respectively, to be compatible with the built-in type syntax. The old keywords can still be parsed but produce a deprecation warning and will be eventually removed. Depends On D94178 Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94179
2021-01-06 23:21:08 +08:00
%9 = llvm.invoke @foo(%7) to ^bb2 unwind ^bb1 : (i32) -> !llvm.struct<(i32, f64, i32)>
[MLIR] Added llvm.invoke and llvm.landingpad Summary: I have tried to implement `llvm.invoke` and `llvm.landingpad`. # `llvm.invoke` is similar to `llvm.call` with two successors added, the first one is the normal label and the second one is unwind label. # `llvm.launchpad` takes a variable number of args with either `catch` or `filter` associated with them. Catch clauses are not array types and filter clauses are array types. This is same as the criteria used by LLVM (https://github.com/llvm/llvm-project/blob/4f82af81a04d711721300f6ca32f402f2ea6faf4/llvm/include/llvm/IR/Instructions.h#L2866) Examples: LLVM IR ``` define i32 @caller(i32 %a) personality i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*) { invoke i32 @foo(i32 2) to label %success unwind label %fail success: ret i32 2 fail: landingpad {i8*, i32} catch i8** @_ZTIi catch i8** null catch i8* bitcast (i8** @_ZTIi to i8*) filter [1 x i8] [ i8 1 ] ret i32 3 } ``` MLIR LLVM Dialect ``` llvm.func @caller(%arg0: !llvm.i32) -> !llvm.i32 { %0 = llvm.mlir.constant(3 : i32) : !llvm.i32 %1 = llvm.mlir.constant("\01") : !llvm<"[1 x i8]"> %2 = llvm.mlir.addressof @_ZTIi : !llvm<"i8**"> %3 = llvm.bitcast %2 : !llvm<"i8**"> to !llvm<"i8*"> %4 = llvm.mlir.null : !llvm<"i8**"> %5 = llvm.mlir.addressof @_ZTIi : !llvm<"i8**"> %6 = llvm.mlir.constant(2 : i32) : !llvm.i32 %7 = llvm.invoke @foo(%6) to ^bb1 unwind ^bb2 : (!llvm.i32) -> !llvm.i32 ^bb1: // pred: ^bb0 llvm.return %6 : !llvm.i32 ^bb2: // pred: ^bb0 %8 = llvm.landingpad (catch %5 : !llvm<"i8**">) (catch %4 : !llvm<"i8**">) (catch %3 : !llvm<"i8*">) (filter %1 : !llvm<"[1 x i8]">) : !llvm<"{ i8*, i32 }"> llvm.return %0 : !llvm.i32 } ``` Signed-off-by: Shraiysh Vaishay <cs17btech11050@iith.ac.in> Differential Revision: https://reviews.llvm.org/D72006
2020-01-30 19:50:12 +08:00
[mlir] Modernize LLVM dialect rountrip test This test largely predates MLIR testing guidelines. Update it to match the guidelines. In particular, avoid pattern-matching SSA value names, avoid unnecessary CHECK-NEXT, relax assumptions about the form of SSA names. Value-returning operations are still matched agaist _any_ name in order to check that the operation indeed produces values. Differential Revision: https://reviews.llvm.org/D82656
2020-06-26 21:27:46 +08:00
// CHECK: ^[[BB1]]:
[mlir] switch the modeling of LLVM types to use the new mechanism A new first-party modeling for LLVM IR types in the LLVM dialect has been developed in parallel to the existing modeling based on wrapping LLVM `Type *` instances. It resolves the long-standing problem of modeling identified structure types, including recursive structures, and enables future removal of LLVMContext and related locking mechanisms from LLVMDialect. This commit only switches the modeling by (a) renaming LLVMTypeNew to LLVMType, (b) removing the old implementaiton of LLVMType, and (c) updating the tests. It is intentionally minimal. Separate commits will remove the infrastructure built for the transition and update API uses where appropriate. Depends On D85020 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D85021
2020-08-04 17:37:50 +08:00
// CHECK: %[[lp:.*]] = llvm.landingpad cleanup (catch %[[a3]] : !llvm.ptr<ptr<i8>>) (catch %[[a6]] : !llvm.ptr<i8>) (filter %[[a2]] : !llvm.array<1 x i8>) : !llvm.struct<(ptr<i8>, i32)>
// CHECK: llvm.resume %[[lp]] : !llvm.struct<(ptr<i8>, i32)>
[MLIR] Added llvm.invoke and llvm.landingpad Summary: I have tried to implement `llvm.invoke` and `llvm.landingpad`. # `llvm.invoke` is similar to `llvm.call` with two successors added, the first one is the normal label and the second one is unwind label. # `llvm.launchpad` takes a variable number of args with either `catch` or `filter` associated with them. Catch clauses are not array types and filter clauses are array types. This is same as the criteria used by LLVM (https://github.com/llvm/llvm-project/blob/4f82af81a04d711721300f6ca32f402f2ea6faf4/llvm/include/llvm/IR/Instructions.h#L2866) Examples: LLVM IR ``` define i32 @caller(i32 %a) personality i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*) { invoke i32 @foo(i32 2) to label %success unwind label %fail success: ret i32 2 fail: landingpad {i8*, i32} catch i8** @_ZTIi catch i8** null catch i8* bitcast (i8** @_ZTIi to i8*) filter [1 x i8] [ i8 1 ] ret i32 3 } ``` MLIR LLVM Dialect ``` llvm.func @caller(%arg0: !llvm.i32) -> !llvm.i32 { %0 = llvm.mlir.constant(3 : i32) : !llvm.i32 %1 = llvm.mlir.constant("\01") : !llvm<"[1 x i8]"> %2 = llvm.mlir.addressof @_ZTIi : !llvm<"i8**"> %3 = llvm.bitcast %2 : !llvm<"i8**"> to !llvm<"i8*"> %4 = llvm.mlir.null : !llvm<"i8**"> %5 = llvm.mlir.addressof @_ZTIi : !llvm<"i8**"> %6 = llvm.mlir.constant(2 : i32) : !llvm.i32 %7 = llvm.invoke @foo(%6) to ^bb1 unwind ^bb2 : (!llvm.i32) -> !llvm.i32 ^bb1: // pred: ^bb0 llvm.return %6 : !llvm.i32 ^bb2: // pred: ^bb0 %8 = llvm.landingpad (catch %5 : !llvm<"i8**">) (catch %4 : !llvm<"i8**">) (catch %3 : !llvm<"i8*">) (filter %1 : !llvm<"[1 x i8]">) : !llvm<"{ i8*, i32 }"> llvm.return %0 : !llvm.i32 } ``` Signed-off-by: Shraiysh Vaishay <cs17btech11050@iith.ac.in> Differential Revision: https://reviews.llvm.org/D72006
2020-01-30 19:50:12 +08:00
^bb1:
[mlir] switch the modeling of LLVM types to use the new mechanism A new first-party modeling for LLVM IR types in the LLVM dialect has been developed in parallel to the existing modeling based on wrapping LLVM `Type *` instances. It resolves the long-standing problem of modeling identified structure types, including recursive structures, and enables future removal of LLVMContext and related locking mechanisms from LLVMDialect. This commit only switches the modeling by (a) renaming LLVMTypeNew to LLVMType, (b) removing the old implementaiton of LLVMType, and (c) updating the tests. It is intentionally minimal. Separate commits will remove the infrastructure built for the transition and update API uses where appropriate. Depends On D85020 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D85021
2020-08-04 17:37:50 +08:00
%10 = llvm.landingpad cleanup (catch %3 : !llvm.ptr<ptr<i8>>) (catch %6 : !llvm.ptr<i8>) (filter %2 : !llvm.array<1 x i8>) : !llvm.struct<(ptr<i8>, i32)>
llvm.resume %10 : !llvm.struct<(ptr<i8>, i32)>
[MLIR] Added llvm.invoke and llvm.landingpad Summary: I have tried to implement `llvm.invoke` and `llvm.landingpad`. # `llvm.invoke` is similar to `llvm.call` with two successors added, the first one is the normal label and the second one is unwind label. # `llvm.launchpad` takes a variable number of args with either `catch` or `filter` associated with them. Catch clauses are not array types and filter clauses are array types. This is same as the criteria used by LLVM (https://github.com/llvm/llvm-project/blob/4f82af81a04d711721300f6ca32f402f2ea6faf4/llvm/include/llvm/IR/Instructions.h#L2866) Examples: LLVM IR ``` define i32 @caller(i32 %a) personality i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*) { invoke i32 @foo(i32 2) to label %success unwind label %fail success: ret i32 2 fail: landingpad {i8*, i32} catch i8** @_ZTIi catch i8** null catch i8* bitcast (i8** @_ZTIi to i8*) filter [1 x i8] [ i8 1 ] ret i32 3 } ``` MLIR LLVM Dialect ``` llvm.func @caller(%arg0: !llvm.i32) -> !llvm.i32 { %0 = llvm.mlir.constant(3 : i32) : !llvm.i32 %1 = llvm.mlir.constant("\01") : !llvm<"[1 x i8]"> %2 = llvm.mlir.addressof @_ZTIi : !llvm<"i8**"> %3 = llvm.bitcast %2 : !llvm<"i8**"> to !llvm<"i8*"> %4 = llvm.mlir.null : !llvm<"i8**"> %5 = llvm.mlir.addressof @_ZTIi : !llvm<"i8**"> %6 = llvm.mlir.constant(2 : i32) : !llvm.i32 %7 = llvm.invoke @foo(%6) to ^bb1 unwind ^bb2 : (!llvm.i32) -> !llvm.i32 ^bb1: // pred: ^bb0 llvm.return %6 : !llvm.i32 ^bb2: // pred: ^bb0 %8 = llvm.landingpad (catch %5 : !llvm<"i8**">) (catch %4 : !llvm<"i8**">) (catch %3 : !llvm<"i8*">) (filter %1 : !llvm<"[1 x i8]">) : !llvm<"{ i8*, i32 }"> llvm.return %0 : !llvm.i32 } ``` Signed-off-by: Shraiysh Vaishay <cs17btech11050@iith.ac.in> Differential Revision: https://reviews.llvm.org/D72006
2020-01-30 19:50:12 +08:00
[mlir] Modernize LLVM dialect rountrip test This test largely predates MLIR testing guidelines. Update it to match the guidelines. In particular, avoid pattern-matching SSA value names, avoid unnecessary CHECK-NEXT, relax assumptions about the form of SSA names. Value-returning operations are still matched agaist _any_ name in order to check that the operation indeed produces values. Differential Revision: https://reviews.llvm.org/D82656
2020-06-26 21:27:46 +08:00
// CHECK: ^[[BB2]]:
[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-06 23:19:04 +08:00
// CHECK: llvm.return %[[a7]] : i32
[MLIR] Added llvm.invoke and llvm.landingpad Summary: I have tried to implement `llvm.invoke` and `llvm.landingpad`. # `llvm.invoke` is similar to `llvm.call` with two successors added, the first one is the normal label and the second one is unwind label. # `llvm.launchpad` takes a variable number of args with either `catch` or `filter` associated with them. Catch clauses are not array types and filter clauses are array types. This is same as the criteria used by LLVM (https://github.com/llvm/llvm-project/blob/4f82af81a04d711721300f6ca32f402f2ea6faf4/llvm/include/llvm/IR/Instructions.h#L2866) Examples: LLVM IR ``` define i32 @caller(i32 %a) personality i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*) { invoke i32 @foo(i32 2) to label %success unwind label %fail success: ret i32 2 fail: landingpad {i8*, i32} catch i8** @_ZTIi catch i8** null catch i8* bitcast (i8** @_ZTIi to i8*) filter [1 x i8] [ i8 1 ] ret i32 3 } ``` MLIR LLVM Dialect ``` llvm.func @caller(%arg0: !llvm.i32) -> !llvm.i32 { %0 = llvm.mlir.constant(3 : i32) : !llvm.i32 %1 = llvm.mlir.constant("\01") : !llvm<"[1 x i8]"> %2 = llvm.mlir.addressof @_ZTIi : !llvm<"i8**"> %3 = llvm.bitcast %2 : !llvm<"i8**"> to !llvm<"i8*"> %4 = llvm.mlir.null : !llvm<"i8**"> %5 = llvm.mlir.addressof @_ZTIi : !llvm<"i8**"> %6 = llvm.mlir.constant(2 : i32) : !llvm.i32 %7 = llvm.invoke @foo(%6) to ^bb1 unwind ^bb2 : (!llvm.i32) -> !llvm.i32 ^bb1: // pred: ^bb0 llvm.return %6 : !llvm.i32 ^bb2: // pred: ^bb0 %8 = llvm.landingpad (catch %5 : !llvm<"i8**">) (catch %4 : !llvm<"i8**">) (catch %3 : !llvm<"i8*">) (filter %1 : !llvm<"[1 x i8]">) : !llvm<"{ i8*, i32 }"> llvm.return %0 : !llvm.i32 } ``` Signed-off-by: Shraiysh Vaishay <cs17btech11050@iith.ac.in> Differential Revision: https://reviews.llvm.org/D72006
2020-01-30 19:50:12 +08:00
^bb2:
[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-06 23:19:04 +08:00
llvm.return %7 : i32
[MLIR] Added llvm.invoke and llvm.landingpad Summary: I have tried to implement `llvm.invoke` and `llvm.landingpad`. # `llvm.invoke` is similar to `llvm.call` with two successors added, the first one is the normal label and the second one is unwind label. # `llvm.launchpad` takes a variable number of args with either `catch` or `filter` associated with them. Catch clauses are not array types and filter clauses are array types. This is same as the criteria used by LLVM (https://github.com/llvm/llvm-project/blob/4f82af81a04d711721300f6ca32f402f2ea6faf4/llvm/include/llvm/IR/Instructions.h#L2866) Examples: LLVM IR ``` define i32 @caller(i32 %a) personality i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*) { invoke i32 @foo(i32 2) to label %success unwind label %fail success: ret i32 2 fail: landingpad {i8*, i32} catch i8** @_ZTIi catch i8** null catch i8* bitcast (i8** @_ZTIi to i8*) filter [1 x i8] [ i8 1 ] ret i32 3 } ``` MLIR LLVM Dialect ``` llvm.func @caller(%arg0: !llvm.i32) -> !llvm.i32 { %0 = llvm.mlir.constant(3 : i32) : !llvm.i32 %1 = llvm.mlir.constant("\01") : !llvm<"[1 x i8]"> %2 = llvm.mlir.addressof @_ZTIi : !llvm<"i8**"> %3 = llvm.bitcast %2 : !llvm<"i8**"> to !llvm<"i8*"> %4 = llvm.mlir.null : !llvm<"i8**"> %5 = llvm.mlir.addressof @_ZTIi : !llvm<"i8**"> %6 = llvm.mlir.constant(2 : i32) : !llvm.i32 %7 = llvm.invoke @foo(%6) to ^bb1 unwind ^bb2 : (!llvm.i32) -> !llvm.i32 ^bb1: // pred: ^bb0 llvm.return %6 : !llvm.i32 ^bb2: // pred: ^bb0 %8 = llvm.landingpad (catch %5 : !llvm<"i8**">) (catch %4 : !llvm<"i8**">) (catch %3 : !llvm<"i8*">) (filter %1 : !llvm<"[1 x i8]">) : !llvm<"{ i8*, i32 }"> llvm.return %0 : !llvm.i32 } ``` Signed-off-by: Shraiysh Vaishay <cs17btech11050@iith.ac.in> Differential Revision: https://reviews.llvm.org/D72006
2020-01-30 19:50:12 +08:00
[mlir] Modernize LLVM dialect rountrip test This test largely predates MLIR testing guidelines. Update it to match the guidelines. In particular, avoid pattern-matching SSA value names, avoid unnecessary CHECK-NEXT, relax assumptions about the form of SSA names. Value-returning operations are still matched agaist _any_ name in order to check that the operation indeed produces values. Differential Revision: https://reviews.llvm.org/D82656
2020-06-26 21:27:46 +08:00
// CHECK: ^[[BB3:.*]]:
[mlir] switch the modeling of LLVM types to use the new mechanism A new first-party modeling for LLVM IR types in the LLVM dialect has been developed in parallel to the existing modeling based on wrapping LLVM `Type *` instances. It resolves the long-standing problem of modeling identified structure types, including recursive structures, and enables future removal of LLVMContext and related locking mechanisms from LLVMDialect. This commit only switches the modeling by (a) renaming LLVMTypeNew to LLVMType, (b) removing the old implementaiton of LLVMType, and (c) updating the tests. It is intentionally minimal. Separate commits will remove the infrastructure built for the transition and update API uses where appropriate. Depends On D85020 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D85021
2020-08-04 17:37:50 +08:00
// CHECK: llvm.invoke @bar(%[[a8]], %[[a6]], %[[a4]]) to ^[[BB2]] unwind ^[[BB1]] : (!llvm.ptr<i8>, !llvm.ptr<i8>, !llvm.ptr<i8>) -> ()
[MLIR] Added llvm.invoke and llvm.landingpad Summary: I have tried to implement `llvm.invoke` and `llvm.landingpad`. # `llvm.invoke` is similar to `llvm.call` with two successors added, the first one is the normal label and the second one is unwind label. # `llvm.launchpad` takes a variable number of args with either `catch` or `filter` associated with them. Catch clauses are not array types and filter clauses are array types. This is same as the criteria used by LLVM (https://github.com/llvm/llvm-project/blob/4f82af81a04d711721300f6ca32f402f2ea6faf4/llvm/include/llvm/IR/Instructions.h#L2866) Examples: LLVM IR ``` define i32 @caller(i32 %a) personality i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*) { invoke i32 @foo(i32 2) to label %success unwind label %fail success: ret i32 2 fail: landingpad {i8*, i32} catch i8** @_ZTIi catch i8** null catch i8* bitcast (i8** @_ZTIi to i8*) filter [1 x i8] [ i8 1 ] ret i32 3 } ``` MLIR LLVM Dialect ``` llvm.func @caller(%arg0: !llvm.i32) -> !llvm.i32 { %0 = llvm.mlir.constant(3 : i32) : !llvm.i32 %1 = llvm.mlir.constant("\01") : !llvm<"[1 x i8]"> %2 = llvm.mlir.addressof @_ZTIi : !llvm<"i8**"> %3 = llvm.bitcast %2 : !llvm<"i8**"> to !llvm<"i8*"> %4 = llvm.mlir.null : !llvm<"i8**"> %5 = llvm.mlir.addressof @_ZTIi : !llvm<"i8**"> %6 = llvm.mlir.constant(2 : i32) : !llvm.i32 %7 = llvm.invoke @foo(%6) to ^bb1 unwind ^bb2 : (!llvm.i32) -> !llvm.i32 ^bb1: // pred: ^bb0 llvm.return %6 : !llvm.i32 ^bb2: // pred: ^bb0 %8 = llvm.landingpad (catch %5 : !llvm<"i8**">) (catch %4 : !llvm<"i8**">) (catch %3 : !llvm<"i8*">) (filter %1 : !llvm<"[1 x i8]">) : !llvm<"{ i8*, i32 }"> llvm.return %0 : !llvm.i32 } ``` Signed-off-by: Shraiysh Vaishay <cs17btech11050@iith.ac.in> Differential Revision: https://reviews.llvm.org/D72006
2020-01-30 19:50:12 +08:00
^bb3:
[mlir] switch the modeling of LLVM types to use the new mechanism A new first-party modeling for LLVM IR types in the LLVM dialect has been developed in parallel to the existing modeling based on wrapping LLVM `Type *` instances. It resolves the long-standing problem of modeling identified structure types, including recursive structures, and enables future removal of LLVMContext and related locking mechanisms from LLVMDialect. This commit only switches the modeling by (a) renaming LLVMTypeNew to LLVMType, (b) removing the old implementaiton of LLVMType, and (c) updating the tests. It is intentionally minimal. Separate commits will remove the infrastructure built for the transition and update API uses where appropriate. Depends On D85020 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D85021
2020-08-04 17:37:50 +08:00
llvm.invoke @bar(%8, %6, %4) to ^bb2 unwind ^bb1 : (!llvm.ptr<i8>, !llvm.ptr<i8>, !llvm.ptr<i8>) -> ()
[MLIR] Added llvm.invoke and llvm.landingpad Summary: I have tried to implement `llvm.invoke` and `llvm.landingpad`. # `llvm.invoke` is similar to `llvm.call` with two successors added, the first one is the normal label and the second one is unwind label. # `llvm.launchpad` takes a variable number of args with either `catch` or `filter` associated with them. Catch clauses are not array types and filter clauses are array types. This is same as the criteria used by LLVM (https://github.com/llvm/llvm-project/blob/4f82af81a04d711721300f6ca32f402f2ea6faf4/llvm/include/llvm/IR/Instructions.h#L2866) Examples: LLVM IR ``` define i32 @caller(i32 %a) personality i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*) { invoke i32 @foo(i32 2) to label %success unwind label %fail success: ret i32 2 fail: landingpad {i8*, i32} catch i8** @_ZTIi catch i8** null catch i8* bitcast (i8** @_ZTIi to i8*) filter [1 x i8] [ i8 1 ] ret i32 3 } ``` MLIR LLVM Dialect ``` llvm.func @caller(%arg0: !llvm.i32) -> !llvm.i32 { %0 = llvm.mlir.constant(3 : i32) : !llvm.i32 %1 = llvm.mlir.constant("\01") : !llvm<"[1 x i8]"> %2 = llvm.mlir.addressof @_ZTIi : !llvm<"i8**"> %3 = llvm.bitcast %2 : !llvm<"i8**"> to !llvm<"i8*"> %4 = llvm.mlir.null : !llvm<"i8**"> %5 = llvm.mlir.addressof @_ZTIi : !llvm<"i8**"> %6 = llvm.mlir.constant(2 : i32) : !llvm.i32 %7 = llvm.invoke @foo(%6) to ^bb1 unwind ^bb2 : (!llvm.i32) -> !llvm.i32 ^bb1: // pred: ^bb0 llvm.return %6 : !llvm.i32 ^bb2: // pred: ^bb0 %8 = llvm.landingpad (catch %5 : !llvm<"i8**">) (catch %4 : !llvm<"i8**">) (catch %3 : !llvm<"i8*">) (filter %1 : !llvm<"[1 x i8]">) : !llvm<"{ i8*, i32 }"> llvm.return %0 : !llvm.i32 } ``` Signed-off-by: Shraiysh Vaishay <cs17btech11050@iith.ac.in> Differential Revision: https://reviews.llvm.org/D72006
2020-01-30 19:50:12 +08:00
[mlir] Modernize LLVM dialect rountrip test This test largely predates MLIR testing guidelines. Update it to match the guidelines. In particular, avoid pattern-matching SSA value names, avoid unnecessary CHECK-NEXT, relax assumptions about the form of SSA names. Value-returning operations are still matched agaist _any_ name in order to check that the operation indeed produces values. Differential Revision: https://reviews.llvm.org/D82656
2020-06-26 21:27:46 +08:00
// CHECK: ^[[BB4:.*]]:
[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-06 23:19:04 +08:00
// CHECK: llvm.return %[[a0]] : i32
[MLIR] Added llvm.invoke and llvm.landingpad Summary: I have tried to implement `llvm.invoke` and `llvm.landingpad`. # `llvm.invoke` is similar to `llvm.call` with two successors added, the first one is the normal label and the second one is unwind label. # `llvm.launchpad` takes a variable number of args with either `catch` or `filter` associated with them. Catch clauses are not array types and filter clauses are array types. This is same as the criteria used by LLVM (https://github.com/llvm/llvm-project/blob/4f82af81a04d711721300f6ca32f402f2ea6faf4/llvm/include/llvm/IR/Instructions.h#L2866) Examples: LLVM IR ``` define i32 @caller(i32 %a) personality i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*) { invoke i32 @foo(i32 2) to label %success unwind label %fail success: ret i32 2 fail: landingpad {i8*, i32} catch i8** @_ZTIi catch i8** null catch i8* bitcast (i8** @_ZTIi to i8*) filter [1 x i8] [ i8 1 ] ret i32 3 } ``` MLIR LLVM Dialect ``` llvm.func @caller(%arg0: !llvm.i32) -> !llvm.i32 { %0 = llvm.mlir.constant(3 : i32) : !llvm.i32 %1 = llvm.mlir.constant("\01") : !llvm<"[1 x i8]"> %2 = llvm.mlir.addressof @_ZTIi : !llvm<"i8**"> %3 = llvm.bitcast %2 : !llvm<"i8**"> to !llvm<"i8*"> %4 = llvm.mlir.null : !llvm<"i8**"> %5 = llvm.mlir.addressof @_ZTIi : !llvm<"i8**"> %6 = llvm.mlir.constant(2 : i32) : !llvm.i32 %7 = llvm.invoke @foo(%6) to ^bb1 unwind ^bb2 : (!llvm.i32) -> !llvm.i32 ^bb1: // pred: ^bb0 llvm.return %6 : !llvm.i32 ^bb2: // pred: ^bb0 %8 = llvm.landingpad (catch %5 : !llvm<"i8**">) (catch %4 : !llvm<"i8**">) (catch %3 : !llvm<"i8*">) (filter %1 : !llvm<"[1 x i8]">) : !llvm<"{ i8*, i32 }"> llvm.return %0 : !llvm.i32 } ``` Signed-off-by: Shraiysh Vaishay <cs17btech11050@iith.ac.in> Differential Revision: https://reviews.llvm.org/D72006
2020-01-30 19:50:12 +08:00
^bb4:
[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-06 23:19:04 +08:00
llvm.return %0 : i32
[MLIR] Added llvm.invoke and llvm.landingpad Summary: I have tried to implement `llvm.invoke` and `llvm.landingpad`. # `llvm.invoke` is similar to `llvm.call` with two successors added, the first one is the normal label and the second one is unwind label. # `llvm.launchpad` takes a variable number of args with either `catch` or `filter` associated with them. Catch clauses are not array types and filter clauses are array types. This is same as the criteria used by LLVM (https://github.com/llvm/llvm-project/blob/4f82af81a04d711721300f6ca32f402f2ea6faf4/llvm/include/llvm/IR/Instructions.h#L2866) Examples: LLVM IR ``` define i32 @caller(i32 %a) personality i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*) { invoke i32 @foo(i32 2) to label %success unwind label %fail success: ret i32 2 fail: landingpad {i8*, i32} catch i8** @_ZTIi catch i8** null catch i8* bitcast (i8** @_ZTIi to i8*) filter [1 x i8] [ i8 1 ] ret i32 3 } ``` MLIR LLVM Dialect ``` llvm.func @caller(%arg0: !llvm.i32) -> !llvm.i32 { %0 = llvm.mlir.constant(3 : i32) : !llvm.i32 %1 = llvm.mlir.constant("\01") : !llvm<"[1 x i8]"> %2 = llvm.mlir.addressof @_ZTIi : !llvm<"i8**"> %3 = llvm.bitcast %2 : !llvm<"i8**"> to !llvm<"i8*"> %4 = llvm.mlir.null : !llvm<"i8**"> %5 = llvm.mlir.addressof @_ZTIi : !llvm<"i8**"> %6 = llvm.mlir.constant(2 : i32) : !llvm.i32 %7 = llvm.invoke @foo(%6) to ^bb1 unwind ^bb2 : (!llvm.i32) -> !llvm.i32 ^bb1: // pred: ^bb0 llvm.return %6 : !llvm.i32 ^bb2: // pred: ^bb0 %8 = llvm.landingpad (catch %5 : !llvm<"i8**">) (catch %4 : !llvm<"i8**">) (catch %3 : !llvm<"i8*">) (filter %1 : !llvm<"[1 x i8]">) : !llvm<"{ i8*, i32 }"> llvm.return %0 : !llvm.i32 } ``` Signed-off-by: Shraiysh Vaishay <cs17btech11050@iith.ac.in> Differential Revision: https://reviews.llvm.org/D72006
2020-01-30 19:50:12 +08:00
}
[MLIR] Added llvm.freeze This patch adds llvm.freeze & processes undef constants from LLVM IR. Syntax: LLVM IR `<result> = freeze ty <val>` MLIR LLVM Dialect: `llvm.freeze val attr-dict : type` Example: LLVM IR: `%3 = freeze i32 5` MLIR: `%6 = llvm.freeze %5 : !llvm.i32` Differential Revision: https://reviews.llvm.org/D75329
2020-03-02 17:19:57 +08:00
// CHECK-LABEL: @useFreezeOp
[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-06 23:19:04 +08:00
func @useFreezeOp(%arg0: i32) {
// CHECK: = llvm.freeze %[[ARG0:.*]] : i32
%0 = llvm.freeze %arg0 : i32
// CHECK: %[[x:.*]] = llvm.mlir.undef : i8
%1 = llvm.mlir.undef : i8
// CHECK: = llvm.freeze %[[x]] : i8
%2 = llvm.freeze %1 : i8
[MLIR] Added llvm.freeze This patch adds llvm.freeze & processes undef constants from LLVM IR. Syntax: LLVM IR `<result> = freeze ty <val>` MLIR LLVM Dialect: `llvm.freeze val attr-dict : type` Example: LLVM IR: `%3 = freeze i32 5` MLIR: `%6 = llvm.freeze %5 : !llvm.i32` Differential Revision: https://reviews.llvm.org/D75329
2020-03-02 17:19:57 +08:00
return
[MLIR] Added llvm.fence This patch adds llvm.fence. I tried not to change the syntax much. syntax: LLVM IR `fence [syncscope("<target-scope>")] <ordering>` MLIR LLVM Dialect `llvm.fence [syncscope("<target-scope>")] <ordering>` example: LLVM IR: `fence syncscope("agent") seq_cst` MLIR: `llvm.fence syncscope("agent") seq_cst` Differential Revision: https://reviews.llvm.org/D75645
2020-03-18 00:43:21 +08:00
}
// CHECK-LABEL: @useFenceInst
func @useFenceInst() {
[mlir] Modernize LLVM dialect rountrip test This test largely predates MLIR testing guidelines. Update it to match the guidelines. In particular, avoid pattern-matching SSA value names, avoid unnecessary CHECK-NEXT, relax assumptions about the form of SSA names. Value-returning operations are still matched agaist _any_ name in order to check that the operation indeed produces values. Differential Revision: https://reviews.llvm.org/D82656
2020-06-26 21:27:46 +08:00
// CHECK: syncscope("agent") seq_cst
[MLIR] Added llvm.fence This patch adds llvm.fence. I tried not to change the syntax much. syntax: LLVM IR `fence [syncscope("<target-scope>")] <ordering>` MLIR LLVM Dialect `llvm.fence [syncscope("<target-scope>")] <ordering>` example: LLVM IR: `fence syncscope("agent") seq_cst` MLIR: `llvm.fence syncscope("agent") seq_cst` Differential Revision: https://reviews.llvm.org/D75645
2020-03-18 00:43:21 +08:00
llvm.fence syncscope("agent") seq_cst
[mlir] Modernize LLVM dialect rountrip test This test largely predates MLIR testing guidelines. Update it to match the guidelines. In particular, avoid pattern-matching SSA value names, avoid unnecessary CHECK-NEXT, relax assumptions about the form of SSA names. Value-returning operations are still matched agaist _any_ name in order to check that the operation indeed produces values. Differential Revision: https://reviews.llvm.org/D82656
2020-06-26 21:27:46 +08:00
// CHECK: seq_cst
[MLIR] Added llvm.fence This patch adds llvm.fence. I tried not to change the syntax much. syntax: LLVM IR `fence [syncscope("<target-scope>")] <ordering>` MLIR LLVM Dialect `llvm.fence [syncscope("<target-scope>")] <ordering>` example: LLVM IR: `fence syncscope("agent") seq_cst` MLIR: `llvm.fence syncscope("agent") seq_cst` Differential Revision: https://reviews.llvm.org/D75645
2020-03-18 00:43:21 +08:00
llvm.fence syncscope("") seq_cst
// CHECK: release
llvm.fence release
return
[mlir] support returning unranked memrefs Initially, unranked memref descriptors in the LLVM dialect were designed only to be passed into functions. An assertion was guarding against returning unranked memrefs from functions in the standard-to-LLVM conversion. This is insufficient for functions that wish to return an unranked memref such that the caller does not know the rank in advance, and hence cannot allocate the descriptor and pass it in as an argument. Introduce a calling convention for returning unranked memref descriptors as follows. An unranked memref descriptor always points to a ranked memref descriptor stored on stack of the current function. When an unranked memref descriptor is returned from a function, the ranked memref descriptor it points to is copied to dynamically allocated memory, the ownership of which is transferred to the caller. The caller is responsible for deallocating the dynamically allocated memory and for copying the pointed-to ranked memref descriptor onto its stack. Provide default lowerings for std.return, std.call and std.indirect_call that maintain the conversion defined above. This convention is additionally exercised by a runtime test to guard against memory errors. Differential Revision: https://reviews.llvm.org/D82647
2020-06-26 20:34:00 +08:00
}
[mlir][LLVMIR] Add support for InlineAsmOp The InlineAsmOp mirrors the underlying LLVM semantics with a notable exception: the embedded `asm_string` is not allowed to define or reference any symbol or any global variable: only the operands of the op may be read, written, or referenced. Attempting to define or reference any symbol or any global behavior is considered undefined behavior at this time. The asm dialect syntax is currently specified with an integer (0 [default] for the "att dialect", 1 for the intel dialect) to circumvent the ODS limitation on string enums. Translation to LLVM is provided and raises the fact that the asm constraints string must be well-formed with respect to in/out operands. No check is performed on the asm_string. An InlineAsm instruction in LLVM is a special call operation to a function that is constructed on the fly. It does not fit the current model of MLIR calls with symbols. As a consequence, the current implementation constructs the function type in ModuleTranslation.cpp. This should be refactored in the future. The mlir-cpu-runner is augmented with the global initialization of the X86 asm parser to allow proper execution in JIT mode. Previously, only the X86 asm printer was initialized. Differential revision: https://reviews.llvm.org/D92166
2020-11-28 06:02:23 +08:00
// CHECK-LABEL: @useInlineAsm
[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-06 23:19:04 +08:00
llvm.func @useInlineAsm(%arg0: i32) {
// CHECK: llvm.inline_asm {{.*}} (i32) -> i8
%0 = llvm.inline_asm "bswap $0", "=r,r" %arg0 : (i32) -> i8
[mlir][LLVMIR] Add support for InlineAsmOp The InlineAsmOp mirrors the underlying LLVM semantics with a notable exception: the embedded `asm_string` is not allowed to define or reference any symbol or any global variable: only the operands of the op may be read, written, or referenced. Attempting to define or reference any symbol or any global behavior is considered undefined behavior at this time. The asm dialect syntax is currently specified with an integer (0 [default] for the "att dialect", 1 for the intel dialect) to circumvent the ODS limitation on string enums. Translation to LLVM is provided and raises the fact that the asm constraints string must be well-formed with respect to in/out operands. No check is performed on the asm_string. An InlineAsm instruction in LLVM is a special call operation to a function that is constructed on the fly. It does not fit the current model of MLIR calls with symbols. As a consequence, the current implementation constructs the function type in ModuleTranslation.cpp. This should be refactored in the future. The mlir-cpu-runner is augmented with the global initialization of the X86 asm parser to allow proper execution in JIT mode. Previously, only the X86 asm printer was initialized. Differential revision: https://reviews.llvm.org/D92166
2020-11-28 06:02:23 +08:00
[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-06 23:19:04 +08:00
// CHECK-NEXT: llvm.inline_asm {{.*}} (i32, i32) -> i8
%1 = llvm.inline_asm "foo", "bar" %arg0, %arg0 : (i32, i32) -> i8
[mlir][LLVMIR] Add support for InlineAsmOp The InlineAsmOp mirrors the underlying LLVM semantics with a notable exception: the embedded `asm_string` is not allowed to define or reference any symbol or any global variable: only the operands of the op may be read, written, or referenced. Attempting to define or reference any symbol or any global behavior is considered undefined behavior at this time. The asm dialect syntax is currently specified with an integer (0 [default] for the "att dialect", 1 for the intel dialect) to circumvent the ODS limitation on string enums. Translation to LLVM is provided and raises the fact that the asm constraints string must be well-formed with respect to in/out operands. No check is performed on the asm_string. An InlineAsm instruction in LLVM is a special call operation to a function that is constructed on the fly. It does not fit the current model of MLIR calls with symbols. As a consequence, the current implementation constructs the function type in ModuleTranslation.cpp. This should be refactored in the future. The mlir-cpu-runner is augmented with the global initialization of the X86 asm parser to allow proper execution in JIT mode. Previously, only the X86 asm printer was initialized. Differential revision: https://reviews.llvm.org/D92166
2020-11-28 06:02:23 +08:00
[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-06 23:19:04 +08:00
// CHECK-NEXT: llvm.inline_asm has_side_effects {{.*}} (i32, i32) -> i8
%2 = llvm.inline_asm has_side_effects "foo", "bar" %arg0, %arg0 : (i32, i32) -> i8
[mlir][LLVMIR] Add support for InlineAsmOp The InlineAsmOp mirrors the underlying LLVM semantics with a notable exception: the embedded `asm_string` is not allowed to define or reference any symbol or any global variable: only the operands of the op may be read, written, or referenced. Attempting to define or reference any symbol or any global behavior is considered undefined behavior at this time. The asm dialect syntax is currently specified with an integer (0 [default] for the "att dialect", 1 for the intel dialect) to circumvent the ODS limitation on string enums. Translation to LLVM is provided and raises the fact that the asm constraints string must be well-formed with respect to in/out operands. No check is performed on the asm_string. An InlineAsm instruction in LLVM is a special call operation to a function that is constructed on the fly. It does not fit the current model of MLIR calls with symbols. As a consequence, the current implementation constructs the function type in ModuleTranslation.cpp. This should be refactored in the future. The mlir-cpu-runner is augmented with the global initialization of the X86 asm parser to allow proper execution in JIT mode. Previously, only the X86 asm printer was initialized. Differential revision: https://reviews.llvm.org/D92166
2020-11-28 06:02:23 +08:00
[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-06 23:19:04 +08:00
// CHECK-NEXT: llvm.inline_asm is_align_stack {{.*}} (i32, i32) -> i8
%3 = llvm.inline_asm is_align_stack "foo", "bar" %arg0, %arg0 : (i32, i32) -> i8
[mlir][LLVMIR] Add support for InlineAsmOp The InlineAsmOp mirrors the underlying LLVM semantics with a notable exception: the embedded `asm_string` is not allowed to define or reference any symbol or any global variable: only the operands of the op may be read, written, or referenced. Attempting to define or reference any symbol or any global behavior is considered undefined behavior at this time. The asm dialect syntax is currently specified with an integer (0 [default] for the "att dialect", 1 for the intel dialect) to circumvent the ODS limitation on string enums. Translation to LLVM is provided and raises the fact that the asm constraints string must be well-formed with respect to in/out operands. No check is performed on the asm_string. An InlineAsm instruction in LLVM is a special call operation to a function that is constructed on the fly. It does not fit the current model of MLIR calls with symbols. As a consequence, the current implementation constructs the function type in ModuleTranslation.cpp. This should be refactored in the future. The mlir-cpu-runner is augmented with the global initialization of the X86 asm parser to allow proper execution in JIT mode. Previously, only the X86 asm printer was initialized. Differential revision: https://reviews.llvm.org/D92166
2020-11-28 06:02:23 +08:00
[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-06 23:19:04 +08:00
// CHECK-NEXT: llvm.inline_asm "foo", "=r,=r,r" {{.*}} : (i32) -> !llvm.struct<(i8, i8)>
%5 = llvm.inline_asm "foo", "=r,=r,r" %arg0 : (i32) -> !llvm.struct<(i8, i8)>
[mlir][LLVMIR] Add support for InlineAsmOp The InlineAsmOp mirrors the underlying LLVM semantics with a notable exception: the embedded `asm_string` is not allowed to define or reference any symbol or any global variable: only the operands of the op may be read, written, or referenced. Attempting to define or reference any symbol or any global behavior is considered undefined behavior at this time. The asm dialect syntax is currently specified with an integer (0 [default] for the "att dialect", 1 for the intel dialect) to circumvent the ODS limitation on string enums. Translation to LLVM is provided and raises the fact that the asm constraints string must be well-formed with respect to in/out operands. No check is performed on the asm_string. An InlineAsm instruction in LLVM is a special call operation to a function that is constructed on the fly. It does not fit the current model of MLIR calls with symbols. As a consequence, the current implementation constructs the function type in ModuleTranslation.cpp. This should be refactored in the future. The mlir-cpu-runner is augmented with the global initialization of the X86 asm parser to allow proper execution in JIT mode. Previously, only the X86 asm printer was initialized. Differential revision: https://reviews.llvm.org/D92166
2020-11-28 06:02:23 +08:00
llvm.return
}
[mlir] Add fastmath flags support to some LLVM dialect ops Add fastmath enum, attributes to some llvm dialect ops, `FastmathFlagsInterface` op interface, and `translateModuleToLLVMIR` support. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D92485
2021-01-07 20:56:37 +08:00
// CHECK-LABEL: @fastmathFlags
[mlir] replace LLVM dialect float types with built-ins Continue the convergence between LLVM dialect and built-in types by replacing the bfloat, half, float and double LLVM dialect types with their built-in counterparts. At the API level, this is a direct replacement. At the syntax level, we change the keywords to `bf16`, `f16`, `f32` and `f64`, respectively, to be compatible with the built-in type syntax. The old keywords can still be parsed but produce a deprecation warning and will be eventually removed. Depends On D94178 Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94179
2021-01-06 23:21:08 +08:00
func @fastmathFlags(%arg0: f32, %arg1: f32, %arg2: i32) {
// CHECK: {{.*}} = llvm.fadd %arg0, %arg1 {fastmathFlags = #llvm.fastmath<fast>} : f32
// CHECK: {{.*}} = llvm.fsub %arg0, %arg1 {fastmathFlags = #llvm.fastmath<fast>} : f32
// CHECK: {{.*}} = llvm.fmul %arg0, %arg1 {fastmathFlags = #llvm.fastmath<fast>} : f32
// CHECK: {{.*}} = llvm.fdiv %arg0, %arg1 {fastmathFlags = #llvm.fastmath<fast>} : f32
// CHECK: {{.*}} = llvm.frem %arg0, %arg1 {fastmathFlags = #llvm.fastmath<fast>} : f32
%0 = llvm.fadd %arg0, %arg1 {fastmathFlags = #llvm.fastmath<fast>} : f32
%1 = llvm.fsub %arg0, %arg1 {fastmathFlags = #llvm.fastmath<fast>} : f32
%2 = llvm.fmul %arg0, %arg1 {fastmathFlags = #llvm.fastmath<fast>} : f32
%3 = llvm.fdiv %arg0, %arg1 {fastmathFlags = #llvm.fastmath<fast>} : f32
%4 = llvm.frem %arg0, %arg1 {fastmathFlags = #llvm.fastmath<fast>} : f32
// CHECK: {{.*}} = llvm.fcmp "oeq" %arg0, %arg1 {fastmathFlags = #llvm.fastmath<fast>} : f32
%5 = llvm.fcmp "oeq" %arg0, %arg1 {fastmathFlags = #llvm.fastmath<fast>} : f32
// CHECK: {{.*}} = llvm.fneg %arg0 {fastmathFlags = #llvm.fastmath<fast>} : f32
%6 = llvm.fneg %arg0 {fastmathFlags = #llvm.fastmath<fast>} : f32
// CHECK: {{.*}} = llvm.call @foo(%arg2) {fastmathFlags = #llvm.fastmath<fast>} : (i32) -> !llvm.struct<(i32, f64, i32)>
%7 = llvm.call @foo(%arg2) {fastmathFlags = #llvm.fastmath<fast>} : (i32) -> !llvm.struct<(i32, f64, i32)>
// CHECK: {{.*}} = llvm.fadd %arg0, %arg1 : f32
%8 = llvm.fadd %arg0, %arg1 {fastmathFlags = #llvm.fastmath<>} : f32
// CHECK: {{.*}} = llvm.fadd %arg0, %arg1 {fastmathFlags = #llvm.fastmath<nnan, ninf>} : f32
%9 = llvm.fadd %arg0, %arg1 {fastmathFlags = #llvm.fastmath<nnan, ninf>} : f32
// CHECK: {{.*}} = llvm.fneg %arg0 : f32
%10 = llvm.fneg %arg0 {fastmathFlags = #llvm.fastmath<>} : f32
[mlir] Add fastmath flags support to some LLVM dialect ops Add fastmath enum, attributes to some llvm dialect ops, `FastmathFlagsInterface` op interface, and `translateModuleToLLVMIR` support. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D92485
2021-01-07 20:56:37 +08:00
return
}
[mlir] Add loop codegen options to some LLVM dialect ops. Add a Loop Option attribute and generate llvm metadata attached to branch instructions to control code generation. Reviewed By: ftynse, mehdi_amini Differential Revision: https://reviews.llvm.org/D96820
2021-03-04 16:00:18 +08:00
module {
Fix LLVM Dialect LoopOptionsAttr round-tripping: the keywords were missing in the output This indicated some missing test coverage, which are now added to the roundtrip test.
2021-03-10 05:59:35 +08:00
// CHECK-LABEL: @loopOptions
llvm.func @loopOptions() {
// CHECK: llvm.br
[mlir] Add LLVM loop codegen options to control software pipelining Support specifying the II and disabling pipelining. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D98420
2021-03-11 23:42:56 +08:00
// CHECK-SAME: llvm.loop = {options = #llvm.loopopts<disable_unroll = true, disable_licm = true, interleave_count = 1, disable_pipeline = true, pipeline_initiation_interval = 1>}, parallel_access = [@metadata::@group1]}
llvm.br ^bb1 {llvm.loop = {options = #llvm.loopopts<disable_unroll = true, disable_licm = true, interleave_count = 1, disable_pipeline = true, pipeline_initiation_interval = 1>}, parallel_access = [@metadata::@group1]}
Fix LLVM Dialect LoopOptionsAttr round-tripping: the keywords were missing in the output This indicated some missing test coverage, which are now added to the roundtrip test.
2021-03-10 05:59:35 +08:00
^bb1:
llvm.return
}
[mlir] Add loop codegen options to some LLVM dialect ops. Add a Loop Option attribute and generate llvm metadata attached to branch instructions to control code generation. Reviewed By: ftynse, mehdi_amini Differential Revision: https://reviews.llvm.org/D96820
2021-03-04 16:00:18 +08:00
// CHECK: llvm.metadata @metadata attributes {test_attribute} {
llvm.metadata @metadata attributes {test_attribute} {
// CHECK: llvm.access_group @group1
llvm.access_group @group1
llvm.return
}
}