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

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

70 lines
2.5 KiB
MLIR
Raw Normal View History

Fix JitRunner.cpp Error creation pattern and reactivate tests. linalg_integration_test.mlir and simple.mlir were temporarily disabled due to an OSS-only failure. The issue is that, once created, an llvm::Error must be explicitly checked before it can be discarded or overwritten. This CL fixes the issue and reenable the test. PiperOrigin-RevId: 271589651
2019-09-28 00:44:54 +08:00
// RUN: mlir-cpu-runner %s | FileCheck %s
// RUN: mlir-cpu-runner %s -e foo | FileCheck -check-prefix=NOMAIN %s
[JitRunner] add support for i32 and i64 output Differential Revision: https://reviews.llvm.org/D80675
2019-11-23 08:04:44 +08:00
// RUN: mlir-cpu-runner %s --entry-point-result=i32 -e int32_main | FileCheck -check-prefix=INT32MAIN %s
// RUN: mlir-cpu-runner %s --entry-point-result=i64 -e int64_main | FileCheck -check-prefix=INT64MAIN %s
Fix JitRunner.cpp Error creation pattern and reactivate tests. linalg_integration_test.mlir and simple.mlir were temporarily disabled due to an OSS-only failure. The issue is that, once created, an llvm::Error must be explicitly checked before it can be discarded or overwritten. This CL fixes the issue and reenable the test. PiperOrigin-RevId: 271589651
2019-09-28 00:44:54 +08:00
// RUN: mlir-cpu-runner %s -O3 | FileCheck %s
Simple CPU runner This implements a simple CPU runner based on LLVM Orc JIT. The base functionality is provided by the ExecutionEngine class that compiles and links the module, and provides an interface for obtaining function pointers to the JIT-compiled MLIR functions and for invoking those functions directly. Since function pointers need to be casted to the correct pointer type, the ExecutionEngine wraps LLVM IR functions obtained from MLIR into a helper function with the common signature `void (void **)` where the single argument is interpreted as a list of pointers to the actual arguments passed to the function, eventually followed by a pointer to the result of the function. Additionally, the ExecutionEngine is set up to resolve library functions to those available in the current process, enabling support for, e.g., simple C library calls. For integration purposes, this also provides a simplistic runtime for memref descriptors as expected by the LLVM IR code produced by MLIR translation. In particular, memrefs are transformed into LLVM structs (can be mapped to C structs) with a pointer to the data, followed by dynamic sizes. This implementation only supports statically-shaped memrefs of type float, but can be extened if necessary. Provide a binary for the runner and a test that exercises it. PiperOrigin-RevId: 230876363
2019-01-25 19:16:06 +08:00
Fix JitRunner.cpp Error creation pattern and reactivate tests. linalg_integration_test.mlir and simple.mlir were temporarily disabled due to an OSS-only failure. The issue is that, once created, an llvm::Error must be explicitly checked before it can be discarded or overwritten. This CL fixes the issue and reenable the test. PiperOrigin-RevId: 271589651
2019-09-28 00:44:54 +08:00
// RUN: cp %s %t
// RUN: mlir-cpu-runner %t -dump-object-file | FileCheck %t
// RUN: ls %t.o
// RUN: rm %t.o
Add mechanism to dump JIT-compiled objects to files This commit introduces the bits to be able to dump JIT-compile objects to external files by passing an object cache to OrcJit. The new functionality is tested in mlir-cpu-runner under the flag `dump-object-file`. Closes tensorflow/mlir#95 PiperOrigin-RevId: 266439265
2019-08-31 04:01:34 +08:00
Fix JitRunner.cpp Error creation pattern and reactivate tests. linalg_integration_test.mlir and simple.mlir were temporarily disabled due to an OSS-only failure. The issue is that, once created, an llvm::Error must be explicitly checked before it can be discarded or overwritten. This CL fixes the issue and reenable the test. PiperOrigin-RevId: 271589651
2019-09-28 00:44:54 +08:00
// RUN: mlir-cpu-runner %s -dump-object-file -object-filename=%T/test.o | FileCheck %s
// RUN: ls %T/test.o
// RUN: rm %T/test.o
Add mechanism to dump JIT-compiled objects to files This commit introduces the bits to be able to dump JIT-compile objects to external files by passing an object cache to OrcJit. The new functionality is tested in mlir-cpu-runner under the flag `dump-object-file`. Closes tensorflow/mlir#95 PiperOrigin-RevId: 266439265
2019-08-31 04:01:34 +08:00
Drop support for memrefs from JitRunner The support for functions taking and returning memrefs of floats was introduced in the first version of the runner, created before MLIR had reliable lowering of allocation/deallocation to library calls. It forcibly runs MLIR transformation convering affine, loop and standard dialects into the LLVM dialect, unlike the other runner flows that accept the LLVM dialect directly. Memref support leads to more complex layering and is generally fragile. Drop it in favor of functions returning a scalar, or library-based function calls to print memrefs and other data structures. PiperOrigin-RevId: 271330839
2019-09-26 20:41:26 +08:00
// Declarations of C library functions.
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 @fabsf(!llvm.float) -> !llvm.float
[mlir] switch the modeling of LLVM types to use the new mechanism A new first-party modeling for LLVM IR types in the LLVM dialect has been developed in parallel to the existing modeling based on wrapping LLVM `Type *` instances. It resolves the long-standing problem of modeling identified structure types, including recursive structures, and enables future removal of LLVMContext and related locking mechanisms from LLVMDialect. This commit only switches the modeling by (a) renaming LLVMTypeNew to LLVMType, (b) removing the old implementaiton of LLVMType, and (c) updating the tests. It is intentionally minimal. Separate commits will remove the infrastructure built for the transition and update API uses where appropriate. Depends On D85020 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D85021
2020-08-04 17:37:50 +08:00
llvm.func @malloc(!llvm.i64) -> !llvm.ptr<i8>
llvm.func @free(!llvm.ptr<i8>)
Simple CPU runner This implements a simple CPU runner based on LLVM Orc JIT. The base functionality is provided by the ExecutionEngine class that compiles and links the module, and provides an interface for obtaining function pointers to the JIT-compiled MLIR functions and for invoking those functions directly. Since function pointers need to be casted to the correct pointer type, the ExecutionEngine wraps LLVM IR functions obtained from MLIR into a helper function with the common signature `void (void **)` where the single argument is interpreted as a list of pointers to the actual arguments passed to the function, eventually followed by a pointer to the result of the function. Additionally, the ExecutionEngine is set up to resolve library functions to those available in the current process, enabling support for, e.g., simple C library calls. For integration purposes, this also provides a simplistic runtime for memref descriptors as expected by the LLVM IR code produced by MLIR translation. In particular, memrefs are transformed into LLVM structs (can be mapped to C structs) with a pointer to the data, followed by dynamic sizes. This implementation only supports statically-shaped memrefs of type float, but can be extened if necessary. Provide a binary for the runner and a test that exercises it. PiperOrigin-RevId: 230876363
2019-01-25 19:16:06 +08:00
Drop support for memrefs from JitRunner The support for functions taking and returning memrefs of floats was introduced in the first version of the runner, created before MLIR had reliable lowering of allocation/deallocation to library calls. It forcibly runs MLIR transformation convering affine, loop and standard dialects into the LLVM dialect, unlike the other runner flows that accept the LLVM dialect directly. Memref support leads to more complex layering and is generally fragile. Drop it in favor of functions returning a scalar, or library-based function calls to print memrefs and other data structures. PiperOrigin-RevId: 271330839
2019-09-26 20:41:26 +08:00
// Check that a simple function with a nested call works.
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 @main() -> !llvm.float {
Drop support for memrefs from JitRunner The support for functions taking and returning memrefs of floats was introduced in the first version of the runner, created before MLIR had reliable lowering of allocation/deallocation to library calls. It forcibly runs MLIR transformation convering affine, loop and standard dialects into the LLVM dialect, unlike the other runner flows that accept the LLVM dialect directly. Memref support leads to more complex layering and is generally fragile. Drop it in favor of functions returning a scalar, or library-based function calls to print memrefs and other data structures. PiperOrigin-RevId: 271330839
2019-09-26 20:41:26 +08:00
%0 = llvm.mlir.constant(-4.200000e+02 : f32) : !llvm.float
%1 = llvm.call @fabsf(%0) : (!llvm.float) -> !llvm.float
llvm.return %1 : !llvm.float
Simple CPU runner This implements a simple CPU runner based on LLVM Orc JIT. The base functionality is provided by the ExecutionEngine class that compiles and links the module, and provides an interface for obtaining function pointers to the JIT-compiled MLIR functions and for invoking those functions directly. Since function pointers need to be casted to the correct pointer type, the ExecutionEngine wraps LLVM IR functions obtained from MLIR into a helper function with the common signature `void (void **)` where the single argument is interpreted as a list of pointers to the actual arguments passed to the function, eventually followed by a pointer to the result of the function. Additionally, the ExecutionEngine is set up to resolve library functions to those available in the current process, enabling support for, e.g., simple C library calls. For integration purposes, this also provides a simplistic runtime for memref descriptors as expected by the LLVM IR code produced by MLIR translation. In particular, memrefs are transformed into LLVM structs (can be mapped to C structs) with a pointer to the data, followed by dynamic sizes. This implementation only supports statically-shaped memrefs of type float, but can be extened if necessary. Provide a binary for the runner and a test that exercises it. PiperOrigin-RevId: 230876363
2019-01-25 19:16:06 +08:00
}
Drop support for memrefs from JitRunner The support for functions taking and returning memrefs of floats was introduced in the first version of the runner, created before MLIR had reliable lowering of allocation/deallocation to library calls. It forcibly runs MLIR transformation convering affine, loop and standard dialects into the LLVM dialect, unlike the other runner flows that accept the LLVM dialect directly. Memref support leads to more complex layering and is generally fragile. Drop it in favor of functions returning a scalar, or library-based function calls to print memrefs and other data structures. PiperOrigin-RevId: 271330839
2019-09-26 20:41:26 +08:00
// CHECK: 4.200000e+02
Simple CPU runner This implements a simple CPU runner based on LLVM Orc JIT. The base functionality is provided by the ExecutionEngine class that compiles and links the module, and provides an interface for obtaining function pointers to the JIT-compiled MLIR functions and for invoking those functions directly. Since function pointers need to be casted to the correct pointer type, the ExecutionEngine wraps LLVM IR functions obtained from MLIR into a helper function with the common signature `void (void **)` where the single argument is interpreted as a list of pointers to the actual arguments passed to the function, eventually followed by a pointer to the result of the function. Additionally, the ExecutionEngine is set up to resolve library functions to those available in the current process, enabling support for, e.g., simple C library calls. For integration purposes, this also provides a simplistic runtime for memref descriptors as expected by the LLVM IR code produced by MLIR translation. In particular, memrefs are transformed into LLVM structs (can be mapped to C structs) with a pointer to the data, followed by dynamic sizes. This implementation only supports statically-shaped memrefs of type float, but can be extened if necessary. Provide a binary for the runner and a test that exercises it. PiperOrigin-RevId: 230876363
2019-01-25 19:16:06 +08:00
Drop support for memrefs from JitRunner The support for functions taking and returning memrefs of floats was introduced in the first version of the runner, created before MLIR had reliable lowering of allocation/deallocation to library calls. It forcibly runs MLIR transformation convering affine, loop and standard dialects into the LLVM dialect, unlike the other runner flows that accept the LLVM dialect directly. Memref support leads to more complex layering and is generally fragile. Drop it in favor of functions returning a scalar, or library-based function calls to print memrefs and other data structures. PiperOrigin-RevId: 271330839
2019-09-26 20:41:26 +08:00
// Helper typed functions wrapping calls to "malloc" and "free".
[mlir] switch the modeling of LLVM types to use the new mechanism A new first-party modeling for LLVM IR types in the LLVM dialect has been developed in parallel to the existing modeling based on wrapping LLVM `Type *` instances. It resolves the long-standing problem of modeling identified structure types, including recursive structures, and enables future removal of LLVMContext and related locking mechanisms from LLVMDialect. This commit only switches the modeling by (a) renaming LLVMTypeNew to LLVMType, (b) removing the old implementaiton of LLVMType, and (c) updating the tests. It is intentionally minimal. Separate commits will remove the infrastructure built for the transition and update API uses where appropriate. Depends On D85020 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D85021
2020-08-04 17:37:50 +08:00
llvm.func @allocation() -> !llvm.ptr<float> {
Drop support for memrefs from JitRunner The support for functions taking and returning memrefs of floats was introduced in the first version of the runner, created before MLIR had reliable lowering of allocation/deallocation to library calls. It forcibly runs MLIR transformation convering affine, loop and standard dialects into the LLVM dialect, unlike the other runner flows that accept the LLVM dialect directly. Memref support leads to more complex layering and is generally fragile. Drop it in favor of functions returning a scalar, or library-based function calls to print memrefs and other data structures. PiperOrigin-RevId: 271330839
2019-09-26 20:41:26 +08:00
%0 = llvm.mlir.constant(4 : index) : !llvm.i64
[mlir] switch the modeling of LLVM types to use the new mechanism A new first-party modeling for LLVM IR types in the LLVM dialect has been developed in parallel to the existing modeling based on wrapping LLVM `Type *` instances. It resolves the long-standing problem of modeling identified structure types, including recursive structures, and enables future removal of LLVMContext and related locking mechanisms from LLVMDialect. This commit only switches the modeling by (a) renaming LLVMTypeNew to LLVMType, (b) removing the old implementaiton of LLVMType, and (c) updating the tests. It is intentionally minimal. Separate commits will remove the infrastructure built for the transition and update API uses where appropriate. Depends On D85020 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D85021
2020-08-04 17:37:50 +08:00
%1 = llvm.call @malloc(%0) : (!llvm.i64) -> !llvm.ptr<i8>
%2 = llvm.bitcast %1 : !llvm.ptr<i8> to !llvm.ptr<float>
llvm.return %2 : !llvm.ptr<float>
Drop support for memrefs from JitRunner The support for functions taking and returning memrefs of floats was introduced in the first version of the runner, created before MLIR had reliable lowering of allocation/deallocation to library calls. It forcibly runs MLIR transformation convering affine, loop and standard dialects into the LLVM dialect, unlike the other runner flows that accept the LLVM dialect directly. Memref support leads to more complex layering and is generally fragile. Drop it in favor of functions returning a scalar, or library-based function calls to print memrefs and other data structures. PiperOrigin-RevId: 271330839
2019-09-26 20:41:26 +08:00
}
[mlir] switch the modeling of LLVM types to use the new mechanism A new first-party modeling for LLVM IR types in the LLVM dialect has been developed in parallel to the existing modeling based on wrapping LLVM `Type *` instances. It resolves the long-standing problem of modeling identified structure types, including recursive structures, and enables future removal of LLVMContext and related locking mechanisms from LLVMDialect. This commit only switches the modeling by (a) renaming LLVMTypeNew to LLVMType, (b) removing the old implementaiton of LLVMType, and (c) updating the tests. It is intentionally minimal. Separate commits will remove the infrastructure built for the transition and update API uses where appropriate. Depends On D85020 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D85021
2020-08-04 17:37:50 +08:00
llvm.func @deallocation(%arg0: !llvm.ptr<float>) {
%0 = llvm.bitcast %arg0 : !llvm.ptr<float> to !llvm.ptr<i8>
llvm.call @free(%0) : (!llvm.ptr<i8>) -> ()
Drop support for memrefs from JitRunner The support for functions taking and returning memrefs of floats was introduced in the first version of the runner, created before MLIR had reliable lowering of allocation/deallocation to library calls. It forcibly runs MLIR transformation convering affine, loop and standard dialects into the LLVM dialect, unlike the other runner flows that accept the LLVM dialect directly. Memref support leads to more complex layering and is generally fragile. Drop it in favor of functions returning a scalar, or library-based function calls to print memrefs and other data structures. PiperOrigin-RevId: 271330839
2019-09-26 20:41:26 +08:00
llvm.return
Simple CPU runner This implements a simple CPU runner based on LLVM Orc JIT. The base functionality is provided by the ExecutionEngine class that compiles and links the module, and provides an interface for obtaining function pointers to the JIT-compiled MLIR functions and for invoking those functions directly. Since function pointers need to be casted to the correct pointer type, the ExecutionEngine wraps LLVM IR functions obtained from MLIR into a helper function with the common signature `void (void **)` where the single argument is interpreted as a list of pointers to the actual arguments passed to the function, eventually followed by a pointer to the result of the function. Additionally, the ExecutionEngine is set up to resolve library functions to those available in the current process, enabling support for, e.g., simple C library calls. For integration purposes, this also provides a simplistic runtime for memref descriptors as expected by the LLVM IR code produced by MLIR translation. In particular, memrefs are transformed into LLVM structs (can be mapped to C structs) with a pointer to the data, followed by dynamic sizes. This implementation only supports statically-shaped memrefs of type float, but can be extened if necessary. Provide a binary for the runner and a test that exercises it. PiperOrigin-RevId: 230876363
2019-01-25 19:16:06 +08:00
}
Add missing lowering to CFG in mlir-cpu-runner + related cleanup - the list of passes run by mlir-cpu-runner included -lower-affine and -lower-to-llvm but was missing -lower-to-cfg (because -lower-affine at some point used to lower straight to CFG); add -lower-to-cfg in between. IR with affine ops can now be run by mlir-cpu-runner. - update -lower-to-cfg to be consistent with other passes (create*Pass methods were changed to return unique ptrs, but -lower-to-cfg appears to have been missed). - mlir-cpu-runner was unable to parse custom form of affine op's - fix link options - drop unnecessary run options from test/mlir-cpu-runner/simple.mlir (none of the test cases had loops) - -convert-to-llvmir was changed to -lower-to-llvm at some point, but the create pass method name wasn't updated (this pass converts/lowers to LLVM dialect as opposed to LLVM IR). Fix this. (If we prefer "convert", the cmd-line options could be changed to "-convert-to-llvm/cfg" then.) Signed-off-by: Uday Bondhugula <uday@polymagelabs.com> Closes tensorflow/mlir#115 PiperOrigin-RevId: 266666909
2019-09-02 02:32:52 +08:00
Drop support for memrefs from JitRunner The support for functions taking and returning memrefs of floats was introduced in the first version of the runner, created before MLIR had reliable lowering of allocation/deallocation to library calls. It forcibly runs MLIR transformation convering affine, loop and standard dialects into the LLVM dialect, unlike the other runner flows that accept the LLVM dialect directly. Memref support leads to more complex layering and is generally fragile. Drop it in favor of functions returning a scalar, or library-based function calls to print memrefs and other data structures. PiperOrigin-RevId: 271330839
2019-09-26 20:41:26 +08:00
// Check that allocation and deallocation works, and that a custom entry point
// works.
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 @foo() -> !llvm.float {
[mlir] switch the modeling of LLVM types to use the new mechanism A new first-party modeling for LLVM IR types in the LLVM dialect has been developed in parallel to the existing modeling based on wrapping LLVM `Type *` instances. It resolves the long-standing problem of modeling identified structure types, including recursive structures, and enables future removal of LLVMContext and related locking mechanisms from LLVMDialect. This commit only switches the modeling by (a) renaming LLVMTypeNew to LLVMType, (b) removing the old implementaiton of LLVMType, and (c) updating the tests. It is intentionally minimal. Separate commits will remove the infrastructure built for the transition and update API uses where appropriate. Depends On D85020 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D85021
2020-08-04 17:37:50 +08:00
%0 = llvm.call @allocation() : () -> !llvm.ptr<float>
Drop support for memrefs from JitRunner The support for functions taking and returning memrefs of floats was introduced in the first version of the runner, created before MLIR had reliable lowering of allocation/deallocation to library calls. It forcibly runs MLIR transformation convering affine, loop and standard dialects into the LLVM dialect, unlike the other runner flows that accept the LLVM dialect directly. Memref support leads to more complex layering and is generally fragile. Drop it in favor of functions returning a scalar, or library-based function calls to print memrefs and other data structures. PiperOrigin-RevId: 271330839
2019-09-26 20:41:26 +08:00
%1 = llvm.mlir.constant(0 : index) : !llvm.i64
%2 = llvm.mlir.constant(1.234000e+03 : f32) : !llvm.float
[mlir] switch the modeling of LLVM types to use the new mechanism A new first-party modeling for LLVM IR types in the LLVM dialect has been developed in parallel to the existing modeling based on wrapping LLVM `Type *` instances. It resolves the long-standing problem of modeling identified structure types, including recursive structures, and enables future removal of LLVMContext and related locking mechanisms from LLVMDialect. This commit only switches the modeling by (a) renaming LLVMTypeNew to LLVMType, (b) removing the old implementaiton of LLVMType, and (c) updating the tests. It is intentionally minimal. Separate commits will remove the infrastructure built for the transition and update API uses where appropriate. Depends On D85020 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D85021
2020-08-04 17:37:50 +08:00
%3 = llvm.getelementptr %0[%1] : (!llvm.ptr<float>, !llvm.i64) -> !llvm.ptr<float>
llvm.store %2, %3 : !llvm.ptr<float>
%4 = llvm.getelementptr %0[%1] : (!llvm.ptr<float>, !llvm.i64) -> !llvm.ptr<float>
%5 = llvm.load %4 : !llvm.ptr<float>
llvm.call @deallocation(%0) : (!llvm.ptr<float>) -> ()
Drop support for memrefs from JitRunner The support for functions taking and returning memrefs of floats was introduced in the first version of the runner, created before MLIR had reliable lowering of allocation/deallocation to library calls. It forcibly runs MLIR transformation convering affine, loop and standard dialects into the LLVM dialect, unlike the other runner flows that accept the LLVM dialect directly. Memref support leads to more complex layering and is generally fragile. Drop it in favor of functions returning a scalar, or library-based function calls to print memrefs and other data structures. PiperOrigin-RevId: 271330839
2019-09-26 20:41:26 +08:00
llvm.return %5 : !llvm.float
Add missing lowering to CFG in mlir-cpu-runner + related cleanup - the list of passes run by mlir-cpu-runner included -lower-affine and -lower-to-llvm but was missing -lower-to-cfg (because -lower-affine at some point used to lower straight to CFG); add -lower-to-cfg in between. IR with affine ops can now be run by mlir-cpu-runner. - update -lower-to-cfg to be consistent with other passes (create*Pass methods were changed to return unique ptrs, but -lower-to-cfg appears to have been missed). - mlir-cpu-runner was unable to parse custom form of affine op's - fix link options - drop unnecessary run options from test/mlir-cpu-runner/simple.mlir (none of the test cases had loops) - -convert-to-llvmir was changed to -lower-to-llvm at some point, but the create pass method name wasn't updated (this pass converts/lowers to LLVM dialect as opposed to LLVM IR). Fix this. (If we prefer "convert", the cmd-line options could be changed to "-convert-to-llvm/cfg" then.) Signed-off-by: Uday Bondhugula <uday@polymagelabs.com> Closes tensorflow/mlir#115 PiperOrigin-RevId: 266666909
2019-09-02 02:32:52 +08:00
}
Drop support for memrefs from JitRunner The support for functions taking and returning memrefs of floats was introduced in the first version of the runner, created before MLIR had reliable lowering of allocation/deallocation to library calls. It forcibly runs MLIR transformation convering affine, loop and standard dialects into the LLVM dialect, unlike the other runner flows that accept the LLVM dialect directly. Memref support leads to more complex layering and is generally fragile. Drop it in favor of functions returning a scalar, or library-based function calls to print memrefs and other data structures. PiperOrigin-RevId: 271330839
2019-09-26 20:41:26 +08:00
// NOMAIN: 1.234000e+03
[JitRunner] add support for i32 and i64 output Differential Revision: https://reviews.llvm.org/D80675
2019-11-23 08:04:44 +08:00
// Check that i32 return type works
llvm.func @int32_main() -> !llvm.i32 {
%0 = llvm.mlir.constant(42 : i32) : !llvm.i32
llvm.return %0 : !llvm.i32
}
// INT32MAIN: 42
// Check that i64 return type works
llvm.func @int64_main() -> !llvm.i64 {
%0 = llvm.mlir.constant(42 : i64) : !llvm.i64
llvm.return %0 : !llvm.i64
}
// INT64MAIN: 42