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

1008 lines
41 KiB
MLIR
Raw Normal View History

Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
// RUN: mlir-translate -mlir-to-llvmir %s | FileCheck %s
Translation to LLVM: support llvm.global Add support for translating recently introduced llvm.global operations to global variables in the LLVM IR proper. PiperOrigin-RevId: 262564700
2019-08-09 23:30:13 +08:00
// CHECK: @i32_global = internal global i32 42
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
llvm.mlir.global @i32_global(42: i32) : !llvm.i32
Translation to LLVM: support llvm.global Add support for translating recently introduced llvm.global operations to global variables in the LLVM IR proper. PiperOrigin-RevId: 262564700
2019-08-09 23:30:13 +08:00
Add support for array-typed constants. PiperOrigin-RevId: 267121729
2019-09-04 18:45:38 +08:00
// CHECK: @i32_const = internal constant i53 52
llvm.mlir.global constant @i32_const(52: i53) : !llvm.i53
// CHECK: @int_global_array = internal global [3 x i32] [i32 62, i32 62, i32 62]
llvm.mlir.global @int_global_array(dense<62> : vector<3xi32>) : !llvm<"[3 x i32]">
Translation to LLVM: support llvm.global Add support for translating recently introduced llvm.global operations to global variables in the LLVM IR proper. PiperOrigin-RevId: 262564700
2019-08-09 23:30:13 +08:00
Add address space attribute to LLVMIR's GlobalOp. PiperOrigin-RevId: 270012505
2019-09-19 19:50:17 +08:00
// CHECK: @i32_global_addr_space = internal addrspace(7) global i32 62
llvm.mlir.global @i32_global_addr_space(62: i32) {addr_space = 7 : i32} : !llvm.i32
Translation to LLVM: support llvm.global Add support for translating recently introduced llvm.global operations to global variables in the LLVM IR proper. PiperOrigin-RevId: 262564700
2019-08-09 23:30:13 +08:00
// CHECK: @float_global = internal global float 0.000000e+00
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
llvm.mlir.global @float_global(0.0: f32) : !llvm.float
Translation to LLVM: support llvm.global Add support for translating recently introduced llvm.global operations to global variables in the LLVM IR proper. PiperOrigin-RevId: 262564700
2019-08-09 23:30:13 +08:00
Add support for array-typed constants. PiperOrigin-RevId: 267121729
2019-09-04 18:45:38 +08:00
// CHECK: @float_global_array = internal global [1 x float] [float -5.000000e+00]
llvm.mlir.global @float_global_array(dense<[-5.0]> : vector<1xf32>) : !llvm<"[1 x float]">
LLVM dialect and translation: support global strings Unlike regular constant values, strings must be placed in some memory and referred to through a pointer to that memory. Until now, they were not supported in function-local constant declarations with `llvm.constant`. Introduce support for global strings using `llvm.global`, which would translate them into global arrays in LLVM IR and thus make sure they have some memory allocated for storage. PiperOrigin-RevId: 262569316
2019-08-09 23:59:45 +08:00
// CHECK: @string_const = internal constant [6 x i8] c"foobar"
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
llvm.mlir.global constant @string_const("foobar") : !llvm<"[6 x i8]">
LLVM dialect and translation: support global strings Unlike regular constant values, strings must be placed in some memory and referred to through a pointer to that memory. Until now, they were not supported in function-local constant declarations with `llvm.constant`. Introduce support for global strings using `llvm.global`, which would translate them into global arrays in LLVM IR and thus make sure they have some memory allocated for storage. PiperOrigin-RevId: 262569316
2019-08-09 23:59:45 +08:00
Make GlobalOp's value attribute optional. Make GlobalOp's value attribute an OptionalAttr. Change code that uses the value to handle 'nullopt'. Translate an unitialized value attribute to llvm::UndefValue. PiperOrigin-RevId: 270423646
2019-09-21 16:19:43 +08:00
// CHECK: @int_global_undef = internal global i64 undef
llvm.mlir.global @int_global_undef() : !llvm.i64
[llvm] Allow GlobalOp to take a region for complex initializers This allows GlobalOp to either take a value attribute (for simple constants) or a region that can contain IR instructions (that must be constant-foldable) to create a ConstantExpr initializer. Example: // A complex initializer is constructed with an initializer region. llvm.mlir.global constant @int_gep() : !llvm<"i32*"> { %0 = llvm.mlir.addressof @g2 : !llvm<"i32*"> %1 = llvm.mlir.constant(2 : i32) : !llvm.i32 %2 = llvm.getelementptr %0[%1] : (!llvm<"i32*">, !llvm.i32) -> !llvm<"i32*"> llvm.return %2 : !llvm<"i32*"> } PiperOrigin-RevId: 278717836
2019-11-06 07:10:28 +08:00
// CHECK: @int_gep = internal constant i32* getelementptr (i32, i32* @i32_global, i32 2)
llvm.mlir.global constant @int_gep() : !llvm<"i32*"> {
%addr = llvm.mlir.addressof @i32_global : !llvm<"i32*">
%_c0 = llvm.mlir.constant(2: i32) :!llvm.i32
%gepinit = llvm.getelementptr %addr[%_c0] : (!llvm<"i32*">, !llvm.i32) -> !llvm<"i32*">
llvm.return %gepinit : !llvm<"i32*">
}
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
//
// Declarations of the allocation functions to be linked against.
//
Reimplement LLVM IR translation to use the MLIR LLVM IR dialect Original implementation of the translation from MLIR to LLVM IR operated on the Standard+BuiltIn dialect, with a later addition of the SuperVector dialect. This required the translation to be aware of a potetially large number of other dialects as the infrastructure extended. With the recent introduction of the LLVM IR dialect into MLIR, the translation can be switched to only translate the LLVM IR dialect, and the translation of the operations becomes largely mechanical. The reimplementation of the translator follows the lines of the original translator in function and basic block conversion. In particular, block arguments are converted to LLVM IR PHI nodes, which are connected to their sources after all blocks of a function had been converted. Thanks to LLVM IR types being wrapped in the MLIR LLVM dialect type, type conversion is simplified to only convert function types, all other types are simply unwrapped. Individual instructions are constructed using the LLVM IRBuilder, which has a great potential for being table-generated from the LLVM IR dialect operation definitions. The input of the test/Target/llvmir.mlir is updated to use the MLIR LLVM IR dialect. While it is now redundant with the dialect conversion test, the point of the exercise is to guarantee exactly the same LLVM IR is emitted. (Only the name of the allocation function is changed from `__mlir_alloc` to `alloc` in the CHECK lines.) It will be simplified in a follow-up commit. PiperOrigin-RevId: 233842306
2019-02-14 07:30:24 +08:00
// CHECK: declare i8* @malloc(i64)
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @malloc(!llvm.i64) -> !llvm<"i8*">
Reimplement LLVM IR translation to use the MLIR LLVM IR dialect Original implementation of the translation from MLIR to LLVM IR operated on the Standard+BuiltIn dialect, with a later addition of the SuperVector dialect. This required the translation to be aware of a potetially large number of other dialects as the infrastructure extended. With the recent introduction of the LLVM IR dialect into MLIR, the translation can be switched to only translate the LLVM IR dialect, and the translation of the operations becomes largely mechanical. The reimplementation of the translator follows the lines of the original translator in function and basic block conversion. In particular, block arguments are converted to LLVM IR PHI nodes, which are connected to their sources after all blocks of a function had been converted. Thanks to LLVM IR types being wrapped in the MLIR LLVM dialect type, type conversion is simplified to only convert function types, all other types are simply unwrapped. Individual instructions are constructed using the LLVM IRBuilder, which has a great potential for being table-generated from the LLVM IR dialect operation definitions. The input of the test/Target/llvmir.mlir is updated to use the MLIR LLVM IR dialect. While it is now redundant with the dialect conversion test, the point of the exercise is to guarantee exactly the same LLVM IR is emitted. (Only the name of the allocation function is changed from `__mlir_alloc` to `alloc` in the CHECK lines.) It will be simplified in a follow-up commit. PiperOrigin-RevId: 233842306
2019-02-14 07:30:24 +08:00
// CHECK: declare void @free(i8*)
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
//
Tidy up references to "basic blocks" that should refer to blocks now. NFC. PiperOrigin-RevId: 227196077
2018-12-29 13:24:30 +08:00
// Basic functionality: function and block conversion, function calls,
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// phi nodes, scalar type conversion, arithmetic operations.
//
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
// CHECK-LABEL: define void @empty() {
// CHECK-NEXT: ret void
// CHECK-NEXT: }
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @empty() {
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
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
}
LLVM dialect: introduce llvm.addressof to access globals This instruction is a local counterpart of llvm.global that takes a symbol reference to a global and produces an SSA value containing the pointer to it. Used in combination, these two operations allow one to use globals with other operations expecting SSA values. At a cost of IR indirection, we make sure the functions don't implicitly capture the surrounding SSA values and remain suitable for parallel processing. PiperOrigin-RevId: 262908622
2019-08-12 21:10:29 +08:00
// CHECK-LABEL: @global_refs
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @global_refs() {
LLVM dialect: introduce llvm.addressof to access globals This instruction is a local counterpart of llvm.global that takes a symbol reference to a global and produces an SSA value containing the pointer to it. Used in combination, these two operations allow one to use globals with other operations expecting SSA values. At a cost of IR indirection, we make sure the functions don't implicitly capture the surrounding SSA values and remain suitable for parallel processing. PiperOrigin-RevId: 262908622
2019-08-12 21:10:29 +08:00
// Check load from globals.
// CHECK: load i32, i32* @i32_global
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%0 = llvm.mlir.addressof @i32_global : !llvm<"i32*">
LLVM dialect: introduce llvm.addressof to access globals This instruction is a local counterpart of llvm.global that takes a symbol reference to a global and produces an SSA value containing the pointer to it. Used in combination, these two operations allow one to use globals with other operations expecting SSA values. At a cost of IR indirection, we make sure the functions don't implicitly capture the surrounding SSA values and remain suitable for parallel processing. PiperOrigin-RevId: 262908622
2019-08-12 21:10:29 +08:00
%1 = llvm.load %0 : !llvm<"i32*">
// Check the contracted form of load from array constants.
// CHECK: load i8, i8* getelementptr inbounds ([6 x i8], [6 x i8]* @string_const, i64 0, i64 0)
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%2 = llvm.mlir.addressof @string_const : !llvm<"[6 x i8]*">
%c0 = llvm.mlir.constant(0 : index) : !llvm.i64
LLVM dialect: introduce llvm.addressof to access globals This instruction is a local counterpart of llvm.global that takes a symbol reference to a global and produces an SSA value containing the pointer to it. Used in combination, these two operations allow one to use globals with other operations expecting SSA values. At a cost of IR indirection, we make sure the functions don't implicitly capture the surrounding SSA values and remain suitable for parallel processing. PiperOrigin-RevId: 262908622
2019-08-12 21:10:29 +08:00
%3 = llvm.getelementptr %2[%c0, %c0] : (!llvm<"[6 x i8]*">, !llvm.i64, !llvm.i64) -> !llvm<"i8*">
%4 = llvm.load %3 : !llvm<"i8*">
llvm.return
}
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
// CHECK-LABEL: declare void @body(i64)
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @body(!llvm.i64)
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
// CHECK-LABEL: define void @simple_loop() {
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @simple_loop() {
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
// CHECK: br label %[[SIMPLE_bb1:[0-9]+]]
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
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
// Constants are inlined in LLVM rather than a separate instruction.
Remove "<label>" from the llvm basic block CHECK names. PiperOrigin-RevId: 239898185
2019-03-23 08:54:26 +08:00
// CHECK: [[SIMPLE_bb1]]:
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
// CHECK-NEXT: br label %[[SIMPLE_bb2:[0-9]+]]
Reimplement LLVM IR translation to use the MLIR LLVM IR dialect Original implementation of the translation from MLIR to LLVM IR operated on the Standard+BuiltIn dialect, with a later addition of the SuperVector dialect. This required the translation to be aware of a potetially large number of other dialects as the infrastructure extended. With the recent introduction of the LLVM IR dialect into MLIR, the translation can be switched to only translate the LLVM IR dialect, and the translation of the operations becomes largely mechanical. The reimplementation of the translator follows the lines of the original translator in function and basic block conversion. In particular, block arguments are converted to LLVM IR PHI nodes, which are connected to their sources after all blocks of a function had been converted. Thanks to LLVM IR types being wrapped in the MLIR LLVM dialect type, type conversion is simplified to only convert function types, all other types are simply unwrapped. Individual instructions are constructed using the LLVM IRBuilder, which has a great potential for being table-generated from the LLVM IR dialect operation definitions. The input of the test/Target/llvmir.mlir is updated to use the MLIR LLVM IR dialect. While it is now redundant with the dialect conversion test, the point of the exercise is to guarantee exactly the same LLVM IR is emitted. (Only the name of the allocation function is changed from `__mlir_alloc` to `alloc` in the CHECK lines.) It will be simplified in a follow-up commit. PiperOrigin-RevId: 233842306
2019-02-14 07:30:24 +08:00
^bb1: // pred: ^bb0
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%0 = llvm.mlir.constant(1 : index) : !llvm.i64
%1 = llvm.mlir.constant(42 : index) : !llvm.i64
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
llvm.br ^bb2(%0 : !llvm.i64)
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
Remove "<label>" from the llvm basic block CHECK names. PiperOrigin-RevId: 239898185
2019-03-23 08:54:26 +08:00
// CHECK: [[SIMPLE_bb2]]:
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
// CHECK-NEXT: %{{[0-9]+}} = phi i64 [ %{{[0-9]+}}, %[[SIMPLE_bb3:[0-9]+]] ], [ 1, %[[SIMPLE_bb1]] ]
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
// CHECK-NEXT: %{{[0-9]+}} = icmp slt i64 %{{[0-9]+}}, 42
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
// CHECK-NEXT: br i1 %{{[0-9]+}}, label %[[SIMPLE_bb3]], label %[[SIMPLE_bb4:[0-9]+]]
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
^bb2(%2: !llvm.i64): // 2 preds: ^bb1, ^bb3
%3 = llvm.icmp "slt" %2, %1 : !llvm.i64
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.cond_br %3, ^bb3, ^bb4
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
Remove "<label>" from the llvm basic block CHECK names. PiperOrigin-RevId: 239898185
2019-03-23 08:54:26 +08:00
// CHECK: [[SIMPLE_bb3]]:
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
// CHECK-NEXT: call void @body(i64 %{{[0-9]+}})
// CHECK-NEXT: %{{[0-9]+}} = add i64 %{{[0-9]+}}, 1
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
// CHECK-NEXT: br label %[[SIMPLE_bb2]]
Reimplement LLVM IR translation to use the MLIR LLVM IR dialect Original implementation of the translation from MLIR to LLVM IR operated on the Standard+BuiltIn dialect, with a later addition of the SuperVector dialect. This required the translation to be aware of a potetially large number of other dialects as the infrastructure extended. With the recent introduction of the LLVM IR dialect into MLIR, the translation can be switched to only translate the LLVM IR dialect, and the translation of the operations becomes largely mechanical. The reimplementation of the translator follows the lines of the original translator in function and basic block conversion. In particular, block arguments are converted to LLVM IR PHI nodes, which are connected to their sources after all blocks of a function had been converted. Thanks to LLVM IR types being wrapped in the MLIR LLVM dialect type, type conversion is simplified to only convert function types, all other types are simply unwrapped. Individual instructions are constructed using the LLVM IRBuilder, which has a great potential for being table-generated from the LLVM IR dialect operation definitions. The input of the test/Target/llvmir.mlir is updated to use the MLIR LLVM IR dialect. While it is now redundant with the dialect conversion test, the point of the exercise is to guarantee exactly the same LLVM IR is emitted. (Only the name of the allocation function is changed from `__mlir_alloc` to `alloc` in the CHECK lines.) It will be simplified in a follow-up commit. PiperOrigin-RevId: 233842306
2019-02-14 07:30:24 +08:00
^bb3: // pred: ^bb2
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
llvm.call @body(%2) : (!llvm.i64) -> ()
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%4 = llvm.mlir.constant(1 : index) : !llvm.i64
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%5 = llvm.add %2, %4 : !llvm.i64
llvm.br ^bb2(%5 : !llvm.i64)
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
Remove "<label>" from the llvm basic block CHECK names. PiperOrigin-RevId: 239898185
2019-03-23 08:54:26 +08:00
// CHECK: [[SIMPLE_bb4]]:
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
// CHECK-NEXT: ret void
Reimplement LLVM IR translation to use the MLIR LLVM IR dialect Original implementation of the translation from MLIR to LLVM IR operated on the Standard+BuiltIn dialect, with a later addition of the SuperVector dialect. This required the translation to be aware of a potetially large number of other dialects as the infrastructure extended. With the recent introduction of the LLVM IR dialect into MLIR, the translation can be switched to only translate the LLVM IR dialect, and the translation of the operations becomes largely mechanical. The reimplementation of the translator follows the lines of the original translator in function and basic block conversion. In particular, block arguments are converted to LLVM IR PHI nodes, which are connected to their sources after all blocks of a function had been converted. Thanks to LLVM IR types being wrapped in the MLIR LLVM dialect type, type conversion is simplified to only convert function types, all other types are simply unwrapped. Individual instructions are constructed using the LLVM IRBuilder, which has a great potential for being table-generated from the LLVM IR dialect operation definitions. The input of the test/Target/llvmir.mlir is updated to use the MLIR LLVM IR dialect. While it is now redundant with the dialect conversion test, the point of the exercise is to guarantee exactly the same LLVM IR is emitted. (Only the name of the allocation function is changed from `__mlir_alloc` to `alloc` in the CHECK lines.) It will be simplified in a follow-up commit. PiperOrigin-RevId: 233842306
2019-02-14 07:30:24 +08:00
^bb4: // pred: ^bb2
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
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
}
// CHECK-LABEL: define void @simple_caller() {
// CHECK-NEXT: call void @simple_loop()
// CHECK-NEXT: ret void
// CHECK-NEXT: }
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @simple_caller() {
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.call @simple_loop() : () -> ()
llvm.return
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
}
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
//func @simple_indirect_caller() {
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
//^bb0:
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
// %f = constant @simple_loop : () -> ()
// call_indirect %f() : () -> ()
// return
//}
// CHECK-LABEL: define void @ml_caller() {
// CHECK-NEXT: call void @simple_loop()
// CHECK-NEXT: call void @more_imperfectly_nested_loops()
// CHECK-NEXT: ret void
// CHECK-NEXT: }
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @ml_caller() {
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.call @simple_loop() : () -> ()
llvm.call @more_imperfectly_nested_loops() : () -> ()
llvm.return
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
}
// CHECK-LABEL: declare i64 @body_args(i64)
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @body_args(!llvm.i64) -> !llvm.i64
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
// CHECK-LABEL: declare i32 @other(i64, i32)
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @other(!llvm.i64, !llvm.i32) -> !llvm.i32
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
[mlir-translate] Fix test suite. llvm ir printer was changed at LLVM r367755. Prints value numbers for unnamed functions argument. Closes tensorflow/mlir#67 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/67 from denis0x0D:sandbox/fix_mlir_translate ae46844e66f34a02e0cf86782ddadc5bce58b30d PiperOrigin-RevId: 261640048
2019-08-05 16:39:26 +08:00
// CHECK-LABEL: define i32 @func_args(i32 {{%.*}}, i32 {{%.*}}) {
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
// CHECK-NEXT: br label %[[ARGS_bb1:[0-9]+]]
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @func_args(%arg0: !llvm.i32, %arg1: !llvm.i32) -> !llvm.i32 {
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%0 = llvm.mlir.constant(0 : i32) : !llvm.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
llvm.br ^bb1
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
Remove "<label>" from the llvm basic block CHECK names. PiperOrigin-RevId: 239898185
2019-03-23 08:54:26 +08:00
// CHECK: [[ARGS_bb1]]:
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
// CHECK-NEXT: br label %[[ARGS_bb2:[0-9]+]]
Reimplement LLVM IR translation to use the MLIR LLVM IR dialect Original implementation of the translation from MLIR to LLVM IR operated on the Standard+BuiltIn dialect, with a later addition of the SuperVector dialect. This required the translation to be aware of a potetially large number of other dialects as the infrastructure extended. With the recent introduction of the LLVM IR dialect into MLIR, the translation can be switched to only translate the LLVM IR dialect, and the translation of the operations becomes largely mechanical. The reimplementation of the translator follows the lines of the original translator in function and basic block conversion. In particular, block arguments are converted to LLVM IR PHI nodes, which are connected to their sources after all blocks of a function had been converted. Thanks to LLVM IR types being wrapped in the MLIR LLVM dialect type, type conversion is simplified to only convert function types, all other types are simply unwrapped. Individual instructions are constructed using the LLVM IRBuilder, which has a great potential for being table-generated from the LLVM IR dialect operation definitions. The input of the test/Target/llvmir.mlir is updated to use the MLIR LLVM IR dialect. While it is now redundant with the dialect conversion test, the point of the exercise is to guarantee exactly the same LLVM IR is emitted. (Only the name of the allocation function is changed from `__mlir_alloc` to `alloc` in the CHECK lines.) It will be simplified in a follow-up commit. PiperOrigin-RevId: 233842306
2019-02-14 07:30:24 +08:00
^bb1: // pred: ^bb0
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%1 = llvm.mlir.constant(0 : index) : !llvm.i64
%2 = llvm.mlir.constant(42 : index) : !llvm.i64
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
llvm.br ^bb2(%1 : !llvm.i64)
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
Remove "<label>" from the llvm basic block CHECK names. PiperOrigin-RevId: 239898185
2019-03-23 08:54:26 +08:00
// CHECK: [[ARGS_bb2]]:
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
// CHECK-NEXT: %5 = phi i64 [ %12, %[[ARGS_bb3:[0-9]+]] ], [ 0, %[[ARGS_bb1]] ]
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
// CHECK-NEXT: %6 = icmp slt i64 %5, 42
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
// CHECK-NEXT: br i1 %6, label %[[ARGS_bb3]], label %[[ARGS_bb4:[0-9]+]]
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
^bb2(%3: !llvm.i64): // 2 preds: ^bb1, ^bb3
%4 = llvm.icmp "slt" %3, %2 : !llvm.i64
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.cond_br %4, ^bb3, ^bb4
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
Remove "<label>" from the llvm basic block CHECK names. PiperOrigin-RevId: 239898185
2019-03-23 08:54:26 +08:00
// CHECK: [[ARGS_bb3]]:
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
// CHECK-NEXT: %8 = call i64 @body_args(i64 %5)
// CHECK-NEXT: %9 = call i32 @other(i64 %8, i32 %0)
// CHECK-NEXT: %10 = call i32 @other(i64 %8, i32 %9)
// CHECK-NEXT: %11 = call i32 @other(i64 %8, i32 %1)
// CHECK-NEXT: %12 = add i64 %5, 1
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
// CHECK-NEXT: br label %[[ARGS_bb2]]
Reimplement LLVM IR translation to use the MLIR LLVM IR dialect Original implementation of the translation from MLIR to LLVM IR operated on the Standard+BuiltIn dialect, with a later addition of the SuperVector dialect. This required the translation to be aware of a potetially large number of other dialects as the infrastructure extended. With the recent introduction of the LLVM IR dialect into MLIR, the translation can be switched to only translate the LLVM IR dialect, and the translation of the operations becomes largely mechanical. The reimplementation of the translator follows the lines of the original translator in function and basic block conversion. In particular, block arguments are converted to LLVM IR PHI nodes, which are connected to their sources after all blocks of a function had been converted. Thanks to LLVM IR types being wrapped in the MLIR LLVM dialect type, type conversion is simplified to only convert function types, all other types are simply unwrapped. Individual instructions are constructed using the LLVM IRBuilder, which has a great potential for being table-generated from the LLVM IR dialect operation definitions. The input of the test/Target/llvmir.mlir is updated to use the MLIR LLVM IR dialect. While it is now redundant with the dialect conversion test, the point of the exercise is to guarantee exactly the same LLVM IR is emitted. (Only the name of the allocation function is changed from `__mlir_alloc` to `alloc` in the CHECK lines.) It will be simplified in a follow-up commit. PiperOrigin-RevId: 233842306
2019-02-14 07:30:24 +08:00
^bb3: // pred: ^bb2
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%5 = llvm.call @body_args(%3) : (!llvm.i64) -> !llvm.i64
%6 = llvm.call @other(%5, %arg0) : (!llvm.i64, !llvm.i32) -> !llvm.i32
%7 = llvm.call @other(%5, %6) : (!llvm.i64, !llvm.i32) -> !llvm.i32
%8 = llvm.call @other(%5, %arg1) : (!llvm.i64, !llvm.i32) -> !llvm.i32
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%9 = llvm.mlir.constant(1 : index) : !llvm.i64
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%10 = llvm.add %3, %9 : !llvm.i64
llvm.br ^bb2(%10 : !llvm.i64)
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
Remove "<label>" from the llvm basic block CHECK names. PiperOrigin-RevId: 239898185
2019-03-23 08:54:26 +08:00
// CHECK: [[ARGS_bb4]]:
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
// CHECK-NEXT: %14 = call i32 @other(i64 0, i32 0)
// CHECK-NEXT: ret i32 %14
Reimplement LLVM IR translation to use the MLIR LLVM IR dialect Original implementation of the translation from MLIR to LLVM IR operated on the Standard+BuiltIn dialect, with a later addition of the SuperVector dialect. This required the translation to be aware of a potetially large number of other dialects as the infrastructure extended. With the recent introduction of the LLVM IR dialect into MLIR, the translation can be switched to only translate the LLVM IR dialect, and the translation of the operations becomes largely mechanical. The reimplementation of the translator follows the lines of the original translator in function and basic block conversion. In particular, block arguments are converted to LLVM IR PHI nodes, which are connected to their sources after all blocks of a function had been converted. Thanks to LLVM IR types being wrapped in the MLIR LLVM dialect type, type conversion is simplified to only convert function types, all other types are simply unwrapped. Individual instructions are constructed using the LLVM IRBuilder, which has a great potential for being table-generated from the LLVM IR dialect operation definitions. The input of the test/Target/llvmir.mlir is updated to use the MLIR LLVM IR dialect. While it is now redundant with the dialect conversion test, the point of the exercise is to guarantee exactly the same LLVM IR is emitted. (Only the name of the allocation function is changed from `__mlir_alloc` to `alloc` in the CHECK lines.) It will be simplified in a follow-up commit. PiperOrigin-RevId: 233842306
2019-02-14 07:30:24 +08:00
^bb4: // pred: ^bb2
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%11 = llvm.mlir.constant(0 : index) : !llvm.i64
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%12 = llvm.call @other(%11, %0) : (!llvm.i64, !llvm.i32) -> !llvm.i32
llvm.return %12 : !llvm.i32
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
}
// CHECK: declare void @pre(i64)
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @pre(!llvm.i64)
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
// CHECK: declare void @body2(i64, i64)
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @body2(!llvm.i64, !llvm.i64)
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
// CHECK: declare void @post(i64)
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @post(!llvm.i64)
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
// CHECK-LABEL: define void @imperfectly_nested_loops() {
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
// CHECK-NEXT: br label %[[IMPER_bb1:[0-9]+]]
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @imperfectly_nested_loops() {
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
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
Remove "<label>" from the llvm basic block CHECK names. PiperOrigin-RevId: 239898185
2019-03-23 08:54:26 +08:00
// CHECK: [[IMPER_bb1]]:
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
// CHECK-NEXT: br label %[[IMPER_bb2:[0-9]+]]
Reimplement LLVM IR translation to use the MLIR LLVM IR dialect Original implementation of the translation from MLIR to LLVM IR operated on the Standard+BuiltIn dialect, with a later addition of the SuperVector dialect. This required the translation to be aware of a potetially large number of other dialects as the infrastructure extended. With the recent introduction of the LLVM IR dialect into MLIR, the translation can be switched to only translate the LLVM IR dialect, and the translation of the operations becomes largely mechanical. The reimplementation of the translator follows the lines of the original translator in function and basic block conversion. In particular, block arguments are converted to LLVM IR PHI nodes, which are connected to their sources after all blocks of a function had been converted. Thanks to LLVM IR types being wrapped in the MLIR LLVM dialect type, type conversion is simplified to only convert function types, all other types are simply unwrapped. Individual instructions are constructed using the LLVM IRBuilder, which has a great potential for being table-generated from the LLVM IR dialect operation definitions. The input of the test/Target/llvmir.mlir is updated to use the MLIR LLVM IR dialect. While it is now redundant with the dialect conversion test, the point of the exercise is to guarantee exactly the same LLVM IR is emitted. (Only the name of the allocation function is changed from `__mlir_alloc` to `alloc` in the CHECK lines.) It will be simplified in a follow-up commit. PiperOrigin-RevId: 233842306
2019-02-14 07:30:24 +08:00
^bb1: // pred: ^bb0
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%0 = llvm.mlir.constant(0 : index) : !llvm.i64
%1 = llvm.mlir.constant(42 : index) : !llvm.i64
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
llvm.br ^bb2(%0 : !llvm.i64)
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
Remove "<label>" from the llvm basic block CHECK names. PiperOrigin-RevId: 239898185
2019-03-23 08:54:26 +08:00
// CHECK: [[IMPER_bb2]]:
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
// CHECK-NEXT: %3 = phi i64 [ %13, %[[IMPER_bb7:[0-9]+]] ], [ 0, %[[IMPER_bb1]] ]
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
// CHECK-NEXT: %4 = icmp slt i64 %3, 42
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
// CHECK-NEXT: br i1 %4, label %[[IMPER_bb3:[0-9]+]], label %[[IMPER_bb8:[0-9]+]]
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
^bb2(%2: !llvm.i64): // 2 preds: ^bb1, ^bb7
%3 = llvm.icmp "slt" %2, %1 : !llvm.i64
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.cond_br %3, ^bb3, ^bb8
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
Remove "<label>" from the llvm basic block CHECK names. PiperOrigin-RevId: 239898185
2019-03-23 08:54:26 +08:00
// CHECK: [[IMPER_bb3]]:
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
// CHECK-NEXT: call void @pre(i64 %3)
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
// CHECK-NEXT: br label %[[IMPER_bb4:[0-9]+]]
Reimplement LLVM IR translation to use the MLIR LLVM IR dialect Original implementation of the translation from MLIR to LLVM IR operated on the Standard+BuiltIn dialect, with a later addition of the SuperVector dialect. This required the translation to be aware of a potetially large number of other dialects as the infrastructure extended. With the recent introduction of the LLVM IR dialect into MLIR, the translation can be switched to only translate the LLVM IR dialect, and the translation of the operations becomes largely mechanical. The reimplementation of the translator follows the lines of the original translator in function and basic block conversion. In particular, block arguments are converted to LLVM IR PHI nodes, which are connected to their sources after all blocks of a function had been converted. Thanks to LLVM IR types being wrapped in the MLIR LLVM dialect type, type conversion is simplified to only convert function types, all other types are simply unwrapped. Individual instructions are constructed using the LLVM IRBuilder, which has a great potential for being table-generated from the LLVM IR dialect operation definitions. The input of the test/Target/llvmir.mlir is updated to use the MLIR LLVM IR dialect. While it is now redundant with the dialect conversion test, the point of the exercise is to guarantee exactly the same LLVM IR is emitted. (Only the name of the allocation function is changed from `__mlir_alloc` to `alloc` in the CHECK lines.) It will be simplified in a follow-up commit. PiperOrigin-RevId: 233842306
2019-02-14 07:30:24 +08:00
^bb3: // pred: ^bb2
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
llvm.call @pre(%2) : (!llvm.i64) -> ()
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 ^bb4
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
Remove "<label>" from the llvm basic block CHECK names. PiperOrigin-RevId: 239898185
2019-03-23 08:54:26 +08:00
// CHECK: [[IMPER_bb4]]:
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
// CHECK-NEXT: br label %[[IMPER_bb5:[0-9]+]]
Reimplement LLVM IR translation to use the MLIR LLVM IR dialect Original implementation of the translation from MLIR to LLVM IR operated on the Standard+BuiltIn dialect, with a later addition of the SuperVector dialect. This required the translation to be aware of a potetially large number of other dialects as the infrastructure extended. With the recent introduction of the LLVM IR dialect into MLIR, the translation can be switched to only translate the LLVM IR dialect, and the translation of the operations becomes largely mechanical. The reimplementation of the translator follows the lines of the original translator in function and basic block conversion. In particular, block arguments are converted to LLVM IR PHI nodes, which are connected to their sources after all blocks of a function had been converted. Thanks to LLVM IR types being wrapped in the MLIR LLVM dialect type, type conversion is simplified to only convert function types, all other types are simply unwrapped. Individual instructions are constructed using the LLVM IRBuilder, which has a great potential for being table-generated from the LLVM IR dialect operation definitions. The input of the test/Target/llvmir.mlir is updated to use the MLIR LLVM IR dialect. While it is now redundant with the dialect conversion test, the point of the exercise is to guarantee exactly the same LLVM IR is emitted. (Only the name of the allocation function is changed from `__mlir_alloc` to `alloc` in the CHECK lines.) It will be simplified in a follow-up commit. PiperOrigin-RevId: 233842306
2019-02-14 07:30:24 +08:00
^bb4: // pred: ^bb3
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%4 = llvm.mlir.constant(7 : index) : !llvm.i64
%5 = llvm.mlir.constant(56 : index) : !llvm.i64
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
llvm.br ^bb5(%4 : !llvm.i64)
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
Remove "<label>" from the llvm basic block CHECK names. PiperOrigin-RevId: 239898185
2019-03-23 08:54:26 +08:00
// CHECK: [[IMPER_bb5]]:
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
// CHECK-NEXT: %8 = phi i64 [ %11, %[[IMPER_bb6:[0-9]+]] ], [ 7, %[[IMPER_bb4]] ]
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
// CHECK-NEXT: %9 = icmp slt i64 %8, 56
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
// CHECK-NEXT: br i1 %9, label %[[IMPER_bb6]], label %[[IMPER_bb7]]
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
^bb5(%6: !llvm.i64): // 2 preds: ^bb4, ^bb6
%7 = llvm.icmp "slt" %6, %5 : !llvm.i64
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.cond_br %7, ^bb6, ^bb7
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
Remove "<label>" from the llvm basic block CHECK names. PiperOrigin-RevId: 239898185
2019-03-23 08:54:26 +08:00
// CHECK: [[IMPER_bb6]]:
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
// CHECK-NEXT: call void @body2(i64 %3, i64 %8)
// CHECK-NEXT: %11 = add i64 %8, 2
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
// CHECK-NEXT: br label %[[IMPER_bb5]]
Reimplement LLVM IR translation to use the MLIR LLVM IR dialect Original implementation of the translation from MLIR to LLVM IR operated on the Standard+BuiltIn dialect, with a later addition of the SuperVector dialect. This required the translation to be aware of a potetially large number of other dialects as the infrastructure extended. With the recent introduction of the LLVM IR dialect into MLIR, the translation can be switched to only translate the LLVM IR dialect, and the translation of the operations becomes largely mechanical. The reimplementation of the translator follows the lines of the original translator in function and basic block conversion. In particular, block arguments are converted to LLVM IR PHI nodes, which are connected to their sources after all blocks of a function had been converted. Thanks to LLVM IR types being wrapped in the MLIR LLVM dialect type, type conversion is simplified to only convert function types, all other types are simply unwrapped. Individual instructions are constructed using the LLVM IRBuilder, which has a great potential for being table-generated from the LLVM IR dialect operation definitions. The input of the test/Target/llvmir.mlir is updated to use the MLIR LLVM IR dialect. While it is now redundant with the dialect conversion test, the point of the exercise is to guarantee exactly the same LLVM IR is emitted. (Only the name of the allocation function is changed from `__mlir_alloc` to `alloc` in the CHECK lines.) It will be simplified in a follow-up commit. PiperOrigin-RevId: 233842306
2019-02-14 07:30:24 +08:00
^bb6: // pred: ^bb5
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
llvm.call @body2(%2, %6) : (!llvm.i64, !llvm.i64) -> ()
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%8 = llvm.mlir.constant(2 : index) : !llvm.i64
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%9 = llvm.add %6, %8 : !llvm.i64
llvm.br ^bb5(%9 : !llvm.i64)
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
Remove "<label>" from the llvm basic block CHECK names. PiperOrigin-RevId: 239898185
2019-03-23 08:54:26 +08:00
// CHECK: [[IMPER_bb7]]:
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
// CHECK-NEXT: call void @post(i64 %3)
// CHECK-NEXT: %13 = add i64 %3, 1
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
// CHECK-NEXT: br label %[[IMPER_bb2]]
Reimplement LLVM IR translation to use the MLIR LLVM IR dialect Original implementation of the translation from MLIR to LLVM IR operated on the Standard+BuiltIn dialect, with a later addition of the SuperVector dialect. This required the translation to be aware of a potetially large number of other dialects as the infrastructure extended. With the recent introduction of the LLVM IR dialect into MLIR, the translation can be switched to only translate the LLVM IR dialect, and the translation of the operations becomes largely mechanical. The reimplementation of the translator follows the lines of the original translator in function and basic block conversion. In particular, block arguments are converted to LLVM IR PHI nodes, which are connected to their sources after all blocks of a function had been converted. Thanks to LLVM IR types being wrapped in the MLIR LLVM dialect type, type conversion is simplified to only convert function types, all other types are simply unwrapped. Individual instructions are constructed using the LLVM IRBuilder, which has a great potential for being table-generated from the LLVM IR dialect operation definitions. The input of the test/Target/llvmir.mlir is updated to use the MLIR LLVM IR dialect. While it is now redundant with the dialect conversion test, the point of the exercise is to guarantee exactly the same LLVM IR is emitted. (Only the name of the allocation function is changed from `__mlir_alloc` to `alloc` in the CHECK lines.) It will be simplified in a follow-up commit. PiperOrigin-RevId: 233842306
2019-02-14 07:30:24 +08:00
^bb7: // pred: ^bb5
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
llvm.call @post(%2) : (!llvm.i64) -> ()
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%10 = llvm.mlir.constant(1 : index) : !llvm.i64
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%11 = llvm.add %2, %10 : !llvm.i64
llvm.br ^bb2(%11 : !llvm.i64)
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
Remove "<label>" from the llvm basic block CHECK names. PiperOrigin-RevId: 239898185
2019-03-23 08:54:26 +08:00
// CHECK: [[IMPER_bb8]]:
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
// CHECK-NEXT: ret void
Reimplement LLVM IR translation to use the MLIR LLVM IR dialect Original implementation of the translation from MLIR to LLVM IR operated on the Standard+BuiltIn dialect, with a later addition of the SuperVector dialect. This required the translation to be aware of a potetially large number of other dialects as the infrastructure extended. With the recent introduction of the LLVM IR dialect into MLIR, the translation can be switched to only translate the LLVM IR dialect, and the translation of the operations becomes largely mechanical. The reimplementation of the translator follows the lines of the original translator in function and basic block conversion. In particular, block arguments are converted to LLVM IR PHI nodes, which are connected to their sources after all blocks of a function had been converted. Thanks to LLVM IR types being wrapped in the MLIR LLVM dialect type, type conversion is simplified to only convert function types, all other types are simply unwrapped. Individual instructions are constructed using the LLVM IRBuilder, which has a great potential for being table-generated from the LLVM IR dialect operation definitions. The input of the test/Target/llvmir.mlir is updated to use the MLIR LLVM IR dialect. While it is now redundant with the dialect conversion test, the point of the exercise is to guarantee exactly the same LLVM IR is emitted. (Only the name of the allocation function is changed from `__mlir_alloc` to `alloc` in the CHECK lines.) It will be simplified in a follow-up commit. PiperOrigin-RevId: 233842306
2019-02-14 07:30:24 +08:00
^bb8: // pred: ^bb2
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
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
}
// CHECK: declare void @mid(i64)
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @mid(!llvm.i64)
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
// CHECK: declare void @body3(i64, i64)
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @body3(!llvm.i64, !llvm.i64)
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
// A complete function transformation check.
// CHECK-LABEL: define void @more_imperfectly_nested_loops() {
// CHECK-NEXT: br label %1
Remove "<label>" from the llvm basic block CHECK names. PiperOrigin-RevId: 239898185
2019-03-23 08:54:26 +08:00
// CHECK: 1: ; preds = %0
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
// CHECK-NEXT: br label %2
Remove "<label>" from the llvm basic block CHECK names. PiperOrigin-RevId: 239898185
2019-03-23 08:54:26 +08:00
// CHECK: 2: ; preds = %19, %1
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
// CHECK-NEXT: %3 = phi i64 [ %20, %19 ], [ 0, %1 ]
// CHECK-NEXT: %4 = icmp slt i64 %3, 42
// CHECK-NEXT: br i1 %4, label %5, label %21
Remove "<label>" from the llvm basic block CHECK names. PiperOrigin-RevId: 239898185
2019-03-23 08:54:26 +08:00
// CHECK: 5: ; preds = %2
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
// CHECK-NEXT: call void @pre(i64 %3)
// CHECK-NEXT: br label %6
Remove "<label>" from the llvm basic block CHECK names. PiperOrigin-RevId: 239898185
2019-03-23 08:54:26 +08:00
// CHECK: 6: ; preds = %5
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
// CHECK-NEXT: br label %7
Remove "<label>" from the llvm basic block CHECK names. PiperOrigin-RevId: 239898185
2019-03-23 08:54:26 +08:00
// CHECK: 7: ; preds = %10, %6
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
// CHECK-NEXT: %8 = phi i64 [ %11, %10 ], [ 7, %6 ]
// CHECK-NEXT: %9 = icmp slt i64 %8, 56
// CHECK-NEXT: br i1 %9, label %10, label %12
Remove "<label>" from the llvm basic block CHECK names. PiperOrigin-RevId: 239898185
2019-03-23 08:54:26 +08:00
// CHECK: 10: ; preds = %7
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
// CHECK-NEXT: call void @body2(i64 %3, i64 %8)
// CHECK-NEXT: %11 = add i64 %8, 2
// CHECK-NEXT: br label %7
Remove "<label>" from the llvm basic block CHECK names. PiperOrigin-RevId: 239898185
2019-03-23 08:54:26 +08:00
// CHECK: 12: ; preds = %7
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
// CHECK-NEXT: call void @mid(i64 %3)
// CHECK-NEXT: br label %13
Remove "<label>" from the llvm basic block CHECK names. PiperOrigin-RevId: 239898185
2019-03-23 08:54:26 +08:00
// CHECK: 13: ; preds = %12
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
// CHECK-NEXT: br label %14
Remove "<label>" from the llvm basic block CHECK names. PiperOrigin-RevId: 239898185
2019-03-23 08:54:26 +08:00
// CHECK: 14: ; preds = %17, %13
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
// CHECK-NEXT: %15 = phi i64 [ %18, %17 ], [ 18, %13 ]
// CHECK-NEXT: %16 = icmp slt i64 %15, 37
// CHECK-NEXT: br i1 %16, label %17, label %19
Remove "<label>" from the llvm basic block CHECK names. PiperOrigin-RevId: 239898185
2019-03-23 08:54:26 +08:00
// CHECK: 17: ; preds = %14
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
// CHECK-NEXT: call void @body3(i64 %3, i64 %15)
// CHECK-NEXT: %18 = add i64 %15, 3
// CHECK-NEXT: br label %14
Remove "<label>" from the llvm basic block CHECK names. PiperOrigin-RevId: 239898185
2019-03-23 08:54:26 +08:00
// CHECK: 19: ; preds = %14
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
// CHECK-NEXT: call void @post(i64 %3)
// CHECK-NEXT: %20 = add i64 %3, 1
// CHECK-NEXT: br label %2
Remove "<label>" from the llvm basic block CHECK names. PiperOrigin-RevId: 239898185
2019-03-23 08:54:26 +08:00
// CHECK: 21: ; preds = %2
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
// CHECK-NEXT: ret void
// CHECK-NEXT: }
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @more_imperfectly_nested_loops() {
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
^bb1: // pred: ^bb0
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%0 = llvm.mlir.constant(0 : index) : !llvm.i64
%1 = llvm.mlir.constant(42 : index) : !llvm.i64
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
llvm.br ^bb2(%0 : !llvm.i64)
^bb2(%2: !llvm.i64): // 2 preds: ^bb1, ^bb11
%3 = llvm.icmp "slt" %2, %1 : !llvm.i64
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.cond_br %3, ^bb3, ^bb12
^bb3: // pred: ^bb2
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
llvm.call @pre(%2) : (!llvm.i64) -> ()
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 ^bb4
^bb4: // pred: ^bb3
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%4 = llvm.mlir.constant(7 : index) : !llvm.i64
%5 = llvm.mlir.constant(56 : index) : !llvm.i64
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
llvm.br ^bb5(%4 : !llvm.i64)
^bb5(%6: !llvm.i64): // 2 preds: ^bb4, ^bb6
%7 = llvm.icmp "slt" %6, %5 : !llvm.i64
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.cond_br %7, ^bb6, ^bb7
^bb6: // pred: ^bb5
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
llvm.call @body2(%2, %6) : (!llvm.i64, !llvm.i64) -> ()
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%8 = llvm.mlir.constant(2 : index) : !llvm.i64
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%9 = llvm.add %6, %8 : !llvm.i64
llvm.br ^bb5(%9 : !llvm.i64)
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
^bb7: // pred: ^bb5
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
llvm.call @mid(%2) : (!llvm.i64) -> ()
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 ^bb8
^bb8: // pred: ^bb7
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%10 = llvm.mlir.constant(18 : index) : !llvm.i64
%11 = llvm.mlir.constant(37 : index) : !llvm.i64
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
llvm.br ^bb9(%10 : !llvm.i64)
^bb9(%12: !llvm.i64): // 2 preds: ^bb8, ^bb10
%13 = llvm.icmp "slt" %12, %11 : !llvm.i64
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.cond_br %13, ^bb10, ^bb11
^bb10: // pred: ^bb9
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
llvm.call @body3(%2, %12) : (!llvm.i64, !llvm.i64) -> ()
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%14 = llvm.mlir.constant(3 : index) : !llvm.i64
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%15 = llvm.add %12, %14 : !llvm.i64
llvm.br ^bb9(%15 : !llvm.i64)
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
^bb11: // pred: ^bb9
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
llvm.call @post(%2) : (!llvm.i64) -> ()
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%16 = llvm.mlir.constant(1 : index) : !llvm.i64
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%17 = llvm.add %2, %16 : !llvm.i64
llvm.br ^bb2(%17 : !llvm.i64)
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
^bb12: // pred: ^bb2
llvm.return
Lower scalar parts of CFG functions to LLVM IR Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
2018-11-21 22:37:49 +08:00
}
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
//
// MemRef type conversion, allocation and communication with functions.
//
// CHECK-LABEL: define void @memref_alloc()
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @memref_alloc() {
Reimplement LLVM IR translation to use the MLIR LLVM IR dialect Original implementation of the translation from MLIR to LLVM IR operated on the Standard+BuiltIn dialect, with a later addition of the SuperVector dialect. This required the translation to be aware of a potetially large number of other dialects as the infrastructure extended. With the recent introduction of the LLVM IR dialect into MLIR, the translation can be switched to only translate the LLVM IR dialect, and the translation of the operations becomes largely mechanical. The reimplementation of the translator follows the lines of the original translator in function and basic block conversion. In particular, block arguments are converted to LLVM IR PHI nodes, which are connected to their sources after all blocks of a function had been converted. Thanks to LLVM IR types being wrapped in the MLIR LLVM dialect type, type conversion is simplified to only convert function types, all other types are simply unwrapped. Individual instructions are constructed using the LLVM IRBuilder, which has a great potential for being table-generated from the LLVM IR dialect operation definitions. The input of the test/Target/llvmir.mlir is updated to use the MLIR LLVM IR dialect. While it is now redundant with the dialect conversion test, the point of the exercise is to guarantee exactly the same LLVM IR is emitted. (Only the name of the allocation function is changed from `__mlir_alloc` to `alloc` in the CHECK lines.) It will be simplified in a follow-up commit. PiperOrigin-RevId: 233842306
2019-02-14 07:30:24 +08:00
// CHECK-NEXT: %{{[0-9]+}} = call i8* @malloc(i64 400)
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK-NEXT: %{{[0-9]+}} = bitcast i8* %{{[0-9]+}} to float*
// CHECK-NEXT: %{{[0-9]+}} = insertvalue { float* } undef, float* %{{[0-9]+}}, 0
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%0 = llvm.mlir.constant(10 : index) : !llvm.i64
%1 = llvm.mlir.constant(10 : index) : !llvm.i64
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%2 = llvm.mul %0, %1 : !llvm.i64
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%3 = llvm.mlir.undef : !llvm<"{ float* }">
%4 = llvm.mlir.constant(4 : index) : !llvm.i64
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%5 = llvm.mul %2, %4 : !llvm.i64
%6 = llvm.call @malloc(%5) : (!llvm.i64) -> !llvm<"i8*">
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
%7 = llvm.bitcast %6 : !llvm<"i8*"> to !llvm<"float*">
%8 = llvm.insertvalue %7, %3[0] : !llvm<"{ float* }">
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK-NEXT: ret void
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
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
}
// CHECK-LABEL: declare i64 @get_index()
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @get_index() -> !llvm.i64
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK-LABEL: define void @store_load_static()
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @store_load_static() {
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
^bb0:
Reimplement LLVM IR translation to use the MLIR LLVM IR dialect Original implementation of the translation from MLIR to LLVM IR operated on the Standard+BuiltIn dialect, with a later addition of the SuperVector dialect. This required the translation to be aware of a potetially large number of other dialects as the infrastructure extended. With the recent introduction of the LLVM IR dialect into MLIR, the translation can be switched to only translate the LLVM IR dialect, and the translation of the operations becomes largely mechanical. The reimplementation of the translator follows the lines of the original translator in function and basic block conversion. In particular, block arguments are converted to LLVM IR PHI nodes, which are connected to their sources after all blocks of a function had been converted. Thanks to LLVM IR types being wrapped in the MLIR LLVM dialect type, type conversion is simplified to only convert function types, all other types are simply unwrapped. Individual instructions are constructed using the LLVM IRBuilder, which has a great potential for being table-generated from the LLVM IR dialect operation definitions. The input of the test/Target/llvmir.mlir is updated to use the MLIR LLVM IR dialect. While it is now redundant with the dialect conversion test, the point of the exercise is to guarantee exactly the same LLVM IR is emitted. (Only the name of the allocation function is changed from `__mlir_alloc` to `alloc` in the CHECK lines.) It will be simplified in a follow-up commit. PiperOrigin-RevId: 233842306
2019-02-14 07:30:24 +08:00
// CHECK-NEXT: %{{[0-9]+}} = call i8* @malloc(i64 40)
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK-NEXT: %{{[0-9]+}} = bitcast i8* %{{[0-9]+}} to float*
// CHECK-NEXT: %{{[0-9]+}} = insertvalue { float* } undef, float* %{{[0-9]+}}, 0
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%0 = llvm.mlir.constant(10 : index) : !llvm.i64
%1 = llvm.mlir.undef : !llvm<"{ float* }">
%2 = llvm.mlir.constant(4 : index) : !llvm.i64
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%3 = llvm.mul %0, %2 : !llvm.i64
%4 = llvm.call @malloc(%3) : (!llvm.i64) -> !llvm<"i8*">
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
%5 = llvm.bitcast %4 : !llvm<"i8*"> to !llvm<"float*">
%6 = llvm.insertvalue %5, %1[0] : !llvm<"{ float* }">
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%7 = llvm.mlir.constant(1.000000e+00 : f32) : !llvm.float
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
Reimplement LLVM IR translation to use the MLIR LLVM IR dialect Original implementation of the translation from MLIR to LLVM IR operated on the Standard+BuiltIn dialect, with a later addition of the SuperVector dialect. This required the translation to be aware of a potetially large number of other dialects as the infrastructure extended. With the recent introduction of the LLVM IR dialect into MLIR, the translation can be switched to only translate the LLVM IR dialect, and the translation of the operations becomes largely mechanical. The reimplementation of the translator follows the lines of the original translator in function and basic block conversion. In particular, block arguments are converted to LLVM IR PHI nodes, which are connected to their sources after all blocks of a function had been converted. Thanks to LLVM IR types being wrapped in the MLIR LLVM dialect type, type conversion is simplified to only convert function types, all other types are simply unwrapped. Individual instructions are constructed using the LLVM IRBuilder, which has a great potential for being table-generated from the LLVM IR dialect operation definitions. The input of the test/Target/llvmir.mlir is updated to use the MLIR LLVM IR dialect. While it is now redundant with the dialect conversion test, the point of the exercise is to guarantee exactly the same LLVM IR is emitted. (Only the name of the allocation function is changed from `__mlir_alloc` to `alloc` in the CHECK lines.) It will be simplified in a follow-up commit. PiperOrigin-RevId: 233842306
2019-02-14 07:30:24 +08:00
^bb1: // pred: ^bb0
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%8 = llvm.mlir.constant(0 : index) : !llvm.i64
%9 = llvm.mlir.constant(10 : index) : !llvm.i64
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
llvm.br ^bb2(%8 : !llvm.i64)
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK: %{{[0-9]+}} = phi i64 [ %{{[0-9]+}}, %{{[0-9]+}} ], [ 0, %{{[0-9]+}} ]
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
^bb2(%10: !llvm.i64): // 2 preds: ^bb1, ^bb3
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK-NEXT: %{{[0-9]+}} = icmp slt i64 %{{[0-9]+}}, 10
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%11 = llvm.icmp "slt" %10, %9 : !llvm.i64
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK-NEXT: br i1 %{{[0-9]+}}, label %{{[0-9]+}}, label %{{[0-9]+}}
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.cond_br %11, ^bb3, ^bb4
Reimplement LLVM IR translation to use the MLIR LLVM IR dialect Original implementation of the translation from MLIR to LLVM IR operated on the Standard+BuiltIn dialect, with a later addition of the SuperVector dialect. This required the translation to be aware of a potetially large number of other dialects as the infrastructure extended. With the recent introduction of the LLVM IR dialect into MLIR, the translation can be switched to only translate the LLVM IR dialect, and the translation of the operations becomes largely mechanical. The reimplementation of the translator follows the lines of the original translator in function and basic block conversion. In particular, block arguments are converted to LLVM IR PHI nodes, which are connected to their sources after all blocks of a function had been converted. Thanks to LLVM IR types being wrapped in the MLIR LLVM dialect type, type conversion is simplified to only convert function types, all other types are simply unwrapped. Individual instructions are constructed using the LLVM IRBuilder, which has a great potential for being table-generated from the LLVM IR dialect operation definitions. The input of the test/Target/llvmir.mlir is updated to use the MLIR LLVM IR dialect. While it is now redundant with the dialect conversion test, the point of the exercise is to guarantee exactly the same LLVM IR is emitted. (Only the name of the allocation function is changed from `__mlir_alloc` to `alloc` in the CHECK lines.) It will be simplified in a follow-up commit. PiperOrigin-RevId: 233842306
2019-02-14 07:30:24 +08:00
^bb3: // pred: ^bb2
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK: %{{[0-9]+}} = extractvalue { float* } %{{[0-9]+}}, 0
// CHECK-NEXT: %{{[0-9]+}} = getelementptr float, float* %{{[0-9]+}}, i64 %{{[0-9]+}}
// CHECK-NEXT: store float 1.000000e+00, float* %{{[0-9]+}}
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%12 = llvm.mlir.constant(10 : index) : !llvm.i64
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
%13 = llvm.extractvalue %6[0] : !llvm<"{ float* }">
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%14 = llvm.getelementptr %13[%10] : (!llvm<"float*">, !llvm.i64) -> !llvm<"float*">
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.store %7, %14 : !llvm<"float*">
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%15 = llvm.mlir.constant(1 : index) : !llvm.i64
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK-NEXT: %{{[0-9]+}} = add i64 %{{[0-9]+}}, 1
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%16 = llvm.add %10, %15 : !llvm.i64
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK-NEXT: br label %{{[0-9]+}}
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
llvm.br ^bb2(%16 : !llvm.i64)
Reimplement LLVM IR translation to use the MLIR LLVM IR dialect Original implementation of the translation from MLIR to LLVM IR operated on the Standard+BuiltIn dialect, with a later addition of the SuperVector dialect. This required the translation to be aware of a potetially large number of other dialects as the infrastructure extended. With the recent introduction of the LLVM IR dialect into MLIR, the translation can be switched to only translate the LLVM IR dialect, and the translation of the operations becomes largely mechanical. The reimplementation of the translator follows the lines of the original translator in function and basic block conversion. In particular, block arguments are converted to LLVM IR PHI nodes, which are connected to their sources after all blocks of a function had been converted. Thanks to LLVM IR types being wrapped in the MLIR LLVM dialect type, type conversion is simplified to only convert function types, all other types are simply unwrapped. Individual instructions are constructed using the LLVM IRBuilder, which has a great potential for being table-generated from the LLVM IR dialect operation definitions. The input of the test/Target/llvmir.mlir is updated to use the MLIR LLVM IR dialect. While it is now redundant with the dialect conversion test, the point of the exercise is to guarantee exactly the same LLVM IR is emitted. (Only the name of the allocation function is changed from `__mlir_alloc` to `alloc` in the CHECK lines.) It will be simplified in a follow-up commit. PiperOrigin-RevId: 233842306
2019-02-14 07:30:24 +08:00
^bb4: // pred: ^bb2
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 ^bb5
Reimplement LLVM IR translation to use the MLIR LLVM IR dialect Original implementation of the translation from MLIR to LLVM IR operated on the Standard+BuiltIn dialect, with a later addition of the SuperVector dialect. This required the translation to be aware of a potetially large number of other dialects as the infrastructure extended. With the recent introduction of the LLVM IR dialect into MLIR, the translation can be switched to only translate the LLVM IR dialect, and the translation of the operations becomes largely mechanical. The reimplementation of the translator follows the lines of the original translator in function and basic block conversion. In particular, block arguments are converted to LLVM IR PHI nodes, which are connected to their sources after all blocks of a function had been converted. Thanks to LLVM IR types being wrapped in the MLIR LLVM dialect type, type conversion is simplified to only convert function types, all other types are simply unwrapped. Individual instructions are constructed using the LLVM IRBuilder, which has a great potential for being table-generated from the LLVM IR dialect operation definitions. The input of the test/Target/llvmir.mlir is updated to use the MLIR LLVM IR dialect. While it is now redundant with the dialect conversion test, the point of the exercise is to guarantee exactly the same LLVM IR is emitted. (Only the name of the allocation function is changed from `__mlir_alloc` to `alloc` in the CHECK lines.) It will be simplified in a follow-up commit. PiperOrigin-RevId: 233842306
2019-02-14 07:30:24 +08:00
^bb5: // pred: ^bb4
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%17 = llvm.mlir.constant(0 : index) : !llvm.i64
%18 = llvm.mlir.constant(10 : index) : !llvm.i64
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
llvm.br ^bb6(%17 : !llvm.i64)
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK: %{{[0-9]+}} = phi i64 [ %{{[0-9]+}}, %{{[0-9]+}} ], [ 0, %{{[0-9]+}} ]
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
^bb6(%19: !llvm.i64): // 2 preds: ^bb5, ^bb7
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK-NEXT: %{{[0-9]+}} = icmp slt i64 %{{[0-9]+}}, 10
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%20 = llvm.icmp "slt" %19, %18 : !llvm.i64
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK-NEXT: br i1 %{{[0-9]+}}, label %{{[0-9]+}}, label %{{[0-9]+}}
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.cond_br %20, ^bb7, ^bb8
Reimplement LLVM IR translation to use the MLIR LLVM IR dialect Original implementation of the translation from MLIR to LLVM IR operated on the Standard+BuiltIn dialect, with a later addition of the SuperVector dialect. This required the translation to be aware of a potetially large number of other dialects as the infrastructure extended. With the recent introduction of the LLVM IR dialect into MLIR, the translation can be switched to only translate the LLVM IR dialect, and the translation of the operations becomes largely mechanical. The reimplementation of the translator follows the lines of the original translator in function and basic block conversion. In particular, block arguments are converted to LLVM IR PHI nodes, which are connected to their sources after all blocks of a function had been converted. Thanks to LLVM IR types being wrapped in the MLIR LLVM dialect type, type conversion is simplified to only convert function types, all other types are simply unwrapped. Individual instructions are constructed using the LLVM IRBuilder, which has a great potential for being table-generated from the LLVM IR dialect operation definitions. The input of the test/Target/llvmir.mlir is updated to use the MLIR LLVM IR dialect. While it is now redundant with the dialect conversion test, the point of the exercise is to guarantee exactly the same LLVM IR is emitted. (Only the name of the allocation function is changed from `__mlir_alloc` to `alloc` in the CHECK lines.) It will be simplified in a follow-up commit. PiperOrigin-RevId: 233842306
2019-02-14 07:30:24 +08:00
^bb7: // pred: ^bb6
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK: %{{[0-9]+}} = extractvalue { float* } %{{[0-9]+}}, 0
// CHECK-NEXT: %{{[0-9]+}} = getelementptr float, float* %{{[0-9]+}}, i64 %{{[0-9]+}}
// CHECK-NEXT: %{{[0-9]+}} = load float, float* %{{[0-9]+}}
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%21 = llvm.mlir.constant(10 : index) : !llvm.i64
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
%22 = llvm.extractvalue %6[0] : !llvm<"{ float* }">
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%23 = llvm.getelementptr %22[%19] : (!llvm<"float*">, !llvm.i64) -> !llvm<"float*">
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
%24 = llvm.load %23 : !llvm<"float*">
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%25 = llvm.mlir.constant(1 : index) : !llvm.i64
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK-NEXT: %{{[0-9]+}} = add i64 %{{[0-9]+}}, 1
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%26 = llvm.add %19, %25 : !llvm.i64
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK-NEXT: br label %{{[0-9]+}}
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
llvm.br ^bb6(%26 : !llvm.i64)
Reimplement LLVM IR translation to use the MLIR LLVM IR dialect Original implementation of the translation from MLIR to LLVM IR operated on the Standard+BuiltIn dialect, with a later addition of the SuperVector dialect. This required the translation to be aware of a potetially large number of other dialects as the infrastructure extended. With the recent introduction of the LLVM IR dialect into MLIR, the translation can be switched to only translate the LLVM IR dialect, and the translation of the operations becomes largely mechanical. The reimplementation of the translator follows the lines of the original translator in function and basic block conversion. In particular, block arguments are converted to LLVM IR PHI nodes, which are connected to their sources after all blocks of a function had been converted. Thanks to LLVM IR types being wrapped in the MLIR LLVM dialect type, type conversion is simplified to only convert function types, all other types are simply unwrapped. Individual instructions are constructed using the LLVM IRBuilder, which has a great potential for being table-generated from the LLVM IR dialect operation definitions. The input of the test/Target/llvmir.mlir is updated to use the MLIR LLVM IR dialect. While it is now redundant with the dialect conversion test, the point of the exercise is to guarantee exactly the same LLVM IR is emitted. (Only the name of the allocation function is changed from `__mlir_alloc` to `alloc` in the CHECK lines.) It will be simplified in a follow-up commit. PiperOrigin-RevId: 233842306
2019-02-14 07:30:24 +08:00
^bb8: // pred: ^bb6
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK: ret void
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
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
}
[mlir-translate] Fix test suite. llvm ir printer was changed at LLVM r367755. Prints value numbers for unnamed functions argument. Closes tensorflow/mlir#67 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/67 from denis0x0D:sandbox/fix_mlir_translate ae46844e66f34a02e0cf86782ddadc5bce58b30d PiperOrigin-RevId: 261640048
2019-08-05 16:39:26 +08:00
// CHECK-LABEL: define void @store_load_dynamic(i64 {{%.*}})
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @store_load_dynamic(%arg0: !llvm.i64) {
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK-NEXT: %{{[0-9]+}} = mul i64 %{{[0-9]+}}, 4
Reimplement LLVM IR translation to use the MLIR LLVM IR dialect Original implementation of the translation from MLIR to LLVM IR operated on the Standard+BuiltIn dialect, with a later addition of the SuperVector dialect. This required the translation to be aware of a potetially large number of other dialects as the infrastructure extended. With the recent introduction of the LLVM IR dialect into MLIR, the translation can be switched to only translate the LLVM IR dialect, and the translation of the operations becomes largely mechanical. The reimplementation of the translator follows the lines of the original translator in function and basic block conversion. In particular, block arguments are converted to LLVM IR PHI nodes, which are connected to their sources after all blocks of a function had been converted. Thanks to LLVM IR types being wrapped in the MLIR LLVM dialect type, type conversion is simplified to only convert function types, all other types are simply unwrapped. Individual instructions are constructed using the LLVM IRBuilder, which has a great potential for being table-generated from the LLVM IR dialect operation definitions. The input of the test/Target/llvmir.mlir is updated to use the MLIR LLVM IR dialect. While it is now redundant with the dialect conversion test, the point of the exercise is to guarantee exactly the same LLVM IR is emitted. (Only the name of the allocation function is changed from `__mlir_alloc` to `alloc` in the CHECK lines.) It will be simplified in a follow-up commit. PiperOrigin-RevId: 233842306
2019-02-14 07:30:24 +08:00
// CHECK-NEXT: %{{[0-9]+}} = call i8* @malloc(i64 %{{[0-9]+}})
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK-NEXT: %{{[0-9]+}} = bitcast i8* %{{[0-9]+}} to float*
// CHECK-NEXT: %{{[0-9]+}} = insertvalue { float*, i64 } undef, float* %{{[0-9]+}}, 0
// CHECK-NEXT: %{{[0-9]+}} = insertvalue { float*, i64 } %{{[0-9]+}}, i64 %{{[0-9]+}}, 1
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%0 = llvm.mlir.undef : !llvm<"{ float*, i64 }">
%1 = llvm.mlir.constant(4 : index) : !llvm.i64
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%2 = llvm.mul %arg0, %1 : !llvm.i64
%3 = llvm.call @malloc(%2) : (!llvm.i64) -> !llvm<"i8*">
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
%4 = llvm.bitcast %3 : !llvm<"i8*"> to !llvm<"float*">
%5 = llvm.insertvalue %4, %0[0] : !llvm<"{ float*, i64 }">
%6 = llvm.insertvalue %arg0, %5[1] : !llvm<"{ float*, i64 }">
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%7 = llvm.mlir.constant(1.000000e+00 : f32) : !llvm.float
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK-NEXT: br label %{{[0-9]+}}
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
Reimplement LLVM IR translation to use the MLIR LLVM IR dialect Original implementation of the translation from MLIR to LLVM IR operated on the Standard+BuiltIn dialect, with a later addition of the SuperVector dialect. This required the translation to be aware of a potetially large number of other dialects as the infrastructure extended. With the recent introduction of the LLVM IR dialect into MLIR, the translation can be switched to only translate the LLVM IR dialect, and the translation of the operations becomes largely mechanical. The reimplementation of the translator follows the lines of the original translator in function and basic block conversion. In particular, block arguments are converted to LLVM IR PHI nodes, which are connected to their sources after all blocks of a function had been converted. Thanks to LLVM IR types being wrapped in the MLIR LLVM dialect type, type conversion is simplified to only convert function types, all other types are simply unwrapped. Individual instructions are constructed using the LLVM IRBuilder, which has a great potential for being table-generated from the LLVM IR dialect operation definitions. The input of the test/Target/llvmir.mlir is updated to use the MLIR LLVM IR dialect. While it is now redundant with the dialect conversion test, the point of the exercise is to guarantee exactly the same LLVM IR is emitted. (Only the name of the allocation function is changed from `__mlir_alloc` to `alloc` in the CHECK lines.) It will be simplified in a follow-up commit. PiperOrigin-RevId: 233842306
2019-02-14 07:30:24 +08:00
^bb1: // pred: ^bb0
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%8 = llvm.mlir.constant(0 : index) : !llvm.i64
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
llvm.br ^bb2(%8 : !llvm.i64)
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK: %{{[0-9]+}} = phi i64 [ %{{[0-9]+}}, %{{[0-9]+}} ], [ 0, %{{[0-9]+}} ]
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
^bb2(%9: !llvm.i64): // 2 preds: ^bb1, ^bb3
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK-NEXT: %{{[0-9]+}} = icmp slt i64 %{{[0-9]+}}, %{{[0-9]+}}
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%10 = llvm.icmp "slt" %9, %arg0 : !llvm.i64
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK-NEXT: br i1 %{{[0-9]+}}, label %{{[0-9]+}}, label %{{[0-9]+}}
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.cond_br %10, ^bb3, ^bb4
Reimplement LLVM IR translation to use the MLIR LLVM IR dialect Original implementation of the translation from MLIR to LLVM IR operated on the Standard+BuiltIn dialect, with a later addition of the SuperVector dialect. This required the translation to be aware of a potetially large number of other dialects as the infrastructure extended. With the recent introduction of the LLVM IR dialect into MLIR, the translation can be switched to only translate the LLVM IR dialect, and the translation of the operations becomes largely mechanical. The reimplementation of the translator follows the lines of the original translator in function and basic block conversion. In particular, block arguments are converted to LLVM IR PHI nodes, which are connected to their sources after all blocks of a function had been converted. Thanks to LLVM IR types being wrapped in the MLIR LLVM dialect type, type conversion is simplified to only convert function types, all other types are simply unwrapped. Individual instructions are constructed using the LLVM IRBuilder, which has a great potential for being table-generated from the LLVM IR dialect operation definitions. The input of the test/Target/llvmir.mlir is updated to use the MLIR LLVM IR dialect. While it is now redundant with the dialect conversion test, the point of the exercise is to guarantee exactly the same LLVM IR is emitted. (Only the name of the allocation function is changed from `__mlir_alloc` to `alloc` in the CHECK lines.) It will be simplified in a follow-up commit. PiperOrigin-RevId: 233842306
2019-02-14 07:30:24 +08:00
^bb3: // pred: ^bb2
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK: %{{[0-9]+}} = extractvalue { float*, i64 } %{{[0-9]+}}, 1
// CHECK-NEXT: %{{[0-9]+}} = extractvalue { float*, i64 } %{{[0-9]+}}, 0
// CHECK-NEXT: %{{[0-9]+}} = getelementptr float, float* %{{[0-9]+}}, i64 %{{[0-9]+}}
// CHECK-NEXT: store float 1.000000e+00, float* %{{[0-9]+}}
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
%11 = llvm.extractvalue %6[1] : !llvm<"{ float*, i64 }">
%12 = llvm.extractvalue %6[0] : !llvm<"{ float*, i64 }">
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%13 = llvm.getelementptr %12[%9] : (!llvm<"float*">, !llvm.i64) -> !llvm<"float*">
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.store %7, %13 : !llvm<"float*">
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%14 = llvm.mlir.constant(1 : index) : !llvm.i64
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK-NEXT: %{{[0-9]+}} = add i64 %{{[0-9]+}}, 1
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%15 = llvm.add %9, %14 : !llvm.i64
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK-NEXT: br label %{{[0-9]+}}
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
llvm.br ^bb2(%15 : !llvm.i64)
Reimplement LLVM IR translation to use the MLIR LLVM IR dialect Original implementation of the translation from MLIR to LLVM IR operated on the Standard+BuiltIn dialect, with a later addition of the SuperVector dialect. This required the translation to be aware of a potetially large number of other dialects as the infrastructure extended. With the recent introduction of the LLVM IR dialect into MLIR, the translation can be switched to only translate the LLVM IR dialect, and the translation of the operations becomes largely mechanical. The reimplementation of the translator follows the lines of the original translator in function and basic block conversion. In particular, block arguments are converted to LLVM IR PHI nodes, which are connected to their sources after all blocks of a function had been converted. Thanks to LLVM IR types being wrapped in the MLIR LLVM dialect type, type conversion is simplified to only convert function types, all other types are simply unwrapped. Individual instructions are constructed using the LLVM IRBuilder, which has a great potential for being table-generated from the LLVM IR dialect operation definitions. The input of the test/Target/llvmir.mlir is updated to use the MLIR LLVM IR dialect. While it is now redundant with the dialect conversion test, the point of the exercise is to guarantee exactly the same LLVM IR is emitted. (Only the name of the allocation function is changed from `__mlir_alloc` to `alloc` in the CHECK lines.) It will be simplified in a follow-up commit. PiperOrigin-RevId: 233842306
2019-02-14 07:30:24 +08:00
^bb4: // pred: ^bb3
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 ^bb5
Reimplement LLVM IR translation to use the MLIR LLVM IR dialect Original implementation of the translation from MLIR to LLVM IR operated on the Standard+BuiltIn dialect, with a later addition of the SuperVector dialect. This required the translation to be aware of a potetially large number of other dialects as the infrastructure extended. With the recent introduction of the LLVM IR dialect into MLIR, the translation can be switched to only translate the LLVM IR dialect, and the translation of the operations becomes largely mechanical. The reimplementation of the translator follows the lines of the original translator in function and basic block conversion. In particular, block arguments are converted to LLVM IR PHI nodes, which are connected to their sources after all blocks of a function had been converted. Thanks to LLVM IR types being wrapped in the MLIR LLVM dialect type, type conversion is simplified to only convert function types, all other types are simply unwrapped. Individual instructions are constructed using the LLVM IRBuilder, which has a great potential for being table-generated from the LLVM IR dialect operation definitions. The input of the test/Target/llvmir.mlir is updated to use the MLIR LLVM IR dialect. While it is now redundant with the dialect conversion test, the point of the exercise is to guarantee exactly the same LLVM IR is emitted. (Only the name of the allocation function is changed from `__mlir_alloc` to `alloc` in the CHECK lines.) It will be simplified in a follow-up commit. PiperOrigin-RevId: 233842306
2019-02-14 07:30:24 +08:00
^bb5: // pred: ^bb4
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%16 = llvm.mlir.constant(0 : index) : !llvm.i64
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
llvm.br ^bb6(%16 : !llvm.i64)
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK: %{{[0-9]+}} = phi i64 [ %{{[0-9]+}}, %{{[0-9]+}} ], [ 0, %{{[0-9]+}} ]
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
^bb6(%17: !llvm.i64): // 2 preds: ^bb5, ^bb7
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK-NEXT: %{{[0-9]+}} = icmp slt i64 %{{[0-9]+}}, %{{[0-9]+}}
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%18 = llvm.icmp "slt" %17, %arg0 : !llvm.i64
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK-NEXT: br i1 %{{[0-9]+}}, label %{{[0-9]+}}, label %{{[0-9]+}}
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.cond_br %18, ^bb7, ^bb8
Reimplement LLVM IR translation to use the MLIR LLVM IR dialect Original implementation of the translation from MLIR to LLVM IR operated on the Standard+BuiltIn dialect, with a later addition of the SuperVector dialect. This required the translation to be aware of a potetially large number of other dialects as the infrastructure extended. With the recent introduction of the LLVM IR dialect into MLIR, the translation can be switched to only translate the LLVM IR dialect, and the translation of the operations becomes largely mechanical. The reimplementation of the translator follows the lines of the original translator in function and basic block conversion. In particular, block arguments are converted to LLVM IR PHI nodes, which are connected to their sources after all blocks of a function had been converted. Thanks to LLVM IR types being wrapped in the MLIR LLVM dialect type, type conversion is simplified to only convert function types, all other types are simply unwrapped. Individual instructions are constructed using the LLVM IRBuilder, which has a great potential for being table-generated from the LLVM IR dialect operation definitions. The input of the test/Target/llvmir.mlir is updated to use the MLIR LLVM IR dialect. While it is now redundant with the dialect conversion test, the point of the exercise is to guarantee exactly the same LLVM IR is emitted. (Only the name of the allocation function is changed from `__mlir_alloc` to `alloc` in the CHECK lines.) It will be simplified in a follow-up commit. PiperOrigin-RevId: 233842306
2019-02-14 07:30:24 +08:00
^bb7: // pred: ^bb6
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK: %{{[0-9]+}} = extractvalue { float*, i64 } %{{[0-9]+}}, 1
// CHECK-NEXT: %{{[0-9]+}} = extractvalue { float*, i64 } %{{[0-9]+}}, 0
// CHECK-NEXT: %{{[0-9]+}} = getelementptr float, float* %{{[0-9]+}}, i64 %{{[0-9]+}}
// CHECK-NEXT: %{{[0-9]+}} = load float, float* %{{[0-9]+}}
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
%19 = llvm.extractvalue %6[1] : !llvm<"{ float*, i64 }">
%20 = llvm.extractvalue %6[0] : !llvm<"{ float*, i64 }">
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%21 = llvm.getelementptr %20[%17] : (!llvm<"float*">, !llvm.i64) -> !llvm<"float*">
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
%22 = llvm.load %21 : !llvm<"float*">
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%23 = llvm.mlir.constant(1 : index) : !llvm.i64
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK-NEXT: %{{[0-9]+}} = add i64 %{{[0-9]+}}, 1
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%24 = llvm.add %17, %23 : !llvm.i64
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK-NEXT: br label %{{[0-9]+}}
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
llvm.br ^bb6(%24 : !llvm.i64)
Reimplement LLVM IR translation to use the MLIR LLVM IR dialect Original implementation of the translation from MLIR to LLVM IR operated on the Standard+BuiltIn dialect, with a later addition of the SuperVector dialect. This required the translation to be aware of a potetially large number of other dialects as the infrastructure extended. With the recent introduction of the LLVM IR dialect into MLIR, the translation can be switched to only translate the LLVM IR dialect, and the translation of the operations becomes largely mechanical. The reimplementation of the translator follows the lines of the original translator in function and basic block conversion. In particular, block arguments are converted to LLVM IR PHI nodes, which are connected to their sources after all blocks of a function had been converted. Thanks to LLVM IR types being wrapped in the MLIR LLVM dialect type, type conversion is simplified to only convert function types, all other types are simply unwrapped. Individual instructions are constructed using the LLVM IRBuilder, which has a great potential for being table-generated from the LLVM IR dialect operation definitions. The input of the test/Target/llvmir.mlir is updated to use the MLIR LLVM IR dialect. While it is now redundant with the dialect conversion test, the point of the exercise is to guarantee exactly the same LLVM IR is emitted. (Only the name of the allocation function is changed from `__mlir_alloc` to `alloc` in the CHECK lines.) It will be simplified in a follow-up commit. PiperOrigin-RevId: 233842306
2019-02-14 07:30:24 +08:00
^bb8: // pred: ^bb6
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK: ret void
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
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
}
[mlir-translate] Fix test suite. llvm ir printer was changed at LLVM r367755. Prints value numbers for unnamed functions argument. Closes tensorflow/mlir#67 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/67 from denis0x0D:sandbox/fix_mlir_translate ae46844e66f34a02e0cf86782ddadc5bce58b30d PiperOrigin-RevId: 261640048
2019-08-05 16:39:26 +08:00
// CHECK-LABEL: define void @store_load_mixed(i64 {{%.*}})
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @store_load_mixed(%arg0: !llvm.i64) {
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%0 = llvm.mlir.constant(10 : index) : !llvm.i64
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK-NEXT: %{{[0-9]+}} = mul i64 2, %{{[0-9]+}}
// CHECK-NEXT: %{{[0-9]+}} = mul i64 %{{[0-9]+}}, 4
// CHECK-NEXT: %{{[0-9]+}} = mul i64 %{{[0-9]+}}, 10
// CHECK-NEXT: %{{[0-9]+}} = mul i64 %{{[0-9]+}}, 4
Reimplement LLVM IR translation to use the MLIR LLVM IR dialect Original implementation of the translation from MLIR to LLVM IR operated on the Standard+BuiltIn dialect, with a later addition of the SuperVector dialect. This required the translation to be aware of a potetially large number of other dialects as the infrastructure extended. With the recent introduction of the LLVM IR dialect into MLIR, the translation can be switched to only translate the LLVM IR dialect, and the translation of the operations becomes largely mechanical. The reimplementation of the translator follows the lines of the original translator in function and basic block conversion. In particular, block arguments are converted to LLVM IR PHI nodes, which are connected to their sources after all blocks of a function had been converted. Thanks to LLVM IR types being wrapped in the MLIR LLVM dialect type, type conversion is simplified to only convert function types, all other types are simply unwrapped. Individual instructions are constructed using the LLVM IRBuilder, which has a great potential for being table-generated from the LLVM IR dialect operation definitions. The input of the test/Target/llvmir.mlir is updated to use the MLIR LLVM IR dialect. While it is now redundant with the dialect conversion test, the point of the exercise is to guarantee exactly the same LLVM IR is emitted. (Only the name of the allocation function is changed from `__mlir_alloc` to `alloc` in the CHECK lines.) It will be simplified in a follow-up commit. PiperOrigin-RevId: 233842306
2019-02-14 07:30:24 +08:00
// CHECK-NEXT: %{{[0-9]+}} = call i8* @malloc(i64 %{{[0-9]+}})
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK-NEXT: %{{[0-9]+}} = bitcast i8* %{{[0-9]+}} to float*
// CHECK-NEXT: %{{[0-9]+}} = insertvalue { float*, i64, i64 } undef, float* %{{[0-9]+}}, 0
// CHECK-NEXT: %{{[0-9]+}} = insertvalue { float*, i64, i64 } %{{[0-9]+}}, i64 %{{[0-9]+}}, 1
// CHECK-NEXT: %{{[0-9]+}} = insertvalue { float*, i64, i64 } %{{[0-9]+}}, i64 10, 2
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%1 = llvm.mlir.constant(2 : index) : !llvm.i64
%2 = llvm.mlir.constant(4 : index) : !llvm.i64
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%3 = llvm.mul %1, %arg0 : !llvm.i64
%4 = llvm.mul %3, %2 : !llvm.i64
%5 = llvm.mul %4, %0 : !llvm.i64
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%6 = llvm.mlir.undef : !llvm<"{ float*, i64, i64 }">
%7 = llvm.mlir.constant(4 : index) : !llvm.i64
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%8 = llvm.mul %5, %7 : !llvm.i64
%9 = llvm.call @malloc(%8) : (!llvm.i64) -> !llvm<"i8*">
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
%10 = llvm.bitcast %9 : !llvm<"i8*"> to !llvm<"float*">
%11 = llvm.insertvalue %10, %6[0] : !llvm<"{ float*, i64, i64 }">
%12 = llvm.insertvalue %arg0, %11[1] : !llvm<"{ float*, i64, i64 }">
%13 = llvm.insertvalue %0, %12[2] : !llvm<"{ float*, i64, i64 }">
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK-NEXT: %{{[0-9]+}} = call i64 @get_index()
// CHECK-NEXT: %{{[0-9]+}} = call i64 @get_index()
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%14 = llvm.mlir.constant(1 : index) : !llvm.i64
%15 = llvm.mlir.constant(2 : index) : !llvm.i64
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%16 = llvm.call @get_index() : () -> !llvm.i64
%17 = llvm.call @get_index() : () -> !llvm.i64
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%18 = llvm.mlir.constant(4.200000e+01 : f32) : !llvm.float
%19 = llvm.mlir.constant(2 : index) : !llvm.i64
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK-NEXT: %{{[0-9]+}} = extractvalue { float*, i64, i64 } %{{[0-9]+}}, 1
// CHECK-NEXT: %{{[0-9]+}} = extractvalue { float*, i64, i64 } %{{[0-9]+}}, 2
// CHECK-NEXT: %{{[0-9]+}} = mul i64 1, %{{[0-9]+}}
// CHECK-NEXT: %{{[0-9]+}} = add i64 %{{[0-9]+}}, 2
// CHECK-NEXT: %{{[0-9]+}} = mul i64 %{{[0-9]+}}, 4
// CHECK-NEXT: %{{[0-9]+}} = add i64 %{{[0-9]+}}, %{{[0-9]+}}
// CHECK-NEXT: %{{[0-9]+}} = mul i64 %{{[0-9]+}}, %{{[0-9]+}}
// CHECK-NEXT: %{{[0-9]+}} = add i64 %{{[0-9]+}}, %{{[0-9]+}}
// CHECK-NEXT: %{{[0-9]+}} = extractvalue { float*, i64, i64 } %{{[0-9]+}}, 0
// CHECK-NEXT: %{{[0-9]+}} = getelementptr float, float* %{{[0-9]+}}, i64 %{{[0-9]+}}
// CHECK-NEXT: store float 4.200000e+01, float* %{{[0-9]+}}
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
%20 = llvm.extractvalue %13[1] : !llvm<"{ float*, i64, i64 }">
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%21 = llvm.mlir.constant(4 : index) : !llvm.i64
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
%22 = llvm.extractvalue %13[2] : !llvm<"{ float*, i64, i64 }">
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%23 = llvm.mul %14, %20 : !llvm.i64
%24 = llvm.add %23, %15 : !llvm.i64
%25 = llvm.mul %24, %21 : !llvm.i64
%26 = llvm.add %25, %16 : !llvm.i64
%27 = llvm.mul %26, %22 : !llvm.i64
%28 = llvm.add %27, %17 : !llvm.i64
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
%29 = llvm.extractvalue %13[0] : !llvm<"{ float*, i64, i64 }">
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%30 = llvm.getelementptr %29[%28] : (!llvm<"float*">, !llvm.i64) -> !llvm<"float*">
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.store %18, %30 : !llvm<"float*">
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK-NEXT: %{{[0-9]+}} = extractvalue { float*, i64, i64 } %{{[0-9]+}}, 1
// CHECK-NEXT: %{{[0-9]+}} = extractvalue { float*, i64, i64 } %{{[0-9]+}}, 2
// CHECK-NEXT: %{{[0-9]+}} = mul i64 %{{[0-9]+}}, %{{[0-9]+}}
// CHECK-NEXT: %{{[0-9]+}} = add i64 %{{[0-9]+}}, %{{[0-9]+}}
// CHECK-NEXT: %{{[0-9]+}} = mul i64 %{{[0-9]+}}, 4
// CHECK-NEXT: %{{[0-9]+}} = add i64 %{{[0-9]+}}, 2
// CHECK-NEXT: %{{[0-9]+}} = mul i64 %{{[0-9]+}}, %{{[0-9]+}}
// CHECK-NEXT: %{{[0-9]+}} = add i64 %{{[0-9]+}}, 1
// CHECK-NEXT: %{{[0-9]+}} = extractvalue { float*, i64, i64 } %{{[0-9]+}}, 0
// CHECK-NEXT: %{{[0-9]+}} = getelementptr float, float* %{{[0-9]+}}, i64 %{{[0-9]+}}
// CHECK-NEXT: %{{[0-9]+}} = load float, float* %{{[0-9]+}}
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%31 = llvm.mlir.constant(2 : index) : !llvm.i64
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
%32 = llvm.extractvalue %13[1] : !llvm<"{ float*, i64, i64 }">
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%33 = llvm.mlir.constant(4 : index) : !llvm.i64
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
%34 = llvm.extractvalue %13[2] : !llvm<"{ float*, i64, i64 }">
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%35 = llvm.mul %17, %32 : !llvm.i64
%36 = llvm.add %35, %16 : !llvm.i64
%37 = llvm.mul %36, %33 : !llvm.i64
%38 = llvm.add %37, %15 : !llvm.i64
%39 = llvm.mul %38, %34 : !llvm.i64
%40 = llvm.add %39, %14 : !llvm.i64
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
%41 = llvm.extractvalue %13[0] : !llvm<"{ float*, i64, i64 }">
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%42 = llvm.getelementptr %41[%40] : (!llvm<"float*">, !llvm.i64) -> !llvm<"float*">
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
%43 = llvm.load %42 : !llvm<"float*">
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK-NEXT: ret void
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
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
}
[mlir-translate] Fix test suite. llvm ir printer was changed at LLVM r367755. Prints value numbers for unnamed functions argument. Closes tensorflow/mlir#67 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/67 from denis0x0D:sandbox/fix_mlir_translate ae46844e66f34a02e0cf86782ddadc5bce58b30d PiperOrigin-RevId: 261640048
2019-08-05 16:39:26 +08:00
// CHECK-LABEL: define { float*, i64 } @memref_args_rets({ float* } {{%.*}}, { float*, i64 } {{%.*}}, { float*, i64 } {{%.*}}) {
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @memref_args_rets(%arg0: !llvm<"{ float* }">, %arg1: !llvm<"{ float*, i64 }">, %arg2: !llvm<"{ float*, i64 }">) -> !llvm<"{ float*, i64 }"> {
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%0 = llvm.mlir.constant(7 : index) : !llvm.i64
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK-NEXT: %{{[0-9]+}} = call i64 @get_index()
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%1 = llvm.call @get_index() : () -> !llvm.i64
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%2 = llvm.mlir.constant(4.200000e+01 : f32) : !llvm.float
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK-NEXT: %{{[0-9]+}} = extractvalue { float* } %{{[0-9]+}}, 0
// CHECK-NEXT: %{{[0-9]+}} = getelementptr float, float* %{{[0-9]+}}, i64 7
// CHECK-NEXT: store float 4.200000e+01, float* %{{[0-9]+}}
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%3 = llvm.mlir.constant(10 : index) : !llvm.i64
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
%4 = llvm.extractvalue %arg0[0] : !llvm<"{ float* }">
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%5 = llvm.getelementptr %4[%0] : (!llvm<"float*">, !llvm.i64) -> !llvm<"float*">
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.store %2, %5 : !llvm<"float*">
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK-NEXT: %{{[0-9]+}} = extractvalue { float*, i64 } %{{[0-9]+}}, 1
// CHECK-NEXT: %{{[0-9]+}} = extractvalue { float*, i64 } %{{[0-9]+}}, 0
// CHECK-NEXT: %{{[0-9]+}} = getelementptr float, float* %{{[0-9]+}}, i64 7
// CHECK-NEXT: store float 4.200000e+01, float* %{{[0-9]+}}
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
%6 = llvm.extractvalue %arg1[1] : !llvm<"{ float*, i64 }">
%7 = llvm.extractvalue %arg1[0] : !llvm<"{ float*, i64 }">
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%8 = llvm.getelementptr %7[%0] : (!llvm<"float*">, !llvm.i64) -> !llvm<"float*">
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.store %2, %8 : !llvm<"float*">
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK-NEXT: %{{[0-9]+}} = extractvalue { float*, i64 } %{{[0-9]+}}, 1
// CHECK-NEXT: %{{[0-9]+}} = mul i64 7, %{{[0-9]+}}
// CHECK-NEXT: %{{[0-9]+}} = add i64 %{{[0-9]+}}, %{{[0-9]+}}
// CHECK-NEXT: %{{[0-9]+}} = extractvalue { float*, i64 } %{{[0-9]+}}, 0
// CHECK-NEXT: %{{[0-9]+}} = getelementptr float, float* %{{[0-9]+}}, i64 %{{[0-9]+}}
// CHECK-NEXT: store float 4.200000e+01, float* %{{[0-9]+}}
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%9 = llvm.mlir.constant(10 : index) : !llvm.i64
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
%10 = llvm.extractvalue %arg2[1] : !llvm<"{ float*, i64 }">
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%11 = llvm.mul %0, %10 : !llvm.i64
%12 = llvm.add %11, %1 : !llvm.i64
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
%13 = llvm.extractvalue %arg2[0] : !llvm<"{ float*, i64 }">
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%14 = llvm.getelementptr %13[%12] : (!llvm<"float*">, !llvm.i64) -> !llvm<"float*">
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.store %2, %14 : !llvm<"float*">
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK-NEXT: %{{[0-9]+}} = mul i64 10, %{{[0-9]+}}
// CHECK-NEXT: %{{[0-9]+}} = mul i64 %{{[0-9]+}}, 4
Reimplement LLVM IR translation to use the MLIR LLVM IR dialect Original implementation of the translation from MLIR to LLVM IR operated on the Standard+BuiltIn dialect, with a later addition of the SuperVector dialect. This required the translation to be aware of a potetially large number of other dialects as the infrastructure extended. With the recent introduction of the LLVM IR dialect into MLIR, the translation can be switched to only translate the LLVM IR dialect, and the translation of the operations becomes largely mechanical. The reimplementation of the translator follows the lines of the original translator in function and basic block conversion. In particular, block arguments are converted to LLVM IR PHI nodes, which are connected to their sources after all blocks of a function had been converted. Thanks to LLVM IR types being wrapped in the MLIR LLVM dialect type, type conversion is simplified to only convert function types, all other types are simply unwrapped. Individual instructions are constructed using the LLVM IRBuilder, which has a great potential for being table-generated from the LLVM IR dialect operation definitions. The input of the test/Target/llvmir.mlir is updated to use the MLIR LLVM IR dialect. While it is now redundant with the dialect conversion test, the point of the exercise is to guarantee exactly the same LLVM IR is emitted. (Only the name of the allocation function is changed from `__mlir_alloc` to `alloc` in the CHECK lines.) It will be simplified in a follow-up commit. PiperOrigin-RevId: 233842306
2019-02-14 07:30:24 +08:00
// CHECK-NEXT: %{{[0-9]+}} = call i8* @malloc(i64 %{{[0-9]+}})
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK-NEXT: %{{[0-9]+}} = bitcast i8* %{{[0-9]+}} to float*
// CHECK-NEXT: %{{[0-9]+}} = insertvalue { float*, i64 } undef, float* %{{[0-9]+}}, 0
// CHECK-NEXT: %{{[0-9]+}} = insertvalue { float*, i64 } %{{[0-9]+}}, i64 %{{[0-9]+}}, 1
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%15 = llvm.mlir.constant(10 : index) : !llvm.i64
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%16 = llvm.mul %15, %1 : !llvm.i64
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%17 = llvm.mlir.undef : !llvm<"{ float*, i64 }">
%18 = llvm.mlir.constant(4 : index) : !llvm.i64
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%19 = llvm.mul %16, %18 : !llvm.i64
%20 = llvm.call @malloc(%19) : (!llvm.i64) -> !llvm<"i8*">
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
%21 = llvm.bitcast %20 : !llvm<"i8*"> to !llvm<"float*">
%22 = llvm.insertvalue %21, %17[0] : !llvm<"{ float*, i64 }">
%23 = llvm.insertvalue %1, %22[1] : !llvm<"{ float*, i64 }">
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
// CHECK-NEXT: ret { float*, i64 } %{{[0-9]+}}
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 %23 : !llvm<"{ float*, i64 }">
LLVM IR lowering: support simple MemRef types Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
2018-11-28 18:32:10 +08:00
}
LLVM IR lowering: support 'dim' operation. Add support for translating 'dim' opreation on MemRefs to LLVM IR. For a static size, this operation merely defines an LLVM IR constant value that may not appear in the output IR if not used (and had not been removed before by DCE). For a dynamic size, this operation is translated into an access to the MemRef descriptor that contains the dynamic size. PiperOrigin-RevId: 223160774
2018-11-28 23:07:56 +08:00
[mlir-translate] Fix test suite. llvm ir printer was changed at LLVM r367755. Prints value numbers for unnamed functions argument. Closes tensorflow/mlir#67 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/67 from denis0x0D:sandbox/fix_mlir_translate ae46844e66f34a02e0cf86782ddadc5bce58b30d PiperOrigin-RevId: 261640048
2019-08-05 16:39:26 +08:00
// CHECK-LABEL: define i64 @memref_dim({ float*, i64, i64 } {{%.*}})
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @memref_dim(%arg0: !llvm<"{ float*, i64, i64 }">) -> !llvm.i64 {
LLVM IR lowering: support 'dim' operation. Add support for translating 'dim' opreation on MemRefs to LLVM IR. For a static size, this operation merely defines an LLVM IR constant value that may not appear in the output IR if not used (and had not been removed before by DCE). For a dynamic size, this operation is translated into an access to the MemRef descriptor that contains the dynamic size. PiperOrigin-RevId: 223160774
2018-11-28 23:07:56 +08:00
// Expecting this to create an LLVM constant.
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%0 = llvm.mlir.constant(42 : index) : !llvm.i64
LLVM IR lowering: support 'dim' operation. Add support for translating 'dim' opreation on MemRefs to LLVM IR. For a static size, this operation merely defines an LLVM IR constant value that may not appear in the output IR if not used (and had not been removed before by DCE). For a dynamic size, this operation is translated into an access to the MemRef descriptor that contains the dynamic size. PiperOrigin-RevId: 223160774
2018-11-28 23:07:56 +08:00
// CHECK-NEXT: %2 = extractvalue { float*, i64, i64 } %0, 1
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
%1 = llvm.extractvalue %arg0[1] : !llvm<"{ float*, i64, i64 }">
LLVM IR lowering: support 'dim' operation. Add support for translating 'dim' opreation on MemRefs to LLVM IR. For a static size, this operation merely defines an LLVM IR constant value that may not appear in the output IR if not used (and had not been removed before by DCE). For a dynamic size, this operation is translated into an access to the MemRef descriptor that contains the dynamic size. PiperOrigin-RevId: 223160774
2018-11-28 23:07:56 +08:00
// Expecting this to create an LLVM constant.
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%2 = llvm.mlir.constant(10 : index) : !llvm.i64
LLVM IR lowering: support 'dim' operation. Add support for translating 'dim' opreation on MemRefs to LLVM IR. For a static size, this operation merely defines an LLVM IR constant value that may not appear in the output IR if not used (and had not been removed before by DCE). For a dynamic size, this operation is translated into an access to the MemRef descriptor that contains the dynamic size. PiperOrigin-RevId: 223160774
2018-11-28 23:07:56 +08:00
// CHECK-NEXT: %3 = extractvalue { float*, i64, i64 } %0, 2
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
%3 = llvm.extractvalue %arg0[2] : !llvm<"{ float*, i64, i64 }">
LLVM IR lowering: support 'dim' operation. Add support for translating 'dim' opreation on MemRefs to LLVM IR. For a static size, this operation merely defines an LLVM IR constant value that may not appear in the output IR if not used (and had not been removed before by DCE). For a dynamic size, this operation is translated into an access to the MemRef descriptor that contains the dynamic size. PiperOrigin-RevId: 223160774
2018-11-28 23:07:56 +08:00
// Checking that the constant for d0 has been created.
// CHECK-NEXT: %4 = add i64 42, %2
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%4 = llvm.add %0, %1 : !llvm.i64
LLVM IR lowering: support 'dim' operation. Add support for translating 'dim' opreation on MemRefs to LLVM IR. For a static size, this operation merely defines an LLVM IR constant value that may not appear in the output IR if not used (and had not been removed before by DCE). For a dynamic size, this operation is translated into an access to the MemRef descriptor that contains the dynamic size. PiperOrigin-RevId: 223160774
2018-11-28 23:07:56 +08:00
// Checking that the constant for d2 has been created.
// CHECK-NEXT: %5 = add i64 10, %3
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%5 = llvm.add %2, %3 : !llvm.i64
LLVM IR lowering: support 'dim' operation. Add support for translating 'dim' opreation on MemRefs to LLVM IR. For a static size, this operation merely defines an LLVM IR constant value that may not appear in the output IR if not used (and had not been removed before by DCE). For a dynamic size, this operation is translated into an access to the MemRef descriptor that contains the dynamic size. PiperOrigin-RevId: 223160774
2018-11-28 23:07:56 +08:00
// CHECK-NEXT: %6 = add i64 %4, %5
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%6 = llvm.add %4, %5 : !llvm.i64
LLVM IR lowering: support 'dim' operation. Add support for translating 'dim' opreation on MemRefs to LLVM IR. For a static size, this operation merely defines an LLVM IR constant value that may not appear in the output IR if not used (and had not been removed before by DCE). For a dynamic size, this operation is translated into an access to the MemRef descriptor that contains the dynamic size. PiperOrigin-RevId: 223160774
2018-11-28 23:07:56 +08:00
// CHECK-NEXT: ret i64 %6
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
llvm.return %6 : !llvm.i64
LLVM IR lowering: support 'dim' operation. Add support for translating 'dim' opreation on MemRefs to LLVM IR. For a static size, this operation merely defines an LLVM IR constant value that may not appear in the output IR if not used (and had not been removed before by DCE). For a dynamic size, this operation is translated into an access to the MemRef descriptor that contains the dynamic size. PiperOrigin-RevId: 223160774
2018-11-28 23:07:56 +08:00
}
LLVM IR Lowering: support multi-value returns. Unlike MLIR, LLVM IR does not support functions that return multiple values. Simulate this by packing values into the LLVM structure type in the same order as they appear in the MLIR return. If the function returns only a single value, return it directly without packing. PiperOrigin-RevId: 223964886
2018-12-04 22:16:26 +08:00
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @get_i64() -> !llvm.i64
llvm.func @get_f32() -> !llvm.float
llvm.func @get_memref() -> !llvm<"{ float*, i64, i64 }">
LLVM IR Lowering: support multi-value returns. Unlike MLIR, LLVM IR does not support functions that return multiple values. Simulate this by packing values into the LLVM structure type in the same order as they appear in the MLIR return. If the function returns only a single value, return it directly without packing. PiperOrigin-RevId: 223964886
2018-12-04 22:16:26 +08:00
// CHECK-LABEL: define { i64, float, { float*, i64, i64 } } @multireturn() {
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @multireturn() -> !llvm<"{ i64, float, { float*, i64, i64 } }"> {
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%0 = llvm.call @get_i64() : () -> !llvm.i64
%1 = llvm.call @get_f32() : () -> !llvm.float
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
%2 = llvm.call @get_memref() : () -> !llvm<"{ float*, i64, i64 }">
LLVM IR Lowering: support multi-value returns. Unlike MLIR, LLVM IR does not support functions that return multiple values. Simulate this by packing values into the LLVM structure type in the same order as they appear in the MLIR return. If the function returns only a single value, return it directly without packing. PiperOrigin-RevId: 223964886
2018-12-04 22:16:26 +08:00
// CHECK: %{{[0-9]+}} = insertvalue { i64, float, { float*, i64, i64 } } undef, i64 %{{[0-9]+}}, 0
// CHECK-NEXT: %{{[0-9]+}} = insertvalue { i64, float, { float*, i64, i64 } } %{{[0-9]+}}, float %{{[0-9]+}}, 1
// CHECK-NEXT: %{{[0-9]+}} = insertvalue { i64, float, { float*, i64, i64 } } %{{[0-9]+}}, { float*, i64, i64 } %{{[0-9]+}}, 2
// CHECK-NEXT: ret { i64, float, { float*, i64, i64 } } %{{[0-9]+}}
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%3 = llvm.mlir.undef : !llvm<"{ i64, float, { float*, i64, i64 } }">
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
%4 = llvm.insertvalue %0, %3[0] : !llvm<"{ i64, float, { float*, i64, i64 } }">
%5 = llvm.insertvalue %1, %4[1] : !llvm<"{ i64, float, { float*, i64, i64 } }">
%6 = llvm.insertvalue %2, %5[2] : !llvm<"{ i64, float, { float*, i64, i64 } }">
llvm.return %6 : !llvm<"{ i64, float, { float*, i64, i64 } }">
LLVM IR Lowering: support multi-value returns. Unlike MLIR, LLVM IR does not support functions that return multiple values. Simulate this by packing values into the LLVM structure type in the same order as they appear in the MLIR return. If the function returns only a single value, return it directly without packing. PiperOrigin-RevId: 223964886
2018-12-04 22:16:26 +08:00
}
// CHECK-LABEL: define void @multireturn_caller() {
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @multireturn_caller() {
LLVM IR Lowering: support multi-value returns. Unlike MLIR, LLVM IR does not support functions that return multiple values. Simulate this by packing values into the LLVM structure type in the same order as they appear in the MLIR return. If the function returns only a single value, return it directly without packing. PiperOrigin-RevId: 223964886
2018-12-04 22:16:26 +08:00
// CHECK-NEXT: %1 = call { i64, float, { float*, i64, i64 } } @multireturn()
// CHECK-NEXT: [[ret0:%[0-9]+]] = extractvalue { i64, float, { float*, i64, i64 } } %1, 0
// CHECK-NEXT: [[ret1:%[0-9]+]] = extractvalue { i64, float, { float*, i64, i64 } } %1, 1
// CHECK-NEXT: [[ret2:%[0-9]+]] = extractvalue { i64, float, { float*, i64, i64 } } %1, 2
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
%0 = llvm.call @multireturn() : () -> !llvm<"{ i64, float, { float*, i64, i64 } }">
%1 = llvm.extractvalue %0[0] : !llvm<"{ i64, float, { float*, i64, i64 } }">
%2 = llvm.extractvalue %0[1] : !llvm<"{ i64, float, { float*, i64, i64 } }">
%3 = llvm.extractvalue %0[2] : !llvm<"{ i64, float, { float*, i64, i64 } }">
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%4 = llvm.mlir.constant(42) : !llvm.i64
LLVM IR Lowering: support multi-value returns. Unlike MLIR, LLVM IR does not support functions that return multiple values. Simulate this by packing values into the LLVM structure type in the same order as they appear in the MLIR return. If the function returns only a single value, return it directly without packing. PiperOrigin-RevId: 223964886
2018-12-04 22:16:26 +08:00
// CHECK: add i64 [[ret0]], 42
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%5 = llvm.add %1, %4 : !llvm.i64
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%6 = llvm.mlir.constant(4.200000e+01 : f32) : !llvm.float
LLVM IR Lowering: support multi-value returns. Unlike MLIR, LLVM IR does not support functions that return multiple values. Simulate this by packing values into the LLVM structure type in the same order as they appear in the MLIR return. If the function returns only a single value, return it directly without packing. PiperOrigin-RevId: 223964886
2018-12-04 22:16:26 +08:00
// CHECK: fadd float [[ret1]], 4.200000e+01
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%7 = llvm.fadd %2, %6 : !llvm.float
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%8 = llvm.mlir.constant(0 : index) : !llvm.i64
%9 = llvm.mlir.constant(42 : index) : !llvm.i64
LLVM IR Lowering: support multi-value returns. Unlike MLIR, LLVM IR does not support functions that return multiple values. Simulate this by packing values into the LLVM structure type in the same order as they appear in the MLIR return. If the function returns only a single value, return it directly without packing. PiperOrigin-RevId: 223964886
2018-12-04 22:16:26 +08:00
// CHECK: extractvalue { float*, i64, i64 } [[ret2]], 0
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
%10 = llvm.extractvalue %3[1] : !llvm<"{ float*, i64, i64 }">
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%11 = llvm.mlir.constant(10 : index) : !llvm.i64
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
%12 = llvm.extractvalue %3[2] : !llvm<"{ float*, i64, i64 }">
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%13 = llvm.mul %8, %10 : !llvm.i64
%14 = llvm.add %13, %8 : !llvm.i64
%15 = llvm.mul %14, %11 : !llvm.i64
%16 = llvm.add %15, %8 : !llvm.i64
%17 = llvm.mul %16, %12 : !llvm.i64
%18 = llvm.add %17, %8 : !llvm.i64
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
%19 = llvm.extractvalue %3[0] : !llvm<"{ float*, i64, i64 }">
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%20 = llvm.getelementptr %19[%18] : (!llvm<"float*">, !llvm.i64) -> !llvm<"float*">
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
%21 = llvm.load %20 : !llvm<"float*">
llvm.return
LLVM IR Lowering: support multi-value returns. Unlike MLIR, LLVM IR does not support functions that return multiple values. Simulate this by packing values into the LLVM structure type in the same order as they appear in the MLIR return. If the function returns only a single value, return it directly without packing. PiperOrigin-RevId: 223964886
2018-12-04 22:16:26 +08:00
}
LLVM IR lowering: support 1D vector operations Introduce initial support for 1D vector operations. LLVM does not support higher-dimensional vectors so the caller must make sure they don't appear in the input MLIR. Handle the presence of higher-dimensional vectors by failing gracefully. Introduce the type conversion for 1D vector types and hook it up with the rest of the type convresion system. Support "splat" constants for vector types. As a side effect, this refactors constant operation emission by separating out scalar integer constants into a separate case and by extracting out the helper function for scalar float construction. Existing binary operations apply to vectors transparently. PiperOrigin-RevId: 225172349
2018-12-12 22:11:33 +08:00
[mlir-translate] Fix test suite. llvm ir printer was changed at LLVM r367755. Prints value numbers for unnamed functions argument. Closes tensorflow/mlir#67 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/67 from denis0x0D:sandbox/fix_mlir_translate ae46844e66f34a02e0cf86782ddadc5bce58b30d PiperOrigin-RevId: 261640048
2019-08-05 16:39:26 +08:00
// CHECK-LABEL: define <4 x float> @vector_ops(<4 x float> {{%.*}}, <4 x i1> {{%.*}}, <4 x i64> {{%.*}}) {
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @vector_ops(%arg0: !llvm<"<4 x float>">, %arg1: !llvm<"<4 x i1>">, %arg2: !llvm<"<4 x i64>">) -> !llvm<"<4 x float>"> {
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%0 = llvm.mlir.constant(dense<4.200000e+01> : vector<4xf32>) : !llvm<"<4 x float>">
LLVM IR lowering: support integer division and remainder operations These operations trivially map to LLVM IR counterparts for operands of scalar and (one-dimensional) vector type. Multi-dimensional vector and tensor type operands would fail type conversion before the operation conversion takes place. Add tests for scalar and vector cases. Also add a test for vector `select` instruction for consistency with other tests. PiperOrigin-RevId: 228077564
2019-01-07 06:09:00 +08:00
// CHECK-NEXT: %4 = fadd <4 x float> %0, <float 4.200000e+01, float 4.200000e+01, float 4.200000e+01, float 4.200000e+01>
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
%1 = llvm.fadd %arg0, %0 : !llvm<"<4 x float>">
LLVM IR lowering: support integer division and remainder operations These operations trivially map to LLVM IR counterparts for operands of scalar and (one-dimensional) vector type. Multi-dimensional vector and tensor type operands would fail type conversion before the operation conversion takes place. Add tests for scalar and vector cases. Also add a test for vector `select` instruction for consistency with other tests. PiperOrigin-RevId: 228077564
2019-01-07 06:09:00 +08:00
// CHECK-NEXT: %5 = select <4 x i1> %1, <4 x float> %4, <4 x float> %0
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
%2 = llvm.select %arg1, %1, %arg0 : !llvm<"<4 x i1>">, !llvm<"<4 x float>">
LLVM IR lowering: support integer division and remainder operations These operations trivially map to LLVM IR counterparts for operands of scalar and (one-dimensional) vector type. Multi-dimensional vector and tensor type operands would fail type conversion before the operation conversion takes place. Add tests for scalar and vector cases. Also add a test for vector `select` instruction for consistency with other tests. PiperOrigin-RevId: 228077564
2019-01-07 06:09:00 +08:00
// CHECK-NEXT: %6 = sdiv <4 x i64> %2, %2
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
%3 = llvm.sdiv %arg2, %arg2 : !llvm<"<4 x i64>">
LLVM IR lowering: support integer division and remainder operations These operations trivially map to LLVM IR counterparts for operands of scalar and (one-dimensional) vector type. Multi-dimensional vector and tensor type operands would fail type conversion before the operation conversion takes place. Add tests for scalar and vector cases. Also add a test for vector `select` instruction for consistency with other tests. PiperOrigin-RevId: 228077564
2019-01-07 06:09:00 +08:00
// CHECK-NEXT: %7 = udiv <4 x i64> %2, %2
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
%4 = llvm.udiv %arg2, %arg2 : !llvm<"<4 x i64>">
LLVM IR lowering: support integer division and remainder operations These operations trivially map to LLVM IR counterparts for operands of scalar and (one-dimensional) vector type. Multi-dimensional vector and tensor type operands would fail type conversion before the operation conversion takes place. Add tests for scalar and vector cases. Also add a test for vector `select` instruction for consistency with other tests. PiperOrigin-RevId: 228077564
2019-01-07 06:09:00 +08:00
// CHECK-NEXT: %8 = srem <4 x i64> %2, %2
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
%5 = llvm.srem %arg2, %arg2 : !llvm<"<4 x i64>">
LLVM IR lowering: support integer division and remainder operations These operations trivially map to LLVM IR counterparts for operands of scalar and (one-dimensional) vector type. Multi-dimensional vector and tensor type operands would fail type conversion before the operation conversion takes place. Add tests for scalar and vector cases. Also add a test for vector `select` instruction for consistency with other tests. PiperOrigin-RevId: 228077564
2019-01-07 06:09:00 +08:00
// CHECK-NEXT: %9 = urem <4 x i64> %2, %2
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
%6 = llvm.urem %arg2, %arg2 : !llvm<"<4 x i64>">
Lower standard DivF and RemF operations to the LLVM IR dialect Add support for lowering DivF and RemF to LLVM::FDiv and LLMV::FRem respectively. The lowering is a trivial one-to-one transformation. The corresponding operations already existed in the LLVM IR dialect and can be lowered to the LLVM IR proper. Add the necessary tests for scalar and vector forms. PiperOrigin-RevId: 234984608
2019-02-21 22:30:53 +08:00
// CHECK-NEXT: %10 = fdiv <4 x float> %0, <float 4.200000e+01, float 4.200000e+01, float 4.200000e+01, float 4.200000e+01>
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
%7 = llvm.fdiv %arg0, %0 : !llvm<"<4 x float>">
Lower standard DivF and RemF operations to the LLVM IR dialect Add support for lowering DivF and RemF to LLVM::FDiv and LLMV::FRem respectively. The lowering is a trivial one-to-one transformation. The corresponding operations already existed in the LLVM IR dialect and can be lowered to the LLVM IR proper. Add the necessary tests for scalar and vector forms. PiperOrigin-RevId: 234984608
2019-02-21 22:30:53 +08:00
// CHECK-NEXT: %11 = frem <4 x float> %0, <float 4.200000e+01, float 4.200000e+01, float 4.200000e+01, float 4.200000e+01>
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
%8 = llvm.frem %arg0, %0 : !llvm<"<4 x float>">
Add conversion of StandardOps and, or and xor to LLVM dialect. -- PiperOrigin-RevId: 242831203
2019-04-10 17:27:30 +08:00
// CHECK-NEXT: %12 = and <4 x i64> %2, %2
%9 = llvm.and %arg2, %arg2 : !llvm<"<4 x i64>">
// CHECK-NEXT: %13 = or <4 x i64> %2, %2
%10 = llvm.or %arg2, %arg2 : !llvm<"<4 x i64>">
// CHECK-NEXT: %14 = xor <4 x i64> %2, %2
%11 = llvm.xor %arg2, %arg2 : !llvm<"<4 x i64>">
LLVM IR lowering: support integer division and remainder operations These operations trivially map to LLVM IR counterparts for operands of scalar and (one-dimensional) vector type. Multi-dimensional vector and tensor type operands would fail type conversion before the operation conversion takes place. Add tests for scalar and vector cases. Also add a test for vector `select` instruction for consistency with other tests. PiperOrigin-RevId: 228077564
2019-01-07 06:09:00 +08:00
// CHECK-NEXT: ret <4 x float> %4
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 %1 : !llvm<"<4 x float>">
LLVM IR lowering: support 1D vector operations Introduce initial support for 1D vector operations. LLVM does not support higher-dimensional vectors so the caller must make sure they don't appear in the input MLIR. Handle the presence of higher-dimensional vectors by failing gracefully. Introduce the type conversion for 1D vector types and hook it up with the rest of the type convresion system. Support "splat" constants for vector types. As a side effect, this refactors constant operation emission by separating out scalar integer constants into a separate case and by extracting out the helper function for scalar float construction. Existing binary operations apply to vectors transparently. PiperOrigin-RevId: 225172349
2018-12-12 22:11:33 +08:00
}
LLVM IR lowering: support SubIOp and SubFOp The binary subtraction operations were not supported by the lowering because they were not essential for the testing flow. Add support for these operations. PiperOrigin-RevId: 226941463
2018-12-27 04:09:06 +08:00
// CHECK-LABEL: @ops
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @ops(%arg0: !llvm.float, %arg1: !llvm.float, %arg2: !llvm.i32, %arg3: !llvm.i32) -> !llvm<"{ float, i32 }"> {
LLVM IR lowering: support SubIOp and SubFOp The binary subtraction operations were not supported by the lowering because they were not essential for the testing flow. Add support for these operations. PiperOrigin-RevId: 226941463
2018-12-27 04:09:06 +08:00
// CHECK-NEXT: fsub float %0, %1
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%0 = llvm.fsub %arg0, %arg1 : !llvm.float
LLVM IR Lowering: support "select" This commit adds support for the "select" operation that lowers directly into its LLVM IR counterpart. A simple test is included. PiperOrigin-RevId: 227527893
2019-01-03 00:52:19 +08:00
// CHECK-NEXT: %6 = sub i32 %2, %3
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%1 = llvm.sub %arg2, %arg3 : !llvm.i32
LLVM IR Lowering: support "select" This commit adds support for the "select" operation that lowers directly into its LLVM IR counterpart. A simple test is included. PiperOrigin-RevId: 227527893
2019-01-03 00:52:19 +08:00
// CHECK-NEXT: %7 = icmp slt i32 %2, %6
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%2 = llvm.icmp "slt" %arg2, %1 : !llvm.i32
LLVM IR lowering: support integer division and remainder operations These operations trivially map to LLVM IR counterparts for operands of scalar and (one-dimensional) vector type. Multi-dimensional vector and tensor type operands would fail type conversion before the operation conversion takes place. Add tests for scalar and vector cases. Also add a test for vector `select` instruction for consistency with other tests. PiperOrigin-RevId: 228077564
2019-01-07 06:09:00 +08:00
// CHECK-NEXT: %8 = select i1 %7, i32 %2, i32 %6
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%3 = llvm.select %2, %arg2, %1 : !llvm.i1, !llvm.i32
LLVM IR lowering: support integer division and remainder operations These operations trivially map to LLVM IR counterparts for operands of scalar and (one-dimensional) vector type. Multi-dimensional vector and tensor type operands would fail type conversion before the operation conversion takes place. Add tests for scalar and vector cases. Also add a test for vector `select` instruction for consistency with other tests. PiperOrigin-RevId: 228077564
2019-01-07 06:09:00 +08:00
// CHECK-NEXT: %9 = sdiv i32 %2, %3
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%4 = llvm.sdiv %arg2, %arg3 : !llvm.i32
LLVM IR lowering: support integer division and remainder operations These operations trivially map to LLVM IR counterparts for operands of scalar and (one-dimensional) vector type. Multi-dimensional vector and tensor type operands would fail type conversion before the operation conversion takes place. Add tests for scalar and vector cases. Also add a test for vector `select` instruction for consistency with other tests. PiperOrigin-RevId: 228077564
2019-01-07 06:09:00 +08:00
// CHECK-NEXT: %10 = udiv i32 %2, %3
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%5 = llvm.udiv %arg2, %arg3 : !llvm.i32
LLVM IR lowering: support integer division and remainder operations These operations trivially map to LLVM IR counterparts for operands of scalar and (one-dimensional) vector type. Multi-dimensional vector and tensor type operands would fail type conversion before the operation conversion takes place. Add tests for scalar and vector cases. Also add a test for vector `select` instruction for consistency with other tests. PiperOrigin-RevId: 228077564
2019-01-07 06:09:00 +08:00
// CHECK-NEXT: %11 = srem i32 %2, %3
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%6 = llvm.srem %arg2, %arg3 : !llvm.i32
LLVM IR lowering: support integer division and remainder operations These operations trivially map to LLVM IR counterparts for operands of scalar and (one-dimensional) vector type. Multi-dimensional vector and tensor type operands would fail type conversion before the operation conversion takes place. Add tests for scalar and vector cases. Also add a test for vector `select` instruction for consistency with other tests. PiperOrigin-RevId: 228077564
2019-01-07 06:09:00 +08:00
// CHECK-NEXT: %12 = urem i32 %2, %3
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%7 = llvm.urem %arg2, %arg3 : !llvm.i32
LLVM IR lowering: support integer division and remainder operations These operations trivially map to LLVM IR counterparts for operands of scalar and (one-dimensional) vector type. Multi-dimensional vector and tensor type operands would fail type conversion before the operation conversion takes place. Add tests for scalar and vector cases. Also add a test for vector `select` instruction for consistency with other tests. PiperOrigin-RevId: 228077564
2019-01-07 06:09:00 +08:00
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%8 = llvm.mlir.undef : !llvm<"{ float, 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
%9 = llvm.insertvalue %0, %8[0] : !llvm<"{ float, i32 }">
%10 = llvm.insertvalue %3, %9[1] : !llvm<"{ float, i32 }">
Lower standard DivF and RemF operations to the LLVM IR dialect Add support for lowering DivF and RemF to LLVM::FDiv and LLMV::FRem respectively. The lowering is a trivial one-to-one transformation. The corresponding operations already existed in the LLVM IR dialect and can be lowered to the LLVM IR proper. Add the necessary tests for scalar and vector forms. PiperOrigin-RevId: 234984608
2019-02-21 22:30:53 +08:00
// CHECK: %15 = fdiv float %0, %1
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%11 = llvm.fdiv %arg0, %arg1 : !llvm.float
Lower standard DivF and RemF operations to the LLVM IR dialect Add support for lowering DivF and RemF to LLVM::FDiv and LLMV::FRem respectively. The lowering is a trivial one-to-one transformation. The corresponding operations already existed in the LLVM IR dialect and can be lowered to the LLVM IR proper. Add the necessary tests for scalar and vector forms. PiperOrigin-RevId: 234984608
2019-02-21 22:30:53 +08:00
// CHECK-NEXT: %16 = frem float %0, %1
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%12 = llvm.frem %arg0, %arg1 : !llvm.float
Lower standard DivF and RemF operations to the LLVM IR dialect Add support for lowering DivF and RemF to LLVM::FDiv and LLMV::FRem respectively. The lowering is a trivial one-to-one transformation. The corresponding operations already existed in the LLVM IR dialect and can be lowered to the LLVM IR proper. Add the necessary tests for scalar and vector forms. PiperOrigin-RevId: 234984608
2019-02-21 22:30:53 +08:00
Add conversion of StandardOps and, or and xor to LLVM dialect. -- PiperOrigin-RevId: 242831203
2019-04-10 17:27:30 +08:00
// CHECK-NEXT: %17 = and i32 %2, %3
%13 = llvm.and %arg2, %arg3 : !llvm.i32
// CHECK-NEXT: %18 = or i32 %2, %3
%14 = llvm.or %arg2, %arg3 : !llvm.i32
// CHECK-NEXT: %19 = xor i32 %2, %3
%15 = llvm.xor %arg2, %arg3 : !llvm.i32
Add integer shift ops to LLVM dialect. PiperOrigin-RevId: 272140049
2019-10-01 13:55:53 +08:00
// CHECK-NEXT: %20 = shl i32 %2, %3
%16 = llvm.shl %arg2, %arg3 : !llvm.i32
// CHECK-NEXT: %21 = lshr i32 %2, %3
%17 = llvm.lshr %arg2, %arg3 : !llvm.i32
// CHECK-NEXT: %22 = ashr i32 %2, %3
%18 = llvm.ashr %arg2, %arg3 : !llvm.i32
Add conversion of StandardOps and, or and xor to LLVM dialect. -- PiperOrigin-RevId: 242831203
2019-04-10 17:27:30 +08:00
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
// CHECK-NEXT: fneg float %0
%19 = llvm.fneg %arg0 : !llvm.float
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 %10 : !llvm<"{ float, i32 }">
LLVM IR lowering: support SubIOp and SubFOp The binary subtraction operations were not supported by the lowering because they were not essential for the testing flow. Add support for these operations. PiperOrigin-RevId: 226941463
2018-12-27 04:09:06 +08:00
}
LLVM dialect conversion and target: support indirect calls Add support for converting MLIR `call_indirect` instructions to the LLVM IR dialect. In LLVM IR, the same instruction is used for direct and indirect calls. In the dialect, we have `llvm.call` and `llvm.call0` to work around the absence of the void type in MLIR. For direct calls, the callee is stored as instruction attribute. Use the same pair of instructions for indirect calls by omitting the callee attribute. In the MLIR to LLVM IR translator, check the presence of attribute to decide whether to construct a direct or an indirect call using different LLVM IR Builder functions. Add support for converting constants of function type to the LLVM IR dialect and for translating them to the LLVM IR proper. The `llvm.constant` operation works similarly to other types: its attribute has MLIR function type but the value it produces has LLVM IR function type wrapped in the dialect type. While lowering, look up the pointer to the converted function in the corresponding mapping. PiperOrigin-RevId: 234132351
2019-02-15 22:25:30 +08:00
//
// Indirect function calls
//
[mlir-translate] Fix test suite. llvm ir printer was changed at LLVM r367755. Prints value numbers for unnamed functions argument. Closes tensorflow/mlir#67 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/67 from denis0x0D:sandbox/fix_mlir_translate ae46844e66f34a02e0cf86782ddadc5bce58b30d PiperOrigin-RevId: 261640048
2019-08-05 16:39:26 +08:00
// CHECK-LABEL: define void @indirect_const_call(i64 {{%.*}}) {
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @indirect_const_call(%arg0: !llvm.i64) {
LLVM dialect conversion and target: support indirect calls Add support for converting MLIR `call_indirect` instructions to the LLVM IR dialect. In LLVM IR, the same instruction is used for direct and indirect calls. In the dialect, we have `llvm.call` and `llvm.call0` to work around the absence of the void type in MLIR. For direct calls, the callee is stored as instruction attribute. Use the same pair of instructions for indirect calls by omitting the callee attribute. In the MLIR to LLVM IR translator, check the presence of attribute to decide whether to construct a direct or an indirect call using different LLVM IR Builder functions. Add support for converting constants of function type to the LLVM IR dialect and for translating them to the LLVM IR proper. The `llvm.constant` operation works similarly to other types: its attribute has MLIR function type but the value it produces has LLVM IR function type wrapped in the dialect type. While lowering, look up the pointer to the converted function in the corresponding mapping. PiperOrigin-RevId: 234132351
2019-02-15 22:25:30 +08:00
// CHECK-NEXT: call void @body(i64 %0)
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%0 = llvm.mlir.constant(@body) : !llvm<"void (i64)*">
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
llvm.call %0(%arg0) : (!llvm.i64) -> ()
LLVM dialect conversion and target: support indirect calls Add support for converting MLIR `call_indirect` instructions to the LLVM IR dialect. In LLVM IR, the same instruction is used for direct and indirect calls. In the dialect, we have `llvm.call` and `llvm.call0` to work around the absence of the void type in MLIR. For direct calls, the callee is stored as instruction attribute. Use the same pair of instructions for indirect calls by omitting the callee attribute. In the MLIR to LLVM IR translator, check the presence of attribute to decide whether to construct a direct or an indirect call using different LLVM IR Builder functions. Add support for converting constants of function type to the LLVM IR dialect and for translating them to the LLVM IR proper. The `llvm.constant` operation works similarly to other types: its attribute has MLIR function type but the value it produces has LLVM IR function type wrapped in the dialect type. While lowering, look up the pointer to the converted function in the corresponding mapping. PiperOrigin-RevId: 234132351
2019-02-15 22:25:30 +08:00
// CHECK-NEXT: ret void
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
LLVM dialect conversion and target: support indirect calls Add support for converting MLIR `call_indirect` instructions to the LLVM IR dialect. In LLVM IR, the same instruction is used for direct and indirect calls. In the dialect, we have `llvm.call` and `llvm.call0` to work around the absence of the void type in MLIR. For direct calls, the callee is stored as instruction attribute. Use the same pair of instructions for indirect calls by omitting the callee attribute. In the MLIR to LLVM IR translator, check the presence of attribute to decide whether to construct a direct or an indirect call using different LLVM IR Builder functions. Add support for converting constants of function type to the LLVM IR dialect and for translating them to the LLVM IR proper. The `llvm.constant` operation works similarly to other types: its attribute has MLIR function type but the value it produces has LLVM IR function type wrapped in the dialect type. While lowering, look up the pointer to the converted function in the corresponding mapping. PiperOrigin-RevId: 234132351
2019-02-15 22:25:30 +08:00
}
[mlir-translate] Fix test suite. llvm ir printer was changed at LLVM r367755. Prints value numbers for unnamed functions argument. Closes tensorflow/mlir#67 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/67 from denis0x0D:sandbox/fix_mlir_translate ae46844e66f34a02e0cf86782ddadc5bce58b30d PiperOrigin-RevId: 261640048
2019-08-05 16:39:26 +08:00
// CHECK-LABEL: define i32 @indirect_call(i32 (float)* {{%.*}}, float {{%.*}}) {
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @indirect_call(%arg0: !llvm<"i32 (float)*">, %arg1: !llvm.float) -> !llvm.i32 {
LLVM dialect conversion and target: support indirect calls Add support for converting MLIR `call_indirect` instructions to the LLVM IR dialect. In LLVM IR, the same instruction is used for direct and indirect calls. In the dialect, we have `llvm.call` and `llvm.call0` to work around the absence of the void type in MLIR. For direct calls, the callee is stored as instruction attribute. Use the same pair of instructions for indirect calls by omitting the callee attribute. In the MLIR to LLVM IR translator, check the presence of attribute to decide whether to construct a direct or an indirect call using different LLVM IR Builder functions. Add support for converting constants of function type to the LLVM IR dialect and for translating them to the LLVM IR proper. The `llvm.constant` operation works similarly to other types: its attribute has MLIR function type but the value it produces has LLVM IR function type wrapped in the dialect type. While lowering, look up the pointer to the converted function in the corresponding mapping. PiperOrigin-RevId: 234132351
2019-02-15 22:25:30 +08:00
// CHECK-NEXT: %3 = call i32 %0(float %1)
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
%0 = llvm.call %arg0(%arg1) : (!llvm.float) -> !llvm.i32
LLVM dialect conversion and target: support indirect calls Add support for converting MLIR `call_indirect` instructions to the LLVM IR dialect. In LLVM IR, the same instruction is used for direct and indirect calls. In the dialect, we have `llvm.call` and `llvm.call0` to work around the absence of the void type in MLIR. For direct calls, the callee is stored as instruction attribute. Use the same pair of instructions for indirect calls by omitting the callee attribute. In the MLIR to LLVM IR translator, check the presence of attribute to decide whether to construct a direct or an indirect call using different LLVM IR Builder functions. Add support for converting constants of function type to the LLVM IR dialect and for translating them to the LLVM IR proper. The `llvm.constant` operation works similarly to other types: its attribute has MLIR function type but the value it produces has LLVM IR function type wrapped in the dialect type. While lowering, look up the pointer to the converted function in the corresponding mapping. PiperOrigin-RevId: 234132351
2019-02-15 22:25:30 +08:00
// CHECK-NEXT: ret i32 %3
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
llvm.return %0 : !llvm.i32
LLVM dialect conversion and target: support indirect calls Add support for converting MLIR `call_indirect` instructions to the LLVM IR dialect. In LLVM IR, the same instruction is used for direct and indirect calls. In the dialect, we have `llvm.call` and `llvm.call0` to work around the absence of the void type in MLIR. For direct calls, the callee is stored as instruction attribute. Use the same pair of instructions for indirect calls by omitting the callee attribute. In the MLIR to LLVM IR translator, check the presence of attribute to decide whether to construct a direct or an indirect call using different LLVM IR Builder functions. Add support for converting constants of function type to the LLVM IR dialect and for translating them to the LLVM IR proper. The `llvm.constant` operation works similarly to other types: its attribute has MLIR function type but the value it produces has LLVM IR function type wrapped in the dialect type. While lowering, look up the pointer to the converted function in the corresponding mapping. PiperOrigin-RevId: 234132351
2019-02-15 22:25:30 +08:00
}
LLVM IR dialect and translation: support conditional branches with arguments Since the goal of the LLVM IR dialect is to reflect LLVM IR in MLIR, the dialect and the conversion procedure must account for the differences betweeen block arguments and LLVM IR PHI nodes. In particular, LLVM IR disallows PHI nodes with different values coming from the same source. Therefore, the LLVM IR dialect now disallows `cond_br` operations that have identical successors accepting arguments, which would lead to invalid PHI nodes. The conversion process resolves the potential PHI source ambiguity by injecting dummy blocks if the same block is used more than once as a successor in an instruction. These dummy blocks branch unconditionally to the original successors, pass them the original operands (available in the dummy block because it is dominated by the original block) and are used instead of them in the original terminator operation. PiperOrigin-RevId: 235682798
2019-02-26 18:02:26 +08:00
//
// Check that we properly construct phi nodes in the blocks that have the same
// predecessor more than once.
//
[mlir-translate] Fix test suite. llvm ir printer was changed at LLVM r367755. Prints value numbers for unnamed functions argument. Closes tensorflow/mlir#67 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/67 from denis0x0D:sandbox/fix_mlir_translate ae46844e66f34a02e0cf86782ddadc5bce58b30d PiperOrigin-RevId: 261640048
2019-08-05 16:39:26 +08:00
// CHECK-LABEL: define void @cond_br_arguments(i1 {{%.*}}, i1 {{%.*}}) {
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @cond_br_arguments(%arg0: !llvm.i1, %arg1: !llvm.i1) {
LLVM IR dialect and translation: support conditional branches with arguments Since the goal of the LLVM IR dialect is to reflect LLVM IR in MLIR, the dialect and the conversion procedure must account for the differences betweeen block arguments and LLVM IR PHI nodes. In particular, LLVM IR disallows PHI nodes with different values coming from the same source. Therefore, the LLVM IR dialect now disallows `cond_br` operations that have identical successors accepting arguments, which would lead to invalid PHI nodes. The conversion process resolves the potential PHI source ambiguity by injecting dummy blocks if the same block is used more than once as a successor in an instruction. These dummy blocks branch unconditionally to the original successors, pass them the original operands (available in the dummy block because it is dominated by the original block) and are used instead of them in the original terminator operation. PiperOrigin-RevId: 235682798
2019-02-26 18:02:26 +08:00
// CHECK-NEXT: br i1 %0, label %3, label %5
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
llvm.cond_br %arg0, ^bb1(%arg0 : !llvm.i1), ^bb2
LLVM IR dialect and translation: support conditional branches with arguments Since the goal of the LLVM IR dialect is to reflect LLVM IR in MLIR, the dialect and the conversion procedure must account for the differences betweeen block arguments and LLVM IR PHI nodes. In particular, LLVM IR disallows PHI nodes with different values coming from the same source. Therefore, the LLVM IR dialect now disallows `cond_br` operations that have identical successors accepting arguments, which would lead to invalid PHI nodes. The conversion process resolves the potential PHI source ambiguity by injecting dummy blocks if the same block is used more than once as a successor in an instruction. These dummy blocks branch unconditionally to the original successors, pass them the original operands (available in the dummy block because it is dominated by the original block) and are used instead of them in the original terminator operation. PiperOrigin-RevId: 235682798
2019-02-26 18:02:26 +08:00
Remove "<label>" from the llvm basic block CHECK names. PiperOrigin-RevId: 239898185
2019-03-23 08:54:26 +08:00
// CHECK: 3:
LLVM IR dialect and translation: support conditional branches with arguments Since the goal of the LLVM IR dialect is to reflect LLVM IR in MLIR, the dialect and the conversion procedure must account for the differences betweeen block arguments and LLVM IR PHI nodes. In particular, LLVM IR disallows PHI nodes with different values coming from the same source. Therefore, the LLVM IR dialect now disallows `cond_br` operations that have identical successors accepting arguments, which would lead to invalid PHI nodes. The conversion process resolves the potential PHI source ambiguity by injecting dummy blocks if the same block is used more than once as a successor in an instruction. These dummy blocks branch unconditionally to the original successors, pass them the original operands (available in the dummy block because it is dominated by the original block) and are used instead of them in the original terminator operation. PiperOrigin-RevId: 235682798
2019-02-26 18:02:26 +08:00
// CHECK-NEXT: %4 = phi i1 [ %1, %5 ], [ %0, %2 ]
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
^bb1(%0 : !llvm.i1):
LLVM IR dialect and translation: support conditional branches with arguments Since the goal of the LLVM IR dialect is to reflect LLVM IR in MLIR, the dialect and the conversion procedure must account for the differences betweeen block arguments and LLVM IR PHI nodes. In particular, LLVM IR disallows PHI nodes with different values coming from the same source. Therefore, the LLVM IR dialect now disallows `cond_br` operations that have identical successors accepting arguments, which would lead to invalid PHI nodes. The conversion process resolves the potential PHI source ambiguity by injecting dummy blocks if the same block is used more than once as a successor in an instruction. These dummy blocks branch unconditionally to the original successors, pass them the original operands (available in the dummy block because it is dominated by the original block) and are used instead of them in the original terminator operation. PiperOrigin-RevId: 235682798
2019-02-26 18:02:26 +08:00
// CHECK-NEXT: ret void
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
LLVM IR dialect and translation: support conditional branches with arguments Since the goal of the LLVM IR dialect is to reflect LLVM IR in MLIR, the dialect and the conversion procedure must account for the differences betweeen block arguments and LLVM IR PHI nodes. In particular, LLVM IR disallows PHI nodes with different values coming from the same source. Therefore, the LLVM IR dialect now disallows `cond_br` operations that have identical successors accepting arguments, which would lead to invalid PHI nodes. The conversion process resolves the potential PHI source ambiguity by injecting dummy blocks if the same block is used more than once as a successor in an instruction. These dummy blocks branch unconditionally to the original successors, pass them the original operands (available in the dummy block because it is dominated by the original block) and are used instead of them in the original terminator operation. PiperOrigin-RevId: 235682798
2019-02-26 18:02:26 +08:00
Remove "<label>" from the llvm basic block CHECK names. PiperOrigin-RevId: 239898185
2019-03-23 08:54:26 +08:00
// CHECK: 5:
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
^bb2:
LLVM IR dialect and translation: support conditional branches with arguments Since the goal of the LLVM IR dialect is to reflect LLVM IR in MLIR, the dialect and the conversion procedure must account for the differences betweeen block arguments and LLVM IR PHI nodes. In particular, LLVM IR disallows PHI nodes with different values coming from the same source. Therefore, the LLVM IR dialect now disallows `cond_br` operations that have identical successors accepting arguments, which would lead to invalid PHI nodes. The conversion process resolves the potential PHI source ambiguity by injecting dummy blocks if the same block is used more than once as a successor in an instruction. These dummy blocks branch unconditionally to the original successors, pass them the original operands (available in the dummy block because it is dominated by the original block) and are used instead of them in the original terminator operation. PiperOrigin-RevId: 235682798
2019-02-26 18:02:26 +08:00
// CHECK-NEXT: br label %3
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
llvm.br ^bb1(%arg1 : !llvm.i1)
LLVM IR dialect and translation: support conditional branches with arguments Since the goal of the LLVM IR dialect is to reflect LLVM IR in MLIR, the dialect and the conversion procedure must account for the differences betweeen block arguments and LLVM IR PHI nodes. In particular, LLVM IR disallows PHI nodes with different values coming from the same source. Therefore, the LLVM IR dialect now disallows `cond_br` operations that have identical successors accepting arguments, which would lead to invalid PHI nodes. The conversion process resolves the potential PHI source ambiguity by injecting dummy blocks if the same block is used more than once as a successor in an instruction. These dummy blocks branch unconditionally to the original successors, pass them the original operands (available in the dummy block because it is dominated by the original block) and are used instead of them in the original terminator operation. PiperOrigin-RevId: 235682798
2019-02-26 18:02:26 +08:00
}
Using llvm.noalias attribute when generating LLVMIR. PiperOrigin-RevId: 237063104
2019-03-07 01:34:53 +08:00
[mlir-translate] Fix test suite. llvm ir printer was changed at LLVM r367755. Prints value numbers for unnamed functions argument. Closes tensorflow/mlir#67 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/67 from denis0x0D:sandbox/fix_mlir_translate ae46844e66f34a02e0cf86782ddadc5bce58b30d PiperOrigin-RevId: 261640048
2019-08-05 16:39:26 +08:00
// CHECK-LABEL: define void @llvm_noalias(float* noalias {{%*.}}) {
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @llvm_noalias(%arg0: !llvm<"float*"> {llvm.noalias = true}) {
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
Using llvm.noalias attribute when generating LLVMIR. PiperOrigin-RevId: 237063104
2019-03-07 01:34:53 +08:00
}
Introduce std.varargs attribute to mark variadic arguments functions This is only teaching the LLVM converter to propagate the attribute onto the function type. MLIR will not recognize this arguments, so it would only be useful when calling for example `printf` with the same arguments across a module. Since varargs is part of the ABI lowering, this is not NFC. -- PiperOrigin-RevId: 242382427
2019-04-08 08:11:02 +08:00
Add iterator support to ElementsAttr and SparseElementsAttr. This will allow iterating the values of a non-opaque ElementsAttr, with all of the types currently supported by DenseElementsAttr. This should help reduce the amount of specialization on DenseElementsAttr. PiperOrigin-RevId: 264968151
2019-08-23 09:58:51 +08:00
// CHECK-LABEL: @llvm_varargs(...)
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @llvm_varargs(...)
Add LLVM::IntToPtrOp and LLVM::PtrToIntOp to LLVM dialect. -- PiperOrigin-RevId: 249604199
2019-05-23 17:03:14 +08:00
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @intpointerconversion(%arg0 : !llvm.i32) -> !llvm.i32 {
Add LLVM::IntToPtrOp and LLVM::PtrToIntOp to LLVM dialect. -- PiperOrigin-RevId: 249604199
2019-05-23 17:03:14 +08:00
// CHECK: %2 = inttoptr i32 %0 to i32*
// CHECK-NEXT: %3 = ptrtoint i32* %2 to i32
%1 = llvm.inttoptr %arg0 : !llvm.i32 to !llvm<"i32*">
%2 = llvm.ptrtoint %1 : !llvm<"i32*"> to !llvm.i32
llvm.return %2 : !llvm.i32
}
[mlir][llvm] Add missing cast ops Also adds a builder method for fcmp, identical to that for icmp. PiperOrigin-RevId: 277923158
2019-11-01 22:31:33 +08:00
llvm.func @fpconversion(%arg0 : !llvm.i32) -> !llvm.i32 {
// CHECK: %2 = sitofp i32 %0 to float
// CHECK-NEXT: %3 = fptosi float %2 to i32
// CHECK-NEXT: %4 = uitofp i32 %3 to float
// CHECK-NEXT: %5 = fptoui float %4 to i32
%1 = llvm.sitofp %arg0 : !llvm.i32 to !llvm.float
%2 = llvm.fptosi %1 : !llvm.float to !llvm.i32
%3 = llvm.uitofp %2 : !llvm.i32 to !llvm.float
%4 = llvm.fptoui %3 : !llvm.float to !llvm.i32
llvm.return %4 : !llvm.i32
}
// CHECK-LABEL: @addrspace
llvm.func @addrspace(%arg0 : !llvm<"i32*">) -> !llvm<"i32 addrspace(2)*"> {
// CHECK: %2 = addrspacecast i32* %0 to i32 addrspace(2)*
%1 = llvm.addrspacecast %arg0 : !llvm<"i32*"> to !llvm<"i32 addrspace(2)*">
llvm.return %1 : !llvm<"i32 addrspace(2)*">
}
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @stringconstant() -> !llvm<"i8*"> {
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%1 = llvm.mlir.constant("Hello world!") : !llvm<"i8*">
Add support for llvm.constant with StringAttr as value. These are translated to an llvm::ConstantDataArray on translation to llvm IR proper. -- PiperOrigin-RevId: 249813111
2019-05-24 19:49:56 +08:00
// CHECK: ret [12 x i8] c"Hello world!"
llvm.return %1 : !llvm<"i8*">
}
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @noreach() {
Add the LLVM IR unreachable instruction to the LLVMIR dialect. http://llvm.org/docs/LangRef.html#unreachable-instruction Closes tensorflow/mlir#64 PiperOrigin-RevId: 262301557
2019-08-08 16:05:26 +08:00
// CHECK: unreachable
llvm.unreachable
}
Add support for floating-point comparison 'fcmp' to the LLVM dialect. This adds support for fcmp to the LLVM dialect and adds any necessary lowerings, as well as support for EDSCs. Closes tensorflow/mlir#69 PiperOrigin-RevId: 262475255
2019-08-09 09:29:23 +08:00
// CHECK-LABEL: define void @fcmp
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @fcmp(%arg0: !llvm.float, %arg1: !llvm.float) {
Add support for floating-point comparison 'fcmp' to the LLVM dialect. This adds support for fcmp to the LLVM dialect and adds any necessary lowerings, as well as support for EDSCs. Closes tensorflow/mlir#69 PiperOrigin-RevId: 262475255
2019-08-09 09:29:23 +08:00
// CHECK: fcmp oeq float %0, %1
// CHECK-NEXT: fcmp ogt float %0, %1
// CHECK-NEXT: fcmp oge float %0, %1
// CHECK-NEXT: fcmp olt float %0, %1
// CHECK-NEXT: fcmp ole float %0, %1
// CHECK-NEXT: fcmp one float %0, %1
// CHECK-NEXT: fcmp ord float %0, %1
// CHECK-NEXT: fcmp ueq float %0, %1
// CHECK-NEXT: fcmp ugt float %0, %1
// CHECK-NEXT: fcmp uge float %0, %1
// CHECK-NEXT: fcmp ult float %0, %1
// CHECK-NEXT: fcmp ule float %0, %1
// CHECK-NEXT: fcmp une float %0, %1
// CHECK-NEXT: fcmp uno float %0, %1
%0 = llvm.fcmp "oeq" %arg0, %arg1 : !llvm.float
%1 = llvm.fcmp "ogt" %arg0, %arg1 : !llvm.float
%2 = llvm.fcmp "oge" %arg0, %arg1 : !llvm.float
%3 = llvm.fcmp "olt" %arg0, %arg1 : !llvm.float
%4 = llvm.fcmp "ole" %arg0, %arg1 : !llvm.float
%5 = llvm.fcmp "one" %arg0, %arg1 : !llvm.float
%6 = llvm.fcmp "ord" %arg0, %arg1 : !llvm.float
%7 = llvm.fcmp "ueq" %arg0, %arg1 : !llvm.float
%8 = llvm.fcmp "ugt" %arg0, %arg1 : !llvm.float
%9 = llvm.fcmp "uge" %arg0, %arg1 : !llvm.float
%10 = llvm.fcmp "ult" %arg0, %arg1 : !llvm.float
%11 = llvm.fcmp "ule" %arg0, %arg1 : !llvm.float
%12 = llvm.fcmp "une" %arg0, %arg1 : !llvm.float
%13 = llvm.fcmp "uno" %arg0, %arg1 : !llvm.float
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
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @vect(%arg0: !llvm<"<4 x float>">, %arg1: !llvm.i32, %arg2: !llvm.float) {
Allow LLVM::ExtractElementOp to have non-i32 indices. Also change the text format a bit, so that indices are braced by squares. PiperOrigin-RevId: 282437095
2019-11-26 06:44:20 +08:00
// CHECK-NEXT: extractelement <4 x float> {{.*}}, i32
// CHECK-NEXT: insertelement <4 x float> {{.*}}, float %2, i32
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-NEXT: shufflevector <4 x float> {{.*}}, <4 x float> {{.*}}, <5 x i32> <i32 0, i32 0, i32 0, i32 0, i32 7>
Allow LLVM::ExtractElementOp to have non-i32 indices. Also change the text format a bit, so that indices are braced by squares. PiperOrigin-RevId: 282437095
2019-11-26 06:44:20 +08:00
%0 = llvm.extractelement %arg0[%arg1 : !llvm.i32] : !llvm<"<4 x float>">
%1 = llvm.insertelement %arg2, %arg0[%arg1 : !llvm.i32] : !llvm<"<4 x float>">
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
%2 = llvm.shufflevector %arg0, %arg0 [0 : i32, 0 : i32, 0 : i32, 0 : i32, 7 : i32] : !llvm<"<4 x float>">, !llvm<"<4 x float>">
llvm.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
Allow LLVM::ExtractElementOp to have non-i32 indices. Also change the text format a bit, so that indices are braced by squares. PiperOrigin-RevId: 282437095
2019-11-26 06:44:20 +08:00
// CHECK-LABEL: @vect_i64idx
llvm.func @vect_i64idx(%arg0: !llvm<"<4 x float>">, %arg1: !llvm.i64, %arg2: !llvm.float) {
// CHECK-NEXT: extractelement <4 x float> {{.*}}, i64
// CHECK-NEXT: insertelement <4 x float> {{.*}}, float %2, i64
%0 = llvm.extractelement %arg0[%arg1 : !llvm.i64] : !llvm<"<4 x float>">
%1 = llvm.insertelement %arg2, %arg0[%arg1 : !llvm.i64] : !llvm<"<4 x float>">
llvm.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
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @alloca(%size : !llvm.i64) {
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: alloca
// CHECK-NOT: align
llvm.alloca %size x !llvm.i32 {alignment = 0} : (!llvm.i64) -> (!llvm<"i32*">)
// CHECK-NEXT: alloca {{.*}} align 8
llvm.alloca %size x !llvm.i32 {alignment = 8} : (!llvm.i64) -> (!llvm<"i32*">)
llvm.return
}
Add iterator support to ElementsAttr and SparseElementsAttr. This will allow iterating the values of a non-opaque ElementsAttr, with all of the types currently supported by DenseElementsAttr. This should help reduce the amount of specialization on DenseElementsAttr. PiperOrigin-RevId: 264968151
2019-08-23 09:58:51 +08:00
// CHECK-LABEL: @constants
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
llvm.func @constants() -> !llvm<"<4 x float>"> {
Add iterator support to ElementsAttr and SparseElementsAttr. This will allow iterating the values of a non-opaque ElementsAttr, with all of the types currently supported by DenseElementsAttr. This should help reduce the amount of specialization on DenseElementsAttr. PiperOrigin-RevId: 264968151
2019-08-23 09:58:51 +08:00
// CHECK: ret <4 x float> <float 4.2{{0*}}e+01, float 0.{{0*}}e+00, float 0.{{0*}}e+00, float 0.{{0*}}e+00>
LLVM dialect: prefix auxiliary operations with "mlir." Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
2019-09-04 00:10:24 +08:00
%0 = llvm.mlir.constant(sparse<[[0]], [4.2e+01]> : vector<4xf32>) : !llvm<"<4 x float>">
Add iterator support to ElementsAttr and SparseElementsAttr. This will allow iterating the values of a non-opaque ElementsAttr, with all of the types currently supported by DenseElementsAttr. This should help reduce the amount of specialization on DenseElementsAttr. PiperOrigin-RevId: 264968151
2019-08-23 09:58:51 +08:00
llvm.return %0 : !llvm<"<4 x float>">
}
Add FPToSI/FPExt/FPTrunc cast ops to the LLVM dialect. Closes tensorflow/mlir#99 PiperOrigin-RevId: 265538731
2019-08-27 05:18:47 +08:00
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
// CHECK-LABEL: @fp_casts
llvm.func @fp_casts(%fp1 : !llvm<"float">, %fp2 : !llvm<"double">) -> !llvm.i16 {
Add FPToSI/FPExt/FPTrunc cast ops to the LLVM dialect. Closes tensorflow/mlir#99 PiperOrigin-RevId: 265538731
2019-08-27 05:18:47 +08:00
// CHECK: fptrunc double {{.*}} to float
%a = llvm.fptrunc %fp2 : !llvm<"double"> to !llvm<"float">
// CHECK: fpext float {{.*}} to double
%b = llvm.fpext %fp1 : !llvm<"float"> to !llvm<"double">
// CHECK: fptosi double {{.*}} to i16
%c = llvm.fptosi %b : !llvm<"double"> to !llvm.i16
llvm.return %c : !llvm.i16
}
Add integer sign- and zero-extension and truncation to standard. This adds sign- and zero-extension and truncation of integer types to the standard dialects. This allows to perform integer type conversions without having to go to the LLVM dialect and introduce custom type casts (between standard and LLVM integer types). Closes tensorflow/mlir#134 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/134 from ombre5733:sext-zext-trunc-in-std c7657bc84c0ca66b304e53ec03797e09152e4d31 PiperOrigin-RevId: 270479722
2019-09-22 07:14:07 +08:00
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
// CHECK-LABEL: @integer_extension_and_truncation
llvm.func @integer_extension_and_truncation(%a : !llvm.i32) {
Add integer sign- and zero-extension and truncation to standard. This adds sign- and zero-extension and truncation of integer types to the standard dialects. This allows to perform integer type conversions without having to go to the LLVM dialect and introduce custom type casts (between standard and LLVM integer types). Closes tensorflow/mlir#134 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/134 from ombre5733:sext-zext-trunc-in-std c7657bc84c0ca66b304e53ec03797e09152e4d31 PiperOrigin-RevId: 270479722
2019-09-22 07:14:07 +08:00
// CHECK: sext i32 {{.*}} to i64
// CHECK: zext i32 {{.*}} to i64
// CHECK: trunc i32 {{.*}} to i16
%0 = llvm.sext %a : !llvm.i32 to !llvm.i64
%1 = llvm.zext %a : !llvm.i32 to !llvm.i64
%2 = llvm.trunc %a : !llvm.i32 to !llvm.i16
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 that the auxiliary `null` operation is converted into a `null` value.
// CHECK-LABEL: @null
llvm.func @null() -> !llvm<"i32*"> {
%0 = llvm.mlir.null : !llvm<"i32*">
// CHECK: ret i32* null
llvm.return %0 : !llvm<"i32*">
}