maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CodeGenCXX/pragma-loop-safety-nested.cpp

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

28 lines
1.4 KiB
C++
Raw Normal View History

[CodeGen] Emit parallel_loop_access for each loop in the loop stack. Summary: Emit !llvm.mem.parallel_loop_access metadata for memory accesses even if the parallel loop is not the top on the loop stack. Fixes llvm.org/PR37558. Reviewers: ABataev, hfinkel, amusman, tyler.nowicki Reviewed By: hfinkel Subscribers: Meinersbur, hfinkel, cfe-commits Differential Revision: https://reviews.llvm.org/D48808 llvm-svn: 338810
2018-08-03 12:42:52 +08:00
// RUN: %clang_cc1 -triple x86_64-apple-darwin -std=c++11 -emit-llvm -o - %s | FileCheck %s
[CodeGen] Generate llvm.loop.parallel_accesses instead of llvm.mem.parallel_loop_access metadata. Instead of generating llvm.mem.parallel_loop_access metadata, generate llvm.access.group on instructions and llvm.loop.parallel_accesses on loops. There is one access group per generated loop. This is clang part of D52116/r349725. Differential Revision: https://reviews.llvm.org/D52117 llvm-svn: 349823
2018-12-21 05:24:54 +08:00
// Verify that the outer loop has the llvm.access.group property for the
// accesses outside and inside the inner loop.
[CodeGen] Emit parallel_loop_access for each loop in the loop stack. Summary: Emit !llvm.mem.parallel_loop_access metadata for memory accesses even if the parallel loop is not the top on the loop stack. Fixes llvm.org/PR37558. Reviewers: ABataev, hfinkel, amusman, tyler.nowicki Reviewed By: hfinkel Subscribers: Meinersbur, hfinkel, cfe-commits Differential Revision: https://reviews.llvm.org/D48808 llvm-svn: 338810
2018-08-03 12:42:52 +08:00
void vectorize_nested_test(int *List, int Length) {
#pragma clang loop vectorize(assume_safety) interleave(disable) unroll(disable)
for (int i = 0; i < Length; ++i) {
#pragma clang loop vectorize(assume_safety) interleave(disable) unroll(disable)
for (int j = 0; j < Length; ++j)
List[i * Length + j] = (i + j) * 2;
}
}
[CodeGen] Generate llvm.loop.parallel_accesses instead of llvm.mem.parallel_loop_access metadata. Instead of generating llvm.mem.parallel_loop_access metadata, generate llvm.access.group on instructions and llvm.loop.parallel_accesses on loops. There is one access group per generated loop. This is clang part of D52116/r349725. Differential Revision: https://reviews.llvm.org/D52117 llvm-svn: 349823
2018-12-21 05:24:54 +08:00
// CHECK: load i32, i32* %Length.addr, align 4, !llvm.access.group ![[ACCESS_GROUP_2:[0-9]+]]
[CodeGen] Emit parallel_loop_access for each loop in the loop stack. Summary: Emit !llvm.mem.parallel_loop_access metadata for memory accesses even if the parallel loop is not the top on the loop stack. Fixes llvm.org/PR37558. Reviewers: ABataev, hfinkel, amusman, tyler.nowicki Reviewed By: hfinkel Subscribers: Meinersbur, hfinkel, cfe-commits Differential Revision: https://reviews.llvm.org/D48808 llvm-svn: 338810
2018-08-03 12:42:52 +08:00
// CHECK: %[[MUL:.+]] = mul
[CodeGen] Generate llvm.loop.parallel_accesses instead of llvm.mem.parallel_loop_access metadata. Instead of generating llvm.mem.parallel_loop_access metadata, generate llvm.access.group on instructions and llvm.loop.parallel_accesses on loops. There is one access group per generated loop. This is clang part of D52116/r349725. Differential Revision: https://reviews.llvm.org/D52117 llvm-svn: 349823
2018-12-21 05:24:54 +08:00
// CHECK: store i32 %[[MUL]], i32* %{{.+}}, !llvm.access.group ![[ACCESS_GROUP_LIST_3:[0-9]+]]
[CodeGen] Emit parallel_loop_access for each loop in the loop stack. Summary: Emit !llvm.mem.parallel_loop_access metadata for memory accesses even if the parallel loop is not the top on the loop stack. Fixes llvm.org/PR37558. Reviewers: ABataev, hfinkel, amusman, tyler.nowicki Reviewed By: hfinkel Subscribers: Meinersbur, hfinkel, cfe-commits Differential Revision: https://reviews.llvm.org/D48808 llvm-svn: 338810
2018-08-03 12:42:52 +08:00
// CHECK: br label %{{.+}}, !llvm.loop ![[INNER_LOOPID:[0-9]+]]
// CHECK: br label %{{.+}}, !llvm.loop ![[OUTER_LOOPID:[0-9]+]]
[CodeGen] Generate llvm.loop.parallel_accesses instead of llvm.mem.parallel_loop_access metadata. Instead of generating llvm.mem.parallel_loop_access metadata, generate llvm.access.group on instructions and llvm.loop.parallel_accesses on loops. There is one access group per generated loop. This is clang part of D52116/r349725. Differential Revision: https://reviews.llvm.org/D52117 llvm-svn: 349823
2018-12-21 05:24:54 +08:00
// CHECK: ![[ACCESS_GROUP_2]] = distinct !{}
// CHECK: ![[ACCESS_GROUP_LIST_3]] = !{![[ACCESS_GROUP_2]], ![[ACCESS_GROUP_4:[0-9]+]]}
// CHECK: ![[ACCESS_GROUP_4]] = distinct !{}
[CodeGen] Generate follow-up metadata for loops with more than one transformation. Before this patch, CGLoop would dump all transformations for a loop into a single LoopID without encoding any order in which to apply them. rL348944 added the possibility to encode a transformation order using followup-attributes. When a loop has more than one transformation, use the follow-up attribute define the order in which they are applied. The emitted order is the defacto order as defined by the current LLVM pass pipeline, which is: LoopFullUnrollPass LoopDistributePass LoopVectorizePass LoopUnrollAndJamPass LoopUnrollPass MachinePipeliner This patch should therefore not change the assembly output, assuming that all explicit transformations can be applied, and no implicit transformations in-between. In the former case, WarnMissedTransformationsPass should emit a warning (except for MachinePipeliner which is not implemented yet). The latter could be avoided by adding 'llvm.loop.disable_nonforced' attributes. Because LoopUnrollAndJamPass processes a loop nest, generation of the MDNode is delayed to after the inner loop metadata have been processed. A temporary LoopID is therefore used to annotate instructions and RAUW'ed by the actual LoopID later. Differential Revision: https://reviews.llvm.org/D57978 llvm-svn: 357415
2019-04-02 01:47:41 +08:00
// CHECK: ![[INNER_LOOPID]] = distinct !{![[INNER_LOOPID]], ![[PARALLEL_ACCESSES_8:[0-9]+]]
[CodeGen] Generate llvm.loop.parallel_accesses instead of llvm.mem.parallel_loop_access metadata. Instead of generating llvm.mem.parallel_loop_access metadata, generate llvm.access.group on instructions and llvm.loop.parallel_accesses on loops. There is one access group per generated loop. This is clang part of D52116/r349725. Differential Revision: https://reviews.llvm.org/D52117 llvm-svn: 349823
2018-12-21 05:24:54 +08:00
// CHECK: ![[PARALLEL_ACCESSES_8]] = !{!"llvm.loop.parallel_accesses", ![[ACCESS_GROUP_4]]}
[CodeGen] Generate follow-up metadata for loops with more than one transformation. Before this patch, CGLoop would dump all transformations for a loop into a single LoopID without encoding any order in which to apply them. rL348944 added the possibility to encode a transformation order using followup-attributes. When a loop has more than one transformation, use the follow-up attribute define the order in which they are applied. The emitted order is the defacto order as defined by the current LLVM pass pipeline, which is: LoopFullUnrollPass LoopDistributePass LoopVectorizePass LoopUnrollAndJamPass LoopUnrollPass MachinePipeliner This patch should therefore not change the assembly output, assuming that all explicit transformations can be applied, and no implicit transformations in-between. In the former case, WarnMissedTransformationsPass should emit a warning (except for MachinePipeliner which is not implemented yet). The latter could be avoided by adding 'llvm.loop.disable_nonforced' attributes. Because LoopUnrollAndJamPass processes a loop nest, generation of the MDNode is delayed to after the inner loop metadata have been processed. A temporary LoopID is therefore used to annotate instructions and RAUW'ed by the actual LoopID later. Differential Revision: https://reviews.llvm.org/D57978 llvm-svn: 357415
2019-04-02 01:47:41 +08:00
// CHECK: ![[OUTER_LOOPID]] = distinct !{![[OUTER_LOOPID]], ![[PARALLEL_ACCESSES_10:[0-9]+]]
[CodeGen] Generate llvm.loop.parallel_accesses instead of llvm.mem.parallel_loop_access metadata. Instead of generating llvm.mem.parallel_loop_access metadata, generate llvm.access.group on instructions and llvm.loop.parallel_accesses on loops. There is one access group per generated loop. This is clang part of D52116/r349725. Differential Revision: https://reviews.llvm.org/D52117 llvm-svn: 349823
2018-12-21 05:24:54 +08:00
// CHECK: ![[PARALLEL_ACCESSES_10]] = !{!"llvm.loop.parallel_accesses", ![[ACCESS_GROUP_2]]}