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/openmp-llvm.mlir

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

358 lines
13 KiB
MLIR
Raw Normal View History

[mlir] Add translation of omp.wsloop to LLVM IR Introduce a translation of OpenMP workshare loop construct to LLVM IR. This is a minimalist version to enable the pipeline and currently only supports static loop schedule (default in the specification) on non-collapsed loops. Other features will be added on per-need basis. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D92055
2020-12-08 23:45:19 +08:00
// RUN: mlir-translate -mlir-to-llvmir -split-input-file %s | FileCheck %s
[MLIR, OpenMP] Translation of OpenMP barrier construct to LLVM IR Summary: This patch adds support for translation of the OpenMP barrier construct to LLVM IR. The OpenMP IRBuilder is used for this translation. In this patch the code for translation is added to the existing LLVM dialect translation to LLVM IR. The patch includes code changes and a testcase. Reviewers: jdoerfert, nicolasvasilache, ftynse, rriddle, mehdi_amini Reviewed By: ftynse, rriddle, mehdi_amini Differential Revision: https://reviews.llvm.org/D72962
2020-03-05 07:36:21 +08:00
[MLIR, OpenMP] Support for flush operation, and translating the same to LLVM IR Summary: This patch adds support for flush operation in OpenMP dialect and translation of this construct to LLVM IR. The OpenMP IRBuilder is used for this translation. The patch includes code changes and testcase modifications. Reviewed By: ftynse, kiranchandramohan Differential Revision: https://reviews.llvm.org/D79937
2020-05-19 19:30:15 +08:00
// CHECK-LABEL: define void @test_stand_alone_directives()
llvm.func @test_stand_alone_directives() {
[MLIR] Support for taskwait and taskyield operations, and translating the same to LLVM IR This patch adds support for taskwait and taskyield operations in OpenMP dialect and translation of the these constructs to LLVM IR. The OpenMP IRBuilder is used for this translation. The patch includes code changes and a testcase modifications. Differential Revision: https://reviews.llvm.org/D77634
2020-04-10 15:41:04 +08:00
// CHECK: [[OMP_THREAD:%.*]] = call i32 @__kmpc_global_thread_num(%struct.ident_t* @{{[0-9]+}})
// CHECK-NEXT: call void @__kmpc_barrier(%struct.ident_t* @{{[0-9]+}}, i32 [[OMP_THREAD]])
[MLIR, OpenMP] Translation of OpenMP barrier construct to LLVM IR Summary: This patch adds support for translation of the OpenMP barrier construct to LLVM IR. The OpenMP IRBuilder is used for this translation. In this patch the code for translation is added to the existing LLVM dialect translation to LLVM IR. The patch includes code changes and a testcase. Reviewers: jdoerfert, nicolasvasilache, ftynse, rriddle, mehdi_amini Reviewed By: ftynse, rriddle, mehdi_amini Differential Revision: https://reviews.llvm.org/D72962
2020-03-05 07:36:21 +08:00
omp.barrier
[MLIR] Support for taskwait and taskyield operations, and translating the same to LLVM IR This patch adds support for taskwait and taskyield operations in OpenMP dialect and translation of the these constructs to LLVM IR. The OpenMP IRBuilder is used for this translation. The patch includes code changes and a testcase modifications. Differential Revision: https://reviews.llvm.org/D77634
2020-04-10 15:41:04 +08:00
// CHECK: [[OMP_THREAD1:%.*]] = call i32 @__kmpc_global_thread_num(%struct.ident_t* @{{[0-9]+}})
// CHECK-NEXT: [[RET_VAL:%.*]] = call i32 @__kmpc_omp_taskwait(%struct.ident_t* @{{[0-9]+}}, i32 [[OMP_THREAD1]])
omp.taskwait
// CHECK: [[OMP_THREAD2:%.*]] = call i32 @__kmpc_global_thread_num(%struct.ident_t* @{{[0-9]+}})
// CHECK-NEXT: [[RET_VAL:%.*]] = call i32 @__kmpc_omp_taskyield(%struct.ident_t* @{{[0-9]+}}, i32 [[OMP_THREAD2]], i32 0)
omp.taskyield
[MLIR, OpenMP] Support for flush operation, and translating the same to LLVM IR Summary: This patch adds support for flush operation in OpenMP dialect and translation of this construct to LLVM IR. The OpenMP IRBuilder is used for this translation. The patch includes code changes and testcase modifications. Reviewed By: ftynse, kiranchandramohan Differential Revision: https://reviews.llvm.org/D79937
2020-05-19 19:30:15 +08:00
// CHECK-NEXT: ret void
llvm.return
}
// CHECK-LABEL: define void @test_flush_construct(i32 %0)
[mlir] replace LLVMIntegerType with built-in integer type The LLVM dialect type system has been closed until now, i.e. did not support types from other dialects inside containers. While this has had obvious benefits of deriving from a common base class, it has led to some simple types being almost identical with the built-in types, namely integer and floating point types. This in turn has led to a lot of larger-scale complexity: simple types must still be converted, numerous operations that correspond to LLVM IR intrinsics are replicated to produce versions operating on either LLVM dialect or built-in types leading to quasi-duplicate dialects, lowering to the LLVM dialect is essentially required to be one-shot because of type conversion, etc. In this light, it is reasonable to trade off some local complexity in the internal implementation of LLVM dialect types for removing larger-scale system complexity. Previous commits to the LLVM dialect type system have adapted the API to support types from other dialects. Replace LLVMIntegerType with the built-in IntegerType plus additional checks that such types are signless (these are isolated in a utility function that replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice. Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94178
2021-01-06 23:19:04 +08:00
llvm.func @test_flush_construct(%arg0: i32) {
[MLIR, OpenMP] Support for flush operation, and translating the same to LLVM IR Summary: This patch adds support for flush operation in OpenMP dialect and translation of this construct to LLVM IR. The OpenMP IRBuilder is used for this translation. The patch includes code changes and testcase modifications. Reviewed By: ftynse, kiranchandramohan Differential Revision: https://reviews.llvm.org/D79937
2020-05-19 19:30:15 +08:00
// CHECK: call void @__kmpc_flush(%struct.ident_t* @{{[0-9]+}}
omp.flush
// CHECK: call void @__kmpc_flush(%struct.ident_t* @{{[0-9]+}}
[mlir] replace LLVMIntegerType with built-in integer type The LLVM dialect type system has been closed until now, i.e. did not support types from other dialects inside containers. While this has had obvious benefits of deriving from a common base class, it has led to some simple types being almost identical with the built-in types, namely integer and floating point types. This in turn has led to a lot of larger-scale complexity: simple types must still be converted, numerous operations that correspond to LLVM IR intrinsics are replicated to produce versions operating on either LLVM dialect or built-in types leading to quasi-duplicate dialects, lowering to the LLVM dialect is essentially required to be one-shot because of type conversion, etc. In this light, it is reasonable to trade off some local complexity in the internal implementation of LLVM dialect types for removing larger-scale system complexity. Previous commits to the LLVM dialect type system have adapted the API to support types from other dialects. Replace LLVMIntegerType with the built-in IntegerType plus additional checks that such types are signless (these are isolated in a utility function that replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice. Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94178
2021-01-06 23:19:04 +08:00
omp.flush (%arg0 : i32)
[MLIR, OpenMP] Support for flush operation, and translating the same to LLVM IR Summary: This patch adds support for flush operation in OpenMP dialect and translation of this construct to LLVM IR. The OpenMP IRBuilder is used for this translation. The patch includes code changes and testcase modifications. Reviewed By: ftynse, kiranchandramohan Differential Revision: https://reviews.llvm.org/D79937
2020-05-19 19:30:15 +08:00
// CHECK: call void @__kmpc_flush(%struct.ident_t* @{{[0-9]+}}
[mlir] replace LLVMIntegerType with built-in integer type The LLVM dialect type system has been closed until now, i.e. did not support types from other dialects inside containers. While this has had obvious benefits of deriving from a common base class, it has led to some simple types being almost identical with the built-in types, namely integer and floating point types. This in turn has led to a lot of larger-scale complexity: simple types must still be converted, numerous operations that correspond to LLVM IR intrinsics are replicated to produce versions operating on either LLVM dialect or built-in types leading to quasi-duplicate dialects, lowering to the LLVM dialect is essentially required to be one-shot because of type conversion, etc. In this light, it is reasonable to trade off some local complexity in the internal implementation of LLVM dialect types for removing larger-scale system complexity. Previous commits to the LLVM dialect type system have adapted the API to support types from other dialects. Replace LLVMIntegerType with the built-in IntegerType plus additional checks that such types are signless (these are isolated in a utility function that replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice. Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94178
2021-01-06 23:19:04 +08:00
omp.flush (%arg0, %arg0 : i32, i32)
[MLIR][OpenMP] Removed the ambiguity in flush op assembly syntax Summary: ======== Bugzilla Ticket No: Bug 46884 [https://bugs.llvm.org/show_bug.cgi?id=46884] Flush op assembly syntax was ambiguous: Consider the below test case: flush operation is not having any arguments. But the next statement token i.e "%2" is read as the argument for flush operation and then translator issues an error. *************************************************************** $ cat -n flush.mlir 1 llvm.func @_QQmain(%arg0: !llvm.i32) { 2 %0 = llvm.mlir.constant(1 : i64) : !llvm.i64 3 %1 = llvm.alloca %0 x !llvm.i32 {in_type = i32, name = "a"} : (!llvm.i64) -> !llvm.ptr<i32> 4 omp.flush 5 %2 = llvm.load %1 : !llvm.ptr<i32> 6 llvm.return 7 } $ mlir-translate -mlir-to-llvmir flush.mlir flush.mlir:5:6: error: expected ':' %2 = llvm.load %1 : !llvm.ptr<i32> ^ *************************************************************** Solution: ========= Introduced begin ( `(` ) and end token ( `)` ) to determince the begin and end of variadic arguments. The patch includes code changes and testcase modifications. Reviewed By: Valentin Clement, Mehdi AMINI Differential Revision: https://reviews.llvm.org/D88376
2020-09-29 12:11:46 +08:00
[mlir] replace LLVMIntegerType with built-in integer type The LLVM dialect type system has been closed until now, i.e. did not support types from other dialects inside containers. While this has had obvious benefits of deriving from a common base class, it has led to some simple types being almost identical with the built-in types, namely integer and floating point types. This in turn has led to a lot of larger-scale complexity: simple types must still be converted, numerous operations that correspond to LLVM IR intrinsics are replicated to produce versions operating on either LLVM dialect or built-in types leading to quasi-duplicate dialects, lowering to the LLVM dialect is essentially required to be one-shot because of type conversion, etc. In this light, it is reasonable to trade off some local complexity in the internal implementation of LLVM dialect types for removing larger-scale system complexity. Previous commits to the LLVM dialect type system have adapted the API to support types from other dialects. Replace LLVMIntegerType with the built-in IntegerType plus additional checks that such types are signless (these are isolated in a utility function that replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice. Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94178
2021-01-06 23:19:04 +08:00
%0 = llvm.mlir.constant(1 : i64) : i64
[MLIR][OpenMP] Removed the ambiguity in flush op assembly syntax Summary: ======== Bugzilla Ticket No: Bug 46884 [https://bugs.llvm.org/show_bug.cgi?id=46884] Flush op assembly syntax was ambiguous: Consider the below test case: flush operation is not having any arguments. But the next statement token i.e "%2" is read as the argument for flush operation and then translator issues an error. *************************************************************** $ cat -n flush.mlir 1 llvm.func @_QQmain(%arg0: !llvm.i32) { 2 %0 = llvm.mlir.constant(1 : i64) : !llvm.i64 3 %1 = llvm.alloca %0 x !llvm.i32 {in_type = i32, name = "a"} : (!llvm.i64) -> !llvm.ptr<i32> 4 omp.flush 5 %2 = llvm.load %1 : !llvm.ptr<i32> 6 llvm.return 7 } $ mlir-translate -mlir-to-llvmir flush.mlir flush.mlir:5:6: error: expected ':' %2 = llvm.load %1 : !llvm.ptr<i32> ^ *************************************************************** Solution: ========= Introduced begin ( `(` ) and end token ( `)` ) to determince the begin and end of variadic arguments. The patch includes code changes and testcase modifications. Reviewed By: Valentin Clement, Mehdi AMINI Differential Revision: https://reviews.llvm.org/D88376
2020-09-29 12:11:46 +08:00
// CHECK: alloca {{.*}} align 4
[mlir] replace LLVMIntegerType with built-in integer type The LLVM dialect type system has been closed until now, i.e. did not support types from other dialects inside containers. While this has had obvious benefits of deriving from a common base class, it has led to some simple types being almost identical with the built-in types, namely integer and floating point types. This in turn has led to a lot of larger-scale complexity: simple types must still be converted, numerous operations that correspond to LLVM IR intrinsics are replicated to produce versions operating on either LLVM dialect or built-in types leading to quasi-duplicate dialects, lowering to the LLVM dialect is essentially required to be one-shot because of type conversion, etc. In this light, it is reasonable to trade off some local complexity in the internal implementation of LLVM dialect types for removing larger-scale system complexity. Previous commits to the LLVM dialect type system have adapted the API to support types from other dialects. Replace LLVMIntegerType with the built-in IntegerType plus additional checks that such types are signless (these are isolated in a utility function that replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice. Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94178
2021-01-06 23:19:04 +08:00
%1 = llvm.alloca %0 x i32 {in_type = i32, name = "a"} : (i64) -> !llvm.ptr<i32>
[MLIR][OpenMP] Removed the ambiguity in flush op assembly syntax Summary: ======== Bugzilla Ticket No: Bug 46884 [https://bugs.llvm.org/show_bug.cgi?id=46884] Flush op assembly syntax was ambiguous: Consider the below test case: flush operation is not having any arguments. But the next statement token i.e "%2" is read as the argument for flush operation and then translator issues an error. *************************************************************** $ cat -n flush.mlir 1 llvm.func @_QQmain(%arg0: !llvm.i32) { 2 %0 = llvm.mlir.constant(1 : i64) : !llvm.i64 3 %1 = llvm.alloca %0 x !llvm.i32 {in_type = i32, name = "a"} : (!llvm.i64) -> !llvm.ptr<i32> 4 omp.flush 5 %2 = llvm.load %1 : !llvm.ptr<i32> 6 llvm.return 7 } $ mlir-translate -mlir-to-llvmir flush.mlir flush.mlir:5:6: error: expected ':' %2 = llvm.load %1 : !llvm.ptr<i32> ^ *************************************************************** Solution: ========= Introduced begin ( `(` ) and end token ( `)` ) to determince the begin and end of variadic arguments. The patch includes code changes and testcase modifications. Reviewed By: Valentin Clement, Mehdi AMINI Differential Revision: https://reviews.llvm.org/D88376
2020-09-29 12:11:46 +08:00
// CHECK: call void @__kmpc_flush(%struct.ident_t* @{{[0-9]+}}
omp.flush
// CHECK: load i32, i32*
%2 = llvm.load %1 : !llvm.ptr<i32>
[MLIR, OpenMP] Support for flush operation, and translating the same to LLVM IR Summary: This patch adds support for flush operation in OpenMP dialect and translation of this construct to LLVM IR. The OpenMP IRBuilder is used for this translation. The patch includes code changes and testcase modifications. Reviewed By: ftynse, kiranchandramohan Differential Revision: https://reviews.llvm.org/D79937
2020-05-19 19:30:15 +08:00
// CHECK-NEXT: ret void
[MLIR, OpenMP] Translation of OpenMP barrier construct to LLVM IR Summary: This patch adds support for translation of the OpenMP barrier construct to LLVM IR. The OpenMP IRBuilder is used for this translation. In this patch the code for translation is added to the existing LLVM dialect translation to LLVM IR. The patch includes code changes and a testcase. Reviewers: jdoerfert, nicolasvasilache, ftynse, rriddle, mehdi_amini Reviewed By: ftynse, rriddle, mehdi_amini Differential Revision: https://reviews.llvm.org/D72962
2020-03-05 07:36:21 +08:00
llvm.return
}
Lowering of OpenMP Parallel operation to LLVM IR 1/n This patch introduces lowering of the OpenMP parallel operation to LLVM IR using the OpenMPIRBuilder. Functions topologicalSort and connectPhiNodes are generalised so that they work with operations also. connectPhiNodes is also made static. Lowering works for a parallel region with multiple blocks. Clauses and arguments of the OpenMP operation are not handled. Reviewed By: rriddle, anchu-rajendran Differential Revision: https://reviews.llvm.org/D81660
2020-07-14 06:13:04 +08:00
// CHECK-LABEL: define void @test_omp_parallel_1()
llvm.func @test_omp_parallel_1() -> () {
// CHECK: call void{{.*}}@__kmpc_fork_call{{.*}}@[[OMP_OUTLINED_FN_1:.*]] to {{.*}}
omp.parallel {
omp.barrier
omp.terminator
}
llvm.return
}
// CHECK: define internal void @[[OMP_OUTLINED_FN_1]]
// CHECK: call void @__kmpc_barrier
[mlir] replace LLVMIntegerType with built-in integer type The LLVM dialect type system has been closed until now, i.e. did not support types from other dialects inside containers. While this has had obvious benefits of deriving from a common base class, it has led to some simple types being almost identical with the built-in types, namely integer and floating point types. This in turn has led to a lot of larger-scale complexity: simple types must still be converted, numerous operations that correspond to LLVM IR intrinsics are replicated to produce versions operating on either LLVM dialect or built-in types leading to quasi-duplicate dialects, lowering to the LLVM dialect is essentially required to be one-shot because of type conversion, etc. In this light, it is reasonable to trade off some local complexity in the internal implementation of LLVM dialect types for removing larger-scale system complexity. Previous commits to the LLVM dialect type system have adapted the API to support types from other dialects. Replace LLVMIntegerType with the built-in IntegerType plus additional checks that such types are signless (these are isolated in a utility function that replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice. Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94178
2021-01-06 23:19:04 +08:00
llvm.func @body(i64)
Lowering of OpenMP Parallel operation to LLVM IR 1/n This patch introduces lowering of the OpenMP parallel operation to LLVM IR using the OpenMPIRBuilder. Functions topologicalSort and connectPhiNodes are generalised so that they work with operations also. connectPhiNodes is also made static. Lowering works for a parallel region with multiple blocks. Clauses and arguments of the OpenMP operation are not handled. Reviewed By: rriddle, anchu-rajendran Differential Revision: https://reviews.llvm.org/D81660
2020-07-14 06:13:04 +08:00
// CHECK-LABEL: define void @test_omp_parallel_2()
llvm.func @test_omp_parallel_2() -> () {
// CHECK: call void{{.*}}@__kmpc_fork_call{{.*}}@[[OMP_OUTLINED_FN_2:.*]] to {{.*}}
omp.parallel {
^bb0:
[mlir] replace LLVMIntegerType with built-in integer type The LLVM dialect type system has been closed until now, i.e. did not support types from other dialects inside containers. While this has had obvious benefits of deriving from a common base class, it has led to some simple types being almost identical with the built-in types, namely integer and floating point types. This in turn has led to a lot of larger-scale complexity: simple types must still be converted, numerous operations that correspond to LLVM IR intrinsics are replicated to produce versions operating on either LLVM dialect or built-in types leading to quasi-duplicate dialects, lowering to the LLVM dialect is essentially required to be one-shot because of type conversion, etc. In this light, it is reasonable to trade off some local complexity in the internal implementation of LLVM dialect types for removing larger-scale system complexity. Previous commits to the LLVM dialect type system have adapted the API to support types from other dialects. Replace LLVMIntegerType with the built-in IntegerType plus additional checks that such types are signless (these are isolated in a utility function that replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice. Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94178
2021-01-06 23:19:04 +08:00
%0 = llvm.mlir.constant(1 : index) : i64
%1 = llvm.mlir.constant(42 : index) : i64
llvm.call @body(%0) : (i64) -> ()
llvm.call @body(%1) : (i64) -> ()
Lowering of OpenMP Parallel operation to LLVM IR 1/n This patch introduces lowering of the OpenMP parallel operation to LLVM IR using the OpenMPIRBuilder. Functions topologicalSort and connectPhiNodes are generalised so that they work with operations also. connectPhiNodes is also made static. Lowering works for a parallel region with multiple blocks. Clauses and arguments of the OpenMP operation are not handled. Reviewed By: rriddle, anchu-rajendran Differential Revision: https://reviews.llvm.org/D81660
2020-07-14 06:13:04 +08:00
llvm.br ^bb1
^bb1:
[mlir] replace LLVMIntegerType with built-in integer type The LLVM dialect type system has been closed until now, i.e. did not support types from other dialects inside containers. While this has had obvious benefits of deriving from a common base class, it has led to some simple types being almost identical with the built-in types, namely integer and floating point types. This in turn has led to a lot of larger-scale complexity: simple types must still be converted, numerous operations that correspond to LLVM IR intrinsics are replicated to produce versions operating on either LLVM dialect or built-in types leading to quasi-duplicate dialects, lowering to the LLVM dialect is essentially required to be one-shot because of type conversion, etc. In this light, it is reasonable to trade off some local complexity in the internal implementation of LLVM dialect types for removing larger-scale system complexity. Previous commits to the LLVM dialect type system have adapted the API to support types from other dialects. Replace LLVMIntegerType with the built-in IntegerType plus additional checks that such types are signless (these are isolated in a utility function that replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice. Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94178
2021-01-06 23:19:04 +08:00
%2 = llvm.add %0, %1 : i64
llvm.call @body(%2) : (i64) -> ()
Lowering of OpenMP Parallel operation to LLVM IR 1/n This patch introduces lowering of the OpenMP parallel operation to LLVM IR using the OpenMPIRBuilder. Functions topologicalSort and connectPhiNodes are generalised so that they work with operations also. connectPhiNodes is also made static. Lowering works for a parallel region with multiple blocks. Clauses and arguments of the OpenMP operation are not handled. Reviewed By: rriddle, anchu-rajendran Differential Revision: https://reviews.llvm.org/D81660
2020-07-14 06:13:04 +08:00
omp.terminator
}
llvm.return
}
// CHECK: define internal void @[[OMP_OUTLINED_FN_2]]
// CHECK-LABEL: omp.par.region:
// CHECK: br label %omp.par.region1
// CHECK-LABEL: omp.par.region1:
// CHECK: call void @body(i64 1)
// CHECK: call void @body(i64 42)
// CHECK: br label %omp.par.region2
// CHECK-LABEL: omp.par.region2:
// CHECK: call void @body(i64 43)
// CHECK: br label %omp.par.pre_finalize
[OpenMP,MLIR] Translation of parallel operation: num_threads, if clauses 3/n This simple patch translates the num_threads and if clauses of the parallel operation. Also includes test cases. A minor change was made to parsing of the if clause to parse AnyType and return the parsed type. Updates to test cases also. Reviewed by: SouraVX Differential Revision: https://reviews.llvm.org/D84798
2020-08-08 02:33:46 +08:00
// CHECK: define void @test_omp_parallel_num_threads_1(i32 %[[NUM_THREADS_VAR_1:.*]])
[mlir] replace LLVMIntegerType with built-in integer type The LLVM dialect type system has been closed until now, i.e. did not support types from other dialects inside containers. While this has had obvious benefits of deriving from a common base class, it has led to some simple types being almost identical with the built-in types, namely integer and floating point types. This in turn has led to a lot of larger-scale complexity: simple types must still be converted, numerous operations that correspond to LLVM IR intrinsics are replicated to produce versions operating on either LLVM dialect or built-in types leading to quasi-duplicate dialects, lowering to the LLVM dialect is essentially required to be one-shot because of type conversion, etc. In this light, it is reasonable to trade off some local complexity in the internal implementation of LLVM dialect types for removing larger-scale system complexity. Previous commits to the LLVM dialect type system have adapted the API to support types from other dialects. Replace LLVMIntegerType with the built-in IntegerType plus additional checks that such types are signless (these are isolated in a utility function that replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice. Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94178
2021-01-06 23:19:04 +08:00
llvm.func @test_omp_parallel_num_threads_1(%arg0: i32) -> () {
[OpenMP,MLIR] Translation of parallel operation: num_threads, if clauses 3/n This simple patch translates the num_threads and if clauses of the parallel operation. Also includes test cases. A minor change was made to parsing of the if clause to parse AnyType and return the parsed type. Updates to test cases also. Reviewed by: SouraVX Differential Revision: https://reviews.llvm.org/D84798
2020-08-08 02:33:46 +08:00
// CHECK: %[[GTN_NUM_THREADS_VAR_1:.*]] = call i32 @__kmpc_global_thread_num(%struct.ident_t* @[[GTN_SI_VAR_1:.*]])
// CHECK: call void @__kmpc_push_num_threads(%struct.ident_t* @[[GTN_SI_VAR_1]], i32 %[[GTN_NUM_THREADS_VAR_1]], i32 %[[NUM_THREADS_VAR_1]])
// CHECK: call void{{.*}}@__kmpc_fork_call{{.*}}@[[OMP_OUTLINED_FN_NUM_THREADS_1:.*]] to {{.*}}
[mlir] replace LLVMIntegerType with built-in integer type The LLVM dialect type system has been closed until now, i.e. did not support types from other dialects inside containers. While this has had obvious benefits of deriving from a common base class, it has led to some simple types being almost identical with the built-in types, namely integer and floating point types. This in turn has led to a lot of larger-scale complexity: simple types must still be converted, numerous operations that correspond to LLVM IR intrinsics are replicated to produce versions operating on either LLVM dialect or built-in types leading to quasi-duplicate dialects, lowering to the LLVM dialect is essentially required to be one-shot because of type conversion, etc. In this light, it is reasonable to trade off some local complexity in the internal implementation of LLVM dialect types for removing larger-scale system complexity. Previous commits to the LLVM dialect type system have adapted the API to support types from other dialects. Replace LLVMIntegerType with the built-in IntegerType plus additional checks that such types are signless (these are isolated in a utility function that replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice. Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94178
2021-01-06 23:19:04 +08:00
omp.parallel num_threads(%arg0: i32) {
[OpenMP,MLIR] Translation of parallel operation: num_threads, if clauses 3/n This simple patch translates the num_threads and if clauses of the parallel operation. Also includes test cases. A minor change was made to parsing of the if clause to parse AnyType and return the parsed type. Updates to test cases also. Reviewed by: SouraVX Differential Revision: https://reviews.llvm.org/D84798
2020-08-08 02:33:46 +08:00
omp.barrier
omp.terminator
}
llvm.return
}
// CHECK: define internal void @[[OMP_OUTLINED_FN_NUM_THREADS_1]]
// CHECK: call void @__kmpc_barrier
// CHECK: define void @test_omp_parallel_num_threads_2()
llvm.func @test_omp_parallel_num_threads_2() -> () {
[mlir] replace LLVMIntegerType with built-in integer type The LLVM dialect type system has been closed until now, i.e. did not support types from other dialects inside containers. While this has had obvious benefits of deriving from a common base class, it has led to some simple types being almost identical with the built-in types, namely integer and floating point types. This in turn has led to a lot of larger-scale complexity: simple types must still be converted, numerous operations that correspond to LLVM IR intrinsics are replicated to produce versions operating on either LLVM dialect or built-in types leading to quasi-duplicate dialects, lowering to the LLVM dialect is essentially required to be one-shot because of type conversion, etc. In this light, it is reasonable to trade off some local complexity in the internal implementation of LLVM dialect types for removing larger-scale system complexity. Previous commits to the LLVM dialect type system have adapted the API to support types from other dialects. Replace LLVMIntegerType with the built-in IntegerType plus additional checks that such types are signless (these are isolated in a utility function that replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice. Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94178
2021-01-06 23:19:04 +08:00
%0 = llvm.mlir.constant(4 : index) : i32
[OpenMP,MLIR] Translation of parallel operation: num_threads, if clauses 3/n This simple patch translates the num_threads and if clauses of the parallel operation. Also includes test cases. A minor change was made to parsing of the if clause to parse AnyType and return the parsed type. Updates to test cases also. Reviewed by: SouraVX Differential Revision: https://reviews.llvm.org/D84798
2020-08-08 02:33:46 +08:00
// CHECK: %[[GTN_NUM_THREADS_VAR_2:.*]] = call i32 @__kmpc_global_thread_num(%struct.ident_t* @[[GTN_SI_VAR_2:.*]])
// CHECK: call void @__kmpc_push_num_threads(%struct.ident_t* @[[GTN_SI_VAR_2]], i32 %[[GTN_NUM_THREADS_VAR_2]], i32 4)
// CHECK: call void{{.*}}@__kmpc_fork_call{{.*}}@[[OMP_OUTLINED_FN_NUM_THREADS_2:.*]] to {{.*}}
[mlir] replace LLVMIntegerType with built-in integer type The LLVM dialect type system has been closed until now, i.e. did not support types from other dialects inside containers. While this has had obvious benefits of deriving from a common base class, it has led to some simple types being almost identical with the built-in types, namely integer and floating point types. This in turn has led to a lot of larger-scale complexity: simple types must still be converted, numerous operations that correspond to LLVM IR intrinsics are replicated to produce versions operating on either LLVM dialect or built-in types leading to quasi-duplicate dialects, lowering to the LLVM dialect is essentially required to be one-shot because of type conversion, etc. In this light, it is reasonable to trade off some local complexity in the internal implementation of LLVM dialect types for removing larger-scale system complexity. Previous commits to the LLVM dialect type system have adapted the API to support types from other dialects. Replace LLVMIntegerType with the built-in IntegerType plus additional checks that such types are signless (these are isolated in a utility function that replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice. Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94178
2021-01-06 23:19:04 +08:00
omp.parallel num_threads(%0: i32) {
[OpenMP,MLIR] Translation of parallel operation: num_threads, if clauses 3/n This simple patch translates the num_threads and if clauses of the parallel operation. Also includes test cases. A minor change was made to parsing of the if clause to parse AnyType and return the parsed type. Updates to test cases also. Reviewed by: SouraVX Differential Revision: https://reviews.llvm.org/D84798
2020-08-08 02:33:46 +08:00
omp.barrier
omp.terminator
}
llvm.return
}
// CHECK: define internal void @[[OMP_OUTLINED_FN_NUM_THREADS_2]]
// CHECK: call void @__kmpc_barrier
// CHECK: define void @test_omp_parallel_num_threads_3()
llvm.func @test_omp_parallel_num_threads_3() -> () {
[mlir] replace LLVMIntegerType with built-in integer type The LLVM dialect type system has been closed until now, i.e. did not support types from other dialects inside containers. While this has had obvious benefits of deriving from a common base class, it has led to some simple types being almost identical with the built-in types, namely integer and floating point types. This in turn has led to a lot of larger-scale complexity: simple types must still be converted, numerous operations that correspond to LLVM IR intrinsics are replicated to produce versions operating on either LLVM dialect or built-in types leading to quasi-duplicate dialects, lowering to the LLVM dialect is essentially required to be one-shot because of type conversion, etc. In this light, it is reasonable to trade off some local complexity in the internal implementation of LLVM dialect types for removing larger-scale system complexity. Previous commits to the LLVM dialect type system have adapted the API to support types from other dialects. Replace LLVMIntegerType with the built-in IntegerType plus additional checks that such types are signless (these are isolated in a utility function that replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice. Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94178
2021-01-06 23:19:04 +08:00
%0 = llvm.mlir.constant(4 : index) : i32
[OpenMP,MLIR] Translation of parallel operation: num_threads, if clauses 3/n This simple patch translates the num_threads and if clauses of the parallel operation. Also includes test cases. A minor change was made to parsing of the if clause to parse AnyType and return the parsed type. Updates to test cases also. Reviewed by: SouraVX Differential Revision: https://reviews.llvm.org/D84798
2020-08-08 02:33:46 +08:00
// CHECK: %[[GTN_NUM_THREADS_VAR_3_1:.*]] = call i32 @__kmpc_global_thread_num(%struct.ident_t* @[[GTN_SI_VAR_3_1:.*]])
// CHECK: call void @__kmpc_push_num_threads(%struct.ident_t* @[[GTN_SI_VAR_3_1]], i32 %[[GTN_NUM_THREADS_VAR_3_1]], i32 4)
// CHECK: call void{{.*}}@__kmpc_fork_call{{.*}}@[[OMP_OUTLINED_FN_NUM_THREADS_3_1:.*]] to {{.*}}
[mlir] replace LLVMIntegerType with built-in integer type The LLVM dialect type system has been closed until now, i.e. did not support types from other dialects inside containers. While this has had obvious benefits of deriving from a common base class, it has led to some simple types being almost identical with the built-in types, namely integer and floating point types. This in turn has led to a lot of larger-scale complexity: simple types must still be converted, numerous operations that correspond to LLVM IR intrinsics are replicated to produce versions operating on either LLVM dialect or built-in types leading to quasi-duplicate dialects, lowering to the LLVM dialect is essentially required to be one-shot because of type conversion, etc. In this light, it is reasonable to trade off some local complexity in the internal implementation of LLVM dialect types for removing larger-scale system complexity. Previous commits to the LLVM dialect type system have adapted the API to support types from other dialects. Replace LLVMIntegerType with the built-in IntegerType plus additional checks that such types are signless (these are isolated in a utility function that replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice. Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94178
2021-01-06 23:19:04 +08:00
omp.parallel num_threads(%0: i32) {
[OpenMP,MLIR] Translation of parallel operation: num_threads, if clauses 3/n This simple patch translates the num_threads and if clauses of the parallel operation. Also includes test cases. A minor change was made to parsing of the if clause to parse AnyType and return the parsed type. Updates to test cases also. Reviewed by: SouraVX Differential Revision: https://reviews.llvm.org/D84798
2020-08-08 02:33:46 +08:00
omp.barrier
omp.terminator
}
[mlir] replace LLVMIntegerType with built-in integer type The LLVM dialect type system has been closed until now, i.e. did not support types from other dialects inside containers. While this has had obvious benefits of deriving from a common base class, it has led to some simple types being almost identical with the built-in types, namely integer and floating point types. This in turn has led to a lot of larger-scale complexity: simple types must still be converted, numerous operations that correspond to LLVM IR intrinsics are replicated to produce versions operating on either LLVM dialect or built-in types leading to quasi-duplicate dialects, lowering to the LLVM dialect is essentially required to be one-shot because of type conversion, etc. In this light, it is reasonable to trade off some local complexity in the internal implementation of LLVM dialect types for removing larger-scale system complexity. Previous commits to the LLVM dialect type system have adapted the API to support types from other dialects. Replace LLVMIntegerType with the built-in IntegerType plus additional checks that such types are signless (these are isolated in a utility function that replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice. Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94178
2021-01-06 23:19:04 +08:00
%1 = llvm.mlir.constant(8 : index) : i32
[OpenMP,MLIR] Translation of parallel operation: num_threads, if clauses 3/n This simple patch translates the num_threads and if clauses of the parallel operation. Also includes test cases. A minor change was made to parsing of the if clause to parse AnyType and return the parsed type. Updates to test cases also. Reviewed by: SouraVX Differential Revision: https://reviews.llvm.org/D84798
2020-08-08 02:33:46 +08:00
// CHECK: %[[GTN_NUM_THREADS_VAR_3_2:.*]] = call i32 @__kmpc_global_thread_num(%struct.ident_t* @[[GTN_SI_VAR_3_2:.*]])
// CHECK: call void @__kmpc_push_num_threads(%struct.ident_t* @[[GTN_SI_VAR_3_2]], i32 %[[GTN_NUM_THREADS_VAR_3_2]], i32 8)
// CHECK: call void{{.*}}@__kmpc_fork_call{{.*}}@[[OMP_OUTLINED_FN_NUM_THREADS_3_2:.*]] to {{.*}}
[mlir] replace LLVMIntegerType with built-in integer type The LLVM dialect type system has been closed until now, i.e. did not support types from other dialects inside containers. While this has had obvious benefits of deriving from a common base class, it has led to some simple types being almost identical with the built-in types, namely integer and floating point types. This in turn has led to a lot of larger-scale complexity: simple types must still be converted, numerous operations that correspond to LLVM IR intrinsics are replicated to produce versions operating on either LLVM dialect or built-in types leading to quasi-duplicate dialects, lowering to the LLVM dialect is essentially required to be one-shot because of type conversion, etc. In this light, it is reasonable to trade off some local complexity in the internal implementation of LLVM dialect types for removing larger-scale system complexity. Previous commits to the LLVM dialect type system have adapted the API to support types from other dialects. Replace LLVMIntegerType with the built-in IntegerType plus additional checks that such types are signless (these are isolated in a utility function that replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice. Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94178
2021-01-06 23:19:04 +08:00
omp.parallel num_threads(%1: i32) {
[OpenMP,MLIR] Translation of parallel operation: num_threads, if clauses 3/n This simple patch translates the num_threads and if clauses of the parallel operation. Also includes test cases. A minor change was made to parsing of the if clause to parse AnyType and return the parsed type. Updates to test cases also. Reviewed by: SouraVX Differential Revision: https://reviews.llvm.org/D84798
2020-08-08 02:33:46 +08:00
omp.barrier
omp.terminator
}
llvm.return
}
// CHECK: define internal void @[[OMP_OUTLINED_FN_NUM_THREADS_3_2]]
// CHECK: call void @__kmpc_barrier
// CHECK: define internal void @[[OMP_OUTLINED_FN_NUM_THREADS_3_1]]
// CHECK: call void @__kmpc_barrier
// CHECK: define void @test_omp_parallel_if_1(i32 %[[IF_VAR_1:.*]])
[mlir] replace LLVMIntegerType with built-in integer type The LLVM dialect type system has been closed until now, i.e. did not support types from other dialects inside containers. While this has had obvious benefits of deriving from a common base class, it has led to some simple types being almost identical with the built-in types, namely integer and floating point types. This in turn has led to a lot of larger-scale complexity: simple types must still be converted, numerous operations that correspond to LLVM IR intrinsics are replicated to produce versions operating on either LLVM dialect or built-in types leading to quasi-duplicate dialects, lowering to the LLVM dialect is essentially required to be one-shot because of type conversion, etc. In this light, it is reasonable to trade off some local complexity in the internal implementation of LLVM dialect types for removing larger-scale system complexity. Previous commits to the LLVM dialect type system have adapted the API to support types from other dialects. Replace LLVMIntegerType with the built-in IntegerType plus additional checks that such types are signless (these are isolated in a utility function that replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice. Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94178
2021-01-06 23:19:04 +08:00
llvm.func @test_omp_parallel_if_1(%arg0: i32) -> () {
[OpenMP,MLIR] Translation of parallel operation: num_threads, if clauses 3/n This simple patch translates the num_threads and if clauses of the parallel operation. Also includes test cases. A minor change was made to parsing of the if clause to parse AnyType and return the parsed type. Updates to test cases also. Reviewed by: SouraVX Differential Revision: https://reviews.llvm.org/D84798
2020-08-08 02:33:46 +08:00
// CHECK: %[[IF_COND_VAR_1:.*]] = icmp slt i32 %[[IF_VAR_1]], 0
[mlir] replace LLVMIntegerType with built-in integer type The LLVM dialect type system has been closed until now, i.e. did not support types from other dialects inside containers. While this has had obvious benefits of deriving from a common base class, it has led to some simple types being almost identical with the built-in types, namely integer and floating point types. This in turn has led to a lot of larger-scale complexity: simple types must still be converted, numerous operations that correspond to LLVM IR intrinsics are replicated to produce versions operating on either LLVM dialect or built-in types leading to quasi-duplicate dialects, lowering to the LLVM dialect is essentially required to be one-shot because of type conversion, etc. In this light, it is reasonable to trade off some local complexity in the internal implementation of LLVM dialect types for removing larger-scale system complexity. Previous commits to the LLVM dialect type system have adapted the API to support types from other dialects. Replace LLVMIntegerType with the built-in IntegerType plus additional checks that such types are signless (these are isolated in a utility function that replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice. Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94178
2021-01-06 23:19:04 +08:00
%0 = llvm.mlir.constant(0 : index) : i32
%1 = llvm.icmp "slt" %arg0, %0 : i32
[OpenMP,MLIR] Translation of parallel operation: num_threads, if clauses 3/n This simple patch translates the num_threads and if clauses of the parallel operation. Also includes test cases. A minor change was made to parsing of the if clause to parse AnyType and return the parsed type. Updates to test cases also. Reviewed by: SouraVX Differential Revision: https://reviews.llvm.org/D84798
2020-08-08 02:33:46 +08:00
// CHECK: %[[GTN_IF_1:.*]] = call i32 @__kmpc_global_thread_num(%struct.ident_t* @[[SI_VAR_IF_1:.*]])
// CHECK: br i1 %[[IF_COND_VAR_1]], label %[[IF_COND_TRUE_BLOCK_1:.*]], label %[[IF_COND_FALSE_BLOCK_1:.*]]
// CHECK: [[IF_COND_TRUE_BLOCK_1]]:
// CHECK: br label %[[OUTLINED_CALL_IF_BLOCK_1:.*]]
// CHECK: [[OUTLINED_CALL_IF_BLOCK_1]]:
// CHECK: call void {{.*}} @__kmpc_fork_call(%struct.ident_t* @[[SI_VAR_IF_1]], {{.*}} @[[OMP_OUTLINED_FN_IF_1:.*]] to void
// CHECK: br label %[[OUTLINED_EXIT_IF_1:.*]]
// CHECK: [[OUTLINED_EXIT_IF_1]]:
// CHECK: br label %[[OUTLINED_EXIT_IF_2:.*]]
// CHECK: [[OUTLINED_EXIT_IF_2]]:
// CHECK: br label %[[RETURN_BLOCK_IF_1:.*]]
// CHECK: [[IF_COND_FALSE_BLOCK_1]]:
// CHECK: call void @__kmpc_serialized_parallel(%struct.ident_t* @[[SI_VAR_IF_1]], i32 %[[GTN_IF_1]])
// CHECK: call void @[[OMP_OUTLINED_FN_IF_1]]
// CHECK: call void @__kmpc_end_serialized_parallel(%struct.ident_t* @[[SI_VAR_IF_1]], i32 %[[GTN_IF_1]])
// CHECK: br label %[[RETURN_BLOCK_IF_1]]
[mlir] replace LLVMIntegerType with built-in integer type The LLVM dialect type system has been closed until now, i.e. did not support types from other dialects inside containers. While this has had obvious benefits of deriving from a common base class, it has led to some simple types being almost identical with the built-in types, namely integer and floating point types. This in turn has led to a lot of larger-scale complexity: simple types must still be converted, numerous operations that correspond to LLVM IR intrinsics are replicated to produce versions operating on either LLVM dialect or built-in types leading to quasi-duplicate dialects, lowering to the LLVM dialect is essentially required to be one-shot because of type conversion, etc. In this light, it is reasonable to trade off some local complexity in the internal implementation of LLVM dialect types for removing larger-scale system complexity. Previous commits to the LLVM dialect type system have adapted the API to support types from other dialects. Replace LLVMIntegerType with the built-in IntegerType plus additional checks that such types are signless (these are isolated in a utility function that replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice. Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94178
2021-01-06 23:19:04 +08:00
omp.parallel if(%1 : i1) {
[OpenMP,MLIR] Translation of parallel operation: num_threads, if clauses 3/n This simple patch translates the num_threads and if clauses of the parallel operation. Also includes test cases. A minor change was made to parsing of the if clause to parse AnyType and return the parsed type. Updates to test cases also. Reviewed by: SouraVX Differential Revision: https://reviews.llvm.org/D84798
2020-08-08 02:33:46 +08:00
omp.barrier
omp.terminator
}
// CHECK: [[RETURN_BLOCK_IF_1]]:
// CHECK: ret void
llvm.return
}
// CHECK: define internal void @[[OMP_OUTLINED_FN_IF_1]]
// CHECK: call void @__kmpc_barrier
[MLIR,OpenMP] Lowering of parallel operation: proc_bind clause 2/n This patch adds the translation of the proc_bind clause in a parallel operation. The values that can be specified for the proc_bind clause are specified in the OMP.td tablegen file in the llvm/Frontend/OpenMP directory. From this single source of truth enumeration for proc_bind is generated in llvm and mlir (used in specification of the parallel Operation in the OpenMP dialect). A function to return the enum value from the string representation is also generated. A new header file (DirectiveEmitter.h) containing definitions of classes directive, clause, clauseval etc is created so that it can be used in mlir as well. Reviewers: clementval, jdoerfert, DavidTruby Differential Revision: https://reviews.llvm.org/D84347
2020-07-23 00:28:04 +08:00
// CHECK-LABEL: define void @test_omp_parallel_3()
llvm.func @test_omp_parallel_3() -> () {
// CHECK: [[OMP_THREAD_3_1:%.*]] = call i32 @__kmpc_global_thread_num(%struct.ident_t* @{{[0-9]+}})
// CHECK: call void @__kmpc_push_proc_bind(%struct.ident_t* @{{[0-9]+}}, i32 [[OMP_THREAD_3_1]], i32 2)
// CHECK: call void{{.*}}@__kmpc_fork_call{{.*}}@[[OMP_OUTLINED_FN_3_1:.*]] to {{.*}}
omp.parallel proc_bind(master) {
omp.barrier
omp.terminator
}
// CHECK: [[OMP_THREAD_3_2:%.*]] = call i32 @__kmpc_global_thread_num(%struct.ident_t* @{{[0-9]+}})
// CHECK: call void @__kmpc_push_proc_bind(%struct.ident_t* @{{[0-9]+}}, i32 [[OMP_THREAD_3_2]], i32 3)
// CHECK: call void{{.*}}@__kmpc_fork_call{{.*}}@[[OMP_OUTLINED_FN_3_2:.*]] to {{.*}}
omp.parallel proc_bind(close) {
omp.barrier
omp.terminator
}
// CHECK: [[OMP_THREAD_3_3:%.*]] = call i32 @__kmpc_global_thread_num(%struct.ident_t* @{{[0-9]+}})
// CHECK: call void @__kmpc_push_proc_bind(%struct.ident_t* @{{[0-9]+}}, i32 [[OMP_THREAD_3_3]], i32 4)
// CHECK: call void{{.*}}@__kmpc_fork_call{{.*}}@[[OMP_OUTLINED_FN_3_3:.*]] to {{.*}}
omp.parallel proc_bind(spread) {
omp.barrier
omp.terminator
}
llvm.return
}
// CHECK: define internal void @[[OMP_OUTLINED_FN_3_3]]
// CHECK: define internal void @[[OMP_OUTLINED_FN_3_2]]
// CHECK: define internal void @[[OMP_OUTLINED_FN_3_1]]
[OpenMP][MLIR] Fix for nested parallel regions Usage of nested parallel regions were not working correctly and leading to assertion failures. Fix contains the following changes, 1) Don't set the insertion point in the body callback. 2) Save the continuation IP in a stack and set the branch to continuationIP at the terminator. Reviewed By: SouraVX, jdoerfert, ftynse Differential Revision: https://reviews.llvm.org/D88720
2020-10-18 05:24:27 +08:00
// CHECK-LABEL: define void @test_omp_parallel_4()
llvm.func @test_omp_parallel_4() -> () {
// CHECK: call void {{.*}}@__kmpc_fork_call{{.*}} @[[OMP_OUTLINED_FN_4_1:.*]] to
// CHECK: define internal void @[[OMP_OUTLINED_FN_4_1]]
// CHECK: call void @__kmpc_barrier
// CHECK: call void {{.*}}@__kmpc_fork_call{{.*}} @[[OMP_OUTLINED_FN_4_1_1:.*]] to
// CHECK: call void @__kmpc_barrier
omp.parallel {
omp.barrier
// CHECK: define internal void @[[OMP_OUTLINED_FN_4_1_1]]
// CHECK: call void @__kmpc_barrier
omp.parallel {
omp.barrier
omp.terminator
}
omp.barrier
omp.terminator
}
llvm.return
}
llvm.func @test_omp_parallel_5() -> () {
// CHECK: call void {{.*}}@__kmpc_fork_call{{.*}} @[[OMP_OUTLINED_FN_5_1:.*]] to
// CHECK: define internal void @[[OMP_OUTLINED_FN_5_1]]
// CHECK: call void @__kmpc_barrier
// CHECK: call void {{.*}}@__kmpc_fork_call{{.*}} @[[OMP_OUTLINED_FN_5_1_1:.*]] to
// CHECK: call void @__kmpc_barrier
omp.parallel {
omp.barrier
// CHECK: define internal void @[[OMP_OUTLINED_FN_5_1_1]]
omp.parallel {
// CHECK: call void {{.*}}@__kmpc_fork_call{{.*}} @[[OMP_OUTLINED_FN_5_1_1_1:.*]] to
// CHECK: define internal void @[[OMP_OUTLINED_FN_5_1_1_1]]
// CHECK: call void @__kmpc_barrier
omp.parallel {
omp.barrier
omp.terminator
}
omp.terminator
}
omp.barrier
omp.terminator
}
llvm.return
}
[MLIR,OpenMP] Added support for lowering MasterOp to LLVMIR Some Ops in OMP dialect have regions associated with them i.e `ParallelOp` `MasterOp`. Lowering of these regions involves interfacing with `OMPIRBuilder` using callbacks, yet there still exist opportunities for sharing common code in between. This patch factors out common code into a separate function and adds support for lowering `MasterOp` using that. Lowering of `ParallelOp` is also modified appropriately. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D87247
2020-10-20 16:53:00 +08:00
// CHECK-LABEL: define void @test_omp_master()
llvm.func @test_omp_master() -> () {
// CHECK: call void {{.*}}@__kmpc_fork_call{{.*}} @{{.*}} to
// CHECK: omp.par.region1:
omp.parallel {
omp.master {
// CHECK: [[OMP_THREAD_3_4:%.*]] = call i32 @__kmpc_global_thread_num(%struct.ident_t* @{{[0-9]+}})
// CHECK: {{[0-9]+}} = call i32 @__kmpc_master(%struct.ident_t* @{{[0-9]+}}, i32 [[OMP_THREAD_3_4]])
// CHECK: omp.master.region
// CHECK: call void @__kmpc_end_master(%struct.ident_t* @{{[0-9]+}}, i32 [[OMP_THREAD_3_4]])
// CHECK: br label %omp_region.end
omp.terminator
}
omp.terminator
}
omp.parallel {
omp.parallel {
omp.master {
omp.terminator
}
omp.terminator
}
omp.terminator
}
llvm.return
}
[mlir] Add translation of omp.wsloop to LLVM IR Introduce a translation of OpenMP workshare loop construct to LLVM IR. This is a minimalist version to enable the pipeline and currently only supports static loop schedule (default in the specification) on non-collapsed loops. Other features will be added on per-need basis. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D92055
2020-12-08 23:45:19 +08:00
// -----
// CHECK: %struct.ident_t = type
// CHECK: @[[$parallel_loc:.*]] = private unnamed_addr constant {{.*}} c";LLVMDialectModule;wsloop_simple;{{[0-9]+}};{{[0-9]+}};;\00"
// CHECK: @[[$parallel_loc_struct:.*]] = private unnamed_addr constant %struct.ident_t {{.*}} @[[$parallel_loc]], {{.*}}
// CHECK: @[[$wsloop_loc:.*]] = private unnamed_addr constant {{.*}} c";LLVMDialectModule;wsloop_simple;{{[0-9]+}};{{[0-9]+}};;\00"
// CHECK: @[[$wsloop_loc_struct:.*]] = private unnamed_addr constant %struct.ident_t {{.*}} @[[$wsloop_loc]], {{.*}}
// CHECK-LABEL: @wsloop_simple
[mlir] replace LLVM dialect float types with built-ins Continue the convergence between LLVM dialect and built-in types by replacing the bfloat, half, float and double LLVM dialect types with their built-in counterparts. At the API level, this is a direct replacement. At the syntax level, we change the keywords to `bf16`, `f16`, `f32` and `f64`, respectively, to be compatible with the built-in type syntax. The old keywords can still be parsed but produce a deprecation warning and will be eventually removed. Depends On D94178 Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94179
2021-01-06 23:21:08 +08:00
llvm.func @wsloop_simple(%arg0: !llvm.ptr<f32>) {
[mlir] replace LLVMIntegerType with built-in integer type The LLVM dialect type system has been closed until now, i.e. did not support types from other dialects inside containers. While this has had obvious benefits of deriving from a common base class, it has led to some simple types being almost identical with the built-in types, namely integer and floating point types. This in turn has led to a lot of larger-scale complexity: simple types must still be converted, numerous operations that correspond to LLVM IR intrinsics are replicated to produce versions operating on either LLVM dialect or built-in types leading to quasi-duplicate dialects, lowering to the LLVM dialect is essentially required to be one-shot because of type conversion, etc. In this light, it is reasonable to trade off some local complexity in the internal implementation of LLVM dialect types for removing larger-scale system complexity. Previous commits to the LLVM dialect type system have adapted the API to support types from other dialects. Replace LLVMIntegerType with the built-in IntegerType plus additional checks that such types are signless (these are isolated in a utility function that replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice. Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94178
2021-01-06 23:19:04 +08:00
%0 = llvm.mlir.constant(42 : index) : i64
%1 = llvm.mlir.constant(10 : index) : i64
%2 = llvm.mlir.constant(1 : index) : i64
[mlir] Add translation of omp.wsloop to LLVM IR Introduce a translation of OpenMP workshare loop construct to LLVM IR. This is a minimalist version to enable the pipeline and currently only supports static loop schedule (default in the specification) on non-collapsed loops. Other features will be added on per-need basis. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D92055
2020-12-08 23:45:19 +08:00
omp.parallel {
"omp.wsloop"(%1, %0, %2) ( {
[mlir] replace LLVMIntegerType with built-in integer type The LLVM dialect type system has been closed until now, i.e. did not support types from other dialects inside containers. While this has had obvious benefits of deriving from a common base class, it has led to some simple types being almost identical with the built-in types, namely integer and floating point types. This in turn has led to a lot of larger-scale complexity: simple types must still be converted, numerous operations that correspond to LLVM IR intrinsics are replicated to produce versions operating on either LLVM dialect or built-in types leading to quasi-duplicate dialects, lowering to the LLVM dialect is essentially required to be one-shot because of type conversion, etc. In this light, it is reasonable to trade off some local complexity in the internal implementation of LLVM dialect types for removing larger-scale system complexity. Previous commits to the LLVM dialect type system have adapted the API to support types from other dialects. Replace LLVMIntegerType with the built-in IntegerType plus additional checks that such types are signless (these are isolated in a utility function that replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice. Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94178
2021-01-06 23:19:04 +08:00
^bb0(%arg1: i64):
[mlir] Add translation of omp.wsloop to LLVM IR Introduce a translation of OpenMP workshare loop construct to LLVM IR. This is a minimalist version to enable the pipeline and currently only supports static loop schedule (default in the specification) on non-collapsed loops. Other features will be added on per-need basis. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D92055
2020-12-08 23:45:19 +08:00
// The form of the emitted IR is controlled by OpenMPIRBuilder and
// tested there. Just check that the right functions are called.
// CHECK: call i32 @__kmpc_global_thread_num
// CHECK: call void @__kmpc_for_static_init_{{.*}}(%struct.ident_t* @[[$wsloop_loc_struct]],
[mlir] replace LLVM dialect float types with built-ins Continue the convergence between LLVM dialect and built-in types by replacing the bfloat, half, float and double LLVM dialect types with their built-in counterparts. At the API level, this is a direct replacement. At the syntax level, we change the keywords to `bf16`, `f16`, `f32` and `f64`, respectively, to be compatible with the built-in type syntax. The old keywords can still be parsed but produce a deprecation warning and will be eventually removed. Depends On D94178 Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94179
2021-01-06 23:21:08 +08:00
%3 = llvm.mlir.constant(2.000000e+00 : f32) : f32
%4 = llvm.getelementptr %arg0[%arg1] : (!llvm.ptr<f32>, i64) -> !llvm.ptr<f32>
llvm.store %3, %4 : !llvm.ptr<f32>
[mlir] Add translation of omp.wsloop to LLVM IR Introduce a translation of OpenMP workshare loop construct to LLVM IR. This is a minimalist version to enable the pipeline and currently only supports static loop schedule (default in the specification) on non-collapsed loops. Other features will be added on per-need basis. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D92055
2020-12-08 23:45:19 +08:00
omp.yield
// CHECK: call void @__kmpc_for_static_fini(%struct.ident_t* @[[$wsloop_loc_struct]],
[mlir] replace LLVMIntegerType with built-in integer type The LLVM dialect type system has been closed until now, i.e. did not support types from other dialects inside containers. While this has had obvious benefits of deriving from a common base class, it has led to some simple types being almost identical with the built-in types, namely integer and floating point types. This in turn has led to a lot of larger-scale complexity: simple types must still be converted, numerous operations that correspond to LLVM IR intrinsics are replicated to produce versions operating on either LLVM dialect or built-in types leading to quasi-duplicate dialects, lowering to the LLVM dialect is essentially required to be one-shot because of type conversion, etc. In this light, it is reasonable to trade off some local complexity in the internal implementation of LLVM dialect types for removing larger-scale system complexity. Previous commits to the LLVM dialect type system have adapted the API to support types from other dialects. Replace LLVMIntegerType with the built-in IntegerType plus additional checks that such types are signless (these are isolated in a utility function that replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice. Reviewed By: mehdi_amini, silvas, antiagainst Differential Revision: https://reviews.llvm.org/D94178
2021-01-06 23:19:04 +08:00
}) {operand_segment_sizes = dense<[1, 1, 1, 0, 0, 0, 0, 0, 0]> : vector<9xi32>} : (i64, i64, i64) -> ()
[mlir] Add translation of omp.wsloop to LLVM IR Introduce a translation of OpenMP workshare loop construct to LLVM IR. This is a minimalist version to enable the pipeline and currently only supports static loop schedule (default in the specification) on non-collapsed loops. Other features will be added on per-need basis. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D92055
2020-12-08 23:45:19 +08:00
omp.terminator
}
llvm.return
}
[MLIR][OpenMP] Attribute to include WsLoop upperbound This patch adds an attribute `inclusive` which if present causes the upperbound to be included in the loop iteration interval. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D94235
2021-01-07 23:51:55 +08:00
// CHECK-LABEL: @wsloop_inclusive_1
[mlir] Drop deprecated syntax for LLVM dialect types After the LLVM dialect types were ported to use built-in types, the parser kept supporting the old syntax for LLVM dialect types to produce built-in types for compatibility. Drop this support. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D96275
2021-02-09 01:22:23 +08:00
llvm.func @wsloop_inclusive_1(%arg0: !llvm.ptr<f32>) {
%0 = llvm.mlir.constant(42 : index) : i64
%1 = llvm.mlir.constant(10 : index) : i64
%2 = llvm.mlir.constant(1 : index) : i64
[MLIR][OpenMP] Attribute to include WsLoop upperbound This patch adds an attribute `inclusive` which if present causes the upperbound to be included in the loop iteration interval. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D94235
2021-01-07 23:51:55 +08:00
// CHECK: store i64 31, i64* %{{.*}}upperbound
"omp.wsloop"(%1, %0, %2) ( {
[mlir] Drop deprecated syntax for LLVM dialect types After the LLVM dialect types were ported to use built-in types, the parser kept supporting the old syntax for LLVM dialect types to produce built-in types for compatibility. Drop this support. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D96275
2021-02-09 01:22:23 +08:00
^bb0(%arg1: i64):
%3 = llvm.mlir.constant(2.000000e+00 : f32) : f32
%4 = llvm.getelementptr %arg0[%arg1] : (!llvm.ptr<f32>, i64) -> !llvm.ptr<f32>
llvm.store %3, %4 : !llvm.ptr<f32>
[MLIR][OpenMP] Attribute to include WsLoop upperbound This patch adds an attribute `inclusive` which if present causes the upperbound to be included in the loop iteration interval. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D94235
2021-01-07 23:51:55 +08:00
omp.yield
[mlir] Drop deprecated syntax for LLVM dialect types After the LLVM dialect types were ported to use built-in types, the parser kept supporting the old syntax for LLVM dialect types to produce built-in types for compatibility. Drop this support. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D96275
2021-02-09 01:22:23 +08:00
}) {operand_segment_sizes = dense<[1, 1, 1, 0, 0, 0, 0, 0, 0]> : vector<9xi32>} : (i64, i64, i64) -> ()
[MLIR][OpenMP] Attribute to include WsLoop upperbound This patch adds an attribute `inclusive` which if present causes the upperbound to be included in the loop iteration interval. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D94235
2021-01-07 23:51:55 +08:00
llvm.return
}
// CHECK-LABEL: @wsloop_inclusive_2
[mlir] Drop deprecated syntax for LLVM dialect types After the LLVM dialect types were ported to use built-in types, the parser kept supporting the old syntax for LLVM dialect types to produce built-in types for compatibility. Drop this support. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D96275
2021-02-09 01:22:23 +08:00
llvm.func @wsloop_inclusive_2(%arg0: !llvm.ptr<f32>) {
%0 = llvm.mlir.constant(42 : index) : i64
%1 = llvm.mlir.constant(10 : index) : i64
%2 = llvm.mlir.constant(1 : index) : i64
[MLIR][OpenMP] Attribute to include WsLoop upperbound This patch adds an attribute `inclusive` which if present causes the upperbound to be included in the loop iteration interval. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D94235
2021-01-07 23:51:55 +08:00
// CHECK: store i64 32, i64* %{{.*}}upperbound
"omp.wsloop"(%1, %0, %2) ( {
[mlir] Drop deprecated syntax for LLVM dialect types After the LLVM dialect types were ported to use built-in types, the parser kept supporting the old syntax for LLVM dialect types to produce built-in types for compatibility. Drop this support. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D96275
2021-02-09 01:22:23 +08:00
^bb0(%arg1: i64):
%3 = llvm.mlir.constant(2.000000e+00 : f32) : f32
%4 = llvm.getelementptr %arg0[%arg1] : (!llvm.ptr<f32>, i64) -> !llvm.ptr<f32>
llvm.store %3, %4 : !llvm.ptr<f32>
[MLIR][OpenMP] Attribute to include WsLoop upperbound This patch adds an attribute `inclusive` which if present causes the upperbound to be included in the loop iteration interval. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D94235
2021-01-07 23:51:55 +08:00
omp.yield
[mlir] Drop deprecated syntax for LLVM dialect types After the LLVM dialect types were ported to use built-in types, the parser kept supporting the old syntax for LLVM dialect types to produce built-in types for compatibility. Drop this support. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D96275
2021-02-09 01:22:23 +08:00
}) {inclusive, operand_segment_sizes = dense<[1, 1, 1, 0, 0, 0, 0, 0, 0]> : vector<9xi32>} : (i64, i64, i64) -> ()
[MLIR][OpenMP] Attribute to include WsLoop upperbound This patch adds an attribute `inclusive` which if present causes the upperbound to be included in the loop iteration interval. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D94235
2021-01-07 23:51:55 +08:00
llvm.return
}